rfc2502.txt

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

    (ACK) or negative acknowledgments (NAK). In any event, its seems
    clear that there is not likely to be a single solution for reliable
    multicast, but rather a number of solutions tailored to different
    application domains. Approaches involving distributed logging seem
    to hold particular promise for the distributed simulation
    application.

    In the DIS/HLA environment, five different transmission needs can be
    identified:

   (1) best-effort low-latency multicast of object attributes that often
       change continuously, for example position of mobile objects;
   (2) low-latency reliable multicast of object attributes that do not
       change continuously but may change at arbitrary times during the
       simulation, for example object appearance (An important
       characteristic of this category is that only the latest value of
       any attribute is needed by the receiver.);
   (3) low-latency, reliable unicast of occasional data among arbitrary
       members of the multicast group (This form of transmission was
       specified for DIS "collisions"; it is not in the current HLA
       specification but might profitably be included there. The
       requirement is for occasional transaction-like exchange of data
       between two arbitrary hosts in the multicast group, with a low
       latency that makes TCP connection impractical.);



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


   (4) reliable but not necessarily real-time multicast distribution of
       supporting bulk data such as terrain databases and object
       enumerations; and
   (5) reliable unicast of control information between individual RTI
       components (this requirement is met by TCP).

   All of these transmissions take place within the same large-scale
   multicasting environment. The value of integrating categories (1) and
   (2) into a single selectively reliable protocol was proposed by Cohen
   [Cohe94].  Pullen and Laviano implemented this concept [PuLa95] and
   demonstrated it within the HLA framework [PLM97] as the Selectively

   Reliable Transmission Protocol (SRTP) for categories (1) through (3).
   Category (4) could be supported by a reliable multicast protocol such
   as the commercial multicast FTP offering from Starburst [MRTW97],
   however adequate congestion control has not been demonstrated in any
   such protocol. There has been some discussion of using the Real-Time
   Streaming Protocol, RTSP, for this purpose, however as the databases
   must be transmitted reliably and RTSP uses a best-effort model, it
   does not appear to be applicable.

   In summary, it is clear that a hybrid of best-effort and reliable
   multicast (not necessarily all in the same protocol) is needed to
   support DIS and HLA, and that the low-latency, reliable part of this
   hybrid is not available in the Internet protocol suite.

3.4 Network management for distributed simulation systems

   Coordinated, integrated network management is one of the more
   difficult aspects of a large distributed simulation exercise.  The
   network management techniques that have been used successfully to
   support the growth of the Internet for the past several years could
   be expanded to fill this need.  The technique is based on a primitive
   called a Management Information Base (MIB) being polled periodically
   at very low data rates.  The receiver of the poll is called an Agent
   and is collocated with the remote process being monitored. The agent
   is simple so as to not absorb very many resources. The requesting
   process is called a Manager, and is typically located elsewhere on a
   separate workstation.  The Manager communicates to all of the agents
   in a given domain using the Simple Network Management Protocol
   (SNMP).  It appears that SNMP is well adapted to the purpose of
   distributed simulation management, in addition to managing the
   underlying simulation network resources.  Creating a standard
   distributed simulation MIB format would make it possible for the
   simulation community to make use of the collection of powerful, off-
   the-shelf network management tools that have been created around
   SNMP.




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


3.5 A session protocol to start, pause, and stop a distributed
    simulation exercise

   Coordinating start, stop, and pause of large distributed exercises is
   a complex and difficult task.  The Session Initiation Protocol (SIP)
   recently proposed by the Multiparty Multimedia Session Control
   (MMUSIC) working group serves a similar purpose for managing large
   scale multimedia conferences. As proposed, SIP appears to offer
   sufficient extensibility to be used for exercise session control, if
   standardized by the IETF.

3.6 An integrated security architecture

   It appears that this requirement will be met by IPv6 deployment. A
   shortcoming of the current Internet Protocol (IPv4) implementation is
   the lack of integrated security. The new IPv6 protocol requires
   implementers to follow an integrated security architecture that
   provides the required integrity, authenticity, and confidentiality
   for use of the Internet by communities with stringent security
   demands, such as the financial community.  The possibility that the
   IPv6 security architecture may meet military needs, when combined
   either with military cryptography or government-certified commercial
   cryptography, merits further study.

