SUBJECT: Data Link Requirements and Bandwidth Allocation for LAN/MAN Support of Multimedia Traffic -- contribution to the IEEE 802.1 Multimedia Task Subgroup SOURCE: Hal Keen, AT&T Global Information Solutions keen@ncrssd.StPaul.ncr.com INTRODUCTION At the Multimedia session of 802.1 in March, it was suggested the requirements for allocation of resources be reduced to a service definition, to be represented (eventually) as a sequence of service primitives. At the same meeting, I made an offhand attempt to summarize the requirements under discussion, with assistance from the committee to ensure completeness. Having had time for further analysis, I believe it is possible to derive the service definition from that summary. This contribution is an attempt at the exercise. This allocation service does not address cases in which dedicated circuits or channels are available for synchronous data. Rather, it attempts to control resources in a general MAC service environment in such a way that imitation of the dedicated circuits or channels, and possibly interconnection with them, is possible. SUMMARY OF REQUIREMENTS Following is a prettied-up representation of the summary developed during the March discussion: Required services: Bandwidth (send more data faster) Limited latency (reduce the delivery delay) Jitter control (reduced variance in delay) Bandwidth allocation (guarantees of these services at specific levels) Additional qualitative capabilities: Synchronization Multicast Allowed tradeoff: In SOME cases, data may be lost or delivered with bit errors. Each of these items is considered below, although the order of presentation has been modified for clarity. A description of the bandwidth allocation service follows. BANDWIDTH For many purposes, bandwidth is not a minimum-requirement concept. On a multiple-file transfer, FTP reports the bandwidth used for each file. Values vary wildly, depending on the activities of other users, but nobody cares much about the differences. Even for file transfer, cases arise in which bandwidth requirements must be met. If the file could be written to tape and manually reloaded on the target machine in nearly the same time, use of the network may be economically unjustified. Services requiring large amounts of data, such as voice or video, may be completely undeliverable unless a minimum bandwidth can be guaranteed, either because insufficient local storage is available at the receiver or because its use is incompatible with the nature of the service (e.g., real- time voice or video). Bandwidth is a simple concept, and one is tempted to measure it simply in terms of the data rate (quantity of data delivered per unit of time). However, the overhead required to deliver a thousand octets of user data is considerably less if a single frame is used than if ten are required. This overhead is of two types: 1) The portion due to additional frame headers and trailers can be considered in calculating the quantity of data. 2) The cumulative time needed for repeated medium accesses (at the sender) and the additional impact of contention for the network (on other users) has no simple relationship to additional data and must be measured separately. Therefore, two distinct parameters define the bandwidth requirement for a data stream: data rate and transmission frequency. For connection- oriented traffic, these parameters take into account additional data link protocol as well as delivery of user data. Bidirectional exchanges may be treated as separate streams in each direction, or the parameters can be totaled, as is found to be best for implementation in particular cases. LIMITED LATENCY Requirements for limited delay are familiar in conventional traffic. Almost any serious interactive use of a network involves an expected maximum or average response time. In many cases, multimedia traffic is characterized by stringent limits on latency. Real-time voice and video allow very little leeway. The delay behavior of a communication via LANs and MANs is, unfortunately, quite likely to be dependent on details of the configuration and types of network involved. For example, on a single Token Ring, two stations at priority zero can easily delay a high-priority competitor's access for over 18 ms (twice the maximum token holding time). Bridging may also affect latency. It is not yet clear how well 802 LANs are suited to delivery of low-latency services. For discussion purposes, however, latency limits can be expressed in terms of a single parameter: maximum frame delay. This parameter may take a range of values, in units of time. It should also be capable of encoding the non-quantified values "as short as possible" and "as long as it takes" to cover cases where a specified value is not suitable. EFFECTS OF FRAME SIZE ON LATENCY Delay on LANs or MANs is largely due to the wait while other stations transmit. Maximum frame length is therefore a significant factor in the delay suffered by other stations. Under some conditions (e.g., the Token Ring case cited above) it must always be considered equal to the maximum frame size supported by the particular MAC service. In other cases (e.g., a full duplex Dedicated Token Ring) the maximum frame size for each competing data stream may be fully controllable and specified as part of the resource allocation process. Maximum frame size for a data stream is treated as a separate parameter below. However, in many cases it is possible to simplify matters (reducing the number of different parameters) by relating it to bandwidth, using the approximation data rate = transmission frequency * maximum frame size which assumes all or most transmissions are at the maximum size for the data stream. TOLERATED DATA LOSS OR CORRUPTION When transmitting real-time voice or video, it is more important to deliver data in timely fashion than to ensure it is correct and complete. Given a sufficiently low bit error rate, the errors that do occur may be tolerable; latency limits may not allow any delay for retransmission. A consequence of this is the use of unconfirmed services, not just at a particular layer, but all the way up the stack. Another technique, recently introduced as an addition to HDLC (the UIH frame type), allows an FCS check that only protects the headers. Data may be delivered with bit errors rather than discarded, because delivery of the corrupt data is better than complete frame loss. LLC Type 4 may attempt this on 802 networks, although MAC-level support will also be needed for acceptable results because of the MAC FCS. Neither of these approaches has any impact on allocation of resources. In both cases, the bandwidth requirements are those for simple, unconfirmed data streams. JITTER CONTROL Control of jitter (variance in delay) has been mentioned as a requirement. Because the MAC service provides a negligible rate of frame misordering, the maximum jitter is simply the difference between maximum and minimum latency, by definition. From the receiver's point of view, however, a frame's absolute delay is unknown, but its spacing relative to others is apparent. The longest spacing between consecutive frames is obtained when the first arrives with minimum delay, the second with maximum delay. The shortest spacing is obtained in the converse sequence (assuming the original transmissions were so far apart that the restriction against misordering does not prevent the arrivals from being independent). The maximum variance in frame arrivals is therefore (maximum delay - minimum delay) - (minimum delay - maximum delay) = 2 x (maximum delay - minimum delay) = 2 x (maximum jitter) Of these two components in the jitter calculation, the maximum frame delay is also used to define latency requirements. Minimum frame delay may be reduced to an internal concern for the receiving station, by implementing a mechanism to delay presentation of any frame which arrives too early. Jitter control, to the extent it is possible, may be achieved entirely by combining this presentation delay with a suitable choice of the maximum frame delay. No additional parameters are needed in the data link layer. This topic is not addressed further in this contribution. SYNCHRONIZATION Synchronization of data streams may be required, for example, to match lip movements in a video data stream with the spoken words in the associated audio. There seems to be little reason to consider this service in connection with bandwidth allocation; the streams to be synchronized may have different service requirements and employ separate allocations, and may even be delivered over different media. It is unnecessary to regard synchronization as a service requirement at the data link layer. Like jitter control, it is strictly a presentation issue at the receiver. It does, however, imply the streams of data converge at some level before presentation to the end user. Delivery of such converging data streams is possible over 802 LANs and MANs, although it may be argued other types of networks are well suited to it. Because synchronization defines no additional data link requirements, it is not addressed further in this contribution. MULTICASTING 802 LANs and MANs permit both LLC and MAC group addresses, which serve as the basis of multicast services. Delivery of connection-oriented, or even reliable, multicast services may be considered in the LLC Type 4 work. However, like the existing connectionless service, the multicast aspect adds no new considerations for specification of required data link resources. Multicast capabilities involving communication with sets of individual LSAPs, by means other than group addresses, appear to be inherently rooted in a higher protocol layer. These approaches (possibly based on lists of individual destinations) would multiply the bandwidth required, but in such a case resources can be managed separately for each instance of individual communication; the multicast aspect is invisible to the data link layer. GUARANTEED SERVICE Some services cannot be provided unless adequate values can be guaranteed for the parameters discussed above: data rate, transmission frequency, and maximum frame delay. A "guarantee" in this sense goes beyond assuring the network and end stations are capable of supporting sustained traffic with the desired characteristics. It also means independent third parties will be prohibited from any use of resources heavy enough to interfere. To enforce the guarantee against interference by independent users, a "bandwidth allocation" service has been proposed. The provider of this service would perform two functions: It would act as a broker for allocating resources to data streams, and it would enforce the allocated limits. Enforcement of priorities, frame sizes, and other limitations for data streams not using this service would be a matter for the network administrator. It cannot be overemphasized that the ability to guarantee a data stream's characteristics (especially low latency) depends on restricting the behavior of stations sharing the media but not using the allocation service. In many cases, the provider of the allocation will require a protocol for communicating with a central repository of information. This protocol is assumed to include periodic checking of stations which have been granted allocations, so the resources can be reclaimed if it is found the user has failed or lost track of them. It may be desirable to define the service boundary and the abovementioned protocol to be MAC-independent. (The enforcement functions in the service provider may be MAC-dependent.) An architectural model might therefore place the bandwidth allocation service provider within the LLC sublayer. NOTE: This service provider is a general adaptation for use in those 802 LANs or MANs lacking exceptional handling for synchronous traffic. Those networks designed to offer a dedicated circuit or channel for support of synchronous data streams already possess suitable allocation mechanisms, which are by nature MAC-dependent. SERVICE PRIMITIVES Based on the data stream parameters developed above, a set of bandwidth allocation service primitives may be defined. This contribution addresses the service boundary at an end station employing the service. The additional primitives pertaining to a centralized server for bandwidth allocation, as well as the protocol for communicating with it, are extensions not explored at this time. Conceptually, the missing "legs" occur at the server (indication corresponding to a request, response to a confirm, etc.) The proposed service primitives are: BWA-ALLOCATE.request use: requests allocation of data stream resources parameters: data stream ID desired data stream characteristics minimal data stream characteristics maximum frame length BWA-ALLOCATE.confirm use: reports actual allocated data stream resources parameters: data stream ID granted data stream characteristics MAC transmission priority BWA-MODIFY.request use: requests modification of an existing data stream resource allocation, either to increase or partially release an existing allocation parameters: data stream ID desired data stream characteristics minimal data stream characteristics maximum frame length BWA-MODIFY.confirm use: reports modified data stream resource allocation parameters: data stream ID granted data stream characteristics MAC transmission priority BWA-RELEASE.request use: releases an existing data stream resource allocation parameters: data stream ID BWA-RELEASE.confirm use: confirms release of an existing allocation parameters: data stream ID BWA-CANCEL.indication use: retracts an existing allocation (due to time limits, or because changes in network conditions prevent its continued support) parameters: data stream ID The data stream ID is an abstract identifier used to correlate successive primitives pertaining to a particular stream. (With respect to enforcement of the allocation, it may also be used during data transmission.) The MAC transmission priority (if applicable) is assigned by the service provider because it may be required to enforce allocations, to both the requestor and competing streams. The "data stream characteristics" include data rate, transmission frequency, and maximum frame delay (for which "as short as possible" is a valid value only for requested, not granted, characteristics). They also include the duration of the allocation (with "unlimited" one of the possible values). This set of primitives supports a simple negotiation process, in which the provider may grant an allocation which is less than requested but still usable, and the requestor may immediately revert to a limited- bandwidth mode of operation, adjusting the granted capacity by releasing any excess. The concept of advance scheduling of allocations, to reserve network capacity for later use, will prove an interesting topic for further study. THE MULTIPLE-HOP PROBLEM The problem of controlling resources for a single network is relatively simple compared to the extension to a bridged case, especially if the bridges interconnect networks of different MAC types. Bridge forwarding capacity is itself a scarce resource, and the bandwidth on each side is a separate issue. If the topology of the bridged network changes, additional difficulties may be revealed. References to "intelligent bridges" propose an extension of bridging functions to management of allocated bandwidth for the individual data streams forwarded via the bridge. This does not seem a particularly clean solution, because the nature of current bridges includes a complete lack of awareness of individual data streams, except for certain options in filtering. The alternative is to make the point of network interconnection the terminal point of a data link. The interconnecting unit is made an end station, capable of using the same bandwidth allocation service (and potentially different MAC-specific peculiarities) on each data link. This divides the problem of bandwidth allocation into two single-hop cases, both able to use the capabilities described above. The allocation of capacity in the interconnecting unit becomes an internal problem. The "interconnecting unit" may be a router, a familiar case. However, users of low-latency data streams tend to prefer "switches" to routers. Switches, in this context, are distinguished by a direct handoff of data from one link to the next, without any need for interpretation of higher- layer protocol or addressing. A call setup procedure establishes the chain of associated links interconnecting two endpoints via switches and obtains the necessary bandwidth allocation for each hop. (The ability to request maximum latency "as short as possible" for each hop was suggested with this approach in mind.) The switching approach simplifies resource allocation by reducing the multiple-hop problem to a sequence of single-hop cases. It also extends the set of possible interconnections to include networks offering synchronous data stream support by means of dedicated circuits or channels. CONCLUSION Multimedia services require the ability to control bandwidth, latency, and jitter. On 802 LANs and MANs, these requirements can be expressed in terms of three data stream parameters: data rate, transmission frequency, and maximum frame delay. The maximum frame size may also be a factor in allocating network resources. From this basis, a service specification can be developed for allocating resources of a single network providing the MAC service. Unless sharing of the media by stations not subject to allocation is controlled by network administration, the service provider has only limited ability to guarantee the data stream characteristics, particularly the maximum frame delay. For the multiple-hop case, one approach might be to modify bridges to manage the behavior of individual data streams. This requires significant extensions of bridge functions so the behavior at a midpoint of the data stream can imitate the behavior at an endpoint. A preferred method is to terminate the data links at each point of network interconnection, so the interconnecting nodes are in fact endpoints for the purpose of allocating resources. An end-to-end data stream may then pass over a series of individual data links. (This observation suggests definitions for the terms "data link" and "data stream," loosely used above.) Many types of networks offer dedicated circuits or channels to guarantee a data stream's requirements can be met. This contribution has explored methods of imitating this capability on networks lacking these features. The value of pursuing this imitation remains a question for further debate.