[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]