Request for Comments: 2816 Nortel Networks
Category: Informational W. Pace
IBM
V. Srinivasan
CoSine Communications
A. Smith
Extreme Networks
M. Seaman
Telseon
May 2000
A Framework for Integrated Services
Over Shared and Switched IEEE 802 LAN Technologies
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 (2000). All Rights Reserved.
Abstract
This memo describes a framework for supporting IETF Integrated
Services on shared and switched LAN infrastructure. It includes
background material on the capabilities of IEEE 802 like networks
with regard to parameters that affect Integrated Services such as
access latency, delay variation and queuing support in LAN switches.
It discusses aspects of IETF's Integrated Services model that cannot
easily be accommodated in different LAN environments. It outlines a
functional model for supporting the Resource Reservation Protocol
(RSVP) in such LAN environments. Details of extensions to RSVP for
use over LANs are described in an accompanying memo [14]. Mappings
of the various Integrated Services onto IEEE 802 LANs are described
in another memo [13].
Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Document Outline . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
4. Frame Forwarding in IEEE 802 Networks . . . . . . . . . . 5
4.1. General IEEE 802 Service Model . . . . . . . . . . . 5
4.2. Ethernet/IEEE 802.3 . . . . . . . . . . . . . . . . . 7
4.3. Token Ring/IEEE 802.5 . . . . . . . . . . . . . . . . 8
4.4. Fiber Distributed Data Interface . . . . . . . . . . 10
4.5. Demand Priority/IEEE 802.12 . . . . . . . . . . . . . 10
5. Requirements and Goals . . . . . . . . . . . . . . . . . . 11
5.1. Requirements . . . . . . . . . . . . . . . . . . . . 11
5.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Non-goals . . . . . . . . . . . . . . . . . . . . . . 14
5.4. Assumptions . . . . . . . . . . . . . . . . . . . . . 14
6. Basic Architecture . . . . . . . . . . . . . . . . . . . . 15
6.1. Components . . . . . . . . . . . . . . . . . . . . . 15
6.1.1. Requester Module . . . . . . . . . . . . . . 15
6.1.2. Bandwidth Allocator . . . . . . . . . . . . . 16
6.1.3. Communication Protocols . . . . . . . . . . . 16
6.2. Centralized vs. Distributed Implementations . . . . 17
7. Model of the Bandwidth Manager in a Network . . . . . . . 18
7.1. End Station Model . . . . . . . . . . . . . . . . . . 19
7.1.1. Layer 3 Client Model . . . . . . . . . . . . 19
7.1.2. Requests to Layer 2 ISSLL . . . . . . . . . . 19
7.1.3. At the Layer 3 Sender . . . . . . . . . . . . 20
7.1.4. At the Layer 3 Receiver . . . . . . . . . . . 21
7.2. Switch Model . . . . . . . . . . . . . . . . . . . . 22
7.2.1. Centralized Bandwidth Allocator . . . . . . . 22
7.2.2. Distributed Bandwidth Allocator . . . . . . . 23
7.3. Admission Control . . . . . . . . . . . . . . . . . . 25
7.4. QoS Signaling . . . . . . . . . . . . . . . . . . . . 26
7.4.1. Client Service Definitions . . . . . . . . . 26
7.4.2. Switch Service Definitions . . . . . . . . . 27
8. Implementation Issues . . . . . . . . . . . . . . . . . . 28
8.1. Switch Characteristics . . . . . . . . . . . . . . . 29
8.2. Queuing . . . . . . . . . . . . . . . . . . . . . . . 30
8.3. Mapping of Services to Link Level Priority . . . . . 31
8.4. Re-mapping of Non-conforming Aggregated Flows . . . . 31
8.5. Override of Incoming User Priority . . . . . . . . . 32
8.6. Different Reservation Styles . . . . . . . . . . . . 32
8.7. Receiver Heterogeneity . . . . . . . . . . . . . . . 33
9. Network Topology Scenarios . . . . . . . . . . . . . . . 35
9.1. Full Duplex Switched Networks . . . . . . . . . . . . 36
9.2. Shared Media Ethernet Networks . . . . . . . . . . . 37
9.3. Half Duplex Switched Ethernet Networks . . . . . . . 38
9.4. Half Duplex Switched and Shared Token Ring Networks . 39
9.5. Half Duplex and Shared Demand Priority Networks . . . 40
10. Justification . . . . . . . . . . . . . . . . . . . . . . 42
11. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 43
References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Security Considerations . . . . . . . . . . . . . . . . . . . 45
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 47
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. A framework for meeting these new requirements
was set out in RFC1633 [8] and this has driven the specification of
various classes of network service by the Integrated Services working
group of the IETF, such as Controlled Load and Guaranteed Service
[6,7]. Each of these service classes is designed to provide certain
Quality of Service (QoS) to traffic conforming to a specified set of
parameters. Applications are expected to choose one of these classes
according to their QoS requirements. One mechanism for end stations
to utilize such services in an IP network is provided by a QoS
signaling protocol, the Resource Reservation Protocol (RSVP) [5]
developed by the RSVP working group of the IETF. The IEEE under its
Project 802 has defined standards for many different local area
network technologies. These all typically offer the same MAC layer
datagram service [1] to higher layer protocols such as IP although
they often provide different dynamic behavior characteristics -- it
is these that are important when considering their ability to support
real time services. Later in this memo we describe some of the
relevant characteristics of the different MAC layer LAN technologies.
In addition, IEEE 802 has defined standards for bridging multiple LAN
segments together using devices known as "MAC Bridges" or "Switches"
[2]. Recent work has also defined traffic classes, multicast
filtering, and virtual LAN capabilities for these devices [3,4].
Such LAN technologies often constitute the last hop(s) between users
and the Internet as well as being a primary building block for entire
campus networks. It is therefore necessary to provide standardized
mechanisms for using these technologies to support end-to-end real
time services. In order to do this, there must be some mechanism for
resource management at the data link layer. 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.
2. Document Outline
This document is concerned with specifying a framework for providing
Integrated Services over shared and switched LAN technologies such as
Ethernet/IEEE 802.3, Token Ring/IEEE 802.5, FDDI, etc. We begin in
Section 4 with a discussion of the capabilities of various IEEE 802
MAC layer technologies. Section 5 lists the requirements and goals
for a mechanism capable of providing Integrated Services in a LAN.
The resource management functions outlined in Section 5 are provided
by an entity referred to as a Bandwidth Manager (BM). The
architectural model of the BM is described in Section 6 and its
various components are discussed in Section 7. Some implementation
issues with respect to link layer support for Integrated Services are
examined in Section 8. Section 9 discusses 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. This framework makes no assumptions about the 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.
3. Definitions
The following is a list of terms used in this and other ISSLL
documents.
- Link Layer or Layer 2 or L2: Data link layer technologies such as
Ethernet/IEEE 802.3 and Token Ring/IEEE 802.5 are referred to as
Layer 2 or L2.
- Link Layer Domain or Layer 2 Domain or L2 Domain: Refers to a set
of nodes and links interconnected without passing through a L3
forwarding function. One or more IP subnets can be overlaid on a
L2 domain.
- Layer 2 or L2 Devices: Devices that only implement Layer 2
functionality as Layer 2 or L2 devices. These include IEEE 802.1D
[2] bridges or switches.
- Internetwork Layer or Layer 3 or L3: Refers to Layer 3 of the ISO
OSI model. This memo is primarily concerned with networks that
use the Internet Protocol (IP) at this layer.
- Layer 3 Device or L3 Device or End Station: These include hosts
and routers that use L3 and higher layer protocols or application
programs that need to make resource reservations.
- Segment: A physical L2 segment that is shared by one or more
senders. Examples of segments include: (a) a shared Ethernet or
Token Ring wire resolving contention for media access using CSMA
or token passing; (b) a half duplex link between two stations or
switches; (c) one direction of a switched full duplex link.
- Managed Segment: A managed segment is a segment with a DSBM
(designated subnet bandwidth manager, see [14]) present and
responsible for exercising admission control over requests for
resource reservation. A managed segment includes those
interconnected parts of a shared LAN that are not separated by
DSBMs.
- Traffic Class: Refers to an aggregation of data flows which are
given similar service within a switched network.
- Subnet: Used in this memo to indicate a group of L3 devices
sharing a common L3 network address prefix along with the set of
segments making up the L2 domain in which they are located.
- Bridge/Switch: A Layer 2 forwarding device as defined by IEEE
802.1D [2]. The terms bridge and switch are used synonymously in
this memo.
4. Frame Forwarding in IEEE 802 Networks
4.1. General IEEE 802 Service Model
The user_priority is a value associated with the transmission and
reception of all frames in the IEEE 802 service model. It is
supplied by the sender that is using the MAC service and is provided
along with the data to a receiver using the MAC service. It may or
may not be actually carried over the network. Token Ring/IEEE 802.5
carries this value encoded in its FC octet while basic Ethernet/IEEE
802.3 does not carry it. IEEE 802.12 may or may not carry it
depending on the frame format in use. When the frame format in use
is IEEE 802.5, the user_priority is carried explicitly. When IEEE
802.3 frame format is used, only the two levels of priority
(high/low) that are used to determine access priority can be
recovered. This is based on the value of priority encoded in the
start delimiter of the IEEE 802.3 frame.
NOTE: The original IEEE 802.1D standard [2] contains the
specifications for the operation of MAC bridges. This has recently
been extended to include support for traffic classes and dynamic
multicast filtering [3]. In this document, the reader should be
aware that references to the IEEE 802.1D standard refer to [3],
unless explicitly noted otherwise.
IEEE 802.1D [3] defines a consistent way for carrying the value of
the user_priority over a bridged network consisting of Ethernet,
Token Ring, Demand Priority, FDDI or other MAC layer media using an
extended frame format. The usage of user_priority is summarized
below. We refer the interested reader to the IEEE 802.1D
specification for further information.
If the user_priority is carried explicitly in packets, its utility is
as a simple label enabling packets within a data stream in different
classes to be discriminated easily by downstream nodes without having
to parse the packet in more detail.
Apart from making the job of desktop or wiring closet switches
easier, an explicit field means they do not have to change hardware
or software as the rules for classifying packets evolve; e.g. based
on new protocols or new policies. More sophisticated Layer 3
switches, perhaps deployed in the core of a network, may be able to
provide added value by performing packet classification more
accurately and, hence, utilizing network resources more efficiently
and providing better isolation between flows. This appears to be a
good economic choice since there are likely to be very many more
desktop/wiring closet switches in a network than switches requiring
Layer 3 functionality.
The IEEE 802 specifications make no assumptions about how
user_priority is to be used by end stations or by the network.
Although IEEE 802.1D defines static priority queuing as the default
mode of operation of switches that implement multiple queues, the
user_priority is really a priority only in a loose sense since it
depends on the number of traffic classes actually implemented by a
switch. The user_priority is defined as a 3 bit quantity with a
value of 7 representing the highest priority and a value of 0 as the
lowest. The general switch algorithm is as follows. Packets are
queued within a particular traffic class based on the received
user_priority, the value of which is either obtained directly from
the packet if an IEEE 802.1Q header or IEEE 802.5 network is used, or
is assigned according to some local policy. The queue is selected
based on a mapping from user_priority (0 through 7) onto the number
of available traffic classes. A switch may implement one or more
traffic classes. The advertised IntServ parameters and the switch's
admission control behavior may be used to determine the mapping from
user_priority to traffic classes within the switch. A switch is not
precluded from implementing other scheduling algorithms such as
weighted fair queuing and round robin.
IEEE 802.1D makes no recommendations about how a sender should select
the value for user_priority. One of the primary purposes of this
document is to propose such usage rules, and to discuss the
communication of the semantics of these values between switches and
end stations. In the remainder of this document we use the term
traffic class synonymously with user_priority.
4.2. Ethernet/IEEE 802.3
There is no explicit traffic class or user_priority field carried in
Ethernet packets. This means that user_priority must be regenerated
at a downstream receiver or switch according to some defaults or by
parsing further into higher layer protocol fields in the packet.
Alternatively, IEEE 802.1Q encapsulation [4] may be used which
provides an explicit user_priority field on top of the basic MAC
frame format.
For the different IP packet encapsulations used over Ethernet/IEEE
802.3, it will be necessary to adjust any admission control
calculations according to the framing and padding requirements as
shown in Table 1. Here, "ip_len" refers to the length of the IP
packet including its headers.
Table 1: Ethernet encapsulations
---------------------------------------------------------------
Encapsulation Framing Overhead IP MTU
bytes/pkt bytes
---------------------------------------------------------------
IP EtherType (ip_len<=46 bytes) 64-ip_len 1500
(1500>=ip_len>=46 bytes) 18 1500
IP EtherType over 802.1D/Q (ip_len<=42) 64-ip_len 1500*
(1500>=ip_len>=42 bytes) 22 1500*
IP EtherType over LLC/SNAP (ip_len<=40) 64-ip_len 1492
(1500>=ip_len>=40 bytes) 24 1492
---------------------------------------------------------------
*Note that the packet length of an Ethernet frame using the IEEE
802.1Q specification exceeds the current IEEE 802.3 maximum packet
length values by 4 bytes. The change of maximum MTU size for IEEE
802.1Q frames is being accommodated by IEEE 802.3ac [21].
4.3. Token Ring/IEEE 802.5
The Token Ring standard [6] 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 a LLC
frame, the User Priority bits, are obtained from the higher layer in
the user_priority parameter when it requests transmission of a
packet. This parameter also establishes the Access Priority used by
the MAC. The user_priority value is conveyed end-to-end by the User
Priority bits in the FC field and is typically preserved through
Token Ring bridges of all types. In all cases, 0 is the lowest
priority.
Token Ring also uses a concept of Reserved Priority which relates to
the value of priority which a station uses to reserve the token for
its 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. Readers are referred to [14] for further discussion of
this topic.
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
recommends that stations send/relay frames as follows.
Table 2: Recommended use of Token Ring User Priority
-------------------------------------
Application User Priority
-------------------------------------
Non-time-critical data 0
- 1
- 2
- 3
LAN management 4
Time-sensitive data 5
Real-time-critical data 6
MAC frames 7
-------------------------------------
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 is 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_priority greater than 4 with a
reservation equal to the user_priority (although IEEE 802.1D [3]
permits network management override this behavior). The capabilities
provided by the Token Ring architecture, such User Priority and
Reserved Priority, can provide effective support for Integrated
Services flows that require QoS guarantees.
For the different IP packet encapsulations used over Token Ring/IEEE
802.5, it will be necessary to adjust any admission control
calculations according to the framing requirements as shown in Table
3.
Table 3: Token Ring encapsulations
---------------------------------------------------------------
Encapsulation Framing Overhead IP MTU
bytes/pkt bytes
---------------------------------------------------------------
IP EtherType over 802.1D/Q 29 4370*
IP EtherType over LLC/SNAP 25 4370*
---------------------------------------------------------------
*The suggested MTU from RFC1042 [13] is 4464 bytes but there are
issues related to discovering the maximum supported MTU between any
two points both within and between Token Ring subnets. The MTU
reported here is consistent with the IEEE 802.5 Annex I
recommendation.
4.4. Fiber Distributed Data Interface
The Fiber Distributed Data Interface (FDDI) standard [16] 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 similar
mechanisms to Token Ring described above. The standard also makes
provision for "Synchronous" data traffic with strict media access and
delay guarantees. This mode of operation is not discussed further
here and represents area within the scope of the ISSLL working group
that requires further work. In the remainder of this document, for
the discussion of QoS mechanisms, FDDI is treated as a 100 Mbps Token
Ring technology using a service interface compatible with IEEE 802
networks.
4.5. Demand Priority/IEEE 802.12
IEEE 802.12 [19] is a standard for a shared 100 Mbps LAN. Data
packets are transmitted using either the IEEE 802.3 or IEEE 802.5
frame format. The MAC protocol is called Demand Priority. Its main
characteristics with respect to QoS are the support of two service
priority levels, normal priority and high priority, and the order of
service for each of these. Data packets from all network nodes (end
hosts and bridges/switches) are served using a simple round robin
algorithm.
If the IEEE 802.3 frame format is used for data transmission then the
user_priority is encoded in the starting delimiter of the IEEE 802.12
data packet. If the IEEE 802.5 frame format is used then the
user_priority is additionally encoded in the YYY bits of the FC field
in the IEEE 802.5 packet header (see also Section 4.3). Furthermore,
the IEEE 802.1Q encapsulation with its own user_priority field may
also be applied in IEEE 802.12 networks. In all cases, switches are
able to recover any user_priority supplied by a sender.
The same rules apply for IEEE 802.12 user_priority mapping in a
bridge as with other media types. The only additional information is
that normal priority is used by default for user_priority values 0
through 4 inclusive, and high priority is used for user_priority
levels 5 through 7. This ensures that the default Token Ring
user_priority level of 4 for IEEE 802.5 bridges is mapped to normal
priority on IEEE 802.12 segments.
The medium access in IEEE 802.12 LANs is deterministic. The Demand
Priority mechanism ensures that, once the normal priority service has
been preempted, all high priority packets have strict priority over
packets with normal priority. In the event that a normal priority
packet has been waiting at the head of line of a MAC transmit queue
for a time period longer than PACKET_PROMOTION (200 - 300 ms) [19],
its priority is automatically promoted to high priority. Thus, even
normal priority packets have a maximum guaranteed access time to the
medium.
Integrated Services can be built on top of the IEEE 802.12 medium
access mechanism. When combined with admission control and bandwidth
enforcement mechanisms, delay guarantees as required for a Guaranteed
Service can be provided without any changes to the existing IEEE
802.12 MAC protocol.
Since the IEEE 802.12 standard supports the IEEE 802.3 and IEEE 802.5
frame formats, the same framing overhead as reported in Sections 4.2
and 4.3 must be considered in the admission control computations for
IEEE 802.12 links.
5. 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
Integrated Services and RSVP.
5.1. Requirements
- Resource Reservation: The mechanism must be capable of reserving
resources on a single segment or multiple segments and at
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 services such as Guaranteed Service, Controlled Load,
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.
- Policing/Shaping: Traffic must be shaped and/or policed by end
stations (workstations, routers) to ensure conformance to
negotiated traffic parameters. Shaping is the recommended
behavior for traffic sources. A router initiating an ISSLL
session must have implemented traffic control mechanisms according
to the IntServ requirements which would ensure that all flows sent
by the router are in conformance. The ISSLL mechanisms at the
link layer rely heavily on the correct implementation of
policing/shaping mechanisms at higher layers by devices capable of
doing so. This is necessary because bridges and switches are not
typically capable of maintaining per flow state which would be
required to check flows for conformance. Policing is left as an
option for bridges and switches, which if implemented, may be used
to enforce tighter control over traffic flows. This issue is
further discussed in Section 8.
- Soft State: The mechanism must maintain soft state information
about the reservations. This means that state information must
periodically be refreshed if the reservation is to be maintained;
otherwise the state information and corresponding reservations
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 end stations 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 more than one entity, each managing
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 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.
- 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.
- 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.
5.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 ST2 [10].
Independence from IP is desirable so that it can interwork with
other network layer protocols such as IPX, NetBIOS, etc.
- Receiver heterogeneity: this 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. More details on supporting receiver heterogeneity are
provided in Section 8.
- 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 wildcard. Some of the issues
with respect to supporting such filter styles in the link layer
domain are examined in Section 8.
- Path Selection: In source routed LAN technologies such as Token
Ring/IEEE 802.5, it may be useful for the mechanism to incorporate
the function of path selection. Using an appropriate path
selection mechanism may optimize utilization of network resources.
5.3. Non-goals
This document describes service mappings onto existing IEEE and ANSI
defined standard MAC layers and uses standard MAC layer services as
in IEEE 802.1 bridging. It does not attempt to make use of or
describe the capabilities of other proprietary or standard MAC layer
protocols although it should be noted that published work regarding
MAC layers suitable for QoS mappings exists. These are outside the
scope of the ISSLL working group charter.
5.4. Assumptions
This framework assumes that typical subnetworks that are concerned
about QoS will be "switch rich"; i.e. most communication between end
stations using integrated services support is expected to pass
through at least one switch. The mechanisms and protocols described
will be trivially extensible to communicating systems on the same
shared medium, but it is important not to allow problem
generalization which may complicate the targeted practical
application to switch rich LAN topologies. There have also been
developments in the area of MAC enhancements to ensure delay
deterministic access on network links e.g. IEEE 802.12 [19] and also
proprietary schemes.
Although we illustrate most examples for this model using RSVP as the
upper layer QoS signaling protocol, there are actually no real
dependencies on this protocol. RSVP could be replaced by some other
dynamic protocol, or the requests could be made by network management
or other policy entities. The SBM signaling protocol [14], which is
based upon RSVP, is designed to work seamlessly in the architecture
described in this memo.
There may be a heterogeneous mix of switches with different
capabilities, all compliant with IEEE 802.1D [2,3], but implementing
varied queuing and forwarding mechanisms ranging from simple systems
with two queues per port and static priority scheduling, to more
complex systems with multiple queues using WFQ or other algorithms.
The problem is decomposed into smaller independent parts which may
lead to sub-optimal use of the network resources but we contend that
such benefits are often equivalent to very small improvement in
network efficiency in a LAN environment. Therefore, it is a goal
that the switches in a network operate using a much simpler set of
information than the RSVP engine in a router. In particular, it is
assumed that such switches do not need to implement per flow queuing
and policing (although they are not precluded from doing so).
A fundamental assumption of the IntServ model is that flows are
isolated from each other throughout their transit across a network.
Intermediate queuing nodes are expected to shape or police the
traffic to ensure conformance to the negotiated traffic flow
specification. In the architecture proposed here for mapping to
Layer 2, we diverge from that assumption in the interest of
simplicity. The policing/shaping functions are assumed to be
implemented in end stations. In some LAN environments, it is
reasonable to assume that end stations are trusted to adhere to their
negotiated contracts at the inputs to the network, and that we can
afford to over-allocate resources during admission control to
compensate for the inevitable packet jitter/bunching introduced by
the switched network itself. This divergence has some implications
on the types of receiver heterogeneity that can be supported and the
statistical multiplexing gains that may be exploited, especially for
Controlled Load flows. This is discussed in Section 8.7 of this
document.
6. Basic Architecture
The functional requirements described in Section 5 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.
6.1. Components
6.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, ST2, 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 [9]. More information on these
parameters may be found in the relevant Integrated Services documents
[6,7,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 [5] 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.
6.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 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.
6.1.3. Communication Protocols
The protocols for communication between the various components of the
BM system 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, change
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.
6.2. Centralized vs. Distributed Implementations
Example scenarios are provided showing the location of 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 that need 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.
+---------+
.-->| 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 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 a 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 have some knowledge of the Layer 2 topology of the subnet
e.g., 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 all segments
for all flows which, in a switched network, would lead to very
inefficient utilization of resources.
+---------+ +---------+
| 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 fully
distributed Bandwidth Allocator
Figure 2 depicts the scenario of a fully distributed bandwidth
manager. In this case, all devices in the subnet have BM
functionality. All the end hosts are still required to have a RM. In
addition, all stations actively participate in admission control.
With this approach, each BA would need only local topology
information since it is responsible for the resources on segments
that are directly connected to it. This local topology information,
such as a list of ports active on the spanning tree and which unicast
addresses are reachable from which ports, is readily available in
today's switches. Note that in the figures above, the arrows between
peer layers are used to indicate logical connectivity.
7. Model of the Bandwidth Manager in a Network
In this section we describe how the model above fits with the
existing IETF Integrated Services model of IP hosts and routers.
First, we describe Layer 3 host and router implementations. Next, we
describe how the model is applied in Layer 2 switches. Throughout we
indicate any differences between centralized and distributed
implementations. Occasional references are made to terminology from
the Subnet Bandwidth Manager specification [14].
7.1. End Station Model
7.1.1. Layer 3 Client Model
We assume the same client model as IntServ and RSVP where we use the
term "client" to mean the entity handling QoS in the Layer 3 device
at each end of a Layer 2 Domain. In this model, the sending client
is responsible for local admission control and packet scheduling onto
its link in accordance with the negotiated service. As with the
IntServ model, this involves per flow scheduling with possible
traffic shaping/policing in every such originating node.
For now, we assume that the client runs an RSVP process which
presents a session establishment interface to applications, provides
signaling over the network, programs a scheduler and classifier in
the driver, and interfaces to a policy control module. In
particular, RSVP also interfaces to a local admission control module
which is the focus of this section.
The following figure, reproduced from the RSVP specification, depicts
the RSVP process in sending hosts.
+-----------------------------+
| +-------+ +-------+ | RSVP
| |Appli- | | RSVP <------------------->
| | cation<--> | |
| | | |process| +-----+|
| +-+-----+ | +->Polcy||
| | +--+--+-+ |Cntrl||
| |data | | +-----+|
|===|===========|==|==========|
| | +--------+ | +-----+|
| | | | +--->Admis||
| +-V--V-+ +---V----+ |Cntrl||
| |Class-| | Packet | +-----+|
| | ifier|==>Schedulr|===================>
| +------+ +--------+ | data
+-----------------------------+
Figure 3: RSVP in Sending Hosts
7.1.2. Requests to Layer 2 ISSLL
The local admission control entity within a client is responsible for
mapping Layer 3 session establishment requests into Layer 2
semantics.
The upper layer entity makes a request, in generalized terms to ISSLL
of the form:
"May I reserve for traffic with <traffic characteristic> with
<performance requirements> from <here> to <there> and how should I
label it?"
where
<traffic characteristic> = Sender Tspec (e.g. bandwidth, burstiness,
MTU)
<performance requirements> = FlowSpec (e.g. latency, jitter bounds)
<here> = IP address(es)
<there> = IP address(es) - may be multicast
7.1.3. At the Layer 3 Sender
The ISSLL functionality in the sender is illustrated in Figure 4.
The functions of the Requester Module may be summarized as follows:
- Maps the endpoints of the conversation to Layer 2 addresses in the
LAN, so that the client can determine what traffic is going where.
This function probably makes reference to the ARP protocol cache
for unicast or performs an algorithmic mapping for multicast
destinations.
- Communicates with any local Bandwidth Allocator module for local
admission control decisions.
- Formats a SBM request to the network with the mapped addresses and
flow/filter specs.
- Receives a response from the network and reports the admission
control decision to the higher layer entity, along with any
negotiated modifications to the session parameters.
- Saves any returned user_priority to be associated with this
session in a "802 header" table. This will be used when
constructing the Layer 2 headers for future data packets belonging
to this session. This table might, for example, be indexed by the
RSVP flow identifier.
from IP from RSVP
+----|------------|------------+
| +--V----+ +---V---+ |
| | Addr <---> | | SBM signaling
| |mapping| |Request|<----------------------->
| +---+---+ |Module | |
| | | | |
| +---+---+ | | |
| | 802 <---> | |
| | header| +-+-+-+-+ |
| +--+----+ / | | |
| | / | | +-----+ |
| | +-----+ | +->|Band-| |
| | | | |width| |
| +--V-V-+ +-----V--+ |Alloc| |
| |Class-| | Packet | +-----+ |
| | ifier|==>Schedulr|=========================>
| +------+ +--------+ | data
+------------------------------+
Figure 4: ISSLL in a Sending End Station
The Bandwidth Allocator (BA) component is only present when a
distributed BA model is implemented. When present, its function is
basically to apply local admission control for the outgoing link
bandwidth and driver's queuing resources.
7.1.4. At the Layer 3 Receiver
The ISSLL functionality in the receiver is simpler and is illustrated
in Figure 5.
The functions of the Requester Module may be summarized as follows:
- Handles any received SBM protocol indications.
- Communicates with any local BA for local admission control
decisions.
- Passes indications up to RSVP if OK.
- Accepts confirmations from RSVP and relays them back via SBM
signaling towards the requester.
to RSVP to IP
^ ^
+----|------------|------+
| +--+----+ | |
SBM signaling | |Request| +---+---+ |
<-------------> |Module | | Strip | |
| +--+---++ |802 hdr| |
| | \ +---^---+ |
| +--v----+\ | |
| | Band- | \ | |
| | width| \ | |
| | Alloc | . | |
| +-------+ | | |
| +------+ +v---+----+ |
data | |Class-| | Packet | |
<==============>| ifier|==>|Scheduler| |
| +------+ +---------+ |
+------------------------+
Figure 5: ISSLL in a Receiving End Station
- May program a receive classifier and scheduler, if used, to
identify traffic classes of received packets and accord them
appropriate treatment e.g., reservation of buffers for particular
traffic classes.
- Programs the receiver to strip away link layer header information
from received packets.
The Bandwidth Allocator, present only in a distributed implementation
applies local admission control to see if a request can be supported
with appropriate local receive resources.
7.2. Switch Model
7.2.1. Centralized Bandwidth Allocator