One document matched: draft-rfced-info-benoit-00.txt
INTERNET-DRAFT EXPIRES: OCTOBER 1997 INTERNET-DRAFT
Network Working Group K. Dobbins
DRAFT J. Benoit
Category: Informational T. Grant
D. Ruffen
Cabletron Systems Incorporated
April 1997
Loop-free Interswitch Message Path (LSMP) Protocol
<draft-rfced-info-benoit-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 Loop-Free Interswitch Message Path (LSMP) protocol is part
of the InterSwitch Message Protocol (ISMP). ISMP was designed
to facilitate interswitch communication within distributed
connection-oriented switching networks. The LSMP protocol is
used to create and maintain the flood path over which undirected
ISMP messages are sent.
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. LSMP Protocol Operational Overview..................5
4.1 Maintaining the Spanning Tree..................5
4.2 Remote Blocking................................6
5. Interswitch Spanning Tree BPDU Message..............7
6. Interswitch Remote Blocking Message.................8
References..............................................9
Security Considerations.................................9
Author's Addresses.....................................10
1. Introduction
This 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]
DRAFT LSMP 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]
DRAFT LSMP 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 LSMP 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]
DRAFT LSMP 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]
DRAFT LSMP 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)
LSMP protocol messages have a message type of 4.
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. LSMP Protocol Operational Overview
The LSMP protocol is used to create and maintain the flood
control path over which undirected ISMP messages are sent.
(Undirected messages are those of the ARLD, SBCD, and SFCT
protocols.) There are two parts to this process:
- Maintaining the spanning tree
- Remote blocking
4.1 Maintaining the Spanning Tree
In a network with redundant network links, a packet traveling
between switches can potentially be caught in an infinite loop --
an intolerable situation in a LAN environment. However, it is
possible to reduce a network topology to a single configuration
(known as a spanning tree) such that there is, at most, one path
between any two switches.
The spanning tree is created and maintained using the Spanning
Tree Algorithm defined by the IEEE 802.1d standard.
NOTE
A detailed discussion of this algorithm is
beyond the scope of this document. See
[IEEE802] for more information.
K. Dobbins, et. al. [Page 5]
DRAFT LSMP Protocol Specification April 1997
To implement the Spanning Tree Algorithm, switches exchange
Interswitch Spanning Tree BPDU messages containing encapsulated
IEEE 802.2-compliant Logical Link Control (LLC) frames that, in
turn, contain Bridge Protocol Data Units (BPDUs). There are two
types of BPDUs:
- Configuration (CFG) BPDUs are exchanged during the switch
discovery process, following the receipt of an Interswitch
Keepalive message [Work in Progress]. They are used to initialize
the spanning tree.
- Topology Change Notification (TCN) BPDUs are exchanged when
changes in the network topology are detected by the Spanning
Tree Algorithm. They are used to redefine the spanning tree
to reflect the current topology.
See [IEEE802] for detailed descriptions of these BPDUs.
After the spanning tree has been computed, each network port on
a switch will be in one of two states:
- Forwarding. A port in the Forwarding state will be used to
transmit all ISMP messages.
- Blocking. A port in the Blocking state will not be used to
forward undirected ISMP messages -- those with a ISMP
message type of 5 (ARLD protocol), 7 (SBCD protocol) or 8
(SFCT protocol). Blocking the transmission of these
messages on selected ports prevents message duplication
arising from multiple paths that exist in the network
topology. Note that all other types of ISMP message will be
transmitted.
4.2 Remote Blocking
As mentioned in Maintaining the Spanning Tree, once the spanning
tree has been computed, each network port on a switch will be in
one of two states: Forwarding or Blocking.
NOTE
The IEEE 802.1d standard specifies other port
states used during the initialization of the
spanning tree. These states are not relevant
to the discussion here.
Although a port in the Blocking state will not forward undirected
ISMP messages, it may still receive them. Any such message
received will ultimately be discarded, but at the cost of CPU
time necessary to process the packet.
K. Dobbins, et. al. [Page 6]
DRAFT LSMP Protocol Specification April 1997
To prevent such unnecessary transmission of undirected messages
to a port in the Blocking state, the port's owner switch can set
remote blocking on the link by sending an Interswitch Remote
Blocking message out over the port. This notifies the switch on
the other end of the link that ISMP messages of type 5, 7 or 8
should not be sent over the link, regardless of the state of the
sending port.
Each switch sends an Interswitch Remote Blocking message out all
its network ports at some predetermined interval (currently 5
seconds). A flag within the message indicates whether remote
blocking should be turned on or off over the link.
5. Interswitch Spanning Tree BPDU Message
The LSMP Interswitch Spanning Tree BPDU 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 | LSMP version | Message type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | Message flags | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
28 | :
: BPDU packet +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame header/ISMP packet header
This 20-octet field contains the frame header and the ISMP
packet header.
LSMP version
This 2-octet field contains the version number of the LSMP
protocol to which this message adheres. This document
describes LSMP Version 1.
Message type
This 2-octet field contains the operation type of the
message. Valid values are as follows:
K. Dobbins, et. al. [Page 7]
DRAFt LSMP Protocol Specification April 1997
1 The message is an Interswitch Spanning Tree BPDU
message.
2 The message is an Interswitch Remote Blocking
message.
Message flags
This 2-octet field is currently unused. It is reserved for
future use.
BPDU packet
This variable-length field contains an IEEE-compliant 802.2
Logical Link Control (LLC) frame containing the Bridge
Protocol Data Unit of the message. See [IEEE802] for a
detailed description of a BPDU.
6. Interswitch Remote Blocking Message
The LSMP Interswitch Remote Blocking message consists of 30
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 | LSMP version | Message type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | Message flags | Blocking flag ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 | ... Blocking flag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame header/ISMP packet header
This 20-octet field contains the frame header and the ISMP
packet header.
LSMP version
This 2-octet field contains the version number of the LSMP
protocol to which this message adheres. This document
describes LSMP Version 1.
Message type
This 2-octet field contains the operation type of the
message. Valid values are as follows:
K. Dobbins, et. al. [Page 8]
DRAFT LSMP Protocol Specification April 1997
1 The message is an Interswitch Spanning Tree BPDU
message.
2 The message is an Interswitch Remote Blocking
message.
Message flags
This 2-octet field is currently unused. It is reserved for
future use.
Blocking flag
This 4-octet field contains a flag indicating the state of
remote blocking on the link over which the message was
received. A value of 1 indicates remote blocking is on and
no undirected ISMP messages (those with a ISMP message type
of 5, 7 or 8) should be sent over the link. A value of 0
indicates remote blocking is off.
References
[RFC1700] Reynolds, S.J., Postel, J. Assigned Numbers.
October 1994.
[IEEE802] IEEE Standard 802.1d. 1990.
Dobbins, K., et. al. ARLD Protocol Specification
Work in Progress.
Dobbins, K., et. al. ISM Protocol Specification
Work in Progress.
Dobbins, K., et. al. SBCD 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.
K. Dobbins, et. al. [Page 9]
DRAFT LSMP Protocol Specification April 1997
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
Joe Benoit Email: jbenoit@ctron.com
Tom Grant Email: tgrant@ctron.com
Dave Ruffen Email: ruffen@ctron.com
INTERNET-DRAFT EXPIRES: OCTOBER 1997 INTERNET-DRAFT
| PAFTECH AB 2003-2026 | 2026-04-23 20:42:57 |