INTERNET-DRAFT EXPIRES: OCTOBER 1997 INTERNET-DRAFT
Network Working Group K. Dobbins
INTERNET-DRAFT T. Grant
Category: Informational D. Ruffen
Cabletron Systems Incorporated
April 1997
SBCD Protocol Specification
<draft-rfced-info-ruffen-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is 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-abstract.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).
Abstract
The Switch Broadcast Control and Delivery (SBCD) protocol is
part of the InterSwitch Message Protocol (ISMP). ISMP was
designed to facilitate interswitch communication within
distributed connection-oriented switching networks. The SBCD
protocol is used to reduce the amount of broadcast traffic
across the switch fabric by restricting unresolved broadcast
packets to only those ports that belong to the same VLAN as the
source.
Table of Contents
Status of this Memo........................................1
Abstract...................................................1
1. Introduction...........................................1
1.1 Data Conventions..................................1
2. ISMP Overview..........................................2
3. General ISMP Packet Format.............................3
3.1 Frame Header......................................3
3.2 ISMP Packet Header................................4
3.3 ISMP Message Body.................................5
4. SBCD Protocol Operational Overview.....................5
5. Tag-Based Flood Message................................6
References.................................................8
Security Considerations....................................8
Author's Addresses.........................................8
1. Introduction
This Internet-Draft is being distributed to members of the Internet
community in order to solicit reactions to the proposals
contained herein. While the specification discussed here
may not be directly relevant to the research problems of the
Internet, it may be of interest to researchers and implementers.
1.1 Data Conventions
The methods used in this memo to describe and picture data
adhere to the standards of Internet Protocol documentation
K. Dobbins, et. al. [Page 1]
INTERNET-DRAFT SBCD Protocol Specification April 1997
[RFC1700], in particular:
The convention in the documentation of Internet Protocols
is to express numbers in decimal and to picture data in
"big-endian" order. That is, fields are described left
to right, with the most significant octet on the left and
the least significant octet on the right.
The order of transmission of the header and data
described in this document is resolved to the octet
level. Whenever a diagram shows a group of octets, the
order of transmission of those octets is the normal order
in which they are read in English.
Whenever an octet represents a numeric quantity the left
most bit in the diagram is the high order or most
significant bit. That is, the bit labeled 0 is the most
significant bit.
Similarly, whenever a multi-octet field represents a
numeric quantity the left most bit of the whole field is
the most significant bit. When a multi-octet quantity is
transmitted the most significant octet is transmitted
first.
2. ISMP Overview
The InterSwitch Message Protocol (ISMP) is used for interswitch
communication within distributed connection-oriented switching
networks. ISMP provides the following services:
- Topology services. Each switch maintains a distributed
topology of the switch fabric by exchanging the following
interswitch messages with other switches:
- Interswitch Keepalive messages (SNDM protocol) are sent by
each switch to announce its existence to its neighboring
switches and to establish the topology of the switch
fabric.
- Interswitch Spanning Tree BPDU messages and Interswitch
Remote Blocking messages (LSMP protocol) are used to
determine and maintain a loop-free flood path between all
network switches in the fabric. This flood path is used
for all undirected interswitch messages -- that is,
messages of the ARLD, SBCD and SFCT protocols.
- Interswitch Link State messages (VLS Protocol) are used to
determine and maintain a fully connected mesh topology
graph of the switch fabric. Call-originating switches use
the topology graph to determine the path over which to
route a call connection.
K. Dobbins, et. al. [Page 2]
INTERNET-DRAFT SBCD Protocol Specification April 1997
- Address resolution services. Interswitch Resolve messages
(ARLD protocol) are used to resolve a packet destination
address when the packet source and destination pair does not
match a known connection. Interswitch New User messages (also
part of the ARLD protocol) are used to provide end-station
address mobility between switches.
- Tag-based flooding. A tag-based broadcast method (SBCD
protocol) is used to restrict the broadcast of unresolved
packets to only those ports within the fabric that belong to
the same VLAN as the source.
- Call tapping services. Interswitch Tap messages (SFCT
protocol) are used to monitor traffic moving between two end
stations. Traffic can be monitored in one or both directions
along the connection path.
NOTE
This document describes the SBCD protocol.
Other ISMP protocols are described in other
RFCs. See the References section for a list of
these related RFCs.
3. General ISMP Packet Format
ISMP packets are of variable length and have the following
general structure:
- Frame header
- ISMP packet header
- ISMP message body
3.1 Frame Header
ISMP packets are encapsulated within an IEEE 802-compliant
frame using a standard header as shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
+ Destination address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
04 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source address +
08 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 | Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
16 | |
+ +
: :
K. Dobbins, et. al. [Page 3]
INTERNET-DRAFT SBCD Protocol Specification April 1997
Destination address
This 6-octet field contains the Media Access Control (MAC)
address of the multicast channel over which all switches in
the fabric receive ISMP packets. The destination address of
all ISMP packets contain a value of 01-00-1D-00-00-00.
Source address
This 6-octet field contains the physical (MAC) address of the
switch originating the ISMP packet.
Type
This 2-octet field identifies the type of data carried within
the frame. The type field of ISMP packets contains the value
0x81FD.
3.2 ISMP Packet Header
The ISMP packet header consists of 6 octets, as shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 |///////////////////////////////////////////////////////////////|
://////// Frame header /////////////////////////////////////////:
+//////// (14 octets) /////////+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 |///////////////////////////////| Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 | ISMP message type | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | |
+ +
: :
Frame header
This 14-octet field contains the frame header.
Version
This 2-octet field contains the version number of the
InterSwitch Message Protocol to which this ISMP packet
adheres. This document describes ISMP Version 2.0.
ISMP message type
This 2-octet field contains a value indicating which type
of ISMP message is contained within the message body. Valid
values are as follows:
K. Dobbins, et. al. [Page 4]
INTERNET-DRAFT SBCD Protocol Specification April 1997
1 (reserved)
2 Interswitch Keepalive messages (SNDM protocol)
3 Interswitch Link State messages (VLS protocol)
4 Interswitch Spanning Tree BPDU messages and Remote
Blocking messages (LSMP protocol)
5 Interswitch Resolve and New User messages (ARLD
protocol)
6 (reserved)
7 Tag-Based Flood messages (SBCD protocol)
8 Interswitch Tap messages (SFCT protocol)
SBCD protocol messages have a message type of 7.
Sequence number
This 2-octet field contains an internally generated sequence
number used by the various protocol handlers for internal
synchronization of messages.
3.3 ISMP Message Body
The ISMP message body is a variable-length field containing the
actual data of the ISMP message. The length and content of this
field are determined by the value found in the message type
field.
4. SBCD Protocol Operational Overview
The SBCD protocol is used to reduce the amount of broadcast
traffic across the switch fabric by restricting the broadcast
of unresolved packets to only those ports that belong to the
same VLAN as the source.
When a switch is unable to resolve the destination address of a
packet, it encapsulates the original packet with a tag-based
flooding header. This header contains a list of identifiers of
the VLANs to which the packet source belongs.
The encapsulated packet is then sent over the switch flood path.
The switch flood path is formed using a spanning tree algorithm
that provides a single path through the switch fabric and
guarantees loop-free delivery to every switch in the fabric.
When a switch receives a tag-based flood packet, it examines
the encapsulated header to determine the VLAN(s) to which the
packet should be sent. If any of the switch's local access
ports belong to one or more of the specified VLANs, the switch
strips off the tag-based header and forwards the original packet
out the appropriate access port(s).
The switch also forwards the entire encapsulated packet along
the flood path to its downstream neighboring switches, if any.
K. Dobbins, et. al. [Page 5]
INTERNET-DRAFT SBCD Protocol Specification April 1997
5. Tag-Based Flood Message
The SBCD tag-based flood message consists of a variable number
of octets, as shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00 | |
+ Frame header / +
: ISMP packet header :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | SBCD version | Opcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | Status | Call Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 | |
+ Source MAC of packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
32 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Originating switch MAC +
36 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
40 | Count | |
+-+-+-+-+-+-+-+-+ +
44 | VLAN list |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n | |
+ +
: Original packet :
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n = 41 + length of VLAN list
Frame header/ISMP packet header
This 20-octet field contains the frame header and the ISMP
packet header.
SBCD version
This 2-octet field contains the version number of the SBCD
protocol to which this message adheres. This document
describes SBCD Version 1.
Opcode
This 2-octet field contains the operation code of the message.
K. Dobbins, et. al. [Page 6]
INTERNET-DRAFT SBCD Protocol Specification April 1997
The value here should be 1, indicating the message is a flood
request.
Status
This 2-octet field is currently unused. It is reserved for
future use.
Call tag
This 2-octet field contains the call tag of the end station
packet encapsulated within this tag-based flood message.
The call tag is a 16-bit value (generated by the originating
switch) that uniquely identifies the packet.
Source MAC of packet
This 6-octet field contains the physical (MAC) address of the
end station that originated the packet identified by the call
tag.
Originating switch MAC
This 6-octet field contains the physical (MAC) address of the
switch that issued the original tag-based flooded message.
Count
This 1-octet field contains the number of VLAN identifiers
included in the VLAN list.
VLAN list
This variable-length field contains a list of the VLAN
identifiers of all VLANs to which the source end station
belongs. Each entry in this list has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value length | |
+-+-+-+-+-+-+-+-+ +
| VLAN identifier value |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 1-octet value length field contains the length of the VLAN
identifier. VLAN identifiers can be from 1 to 16 characters
long.
K. Dobbins, et. al. [Page 7]
INTERNET-DRAFT SBCD Protocol Specification April 1997
Original packet
This variable-length field contains the original packet as
sent by the source end station.
References
[RFC1700] Reynolds, S.J., Postel, J. Assigned Numbers.
October 1994.
Dobbins, K., et. al. ARLD Protocol Specification
Work in Progress.
Dobbins, K., et. al. ISM Protocol Specification
Work in Progress
Dobbins, K., et. al. LSMP Protocol Specification
Work in Progress.
Dobbins, K., et. al. SFCT Protocol Specification
Work in Progress.
Dobbins, K., et. al. SNDM Protocol Specification
Work in Progress.
Dobbins, K., et. al. VLS Protocol Specification
Work in Progress.
Security Considerations
Security issues are not discussed in this document.
Authors' Addresses
Cabletron Systems, Inc., is located at:
Post Office Box 5005
Rochester, NH 03866-5005
(603) 332-9400
Kurt Dobbins Email: dobbins@ctron.com
Tom Grant Email: tgrant@ctron.com
Dave Ruffen Email: ruffen@ctron.com
INTERNET-DRAFT EXPIRES: OCTOBER 1997 INTERNET-DRAFT