rfc2502.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                           M. Pullen
Request for Comments: 2502                        George Mason University
Category: Informational                                          M. Myjak
                                                     The Virtual Workshop
                                                               C. Bouwens
                                                                     SAIC
                                                            February 1999


   Limitations of Internet Protocol Suite for Distributed Simulation
                   in the Large Multicast Environment

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   The Large-Scale Multicast Applications (LSMA) working group was
   chartered to produce documents aimed at a consensus based development
   of the Internet protocols to support large scale multicast
   applications including real-time distributed simulation.  This memo
   defines services that LSMA has found to be required, and aspects of
   the Internet protocols that LSMA has found to need further
   development in order to meet these requirements.

1. The Large Multicast Environment

   The Large-Scale Multicast Applications working group (LSMA) was
   formed to create a consensus based requirement for Internet Protocols
   to support Distributed Interactive Simulation (DIS) [DIS94], its
   successor the High Level Architecture for simulation (HLA) [DMSO96],
   and related applications. The applications are characterized by the
   need to distribute a real-time applications over a shared wide area
   network in a scalable manner such that numbers of hosts from a few to
   tens of thousands are able to interchange state data with sufficient
   reliability and timeliness to sustain a three dimensional virtual,
   visual environment containing large numbers of moving objects.  The
   network supporting such an system necessarily will be capable of
   multicast [IEEE95a,IEEE95b].





Pullen                       Informational                      [Page 1]

RFC 2502         Limitations of Internet Protocol Suite    February 1999


   Distributed Interactive Simulation is the name of a family of
   protocols used to exchange information about a virtual environment
   among hosts in a distributed system that are simulating the behavior
   of objects in that environment.  The objects are capable of physical
   interactions and can sense each other by visual and other means
   (infrared, etc.).  DIS was developed by the U.S. Department of
   Defense (DoD) to implement systems for military training, rehearsal,
   and other purposes. More information on DIS can be found in [SSM96].

   The feature of distributed simulation that drives network
   requirements is that it is intended to work with output to and input
   from humans across distributed simulators in real time. This places
   tight limits on latency between hosts.  It also means that any
   practical network will require multicasting to implement the required
   distribution of all data to all participating simulators.  Large
   distributed simulation configurations are expected to group hosts on
   multicast groups based on sharing the same sensor inputs in the
   virtual environment.  This can mean a need for thousands of multicast
   groups where objects may move between groups in large numbers at high
   rates.  Because the number of simulators is known in advance and
   their maximum output rate in packets per second and bits per second
   is specified, the overall total data rate (the sum of all multicast
   groups) is bounded. However the required data rate in any particular
   group cannot be predicted, and may change quite rapidly during the
   simulation.

   DIS real time flow consists of packets of length around 2000 bits at
   rates from .2 packets per second per simulator to 15 packets per
   second per simulator. This information is intentionally redundant and
   is normally transmitted with a best effort transport protocol (UDP).
   In some cases it also is compressed.  Required accuracy both of
   latency and of physical simulation varies with the intended purpose
   but generally must be at least sufficient to satisfy human
   perception.  For example, in tightly coupled simulations such as high
   performance aircraft maximum acceptable latency is 100 milliseconds
   between any two hosts.  At relatively rare intervals events (e.g.
   collisions) may occur which require reliable transmission of some
   data, on a unicast basis, to any other host in the system.

   The U.S. DoD has a goal to build distributed simulation systems with
   up to 100,000 simulated objects, many of them computer generated
   forces that run with minimal human intervention, acting as opposing
   force or simulating friendly forces that are not available to
   participate.  DoD would like to carry out such simulations using a
   shared WAN.  Beyond DoD many people see a likelihood that distributed
   simulation capabilities may be commercialized as entertainment.  The
   scope of such an entertainment system is hard to predict but
   conceivably could be larger than the DoD goal of 100,000.



Pullen                       Informational                      [Page 2]

