rfc1679.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 564 行 · 第 1/2 页


RFC 1679                 HPN IPng Requirements               August 1994


   minimum 2**16 globally unique multicast groups must be
   distinguishable per platform.

4.2   Integrated Services Architecture

   An important goal of the HPN working group is to identify existing
   and emerging technologies which provide mechanisms for integrating
   the services required by mission critical Navy systems. The HPN
   working group has identified two classes of problems under the
   general category of integrated services. The first is to provide for
   the multiple types of services identified in section 2.1.  It is
   required to support these services in an integrated fashion in order
   to be able to correlate (in time) related streams of information.

   The second class of problems relates to the predictable management of
   the various traffic flows associated with the above identified
   services.  While many of these services require the delivery of a PDU
   within a specified time window, the applications in a mission
   critical environment can demand more stringent requirements. In areas
   where real-time systems are in use, such as machinery control,
   narrower and/or more predictable delivery windows may be required
   than in the case of the delivery of audio or video streams. The
   mission critical environment also requires the ability to assign
   end-to-end importance to instances of communications (i.e.,
   invocations of a particular service). For example, an ongoing video
   stream may need to yield to machinery control commands to ensure that
   the commands are received before their deadline.  The expense of this
   action is to degrade temporarily the video stream quality.

   The HPN working group is looking for mechanisms in the IPng protocols
   to provide for both of these classes of problems in an integrated
   fashion.  An integrated services architecture reduces design and
   integration complexities by providing a uniform set of tools for use
   by the mission critical system designer and application developer.
   Finally, the integrated services architecture must be flexible and
   scalable so that new services can be added in the future with minimum
   impact on systems using it.  The HPN working group has intentionally
   avoided mentioning particular mechanisms that can be used to solve
   some of these problems in order to avoid requiring a particular
   solution.

4.3   Mobility

   The HPN working group has identified two classes of mobility for the
   Navy mission critical environment. First, most platforms are
   themselves mobile. As these platforms move from port to port or from
   flight deck to flight deck, it is important that they are able to
   communicate with a number of defense installations via a general



Green, Irey, Marlow & O'Donoghue                                [Page 6]

RFC 1679                 HPN IPng Requirements               August 1994


   infrastructure.  Additionally, it is feasible that systems within a
   single platform may be mobile. Maintenance and damage assessment
   requires large amounts of information at numerous locations on a
   platform. This information could possibly be made available through
   mobile terminals.

4.4   Multicast

   Multicast transfer is a very critical IPng requirement for the Navy's
   mission critical systems. Aboard a Naval platform there are many
   hosts (e.g., workstations) connected via numerous subnetworks. These
   hosts are all working different aspects of the problem of keeping the
   platform operational to perform its mission. In support of this
   environment, multicast transfer is needed to share data that is
   needed by multiple hosts. For example, aboard a ship platform,
   environmental data (roll, pitch, heading...) is needed by almost all
   systems. Video conferencing may be used for communication among
   operational personnel at multiple places aboard this ship. Video
   conferencing could also be used for communicating with personnel on
   other platforms or at shore facilities.  Both of these examples, in
   addition to a number of DoD and NATO studies, have highlighted the
   need for multicast functionality in mission critical systems.

   One of the limiting factors with the present IP version 4 multicast
   is the optional nature of this multicast, particularly with respect
   to routers. The use of tunnels, while enabling the initial deployment
   of multicast in the Internet, appears to limit its potential. The HPN
   working group believes that the best approach to provision of
   multicast functionality is to consider it as a basic functionality to
   be provided by IPng. In addition, sensible mechanisms are needed to
   control multicast traffic (i.e., scope control). Finally, support is
   required to enable multicast functionality in IPng in areas such as
   group addressing and scalable multicast routing.

