One document matched: draft-yavatkar-sbm-ethernet-01.txt
Differences from draft-yavatkar-sbm-ethernet-00.txt
Internet Engineering Task Force Raj Yavatkar, Intel
INTERNET-DRAFT Don Hoffman, Sun Microsystems
Yoram Bernet, Microsoft
Ema Patki, Intel
September 1996
Expires: December 31, 1996
SBM (Subnet Bandwidth Manager):
A Proposal for Admission Control over Ethernet
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au
(Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West
Coast).
This document is a product of the ISSLL subgroup of the Integrated Services
working group of the Internet Engineering Task Force. Comments are
solicited and should be addressed to the working group's mailing list
at issll@mercury.lcs.mit.edu, and/or the author(s).
Abstract
This document outlines an architecture for RSVP-based admission
control over an IEEE 802.3 ethernet environment. The proposed
architecture is designed to work with the current generation of
Ethernet infrastructure (NICs, bridges, hubs, and switches) and should
be considered as a first step towards discovering solutions for
implementation of IntServ capabilities over Ethernet. This draft is
intended for discussions in ISSLL working group's interim meeting
(Boston, October 1996) and is a revision of an earlier draft presented
at the Montreal IETF meeting in June 1996.
draft-yavatkar-sbm-ethernet-01.txt [Page 1]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996
1. Introduction
RSVP and Integrated-Services specifications together define an
admission control and traffic control framework for providing
end-to-end QoS guarantees over the Internet. However, specific
algorithms, mechanisms, and protocols are needed to map the proposed
integrated services over specific link-layer technologies such as
Ethernet. Our goal is to propose an architecture for achieving
admission control and traffic control over Ethernet on the basis of
the framework proposed in the RSVP and Int-Serv working groups. Our
proposal is based on the following architectural goals and assumptions:
I. Our goal is to define an architecture that provides a step-by-step
solution to the problem of managing bandwidth that works with the
existing, legacy Ethernet infrastructure and takes advantage of
additional functionality (such as an explicit support for
integrated services) as it becomes available in new generation of
Ethernet NICs, switches, hubs, or bridges. As a result, our archi-
tecture would allow for a range of LAN bandwidth management solu-
tions that vary from one that exercises purely administrative con-
trol (over the amount of bandwidth consumed by RSVP-enabled
traffic flows) to one that requires cooperation (and enforcement)
from all the end-systems attached to a shared sub-network.
II. To support integrated services on a specific networking technology,
we must specify both admission control and traffic control com-
ponents. Our goal is to specify an architecture for admission con-
trol in this document and suggest possible approaches for traffic
control in end-systems and Ethernet infrastructure (switches, hubs,
etc.)
III. An effective admission control mechanism for Ethernet requires
managing and controlling bandwidth usage so that the aggregate
traffic load on any Ethernet segment does not exceed its capacity.
This requires controlling the amount of traffic generated by both
RSVP-enabled and best-effort traffic flows. On one hand, RSVP pro-
vides a framework for achieving admission control over RSVP-enabled
flows under which receivers must request reservation of resources
for the traffic they wish to receive. Thus, amount of traffic load
imposed by RSVP-enabled flows can be controlled to stay within a
limit. On the other hand, the best-effort traffic generated by
TCP/IP based sources is generally rate-adaptive (using "slow start"
type congestion avoidance mechanisms or feedback-based rate adapta-
tion used by sources based on RTP/RTCP protocols) and limits the
amount of traffic generated to adapt to available capacity. Thus,
specification of an RSVP-based admission control mechanism for Eth-
ernet typically suffices to control the total amount of traffic
draft-yavatkar-sbm-ethernet-01.txt [Page 2]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996
over a shared LAN. This is especially true in a switched Ethernet
environment if switches and NICs support at least two levels of
priority. In such a multi-priority LAN, assignment of higher prior-
ity to RSVP traffic (to separate it from best-effort traffic) cou-
pled with a combination of admission control (over RSVP traffic to
keep it within a fraction of any link's capacity) and per-flow pol-
icing at end-systems should suffice to realize an approximation to
"controlled load" service specified in the int-serv working group.
However, in some cases and topologies such as a shared Ethernet
segment, best-effort traffic can interfere with traffic from
RSVP-enabled traffic and, therefore, an explicit control over the
amount of best-effort traffic that can be sent over Ethernet may
also be necessary to implement a particular service class. Such a
control may be exercised at end-nodes through a combination of pol-
icing and admission control for best-effort traffic without an
explicit QoS specification by and participation of applications
that generate such traffic. To accommodate such needs, our proposal
includes mechanisms for reservation of bandwidth by both RSVP-
enabled and non-RSVP traffic.
IV. RSVP uses a receiver-initiated approach for resource reservation.
Under this approach, a sender notifies the (network and the)
receivers about its traffic characteristics and the receiver ini-
tiates a reservation request that propagates back to the sender.
As the reservation request propagates back to the sender, each
intermediate RSVP node (a host or a router) reserves resources on
its downstream interface. We propose to retain the same model of
receiver-based reservations for RSVP flows. However, to allow for
reservation of bandwidth by non-RSVP flows, a sender-based reser-
vation mechanism is also included for unicast flows. We will show
that these two can coexist.
V. For traffic control, we assume that end-systems will police indivi-
dual flows to ensure that each flow stays within its traffic
specification stipulated in its reservation request for admission
control. Additional traffic scheduling mechanisms may also be
employed to realize a particular QoS service class. No explicit
support for integrated services is assumed from Ethernet NICs,
switches, hubs, or bridges. This document mainly concentrates on
the admission control component. At the end of this document, we
identify possible alternatives for traffic control support in both
end-systems and Ethernet switches.
VI. In the absence of any policing or traffic shaping mechanism for
limiting outgoing traffic on an end-system, our architecture only
provides an administrative control over the maximum amount of
RSVP-capable traffic admitted on any segment of a LAN. We assume
that all the RSVP nodes on a LAN will utilize the proposed
draft-yavatkar-sbm-ethernet-01.txt [Page 3]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996
admission control procedure to reserve bandwidth in advance of
sending any RSVP-enabled data flows and will not send/forward such
traffic if the reservation request fails. Thus, if all the mul-
timedia traffic on a LAN is sent using RSVP for resource reserva-
tion, the proposed architecture would restrict the total mul-
timedia traffic on any LAN segment within the bounds desired by a
LAN administrator. This does not assure that non-RSVP traffic will
not interfere with the RSVP traffic.
2. Overview
2.1 Terminology
Our architecture is based on a logical entity called an SBM (Subnet
Bandwidth Manager) responsible for handling admission control
requests. We assume that a Designated SBM (DSBM) exists for each LAN
segment (called a Managed Segment or MS) and services reservation
requests (manages bandwidth) for that segment. An SBM is an
application-level entity that uses the raw IP protocol with its own pro-
tocol identifier for communication with its clients. The architecture
makes no assumptions about the number of SBMs within a LAN; an SBM may
act as a DSBM for one or more segments, or a single DSBM may exist for
each LAN segment. In the following, we refer to an entity requesting
bandwidth reservation as an "SBM client".
2.1 Basic Algorithm
Figure 1 - Example Managed Segment.
Host Host
_______ === ------- ===
| | | C | | SBM | | B |
| Router| | | - /---- |
|
|_R2____| === / ===
| | / |
| | / |
==============================================================LAN
| |
| |
=== __|_____
| A | | Router |
| | | R1 |
=== |________|
Host
draft-yavatkar-sbm-ethernet-01.txt [Page 4]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996
Figure 1 shows an example topology with hosts and routers interconnected
across a LAN. For the purpose of this discussion, we ignore the actual
physical topology of the LAN and a single SBM is assumed to be the DSBM
for the entire LAN. The basic SBM algorithm works as follows:
1. DSBM Initialization: As part of its initial configuration, DSBM
obtains information such as maximum bandwidth that can be reserved
on each LAN segment under its control. Configuration is likely to
be static with the current Ethernet devices. Future work may allow
for dynamic discovery of this information. Section 3 discusses some
of these issues in more detail.
2 SBM Client Initialization: At the start, an SBM client discovers
and binds to its DSBM using a "SBM Discovery Protocol" (described
in section 2.4).
3. SBM Message Types: Admission control under SBM has two parts. The
first part is an RSVP-based admission control mechanism that sup-
ports receiver-initiated reservations for RSVP-enabled flows. The
second part provides admission control for non-RSVP flows and
allows resource reservation by sources of such traffic. Therefore,
DSBM recognizes two types of messages: RSVP-based RESERVE (and
related) messages and additional message types defined explicitly
for interaction with non-RSVP enabled SBM clients.
4. RSVP-based Admission Control: To reserve Ethernet bandwidth, RSVP
nodes (RSVP-capable hosts and routers) follow the following steps:
a) As in conventional RSVP processing, Path messages from a sender
are sent/forwarded to potential receivers using the destination
session address or using the standard RSVP encapsulation. For
example, if the sender to a session is outside the LAN and
router R1 (see Figure 1) is on the path to the receivers, R1 will
forward a PATH message from the sender to the session address.
b) When a receiver (say, host A) wishes to make a reservation
request for the session, it sends a RSVP RESERVE message to its
DSBM using that DSBM's unicast address. The RESERVE message must
contain an additional, new RSVP object called LAN_PHOP object.
This object specifies the IP address of the PHOP
(previous hop) associated with the RESERVE message and has the
same structure as the RSVP_HOP object.
c) The DSBM processes the RSVP RESERVE message based on the
bandwidth available and returns an RSVP_ERROR to the requester
(host A) if the request cannot be granted. In case of a success-
ful reservation, DSBM forwards the RESERVE message towards the
draft-yavatkar-sbm-ethernet-01.txt [Page 5]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996
PHOP specified in the LAN_PHOP object. The RESERVE message lists
DSBM as the NHOP and, thus, DSBM effectively inserts itself as an
intermediate node between the actual NHOP (receiver) and the PHOP
(router or sender specified in the LAN_PHOP object). The DSBM
merges reservation requests for the same session as and when pos-
sible using the rules similar to the conventional RSVP process-
ing.
d) The RESERVE message eventually reaches the original PHOP on that
MS (as specified in the LAN_PHOP object) if all reservation
requests within the MS succeed.
5. Admission Control for non-RSVP flows: To reserve bandwidth for
non-RSVP flows, SBM clients that are traffic sources also reserve
bandwidth as follows.
An SBM client sends an SBM_RESV message to its DSBM that specifies
the source IP address, destination IP address, the QoS control ser-
vice desired (as per the int-serv specification), and the service-
specific flow specification (FLOWSPEC object). The DSBM processes
the SBM_RESV message and returns an SBM_ERROR or SBM_CONFM message
back to the requester depending on the result of admission con-
trol. The error message indicates the reason for failure and pro-
vides a hint on available bandwidth if the request failed due to in
availability of bandwidth.
2.2 Changes to conventional RSVP operation
The SBM algorithm requires following changes to the RSVP operation on
part of RSVP end-nodes:
- Outgoing RESERVE messages on an Ethernet interface are unicast to
the DSBM.
- RESERVE messages sent to a DSBM contain a new, additional object
called LAN_PHOP that specifies the IP address of the PHOP for the
RESERVE message.
- RESERVE messages are sent from an RSVP node to the DSBM, and not
the PHOP.
- Because DSBM inserts itself as a hop between PHOP and the receiver,
all RSVP_RESERVE related messages (such as RESV_CONFM, RESV_TEAR,
and RESV_ERR) flow through the DSBM.
draft-yavatkar-sbm-ethernet-01.txt [Page 6]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996
2.3 Co-Existence of RSVP and non-RSVP flows
On the shared segment shown in Figure 1, it is possible for both RSVP
and non-RSVP flows to exist simultaneously without compromising the QoS
granted to the RSVP flows. To this end, it is necessary for all non-
RSVP traffic sent on the segment, to be subject to admission control by
the same DSBM as RSVP traffic, and for non-RSVP traffic to be policed
(or shaped) in the same manner as RSVP traffic, at each sender.
As an example, consider an RSVP reservation initiated by host A for a
flow generated by host B; the reservation will flow through the SBM,
where it will be subjected to admission control. Assuming that it
passes admission control, the reservation will be forwarded to host B.
Host B`s traffic control elements will be configured to transmit traffic
for the new flow such that it is conformant with the accepted reserva-
tion. Now consider that an application on host C, which is not RSVP
aware, begins sending traffic to host A. No RSVP reservation will be
generated on behalf of this traffic. Instead, traffic control elements
in host C will signal to the DSBM, using the described sender initiated
protocol, requesting a reservation for the new traffic flow. This
reservation will be subject to the same admission control procedure as
RSVP reservations, based on the availability of resources in the same
shared pool.
2.4 Discovering and Binding to a DSBM
DSBM listens to a well-known SBM multicast address (SBM_GRP - an IP
multicast address) and an SBM client locates its DSBM by multicasting a
LOCATE_SBM request to SBM_GRP with a restricted multicast scope (multi-
cast TTL=1). After the initial handshake between the DSBM and an SBM
client, the SBM client is considered bound to its DSBM. The SBM client
must listen to the subsequent, periodic I_AM_DSBM refresh messages from
its DSBM to detect the DSBM failure. The client must repeat the binding
procedure if original DSBM fails (or is replaced by another one).
2.5 More than one active SBM on a LAN segment
For the sake of redundancy and fault tolerance, it is possible to have
more than one active SBM on any LAN segment that can act as a backup
DSBM if necessary. In such a case, exactly one SBM acts as the DSBM at
any time and is elected using an DSBM election algorithm. Once a DSBM is
elected, other SBMs stay around and step in to elect a new DSBM if the
previously elected DSBM terminates or crashes for some reason. The elec-
tion algorithm works as follows.
When a SBM comes up on an IP subnet, it must first discover whether a
DSBM already exists on the subnet. It does so by listening for incoming
draft-yavatkar-sbm-ethernet-01.txt [Page 7]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996
I_AM_DSBM messages for a random amount of time. If no other DSBM is
present, it announces its willingness to be a DSBM by periodically mul-
ticasting a DSBM WILLING message to the SBM_GRP address with restricted
multicast scope (TTL=1). If another SBM exists on the same subnet and
considers itself a current or a better choice, it replies to the new SBM
via a multicast I AM DSBM message to the same group. Ties between can-
didate DSBMs may be broken based on a priority field in the I_AM_DSBM
message (priority specified by the network administrator) or simply
based on IP address ordering. (e.g. candidate with the lower IP address
wins). If the new SBM does not hear a response from a better choice
within K periodic announcements, it declares itself to be the SBM by
multicasting a I_AM_DSBM message.
The designated SBM of the MS periodically multicasts the I_AM_DSBM mes-
sage. Other SBMs in the MS listen to the periodic announcements and
assume that the SBM has terminated functioning if they do not hear K
successive periodic announcements. In that case, all the SBMs initiate
the election algorithm to elect a new DSBM.
2.6 Application Behavior
This proposal makes no assumptions about any traffic separation or pol-
icing mechanisms on the MS. Consequently, there are no network
enforced mechanisms to keep non adaptive traffic intended to be part
of a reserved flow, but that did not receive a reservation due to
admission control, from interfering with traffic running with valid
reservations. Instead, applications are expected to be well behaved
and follow the following set of rules in such environments:
- For both unicast and multicast flows, an RSVP-based sender is not
to transmit any traffic on a RSVP flow until at least
one RESERVE has been received for that flow. The outgo-
ing flow should be policed at the sender to be less
than or equal to the maximum flow reserved. RESERVE
TEARS are indications that the sender should no longer send a
flow.
- For multicast flows, the receiver is to leave the session multicast
group if a reservation error (RESV_ERROR) or a Path Tear (PTEAR) is
received. This rule may create some difficulty in environments
where source specific multicast pruning is not implemented (the
default case in the current MBONE). A reservation error from a
path toward any one specific sender would result in the receiver
dropping all senders, even those with fully reserved paths.
Applications running in such environments should restrict ses-
sions to a single sender if at all possible.
draft-yavatkar-sbm-ethernet-01.txt [Page 8]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996
- For non-RSVP flows, the sender must first contact the DSBM to suc-
cessfully reserve the resources before sending any traffic. Also,
the outgoing flow must be policed at the sender to be less than or
equal to the maximum flow reserved.
2.6.1
Non-RSVP Flows The primary goal in supporting reservations for non-RSVP
flows is to protect RSVP flows on a shared segment from non-RSVP flows
on that segment. While this mechanism may be used to grant a specific
QoS to a specific flow, it is only its secondary benefit when the
application generating the flow is RSVP-unaware. Applications requiring
a specific QoS should obtain it using RSVP and non-RSVP flows are
intended to be used primarily to provide best-effort service to non-RSVP
aware applications.
Traffic control components on end-stations are expected to track the
offered load of the aggregate non-RSVP traffic generated on that end-
station and to request reservations on its behalf, from the SBM. The SBM
will allocate resources, as available, for non-RSVP traffic. These will
be allocated from that fraction of the shared segments resource pool,
designated to be available for best-effort traffic. End stations are
expected to limit their aggregate transmitted best-effort traffic per
the parameters indicated in the SBM`s response to the reservation
request.
draft-yavatkar-sbm-ethernet-01.txt [Page 9]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996
3. Handling Complex LAN Physical Topologies
The physical topology of a LAN may vary from a single, shared segment to
a more complex, multi-hop topology (e.g., an interconnected network of
bridges, hubs, and switches). In such a complex topology, the SBM algo-
rithm should handle two cases that may arise:
- In a multi-hub (or bridged) LAN topology, unicast data flows
between two entities on the subnet only traverse a subset of LAN
segments. Similarly, if Ethernet switches/hubs support IP multicast
traffic filtering, multicast data flows would also traverse a sub-
set of segments based on the location of IP multicast group
members. Thus, the SBM algorithm must reserve bandwidth only on
affected segments in such cases.
- Instead of a single SBM acting as a centralized DSBM for the entire
multi-hop LAN, it may be desirable to deploy many SBMs with each
SBM responsible for managing bandwidth on a separate portion of the
LAN. To handle such a case of many DSBMs within a LAN, our SBM
algorithm must include mechanisms for discovering and communicating
with peer DSBMs within a LAN.
In the remainder of this document, we address each of these issues
in more detail.
3.1 Discovering Physical Topology of a LAN
We assume that an SBM can discover the topological information
about the physical interconnections among hubs, switches, and
bridges using a variety of methods such as using a static topology
configuration database or using MIBs and techniques used by network
management utilities. Using a static topology database is suffi-
cient when the multi-hop LAN uses a star-based topology with no
alternate, redundant interconnections between bridges and hubs.
However, when alternate paths exist in a rich topology, bandwidth
reservation optimizations require access to information that
reveals the LAN segments traversed between two endpoints. Ideally,
a standard interface to information such as the spanning tree con-
figuration should be made available by IEEE 802.3 (or associated)
working groups. Until such an interface is available, we propose a
topology discovery protocol that relies on the "Topology Mapping"
section (section 4.0) of the hub MIB WG specification being con-
sidered in IETF [3].
3.1.1 Topology Discovery Protocol
Figure 2 -- Alternative representation of the LAN in figure 1.
draft-yavatkar-sbm-ethernet-01.txt [Page 10]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996
Switch Host
____ ===
| Sw1| | A |
|____|-------------| |
/ ===
/
/
_/__ ===
| Sw2|-------------| C |
|____| | |
/ ===
/ Host
__/__ ____
| SW3 | | Sw4 |
|_____| |_____|
/
/
=== _/____
| B |------| Sw5|
| | |____|
===
Host
As described above, in a multi-hop LAN, a DSBM should identify the
relevant physical segments on a path between a sender and a
receiver and perform admission control over one or more such seg-
ments. Figure 2 shows an example multi-hop topology. Communication
between endpoints (e.g., between hosts A and B, or between B and C)
requires reservation of bandwidth across only few of the LAN seg-
ments segments that lie on the path between the two endpoints.
Given a topology map, the DSBM needs to place the two endpoints on
the map and identify the LAN segments on the path between them. An
SBM follows the following steps to achieve the goal:
1. The SBM determines the MAC address of the endpoint it wishes to
place on the map.
2. The SBM tells all managed hubs in the collision domain to watch for
packets with that source MAC address.
3. The SBM sends an echo datagram ("ping") to the endpoint to cause it
to transmit. The SBM then uses the hub MIB interface to read the
group and port of the targeted MAC address from the managed hubs.
The information obtained identifies the location of the endpoint on
draft-yavatkar-sbm-ethernet-01.txt [Page 11]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996
the map and the LAN segments currently used to reach the endpoint.
Similar information can be gathered for the other endpoint.
4. Once the endpoints and the traversed hops are placed on the topol-
ogy map, the SBM can identify the affected segments between the two
endpoints assuming a spanning tree topology.
3.2 Handling Multiple, Peer DSBMs in a LAN
We assume that each DSBM has information on which LAN segments are
under its control and needs to communicate with its peer DSBMs
whenever admission control involves LAN segments that are not under
its control. Thus, peer-to-peer DSBM communication involves two
parts:
- Discovering peer DSBMs (and information on which segments
they manage).
- Coordinating with peer DSBMs when a reservation request
involves LAN segments under the control of more than one
SBM.
3.2.1 Discovery of Peer SBMs
All SBMs maintain a local cache of information on peer SBMs and
segments under their control. The cache is periodically updated to
flush outdated entries. When an SBM processes a reservation request
involving segment(s) that are not under its control, it checks its
cache to locate appropriate DSBMs for the segment(s) of interest.
If no DSBM is known, it multicasts (with TTL=1) a PEER_SEARCH query
to the SBM_GRP specifying the segment(s) of interest. When the
appropriate DSBM receives such a request, it multicasts its reply
to the group giving its unicast address and the list of segments
under its control. The requesting SBM (and others) then include the
information in their cache.
3.2.2 Peer-to-Peer Communication
When a reservation request involves segments outside the domain of
a DSBM, it first performs admission control on segments under its
control. If the admission control succeeds, the DSBM forwards the
RSVP RESERVE request to the peer DSBM responsible for the next
segment(s) on the path towards the LAN_PHOP using the peer`s uni-
cast address. The peer DSBM will repeat similar procedure and for-
ward the RESERVE to the next DSBM if necessary. Finally, the DSBM
responsible for the final segment for the LAN_PHOP will forward the
RESERVE to the LAN_PHOP if admission control succeeds up to and
draft-yavatkar-sbm-ethernet-01.txt [Page 12]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996
including the final segment. If admission control fails at any
intervening SBM, that SBM sends back an RSVP_ERROR message to its
previous peer and the error message propagates hop-by-hop (using
the information in the reservation state at intermediate SBMs) back
to the first DSBM which then communicates the RSVP_ERROR back to
the RSVP node that initiated the RESERVE.
DSBMs merge reservation requests (and handle killer reservation
problems) for the same session on segments under their control
according to the rules specified in the RSVP specification.
4. ADDITIONAL NOTES
It should be noted that our design allows for one DSBM per switch
in a LAN. However, our design will benefit from definition of
standard interface for accessing routing (spanning tree) informa-
tion available at switches and other 802.3 medium attachment units.
We also hope the draft to be a starting point of discussion between
IETF and IEEE 802.1P/Q subcommittee(s) to identify Level 2 mechan-
isms that will help in implementation of integrated-services capa-
bilities over Ethernets. In particular, per-flow traffic shaping
and scheduling mechanisms might be necessary in both end-systems
and Ethernet switches to provide guarantees on end-to-end delays
and such mechanisms should be investigated further.
Acknowledgements
The authors wish to thank John Flick of HP for explanation of the
"Topology Mapping" section of the hub MIB specification.
5. References
[1] R Braden, L Zhang, S Berson, S Herzog, J Wroclaswki, "Resource
Reservation Protocol", Internet Draft draft-ietf-rsvp-
spec12.txt,May 1996.
[2] S.Shenker, "Specification of General Characterization Parame-
ters", draft-ietf-intserv-charac-00.txt,Nov 1995
[3] D Romascanu, "Definitions of Managed Objects for IEEE 802.3
Repeater Devices", draft-ietf-hubmib-repeater-dev-03.txt, Sept.
1996.
6. Authors` Addresses
Raj Yavatkar
Intel Corporation
MS : JF2-74
draft-yavatkar-sbm-ethernet-01.txt [Page 13]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) Sept, 1996
2111 N.E. 25th Avenue,
Hillsboro, OR 97124 USA
phone: +1 503-264-9077
email: yavatkar@ibeam.intel.com
Don Hoffman
Sun Microsystems, Inc.
MS: UMPK14-305
2550 Garcia Avenue
Mountain View, California 94043-1100 USA
phone: +1 503-297-1580
email: don.hoffman@eng.sun.com
Yoram Bernet
Microsoft
1 Microsoft Way
Redmond, WA 98052
phone: +1 206 936 9568
email: yoramb@microsoft.com
Ema Patki
Intel Corporation
MS: JF2-74
2111 N.E. 25th Avenue,
Hillsboro, OR 97124 USA
phone: +1 503-264-0440
email: epatki@ibeam.intel.com
draft-yavatkar-sbm-ethernet-01.txt [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 01:30:04 |