As per Relevance of the word critical, we have this rfc below:
Network Working Group D.
Request for Comments: 1679 P.
Category: Informational D.
K. O'
NSWC-
August 1994
HPN Working Group Input to the IPng Requirements
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 Navy's High Performance Network (HPN) working group has
the requirements of mission critical applications on Navy platforms
Based on this study, three basic categories of issues for IPng
been identified. The assumptions identified include accommodation
current functionality, commercial viability, and transitioning.
general requirements identified include addressing,
services architecture, mobility, multicast, and rapid
reconfiguration. Finally, the additional considerations
include fault tolerance, policy based routing, security, and
synchroniztion. The HPN working group is interested in
with the IETF in the development of standards which would apply
mission critical systems. In particular, the HPN working group
interested in the development of multicast functionality,
integrated services architecture, and support for high
subnetworks
1.
The HPN working group has been established to study future
architectures for mission critical applications aboard
platforms. As a result, the HPN working group is interested in
results of the IPng selection and development process. This
is a product of discussions within the HPN working group
Green, Irey, Marlow & O'Donoghue [Page 1]
RFC 1679 HPN IPng Requirements August 1994
The purpose of this document is to provide what the HPN working
perceives as requirements for an IPng protocol set. Many of
necessary capabilities exist in current Internet and ISO
protocols; however, the HPN working group has identified
capabilities that are beyond the existing standards
The HPN working group has identified three categories of topics
discussion in this document. The first category is assumptions
those topics that the HPN working group believes the IPng
will solve satisfactorily without specific Navy input. The
category is general requirements. These are capabilities that
felt to be insufficiently addressed in existing network protocols
of key importance to Navy mission critical applications. Finally,
set of additional considerations has been identified. These are
issues of importance to the HPN working group. However, no
or specific requests can be provided at this time
2.
The US Navy has set up a program through the Space and Naval
Systems Command called the Next Generation Computer Resources (NGCR
Program. The purpose of this program is to identify the
needs for information system technology in Navy mission
systems. The NGCR High Performance Network (HPN) working group
recently established by the NGCR program to examine high
networks for use on future Navy platforms (aircraft, surface ships
submarines, and certain shore-based applications). This working
is currently reviewing Navy needs. The requirements provided
are based on the HPN working group's current understanding of
Navy application areas. The application areas of interest are
examined below. The time frame for design, development,
deployment of HPN based systems and subsystems is 1996 into
twenty first century
Three general problem domains have been identified by the HPN
group. These are the particular problem domains within a
critical environment that the HPN working group is targeting.
first is a distributed combat system environment. This
domain is analogous to a collection of workstations involved in
varied applications involving multiple sources and types
information. Analog, audio, digital, discrete, graphic, textual
video, and voice information must be coordinated in order to
a single concise view to a commander, operator, or any end user.
second problem area highlights the general
environment. The task of moving information to many
systems over various subnetworks is addressed. Finally, the
of providing a high speed interconnect for devices such as
and signal processors is identified. [1]
Green, Irey, Marlow & O'Donoghue [Page 2]
RFC 1679 HPN IPng Requirements August 1994
2.1 Application
The application area of HPN is the communication network which is
component of the mission critical systems of Navy platforms.
expected end points or users of the HPN include humans, computers
and the many devices (cameras, etc.) found on such platforms.
function of these end points includes sensor input,
processors, operator consoles, navigation systems, etc. The
are typically grouped into systems both on platforms and at shore
based sites. These systems perform functions including long
planning, analysis of sensor information, and machinery control
real-time
Information types that have been identified as required by the
working group include voice, live and pre-recorded audio ranging
voice to CD quality (e.g., from sensors), video (1 to 30 frames
second in both monochrome and color), image data (static or
real-time sensors), reliable and connectionless data transfer,
very high-bandwidth (gigabits per second) unprocessed sensor data
2.2
Another way of categorizing the HPN application area is
considering the user services that need to be supported. Some
these services are the following
1. process to process message
2. distributed file and database
3. e-mail (both within the platform and off the platform
4. teleconferencing (with the platform, between platforms,
across the Internet
5. video monitoring of various physical
6. voice distribution (as a minimum between computer
and people
7. image
8. time
9. name or directory
10. network and system
Green, Irey, Marlow & O'Donoghue [Page 3]
RFC 1679 HPN IPng Requirements August 1994
11. security services (support of multilevel data security
privacy and protection
3.
The assumptions documented below are concerns that the HPN
group presumes will be accommodated in the IPng process. However
they are of enough importance to this working group to
identification
3.1 Accommodation of Current
The IPng protocols need to provide for at least the
functionality. In particular, the following issues have
identified
1) The IPng protocols need to provide for the
connectionless transfer of information from one end-point
another
2) The IPng protocols need to support multiple
technologies. This includes but is not limited to Ethernet
FDDI, Asynchronous Transfer Mode (ATM), Fiber Channel,
Scalable Coherent Interface (SCI). These are the
technologies that are of particular interest to the
working group. Ideally, IPng protocols should be
independent
3) The IPng protocols need to support hosts that may
multihomed. Multihomed in this context implies that a
host may support multiple different subnetwork technologies
Multihomed hosts must have the capability to steer the
to selected subnetworks
4) The IPng process needs to recognize that IPng may be only
of several network protocols that a host utilizes
5) The IPng process needs to provide for appropriate
management in the finished product. Network management is
vital importance to the applications of interest to the
working group
3.2 Commercial
As is the case in the commercial world, the HPN working group
strongly that the IPng protocols must be commercially viable.
includes but is not limited to the following issues
Green, Irey, Marlow & O'Donoghue [Page 4]
RFC 1679 HPN IPng Requirements August 1994
1) The IPng protocols must function correctly. The Navy
afford to have network protocol problems in mission
systems. There must be a high degree of confidence that
protocols are technically sound and multi-
interoperability is achievable
2) The IPng protocols must have the support of
commercial/industrial community. This may first
demonstrated by a strong consensus within the IETF community
3.3 Transition
The Navy has a large number of existing networks including
Internet and ISO protocols as well as a number of
systems. As a minimum, the IPng effort must address how
transition from existing IP based networks. Additionally, it would
desirable to have some guidance for transitioning from other
protocols including, but not limited to, CLNP and other commonly
network protocols. The transition plan for IPng needs to
the large existing infrastructure and the lack of funds for a
scale immediate transition. There will, in all likelihood, be a
period of co-existence that should be addressed
4. General
The general requirements documented below are topics that the
working group considers to be of vital importance in a
protocol solution. It is hoped that the IPng solution will
all of these issues
4.1
The HPN working group has identified initial addressing requirements
First, a large number of addresses are required. In particular,
number of addressable entities on a single platform will range
the 100's to 100,000. The number of large platforms (ships
submarines, shore based sites) will range from a few hundred
several thousand. In addition, there will be 500 to 1000 or
small platforms, primarily aircraft. Since it is expected that
the future many of these platforms will be connected to
networks, the addresses must be globally unique
The second requirement identified is for some form of
structure. It is felt that this structure should be flexible
to allow for logical structures (not necessarily geographical) to
applied. It is also felt that this is important for
implementation of efficient routing solutions. In addition,
addressing structure must support multicast group addressing. At
Green, Irey, Marlow & O'Donoghue [Page 5]
RFC 1679 HPN IPng Requirements August 1994
minimum 2**16 globally unique multicast groups must
distinguishable per platform
4.2 Integrated Services
An important goal of the HPN working group is to identify
and emerging technologies which provide mechanisms for
the services required by mission critical Navy systems. The
working group has identified two classes of problems under
general category of integrated services. The first is to provide
the multiple types of services identified in section 2.1. It
required to support these services in an integrated fashion in
to be able to correlate (in time) related streams of information
The second class of problems relates to the predictable management
the various traffic flows associated with the above
services. While many of these services require the delivery of a
within a specified time window, the applications in a
critical environment can demand more stringent requirements. In
where real-time systems are in use, such as machinery control
narrower and/or more predictable delivery windows may be
than in the case of the delivery of audio or video streams.
mission critical environment also requires the ability to
end-to-end importance to instances of communications (i.e.,
invocations of a particular service). For example, an ongoing
stream may need to yield to machinery control commands to ensure
the commands are received before their deadline. The expense of
action is to degrade temporarily the video stream quality
The HPN working group is looking for mechanisms in the IPng
to provide for both of these classes of problems in an
fashion. An integrated services architecture reduces design
integration complexities by providing a uniform set of tools for
by the mission critical system designer and application developer
Finally, the integrated services architecture must be flexible
scalable so that new services can be added in the future with
impact on systems using it. The HPN working group has
avoided mentioning particular mechanisms that can be used to
some of these problems in order to avoid requiring a
solution
4.3
The HPN working group has identified two classes of mobility for
Navy mission critical environment. First, most platforms
themselves mobile. As these platforms move from port to port or
flight deck to flight deck, it is important that they are able
communicate with a number of defense installations via a
Green, Irey, Marlow & O'Donoghue [Page 6]
RFC 1679 HPN IPng Requirements August 1994
infrastructure. Additionally, it is feasible that systems within
single platform may be mobile. Maintenance and damage
requires large amounts of information at numerous locations on
platform. This information could possibly be made available
mobile terminals
4.4
Multicast transfer is a very critical IPng requirement for the Navy'
mission critical systems. Aboard a Naval platform there are
hosts (e.g., workstations) connected via numerous subnetworks.
hosts are all working different aspects of the problem of keeping
platform operational to perform its mission. In support of
environment, multicast transfer is needed to share data that
needed by multiple hosts. For example, aboard a ship platform
environmental data (roll, pitch, heading...) is needed by almost
systems. Video conferencing may be used for communication
operational personnel at multiple places aboard this ship.
conferencing could also be used for communicating with personnel
other platforms or at shore facilities. Both of these examples,
addition to a number of DoD and NATO studies, have highlighted
need for multicast functionality in mission critical systems
One of the limiting factors with the present IP version 4
is the optional nature of this multicast, particularly with
to routers. The use of tunnels, while enabling the initial
of multicast in the Internet, appears to limit its potential. The
working group believes that the best approach to provision
multicast functionality is to consider it as a basic functionality
be provided by IPng. In addition, sensible mechanisms are needed
control multicast traffic (i.e., scope control). Finally, support
required to enable multicast functionality in IPng in areas such
group addressing and scalable multicast routing
4.5 Rapid Route
The HPN project will be using very high bandwidth
technology. In the mission critical environment one very
problem is placing a very low bound on the time it takes to
a subnetwork problem and to complete the necessary
reconfigurations. The Navy's mission critical environment needs to
able to trade-off bandwidth to enable a
detection/reconfiguration time on subnetwork faults. A maximum
on this time is felt to be less than 1 second
Green, Irey, Marlow & O'Donoghue [Page 7]
RFC 1679 HPN IPng Requirements August 1994
5. Additional
This section represents additional concerns of the mission
environment which may impact IPng. The HPN working group felt
these issues are important for the mission critical environment
however, it was not clear how or whether it is necessary
accommodate them in IPng solutions. It may suffice that designers
IPng are aware of these issues and therefore do not
reasonable solutions to these problems
5.1 Fault
The mission critical environment is particularly sensitive to
area of fault tolerance. Any mechanisms that can be
within the IPng protocol set, including routing and management,
support various levels of fault tolerance are desirable.
particular, the following features should be supported:
detection, error reporting, traffic analysis, and status reporting
5.2 Policy Based
The HPN working group feels that there may be some uses for
based routing within the Navy's mission critical systems.
primary interest is in support of a very capable security facility
Other uses discussed are as a means for keeping certain types of
on certain subnetworks (for multiply homed hosts) and providing
automatic reconfiguration in the event of particular
failures
5.3
Security is an important requirement for most Navy applications
thus the ability for the network functions to be designed to
security services are essential. The following are several
services in particular that the HPN working group believes
network function should be able to support: rule based
control, labeling, authentication, audit, connection oriented
connectionless confidentiality, selective routing, traffic
confidentiality, connection oriented and connectionless integrity
denial of service protection, continuity of operations,
precedence/preemption. In addition to these services, the
function should also support the security management of
security services. In particular, key management is of importance
Currently, the IPSEC of the IETF has several draft memos
considered to incorporate various security services in the
functions. It is of concern to the HPN working group that the IPng
able to support the concepts currently being developed by the
Green, Irey, Marlow & O'Donoghue [Page 8]
RFC 1679 HPN IPng Requirements August 1994
and also provide the ability for the addition of future
services
5.4 Time
Time synchronization among the various components of mission
systems is of vital importance to the Navy. It is desirable to
able to synchronize systems on multiple subnetworks via a
layer infrastructure. Some hooks for time synchronization can
envisioned in the network layer. However, the HPN working
feels that, as a minimum, efficient time synchronization
must be able to function above an IPng infrastructure. For
systems, it is desirable that a time-of-day
capability be supported of at least an accuracy of one
among all hosts in a platform or campus network. The IPng
should not arbitrarily prevent this type of
capability
6.
A number of concerns specific to mission critical systems targeted
the HPN working group have been identified. The HPN working group
interested in participating with the IETF in the development
standards which would apply to mission critical systems.
particular, the HPN working group is interested in the development
multicast functionality, an integrated services architecture,
support for high performance subnetworks
7.
[1] HPN Planning Group, "Concepts and Guidance for High
Network (HPN)", Work in Progress, May 17, 1993.
8. Security
Security issues are discussed in Section 5.3.
Green, Irey, Marlow & O'Donoghue [Page 9]
RFC 1679 HPN IPng Requirements August 1994
9. Authors'
Dan
NSWC-
Code B35
Dahlgren, VA 22448
Phone: (703) 663-1571
EMail: dtgreen@relay.nswc.navy.
Phil
NSWC-
Code B35
Dahlgren, VA 22448
Phone: (703) 663-1571
EMail: pirey@relay.nswc.navy.
Dave
NSWC-
Code B35
Dahlgren, VA 22448
Phone: (703) 663-1571
EMail: dmarlow@relay.nswc.navy.
Karen O'
NSWC-
Code B35
Dahlgren, VA 22448
Phone: (703) 663-1571
EMail: kodonog@relay.nswc.navy.
Green, Irey, Marlow & O'Donoghue [Page 10]
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
