Where a centralized Bandwidth Allocator model is implemented,
switches do not take part in the admission control process.
Admission control is implemented by a centralized BA, e.g., a "Subnet
Bandwidth Manager" (SBM) as described in [14]. This centralized BA
may actually be co-located with a switch but its functions would not
necessarily then be closely tied with the switch's forwarding
functions as is the case with the distributed BA described below.
7.2.2. Distributed Bandwidth Allocator
The model of Layer 2 switch behavior described here uses the
terminology of the SBM protocol as an example of an admission control
protocol. The model is equally applicable when other mechanisms,
e.g. static configuration or network management, are in use for
admission control. We define the following entities within the
switch:
- Local Admission Control Module: One of these on each port
accounts for the available bandwidth on the link attached to that
port. For half duplex links, this involves taking account of the
resources allocated to both transmit and receive flows. For full
duplex links, the input port accountant's task is trivial.
- Input SBM Module: One instance on each port performs the
"network" side of the signaling protocol for peering with clients
or other switches. It also holds knowledge about the mappings of
IntServ classes to user_priority.
- SBM Propagation Module: Relays requests that have passed
admission control at the input port to the relevant output ports'
SBM modules. This will require access to the switch's forwarding
table (Layer-2 "routing table" cf. RSVP model) and port spanning
tree state.
- Output SBM Module: Forwards requests to the next Layer 2 or Layer
3 hop.
- Classifier, Queue and Scheduler Module: The functions of this
module are basically as described by the Forwarding Process of
IEEE 802.1D (see Section 3.7 of [3]). The Classifier module
identifies the relevant QoS information from incoming packets and
uses this, together with the normal bridge forwarding database, to
decide at which output port and traffic class to enqueue the
packet. Different types of switches will use different techniques
for flow identification (see Section 8.1). In IEEE 802.1D
switches this information is the regenerated user_priority
parameter which has already been decoded by the receiving MAC
service and potentially remapped by the forwarding process (see
Section 3.7.3 of [3]). This does not preclude more sophisticated
classification rules such as the classification of individual
IntServ flows. The Queue and Scheduler implement the
output queues for ports and provide the algorithm for servicing
the queues for transmission onto the output link in order to
provide the promised IntServ service. Switches will implement one
or more output queues per port and all will implement at least a
basic static priority dequeuing algorithm as their default, in
accordance with IEEE 802.1D.
- Ingress Traffic Class Mapping and Policing Module: Its functions
are as described in IEEE 802.1D Section 3.7. This optional module
may police the data within traffic classes for conformance to the
negotiated parameters, and may discard packets or re-map the
user_priority. The default behavior is to pass things through
unchanged.
- Egress Traffic Class Mapping Module: Its functions are as
described in IEEE 802.1D Section 3.7. This optional module may
perform re-mapping of traffic classes on a per output port basis.
The default behavior is to pass things through unchanged.
Figure 6 shows all of the modules in an ISSLL enabled switch. The
ISSLL model is a superset of the IEEE 802.1D bridge model.
+-------------------------------+
SBM signaling | +-----+ +------+ +------+ | SBM signaling
<------------------>| IN |<->| SBM |<->| OUT |<---------------->
| | SBM | | prop.| | SBM | |
| +-++--+ +---^--+ /----+-+ |
| / | | / | |
______________| / | | | | +-------------+
| \ /+--V--+ | | +--V--+ / |
| \ ____/ |Local| | | |Local| / |
| \ / |Admis| | | |Admis| / |
| \/ |Cntrl| | | |Cntrl| / |
| +-----V+\ +-----+ | | +-----+ /+-----+ |
| |traff | \ +---+--+ +V-------+ / |egrss| |
| |class | \ |Filter| |Queue & | / |traff| |
| |map & |=====|==========>|Data- |=| Packet |=|===>|class| |
| |police| | | base| |Schedule| | |map | |
| +------+ | +------+ +--------+ | +-+---+ |
+----^---------+-------------------------------+------|------+
data in | |data out
========+ +========>
Figure 6: ISSLL in a Switch
7.3. Admission Control
On receipt of an admission control request, a switch performs the
following actions, again using SBM as an example. The behavior is
different depending on whether the "Designated SBM" for this segment
is within this switch or not. See [14] for a more detailed
specification of the DSBM/SBM actions.
- If the ingress SBM is the "Designated SBM" for this link, it
either translates any received user_priority or selects a Layer 2
traffic class which appears compatible with the request and whose
use does not violate any administrative policies in force. In
effect, it matches the requested service with the available
traffic classes and chooses the "best" one. It ensures that, if
this reservation is successful, the value of user_priority
corresponding to that traffic class is passed back to the client.
- The ingress DSBM observes the current state of allocation of
resources on the input port/link and then determines whether the
new resource allocation from the mapped traffic class can be
accommodated. The request is passed to the reservation propagator
if accepted.
- If the ingress SBM is not the "Designated SBM" for this link then
it directly passes the request on to the reservation propagator.
- The reservation propagator relays the request to the bandwidth
accountants on each of the switch's outbound links to which this
reservation would apply. This implies an interface to
routing/forwarding database.
- The egress bandwidth accountant observes the current state of
allocation of queuing resources on its outbound port and bandwidth
on the link itself and determines whether the new allocation can
be accommodated. Note that this is only a local decision at this
switch hop; further Layer 2 hops through the network may veto the
request as it passes along.
- The request, if accepted by this switch, is propagated on each
output link selected. Any user_priority described in the
forwarded request must be translated according to any egress
mapping table.
- If accepted, the switch must notify the client of the
user_priority to be used for packets belonging to that flow.
Again, this is an optimistic approach assuming that admission
control succeeds; downstream switches may refuse the request.
- If this switch wishes to reject the request, it can do so by
notifying the client that originated the request by means of its
Layer 2 address.
7.4. QoS Signaling
The mechanisms described in this document make use of a signaling
protocol for devices to communicate their admission control requests
across the network. The service definitions to be provided by such a
protocol e.g. [14] are described below. We illustrate the
primitives and information that need to be exchanged with such a
signaling protocol entity. In all of the examples, appropriate
delete/cleanup mechanisms will also have to be provided for tearing
down established sessions.
7.4.1. Client Service Definitions
The following interfaces can be identified from Figures 4 and 5.
- SBM <-> Address Mapping
This is a simple lookup function which may require ARP protocol
interactions or an algorithmic mapping. The Layer 2 addresses are
needed by SBM for inclusion in its signaling messages to avoid
requiring that switches participating in the signaling have Layer
3 information to perform the mapping.
l2_addr = map_address( ip_addr )
- SBM <-> Session/Link Layer Header
This is for notifying the transmit path of how to add Layer 2
header information, e.g. user_priority values to the traffic of
each outgoing flow. The transmit path will provide the
user_priority value when it requests a MAC layer transmit
operation for each packet. The user_priority is one of the
parameters passed in the packet transmit primitive defined by the
IEEE 802 service model.
bind_l2_header( flow_id, user_priority )
- SBM <-> Classifier/Scheduler
This is for notifying transmit classifier/scheduler of any
additional Layer 2 information associated with scheduling the
transmission of a packet flow. This primitive may be unused in
some implementations or it may be used, for example, to provide
information to a transmit scheduler that is performing per traffic
class scheduling in addition to the per flow scheduling required
by IntServ; the Layer 2 header may be a pattern (in addition to
the FilterSpec) to be used to identify the flow's traffic.
bind_l2schedulerinfo( flow_id, , l2_header, traffic_class )
- SBM <-> Local Admission Control
This is used for applying local admission control for a session
e.g. is there enough transmit bandwidth still uncommitted for
this new session? Are there sufficient receive buffers? This
should commit the necessary resources if it succeeds. It will be
necessary to release these resources at a later stage if the
admission control fails at a subsequent node. This call would be
made, for example, by a segment's Designated SBM.
status = admit_l2session( flow_id, Tspec, FlowSpec )
- SBM <-> RSVP
This is outlined above in Section 7.1.2 and fully described in
[14].
- Management Interfaces
Some or all of the modules described by this model will also
require configuration management. It is expected that details of
the manageable objects will be specified by future work in the
ISSLL WG.
7.4.2. Switch Service Definitions
The following interfaces are identified from Figure 6.
- SBM <-> Classifier
This is for notifying the receive classifier of how to match
incoming Layer 2 information with the associated traffic class.
It may in some cases consist of a set of read only default
mappings.
bind_l2classifierinfo( flow_id, l2_header, traffic_class )
- SBM <-> Queue and Packet Scheduler
This is for notifying transmit scheduler of additional Layer 2
information associated with a given traffic class. It may be
unused in some cases (see discussion in previous section).
bind_l2schedulerinfo( flow_id, l2_header, traffic_class )
- SBM <-> Local Admission Control
Same as for the host discussed above.
- SBM <-> Traffic Class Map and Police
Optional configuration of any user_priority remapping that might
be implemented on ingress to and egress from the ports of a
switch. For IEEE 802.1D switches, it is likely that these
mappings will have to be consistent across all ports.
bind_l2ingressprimap( inport, in_user_pri, internal_priority )
bind_l2egressprimap( outport, internal_priority, out_user_pri )
Optional configuration of any Layer 2 policing function to be
applied on a per class basis to traffic matching the Layer 2
header. If the switch is capable of per flow policing then
existing IntServ/RSVP models will provide a service definition for
that configuration.
bind_l2policing( flow_id, l2_header, Tspec, FlowSpec )
- SBM <-> Filtering Database
SBM propagation rules need access to the Layer 2 forwarding
database to determine where to forward SBM messages. This is
analogous to RSRR interface in Layer 3 RSVP.
output_portlist = lookup_l2dest( l2_addr )
- Management Interfaces
Some or all of the modules described by this model will also
require configuration management. It is expected that details of
the manageable objects will be specified by future work in the
ISSLL working group.
8. Implementation Issues
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 [6]
and Guaranteed Service classes [7]. The Controlled Load service
provides a loose guarantee, informally stated as "the same as best
effort would be on an unloaded network". The Guaranteed Service
provides an upper bound on the transit delay of any packet. 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 discussed 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, 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. But if this task is left to the end stations, a
reasonably good approximation to the service can be obtained.
8.1. Switch Characteristics
There are many LAN bridges/switches with varied capabilities for
supporting QoS. We discuss below the various kinds of devices that
that one may expect to find in a LAN environment.
The most basic bridge is one which conforms to the IEEE 802.1D
specification of 1993 [2]. This device has a single queue per output
port, and uses the spanning tree algorithm to eliminate topology
loops. Networks constructed from this kind of device cannot be
expected to provide service guarantees of any kind because of the
complete lack of traffic isolation.
The next level of bridges/switches are those which conform to the
more recently revised IEEE 802.1D specification [3]. They include
support for queuing up to eight traffic classes separately. The level
of traffic isolation provided is coarse because all flows
corresponding to a particular traffic class are aggregated. Further,
it is likely that more than one priority will map to a traffic class
depending on the number of queues implemented in the switch. It
would be difficult for such a device to offer protection against
misbehaving flows. The scope of multicast traffic may be limited by
using GMRP to only those segments which are on the path to interested
receivers.
A next step above these devices are bridges/switches which implement
optional parts of the IEEE 802.1D specification such as mapping the
received user_priority to some internal set of canonical values on a
per-input-port basis. It may also support the mapping of these
internal canonical values onto transmitted user_priority on a per-
output-port basis. With these extra capabilities, network
administrators can perform mapping of traffic classes between
specific pairs of ports, and in doing so gain more control over
admission of traffic into the protected classes.
Other entirely optional features that some bridges/switches may
support include classification of IntServ flows using fields in the
network layer header, per-flow policing and/or reshaping which is
essential for supporting Guaranteed Service, and more sophisticated
scheduling algorithms such as variants of weighted fair queuing to
limit the bandwidth consumed by a traffic class. Note that it is
advantageous to perform flow isolation and for all network elements
to police each flow in order to support the Controlled Load and
Guaranteed Service.
8.2. Queuing
Connectionless packet networks in general, and LANs in particular,
work today because of scaling choices in network provisioning.
Typically, excess bandwidth and buffering is provisioned in the
network to absorb the traffic sourced by higher layer protocols,
often sufficient to cause their transmission windows to run out on a
statistical basis, so that network overloads are rare and transient
and the expected loading is very low.
With the advent of time-critical traffic such over-provisioning has
become far less easy to achieve. Time-critical frames may be queued
for annoyingly long periods of time behind temporary bursts of file
transfer traffic, particularly at network bottleneck points, e.g. at
the 100 Mbps to 10 Mbps transition that might occur between the riser
to the wiring closet and the final link to the user from a desktop
switch. In this case, however, if it is known a priori (either by
application design, on the basis of statistics, or by administrative
control) that time-critical traffic is a small fraction of the total
bandwidth, it suffices to give it strict priority over the non-time-
critical traffic. The worst case delay experienced by the time-
critical traffic is roughly the maximum transmission time of a
maximum length non-time-critical frame -- less than a millisecond for
10 Mbps Ethernet, and well below the end to end delay budget based on
human perception times.
When more than one priority service is to be offered by a network
element e.g. one which supports both Controlled Load as well as
Guaranteed Service, the requirements for the scheduling discipline
become more complex. In order to provide the required isolation
between the service classes, it will probably be necessary to queue
them separately. There is then an issue of how to service the queues
which requires a combination of admission control and more
intelligent queuing disciplines. As with the service specifications
themselves, the specification of queuing algorithms is beyond the
scope of this document.
8.3. 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/IEEE 802.5, for
instance, supports eight priority levels which may be mapped to one
or more traffic classes. Ethernet/IEEE 802.3 has no support for
signaling priorities within frames. However, the IEEE 802 standards
committee has recently developed a new standard for bridges/switches
related to multimedia traffic expediting and dynamic multicast
filtering [3]. A packet format for carrying a user_priority field on
all IEEE 802 LAN media types is now defined in [4]. These standards
allow for up to eight traffic classes on all media. The
user_priority bits carried in the frame are mapped to a particular
traffic class within a bridge/switch. The user_priority is signaled
on an end-to-end basis, unless overridden by bridge/switch
management. The traffic class that is used by a flow should depend
on the quality of service desired and whether the reservation is
successful or not. Therefore, a sender should use the user_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 value of user_priority to be used
by the sender for that session's data. An accompanying memo [13]
addresses the issue of mapping the various Integrated Services to
appropriate traffic classes.
8.4. Re-mapping of Non-conforming Aggregated Flows
One other topic under discussion in the IntServ context is how to
handle the traffic for data flows from sources that exceed their
negotiated traffic contract with the network. An approach that shows
some promise is to treat such traffic with "somewhat less than best
effort" service in order to protect traffic that is normally given
"best effort" service from having to back off. Best effort traffic
is often adaptive, using TCP or other congestion control algorithms,
and it would be unfair to penalize those flows due to badly behaved
traffic from reserved flows which are often set up by non-adaptive
applications.
A possible solution might be to assign normal best effort traffic to
one user_priority and to label excess non-conforming traffic as a
lower user_priority although the re-ordering problems that might
arise from doing this may make this solution undesirable,
particularly if the flows are using TCP. For this reason the
controlled load service recommends dropping excess traffic, rather
than re-mapping to a lower priority. This is further discussed
below.
8.5. Override of Incoming User Priority
In some cases, a network administrator may not trust the
user_priority values contained in packets from a source and may wish
to map these into some more suitable set of values. Alternatively,
due perhaps to equipment limitations or transition periods, the
user_priority values may need to be re-mapped as the data flows
to/from different regions of a network.
Some switches may implement such a function on input that maps
received user_priority to some internal set of values. This function
is provided by a table known in IEEE 802.1D as the User Priority
Regeneration Table (Table 3-1 in [3]). These values can then be
mapped using an output table described above onto outgoing
user_priority values. These same mappings must also be used when
applying admission control to requests that use the user_priority
values (see e.g. [14]). More sophisticated approaches are also
possible where a device polices traffic flows and adjusts their
onward user_priority based on their conformance to the admitted
traffic flow specifications.
8.6. Different Reservation Styles
In the figure above, SW is a bridge/switch in the link layer domain.
S1, S2, S3, R1 and R2 are end stations which are members of a group
associated with the same RSVP flow. S1, S2 and S3 are upstream end
stations. R1 and R2 are the downstream end stations which receive
traffic from all the senders. RSVP allows receivers R1 and R2 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 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 R1 and R2 are
different. Therefore, in the absence of policing within
bridges/switches, it may be possible to support only fixed filter
reservations at the link layer.
+-----+ +-----+ +-----+
| S1 | | S2 | | S3 |
+-----+ +-----+ +-----+
| | |
| v |
| +-----+ |
+--------->| SW |<---------+
+-----+
| |
+----+ +----+
| |
v V
+-----+ +-----+
| R1 | | R2 |
+-----+ +-----+
Figure 7: Illustration of filter styles
8.7. Receiver Heterogeneity
At Layer 3, the IntServ model allows heterogeneous receivers for
multicast flows where different branches of a tree can have different
types of reservations for a given multicast destination. It also
supports the notion that trees may have some branches with reserved
flows and some using best effort service. If we were to treat a
Layer 2 subnet as a single network element as defined in [8], then
all of the branches of the distribution tree that lie within the
subnet could be assumed to require the same QoS treatment and be
treated as an atomic unit as regards admission control, etc. With
this assumption, the model and protocols already defined by IntServ
and RSVP already provide sufficient support for multicast
heterogeneity. Note, however, that an admission control request may
well be rejected because just one link in the subnet is
oversubscribed leading to rejection of the reservation request for
the entire subnet.
As an example, consider Figure 8, SW is a Layer 2 device
(bridge/switch) participating in resource reservation, S is the
upstream source end station and R1 and R2 are downstream end station
receivers. R1 would like to make a reservation for the flow while R2
would like to receive the flow using best effort service. S sends
RSVP PATH messages which are multicast to both R1 and R2. R1 sends
an RSVP RESV message to S requesting the reservation of resources.
+-----+
| S |
+-----+
|
v
+-----+ +-----+ +-----+
| R1 |<-----| SW |----->| R2 |
+-----+ +-----+ +-----+
Figure 8: Example of receiver heterogeneity
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 R1. At SW, there must be some mechanism
which forwards the packet providing service corresponding to the
reserved traffic class at the interface to R1 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 MAC 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 IEEE
802.1D 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
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 thus potentially duplicating the traffic on
a portion of the distribution tree.
The above approaches would provide very sub-optimal utilization of
resources given the expected size and complexity of the Layer 2
subnets. Therefore, it is desirable to enable switches to apply QoS
differently on different egress branches of a tree that divide at
that switch.
IEEE 802.1D specifies a basic model for multicast whereby a switch
makes multicast forwarding decisions based on the destination
address. This would produce a list of output ports to which the
packet should be forwarded. In its default mode, such a switch would
use the user_priority value in received packets, or a value
regenerated on a per input port basis in the absence of an explicit
value, to enqueue the packets at each output port. Any IEEE 802.1D
switch which supports multiple traffic classes can support this
operation.
If a switch selects per port output queues based only on the incoming
user_priority, as described by IEEE 802.1D, it must treat all
branches of all multicast sessions within that user_priority class
with the same queuing mechanism. Receiver heterogeneity is then not
possible and this could well lead to the failure of an admission
control request for the whole multicast session due to a single link
being oversubscribed. Note that in the Layer 2 case as distinct from
the Layer 3 case with RSVP/IntServ, the option of having some
receivers getting the session with the requested QoS and some getting
it best effort does not exist as basic IEEE 802.1 switches are unable
to re-map the user_priority on a per link basis. This could become
an issue with heavy use of dynamic multicast sessions. If a switch
were to implement a separate user_priority mapping at each output
port, then, in some cases, reservations can use a different traffic
class on different paths that branch at such a switch in order to
provide multiple receivers with different QoS. This is possible if
all flows within a traffic class at the ingress to a switch egress in
the same traffic class on a port. For example, traffic may be
forwarded using user_priority 4 on one branch where receivers have
performed admission control and as user_priority 0 on ones where they
have not. We assume that per user_priority queuing without taking
account of input or output ports is the minimum standard
functionality for switches in a LAN environment (IEEE 802.1D) but
that more functional Layer 2 or even Layer 3 switches (i.e. routers)
can be used if even more flexible forms of heterogeneity are
considered necessary to achieve more efficient resource utilization.
The behavior of Layer 3 switches in this context is already well
standardized by the IETF.
9. Network Topology Scenarios
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 the LAN technologies under consideration 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.
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. Obviously, this topology provides the best
QoS capabilities. Another important element in the discussion of
topologies is the presence or absence of support for multiple traffic
classes. These were discussed earlier in Section 4.1. Depending on
the basic topology used and the ability to support traffic classes,
we identify six scenarios as follows:
1. Shared topology without traffic classes.
2. Shared topology with traffic classes.
3. Switched half duplex topology without traffic classes.
4. Switched half duplex topology with traffic classes.
5. Switched full duplex topology without traffic classes.
6. Switched full duplex topology with traffic classes.
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 switches which support traffic classes
and some which do not. If the flow in question traverses both kinds
of 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. In the following sections, we present these
scenarios in further detail for some of the different IEEE 802
network types with discussion of their abilities to support the
IntServ services.
9.1. Full Duplex Switched Networks
On a full duplex switched LAN, the MAC protocol is unimportant as as
access is concerned, but must be factored into the characterization
parameters advertised by the device since the access latency is equal
to the time required to transmit the largest packet. Approximate
values for the characteristics on various media are provided in the
following tables. These delays should be also be considered in the
context of the speed of light delay which is approximately 400 ns for
typical 100 m UTP links and 7 us for typical 2 km multimode fiber
links.
Table 4: Full duplex switched media access latency
--------------------------------------------------
Type Speed Max Pkt Max Access
Length Latency
--------------------------------------------------
Ethernet 10 Mbps 1.2 ms 1.2 ms
100 Mbps 120 us 120 us
1 Gbps 12 us 12 us
Token Ring 4 Mbps 9 ms 9 ms
16 Mbps 9 ms 9 ms
FDDI 100 Mbps 360 us 8.4 ms
Demand Priority 100 Mbps 120 us 120 us
--------------------------------------------------
Full duplex switched network topologies offer good QoS capabilities
for both Controlled Load and Guaranteed Service when supported by
suitable queuing strategies in the switches.
9.2. Shared Media Ethernet Networks
Thus far, we have not discussed the difficulty of dealing with
allocation on a single shared CSMA/CD segment. As soon as any
CSMA/CD algorithm is introduced the ability to provide any form of
Guaranteed Service is seriously compromised in the absence of any
tight coupling between the multiple senders on the link. There are a
number of reasons for not offering a better solution to this problem.
Firstly, we do not believe this is a truly solvable problem as it
would require changes to the MAC protocol. IEEE 802.1 has examined
research showing disappointing simulation results for performance
guarantees on shared CSMA/CD Ethernet without MAC enhancements.
There have been proposals for enhancements to the MAC layer
protocols, e.g. BLAM and enhanced flow control in IEEE 802.3.
However, any solution involving an enhanced software MAC running
above the traditional IEEE 802.3 MAC, or other proprietary MAC
protocols, is outside the scope of the ISSLL working group and this
document. Secondly, we are not convinced that it is really an
interesting problem. While there will be end stations on shared
segments for some time to come, the number of deployed switches is
steadily increasing relative to the number of stations on shared
segments. This trend is proceeding to the point where it may be
satisfactory to have a solution which assumes that any network
communication requiring resource reservations will take place through
at least one switch or router. Put another way, the easiest upgrade
to existing Layer 2 infrastructure for QoS support is the
installation of segment switching. Only when this has been done is
it worthwhile to investigate more complex solutions involving
admission control. Thirdly, the core of campus networks typically
consists of solutions based on switches rather than on repeated
segments. There may be special circumstances in the future, e.g.
Gigabit buffered repeaters, but the characteristics of these devices
are different from existing CSMA/CD repeaters anyway.
Table 5: Shared Ethernet media access latency
--------------------------------------------------
Type Speed Max Pkt Max Access
Length Latency
--------------------------------------------------
Ethernet 10 Mbps 1.2 ms unbounded
100 Mbps 120 us unbounded
1 Gbps 12 us unbounded
--------------------------------------------------
9.3. Half Duplex Switched Ethernet Networks
Many of the same arguments for sub optimal support of Guaranteed
Service on shared media Ethernet also apply to half duplex switched
Ethernet. In essence, this topology is a medium that is shared
between at least two senders contending for packet transmission.
Unless these are tightly coupled and cooperative, there is always the
chance that the best effort traffic of one will interfere with the
reserved traffic of the other. Dealing with such a coupling would
require some form of modification to the MAC protocol.
Not withstanding the above argument, half duplex switched topologies
do seem to offer the chance to provide Controlled Load service. With
the knowledge that there are exactly two potential senders that are
both using prioritization for their Controlled Load traffic over best
effort flows, and with admission control having been done for those
flows based on that knowledge, the media access characteristics while
not deterministic are somewhat predictable. This is probably a close
enough useful approximation to the Controlled Load service.
Table 6: Half duplex switched Ethernet media access latency
------------------------------------------
Type Speed Max Pkt Max Access
Length Latency
------------------------------------------
Ethernet 10 Mbps 1.2 ms unbounded
100 Mbps 120 us unbounded
1 Gbps 12 us unbounded
------------------------------------------
9.4. Half Duplex Switched and Shared Token Ring Networks
In a shared Token Ring network, the network access time for high
priority traffic at any station is bounded and is given by
(N+1)*THTmax, where N is the number of stations sending high priority
traffic and THTmax is the maximum token holding time [14]. This
assumes that network adapters have priority queues so that
reservation of the token is done for traffic with the highest
priority currently queued in the adapter. It is easy to see that
access times can be improved by reducing N or THTmax. The
recommended default for THTmax is 10 ms [6]. N is an integer from 2
to 256 for a shared ring and 2 for a switched half duplex topology.
A similar analysis applies for FDDI.
Table 7: Half duplex switched and shared Token
Ring media access latency
----------------------------------------------------
Type Speed Max Pkt Max Access
Length Latency
----------------------------------------------------
Token Ring 4/16 Mbps shared 9 ms 2570 ms
4/16 Mbps switched 9 ms 30 ms
FDDI 100 Mbps 360 us 8 ms
----------------------------------------------------
Given that access time is bounded, it is possible to provide an upper
bound for end-to-end delays as required by Guaranteed Service
assuming that traffic of this class uses the highest priority
allowable for user traffic. The actual number of stations that send
traffic mapped into the same traffic class as Guaranteed Service may
vary over time but, from an admission control standpoint, this value
is needed a priori. The admission control entity must therefore use
a fixed value for N, which may be the total number of stations on the
ring or some lower value if it is desired to keep the offered delay
guarantees smaller. If the value of N used is lower than the total
number of stations on the ring, admission control must ensure that
the number of stations sending high priority traffic never exceeds
this number. This approach allows admission control to estimate
worst case access delays assuming that all of the N stations are
sending high priority data even though, in most cases, this will mean
that delays are significantly overestimated.
Assuming that Controlled Load flows use a traffic class lower than
that used by Guaranteed Service, no upper bound on access latency can
be provided for Controlled Load flows. However, Controlled Load
flows will receive better service than best effort flows.
Note that on many existing shared Token Rings, bridges transmit
frames using an Access Priority (see Section 4.3) value of 4
irrespective of the user_priority carried in the frame control field
of the frame. Therefore, existing bridges would need to be
reconfigured or modified before the above access time bounds can
actually be used.
9.5. Half Duplex and Shared Demand Priority Networks
In IEEE 802.12 networks, communication between end nodes and hubs and
between the hubs themselves is based on the exchange of link control
signals. These signals are used to control access to the shared
medium. If a hub, for example, receives a high priority request
while another hub is in the process of serving normal priority
requests, then the service of the latter hub can effectively be
preempted in order to serve the high priority request first. After
the network has processed all high priority requests, it resumes the
normal priority service at the point in the network at which it was
interrupted.
The network access time for high priority packets is basically the
time needed to preempt normal priority network service. This access
time is bounded and it depends on the physical layer and on the
topology of the shared network. The physical layer has a significant
impact when operating in half duplex mode as, e.g. when used across
unshielded twisted pair cabling (UTP) links, because link control
signals cannot be exchanged while a packet is transmitted over the
link. Therefore the network topology has to be considered since, in
larger shared networks, the link control signals must potentially
traverse several links and hubs before they can reach the hub which
has the network control function. This may delay the preemption of
the normal priority service and hence increase the upper bound that
may be guaranteed.
Upper bounds on the high priority access time are given below for a
UTP physical layer and a cable length of 100 m between all end nodes
and hubs using a maximum propagation delay of 570 ns as defined in
[19]. These values consider the worst case signaling overhead and
assume the transmission of maximum sized normal priority data packets
while the normal priority service is being preempted.
Table 8: Half duplex switched Demand Priority UTP access latency
------------------------------------------------------------
Type Speed Max Pkt Max Access
Length Latency
------------------------------------------------------------
Demand Priority 100 Mbps, 802.3 pkt, UTP 120 us 254 us
802.5 pkt, UTP 360 us 733 us
------------------------------------------------------------
Shared IEEE 802.12 topologies can be classified using the hub
cascading level "N". The simplest topology is the single hub network
(N = 1). For a UTP physical layer, a maximum cascading level of N =
5 is supported by the standard. Large shared networks with many
hundreds of nodes may be built with a level 2 topology. The
bandwidth manager could be informed about the actual cascading level
by network management mechanisms and can use this information in its
admission control algorithms.
In contrast to UTP, the fiber optic physical layer operates in dual
simplex mode. Upper bounds for the high priority access time are
given below for 2 km multimode fiber links with a propagation delay
of 10 us.
For shared media with distances of up to 2 km between all end nodes
and hubs, the IEEE 802.12 standard allows a maximum cascading level
of 2. Higher levels of cascaded topologies are supported but require
a reduction of the distances [15].
The bounded access delay and deterministic network access allow the
support of service commitments required for Guaranteed Service and
Controlled Load, even on shared media topologies. The support of
just two priority levels in 802.12, however, limits the number of
services that can simultaneously be implemented across the network.
Table 9: Shared Demand Priority UTP access latency
----------------------------------------------------------------
Type Speed Max Pkt Max Access Topology
Length Latency
----------------------------------------------------------------
Demand Priority 100 Mbps, 802.3 pkt 120 us 262 us N = 1
120 us 554 us N = 2
120 us 878 us N = 3
120 us 1.24 ms N = 4
120 us 1.63 ms N = 5
Demand Priority 100 Mbps, 802.5 pkt 360 us 722 us N = 1
360 us 1.41 ms N = 2
360 us 2.32 ms N = 3
360 us 3.16 ms N = 4
360 us 4.03 ms N = 5
-----------------------------------------------------------------
Table 10: Half duplex switched Demand Priority
fiber access latency
-------------------------------------------------------------
Type Speed Max Pkt Max Access
Length Latency
-------------------------------------------------------------
Demand Priority 100 Mbps, 802.3 pkt, fiber 120 us 139 us
802.5 pkt, fiber 360 us 379 us
-------------------------------------------------------------
Table 11: Shared Demand Priority fiber access latency
---------------------------------------------------------------
Type Speed Max Pkt Max Access Topology
Length Latency
---------------------------------------------------------------
Demand Priority 100 Mbps, 802.3 pkt 120 us 160 us N = 1
120 us 202 us N = 2
Demand Priority 100 Mbps, 802.5 pkt 360 us 400 us N = 1
360 us 682 us N = 2
---------------------------------------------------------------
10. Justification
An obvious concern is the complexity of this model. It essentially
does what RSVP already does at Layer 3, so why do we think we can do
better by reinventing the solution to this problem at Layer 2?
The key is that there are a number of simple Layer 2 scenarios that
cover a considerable portion of the real QoS problems that will
occur. A solution that covers the majority of problems at
significantly lower cost is beneficial. Full RSVP/IntServ with per
flow queuing in strategically positioned high function switches or
routers may be needed to completely resolve all issues, but devices
implementing the architecture described in herein will allow for a
significantly simpler network.
11. Summary
This document has specified a framework for providing Integrated
Services over shared and switched LAN technologies. The ability to
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.
Accompanying memos from the ISSLL working group address service
mapping issues [13] and provide a protocol specification for the
Bandwidth Manager protocol [14] based on the requirements and goals
discussed in this document.
References
[1] IEEE Standards for Local and Metropolitan Area Networks:
Overview and Architecture, ANSI/IEEE Std 802, 1990.
[2] ISO/IEC 10038 Information technology - Telecommunications and
information exchange between systems - Local area networks -
Media Access Control (MAC) Bridges, (also ANSI/IEEE Std 802.1D-
1993), 1993.
[3] ISO/IEC 15802-3 Information technology - Telecommunications and
information exchange between systems - Local and metropolitan
area networks - Common specifications - Part 3: Media Access
Control (MAC) bridges (also ANSI/IEEE Std 802.1D-1998), 1998.
[4] IEEE Standards for Local and Metropolitan Area Networks:
Virtual Bridged Local Area Networks, IEEE Std 802.1Q-1998, 1998.
[5] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource Reservation Protocol (RSVP) - Version 1 Functional
Specification", RFC2205, September 1997.
[6] Wroclawski, J., "Specification of the Controlled Load Network
Element Service", RFC2211, September 1997.
[7] Shenker, S., Partridge, C. and R. Guerin, "Specification of
Guaranteed Quality of Service", RFC2212, September 1997.
[8] Braden, R., Clark, D. and S. Shenker, "Integrated Services in
the Internet Architecture: An Overview", RFC1633, June 1994.
[9] Wroclawski, J., "The Use of RSVP with IETF Integrated Services",
RFC2210, September 1997.
[10] Shenker, S. and J. Wroclawski, "Network Element Service
Specification Template", RFC2216, September 1997.
[11] Shenker, S. and J. Wroclawski, "General Characterization
Parameters for Integrated Service Network Elements", RFC2215,
September 1997.
[12] Delgrossi, L. and L. Berger (Editors), "Internet Stream Protocol