RFC 2502         Limitations of Internet Protocol Suite    February 1999


   The High Level Architecture (HLA) is a DoD development beyond DIS
   that aims at bringing DIS and other forms of distributed simulation
   into a unifying system paradigm. From a distributed systems
   standpoint HLA is considerably more sophisticated than DIS. For
   example attributes of distributed objects may be controlled by
   different simulators.  From the standpoint of the supporting network
   the primary difference between HLA and DIS is that HLA does not call
   for redundant transmission of object attributes; instead it specifies
   a "Run Time Infrastructure" (RTI) that is responsible to transmit
   data reliably, and may choose to do so by various means including
   redundant transmission using best effort protocols. It is reasonable
   to say that any network that can meet the needs of DIS can support
   HLA by DIS-like redundant transmission, however this approach ignores
   the possibility that under HLA some mixture of redundant and reliable
   transmission can make significantly better use of network resources
   than is possible using DIS.  While HLA, like DIS, does not specify
   use of a multicasting network, it has similar requirements for many-
   to-many transmission of object attributes at rates in excess of one
   update per object per second that cannot be met without multicasting.
   Further, HLA calls for transmission of semantically organized data
   (for example, groups of objects with similar capabilities such as
   tanks or aircraft) in this many-to-many context.

   One solution that has been employed to deal with these challenges is
   to aggregate the contents of many multicast groups into a single
   multicast transmission [PuWh95, CSTH95].  Termed "dual-mode" or "bi-
   level" multicast, this approach takes advantage of the fact that
   although the amount of traffic in any particular multicast group can
   vary greatly, the aggregate of all transmissions is bounded. If the
   traffic is all aggregated into one large flow, an underlying ATM
   network can create multicast SVCs with acceptable QoS to support the
   requirement. It also bounds the network control problem of group
   joins, in that the joins take place among dedicated collections of
   routers and across the dedicated SVCs, rather than contending with
   other LSMAs that may be sharing the same network. But it does this at
   the cost of adding to the network a new, nonstandard aggregation
   element that is a hybrid of the Internet and ATM protocols. We
   address below the requirement to achieve such a result using a purely
   IP network with aggregated reservation via RSVP.

   The defense distributed simulation community has created a number of
   multicast-capable networks for various simulated exercises, ranging
   from tens to hundreds of simulated objects distributed across numbers
   of sites ranging from two to twenty. As the number of objects has
   increased they have found that building multicasting networks
   potentially supporting thousands of simultaneous multicast groups
   with large group change rates is a hard problem. This defense problem
   is the precursor of similar problems that can be expected in



Pullen                       Informational                      [Page 3]

RFC 2502         Limitations of Internet Protocol Suite    February 1999


   commercial networks.  Therefore the following sections describe the
   services required and the shortcomings that have been found in using
   today's Internet protocols in providing these services, with the
   intention of informing the IETF to enable it to produce protocols
   that meet the needs in these areas.

2. Distributed Simulation (DIS and HLA) network service requirements.

   a. real-time packet delivery, with low packet loss (less than 2%),
   predictable latency on the order of a few hundred milliseconds, after
   buffering to account for jitter (variation of latency) such that less
   than 2% of packets fail to arrive within the specified latency, in a
   shared network

   b. multicasting with thousands of multicast groups that can support
   join latencies of less than one second, at rates of hundreds of joins
   per second

   c. multicasting using a many-to-many paradigm in which 90% or more of
   the group members act as receivers and senders within any given
   multicast group

   d. support for resource reservation; because of the impracticality of
   over-provisioning the WAN and the LAN for large distributed
   simulations, it is important to be able to reserve an overall
   capacity that can be dynamically allocated among the multicast groups

   e. support for a mixture of best-effort and reliable low-latency
   multicast transport, where best-effort predominates in the mixture,
   and the participants in the reliable multicast may be distributed
   across any portion of the network

   f. support for secure networking, in the form of per-packet
   encryption and authentication needed for classified military
   simulations

