home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1679 < prev    next >
Text File  |  1994-08-05  |  23KB  |  564 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           D. Green
  8. Request for Comments: 1679                                       P. Irey
  9. Category: Informational                                        D. Marlow
  10.                                                            K. O'Donoghue
  11.                                                                  NSWC-DD
  12.                                                              August 1994
  13.  
  14.  
  15.      HPN Working Group Input to the IPng Requirements Solicitation
  16.  
  17. Status of this Memo
  18.  
  19.    This memo provides information for the Internet community.  This memo
  20.    does not specify an Internet standard of any kind.  Distribution of
  21.    this memo is unlimited.
  22.  
  23. Abstract
  24.  
  25.    This document was submitted to the IETF IPng area in response to RFC
  26.    1550.  Publication of this document does not imply acceptance by the
  27.    IPng area of any ideas expressed within.  Comments should be
  28.    submitted to the big-internet@munnari.oz.au mailing list.
  29.  
  30. Executive Summary
  31.  
  32.    The Navy's High Performance Network (HPN) working group has studied
  33.    the requirements of mission critical applications on Navy platforms.
  34.    Based on this study, three basic categories of issues for IPng have
  35.    been identified.  The assumptions identified include accommodation of
  36.    current functionality, commercial viability, and transitioning. The
  37.    general requirements identified include addressing, integrated
  38.    services architecture, mobility, multicast, and rapid route
  39.    reconfiguration. Finally, the additional considerations identified
  40.    include fault tolerance, policy based routing, security, and time
  41.    synchroniztion. The HPN working group is interested in participating
  42.    with the IETF in the development of standards which would apply to
  43.    mission critical systems. In particular, the HPN working group is
  44.    interested in the development of multicast functionality, an
  45.    integrated services architecture, and support for high performance
  46.    subnetworks.
  47.  
  48. 1.   Introduction
  49.  
  50.    The HPN working group has been established to study future network
  51.    architectures for mission critical applications aboard Navy
  52.    platforms.  As a result, the HPN working group is interested in the
  53.    results of the IPng selection and development process. This document
  54.    is a product of discussions within the HPN working group.
  55.  
  56.  
  57.  
  58. Green, Irey, Marlow & O'Donoghue                                [Page 1]
  59.  
  60. RFC 1679                 HPN IPng Requirements               August 1994
  61.  
  62.  
  63.    The purpose of this document is to provide what the HPN working group
  64.    perceives as requirements for an IPng protocol set. Many of the
  65.    necessary capabilities exist in current Internet and ISO network
  66.    protocols; however, the HPN working group has identified needed
  67.    capabilities that are beyond the existing standards.
  68.  
  69.    The HPN working group has identified three categories of topics for
  70.    discussion in this document. The first category is assumptions or
  71.    those topics that the HPN working group believes the IPng process
  72.    will solve satisfactorily without specific Navy input. The second
  73.    category is general requirements. These are capabilities that are
  74.    felt to be insufficiently addressed in existing network protocols and
  75.    of key importance to Navy mission critical applications. Finally, a
  76.    set of additional considerations has been identified. These are also
  77.    issues of importance to the HPN working group. However, no guidance
  78.    or specific requests can be provided at this time.
  79.  
  80. 2.   Background
  81.  
  82.    The US Navy has set up a program through the Space and Naval Warfare
  83.    Systems Command called the Next Generation Computer Resources (NGCR)
  84.    Program. The purpose of this program is to identify the evolving
  85.    needs for information system technology in Navy mission critical
  86.    systems. The NGCR High Performance Network (HPN) working group was
  87.    recently established by the NGCR program to examine high performance
  88.    networks for use on future Navy platforms (aircraft, surface ships,
  89.    submarines, and certain shore-based applications). This working group
  90.    is currently reviewing Navy needs. The requirements provided below
  91.    are based on the HPN working group's current understanding of these
  92.    Navy application areas. The application areas of interest are further
  93.    examined below. The time frame for design, development, and
  94.    deployment of HPN based systems and subsystems is 1996 into the
  95.    twenty first century.
  96.  
  97.    Three general problem domains have been identified by the HPN working
  98.    group. These are the particular problem domains within a mission
  99.    critical environment that the HPN working group is targeting. The
  100.    first is a distributed combat system environment.  This problem
  101.    domain is analogous to a collection of workstations involved in many
  102.    varied applications involving multiple sources and types of
  103.    information.  Analog, audio, digital, discrete, graphic, textual,
  104.    video, and voice information must be coordinated in order to present
  105.    a single concise view to a commander, operator, or any end user. The
  106.    second problem area highlights the general internetworking
  107.    environment. The task of moving information to many heterogeneous
  108.    systems over various subnetworks is addressed. Finally, the problem
  109.    of providing a high speed interconnect for devices such as sensors
  110.    and signal processors is identified. [1]
  111.  
  112.  
  113.  
  114. Green, Irey, Marlow & O'Donoghue                                [Page 2]
  115.  
  116. RFC 1679                 HPN IPng Requirements               August 1994
  117.  
  118.  
  119. 2.1   Application Area
  120.  
  121.    The application area of HPN is the communication network which is a
  122.    component of the mission critical systems of Navy platforms. The
  123.    expected end points or users of the HPN include humans, computers,
  124.    and the many devices (cameras, etc.) found on such platforms. The
  125.    function of these end points includes sensor input, signal
  126.    processors, operator consoles, navigation systems, etc. The endpoints
  127.    are typically grouped into systems both on platforms and at shore-
  128.    based sites. These systems perform functions including long range
  129.    planning, analysis of sensor information, and machinery control in
  130.    real-time.
  131.  
  132.    Information types that have been identified as required by the HPN
  133.    working group include voice, live and pre-recorded audio ranging from
  134.    voice to CD quality (e.g., from sensors), video (1 to 30 frames per
  135.    second in both monochrome and color), image data (static or from
  136.    real-time sensors), reliable and connectionless data transfer, and
  137.    very high-bandwidth (gigabits per second) unprocessed sensor data.
  138.  
  139. 2.2   Services
  140.  
  141.    Another way of categorizing the HPN application area is by
  142.    considering the user services that need to be supported. Some of
  143.    these services are the following:
  144.  
  145.      1.   process to process message passing
  146.  
  147.      2.   distributed file and database manipulation
  148.  
  149.      3.   e-mail (both within the platform and off the platform)
  150.  
  151.      4.   teleconferencing (with the platform, between platforms, and
  152.           across the Internet)
  153.  
  154.      5.   video monitoring of various physical environments
  155.  
  156.      6.   voice distribution (as a minimum between computer processes
  157.           and people)
  158.  
  159.      7.   image services
  160.  
  161.      8.   time synchronization
  162.  
  163.      9.   name or directory services
  164.  
  165.      10.  network and system management
  166.  
  167.  
  168.  
  169.  
  170. Green, Irey, Marlow & O'Donoghue                                [Page 3]
  171.  
  172. RFC 1679                 HPN IPng Requirements               August 1994
  173.  
  174.  
  175.      11.  security services (support of multilevel data security,
  176.           privacy and protection)
  177.  
  178. 3.   Assumptions
  179.  
  180.    The assumptions documented below are concerns that the HPN working
  181.    group presumes will be accommodated in the IPng process.  However,
  182.    they are of enough importance to this working group to merit
  183.    identification.
  184.  
  185. 3.1   Accommodation of Current Functionality
  186.  
  187.    The IPng protocols need to provide for at least the existing
  188.    functionality. In particular, the following issues have been
  189.    identified.
  190.  
  191.  
  192.      1)   The IPng protocols need to provide for the basic
  193.           connectionless transfer of information from one end-point to
  194.           another.
  195.  
  196.      2)   The IPng protocols need to support multiple subnetwork
  197.           technologies. This includes but is not limited to Ethernet,
  198.           FDDI, Asynchronous Transfer Mode (ATM), Fiber Channel, and
  199.           Scalable Coherent Interface (SCI). These are the subnetwork
  200.           technologies that are of particular interest to the HPN
  201.           working group. Ideally, IPng protocols should be subnetwork
  202.           independent.
  203.  
  204.      3)   The IPng protocols need to support hosts that may be
  205.           multihomed. Multihomed in this context implies that a single
  206.           host may support multiple different subnetwork technologies.
  207.           Multihomed hosts must have the capability to steer the traffic
  208.           to selected subnetworks.
  209.  
  210.      4)   The IPng process needs to recognize that IPng may be only one
  211.           of several network protocols that a host utilizes.
  212.  
  213.      5)   The IPng process needs to provide for appropriate network
  214.           management in the finished product. Network management is of
  215.           vital importance to the applications of interest to the HPN
  216.           working group.
  217.  
  218. 3.2   Commercial Viability
  219.  
  220.    As is the case in the commercial world, the HPN working group feels
  221.    strongly that the IPng protocols must be commercially viable. This
  222.    includes but is not limited to the following issues:
  223.  
  224.  
  225.  
  226. Green, Irey, Marlow & O'Donoghue                                [Page 4]
  227.  
  228. RFC 1679                 HPN IPng Requirements               August 1994
  229.  
  230.  
  231.      1)   The IPng protocols must function correctly. The Navy cannot
  232.           afford to have network protocol problems in mission critical
  233.           systems. There must be a high degree of confidence that the
  234.           protocols are technically sound and multi-vendor
  235.           interoperability is achievable.
  236.  
  237.      2)   The IPng protocols must have the support of the
  238.           commercial/industrial community. This may first be
  239.           demonstrated by a strong consensus within the IETF community.
  240.  
  241. 3.3   Transition Plan
  242.  
  243.    The Navy has a large number of existing networks including both
  244.    Internet and ISO protocols as well as a number of proprietary
  245.    systems.  As a minimum, the IPng effort must address how to
  246.    transition from existing IP based networks. Additionally, it would be
  247.    desirable to have some guidance for transitioning from other network
  248.    protocols including, but not limited to, CLNP and other commonly used
  249.    network protocols. The transition plan for IPng needs to recognize
  250.    the large existing infrastructure and the lack of funds for a full
  251.    scale immediate transition. There will, in all likelihood, be a long
  252.    period of co-existence that should be addressed.
  253.  
  254. 4.   General Requirements
  255.  
  256.    The general requirements documented below are topics that the HPN
  257.    working group considers to be of vital importance in a network
  258.    protocol solution. It is hoped that the IPng solution will address
  259.    all of these issues.
  260.  
  261. 4.1   Addressing
  262.  
  263.    The HPN working group has identified initial addressing requirements.
  264.    First, a large number of addresses are required.  In particular, the
  265.    number of addressable entities on a single platform will range from
  266.    the 100's to 100,000. The number of large platforms (ships,
  267.    submarines, shore based sites) will range from a few hundred to
  268.    several thousand. In addition, there will be 500 to 1000 or more
  269.    small platforms, primarily aircraft.  Since it is expected that in
  270.    the future many of these platforms will be connected to global
  271.    networks, the addresses must be globally unique.
  272.  
  273.    The second requirement identified is for some form of addressing
  274.    structure. It is felt that this structure should be flexible enough
  275.    to allow for logical structures (not necessarily geographical) to be
  276.    applied. It is also felt that this is important for the
  277.    implementation of efficient routing solutions.  In addition, the
  278.    addressing structure must support multicast group addressing. At a
  279.  
  280.  
  281.  
  282. Green, Irey, Marlow & O'Donoghue                                [Page 5]
  283.  
  284. RFC 1679                 HPN IPng Requirements               August 1994
  285.  
  286.  
  287.    minimum 2**16 globally unique multicast groups must be
  288.    distinguishable per platform.
  289.  
  290. 4.2   Integrated Services Architecture
  291.  
  292.    An important goal of the HPN working group is to identify existing
  293.    and emerging technologies which provide mechanisms for integrating
  294.    the services required by mission critical Navy systems. The HPN
  295.    working group has identified two classes of problems under the
  296.    general category of integrated services. The first is to provide for
  297.    the multiple types of services identified in section 2.1.  It is
  298.    required to support these services in an integrated fashion in order
  299.    to be able to correlate (in time) related streams of information.
  300.  
  301.    The second class of problems relates to the predictable management of
  302.    the various traffic flows associated with the above identified
  303.    services.  While many of these services require the delivery of a PDU
  304.    within a specified time window, the applications in a mission
  305.    critical environment can demand more stringent requirements. In areas
  306.    where real-time systems are in use, such as machinery control,
  307.    narrower and/or more predictable delivery windows may be required
  308.    than in the case of the delivery of audio or video streams. The
  309.    mission critical environment also requires the ability to assign
  310.    end-to-end importance to instances of communications (i.e.,
  311.    invocations of a particular service). For example, an ongoing video
  312.    stream may need to yield to machinery control commands to ensure that
  313.    the commands are received before their deadline.  The expense of this
  314.    action is to degrade temporarily the video stream quality.
  315.  
  316.    The HPN working group is looking for mechanisms in the IPng protocols
  317.    to provide for both of these classes of problems in an integrated
  318.    fashion.  An integrated services architecture reduces design and
  319.    integration complexities by providing a uniform set of tools for use
  320.    by the mission critical system designer and application developer.
  321.    Finally, the integrated services architecture must be flexible and
  322.    scalable so that new services can be added in the future with minimum
  323.    impact on systems using it.  The HPN working group has intentionally
  324.    avoided mentioning particular mechanisms that can be used to solve
  325.    some of these problems in order to avoid requiring a particular
  326.    solution.
  327.  
  328. 4.3   Mobility
  329.  
  330.    The HPN working group has identified two classes of mobility for the
  331.    Navy mission critical environment. First, most platforms are
  332.    themselves mobile. As these platforms move from port to port or from
  333.    flight deck to flight deck, it is important that they are able to
  334.    communicate with a number of defense installations via a general
  335.  
  336.  
  337.  
  338. Green, Irey, Marlow & O'Donoghue                                [Page 6]
  339.  
  340. RFC 1679                 HPN IPng Requirements               August 1994
  341.  
  342.  
  343.    infrastructure.  Additionally, it is feasible that systems within a
  344.    single platform may be mobile. Maintenance and damage assessment
  345.    requires large amounts of information at numerous locations on a
  346.    platform. This information could possibly be made available through
  347.    mobile terminals.
  348.  
  349. 4.4   Multicast
  350.  
  351.    Multicast transfer is a very critical IPng requirement for the Navy's
  352.    mission critical systems. Aboard a Naval platform there are many
  353.    hosts (e.g., workstations) connected via numerous subnetworks. These
  354.    hosts are all working different aspects of the problem of keeping the
  355.    platform operational to perform its mission. In support of this
  356.    environment, multicast transfer is needed to share data that is
  357.    needed by multiple hosts. For example, aboard a ship platform,
  358.    environmental data (roll, pitch, heading...) is needed by almost all
  359.    systems. Video conferencing may be used for communication among
  360.    operational personnel at multiple places aboard this ship. Video
  361.    conferencing could also be used for communicating with personnel on
  362.    other platforms or at shore facilities.  Both of these examples, in
  363.    addition to a number of DoD and NATO studies, have highlighted the
  364.    need for multicast functionality in mission critical systems.
  365.  
  366.    One of the limiting factors with the present IP version 4 multicast
  367.    is the optional nature of this multicast, particularly with respect
  368.    to routers. The use of tunnels, while enabling the initial deployment
  369.    of multicast in the Internet, appears to limit its potential. The HPN
  370.    working group believes that the best approach to provision of
  371.    multicast functionality is to consider it as a basic functionality to
  372.    be provided by IPng. In addition, sensible mechanisms are needed to
  373.    control multicast traffic (i.e., scope control). Finally, support is
  374.    required to enable multicast functionality in IPng in areas such as
  375.    group addressing and scalable multicast routing.
  376.  
  377. 4.5   Rapid Route Reconfiguration
  378.  
  379.    The HPN project will be using very high bandwidth subnetwork
  380.    technology.  In the mission critical environment one very important
  381.    problem is placing a very low bound on the time it takes to identify
  382.    a subnetwork problem and to complete the necessary route
  383.    reconfigurations. The Navy's mission critical environment needs to be
  384.    able to trade-off bandwidth to enable a short
  385.    detection/reconfiguration time on subnetwork faults. A maximum bound
  386.    on this time is felt to be less than 1 second.
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Green, Irey, Marlow & O'Donoghue                                [Page 7]
  395.  
  396. RFC 1679                 HPN IPng Requirements               August 1994
  397.  
  398.  
  399. 5.   Additional considerations
  400.  
  401.    This section represents additional concerns of the mission critical
  402.    environment which may impact IPng. The HPN working group felt that
  403.    these issues are important for the mission critical environment;
  404.    however, it was not clear how or whether it is necessary to
  405.    accommodate them in IPng solutions. It may suffice that designers of
  406.    IPng are aware of these issues and therefore do not preclude
  407.    reasonable solutions to these problems.
  408.  
  409. 5.1   Fault Tolerance
  410.  
  411.    The mission critical environment is particularly sensitive to the
  412.    area of fault tolerance. Any mechanisms that can be accommodated
  413.    within the IPng protocol set, including routing and management, to
  414.    support various levels of fault tolerance are desirable. In
  415.    particular, the following features should be supported: error
  416.    detection, error reporting, traffic analysis, and status reporting.
  417.  
  418. 5.2   Policy Based Routing
  419.  
  420.    The HPN working group feels that there may be some uses for policy
  421.    based routing within the Navy's mission critical systems.  The
  422.    primary interest is in support of a very capable security facility.
  423.    Other uses discussed are as a means for keeping certain types of data
  424.    on certain subnetworks (for multiply homed hosts) and providing for
  425.    automatic reconfiguration in the event of particular subnetwork
  426.    failures.
  427.  
  428. 5.3   Security
  429.  
  430.    Security is an important requirement for most Navy applications and
  431.    thus the ability for the network functions to be designed to support
  432.    security services are essential. The following are several security
  433.    services in particular that the HPN working group believes the
  434.    network function should be able to support:  rule based access
  435.    control, labeling, authentication, audit, connection oriented and
  436.    connectionless confidentiality, selective routing, traffic flow
  437.    confidentiality, connection oriented and connectionless integrity,
  438.    denial of service protection, continuity of operations, and
  439.    precedence/preemption.  In addition to these services, the network
  440.    function should also support the security management of these
  441.    security services. In particular, key management is of importance.
  442.  
  443.    Currently, the IPSEC of the IETF has several draft memos being
  444.    considered to incorporate various security services in the network
  445.    functions. It is of concern to the HPN working group that the IPng be
  446.    able to support the concepts currently being developed by the IPSEC
  447.  
  448.  
  449.  
  450. Green, Irey, Marlow & O'Donoghue                                [Page 8]
  451.  
  452. RFC 1679                 HPN IPng Requirements               August 1994
  453.  
  454.  
  455.    and also provide the ability for the addition of future security
  456.    services.
  457.  
  458. 5.4   Time Synchronization
  459.  
  460.    Time synchronization among the various components of mission critical
  461.    systems is of vital importance to the Navy. It is desirable to be
  462.    able to synchronize systems on multiple subnetworks via a network
  463.    layer infrastructure. Some hooks for time synchronization can be
  464.    envisioned in the network layer.  However, the HPN working group
  465.    feels that, as a minimum, efficient time synchronization algorithms
  466.    must be able to function above an IPng infrastructure. For HPN
  467.    systems, it is desirable that a time-of-day synchronization
  468.    capability be supported of at least an accuracy of one microsecond
  469.    among all hosts in a platform or campus network. The IPng protocols
  470.    should not arbitrarily prevent this type of synchronization
  471.    capability.
  472.  
  473. 6.   Conclusions
  474.  
  475.    A number of concerns specific to mission critical systems targeted by
  476.    the HPN working group have been identified. The HPN working group is
  477.    interested in participating with the IETF in the development of
  478.    standards which would apply to mission critical systems. In
  479.    particular, the HPN working group is interested in the development of
  480.    multicast functionality, an integrated services architecture, and
  481.    support for high performance subnetworks.
  482.  
  483. 7.   References
  484.  
  485.    [1] HPN Planning Group, "Concepts and Guidance for High Performance
  486.        Network (HPN)", Work in Progress, May 17, 1993.
  487.  
  488. 8.  Security Considerations
  489.  
  490.    Security issues are discussed in Section 5.3.
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Green, Irey, Marlow & O'Donoghue                                [Page 9]
  507.  
  508. RFC 1679                 HPN IPng Requirements               August 1994
  509.  
  510.  
  511. 9.   Authors' Addresses
  512.  
  513.    Dan Green
  514.    NSWC-DD
  515.    Code B35 NSWCDD
  516.    Dahlgren, VA 22448
  517.  
  518.    Phone: (703) 663-1571
  519.    EMail: dtgreen@relay.nswc.navy.mil
  520.  
  521.  
  522.    Phil Irey
  523.    NSWC-DD
  524.    Code B35 NSWCDD
  525.    Dahlgren, VA 22448
  526.  
  527.    Phone: (703) 663-1571
  528.    EMail: pirey@relay.nswc.navy.mil
  529.  
  530.  
  531.    Dave Marlow
  532.    NSWC-DD
  533.    Code B35 NSWCDD
  534.    Dahlgren, VA 22448
  535.  
  536.    Phone: (703) 663-1571
  537.    EMail: dmarlow@relay.nswc.navy.mil
  538.  
  539.  
  540.    Karen O'Donoghue
  541.    NSWC-DD
  542.    Code B35 NSWCDD
  543.    Dahlgren, VA 22448
  544.  
  545.    Phone: (703) 663-1571
  546.    EMail: kodonog@relay.nswc.navy.mil
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Green, Irey, Marlow & O'Donoghue                               [Page 10]
  563.  
  564.