Internet Engineering Task Force A. Ghanwani
INTERNET DRAFT J. W. Pace
V. Srinivasan
IBM
3 June 1996
Integrated Services over Token Ring Networks
draft-ghanwani-istr-00.txt
Status of This Memo
This document is an Internet-Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months, and may be updated, replaced, or obsoleted by other documents
at any time. It is not appropriate to use Internet Drafts as
reference material, or to cite them other than as a ``working draft''
or ``work in progress.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the internet-drafts
Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract
The RSVP and Integrated Services working groups have been working
towards the goal of an "Integrated Services Internet" where
applications can request a Quality of Service (QoS) from the network
in order to meet their end-to-end service requirements. This
document reviews various issues related to supporting Integrated
Service models over token ring networks. It also describes
features of token ring networks that can be leveraged to provide
QoS guarantees. It is intended as a starting point for building
an architectural framework to support these services in token ring
environments.
Ghanwani, Pace, Srinivasan Expires 2 December 1996 [Page i]
Internet Draft Integrated Services over Token Ring Networks 3 June 1996
1. Introduction
The Internet is soon expected to carry significant amounts of
multimedia traffic requiring end-to-end Quality of Service (QoS)
guarantees. In anticipation of this transition from largely
data-oriented traffic to multimedia traffic with QoS over the
Internet, the IETF is studying several service definitions within
the Integrated Services (INTSERV) working group. These service
definitions are called Guaranteed Delay, Predictive, Controlled
Delay, and Controlled Load. The QoS guarantees that these services
provide to flows range from the very stringent Guaranteed Delay
service to the minimal -- "better than best effort" -- Controlled
Load service.
The Internet spans a wide range of subnetwork technologies, from
dedicated, high bandwidth, router-to-router, point-to-point links
to shared LANs and dialup SLIP/PPP connections. This range of
subnetworks continues to expand with the advent of new technologies
such as ATM. Consequently, to be able provide a multimedia session
with end-to-end guaranteed QoS over the Internet, we must be able to
support the Integrated Services on any subnetwork that the session
might traverse. To this end, the IETF recently formed the Integrated
Services over Specific Link Layers (ISSLL) proto-working-group
to develop techniques and guidelines needed to support Internet
Integrated Service capabilities on specific network technologies.
The purpose of this document is to describe some of the issues
related to supporting Integrated Services over token ring networks.
Token ring networks possess many features such as source routing and
frame priorities that differentiate them from other shared media
LAN technologies. In this document, we will identify key features
of token rings that may be exploited in order to provide Integrated
Services and describe a possible framework for supporting QoS in a
shared environment.
2. Source Routing
The token ring MAC frame format is shown in Figure 1.
---------------------------------------------------------------------
| SD | AC | FC | DA | SA |Routing Info.|Info. field| FCS | ED | FS |
---------------------------------------------------------------------
Figure 1: Token ring Network Frame Format. SD is the starting
delimiter; AC is the access control field; FC is the frame control field;
ED is the ending delimiter; and FS is the frame status field.
Ghanwani, Pace, Srinivasan Expires 2 December 1996 [Page 1]
Internet Draft Integrated Services over Token Ring Networks 3 June 1996
Source routing is an important feature that differentiates token ring
networks from other LAN types. In source routing, each frame carries
information about the route it will follow through a multiple-segment
bridged network. This information is specified in the optional
Routing Information (RI) field in the frame. The RI field (RIF)
can be up to 32 bytes. When the RIF is included by the station
originating the frame, bridges processing the frame examine this
field to determine how to forward the frame.
The RIF is made up of a 2 byte control field, followed by up to 30
bytes of Route Designator (RD) fields. The control field contains:
- the type of frame,
- length of the RIF,
- direction in which to process the RIF, and
- largest-size information field that can be transmitted between two
communicating stations on a specific route.
Each segment in a given multiple-segment network is assigned a unique
ring number, and each bridge is assigned a number which may or may
not be unique. Together, a (ring number, bridge number) pair make up
a route designator. The RD fields in the RIF are made up of these
pairs that specify the frame's path through the network.
There are three token ring frame types that can be specified in the
control portion of the RIF:
- Specifically Routed Frame (SRF): this indicates that the RD fields
contain a specific route for the frame to traverse the network.
- All Routes Explorer (ARE): this indicates that the frame will be
transmitted along every route in the network to the destination
station. Frames transmitted as ARE will result in as many copies
being delivered to the destination as there are different routes to
the destination station.
- Spanning Tree Explorer (STE): this indicates that only certain
designated bridges (the ones on the spanning tree) will relay the
frame from one segment to another with the result that the frame will
appear exactly once on every segment in the network.
When an ARE or STE frame is transmitted, each bridge that forwards
the frame to another ring adds its bridge number and that ring's
number to the frame's RIF. When such a frame reaches its destination,
the routing information in the frame indicates the path taken by the
frame through the network. This routing information can be used
for subsequent communication between the stations, eliminating the
need to broadcast frames and conserving network bandwidth. In this
manner, source routing provides a dynamic mechanism to select routes
between stations in a token ring network. This feature can be used
in conjunction with a resource allocation mechanism, such as the one
Ghanwani, Pace, Srinivasan Expires 2 December 1996 [Page 2]
Internet Draft Integrated Services over Token Ring Networks 3 June 1996
described in the last section, to perform "QoS routing" of RSVP flows
through multiple ring networks.
3. Token Priority
The token ring standard [1] provides a priority mechanism that can
be used to control both the queuing of packets for transmission and
the access of packets to the shared media. The priority mechanisms
are implemented using bits within the Access Control (AC) and the
Frame Control (FC) fields of a LLC frame. The first three bits of
the AC field, the Token Priority bits, together with the last three
bits of the AC field, the Reservation bits, regulate which stations
get access to the ring. The last three bits of the FC field of an
LLC frame, the User Priority bits, are obtained from the higher
layer when it requests transmission of a packet. The requested
user priority establishes the requested access priority. The user
priority is conveyed end-to-end by the User Priority bits in the FC
field. In all cases, B'000' is the lowest priority.
A token ring station is theoretically capable of separately queuing
each of the eight levels of requested user priority and then
transmitting frames in order of priority. A station sets Reservation
bits according to the user priority of frames that are queued
for transmission in the highest priority queue. This allows the
access mechanism to ensure that the frame with the highest priority
throughout the entire ring will be transmitted before any lower
priority frame. Annex I to the IEEE 802.5 token ring standard
([1]) recommends that stations queue MAC frames and LAN management
frames with a user priority of 7 and 4, respectively. For LLC
frames, the annex recommends that time sensitive traffic (e.g.,
video playback) be queued with user priority 5, real time critical
service traffic (e.g., interactive video) with user priority 6, and
non-time critical traffic with user priority 0. Priorities 1-3
are left for use by other user traffic. To reduce frame jitter
associated with high-priority traffic, the annex also recommends
that only one frame be transmitted per token and that the maximum
information field size be 4399 octets whenever delay-sensitive
traffic in traversing the ring. Most existing implementations of
token ring bridges forward all LLC frames with a default access
priority of 4. Annex I recommends that bridges forward LLC frames
that have a user priorities greater that 4 with a reservation equal
to the user priority. (The draft IEEE Standard P802.1p ([2]) permits
network management to control whether bridges forward frames with the
outbound user priority set to the same value as received in the user
priority field. It also describes the forwarding process for bridges
that support traffic classes and multiple queues.) The capabilities
provided by token ring's user and reservation priorities and by IEEE
Ghanwani, Pace, Srinivasan Expires 2 December 1996 [Page 3]
Internet Draft Integrated Services over Token Ring Networks 3 June 1996
802.1p can provide effective support for Integrated Services flows
that request QoS using RSVP. These mechanisms can provide, with few
or no addition to the token ring architecture, bandwidth guarantees
and the network flow control necessary to support quarantees.
4. Multicast Addressing
RSVP is designed to inherently support multicast IP destination
addresses. References [3] and [4] define methods for mapping
multicast IP addresses (respectively) to multicast MAC addresses
for use on all IEEE 802 LANs and to functional addresses for use on
token ring networks. IEEE Standard 802.1p is also defining a method
to support the filtering of multicast MAC addresses by LAN bridges
and switches. With a fully implemented network of 802.1p compliant
bridges, it therefore becomes possible to filter Integrated Services
flows at both the IP layer (via IGMP) and at the MAC layer (via
802.1p). Multicast filtering can potentially reduce the bandwidth
consumed by Integrated Services flows on parts of the spanning
tree. This filtering is available on both token ring and IEEE 802.3
networks. In the absence of 802.1p filtering, source routing might
be used on token ring networks to limit the bandwidth consumed on
those segments of the network that have no receivers for a particular
Integrated Services flow.
5. Client-Server QoS Framework
One method of exploiting the above features of token ring and of
supporting QoS in a shared LAN is via a client-server mechanism.
The server implements a "QoS Allocator" that is responsible for
maintaining awareness of the resource usage of various LAN components
(e.g. bridges, segments). End stations desiring to transmit data
with QoS guarantees implement a "QoS Requestor," which is the client
component responsible for making requests to reserve resources
across the LAN. The Allocator determines whether a particular
request for a quality of service allocation can be satisfied, and
maintains knowledge of existing QoS allocations. (Note: this simple
client-server framework has been informally referred to as a "Mother
May I?" protocol.)
The Allocator may be implemented in a distributed fashion or as a
single entity. In the former case, each token ring segment could
have a separate Allocator, and all Allocators would periodically
exchange information about available resources on all segments. If
implemented as a single entity, there would be a single Allocator
for all segments and bridges in the network. Having a centralized
Allocator is simpler to implement, and avoids synchronization and
Ghanwani, Pace, Srinivasan Expires 2 December 1996 [Page 4]
Internet Draft Integrated Services over Token Ring Networks 3 June 1996
deadlock problems. However, this approach does not scale well with
larger networks.
In order to support Integrated Services, the Requestor-Allocator
framework must interact with higher layer QoS signalling mechanisms
such as RSVP. Each RSVP router/host in the network must use the QoS
Requestor to reserve resources for RSVP flows. When an RSVP RESV
message containing a reservation request is received at a station
(router/host) on the LAN, it must be translated into an appropriate
request to the Allocator to reserve resources at Layer 2. The
Allocator will process the request and send a reply to the Requestor
with a success/failure indication. This reply is returned to the
RSVP daemon which will take appropriate action such as forwarding the
RESV message upstream, or sending a RESVERR to the originator of the
RESV message.
The QoS Allocator can use the various features of token rings, such
as source routing and token priorities, in order to accomplish
resource reservations for RSVP flows. In the earlier sections, we
have described some of these features.
6. References
[1] IEEE Standards for Local and Metroplitan Area Networks: Token
Ring Access Method and Physical Layer Specifications. IEEE Std
802.5-1995.
[2] IEEE Standards for Local and Metropolitan Area Networks: Draft
Standard for Traffic Class and Dynamic Multicast Filtering Services
in Bridged Local Area Networks (Draft Supplement to 802.1D),
P802.1p/D3, April 30, 1996.
[3] S. Deering, Host Extensions for IP Multicasting, Std 5, RFC 1112,
August 1989.
[4] S. Thomas, A Method for the Transmission of IPv6 Packets over
Token Ring Networks, draft-ietf-ipnwg-token-ring-01.txt, work in
progress, Jan 22, 1996.
7. Authors' Address
Anoop Ghanwani
IBM Corporation
P. O. Box 12195
Research Triangle Park, NC 27709
Ghanwani, Pace, Srinivasan Expires 2 December 1996 [Page 5]
Internet Draft Integrated Services over Token Ring Networks 3 June 1996
Phone: +1-919-254-0260
Fax: +1-919-254-5410
E-mail: anoop@raleigh.ibm.com
Wayne Pace
IBM Corporation
P. O. Box 12195
Research Triangle Park, NC 27709
Phone: +1-919-254-4930
Fax: +1-919-254-5410
E-mail: pacew@raleigh.ibm.com
Vijay Srinivasan
IBM Corporation
P. O. Box 12195
Research Triangle Park, NC 27709
Phone: +1-919-254-2730
Fax: +1-919-254-5410
E-mail: vijay@raleigh.ibm.com
Ghanwani, Pace, Srinivasan Expires 2 December 1996 [Page 6]