3.7 Low-latency multicast naming service

   Name-to-address mapping in the Internet is performed by the Domain
   Name Service (DNS).  DNS has a distributed architecture tuned to the
   needs of unicast networking with reliable transmission (TCP) that is
   not considered problematic if its latency is on the order of a second
   or more. The requirement of distributed simulation for agile movement
   among multicast groups implies a need for name-to-multicast-address
   mapping with latency of under one second for the name resolution and
   group join combined.  This problem has been circumvented in military
   simulations by using group IP addresses rather than names. While
   military simulations may be satisfied to communicate using a known
   mapping from grid squares to multicast groups, growth of distributed
   simulation into commercial entertainment cannot be based on such a
   simple capability. The players in distributed entertainment
   simulations will want to be organized symbolically by virtual world
   and role. A low-latency multicast naming service will be required.

3.8 Inter-Domain Multicast Routing for LSMA

   While military LSMAs typically take place within a single
   administrative domain, future entertainment LSMAs can be expected to
   involve heavy inter-domain multicast traffic so that players can be
   supported by multiple service providers.  Standardized protocols able



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


   to support large numbers of multicast flows across domain boundaries
   will be needed for this purpose.  Current work to create a Border
   Gateway Multicast Protocol (BGMP) shows promise of meeting this need.

4.  References

   [CSTH95]  Calvin, J., et. al., "STOW Realtime Information Transfer
             and Networking Architecture," 12th DIS Workshop on
             Standards for the Interoperability Distributed Simulations,
             March 1995.

   [Cohe94]  Cohen, D., "Back to Basics," Proceedings of the 11th
             Workshop on Standards for Distributed Interactive
             Simulation, Orlando, FL, September 1994.

   [DIS94]   DIS Steering Committee, "The DIS Vision," Institute for
             Simulation and Training, University of Central Florida, May
             1994.

   [DMSO96]  Defense Modeling and Simulation Office, High Level
             Architecture Rules Version 1.0, U.S. Department of Defense,
             August 1996.

   [IEEE95a] IEEE 1278.1-1995, Standard for Distributed Interactive
             Simulation - Application Protocols

   [IEEE95b] IEEE 1278.2-1995, Standard for Distributed Interactive
             Simulation - Communication services and Profiles

   [MRTW97]  Miller, K., et. al. "StarBurst Multicast File Transfer
             Protocol (MFTP) Specification", Work in Progress.

   [Mont97]  Montgomery, T., Reliable Multicast Links webpage,
             http://research.ivv.nasa.gov/RMP/links.html

   [PuLa95]  Pullen, M. and V. Laviano, "A Selectively Reliable
             Transport Protocol for Distributed Interactive Simulation",
             Proceedings of the 13th Workshop on Standards for
             Distributed Interactive Simulation, Orlando, FL, September
             1995.

   [PuWh95]  Pullen, M. and E. White, "Dual-Mode Multicast: A New
             Multicasting Architecture for Distributed Interactive
             Simulation," 12th DIS Workshop on Standards for the
             Interoperability of Distributed Simulations, Orlando, FL,
             March 1995.





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


   [PLM97]   Pullen, M., Laviano, V. and M. Moreau, "Creating A Light-
             Weight RTI As An Evolution Of Dual-Mode Multicast Using
             Selectively Reliable Transmission," Proceedings of the
             Second Simulation Interoperability Workshop, Orlando, FL,
             September 1997.

   [SPW94]   Symington, S., Pullen, M. and D. Wood, "Modeling and
             Simulation Requirements for IPng", RFC 1667, August 1994.

   [SSM96]   Seidensticker, S., Smith, W. and M. Myjak, "Scenarios and
             Appropriate Protocols for Distributed Interactive
             Simulation", Work in Progress.

   [ZSSC97]  Zhang, Z., et. al., "Quality of Service Path First Routing
             Protocol", Work in Progress.

4.  Security Considerations

   Security issues are discussed in section 3.6.

5.  Authors' Addresses

   J. Mark Pullen
   Computer Science/C3I Center
   MS 4A5
   George Mason University
   Fairfax, VA 22032

   EMail: [e-mail]


   Michael Myjak
   The Virtual Workshop
   P.O. Box 98
   Titusville, FL 32781

   EMail: [e-mail]


   Christina Bouwens
   ASSET Group, SAIC Inc.
   Orlando, FL

   EMail: [e-mail]







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


6.  Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Pullen                       Informational                     [Page 11]