The development of Nascom systems for ground communications began in 1958 with Project Vanguard. The low-speed systems (rates less than 9.6 Kbs) were developed following existing standards; but, there were no comparable standards for high-speed systems. As a result, these systems were developed using custom protocols and custom hardware. Technology has made enormous strides since the ground support systems were implemented. Standards for computer equipment, software, and high-speed communications exist and the performance of current workstations exceeds that of the mainframes used in the development of the ground systems. Nascom is in the process of upgrading its ground support systems and providing additional services. The Message Switching System (MSS), Communications Address Processor (CAP), and Multiplexer/Demultiplexer (MDM) Automated Control System (MACS) are all examples of Nascom systems developed using standards such as, X-windows, Motif, and Simple Network Management Protocol (SNMP). Also, the Earth Observing System (EOS) Communications (Ecom) project is stressing standards as an integral part of its network. The move towards standards has produced a reduction in development, maintenance, and interoperability costs, while providing operational quality improvement. The Facility and Resource Manager (FARM) project has been established to integrate the Nascom networks and systems into a common network management architecture. The maximization of standards and implementation of computer automation in the architecture will lead to continued cost reductions and increased operational efficiency. The first step has been to derive overall Nascom requirements and identify the functionality common to all the current management systems. The identification of these common functions will enable the reuse of processes in the management architecture and promote increased use of automation throughout the Nascom network. The MSS, CAP, MACS, and Ecom projects have indicated the potential value of commercial-off-the-shelf (COTS) and standards through reduced cost and high quality. The FARM will allow the application of the lessons learned from these projects to all future Nascom systems

Drake, Brian C.

Messent, David

English

NASA Technical Reports Server