3. Internet Protocol Suite facilities needed and not yet available for
   large-scale distributed simulation in shared networks: These derive
   from the need for real-time multicast with established quality of
   service in a shared network.  (Implementation questions are not
   included in this discussion.  For example, it is not clear that
   implementations of IP multicast exist that will support the required
   scale of multicast group changes for LSMA, but that appears to be a
   question of implementation, not a limitation of IP multicast.)







Pullen                       Informational                      [Page 4]

RFC 2502         Limitations of Internet Protocol Suite    February 1999


3.1 Large-scale resource reservation in shared networks

   The Resource reSerVation Protocol (RSVP) is aimed at providing setup
   and flow-based information for managing information flows at pre-
   committed performance levels.  This capability is generally seen as
   needed in real-time systems such as the HLA RTI. Concerns have been
   raised about the scalability of RSVP, and also about its ability to
   support highly dynamic flow control changes.  In terms of existing
   RTI capabilities, the requirement in LSMA is for rapid change of
   group membership, not for rapid change of group reservations.  This
   is because in existing RTIs the aggregate requirement for all groups
   in a large scale distributed simulation is static. However the
   current RSVP draft standard for LSMA does not support aggregation of
   reservation resources for groups of flows and therefore does not meet
   the needs of existing RTIs.  Moreover, there is at least one RTI
   development underway that intends to use individual, dynamic
   reservations for large numbers of groups, and therefore will require
   a dynamic resource reservation capability that scales to thousands of
   multicast groups.

   Further, RSVP provides support only for communicating specifications
   of the required information flows between simulators and the network,
   and within the network.  Distributing routing information among the
   routers within the network is a different function altogether,
   performed by routing protocols such as Multicast Open Shortest Path
   First (MOSPF). In order to provide effective resource reservation in
   a large shared network function, it may be necessary to have a
   routing protocol that determines paths through the network within the
   context of a quality of service requirement.  An example is the
   proposed Quality Of Service Path First (QOSPF) routing protocol
   [ZSSC97]. Unfortunately the requirement for resource-sensitive
   routing will be difficult to define before LSMA networks are deployed
   with RSVP.

3.2 IP multicast that is capable of taking advantage of all common
    link layer protocols (in particular, ATM)

    Multicast takes advantage of the efficiency obtained when the
    network can recognize and replicate information packets that are
    destined to a group of locations. Under these circumstances, the
    network can take on the job of providing duplicate copies to all
    destinations, thereby greatly reducing the amount of information
    flowing into and through the network.

    When IP multicast operates over Ethernet, IP multicast packets are
    transmitted once and received by all receivers using Ethernet-layer
    multicast addressing, avoiding replication of packets.  However,
    with wide-area Asynchronous Transfer Mode (ATM), the ability to take



Pullen                       Informational                      [Page 5]

RFC 2502         Limitations of Internet Protocol Suite    February 1999


    advantage of data link layer multicast capability is not yet
    available beyond a single Logical IP Subnet (LIS).  This appears to
    be due to the fact that (1) the switching models of IP and ATM are
    sufficiently different that this capability will require a rather
    complex solution, and (2) there has been no clear application
    requirement for IP multicast over ATM multicast that provides for
    packet replication across multiple LIS.  Distributed simulation is
    an application with such a requirement.

3.3 Hybrid transmission of best-effort and reliable multicast

    In general the Internet protocol suite uses the Transmission Control
    Protocol (TCP) for reliable end-to-end transport, and the User
    Datagram Protocol (UDP) for best-effort end-to-end transport,
    including all multicast transport services.  The design of TCP is
    only capable of unicast transmission.

    Recently the IETF has seen proposals for several reliable multicast
    transport protocols (see [Mont97] for a summary). A general issue
    with reliable transport for multicast is the congestion problem
    associated with delivery acknowledgments, which has made real-time
    reliable multicast transport infeasible to date.  Of the roughly 15
    attempts to develop a reliable multicast transport, all have shown
    to have some problem relating to positive receipt acknowledgments