Internet Engineering Task Force A. Ghanwani
INTERNET DRAFT J. W. Pace
V. Srinivasan
IBM
April 1997
A Framework for Providing Integrated Services
Over Shared and Switched LAN Technologies
draft-ietf-issll-is802-framework-01.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
Traditionally, LAN technologies such as ethernet and token ring have
been required to handle best effort services only. No standard
mechanism exists for providing service guarantees on these media as
will be required by emerging and future multimedia applications. The
anticipated demand for such applications on the Internet has led
to the development of RSVP, a signaling mechanism for performing
resource reservation in the Internet. Concurrently, the Integrated
Services working group within the IETF has been working on the
definition of service classes called Integrated Services which are
expected to make use of RSVP. Applications will use these service
classes in order to obtain the desired quality of service from the
network. LAN technologies such as token ring and ethernet typically
constitute the last hop in Internet connections. It is therefore
Ghanwani, Pace, Srinivasan Expires October 1997 [Page i]
Internet Draft Integrated Services Over LANs April 1997
necessary to enhance these technologies so that they are able to
support the Integrated Services. This memo describes a framework for
providing the functionality to support Integrated Services on shared
and switched LAN technologies.
Ghanwani, Pace, Srinivasan Expires October 1997 [Page ii]
Internet Draft Integrated Services Over LANs April 1997
1. Introduction
The Internet has traditionally provided support for best effort
traffic only. However, with the recent advances in link layer
technology, and with numerous emerging real-time applications such
as video conferencing and Internet telephony, there has been much
interest for developing mechanisms which enable real-time services
over the Internet. These new requirements have led to the design of
the Resource ReSerVation Protocol (RSVP) [3], a signaling mechanism
for providing resource reservation on the Internet. The protocol
is currently being standardized by the IETF. Simultaneously, the
Integrated Services working group of the IETF has been working on
the specification of various service classes. Each of these service
classes is designed to provide certain Quality of Service (QoS)
guarantees to traffic conforming to a specified set of parameters.
Applications are expected to use one of these classes depending on
their QoS requirements.
There is no standard mechanism for providing service guarantees on
LAN technologies such as ethernet and token ring. They, however,
typically constitute the last hop between users and the Internet
backbone. Furthermore, the development of standards for high speed
LANs such as gigabit ethernet favors the likelihood that these
technologies will eventually be deployed in the backbone of campus
networks. It is therefore necessary to enhance these technologies so
that they are able to support end-to-end service guarantees such as
those defined by the Integrated Services.
In order to support real-time services, there must be some mechanism
for resource management at the link level. Resource management
in this context encompasses the functions of admission control,
scheduling, traffic policing, etc. The ISSLL (Integrated Services
over Specific Link Layers) working group in the IETF was chartered
with the purpose of exploring and standardizing such mechanisms for
various link layer technologies.
This document is concerned with specifying a framework for providing
Integrated Services over shared and switched LAN technologies such
as ethernet/802.3, token ring/802.5, FDDI, etc. We begin with a
list of definitions in Section 2. Section 3 lists the requirements
and goals for a mechanism capable of providing Integrated Services
in a subnet. We then discuss a taxonomy of topologies for the LAN
technologies under consideration with an emphasis on the capabilities
of each which can be leveraged for enabling Integrated Services. The
resource management functions outlined in Section 3 are expected
to be provided by an entity which, in this document, is referred
to as the Bandwidth Manager (BM). The various components of the
Bandwidth Manager are discussed in the following section and some
Ghanwani, Pace, Srinivasan Expires October 1997 [Page 1]
Internet Draft Integrated Services Over LANs April 1997
examples of the implementation of the Bandwidth Manager are provided.
Some issues with respect to link layer support for Integrated
Services are examined in Section 6. In the development of this
framework, no assumptions have been made about the technology or
topology at the link layer. The framework is intended to be as
exhaustive as possible; this means that it is possible that all the
functions discussed may not be supportable by a particular topology
or technology, but this should not preclude the usage of this model
for it.
2. Definitions
The following is a list of the terms used in this document.
- End Station: A device (e.g. router, host) which runs the
application program or higher layer protocol which needs to make
reservations.
- Link Layer/Layer 2: The data link layer. This memo is concerned
with link layer technologies such as ethernet, token ring, and
FDDI.
- Link Layer Domain: A an interconnection of segments and
bridges/switches between two end stations.
- Segment: A link which is shared by one or more senders.
- Traffic Class: A category of flows which are given similar
service within a bridge/switch.
3. Supporting Integrated Services Within a Subnet: Requirements and
Goals
This section discusses the requirements and goals which should drive
the design of an architecture for supporting Integrated Services over
LAN technologies. The requirements refer to functions and features
which must be supported, while goals refer to functions and features
which are desirable, but are not an absolute necessity. Many of the
requirements and goals are driven by the functionality supported by
RSVP.
3.1. Requirements
- Resource Reservation: The mechanism must be capable of reserving
resources on a single segment or multiple segments and at
Ghanwani, Pace, Srinivasan Expires October 1997 [Page 2]
Internet Draft Integrated Services Over LANs April 1997
bridges/switches connecting them. It must be able to provide
reservations for both unicast and multicast sessions. It should
be possible to change the level of reservation while the session
is in progress.
- Admission Control: The mechanism must be able to estimate
the level of resources necessary to meet the QoS requested by
the session in order to decide whether or not the session can
be admitted. For the purpose of management, it is useful to
provide the ability to respond to queries about availability of
resources. It must be able to make admission control decisions
for different types of QoS such as guaranteed delay, guaranteed
bandwidth, etc.
- Flow Separation and Scheduling: It is necessary to provide a
mechanism for traffic flow separation so that real-time flows can
be given preferential treatment over best effort flows. Packets
of real-time flows can then be isolated and scheduled according
to their service requirements. Scheduling algorithms can range
from simple static priority queueing to more complex algorithms
such as weighted fair queueing and its variants.
- Policing: Traffic policing must be performed in order to ensure
that sources adhere to their negotiated traffic specifications.
Policing must be implemented at the sources and must ensure
that violating traffic is either dropped or transmitted as best
effort. Policing may optionally be implemented in the bridges
and switches. Alternatively, traffic may be shaped to insure
conformance to the negotiated parameters.
- Soft State: The mechanism must maintain soft state information
about the reservations. This means that state information must
be periodically refreshed if the reservation is to be maintained;
otherwise the state information and reservation will expire after
some pre-specified interval.
- Centralized or Distributed Implementation: In the case of a
centralized implementation, a single entity manages the resources
of the entire subnet. This approach has the advantage of being
easier to deploy since bridges and switches may not need to be
upgraded with additional functionality. However, this approach
scales poorly with geographical size of the subnet and the number
of hosts attached. In a fully distributed implementation, each
segment will have a local entity managing its resources. This
approach has better scalability than the former. However, it
requires that all bridges and switches in the network support
new mechanisms. It is also possible to have a semi-distributed
implementation where there is most than one entity, each managing
Ghanwani, Pace, Srinivasan Expires October 1997 [Page 3]
Internet Draft Integrated Services Over LANs April 1997
the resources of a subset of segments and bridges/switches
within the subnet. Ideally, implementation should be flexible;
i.e. a centralized approach may be used for small subnets and a
distributed approach can be used for larger subnets. Examples
of centralized and distributed implementations are discussed in
Section 4.
- Fault Tolerance and Recovery: The mechanism must be able to
function in the presence of failures; i.e. there should not
be a single point of failure. For instance, in a centralized
implementation, some mechanism must be specified for back-up and
recovery in the event of failure.
- Network Management: The MIBs supported must be specified.
- Interaction with Existing Resource Management Controls: The
interaction with existing infrastructure for resource management
needs to be specified. For example, FDDI has a resource
management mechanism called the "Synchronous Bandwidth Manager".
The mechanism must be designed so that it takes advantage of,
and specifies the interaction with, existing controls where
available.
3.2. Goals
- Independence from higher layer protocols: The mechanism should,
as far as possible, be independent of higher layer protocols
such as RSVP and IP. Independence from RSVP is desirable so that
it can interwork with other reservation protocols such as STII.
Independence from IP is desirable so that it can interwork with
network layer protocols such as IPX, NetBIOS, etc.
- Receiver heterogeneity: Receiver heterogeneity refers to
multicast communication where different receivers request
different levels of service. For example, in a multicast
group with many receivers, it is possible that one of the
receivers desires a lower delay bound than the others. A
better delay bound may be provided by increasing the amount
of resources reserved along the path to that receiver while
leaving the reservations for the other receivers unchanged.
In its most complex form, receiver heterogeneity implies the
ability to simultaneously provide various levels of service as
requested by different receivers. In its simplest form, receiver
heterogeneity will allow a scenario where some of the receivers
use best effort service and those requiring service guarantees
make a reservation. Receiver heterogeneity, especially for the
reserved/best effort scenario, is a very desirable function.
Ghanwani, Pace, Srinivasan Expires October 1997 [Page 4]
Internet Draft Integrated Services Over LANs April 1997
More details on supporting receiver heterogeneity are provided in
Section 6.
- Support for different filter styles: It is desirable to provide
support for the different filter styles defined by RSVP such as
fixed filter, shared explicit and shared wildcard. Some of the
issues with respect to supporting such filter styles in the link
layer domain are examined in Section 6.
- Scalability: The mechanism and protocols should have a low
overhead and should scale to the largest receiver groups likely
to occur within a single link layer domain.
- Path Selection: In source routed LAN technologies such as token
ring/802.5, it may be useful for the mechanism to incorporate the
function of path selection. Using an appropriate path selection
mechanism will optimize utilization of network resources.
4. LAN Topologies and Their Features
As stated earlier, this memo is concerned with specifying a framework
for supporting Integrated Services in LAN technologies such as
ethernet/IEEE 802.3, token ring/IEEE 802.5, and FDDI. The extent
to which service guarantees can be provided by a network depend to
a large degree on the ability to provide the key functions of flow
identification and scheduling in addition to admission control and
policing. This section discusses some of the capabilities of these
LAN technologies and provides a taxonomy of possible topologies
emphasizing the capabilities of each with regard to supporting the
above functions.
For the technologies considered here, the basic topology of a LAN
may be shared, switched half duplex or switched full duplex. In the
shared topology, multiple senders share a single segment. Contention
for media access is resolved using protocols such as CSMA/CD in
ethernet and token passing in token ring and FDDI. Switched half
duplex, is essentially a shared topology with the restriction that
there are only two transmitters contending for resources on any
segment. This topology is fast becoming popular with the need for
increased bandwidth. Finally, in a switched full duplex topology, a
full bandwidth path is available to the transmitter at each end of
the link at all times. Therefore, in this topology, there is no need
for any access control mechanism such as CSMA/CD or token passing as
there is no contention between the transmitters.
Another important element in the discussion of topologies is the
support for multiple traffic classes. Traffic classes provide a
Ghanwani, Pace, Srinivasan Expires October 1997 [Page 5]
Internet Draft Integrated Services Over LANs April 1997
coarse method for isolation between flows and allows the possibility
to easily support scheduling algorithms in order to meet service
requirements. Native ethernet/802.3 does not support multiple
traffic classes. Token ring/802.5 and FDDI on the other hand
provides support for traffic classes. Three bits of the Frame
Control field are used to indicate the Frame Priority which may be
mapped to a traffic class as appropriate. Equally important in
token ring networks are the notions of Reserved Priority and Access
Priority. Reserved Priority relates to the value of priority which
a station uses to reserve the token for the next transmission on
the ring. When a free token is circulating, only a station having
an Access Priority greater than or equal to the Reserved Priority
in the token will be allowed to seize the token for transmission.
More recently, the IEEE 802 Standards Committee has been working on
the a 802.1p, a standard for expedited traffic classes and dynamic
multicast filtering in bridges and switches [1]. The proposed
standard requires a new frame format for ethernet in which three
bits are used for indicating the User Priority which may be mapped
to an appropriate traffic class. Up to eight traffic classes may
be supported. The actual number of traffic classes supported is
an implementation option. Further, the emerging standard does not
specify scheduling algorithms between traffic classes.
Depending on the basic topology used and the ability to support
traffic classes, there are six possible scenarios as follows:
1. Shared topology without traffic classes: This category includes
pure shared media such as ethernet/802.3 networks which are
multi-access technologies with no support for priority signaling
and traffic classes. Shared topology without traffic classes
offers little capability for isolation between reserved and
unreserved flows. No service guarantees can be provided in
this scenario without modification to the basic transmission
mechanisms.
2. Shared topology with traffic classes: This category includes
ethernet/802.3 networks which implement the emerging IEEE
802.1p standard, as well as token ring/802.5 and FDDI networks.
Even with support for traffic classes, shared ethernet can at
best offer loose statistical service guarantees because of the
non-deterministic nature of the CSMA/CD protocol. On the other
hand, better guarantees can be provided on token ring media if
the Frame Priority, Reserved Priority and Access Priority are
used in conjunction with appropriate controls.
3. Switched half duplex topology without traffic classes: This
scenario is a special case of shared topology without traffic
classes where there are only two senders contending for resources
Ghanwani, Pace, Srinivasan Expires October 1997 [Page 6]
Internet Draft Integrated Services Over LANs April 1997
on any segment (a host and a switch or two switches). This
topology provides higher bandwidth per station and fewer
collisions. Due to the use of the CSMA/CD protocol and the lack
of traffic classes, little can be done to isolate flows and
provide scheduling.
4. Switched half duplex topology with traffic classes: This
scenario is a special case of shared topology with priority
but there are now only two senders contending for resources
on any segment. This reduces the contention for resources.
Ethernet/802.3 networks with this topology will likely be
able to support better statistical service guarantees than
the corresponding shared topology. Better guarantees will be
possible for token ring/802.5 media with this topology.
5. Switched full duplex topology without traffic classes: This
scenario includes switched ethernet/802.3 and token ring/802.5
where the access control protocol is no longer used since a full
bandwidth path is available to each transmitter. However, since
traffic classes are not available, it is not possible to isolate
flows for scheduling.
6. Switched full duplex topology with traffic classes: This
category is similar to the above, but traffic classes are
also available. This topology is the most capable in terms of
link layer functions that can be exploited for supporting the
functions of flow separation and scheduling.
There is also the possibility of hybrid topologies where two or more
of the above coexist. For instance, it is possible that within a
single subnet, there are some bridges/switches which support traffic
classes and some which do not. If the flow in question traverses
both kinds of bridges/switches in the network, the least common
denominator will prevail. In other words, as far as that flow is
concerned, the network is of the type corresponding to the least
capable topology that is traversed.
Note that even within the different switched topologies categorized
above, there are likely to be switches having varied capabilities
with respect to providing functions such as receiver heterogeneity
and the ability to dedicate resources such as buffering and
scheduling algorithms for supporting the various Integrated Services.
Future work on service mappings in the ISSLL working group will
elaborate on these issues.
Ghanwani, Pace, Srinivasan Expires October 1997 [Page 7]
Internet Draft Integrated Services Over LANs April 1997
5. Architecture for Supporting Integrated Services in LANs
The functional requirements described in Section 3 will be performed
by an entity which we refer to as the Bandwidth Manager (BM). The BM
is responsible for providing mechanisms for an application or higher
layer protocol to request QoS from the network. For architectural
purposes, the BM consists of the following components.
5.1. Components of the Bandwidth Manager
5.1.1. Requester Module
The Requester Module (RM) resides in every end station in the subnet.
One of its functions is to provide an interface between applications
or higher layer protocols such as RSVP, STII, SNMP, etc. and the BM.
An application can invoke the various functions of the BM by using
the primitives for communication with the RM and providing it with
the appropriate parameters. To initiate a reservation, in the link
layer domain, the following parameters must be passed to the RM: the
service desired (Guaranteed Service or Controlled Load), the traffic
descriptors contained in the TSpec, and an RSpec specifying the
amount of resources to be reserved [8]. More information on these
parameters may be found in the relevant Integrated Services documents
[8,9]. When RSVP is used for signaling at the network layer, this
information is available and needs to be extracted from the RSVP PATH
and RSVP RESV messages (See [7] for details). In addition to these
parameters, the network layer addresses of the end points must be
specified. The RM must then translate the network layer addresses
to link layer addresses and convert the request into an appropriate
format which is understood by other components of the BM responsible
admission control. The RM is also responsible for returning the
status of requests processed by the BM to the invoking application or
higher layer protocol.
5.1.2. Bandwidth Allocator
The Bandwidth Allocator (BA) is responsible for performing admission
control and maintaining state about the allocation of resources
in the subnet. An end station can request various services, e.g.
bandwidth reservation, modification of an existing reservation,
queries about resource availability, etc. These requests are
processed by the BA. The communication between the end station and
the BA takes place through the RM. The location of the BA will
depend largely on the implementation method. In a centralized
implementation, the BA may reside on a single station in the
subnet. In a distributed implementation, the functions of the BA
Ghanwani, Pace, Srinivasan Expires October 1997 [Page 8]
Internet Draft Integrated Services Over LANs April 1997
may be distributed in all the end stations and bridges/switches as
necessary. The BA is also responsible for deciding how to label
flows, e.g. based on the admission control decision, the BA may
indicate to the RM that packets belonging to a particular flow be
tagged with some priority value which maps to the appropriate traffic
class.
5.1.3. Communication Protocols and Primitives
The protocols and primitives for communication between the various
components of the BM must be specified. These include the following:
- Communication between the higher layer protocols and the RM:
The BM must define primitives for the application to initiate
reservations, query the BA about available resources, and
change or delete reservations, etc. These primitives could be
implemented as an API for an application to invoke functions of
the BM via the RM.
- Communication between the RM and the BA: A signaling mechanism
must be defined for the communication between the RM and the BA.
This protocol will specify the messages which must be exchanged
between the RM and the BA in order to service various requests by
the higher layer entity.
- Communication between peer BAs: If there is more than one BA in
the subnet, a means must be specified for inter-BA communication.
Specifically, the BAs must be able to decide among themselves
about which BA would be responsible for which segments and
bridges or switches. Further, if a request is made for resource
reservation along the domain of multiple BAs, the BAs must be
able to handle such a scenario correctly. Inter-BA communication
will also be responsible for back-up and recovery in the event of
failure.
5.2. Implementation Scenarios
Example scenarios are provided showing the location of the the
components of the bandwidth manager in centralized and fully
distributed implementations. Note that in either case, the RM must
be present in all end stations which desire to make reservations.
Essentially, centralized or distributed refers to the implementation
of the BA, the component responsible for resource reservation
and admission control. In the figures below, "App" refers to
the application making use of the BM. It could either be a user
application, or a higher layer protocol process such as RSVP.
Ghanwani, Pace, Srinivasan Expires October 1997 [Page 9]
Internet Draft Integrated Services Over LANs April 1997
+---------+
.-->| BA |<--.
/ +---------+ \
/ .-->| Layer 2 |<--. \
/ / +---------+ \ \
/ / \ \
/ / \ \
+---------+ / / \ \ +---------+
| App |<----- /-/---------------------------\-\----->| App |
+---------+ / / \ \ +---------+
| RM |<----. / \ .--->| RM |
+---------+ / +---------+ +---------+ \ +---------+
| Layer 2 |<------>| Layer 2 |<------>| Layer 2 |<------>| Layer 2 |
+---------+ +---------+ +---------+ +---------+
RSVP Host/ Intermediate Intermediate RSVP Host/
Router Bridge/Switch Bridge/Switch Router
Figure 1: Bandwidth Manager with a centralized Bandwidth Allocator
Figure 1 shows a centralized implementation where a single BA is
responsible for admission control decisions for the entire subnet.
Every end station contains an RM. Intermediate bridges and switches
in the network need not have any functions of the BM since they will
not be actively participating in admission control. The RM at the
end station requesting a reservation initiates communication with
its BA. For larger subnets, a single BA may not be able to handle
the reservations for the entire subnet. In that case it would be
necessary to deploy multiple BAs, each managing the resources of a
non-overlapping subset of segments. In a centralized implementation,
the BA must be able to access topology information such as link layer
spanning tree information in order to be able to reserve resources
on appropriate segments. Without this topology information, the BM
would have to reserve resources on the entire spanning tree for all
flows leading to an inefficient utilization of resources.
Ghanwani, Pace, Srinivasan Expires October 1997 [Page 10]
Internet Draft Integrated Services Over LANs April 1997
+---------+ +---------+
| App |<-------------------------------------------->| App |
+---------+ +---------+ +---------+ +---------+
| RM/BA |<------>| BA |<------>| BA |<------>| RM/BA |
+---------+ +---------+ +---------+ +---------+
| Layer 2 |<------>| Layer 2 |<------>| Layer 2 |<------>| Layer 2 |
+---------+ +---------+ +---------+ +---------+
RSVP Host/ Intermediate Intermediate RSVP Host/
Router Bridge/Switch Bridge/Switch Router
Figure 2: Bandwidth Manager with a fully distributed Bandwidth
Allocator
Figure 2 depicts the scenario of a fully distributed bandwidth
manager. In this case, all devices in the subnet must have some BM
functionality. All the end hosts are still required to have an RM.
In addition, all bridges and switches must actively participate in
admission control. With this approach, the BA would need only local
topology information since each BA is responsible for the resources
on segments that are directly connected to it. This local topology
information, such as which ports are on the spanning tree and
which unicast addresses are reachable from which ports, is readily
available in existing bridges/switches.
Note that in the figures above, the arrows between peer layers are
used to indicate logical connectivity.
5.3. Logical Operation of the BM in End Stations and Link Layer Domain
The figure below shows the location and logical operation of the
BM in end stations and the link layer domain. It is not possible
to provide the details of physical flows because of the inherent
differences that arise in centralized and distributed implementations
as discussed in Section 5.2.
Ghanwani, Pace, Srinivasan Expires October 1997 [Page 11]
Internet Draft Integrated Services Over LANs April 1997
+-------------------------+
| +--------+ +------+ |
| |Appli- <---> RM | |
| | cation | +--^---+ |
| +--------+ | | +-------------------------+
| || +--V---+ | | +------+ |
| || +------| BA <------------------------> BA | |
| || | +------+ | | +----------+ +-^-^|-+ |
| || | | | | |Forwarding| | || |
| || | | | | |Process <---+ || |
| || | | | | +---|------+ || |
| || | | | | | +---------+| |
| \/ | | | | | | | |
| +-----V-+ +--V---+ | | +---V--V+ +----V-+ |
| |Class- | |Sched-| | | |Class- | |Sched-| |
| | ifier |===>| uler |==========>| ifier |===>| uler |====>
| +-------+ +------+ | | +-------+ +------+ |
+-------------------------+ +-------------------------+
End Station Link Layer Domain
----> Signaling/Control
====> Data
Figure 3: The logical Operation of the BM in end stations and the
link layer domain.
The application, which may be RSVP or some other higher layer
reservation protocol requests resources by passing the relevant
parameters to the RM. The RM then starts the process of resource
reservation at the link layer by contacting the local BA. In the
case of a distributed implementation, The local BA is responsible
for admission control on the segment to which the end station is
directly attached. If the reservation succeeds, the local BA sets
up the classifier and scheduler as required so that the appropriate
priority is used for the flow. The request is then propagated
to the the "remote" BA controlling the other segments along the
forwarding path. In this case, it is possible to set up more complex
schedulers as well as policing at the bridges/switches since the
BA, which maintains the state, is co-located in every bridge/switch
and participates actively in the process of admission control. In
a centralized implementation, the BA resides in a server within the
subnet. The classifier and scheduler in the bridges/switches along
the forwarding path are implicitly set up by the priority carried in
the data frames if the reservation is successful.
Ghanwani, Pace, Srinivasan Expires October 1997 [Page 12]
Internet Draft Integrated Services Over LANs April 1997
6. Mapping Issues and Link Layer Support for IntServ Traffic Classes
As stated earlier, the Integrated Services working group has defined
various service classes offering varying degrees of QoS guarantees.
Initial effort will concentrate on enabling the Controlled Load
and Guaranteed Service classes [4,5]. The Controlled Load service
provides a loose guarantee, informally stated as "better than best
effort". The Guaranteed Service provides a delay bound which the
network guarantees will never be exceeded. The extent to which these
services can be supported at the link layer will depend on many
factors including the topology and technology used. Some of the
mapping issues are dicussed below in light of the emerging link layer
standards and the functions supported by higher layer protocols.
Considering the limitations of some of the topologies under
consideration, it may not be possible to satisfy all the requirements
for Integrated Services on a given topology. In such cases, it
is useful to consider providing support for an approximation of
the service which may suffice in most practical instances. For
example, it may not be feasible to provide policing/shaping at each
network element (bridge/switch) as required by the Controlled Load
specification [4]. But if this task is left to the end stations, a
reasonably good approximation to the service can be obtained.
6.1. Mapping of Services to Link Level Priority
The number of traffic classes supported and access methods of
the technology under consideration will determine how many and
what services may be supported. Native token ring/802.5, for
instance, supports eight priority levels which may be mapped to
one or more traffic classes. Ethernet/802.3 has no support for
signaling priorities within frames. However, the IEEE 802 standards
committee is working on a new standard for bridges/switches related
to multimedia traffic expediting and dynamic multicast filtering
[1]. These standards allow for eight levels of User Priority on all
media. The User Priority is signaled on an end-to-end basis, unless
overridden by bridge/switch management.
The priority that is used by a flow should depend on the quality of
service desired and whether the reservation was successful or not.
Therefore, a sender should use the a priority value which maps to
the best effort traffic class until told otherwise by the BM. The BM
will, upon successful completion of resource reservation, specify
the User Priority to be used by the sender for that session's data.
Future work in the ISSLL working group will address the issue of
mapping User Priority to traffic classes in the bridges/switches.
Ghanwani, Pace, Srinivasan Expires October 1997 [Page 13]
Internet Draft Integrated Services Over LANs April 1997
6.2. Supporting Receiver Heterogeneity
Receiver heterogeneity means that receivers within a group can each
have different QoS requirements; i.e. it is possible that, for a
given flow, some receivers make a reservation while others decide
to make use of best effort transport. RSVP allows heterogeneous
receivers within a group. However, handling the problem at layer
2 can be non-trivial. Consider for instance, the scenario in the
figure below.
+-----+
| R1 |
+-----+
|
v
+-----+ +-----+ +-----+
| R2 |<-----| SW |----->| R3 |
+-----+ +-----+ +-----+
Figure 4: An instance of receiver heterogeneity. R1 is the source.
R2 is a receiver which makes a reservation, and R3 is a receiver
which is satisfied with best effort service. SW is a Layer 2 device
(bridge/switch) participating in resource reservation.
In the figure above, R1 is the upstream end station and R2 and R3
are downstream end stations. R2 would like to make a reservation
for the flow while R3 would like to receive the flow using best
effort transport. R1 sends RSVP PATH messages which are multicast
to both R2 and R3. R2 sends an RSVP RESV message to R1 requesting
the reservation of resources. If the reservation is successful at
Layer 2, the frames addressed to the group will be categorized in
the traffic class corresponding to the service requested by R3. At
SW, there must be some mechanism which forwards the packet using
providing service corresponding to the reserved traffic class at the
interface to R3 while using the best effort traffic class at the
interface to R2. This may involve changing the contents of the frame
itself, or ignoring the frame priority at the interface to R2.
Another possibility for supporting heterogeneous receivers would be
to have separate groups with distinct addresses, one for each class
of service. By default, a receiver would join the "best effort"
group where the flow is classified as best effort. If the receiver
makes a reservation successfully, it can be transferred to the group
for the class of service desired. The dynamic multicast filtering
capabilities of bridges and switches implementing the emerging IEEE
802.1p standard would be a very useful feature in such a scenario.
A given flow would be transmitted only on those segments which are
on the path between the sender and the receivers of that flow. The
Ghanwani, Pace, Srinivasan Expires October 1997 [Page 14]
Internet Draft Integrated Services Over LANs April 1997
obvious disadvantage of such an approach is that the sender needs to
send out multiple copies of the same packet corresponding to each
class of service desired.
6.3. Support for Different Reservation Styles
+-----+ +-----+ +-----+
| R1 | | R2 | | R3 |
+-----+ +-----+ +-----+
| | |
| v |
| +-----+ |
+--------->| SW |<---------+
+-----+
| |
+----+ +----+
| |
v V
+-----+ +-----+
| R4 | | R5 |
+-----+ +-----+
Figure 5: An illustration of filter styles. R1, R2, R3, R4 and R5
are RSVP end stations which are members of the same group. SW is a
bridge/switch in the link layer domain.
In the figure above, R1-R5 are end stations which are members of a
group associated with the same RSVP flow. R1, R2 and R3 are upstream
end stations. R4 and R5 are the downstream end stations which
receive traffic from all the senders. RSVP allows receivers R4 and
R5 to specify reservations which can apply to: (a) one specific
sender only (fixed filter); (b) any of two or more explicitly
specified senders (shared explicit filter); and (c) any sender in the
group (shared wildcard filter). Support for the fixed filter style
is straightforward; a separate reservation is made for the traffic
from each of the senders. However, support for the the other two
filter styles has implications regarding policing; i.e. the merged
flow from the different senders must be policed so that they conform
to traffic parameters specified in the filter's RSpec. This scenario
is further complicated if the services requested by R4 and R5 are
different.
7. Summary
This document has specified a framework for providing Integrated
Services over shared and switched LAN technologies. The ability to
Ghanwani, Pace, Srinivasan Expires October 1997 [Page 15]
Internet Draft Integrated Services Over LANs April 1997
provide QoS guarantees necessitates some form of admission control
and resource management. The requirements and goals of a resource
management scheme for subnets have been identified and discussed.
We refer to the entire resource management scheme as a Bandwidth
Manager. Architectural considerations were discussed and examples
were provided to illustrate possible implementations of a Bandwidth
Manager. Some of the issues involved in mapping the services from
higher layers to the link layer have also been discussed.
References
[1] 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/D5, February, 1997.
[2] IEEE Standards for Local and Metropolitan Area Networks:
Draft Standard for Virtual Bridged Local Area Networks,
P802.1Q/D5, February, 1997.
[3] B. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin,
"Resource Reservation Protocol (RSVP) - Version 1 Functional
Specification," Internet Draft, November 1996,
<draft-ietf-rsvp-spec-14.txt>
[4] J. Wroclawski, "Specification of the Controlled Load Network
Element Service," Internet Draft, November 1996,
<draft-ietf-intserv-ctrl-load-svc-04.txt>
[5] S. Shenker, C. Partridge and R. Guerin, "Specification of
Guaranteed Quality of Service," Internet Draft, August 1996,
<draft-ietf-intserv-guaranteed-svc-06.txt>
[6] R. Braden, D. Clark and S. Shenker, "Integrated Services in the
Internet Architecture: An Overview," RFC 1633, June 1994.
[7] J. Wroclawski, "The Use of RSVP with IETF Integrated Services,"
Internet Draft, October 1996, <draft-ietf-intserv-rsvp-use-01.txt>
[8] S. Shenker and J. Wroclawski, "Network Element Service
Specification Template", Internet Draft, November 1995,
<draft-ietf-intserv-svc-template-02.txt>
[9] S. Shenker and J. Wroclawski, "General Characterization Parameters
for Integrated Service Network Elements", Internet Draft,
October 1996, <draft-ietf-intserv-charac-02.txt>
Ghanwani, Pace, Srinivasan Expires October 1997 [Page 16]
Internet Draft Integrated Services Over LANs April 1997
Acknowledgements
Much of the work presented in this document has benefited greatly
from discussion held at the meetings of the Integrated Services over
Specific Link Layers (ISSLL) working group. In particular we would
like to thank Eric Crawley, Don Hoffman, Mick Seaman, Andrew Smith
and Raj Yavatkar who have contributed to this effort via earlier
Internet drafts.
Authors' Address
Anoop Ghanwani
IBM Corporation
P. O. Box 12195
Research Triangle Park, NC 27709
Phone: +1-919-254-0260
Fax: +1-919-254-5410
Email: 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
Email: 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
Email: vijay@raleigh.ibm.com
Ghanwani, Pace, Srinivasan Expires October 1997 [Page 17]
