From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2502.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc2502.txt (limited to 'doc/rfc/rfc2502.txt') diff --git a/doc/rfc/rfc2502.txt b/doc/rfc/rfc2502.txt new file mode 100644 index 0000000..c9683f9 --- /dev/null +++ b/doc/rfc/rfc2502.txt @@ -0,0 +1,619 @@ + + + + + + +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 + (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: mpullen@gmu.edu + + + Michael Myjak + The Virtual Workshop + P.O. Box 98 + Titusville, FL 32781 + + EMail: mmyjak@virtualworkshop.com + + + Christina Bouwens + ASSET Group, SAIC Inc. + Orlando, FL + + EMail: christina.bouwens@cpmx.mail.saic.com + + + + + + + +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] + -- cgit v1.2.3