home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_n_r
/
draft-rfced-info-grant-00.txt
< prev
next >
Wrap
Text File
|
1997-04-17
|
32KB
|
816 lines
INTERNET-DRAFT EXPIRES: OCTOBER 1997 INTERNET-DRAFT
Network Working Group K. Dobbins
Expire in six months T. Grant
Category: Informational J. Liessner
D. Ruffen
Cabletron Systems Incorporated
April 1997
Switched Fabric Connection Tap (SFCT) Protocol
<draft-rfced-info-grant-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 Switched Fabric Connection Tap (SFCT) protocol is part of
the InterSwitch Message Protocol (ISMP). ISMP was designed to
facilitate interswitch communication within distributed
connection-oriented switching networks. The SFCT protocol is
used to monitor communication between two end stations.
Table of Contents
Status of this Memo.....................................1
Abstract................................................1
1. Introduction........................................2
1.1 Data Conventions...............................2
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. SFCT Protocol Operational Overview..................5
4.1 Definitions....................................5
4.1.1 Ingress Switch..........................6
4.1.2 Egress Switch...........................6
4.1.3 Intermediate Switch.....................6
4.1.4 Call Connection Path....................6
4.1.5 Originating Switch......................6
4.1.6 Probe...................................6
4.1.7 Probe Switch............................6
4.1.8 Undirected Messages.....................7
4.1.9 Switch Flood Path.......................7
4.1.10 Upstream Neighbor......................7
4.1.11 Downstream Neighbor....................7
4.2 Tapping a Connection...........................7
4.2.1 Types of Tap Connections................7
4.2.2 Locating the Probe and
Establishing the Tap Connection.......8
4.2.3 Status Field............................9
4.3 Untapping a Connection........................10
5. Interswitch Tap/Untap Message.....................11
K. Dobbins, et. al. [Page 1]
DRAFT SFCT Protocol Specification April 1997
References.............................................14
Security Considerations................................14
Author's Addresses.....................................14
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
[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
K. Dobbins, et. al. [Page 2]
DRAFT SFCT Protocol Specification April 1997
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.
- 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 SFCT 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:
K. Dobbins, et. al. [Page 3]
DRAFT SFCT Protocol Specification April 1997
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 | |
+ +
: :
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 | |
+ +
: :
K. Dobbins, et. al. [Page 4]
DRAFT SFCT Protocol Specification April 1997
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:
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)
SFCT protocol messages have a message type of 8.
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. SFCT Protocol Operational Overview
The SFCT protocol is used to monitor traffic moving along a
connection between two end stations. Traffic can be monitored
in one or both directions along the connection path.
4.1 Definitions
The following terms are used in this description of the SFCT
protocol.
K. Dobbins, et. al. [Page 5]
DRAFT SFCT Protocol Specification April 1997
4.1.1 Ingress Switch
The ingress switch is the owner switch of the source end
station of the call connection. That is, the source end
station is attached to one of the local access ports of the
switch.
4.1.2 Egress Switch
The egress switch is the owner switch of the destination end
station of the call connection. That is, the destination end
station is attached to one of the local access ports of the
switch.
4.1.3 Intermediate Switch
An intermediate switch is any switch along the call connection
path on which the connection packets enter and leave over
network links. Note that the following types of connections
have no intermediate switches:
- Call connections between source and destination end stations
that are attached to the same switch -- that is the ingress
switch is the same as the egress switch
- Call connections where the ingress and egress switches are
physical neighbors connected by a single network link
4.1.4 Call Connection Path
A call connection path consists of 0 to 7 links between
switches. It is selected from a list of alternate equal cost
paths provided by the Path Service, and is chosen to load
balance traffic across the fabric.
4.1.5 Originating Switch
The originating switch is the switch that requests the call
tap. Any switch along a call connection path may request a tap
on that call connection.
4.1.6 Probe
The tap probe is the device to receive a copy of the call
connection data. The probe is attached to a port on the probe
switch.
4.1.7 Probe Switch
The probe switch (also known as the terminating switch) is the
switch to which the probe is attached. The probe switch can be
anywhere in the topology.
K. Dobbins, et. al. [Page 6]
DRAFT SFCT Protocol Specification April 1997
4.1.8 Undirected Messages
Undirected messages are those messages that are (potentially)
sent to all switches in the switch fabric -- that is, they are
not directed to any particular switch. ISMP messages of the
SBCD, ARLD, and SFCT protocols are undirected messages.
4.1.9 Switch Flood Path
The switch flood path is used to send undirected ISMP messages
throughout the switch fabric. The 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 other
switch in the fabric.
4.1.10 Upstream Neighbor
A switch's upstream neighbor is that switch attached to the in
port of the switch flood path -- that is, the switch from which
the undirected message was received. Note that each switch
receiving an undirected message has, at most, one upstream
neighbor, and the originator of any undirected ISMP message
has no upstream neighbors.
4.1.11 Downstream Neighbor
A switch's downstream neighbors are those switches attached to
all out ports of the flood path except the port on which the
undirected message was received. Note that for each undirected
message some number of switches have no downstream neighbors.
4.2 Tapping a Connection
A request to tap a call connection between two end stations can
originate on any switch along the call connection path -- the
ingress switch, the egress switch, or any of the intermediate
switches. The call connection must have already been
established before a call tap request can be issued. The probe
device can be attached to any switch in the topology.
4.2.1 Types of Tap Connections
A call tap is enabled by setting up an auxiliary tap connection
associated with the call being monitored. Since the tap must
originate on a switch somewhere along the call connection path,
the tap connection path will pass through one or more of the
switches along the call path. However, since the probe switch
can be anywhere in the switch fabric, the tap path and the call
path may diverge at some point.
Therefore, on each switch along the tap path, the tap
connection is established in one of three ways:
K. Dobbins, et. al. [Page 7]
DRAFT SFCT Protocol Specification April 1997
- The existing call connection is used with no modification.
When both the call path and tap path pass through the
switch, and the in and out ports of both connections are
identical, the switch uses the existing call connection to
route the tap.
- The existing call connection is modified.
When both the call path and tap path pass through the
switch, but the call path out port is different from the tap
path out port, the switch enables an extra out port in
either one or both directions of the call connection,
depending on the direction of the tap. This happens under
two conditions.
- If the switch is also the probe switch, an extra out port
is enabled to the probe.
- If the switch is the point at which the call path and the
tap path diverge, an extra out port is enabled to the
downstream neighbor on that leg of the flood path on which
the probe switch is located.
- A new connection is established.
If the call path does not pass through the switch (because
the tap path has diverged from the call path), a completely
new connection is established for the tap.
4.2.2 Locating the Probe and Establishing the Tap Connection
To establish a call tap, the originating switch formats an
Interswitch Tap request message and sends it out over the flood
path to all other switches in the topology.
NOTE
If the originating switch is also the probe
switch, no Interswitch Tap request message is
necessary.
As the Interswitch Tap request message travels out along the
flood path, each switch receiving the message checks to see if
it is the probe switch and does the following:
- If the switch is the probe switch, it establishes the tap
connection by either setting up a new connection or
modifying the call connection, as appropriate (see section
Types of Tap Connections). It then reformats the Tap
request message to be a Tap response message with a status
indicating that the probe has been found, and sends the
message back to its upstream neighbor.
K. Dobbins, et. al. [Page 8]
DRAFT SFCT Protocol Specification April 1997
- If the switch is not the probe switch, it forwards the Tap
request message to all its downstream neighbors (if any).
- If the switch is not the probe switch and has no downstream
neighbors, it reformats the Tap request message to be a Tap
response message with a status indicating that the probe is
not located on that leg of the spanning tree. It then
sends the response message back to its upstream neighbor.
When a switch forwards an Interswitch Tap request message to
its downstream neighbors, it keeps track of the number of
requests it has sent out.
- If a response is received with a status indicating that the
probe switch is located somewhere downstream, the switch
establishes the appropriate type of tap connection (see
section Types of Tap Connections). It then formats a Tap
response message with a status indicating that the probe has
been found and passes the message to its upstream neighbor.
- If no responses are received with a status indicating that
the probe switch is located downstream, the switch formats a
Tap response message with a status indicating that the probe
has not been found and passes the message to its upstream
neighbor.
4.2.3 Status Field
The status field of the Tap request/response message contains
information about the state of the tap. Some of these status
values are transient and are merely used to track the progress
of the Tap request. Other status values are stored in the tap
table of each switch along the tap path for use when the tap is
torn down. The possible status values are as follows:
- StatusUnassigned. This is the initial status of the Tap
request message.
- OutportDecisionUnknown. The Tap request is still moving
downstream along the flood path. The probe switch had not
yet been found.
- ProbeNotFound. The probe switch is not located on this leg
of the spanning tree.
- DisableOutport. The probe switch is located on this leg of
the spanning tree, and the switch has had to either modify
the call connection or establish a new connection to
implement the tap (see section Types of Tap Connections).
When the tap is torn down, the switch will have to disable
any additional outports that have been enabled for the tap.
K. Dobbins, et. al. [Page 9]
DRAFT SFCT Protocol Specification April 1997
- KeepOutport. The probe switch is located on this leg of the
spanning tree, and the switch was able to route the tap over
the existing call path (see section Types of Tap
Connections). Any ports used for the tap will remain
enabled when the tap is torn down.
4.3 Untapping a Connection
A request to untap a call connection must be issued on the tap
originating switch -- that is, the same switch that issued the
tap request.
To untap a call connection, the originating switch sends an
Interswitch Untap request message out over the switch flood
path to all other switches in the topology. The message is
sent over the flood path, rather than the tap connection path,
to ensure that all switches that know of the tap are properly
notified, even if the switch topology has changed since the tap
was established.
When a switch receives an Interswitch Untap request message, it
checks to see if it is handling a tap for the specified call
connection. If so, the switch disables the tap connection, as
follows:
- If a new connection was added for the tap, the connection is
deleted from the connection table.
- If additional outports were enabled on the call connection,
they are disabled.
The switch then forwards the Untap request message to its
downstream neighbor (if any). If the switch has no downstream
neighbors, it formats an Untap response and sends the message
back to its upstream neighbor.
When a switch forwards an Untap request message to its
downstream neighbors, it keeps track of the number of requests
it has sent out and does not respond back to its upstream
neighbor until all Untap requests have been responded to. Once
all responses have been received, the switch handles any final
cleanup for the tap and then sends a single Untap response
message to its upstream neighbor.
K. Dobbins, et. al. [Page 10]
DRAFT SFCT Protocol Specification April 1997
5. Interswitch Tap/Untap Message
The SFCT Interswitch Tap 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 | SFCT version | Message type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | Status | Error code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 | Header type | Header length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
32 | Direction | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Probe switch MAC +
36 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
40 | Probe port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
44 | |
+ +
48 | (Reserved) |
+ +
52 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
56 | |
+ +
| Header |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame header/ISMP packet header
This 20-octet field contains the frame header and the ISMP
packet header.
SFCT version
This 2-octet field contains the version number of the SFCT
protocol to which this message adheres. This document
describes SFCT 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 11]
DRAFT SFCT Protocol Specification April 1997
1 The message is a Tap request.
2 The message is a Tap response.
3 The message is an Untap request.
4 The message is an Untap response.
Status
This 2-octet field contains the current status of the tap
request. Valid values are as follows:
1 Switch must disable an outport on an untap.
(DisableOutport)
2 Switch must keep its outports on an untap.
(KeepOutport)
3 Probe has not been found on this leg of the spanning
tree. (ProbeNotFound)
4 Still searching for the probe switch.
(OutportDecisionUnknown)
5 Unassigned. (StatusUnassigned) This is the initial
switch status.
6 (reserved)
7 (reserved)
8 (reserved)
9 (reserved)
See section Status Field for details on the use of this
field.
Error code
This 2-octet field contains the response message error code
of the requested operation. Valid values are as follows:
1 Operation was successful. (NoError)
2 No response was heard from a downstream neighbor.
(Timeout)
3 Port does not exist on the probe switch. (BadPort)
4 Message was invalid. (InvalidMessage)
5 Version number was invalid. (IncompatibleVersions)
Header type
This 2-octet field contains the type of information
contained in the header field. In the current version of
the SFCT protocol, valid values are as follows:
1 (reserved)
2 Header contains destination and source end station
MAC addresses.
K. Dobbins, et. al. [Page 12]
DRAFT SFCT Protocol Specification April 1997
Header length
This 2-octet field contains the length of the header field.
In the current version of the SFCT protocol, this field
always contains a value of 12.
Direction
This 2-octet field contains a value indicating the type of
tap. Valid values are as follows:
1 (reserved)
2 Tap is bi-directional and data should be captured
flowing in either direction over the connection.
3 Tap is uni-directional and data should be captured
only when it flows from the source to the
destination.
Probe switch MAC
This 6-octet field contains the physical (MAC) address of
the switch to which the probe is attached.
Probe port
This 4-octet field contains the logical port number (on the
probe switch) to which the probe is attached.
Reserved
These 12 octets are reserved.
Header
This variable-length field contains the header that
identifies the connection being tapped. The length of the
header is stored in the length field.
In the current version of the SFCT protocol, this field is
12 octets long and contains the 6-octet physical address of
the connection's destination end station, followed by the 6-
octet physical address of the connection's source end
station, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination MAC address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source MAC address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
K. Dobbins, et. al. [Page 13]
DRAFT SFCT Protocol Specification April 1997
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. 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
Judy Liessner Email: liessner@ctron.com
Dave Ruffen Email: ruffen@ctron.com
INTERNET-DRAFT EXPIRES: OCTOBER 1997 INTERNET-DRAFT