RE-ENGINEERING NASCOM 'S NETWORK MANAGEMENT
ARCHITECTURE
N95- 17584
/ /
BRIAN C. DRAKE
GODDARD SPACE FLIGHT CENTER (GSFC)
CODE 541.2
GREENBELT, MD 20771
&
DAVID MESSENT
COMPUTER SCIENCES CORPORATION
7700 HUBBLE DRIVE
LANHAM-SEABROOK, MD 20706
ABSTRACT
The development of Nascom systems for
ground communications began in 1958
with Project Vanguard. The low-speed
systems (rates less than 9.6 Kbs) were
developed following existing standards;
but, there were no comparable standards
for high-speed systems. As a result,
these systems were developed using
custom protocols and custom hardware.
Technology has made enormous strides
since the ground support systems were
implemented. Standards for computer
equipment, software, and high-speed
communications exist and the
performance of current workstations
exceeds that of the mainframes used in
the development of the ground systems.
Nascom is in the process of upgrading its
ground support systems and providing
additional services. The Message
Switching System (MSS),
Communications Address Processor
(CAP), and Multiplexer/Demultiplexer
(MDM) Automated Control System
(MACS) are all examples of Nascom
systems developed using standards such
as, X-windows, Motif, and Simple
Network Management Protocol (SNMP).
Also, the Earth Observing System
(EOS) Communications (Ecom) project
is stressing standards as an integral part
of its network. The move towards
standards has produced a reduction in
development, maintenance, and
interoperability costs, while providing
operational quality improvement.
The Facility and Resource Manager
(FARM) project has been established to
integrate the Nascom networks and
systems into a common network
management architecture. The
maximization of standards and
implementation of computer automation
in the architecture will lead to continued
cost reductions and increased operational
efficiency. The first step has been to
derive overall Nascom requirements and
identify the functionality common to all
the current management systems. The
identification of these common functions
will enable the reuse of processes in the
management architecture and promote
increased use of automation throughout
the Nascom network.
The MSS, CAP, MACS, and Ecom
projects have indicated the potential value
of commercial,off-the-shelf (COTS) and
standards through reduced cost and high
quality. The FARM will allow the
application of the lessons learned from
these projects to all future Nascom
systems.
1133
PAGE _LAt'_ NOT FR.MgD
https://ntrs.nasa.gov/search.jsp?R=19950011169 2020-06-16T09:28:18+00:00Z
5f ¸
:• i ¸ k ¸ •
"! ik
iq: if:i:!} {_if
!:i
! _i'i'
:,?/iiiiiiii_:i_
x_7_i i_/ :i I
i_i}/i
: i
i _,
INTRODUCTION
The development of NASA
Communication (Nascom) systems for
ground communications began in 1958
with Project Vanguard. The low-speed
systems (less than 9600 bps) were
developed following existing standards.
However, the existing communication
standards could not be used to meet the
higher data rates and transmission
reliability requirements demanded by
next generation of NASA projects. As a
result, custom protocols and associated
hardware had to be developed to meet the
needs of the growing space agency.
The Nascom protocol that was developed
in 1968 consisted of a 1200-bit block
with header information, data field, and
polynomial error control field at the end.
Over time, user communication
requirements increased and the Nascom
block size was increased to 4800 bits.
The basic structure remained the same,
but provided an expanded user data field.
integrity. Fortunately, communication
standards for both transmission and
management had been developing over
the last few years to keep up with user
demands.
Nascom began its move towards
standards with development of an X.25
network for the Pacor/Gamma Ray
Observatory (GRO) project and the
Mission Operations and Data Systems
Directorate (MO&DSD) Operational/
Development Network (MODNET)/
Nascom Operational Local Area Network
(NOLAN) for high-speed local data
distribution. Now, Nascom is
developing a high-speed Asynchronous
Transfer Mode (ATM) network for the
EOS project and re-engineering its
automated network management
architecture to integrate these standards-
based networks and the existing
customized network into a centralized
operations area.
EXISTING ARCHITECTURE
C
i,
/_}ii!i&::
}i/!i!_i '
• !<
x x
<
i}
In the 1970's, development began on a
system of geosynchronous satellites to
relay data around the world instead of
many earth stations. As the Tracking and
Data Relay Satellite System (TDRSS)
grew, it became evident the manual
network control and monitoring would be
impossible. Nascom began to automate
its portion of the network.
Once again, network management
standards did not exist to meet NASA's
requirements. Nascom began custom
development for automated network
management, using the existing Nascom
protocol with 1200-bit blocks as the
management protocol.
With today's reality of budget reductions
and the high cost of custom development,
the use of standards has become as
important as high-speed and data
Nascom currently has three distinct
networks with separate management
systems: the Data Distribution and
Command System (DDCS), MODNET,
and the 4800-bit block network.
The DDCS X.25 network has two nodes
located at GSFC, a node at Marshall
Space Flight Center (MSFC) and a node
at the University of California at Berkeley
(UCB) (figure 1), distributing X.25
packets at data rates up to 224 Kbps.
Each node has a redundant backup for
automatic fail over. It is composed of
COTS hardware and software with
integrated network management
software. The controlling node is located
in the Nascom computer facility at
GSFC.
>!i "
i_:ii}/
if _
1134
!ili!!!!iili!iI f!¸..................._ __z___,__ _ z_ __ ___ __ ___ _ ____i_ i_i_i__!_,i_i_!_i_!_!_i_>_._i_i_i_ii_ii i_i_i!_iii_!_ii!_iii!ii!_i_!!_i_i!i_ii_i_i_ii!ii_iii_i_iiiiiiiiiiiiiii_iii_iiiiiiiii_iiiii_iiiiii_iiiii_iiii_iiiiiiiiiiiiiiii_iii_iiiiiiiii_iiiiiii_iiiiiiiiiiiii
!i: ¸_ :: i
i ii_!_!_i/i_
_ii _iil _,_
, ,_ ,- . i__, X
M
..... 56 Kbps
!i
i
, ii!iii,! ii: 
I
i iii
224 Kbps
ili!ii_:ii!:iii'
iilil
:)
iil_ :
: i!:
: 5¸¸¸i¸ :
Figure 1. The DDCS
The second network is the Mission
Operations and Data Systems Directorate
(MO&DSD) Operational/Development
Network (MODNET). MODNET was
formed in May 1986 through the
integration of three division-level
networks: the MOD&DSD Network
(MNET), Mission Operations Division
(MOD) Local Area Network
(MODLAN), and the Information
Processing Division LAN (InfoLAN).
This network provides high-speed, 50
Mbps, interconnectivity between
operational LANs and computer systems
at GSFC (figure 2).
The LAN technology used by
MODNET is HYPERchannel.
GSFC
Building 3/14
GSFC
Building 28
... (19)
HYPERchannel Trunks
... (21)
GSFC
Building 23
Figure 2. MODNET
... (?)
1135
HYPERchannel, a registered trademark,
is a generic name for the various network
components and protocols developed by
Network Systems Corporation (NSC) to
provide networking capabilities between
entities within Nascom to handle the data
requirements each with their own control
capabilities. The MSS is the original
Nascom block star network hub (figure
3). The MSS provides packet switching
<
|
T I
E I
N i
T t
R I
I
I
High-Speed (HS) Da___
Combined
Operator
Workstation A
Combined
Operator
Workstation B
Message
Switching
System A
HS Transfer
Switch
HS Data
__t Message
Switching
System B
Figure 3. The MSS
XTerminal A
XTerminal B
H
networked computers. The fastest
alternative protocol at the time MODNET
was formed was the 10 Mbps Ethernet.
The NOLAN will expand upon
MODNET's capabilities using a Fiber
Distributed Data Interface (FDDI)
backbone with a larger distribution area.
MODNET/NOLAN will be managed by
Nascom operations using Hewlett-
Packard's HP Openview network
management system with ISICAD for
automated trouble ticketing.
The final network is the 4800-bit block
network that distributes data throughout
the world with data rates ranging from 50
baud to 2 Mbps. There are two network
capabilities for hundreds of 4800-bit
block users with data requirements
ranging from 9600 bps to 1.544 Mbps.
The management control consists of
custom developed software operating on
a Sun workstation.
The TDRSS network portion of Nascom
consists of custom built
Multiplexer/Demultiplexers (MDMs) and
controllers located at the Johnson Space
Center (JSC), NASA Ground Terminal
(NGT), MSFC, and GSFC, a custom
Digital Matrix Switch (DMS) and
controller at GSFC, and custom Data
Link Monitoring Systems (DLMS)
located at GSFC, JSC, and NGT. This
network equipment is being constantly
1136
ii_i:.!ii:ii<ii i:! ::
_:ii::_:i_<i !!i!ii!_
i ¸.
• ':ii_ _ •
ii <
>>
%:i
ii!I _, /
reconfigured according to the network
schedule supplied by the Network
Control Center at GSFC. In order to
meet the reconfiguration requirements of
the network, the Control and Status
System (CSS) was a custom
development to provide automated
network management (figure 4). The
CSS uses the Nascom 1200-bit block to
send commands and receive status from
the network equipment.
and engineer an efficient network
management architecture using new
technology and standards. Computer
workstations today can process the same
data that required mainframes ten years
ago. Standard protocols can send data at
higher rates and provide interconnectivity
between different hardware platforms.
COTS software packages can be found to
meet almost every need. Custom
systems are not an effective application of
limited resources any more.
NCC
Schedules
Control
and
Status
System
Figure 4. The CSS
Status I
.. [
" IStatus
Digital Matrix
Switch
Statistical
Multiplexer
Downlink
-_'= Monitoring
Status System
Status | Multiplexer/ I
Demultiplexer
Advance Schedule _i JSC ]
MORE WITH LESS
Do more with less is the motto of the
world today. Every year, the demand
increases and the budget decreases. In
order to maintain communication
services for the Agency, Nascom has
begun a project to re-engineer its network
management architecture.
The Facility and Resource Manager
(FARM) is an attempt to step back,
analyze Nascom's management
requirements, with an eye to the future,
The basic goal of the FARM is to meet
today's motto, more with less. More
network operational demands with less
budget cause additional capabilities and
requirements to be engineered into the
systems with less engineering budget.
Standards, COTS, reuse, and new
technology are the FARM's tools.
Operational Costs
The biggest cost to Nascom operations is
the large number of personnel required to
run the networks. The 4800-bit block
/
:< <i
1137
network is very manually intensiveand
operates in a reactive mode for
troubleshooting. MODNET, NOLAN,
and the X.25 networksarea little more
automated,lesspersonneldependent;but
beingseparatenetworks,theystill require
additional operationspersonnel. In the
nearfuture,Nascomwill implementand
operatethe FederalTelecommunications
System (FTS)-2000 network and the
EOS Communications (Ecom) ATM
network. Although thesearebothhighly
automatednetworks,theyalsohavetheir
own network managementsystemsthat
haveto beoperated,requiringadditional
personnel.
from text menusto windowed graphical
interfaces. Comprehensive operator
training for each system has to be
developed,which is time consumingand
expensive.
THE FARM ARCHITECTURE
The FARM is developing the functional
requirements of all the management
systems and designing a workstation-
based distributed network management
architecture using SNMP between the
systems. By down-sizing from
mainframes, using COTS products, and
Object Oriented (OO) development
methodologies for software reuse, the
Engineering Costs
Nascom engineering costs largely come
from developing and maintaining
specialized hardware and software. Until
recently, to perform real-time processing
of large amounts of data required the use
of mainframes in conjunction with mini-
computers and large amounts of
assembly code. Add to that a unique
protocol, requiring specialized hardware,
and you have a recipe for a marching
army of software and hardware engineers
to keep Nascom operational.
Figure 5. The FARM
FARM will reduce engineering costs and
development time. By consolidating
multiple network management systems
into a consolidated environment, the
FARM will provide a consistent operator
interface into the different networks,
reducing training time and the need for
separate operators for each system
(figure 5).
Another cost is training personnel on
every new system or network. Every
one of the management systems operated
by Nascom has a different user interface,
The FARM has five functions: operator
interface, data management, resource
scheduling, system automation, and a
non-SNMP gateway (figure 6). The
operator interface will be designed using
X-window and Motif standards to
provide a comprehensive graphical user
interface. COTS development tools, such
as TAE+, will be used to provide rapid
1138
i_:_. :
i!!ii, :
!,
•<
H ,
screen prototyping. This will allow the
FARM the capability to provide the most
efficient user interface in the shortest
amount of time.
The data management function will
provide storage and retrieval of network
configuration, management, and
project is evaluating several vendor
packages for most comprehensive
adherence to requirements.
System automation will be provided by
using expert systems. Several of the
COTS management systems also provide
expert system development tools. The
NCC
FARM
Database
Manager
Operator
Interface
Expert
System
Resource Facility
Scheduler Sensor
MDM
Non-SNMP
Interface
-- DLMS
VDS
ELS
I Ecom
ICLU
SNMP & TCP/IP
DMSR !
ITS
DDCS
FTS-2000 MSS llnternational NOLAN
Muxes
Figure 6. The FARM Functions
SMR
statistical information for the FARM.
This functional will be performed using a
Structured Query Language (SQL)-based
database management system, such as
Oracle or Sybase.
The resource scheduling function
provides the FARM with the ability to
configure TDRSS network equipment
according to the network event schedule
supplied by the Network Control Center.
A large portion of this function can be
performed by COTS network
management software. The FARM
expert systems will analyze alarms and
passive circuit monitoring equipment to
perform pro-active troubleshooting for
the network.
The Nascom networks have equipment
and interfaces with specialized protocols.
These non-SNMP interfaces will require
gateways to convert between protocols.
Again, several of the COTS management
systems provide the capability to define
unique interfaces.
1139
ilia!_ ii!i _i!_/
i_iiii_i_i_
+/
ililil_ ::iii
7
ii-
)i
• •••• • .... • •_: _ : :•: • •• •_ : _ • : :_•:•::•:::•••:_•_•_:_::••_::• •_i_:_:_!ii_:_i¸: I::I:II_:_I_•_I::_!_!_:_i_:!!_:_:_!_i_ii_i_iiiii_!_iii!_?_i:_!_!ii_i_i_!ii_ii_iii_iii_iii_iii_iii!_iiiiiiiiii_iiiiiiiii_i_iJiii_i_i7iii_iiii_i_i!i_iii_iii_iiiiii_
DEVELOPMENT
METHODOLOGY
Development costs will also be reduced
by applying some of the ideas from
Object-Oriented (OO) methodologies to
enhance reuse of already developed
components and COTS products.
The FARM will not use an OO
implementation language, as the project's
short schedule, the long learning curve
for OO methodologies, and the
questionable success of OO projects are
incompatible. Instead, the ideas within
OO development that have been designed
to enhance reuse are being employed.
The first of these OO development ideas
is to perform a problem domain analysis.
A domain is a problem area defined by
the user interface, external interfaces and
interaction of a proposed system. Its
extent depends, in large, on the definition
of what a user is. In the case of the
FARM, users are operations personnel
and developers. However, the developer
is a user only to the extent necessary to
safeguard reuse.
The problem domain analysis concludes
with the specification of a development
framework. The framework consists of
the components identified in the problem
domain analysis that appear to be
candidates for reuse or COTS products in
the system.
TESTING METHODOLOGY
COTS and reusable components are
integrated into system development
following System Engineering and
Analysis Support (SEAS) System
Development Methodology (SSDM).
There are different levels of development
testing required for COTS and reusable
components depending on their level of
reusability. The basic idea is that the
supplied component is assumed to be
fully tested and working. The task of
development testing is to ensure it works
within the system, that the interfaces are
functioning as stated. System testing
remains the same: the system is still
tested to ensure requirements are met.
The level of testing, and when testing
begins, depends on the component's
position in the hierarchy of system
components. When an entire function is
reusable or COTS, the lowest level of
testing required is module testing to
ensure that the interface matches
expectations. If the supplied function is
more-or-less a client/server function, then
integration testing is required to ensure
that the client/server interface is correct.
Using the definition of a process as the
smallest stand-alone system entity;
testing should start at the level of testing
in the following table:
Table 1. Testing Requirements
Level of Testing Required
Reuse/COTS
One or more Integration testing
processes
Complete Integration testing or
function Module testing
One or more Module testing
units
Modified unit Unit testing
IMPLEMENTATION PLAN
The integration of management systems
will be done in a phased approach,
attacking the manually intensive legacy
systems first, then moving to the more
automated standards-based networks in
later phases. This will allow Nascom to
replace the expensive custom control
systems, reducing the software
maintenance costs.
1140
: :i i_
i_ii_i
!_i!ii/iii!¸
:HIll _ :_
!_i!:_ ,.....
r!_i__i:ii_¸_:
ili!i!?ilil_ii:,i
!_iili !_ :
:i__ _
• ::_i!i :-
H
The CSS and its associated control
systems in the TDRSS network will be
re-engineered to provide the framework
for the consolidated network operations
center. These systems are the most
manually intensive, least automated
systems. By consolidating these systems
and implementing expert systems
technology, operational costs will be
greatly reduced.
Future phases of the FARM will integrate
the remaining COTS management
systems through SNMP interfaces and
increasing operational automation.
A FARM lab is being developed which
will be used to evaluate and test different
hardware platforms and software
packages, perform network performance
analysis, and prototype new technologies
and configurations for use in the FARM.
By performing rapid prototyping and
evaluation on every aspect of the FARM
development, road blocks and design
flaws will be identified early in the project
life cycle.
CONCLUSION
The Nascom networks have evolved over
the last thirty years into what they are
today. Each system and network were
developed to meet a specific set of
requirements to support NASA's
communications needs. Today,
technology and standards have matured
to the point that it makes engineering
sense, as well as budgetary sense to start
over from the beginning and re-engineer
Nascom's network management
architecture.
?
1141


Re-engineering Nascom's network management architecture

Abstract

Similar works

Full text

Available Versions

NASA Technical Reports Server