One document matched: draft-rfced-info-livingston-00.txt
INTERNET-DRAFT EXPIRES OCTOBER 1997 INTERNET-DRAFT
Network Working Group K. Dobbins
INTERNET-DRAFT T. Grant
Category: Informational J. Livingston
D. Ruffen
Cabletron Systems Incorporated
April 1997
SNDM Protocol Specification
<draft-rfced-info-livingston-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 Neighbor Discovery and Maintenance (SNDM) protocol
is part of the InterSwitch Message Protocol (ISMP). ISMP was
designed to facilitate interswitch communication within
distributed connection-oriented switching networks. Switches
use the SNDM protocol to discover their neighboring switches
and establish the topology of the switch fabric.
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. SNDM Protocol Operational Overview ....................5
5. Interswitch Keepalive Message..........................6
6. Port States............................................7
7. Timers.................................................8
References.................................................8
Security Considerations....................................9
Author's Addresses.........................................9
1. Introduction
This memo 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
K. Dobbins, et. al. [Page 1]
I/D SNDM Protocol Specification April 1997
adhere to the standards of Internet Protocol documentation
[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 leftmost
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 (VLSP 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]
I/D SNDM 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 SNDM 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]
I/D SNDM 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]
I/D SNDM Protocol Specification April 1997
1 (reserved)
2 Interswitch Keepalive messages (SNDM protocol)
3 Interswitch Link State messages (VLSP 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)
SNDM protocol messages have a message type of 2.
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. SNDM Protocol Operational Overview
Switches use the SNDM protocol to detect their switch neighbors
and establish the topology of the switching fabric.
At initialization, each switch sends an Interswitch Keepalive
message out all local ports except those which have been
preconfigured such that they cannot be Network ports (see Port
States). Then, as each switch discovers its neighboring
switches via incoming Interswitch Keepalive messages, it
notifies its local topology services who then build the
topology tables for the switching fabric.
Each switch continues to send Interswitch Keepalive messages at
regular intervals (currently 5 seconds). If a switch has not
heard from one of its neighbors for some predetermined interval
(see Timers), notification is sent to all interested services
and the neighboring switch is removed from the topology table.
K. Dobbins, et. al. [Page 5]
I/D SNDM Protocol Specification April 1997
5. Interswitch Keepalive Message
The SNDM Interswitch Keepalive 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 | Switch IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | Checksum | Switch ID length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 | |
: Switch ID :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n | |
+ Chassis MAC address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Base MAC count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n1 | |
: Base MAC addresses :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n = 28 + switch ID length
n1 = n + 8
Frame header/ISMP packet header
This 20-octet field contains the frame header and the ISMP
packet header.
Switch IP address
This 4-octet field contains the Internet Protocol (IP)
address of the sending switch.
Checksum
This 2-octet field contains the checksum value calculated
for the ISMP message, including the ISMP header.
Switch ID length
This 2-octet field contains the length of the Switch ID
field. This field always contains a value of 10.
K. Dobbins, et. al. [Page 6]
I/D SNDM Protocol Specification April 1997
Switch ID
This 10-octet field contains the internal ISMP identifier of
the sending switch. The identifier is generated by the
sending switch and consists of the 6-octet physical (MAC)
address of the switch, followed by a 4-octet value
containing the logical port number over which the switch
sent the SNDM packet.
Chassis MAC
This 6-octet field contains the physical (MAC) address of
the chassis of the sending switch.
Base MAC count
This 2-octet field contains the number of entries in the
list of Base MAC addresses.
Base MAC addresses
This variable-length field contains a list of the physical
(MAC) addresses of all neighboring switches that the sending
switch has previously discovered on the port over which the
message was sent. Each address is 6 octets long. The
number of addresses is found in the Base MAC count field.
6. Port States
Each port on a switch can be in one of four different states.
- Unknown. This is the default state of all ports at
initialization. Once the state of a port is determined, it
is returned to the Unknown state under two conditions:
- If the last switch is lost on a Network port.
- If the last end user is lost on an Access port.
- Network. A port is deemed a Network port when the switch
has received an Interswitch Keepalive message over the port.
- Going to Access. When any packet other than an Interswitch
Keepalive message is received over an Unknown port, the
state of the port is changed to Going to Access and a timer
is activated. If the timer expires without an Interswitch
Keepalive message being received over the port, the port
state changes to Access.
- Access. A port is deemed an Access port when any packet
other than an Interswitch Keepalive message has been
received over the port and the Going to Access timer has
expired. A port can also be administratively designated an
K. Dobbins, et. al. [Page 7]
I/D SNDM Protocol Specification April 1997
Access "control" port, meaning the port is to remain an
Access port, regardless of the type of messages that are
received on it. Interswitch Keepalive messages are not sent
over Access control ports.
Three other types of ports are recognized: the host management
port, host data port, and host control port. These ports are
designated at initialization and are used to access the host
CPU. Interswitch Keepalive messages are not sent over these
ports.
7. Timers
The SNDM protocol uses three timers.
- Send Hello timer. The Send Hello timer is used to control
the interval at which Interswitch Keepalive messages are
sent.
- Aging timer. The Aging Timer is used to detect when
communication with a neighboring switch has been lost.
- Going to Access timer. The Going to Access timer is used to
synchronize the transition of a port state to Access and
prevent a port from being prematurely designation as an
Access port during network initialization. If an Unknown
port receives any packet other than an Interswitch Keepalive
message, the port state is set to Going To Access. If the
switch receives an Interswitch Keepalive message over that
port before the timer expires, the port state is changed to
Network. Otherwise, when the timer expires, the port state
is changed to Access.
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. SBCD Protocol Specification, Work in Progress.
Dobbins, K., et. al. SFCT Protocol Specification, Work in Progress.
Dobbins, K., et. al. VLS Protocol Specification, Work in Progress.
K. Dobbins, et. al. [Page 8]
I/D SNDM Protocol Specification April 1997
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
John Livingston Email: jlston@ctron.com
Dave Ruffen Email: ruffen@ctron.com
K. Dobbins, et. al. [Page 9]
INTERNET-DRAFT EXPIRES OCTOBER 1997 INTERNET-DRAFT
| PAFTECH AB 2003-2026 | 2026-04-24 13:07:16 |