4.5   Rapid Route Reconfiguration

   The HPN project will be using very high bandwidth subnetwork
   technology.  In the mission critical environment one very important
   problem is placing a very low bound on the time it takes to identify
   a subnetwork problem and to complete the necessary route
   reconfigurations. The Navy's mission critical environment needs to be
   able to trade-off bandwidth to enable a short
   detection/reconfiguration time on subnetwork faults. A maximum bound
   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 considerations

   This section represents additional concerns of the mission critical
   environment which may impact IPng. The HPN working group felt that
   these issues are important for the mission critical environment;
   however, it was not clear how or whether it is necessary to
   accommodate them in IPng solutions. It may suffice that designers of
   IPng are aware of these issues and therefore do not preclude
   reasonable solutions to these problems.

5.1   Fault Tolerance

   The mission critical environment is particularly sensitive to the
   area of fault tolerance. Any mechanisms that can be accommodated
   within the IPng protocol set, including routing and management, to
   support various levels of fault tolerance are desirable. In
   particular, the following features should be supported: error
   detection, error reporting, traffic analysis, and status reporting.

5.2   Policy Based Routing

   The HPN working group feels that there may be some uses for policy
   based routing within the Navy's mission critical systems.  The
   primary interest is in support of a very capable security facility.
   Other uses discussed are as a means for keeping certain types of data
   on certain subnetworks (for multiply homed hosts) and providing for
   automatic reconfiguration in the event of particular subnetwork
   failures.

5.3   Security

   Security is an important requirement for most Navy applications and
   thus the ability for the network functions to be designed to support
   security services are essential. The following are several security
   services in particular that the HPN working group believes the
   network function should be able to support:  rule based access
   control, labeling, authentication, audit, connection oriented and
   connectionless confidentiality, selective routing, traffic flow
   confidentiality, connection oriented and connectionless integrity,
   denial of service protection, continuity of operations, and
   precedence/preemption.  In addition to these services, the network
   function should also support the security management of these
   security services. In particular, key management is of importance.

   Currently, the IPSEC of the IETF has several draft memos being
   considered to incorporate various security services in the network
   functions. It is of concern to the HPN working group that the IPng be
   able to support the concepts currently being developed by the IPSEC



Green, Irey, Marlow & O'Donoghue                                [Page 8]

RFC 1679                 HPN IPng Requirements               August 1994


   and also provide the ability for the addition of future security
   services.

5.4   Time Synchronization

   Time synchronization among the various components of mission critical
   systems is of vital importance to the Navy. It is desirable to be
   able to synchronize systems on multiple subnetworks via a network
   layer infrastructure. Some hooks for time synchronization can be
   envisioned in the network layer.  However, the HPN working group
   feels that, as a minimum, efficient time synchronization algorithms
   must be able to function above an IPng infrastructure. For HPN
   systems, it is desirable that a time-of-day synchronization
   capability be supported of at least an accuracy of one microsecond
   among all hosts in a platform or campus network. The IPng protocols
   should not arbitrarily prevent this type of synchronization
   capability.

6.   Conclusions

   A number of concerns specific to mission critical systems targeted by
   the HPN working group have been identified. The HPN working group is
   interested in participating with the IETF in the development of
   standards which would apply to mission critical systems. In
   particular, the HPN working group is interested in the development of
   multicast functionality, an integrated services architecture, and
   support for high performance subnetworks.

7.   References

   [1] HPN Planning Group, "Concepts and Guidance for High Performance
       Network (HPN)", Work in Progress, May 17, 1993.

8.  Security Considerations

   Security issues are discussed in Section 5.3.















Green, Irey, Marlow & O'Donoghue                                [Page 9]

RFC 1679                 HPN IPng Requirements               August 1994


9.   Authors' Addresses

   Dan Green
   NSWC-DD
   Code B35 NSWCDD
   Dahlgren, VA 22448

   Phone: [phone]
   EMail: [e-mail]


   Phil Irey
   NSWC-DD
   Code B35 NSWCDD
   Dahlgren, VA 22448

   Phone: [phone]
   EMail: [e-mail]


   Dave Marlow
   NSWC-DD
   Code B35 NSWCDD
   Dahlgren, VA 22448

   Phone: [phone]
   EMail: [e-mail]


   Karen O'Donoghue
   NSWC-DD
   Code B35 NSWCDD
   Dahlgren, VA 22448

   Phone: [phone]
   EMail: [e-mail]















Green, Irey, Marlow & O'Donoghue                               [Page 10]