One document matched: draft-yavatkar-sbm-ethernet-02.txt
Differences from draft-yavatkar-sbm-ethernet-01.txt
Internet Engineering Task Force Raj Yavatkar, Intel
INTERNET-DRAFT Don Hoffman, Sun Microsystems
Yoram Bernet, Microsoft
December 1996
Expires: June 30, 1997
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).
Changes From Last Version
This draft reflects the following changes to its previous version:
1. SBM now accepts and processes the RSVP PATH messages. A PATH mes-
sage sent over a LAN now contains LAN_NHOP and LAN_PHOP objects.
Section 2.2 describes changes to the RSVP operation.
2. Message encapsulation rules and message formats are added.
3. A section that describes the SBM operation over different LAN topo-
logies has been added.
draft-yavatkar-sbm-ethernet-02.txt [Page 1]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996
Abstract
This document outlines an architecture for RSVP-based admission
control over IEEE 802-style LANs. The proposed architecture is
designed to work with the current generation of IEEE 802 LANs and
should be considered as a first step towards discovering solutions
for implementation of IntServ capabilities over such networks.
draft-yavatkar-sbm-ethernet-02.txt [Page 2]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 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 pro-
posed integrated services over specific link-layer technologies
such as the IEEE 802-style LANs. Our goal is to propose an archi-
tecture for achieving admission control over the 802-style networks
such as Ethernet on the basis of the framework proposed in the RSVP
and Int-Serv working groups. Our proposal is based on the follow-
ing architectural goals and assumptions:
I. We define an architecture that provides a step-by-step solution to
the problem of managing bandwidth over shared subnetworks (such as
an Ethernet) that works with the existing, legacy LAN infrastruc-
ture and takes advantage of the additional functionality (such as
an explicit support for integrated services) as it becomes avail-
able in the new generation of switches, hubs, or bridges. As a
result, our architecture would allow for a range of LAN bandwidth
management solutions that vary from one that exercises purely
administrative control (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,
one needs to define mechanisms for admission control, traffic flow
separation, and traffic scheduling (the latter two are usually
grouped together under "traffic control"). For instance, an effec-
tive admission control mechanism for shared subnetworks requires
managing and controlling bandwidth usage so that the aggregate
traffic load on any shared segment does not exceed its capacity.
This requires controlling the amount of traffic generated by both
RSVP-enabled and non-RSVP traffic flows. Additional link level
mechanisms for traffic flow separation and traffic control may be
necessary to achieve the goal. Appendix A elaborates further on the
traffic control mechanisms necessary for this purpose.
In the short term, our goal is to specify only a signaling method
and protocol for LAN-based admission control over RSVP flows and
leave the task of specifying link layer mechanisms for traffic con-
trol to the appropriate IEEE 802 working groups.
Thus, the proposed mechanism explicitly controls only the total
draft-yavatkar-sbm-ethernet-02.txt [Page 3]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996
amount of traffic load imposed by RSVP-enabled flows on a shared
LAN. However, the best-effort traffic generated by the TCP/IP
sources is generally rate-adaptive (using "slow start" type conges-
tion avoidance mechanisms or feedback-based rate adaptation used by
sources based on RTP/RTCP protocols) and limits the amount of
traffic generated to adapt to available capacity. A specification
of an RSVP-based admission control mechanism for a LAN should typi-
cally suffice to control the total amount of traffic 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 priority to the RSVP
traffic (to separate it from best-effort traffic) coupled with a
combination of admission control (over RSVP traffic to keep it
within a fraction of any link's capacity) and per-flow policing at
end-systems should suffice to realize an approximation to the "con-
trolled load" service specified in the int-serv working group.
III. For traffic control, we assume that end-systems will police indivi-
dual RSVP-enabled data 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.
IV. As an interim measure until 802-mediated traffic control mechanisms
become available, we assume that all the RSVP nodes on a LAN will
utilize the proposed 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 multimedia traffic on a LAN is sent using
RSVP for resource reservation, the proposed architecture would
restrict the total multimedia traffic on any LAN segment within the
bounds desired by a LAN administrator. This does not, however,
assure that non-RSVP traffic will not interfere with the RSVP
traffic. Appendix A.1 discusses this approach in more detail.
2. Overview
Our architecture is based on a logical entity called an SBM (Subnet
Bandwidth Manager) responsible for handling admission control requests.
We assume that an IP subnet corresponds to a single L2 (Layer 2) domain
[3]. An L2 domain is defined to be a set of nodes and links intercon-
nected without passing through a L3 (IP or Layer 3) forwarding function.
We refer to links (point-to-point or shared segments) that interconnect
nodes within a L2 domain simply as LAN segments. We assume that a Desig-
nated SBM (DSBM) exists for each LAN segment (also called a Managed
draft-yavatkar-sbm-ethernet-02.txt [Page 4]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996
Segment or a MS) and services reservation requests (manages bandwidth)
for that segment. An SBM is an application-level entity that uses UDP
for communication with its clients. The architecture makes no assump-
tions about the number of SBMs within a LAN; a single DSBM may manage a
shared LAN segment whereas a separate SBM may run on each switch in a
switched LAN topology (Section 3 discusses this point in greater
detail). In the following, we use the term "SBM client" to refer to an
entity (host or router) that communicates with a DSBM for the purpose of
establishing a QoS reservation.
2.1 Basic Algorithm
Figure 1 - An Example of a Managed Segment.
Host Host
_______ === ------- ===
| | | C | | SBM | | B |
| Router| | | - /---- | |
|_R2____| === / ===
| | / |
| | / |
==============================================================LAN
| |
| |
=== __|_____
| A | | Router |
| | | R1 |
=== |________|
Host
Figure 1 shows an example topology consisting of 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. Section 3 describes how an
SBM operates over different LAN topologies.
The basic SBM algorithm works as follows:
1. DSBM Initialization: As part of its initial configuration, DSBM
obtains information such as the 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.
2 SBM Client Initialization: At the start, an SBM client discovers
and binds to its DSBM using a "DSBM Discovery Protocol" (described
draft-yavatkar-sbm-ethernet-02.txt [Page 5]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996
in section 2.3).
3. RSVP-based Admission Control: To reserve LAN bandwidth, RSVP nodes
(RSVP-capable hosts and routers) follow the following steps:
a) When an RSVP node sends or forwards a PATH message over a LAN
interface, it unicasts the PATH message to its DSBM instead of
sending it to the destination address (as is done in conventional
RSVP processing). After processing (and possibly updating an
ADSPEC), the DSBM will forward the PATH message toward its desti-
nation address (See Section 3 for the case involving multiple
Layer 2 hops between a sender and a destination). As part of its
processing, the DSBM builds and maintains a path state for the
session and notes the previous hop that sent it the PATH message.
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 its DSBM (the DSBM's
unicast address) and the DSBM will eventually send the PATH mes-
sage to the RSVP session address. In the process, the DSBM builds
the PATH state, remembers the sender (router R1 in Figure 1) as
the previous hop for the session, and effectively inserts itself
as an intermediate node between the sender (or R1 in Figure 1)
and the receivers (or routers) on the LAN.
b) When a receiver (say, host A) wishes to make a reservation
request for the session, it follows standard RSVP rules and sends
a RSVP RESERVE message to the previous hop address obtained from
the PHOP object in the previously received PATH message.
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. Admission control
algorithm at DSBM ensures that sufficient bandwidth is available
on managed segments (MS) between the NHOP (requester) and the
PHOP (sender/router).
In case of a successful reservation, DSBM forwards the RESERVE
message towards the PHOP(s) based on the contents of the RESERVE
message and its local path state for the session. 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
(sender/router) on that MS if all reservation requests within the
MS succeed.
draft-yavatkar-sbm-ethernet-02.txt [Page 6]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996
2.2 Changes to conventional RSVP operation
The addition of an SBM for admission control over Ethernet results in
the following changes to the RSVP operation on an Ethernet:
- Outgoing PATH messages on an Ethernet interface are unicast to the
DSBM.
- In conventional RSVP processing over point-to-point links, RSVP
nodes (hosts/routers) use NHOP and PHOP objects to keep track of
the next hop (and the previous hop) nodes on the path between a
sender and a receiver. Over a shared LAN such as an Ethernet, we
introduce an SBM (subnet Bandwidth Manager) as a logical entity
that performs admission control over the LAN. Such a LAN may span
multiple switched or shared segments between a RSVP PHOP node and a
RSVP NHOP node. For the purpose of Layer 3 routing and RSVP seman-
tics between two Layer 3 entities, however, the entire LAN acts a
logical segment and the connection between RSVP PHOP and NHOP nodes
must be maintained for the correct operation and routing of RSVP
messages. Therefore, we introduce two new RSVP objects called
LAN_PHOP and LAN_NHOP that keep track of the peer RSVP nodes on a
path between a RSVP sender (or a previous hop router) and a RSVP
receiver (or a next hop router).
When an RSVP entity (a host or a router acting as the originator of
a PATH message) sends out a PATH message over an Ethernet inter-
face, it needs to include both LAN_NHOP and LAN_PHOP objects in the
message as described below. When a DSBM receives a PATH message it
passes on LAN_PHOP and LAN_NHOP objects unchanged and only modifies
PHOP and NHOP (i.e., RSVP_HOP) objects in those messages. Thus,
when an RSVP node finally receives the PATH message, it has the
necessary information about RSVP peer-to-peer association (and,
therefore, the layer 3 routing information) through the contents of
the LAN_PHOP and LAN_NHOP objects.
When sending out a PATH message over an Ethernet interface, first
RSVP node (sender or an edge router forwarding the PATH message)
must include two new objects, namely, a LAN_NHOP object and a
LAN_PHOP object. The LAN_NHOP object specifies the destination IP
address of the PATH message. In case of a unicast destination, the
LAN_NHOP address specifies the destination address or the address
of the next hop router towards the destination. The LAN_PHOP object
in the PATH message specifies the IP address of the RSVP node
(sender or forwarding router) that originated the PATH message on
the LAN.
- When an SBM receives a RSVP PATH message, it processes it according
draft-yavatkar-sbm-ethernet-02.txt [Page 7]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996
to the PATH processing rules described in the RSVP specification.
In particular, it remembers the PHOP address from which it received
the messages and forwards the path message with the PHOP object
modified to reflect its IP address. LAN_PHOP and LAN_NHOP objects
in the PATH message are passed along unchanged.
- The path state in SBM is used for forwarding subsequent RESV mes-
sages for the same session. When an SBM receives a RESV message, it
processes the message and forwards it to appropriate PHOP(s) based
on its path state.
- Because a DSBM inserts itself as a hop between a source of traffic
on the LAN (sender or router) and the receiver, all RSVP related
messages (such as PATH, PATH_TEAR, RESV, RESV_CONFM, RESV_TEAR, and
RESV_ERR) now flow through the DSBM.
- When RSVP session address is a multicast address, it is possible
for a router that originated a PATH message to receive one or more
copies of the PATH message when a DSBM on the path to the destina-
tion forwards it (i.e., multicasts it). However, the router can
detect and discard the duplicates either based on the contents of
the LAN_PHOP object (lists one of its interface addresses) or based
on who forwarded it (any PATH message coming from a SBM other than
its own DSBM).
2.3 Discovering and Binding to a DSBM
DSBM listens to a well-known SBM multicast address (SBM_GRP - an UDP
multicast address with a local scope -- of the form, <224.0.0.x, port
XXXX>, TBD) and an SBM client locates its DSBM by multicasting a
LOCATE_SBM request to the SBM_GRP address with a restricted multicast
scope (multicast TTL=1). DSBM replies to the client's query and provides
its unicast address for further communication. After the initial
handshake between the DSBM and an SBM client, the SBM client is con-
sidered bound to its DSBM and SBM client uses DSBM's unicast address for
subsequent communication.
To allow recovery from DSBM failures and binding to a newly elected
DSBM, the SBM client must listen to the subsequent, periodic I_AM_DSBM
refresh messages from its DSBM to detect the DSBM failure. These refresh
draft-yavatkar-sbm-ethernet-02.txt [Page 8]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996
messages (or "DSBM advertisements") are sent to the SBM_GRP address
every refresh interval (e.g., every 30 seconds; the refresh interval is
a configuration parameter). The client must repeat the binding pro-
cedure if original DSBM fails (or is replaced by another one).
2.4 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 for
the segment 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 election algorithm works as follows: When a SBM comes up on an IP
subnet, it must first discover whether a DSBM already exists on the sub-
net. It does so by listening for incoming I_AM_DSBM messages for a ran-
dom amount of time. If no other DSBM is present, it announces its wil-
lingness to be a DSBM by periodically multicasting a DSBM WILLING mes-
sage to the SBM_GRP address with the 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 candidate 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 (K >= 3) 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 (K
>= 3) successive periodic announcements. In that case, all the SBMs ini-
tiate the election algorithm to elect a new DSBM.
3. Various LAN Topologies
Our goal is to offer an admission control solution that works with the
existing, shared segments LANs as well as newer, switched LAN topolo-
gies. In the following, we consider three different LAN topologies and
describe how our solution works in each case.
3.1 Shared LAN segments
Figure 1 shows a sample topology where entire IP subnet spans a single
draft-yavatkar-sbm-ethernet-02.txt [Page 9]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996
shared segment. Actual physical topology in this case may consist of
multiple physical segments interconnected by hubs. However, for practi-
cal purposes, such a LAN acts as if all hosts are attached to a single
shared segment. In this case, a single DSBM manages shared bandwidth for
the entire subnet.
3.2 Switched LAN segments
Figure 2 shows a sample topology where an IP subnet spans a switched
Ethernet consisting of one or more switches interconnecting all the
end-systems within the subnet. In this case, we assume that one SBM
resides at each switch, the DSBM is responsible for managing outgoing
interfaces at the switch, and that the DSBM accesses its switch's local
MAC address table to discern forwarding information.
In this case, PATH and RESV messages between two end-systems on the sub-
net will propagate hop-by-hop from one DSBM to another DSBM as they
travel across the switches along the path.
For example, let us assume a unicast RSVP session addressed to host D in
Figure 2. Let us also assume that the sender in the session resides out-
side the LAN shown in Figure 2 and the router R1 forwards a PATH message
towards its receiver on the LAN.
When a PATH message for the session arrives at R1, the following
sequence of events will happen:
1. R1 forwards the PATH message to its DSBM (B1 in Figure 2).
2. B1 processes the PATH message, builds the path state, and then for-
wards the PATH message to the next DSBM on the path towards the
LAN_NHOP address (forwarding information discerned from the MAC
address table).
In the case of a LAN with multiple hops (segments) between an RSVP
sender (LAN_PHOP) and a destination (LAN_NHOP), the DSBMs forward
the PATH message hop-by-hop until it reaches a managed segment
where the destination resides. At that point, the DSBM for the
managed segment will send the PATH message directly to the destina-
tion.
In the case of a multicast destination where many receivers are
scattered across a LAN, the DSBM at each intermediate hop must for-
ward the PATH message to the session destination address for all
outgoing interfaces where group members reside. We assume that the
DSBM has access to a switch's local MAC address table to discern
draft-yavatkar-sbm-ethernet-02.txt [Page 10]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996
such forwarding information.
3. B2 will then process the PATH message and forward it to the
LAN_NHOP address.
4. When the host D decides to make a reservation for the session, it
looks up its path state to determine the previous hop(s) for the
session and sends the RSVP RESV message to its PHOP (B2). If the
admission control at B2 succeeds, it will forward the RESV message
to the PHOP (B1) according to its path state, and finally, the RSVP
RESV message will arrive at R1 if admission control at intermediate
switches succeeds.
5. Any admission control failure results in a RESV_ERROR being sent to
the requester and the RESV state at intermediate nodes is removed.
Figure 2 - An example of a switched topology
---------
| Router |
| R1 |
|_________|
/
/
/
++++++
Switch + B1 +
S1 + +
++++++
/ |__
/ |
/ |
++++++ ++++++
switch + B2 + + B3 + switch
S2 + + + + S3
++++++ ++++++
/ |__ |_____
/ | |
/ | |
Host Host Host
=== ==== ===
| D | | E | | F |
| | | | | |
=== === ===
draft-yavatkar-sbm-ethernet-02.txt [Page 11]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996
3.3 Combination of Shared and Switched segments (heterogeneous case)
Previous two cases represent two popular topologies (shared segment
topology is popular among legacy LANs and switched topology is popular
with the newer installations). However, we must also consider a more
general case when an IP subnet spans a combination of shared and
switched segments. In this case, we still assume that a DSBM exists at
each switch. However, the DSBM at a switch is not only responsible for
managing bandwidth across its incident point-to-point links to its
peers, but also manages shared segments that are incident to it. When
more than one switch is attached to a shared segment, the DSBM will
determine the directly attached segments that it manages >From the con-
figuration information supplied at the startup time. Shared segments
(and any non-SBM switches attached to them) are treated as a single log-
ical segment for the purpose of admission control. When a RESV request
arrives at the DSBM, it will perform admission control over all the
managed segments under its domain that are affected by the RESV message
before forwarding the RESV towards the previous hop address.
4. Layer 2 Support Issues
When an SBM resides on a switch, we assume that it has access to the
local MAC address table so that it can discern the information necessary
for forwarding PATH and RESV messages to their respective LAN_NHOP and
LAN_PHOP addresses. An accompanying document [3] describes the require-
ments for mapping IP Integrated Services over IEEE 802 traffic control
mechanisms.
5. Message Encapsulation and Formats
To minimize changes to existing RSVP implementations and to ensure quick
deployment of an SBM in conjunction with RSVP, all communication to and
from a DSBM will be performed using messages constructed using the
current rules for RSVP message formats. For more details on the RSVP
message formats, refer to the RSVP specification (draft-ietf-rsvp-spec-
14.ps). No changes to the RSVP message formats are proposed, but new
message types and new LAN_NHOP and LAN_PHOP objects are added to the
RSVP message formats to accommodate DSBM-related messages. These addi-
tions are described below.
All messages to a DSBM (except messages related to DSBM discovery and
advertizements) are addressed to the DSBM's unicast address. In partic-
ular, all RSVP-related messages (PATH, RESV, and other TEAR and ERROR
messages) directed to a DSBM are sent to the DSBM's unicast address. An
RSVP node discovers its DSBM (and DSBM's unicast address) using a
discovery method described in Section 2.3 earlier.
draft-yavatkar-sbm-ethernet-02.txt [Page 12]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996
Each message must occupy exactly one IP datagram. If it exceeds the MTU,
such a datagram will be fragmented by IP and reassembled at the reci-
pient node. This has a consequence that a single message may not exceed
the maximum IP datagram size, approximately 64K bytes.
5.1. RSVP-related Message Formats
All RSVP messages directed to and from a DSBM may contain various RSVP
objects defined in the RSVP specification and messages continue to fol-
low the formatting rules specified in the RSVP specification. In addi-
tion, an RSVP implementation must also recognize two new object classes,
LAN_NHOP and LAN_PHOP, that are described below.
5.2 LAN_NHOP and LAN_PHOP Objects
Both LAN_NHOP and LAN_PHOP objects have the same structure as the
RSVP_HOP object, but are identified as separate object classes to dis-
tinguish them from each other and from the RSVP_HOP objects.
LAN_NHOP objects use object class = 40; IPv4 LAN_NHOP object uses
<Class=40, C-Type=1> and IPv6 LAN_NHOP object uses <Class=40,
C-Type=2>.
IPv4 LAN_NHOP object: class = 40, C-Type =1
+---------------+---------------+---------------+---------------+
| IPv4 Next Hop Address |
+---------------+---------------+---------------+---------------+
| Logical Interface Handle |
+---------------+---------------+---------------+---------------+
IPv6 LAN_NHOP object: Class = 40, C-Type = 2
+---------------+---------------+---------------+---------------+
| |
+ +
| |
+ IPv6 next Hop Address +
| |
+ +
| |
+---------------+---------------+---------------+---------------+
| Logical Interface Handle |
+---------------+---------------+---------------+---------------+
LAN_PHOP objects use class=41; IPv4 LAN_PHOP and IPv6 LAN_PHOP objects
use C-Types 1 and 2 respectively. These objects are structured same as
those shown above.
draft-yavatkar-sbm-ethernet-02.txt [Page 13]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996
5.3 RSVP PATH Message Format
As specified in the RSVP specification, an RSVP_PATH message contains
the RSVP Common Header and the relevant RSVP objects. For the RSVP Com-
mon Header, refer to the RSVP specification (draft-ietf-rsvp-spec-
14.ps). Changes to an RSVP_PATH message include addition of the LAN_NHOP
and the LAN_PHOP objects as specified below.
<RSVP_PATH> ::= <RSVP Common Header> [INTEGRITY>]
<LAN_PHOP> <LAN_NHOP> <SESSION><RSVP_HOP><TIME_VALUES>
[<POLICY DATA>] <sender descriptor>
If the INTEGRITY object is present, it must immediately follow the RSVP
common header. LAN_NHOP object must always precede the SESSION object.
5.4 RSVP RESV Message Format
As specified in the RSVP specification, an RSVP_RESV message contains
the RSVP Common Header and relevant RSVP objects. No Changes to the RESV
message format are needed with the SBM protocol.
5.5. Additional RSVP message types to handle SBM interactions
New RSVP message types are introduced to allow interactions between a
DSBM and an RSVP node (host/router) for the purpose of discovering and
binding to a DSBM. New RSVP message types needed are as follows:
RSVP Msg Type (8 bits) Value
SBM_QUERY 64
SBM_REPLY 65
DSBM_WILLING 66
I_AM_DSBM 67
All SBM-specific messages are formatted as RSVP messages with an RSVP
common header followed by SBM-specific objects.
<SBMP_MESSAGE> ::= <SBMP common header> <SBM-specific objects>
where <SBMP common header> ::= <RSVP common Header> [<INTEGRITY>]
For each SBM message type, there is a set of rules for the permissible
choice of object types. These rules are specified using Backus-Naur Form
(BNF) augmented with square brackets surrounding optional sub-sequences.
The BNF implies an order for the objects in a message. However, in many
draft-yavatkar-sbm-ethernet-02.txt [Page 14]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996
(but not all) cases, object order makes no logical difference. An imple-
mentation should create messages with the objects in the order shown
here, but accept the objects in any permissible order. Any exceptions to
this rule will be pointed out in the specific message formats.
5.5.1 SBM_QUERY Message
SBM_QUERY message contains a single address object in the format that is
same as the RSVP SESSION object and gives the IP address of the request-
ing node. The SBM_QUERY message is multicast to the well known
DSBM_GROUP address as described earlier.
<SBM_QUERY message> ::= <SBMP common header> <IP address>
where <IP address> object is same as the <SESSION> object.
5.5.2 SBM_REPLY Message
SBM_REPLY message provides the IP address of the node sending out the
reply.
<SBM_REPLY Message> ::= <SBM Common Header> <IP ADDRESS>
The SBM_REPLY message is unicast to the sender of the SBM_QUERY message
.
5.5.3 DSBM_WILLING Message
<DSBM_WILLING message> ::= <SBM Common Header> <IP ADDRESS>
IP ADDRESS is the address of the DSBM sending out this message. All
DSBM_WILLING messages are multicast to the well known DSBM_GROUP
address.
5.5.4 I_AM_DSBM Message
<I_AM_DSBM> ::= <SBM Common Header> <IP ADDRESS> [<PRIORITY>]
IP ADDRESS is the address of the DSBM sending out this message. All
I_AM_DSBM messages are multicast to the well known DSBM_GROUP address.
The optional PRIORITY object specifies the relative priority of the
requesting SBM. When multiple, redundant SBMs are present on a LAN, a
priority level is assigned to each one of them by a network administra-
tor and is used to break ties when multiple candidate DSBMs participate
in the DSBM election algorithm. The default priority of an SBM is 1 and
higher priority values represent higher precedence.
PRIORITY Object: class = 42, C-Type =1
draft-yavatkar-sbm-ethernet-02.txt [Page 15]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996
+---------------+---------------+---------------+---------------+
| //// | //// | //// | priority |
+---------------+---------------+---------------+---------------+
6. 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 Parameters",
draft-ietf-intserv-charac-00.txt,Nov 1995
[3] D.Hoffman, "Integrated Services/RSVP Requirements for Layer 2
Traffic Control", draft-hoffman-issll-l2tcreq-00.txt, December 1996.
[4] Y.Bernet, "Admission Control for Best-Effort Traffic", in prepara-
tion.
draft-yavatkar-sbm-ethernet-02.txt [Page 16]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996
APPENDIX A
Traffic Control Issues on a LAN
A.1 Application Behavior
Because of its goal to support existing 802 infrastructures, this propo-
sal makes no assumptions about any traffic separation or policing
mechanisms on the MS. Consequently, there are no network enforced
mechanisms to keep non-adaptive traffic from interfering with the
traffic over reserved flows. In these sorts of environments we propose
that applications are expected to be well behaved and follow the follow-
ing set of rules:
- 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 outgoing flow should be pol-
iced at the sender host 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 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 drop-
ping all senders, even those with the fully reserved paths. Appli-
cations running in such environments should restrict sessions to a
single sender if at all possible.
A.2 Traffic Control Mechanisms in Layer 2
An effective admission control mechanism for shared subnetworks requires
managing and controlling bandwidth usage so that the aggregate traffic
load on any shared segment does not exceed its capacity. This requires
controlling the amount of traffic generated by both RSVP-enabled and
best-effort traffic flows.
We do not assume any particular explicit support for integrated ser-
vices is assumed from the LAN infrastructure (NICs, switches, hubs, or
bridges) and assume that an appropriate IEEE 802 working group will
specify the traffic control solutions for the link-level devices (an
accompanying document [3] provides recommendations to the IEEE 802.1
committee on the Layer 2 facilities needed to facilitate mapping of
int-serv services over Ethernet).
draft-yavatkar-sbm-ethernet-02.txt [Page 17]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996
In the absence of any layer 2 support, some topologies such as a shared
Ethernet segment may pose a problem when unrestricted best-effort
traffic can interfere with the traffic from RSVP-enabled traffic.
Therefore, an explicit end-system based control over the amount of
best-effort traffic that can be sent over Ethernet may be necessary to
implement a particular service class. Further investigation and experi-
mentation is necessary in this area [4].
ACKNOWLEDGEMENTS
Many thanks to Ema Patki for her active participation with the earlier
versions of this draft. Authors are also thankful to Fred Baker of Cisco
Systems and John ("JJ") Krawczyk of Bay Networks for their constructive
comments on the SBM design and the earlier versions of this draft.
6. Authors` Addresses
Raj Yavatkar
Intel Corporation
MS: JF3-206
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
USA
phone: +1 206 936 9568
email: yoramb@microsoft.com
draft-yavatkar-sbm-ethernet-02.txt [Page 18]
INTERNET-DRAFT SBM (Subnet Bandwidth Manager) December, 1996
draft-yavatkar-sbm-ethernet-02.txt [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 01:30:33 |