📄 rfc1679.txt
字号:
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 generalGreen, 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 19945. 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 IPSECGreen, 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 19949. Authors' Addresses Dan Green NSWC-DD Code B35 NSWCDD Dahlgren, VA 22448 Phone: (703) 663-1571 EMail: dtgreen@relay.nswc.navy.mil Phil Irey NSWC-DD Code B35 NSWCDD Dahlgren, VA 22448 Phone: (703) 663-1571 EMail: pirey@relay.nswc.navy.mil Dave Marlow NSWC-DD Code B35 NSWCDD Dahlgren, VA 22448 Phone: (703) 663-1571 EMail: dmarlow@relay.nswc.navy.mil Karen O'Donoghue NSWC-DD Code B35 NSWCDD Dahlgren, VA 22448 Phone: (703) 663-1571 EMail: kodonog@relay.nswc.navy.milGreen, Irey, Marlow & O'Donoghue [Page 10]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -