Network Working Group D. Ruffen
Request for Comments: 2643 T. Len
Category: Informational J. Yanacek
Cabletron Systems Incorporated
August 1999
Network Working Group D. Ruffen
Request for Comments: 2643 T. Len
Category: Informational J. Yanacek
Cabletron Systems Incorporated
August 1999
Cabletron's SecureFast VLAN Operational Model Version 1.8
Cabletron的SecureFast VLAN操作模型版本1.8
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
Cabletron's SecureFast VLAN (SFVLAN) product implements a distributed connection-oriented switching protocol that provides fast forwarding of data packets at the MAC layer. The product uses the concept of virtual LANs (VLANs) to determine the validity of call connection requests and to scope the broadcast of certain flooded messages.
Cabletron的SecureFast VLAN（SFVLAN）产品实现了一种面向分布式连接的交换协议，可在MAC层快速转发数据包。该产品使用虚拟局域网（VLAN）的概念来确定呼叫连接请求的有效性，并确定某些泛洪消息的广播范围。
Table of Contents
目录
1. Introduction............................................. 3
1.1 Data Conventions..................................... 3
1.2 Definitions of Commonly Used Terms................... 4
2. SFVLAN Overview.......................................... 6
2.1 Features............................................. 7
2.2 VLAN Principles...................................... 8
2.2.1 Default, Base and Inherited VLANs.............. 8
2.2.2 VLAN Configuration Modes....................... 8
2.2.2.1 Endstations............................ 8
2.2.2.2 Ports.................................. 9
2.2.2.3 Order of Precedence.................... 9
2.2.3 Ports with Multiple VLAN Membership............ 10
2.3 Tag/Length/Value Method of Addressing................ 10
2.4 Architectural Overview............................... 11
3. Base Services............................................ 13
4. Call Processing.......................................... 14
4.1 Directory Service Center............................. 14
4.1.1 Local Add Server............................... 15
1. Introduction............................................. 3
1.1 Data Conventions..................................... 3
1.2 Definitions of Commonly Used Terms................... 4
2. SFVLAN Overview.......................................... 6
2.1 Features............................................. 7
2.2 VLAN Principles...................................... 8
2.2.1 Default, Base and Inherited VLANs.............. 8
2.2.2 VLAN Configuration Modes....................... 8
2.2.2.1 Endstations............................ 8
2.2.2.2 Ports.................................. 9
2.2.2.3 Order of Precedence.................... 9
2.2.3 Ports with Multiple VLAN Membership............ 10
2.3 Tag/Length/Value Method of Addressing................ 10
2.4 Architectural Overview............................... 11
3. Base Services............................................ 13
4. Call Processing.......................................... 14
4.1 Directory Service Center............................. 14
4.1.1 Local Add Server............................... 15
4.1.2 Inverse Resolve Server......................... 15
4.1.3 Local Delete Server............................ 18
4.2 Topology Service Center.............................. 18
4.2.1 Neighbor Discovery Server...................... 18
4.2.2 Spanning Tree Server........................... 18
4.2.2.1 Creating and Maintaining
the Spanning Tree........... 19
4.2.2.2 Remote Blocking........................ 19
4.2.3 Link State Server.............................. 20
4.3 Resolve Service Center............................... 21
4.3.1 Table Server................................... 22
4.3.2 Local Server................................... 22
4.3.3 Subnet Server.................................. 22
4.3.4 Interswitch Resolve Server..................... 22
4.3.5 Unresolvable Server............................ 23
4.3.6 Block Server................................... 23
4.4 Policy Service Center................................ 24
4.4.1 Unicast Rules Server........................... 24
4.5 Connect Service Center............................... 25
4.5.1 Local Server................................... 25
4.5.2 Link State Server.............................. 25
4.5.3 Directory Server............................... 26
4.6 Filter Service Center................................ 26
4.7 Path Service Center.................................. 26
4.7.1 Link State Server.............................. 26
4.7.2 Spanning Tree Server........................... 27
4.8 Flood Service Center................................. 27
4.8.1 Tag-Based Flood Server......................... 27
5. Monitoring Call Connections.............................. 27
5.1 Definitions.......................................... 27
5.2 Tapping a Connection................................. 28
5.2.1 Types of Tap Connections....................... 28
5.2.2 Locating the Probe and Establishing
the Tap Connection.......... 29
5.2.3 Status Field................................... 30
5.3 Untapping a Connection............................... 31
6. Interswitch Message Protocol (ISMP)...................... 32
6.1 General Packet Structure............................. 32
6.1.1 Frame Header................................... 32
6.1.2 ISMP Packet Header............................. 33
6.1.2.1 Version 2.............................. 33
6.1.2.2 Version 3.............................. 34
6.1.3 ISMP Message Body.............................. 35
6.2 Interswitch BPDU Message............................. 35
6.3 Interswitch Remote Blocking Message.................. 36
6.4 Interswitch Resolve Message.......................... 37
6.4.1 Prior to Version 1.8........................... 37
6.4.2 Version 1.8.................................... 41
4.1.2 Inverse Resolve Server......................... 15
4.1.3 Local Delete Server............................ 18
4.2 Topology Service Center.............................. 18
4.2.1 Neighbor Discovery Server...................... 18
4.2.2 Spanning Tree Server........................... 18
4.2.2.1 Creating and Maintaining
the Spanning Tree........... 19
4.2.2.2 Remote Blocking........................ 19
4.2.3 Link State Server.............................. 20
4.3 Resolve Service Center............................... 21
4.3.1 Table Server................................... 22
4.3.2 Local Server................................... 22
4.3.3 Subnet Server.................................. 22
4.3.4 Interswitch Resolve Server..................... 22
4.3.5 Unresolvable Server............................ 23
4.3.6 Block Server................................... 23
4.4 Policy Service Center................................ 24
4.4.1 Unicast Rules Server........................... 24
4.5 Connect Service Center............................... 25
4.5.1 Local Server................................... 25
4.5.2 Link State Server.............................. 25
4.5.3 Directory Server............................... 26
4.6 Filter Service Center................................ 26
4.7 Path Service Center.................................. 26
4.7.1 Link State Server.............................. 26
4.7.2 Spanning Tree Server........................... 27
4.8 Flood Service Center................................. 27
4.8.1 Tag-Based Flood Server......................... 27
5. Monitoring Call Connections.............................. 27
5.1 Definitions.......................................... 27
5.2 Tapping a Connection................................. 28
5.2.1 Types of Tap Connections....................... 28
5.2.2 Locating the Probe and Establishing
the Tap Connection.......... 29
5.2.3 Status Field................................... 30
5.3 Untapping a Connection............................... 31
6. Interswitch Message Protocol (ISMP)...................... 32
6.1 General Packet Structure............................. 32
6.1.1 Frame Header................................... 32
6.1.2 ISMP Packet Header............................. 33
6.1.2.1 Version 2.............................. 33
6.1.2.2 Version 3.............................. 34
6.1.3 ISMP Message Body.............................. 35
6.2 Interswitch BPDU Message............................. 35
6.3 Interswitch Remote Blocking Message.................. 36
6.4 Interswitch Resolve Message.......................... 37
6.4.1 Prior to Version 1.8........................... 37
6.4.2 Version 1.8.................................... 41
6.5 Interswitch New User Message......................... 46
6.6 Interswitch Tag-Based Flood Message.................. 49
6.6.1 Prior to Version 1.8........................... 49
6.6.2 Version 1.8.................................... 52
6.7 Interswitch Tap/Untap Message........................ 55
7. Security Considerations.................................. 58
8. References............................................... 58
9. Authors' Addresses....................................... 59
10. Full Copyright Statement................................ 60
6.5 Interswitch New User Message......................... 46
6.6 Interswitch Tag-Based Flood Message.................. 49
6.6.1 Prior to Version 1.8........................... 49
6.6.2 Version 1.8.................................... 52
6.7 Interswitch Tap/Untap Message........................ 55
7. Security Considerations.................................. 58
8. References............................................... 58
9. Authors' Addresses....................................... 59
10. Full Copyright Statement................................ 60
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.
本备忘录将分发给互联网社区的成员，以征求对本文所载建议的反应。虽然这里讨论的规范可能与互联网的研究问题没有直接关系，但研究人员和实现人员可能对此感兴趣。
The methods used in this memo to describe and picture data adhere to the standards of Internet Protocol documentation [RFC1700]. In particular:
本备忘录中用于描述和描绘数据的方法符合互联网协议文件[RFC1700]的标准。特别地：
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.
每当一个八位组代表一个数字量时，图表中最左边的位就是高阶或最高有效位。也就是说，标记为0的位是最高有效位。
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.
类似地，每当一个多八位组字段表示一个数值时，整个字段最左边的位就是最高有效位。当传输多个八位组数量时，首先传输最重要的八位组。
This section contains a collection of definitions for terms that have a specific meaning for the SFVLAN product and that are used throughout the text.
本节包含对SFVLAN产品具有特定含义并贯穿全文的术语定义集合。
Switch ID
交换机ID
A 10-octet value that uniquely identifies an SFVLAN switch within the switch fabric. The value consists of the 6-octet base MAC address of the switch, followed by 4 octets of zeroes.
10个八位字节的值，用于唯一标识交换机结构中的SFVLAN交换机。该值由交换机的6个八位字节的基本MAC地址组成，后跟4个八位字节的零。
Network link
网络链路
The physical connection between two switches. A network link is associated with a network interface (or port) of a switch.
两个交换机之间的物理连接。网络链路与交换机的网络接口（或端口）相关联。
Network port
网络端口
An interface on a switch that attaches to another switch.
交换机上连接到另一个交换机的接口。
Access port
接入端口
An interface on a switch that attaches to a user endstation.
交换机上连接到用户终端站的接口。
Port ID
端口ID
A 10-octet value that uniquely identifies an interface of a switch. The value consists of the 6-octet base MAC address of the switch, followed by the 4-octet local port number of the interface.
唯一标识交换机接口的10个八位组值。该值由交换机的6个八位字节的基本MAC地址组成，后跟接口的4个八位字节的本地端口号。
Neighboring switches
相邻交换机
Two switches attached to a common (network) link.
连接到公共（网络）链路的两个交换机。
Call connection
呼叫连接
A mapping of user traffic through a switch that correlates the source and destination address pair specified within the packet to an inport and outport pair on the switch.
通过交换机的用户通信量映射，该交换机将数据包中指定的源地址对和目标地址对与交换机上的输入端口对和输出端口对相关联。
Call connection path
呼叫连接路径
A set of 0 to 7 network links over which user traffic travels between the source and destination endstations. Call connection paths are selected from a list of alternate equal cost paths calculated by the VLS protocol [IDvlsp], and are chosen to load balance traffic across the fabric.
一组0到7条网络链路，用户通信量通过这些链路在源端站和目的端站之间传输。呼叫连接路径从由VLS协议[IDvlsp]计算的备用等成本路径列表中选择，并被选择以在整个结构上实现流量负载平衡。
Ingress switch
入口开关
The owner switch of the source endstation of a call connection. That is, the source endstation is attached to one of the local access ports of the switch.
呼叫连接的源端站的所有者开关。也就是说，源端站连接到交换机的一个本地访问端口。
Egress switch
出口开关
The owner switch of the destination endstation of a call connection. That is, the destination endstation is attached to one of the local access ports of the switch.
呼叫连接的目标端站的所有者交换机。也就是说，目标端站连接到交换机的一个本地访问端口。
Intermediate switches
中间开关
Any switch along the call connection path on which user traffic enters and leaves over network links. Note that the following types of connections have no intermediate switches:
沿着呼叫连接路径的任何交换机，用户流量通过网络链路进入和离开该交换机。请注意，以下类型的连接没有中间开关：
- Call connections between source and destination endstations that are attached to the same switch -- that is, the ingress switch is the same as the egress switch. Note also that the path for this type of connection consists of 0 network links.
- 连接到同一交换机的源和目标端站之间的呼叫连接——也就是说，入口交换机与出口交换机相同。还请注意，此类型连接的路径由0个网络链接组成。
- Call connections where the ingress and egress switches are physical neighbors connected by a single network link. The path for this type of connection consists of a single network link.
- 呼叫连接，其中入口和出口交换机是通过单个网络链路连接的物理邻居。此类型连接的路径由单个网络链路组成。
InterSwitch Message protocol (ISMP)
交换机间消息协议（ISMP）
The protocol used for interswitch communication between SFVLAN switches.
用于SFVLAN交换机之间交换机间通信的协议。
Undirected messages
无向消息
Messages that are (potentially) sent to all SFVLAN switches in the switch fabric -- that is, they are not directed to any particular switch. ISMP messages with a message type of 5, 7 or 8 are undirected messages.
（可能）发送到交换机结构中所有SFVLAN交换机的消息——也就是说，它们不会定向到任何特定交换机。消息类型为5、7或8的ISMP消息是无向消息。
Switch flood path
切换洪水路径
The path used to send undirected messages throughout the switch fabric. The switch flood path is formed using a spanning tree algorithm that provides a single path through the switch fabric that guarantees loop-free delivery to every other SFVLAN switch in the fabric.
用于在整个交换机结构中发送无向消息的路径。交换机泛洪路径是使用生成树算法形成的，该算法提供了通过交换机结构的单一路径，以确保结构中的每个其他SFVLAN交换机都能无环传输。
Upstream Neighbor
上游邻居
That switch attached to the inport of the switch flood path -- that is, the switch from which undirected messages are 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.
连接到交换机泛用路径输入端口的交换机，即接收无向消息的交换机。请注意，接收无向消息的每个交换机最多有一个上游邻居，而任何无向ISMP消息的发起人都没有上游邻居。
Downstream Neighbors
下游邻国
Those switches attached to all outports of the switch 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.
这些交换机连接到交换机泛用路径的所有输出端口，但接收无向消息的端口除外。请注意，对于每个无向消息，一些交换机没有下游邻居。
Virtual LAN (VLAN) identifier
虚拟局域网（VLAN）标识符
A VLAN is a logical grouping of ports and endstations such that all ports and endstations in the VLAN appear to be on the same physical (or extended) LAN segment even though they may be geographically separated.
VLAN是端口和端站的逻辑分组，使得VLAN中的所有端口和端站看起来都位于同一物理（或扩展）LAN段上，即使它们可能在地理上是分开的。
A VLAN identifier consists of a variable-length string of octets. The first octet in the string contains the number of octets in the remainder of the string -- the actual VLAN identifier value. A VLAN identifier can be from 1 to 16 octets long.
VLAN标识符由长度可变的八位字节字符串组成。字符串中的第一个八位字节包含字符串其余部分的八位字节数——实际的VLAN标识符值。VLAN标识符的长度可以是1到16个八位字节。
VLAN policy
VLAN策略
Each VLAN has an assigned policy value used to determine whether a particular call connection can be established. SFVLAN recognizes two policy values: Open and Secure.
每个VLAN都有一个分配的策略值，用于确定是否可以建立特定的呼叫连接。SFVLAN识别两个策略值：开放和安全。
Cabletron's SecureFast VLAN (SFVLAN) product implements a distributed connection-oriented switching protocol that provides fast forwarding of data packets at the MAC layer.
Cabletron的SecureFast VLAN（SFVLAN）产品实现了一种面向分布式连接的交换协议，可在MAC层快速转发数据包。
Within a connection-oriented switching network, user traffic is routed through the switch fabric based on the source and destination address (SA/DA) pair found in the arriving packet. For each SA/DA pair encountered by a switch, a "connection" is programmed into the switch hardware. This connection maps the SA/DA pair and the port on which the packet was received to a specific outport over which the packet is to be forwarded. Thus, once a connection has been established, all packets with a particular SA/DA pair arriving on a particular inport are automatically forwarded by the switch hardware out the specified outport.
在面向连接的交换网络中，用户流量根据到达数据包中的源地址和目标地址（SA/DA）对通过交换结构进行路由。对于交换机遇到的每个SA/DA对，一个“连接”被编程到交换机硬件中。此连接将SA/DA对和接收数据包的端口映射到要转发数据包的特定输出端口。因此，一旦建立了连接，到达特定输入端口的具有特定SA/DA对的所有数据包将由交换机硬件自动转发到指定输出端口。
A distributed switching environment requires that each switch be capable of processing all aspects of the call processing and switching functionality. Thus, each switch must synchronize its various databases with all other switches in the fabric or be capable of querying other switches for information it does not have locally.
分布式交换环境要求每个交换机能够处理呼叫处理和交换功能的所有方面。因此，每个交换机必须将其各种数据库与结构中的所有其他交换机同步，或者能够查询其他交换机以获取其在本地没有的信息。
SFVLAN accomplishes the above objectives by providing the following features:
SFVLAN通过提供以下功能实现上述目标：
- A virtual directory of the entire switch fabric.
- 整个交换机结构的虚拟目录。
- Call processing for IP, IPX and MAC protocols.
- IP、IPX和MAC协议的呼叫处理。
- Automatic call connection, based on VLAN policy.
- 自动呼叫连接，基于VLAN策略。
- Automatic call rerouting around failed switches and links.
- 围绕故障交换机和链路的自动呼叫重新路由。
In addition, SFVLAN optimizes traffic flow across the switch fabric by providing the following features:
此外，SFVLAN通过提供以下功能优化交换机结构上的流量：
- Broadcast interception and address resolution at the ingress port.
- 在入口端口进行广播拦截和地址解析。
- Broadcast scoping, restricting the flooding of broadcast packets to only those ports that belong to the same VLAN as the packet source.
- 广播作用域，将广播数据包的泛洪限制为仅属于与数据包源相同VLAN的端口。
- A single loop-free path (spanning tree) used for the flooding of undirected interswitch control messages. Only switches running the SFVLAN switching protocol are included in this spanning tree calculation -- that is, traditional bridges or routers configured for bridging are not included.
- 用于无向交换机间控制消息泛滥的单循环自由路径（生成树）。生成树计算中只包括运行SFVLAN交换协议的交换机——也就是说，不包括为桥接配置的传统网桥或路由器。
- Interception of both service and route advertisements with readvertisement sourced from the MAC address of the original advertiser.
- 截取服务和路线广告，并从原始广告商的MAC地址获取读授权。
Each SFVLAN switch port, along with its attached endstations, belongs to one or more virtual LANs (VLANs). A VLAN is a logical grouping of ports and endstations such that all ports and endstations in the VLAN appear to be on the same physical (or extended) LAN segment even though they may be geographically separated.
每个SFVLAN交换机端口及其连接的端站都属于一个或多个虚拟LAN（VLAN）。VLAN是端口和端站的逻辑分组，使得VLAN中的所有端口和端站看起来都位于同一物理（或扩展）LAN段上，即使它们可能在地理上是分开的。
VLAN assignments are used to determine the validity of call connection requests and to scope the broadcast of certain flooded messages.
VLAN分配用于确定呼叫连接请求的有效性，并确定某些泛洪消息的广播范围。
Each port is explicitly assigned to a default VLAN. At start-up, the default VLAN to which all ports are assigned is the base VLAN -- a permanent, non-deletable VLAN to which all ports belong at all times.
每个端口都显式分配给默认VLAN。在启动时，所有端口都分配到的默认VLAN是基本VLAN——一个永久的、不可删除的VLAN，所有端口在任何时候都属于该VLAN。
The network administrator can change the default VLAN of a port from the base VLAN to any other unique VLAN by using a management application known here as the VLAN Manager. A port's default VLAN is persistent -- that is, it is preserved across a switch reset.
网络管理员可以使用此处称为VLAN管理器的管理应用程序，将端口的默认VLAN从基本VLAN更改为任何其他唯一VLAN。端口的默认VLAN是持久的——也就是说，它在交换机重置过程中保持不变。
When an endstation attaches to a port for the first time, it inherits the default VLAN of the port. Using the VLAN Manager, the network administrator can reassign an endstation to another VLAN.
当终端站第一次连接到端口时，它将继承该端口的默认VLAN。使用VLAN管理器，网络管理员可以将端站重新分配给另一个VLAN。
Note:
注:
When all ports and all endstations belong to the base VLAN, the switch fabric behaves like an 802.1D bridging system.
当所有端口和所有端站都属于基本VLAN时，交换机结构的行为类似于802.1D桥接系统。
For both ports and endstations, there are a variety of VLAN configuration types, or modes.
对于端口和终端站，都有各种VLAN配置类型或模式。
For endstations, there are two VLAN configuration modes: inherited and static.
对于终端站，有两种VLAN配置模式：继承和静态。
- Inherited
- 继承
An inherited endstation becomes a member of its port's default VLAN.
继承的端站将成为其端口的默认VLAN的成员。
- Static
- 静止的
A static port becomes a member of the VLAN to which it has been assigned by the VLAN Manager.
静态端口成为VLAN管理器分配给它的VLAN的成员。
The default configuration mode for an endstation is inherited.
端站的默认配置模式是继承的。
For ports, there are two VLAN configuration modes: normal and locked.
对于端口，有两种VLAN配置模式：正常和锁定。
- Normal
- 典型的
All inherited endstations on a normal port become members of the port's default VLAN. All static endstations are members of the VLAN to which they were mapped by the VLAN Manager.
正常端口上所有继承的端站都将成为端口默认VLAN的成员。所有静态端站都是VLAN管理器映射到的VLAN的成员。
If the VLAN Manager reassigns the default VLAN of a normal port, the VLAN(s) for the attached endstations may or may not change, depending on the VLAN configuration mode of each endstation. All inherited endstations will become members of the new default VLAN. All others will retain membership in their previously mapped VLANs.
如果VLAN管理器重新分配正常端口的默认VLAN，则连接的端站的VLAN可能会更改，也可能不会更改，具体取决于每个端站的VLAN配置模式。所有继承的端站都将成为新默认VLAN的成员。所有其他人将保留其先前映射的VLAN中的成员资格。
- Locked
- 锁定
All endstations attached to a locked port can be members only of the port's default VLAN.
连接到锁定端口的所有端站只能是端口默认VLAN的成员。
If the VLAN Manager reconfigures a normal port to be a locked port, all endstations attached to the port become members of the port's default VLAN, regardless of any previous VLAN membership.
如果VLAN管理器将普通端口重新配置为锁定端口，则连接到该端口的所有端站都将成为该端口默认VLAN的成员，而不考虑以前的任何VLAN成员身份。
The default configuration mode for ports is normal.
端口的默认配置模式为正常。
On a normal port, static VLAN membership prevails over inherited membership.
在普通端口上，静态VLAN成员资格优先于继承的成员资格。
On a locked port, default VLAN membership prevails over any static VLAN membership.
在锁定端口上，默认VLAN成员资格优先于任何静态VLAN成员资格。
If a statically assigned endstation moves from a locked port back to a normal port, the endstation's static VLAN membership must be preserved.
如果静态分配的端站从锁定端口移回正常端口，则端站的静态VLAN成员身份必须保留。
A port can belong to multiple VLANs, based on the VLAN membership of its attached endstations.
一个端口可以属于多个VLAN，这取决于其连接的端站的VLAN成员身份。
For example, consider a port with three endstations, a default VLAN of "blue" and the following endstation VLAN assignments:
例如，考虑一个带有三个终端的端口，一个默认的“蓝色”VLAN和下面的终端站VLAN分配：
- One of the endstations is statically assigned to VLAN "red." - Another endstation is statically assigned to VLAN "green." - The third endstation inherits the default VLAN of "blue."
- 其中一个端站静态分配给VLAN“红色”。-另一个端站静态分配给VLAN“绿色”。-第三个端站继承默认VLAN“蓝色”
In this instance, the port is explicitly a member of VLAN "blue." But note that it is also implicitly a member of VLAN "red" and VLAN "green." Any tag-based flooding (Section 4.8) directed to any one of the three VLANs ("red," "green," or "blue") will be forwarded out the port.
在本例中，端口显式地是VLAN“蓝色”的成员。但请注意，它也隐式地是VLAN“红色”和VLAN“绿色”的成员。指向三个VLAN中任何一个（“红色”、“绿色”或“蓝色”）的任何基于标记的泛洪（第4.8节）都将转发出端口。
Within most computer networks, the concept of "address" is somewhat elusive because different protocols can (and do) use different addressing schemes and formats. For example, Ethernet (physical layer) addresses are six octets long, while IP (network layer) addresses are only four octets long.
在大多数计算机网络中，“地址”的概念有些难以捉摸，因为不同的协议可以（而且确实）使用不同的寻址方案和格式。例如，以太网（物理层）地址有六个八位字节长，而IP（网络层）地址只有四个八位字节长。
To distinguish between the various protocol-specific forms of addressing, many software modules within the SFVLAN product specify addresses in a format known as Tag/Length/Value (TLV). This format uses a variable-length construct as shown below:
为了区分各种特定于协议的寻址形式，SFVLAN产品中的许多软件模块以称为标记/长度/值（TLV）的格式指定地址。此格式使用可变长度构造，如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value length | |
+-+-+-+-+-+-+-+-+ +
| Address value |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value length | |
+-+-+-+-+-+-+-+-+ +
| Address value |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tag
标签
This 4-octet field specifies the type of address contained in the structure. The following address types are currently supported:
此4个八位字节字段指定结构中包含的地址类型。当前支持以下地址类型：
Tag name Value Address type
标记名值地址类型
aoMacDx 1 DX ethernet dst/src/type aoIpxSap 2 Sap aoIpxRIP 3 RIP aoInstYP 4 YP (YP name and version) aoInstUDP 5 UDP (Port #) aoIpxIpx 6 Ipx aoInetIP 7 IP (Net address) aoInetRPC 8 RPC (Program #) aoInetRIP 9 INET RIP aoMacDXMcast 10 Multicast unknown type aoAtDDP 11 AppleTalk DDP aoEmpty 12 (no address type specified) aoVlan 13 VLAN identifier aoHostName 14 Host name aoNetBiosName 15 NetBIOS name aoNBT 16 NetBIOS on TCP name aoInetIPMask 17 IP Subnet Mask aoIpxSap8022 18 Sap 8022 type service aoIpxSapSnap 19 Sap Snap type service aoIpxSapEnet 20 Sap Enet type service aoDHCPXID 21 DHCP Transaction ID aoIpMcastRx 22 IP class D receiver aoIpMcastTx 23 IP class D sender aoIpxRip8022 24 Ipx Rip 8022 type service aoIpxRipSnap 25 Ipx Rip type service aoIpxRipEnet 26 Ipx Rip Enet service aoATM 27 ATM aoATMELAN 28 ATM LAN Emulation Name
aoMacDx 1 DX以太网dst/src/类型aoIpxSap 2 Sap aoIpxRIP 3 RIP aoInstYP 4 YP（YP名称和版本）AOINSTUP 5 UDP（端口号）aoIpxIpx 6 Ipx aoInetIP 7 IP（网络地址）aoInetRPC 8 RPC（程序号）aoInetRIP 9 INETRIP aoMacDXMcast 10多播未知类型aoAtDDP 11 AppleTalk DDP aoEmpty 12（未指定地址类型）aoVlan 13 VLAN标识符aoHostName 14主机名aoNetBiosName 15 NetBIOS名称aoNBT 16 TCP上的NetBIOS名称aoInetIPMask 17 IP子网掩码aoIpxSap8022 18 Sap 8022类型服务aoIpxSapSnap 19 Sap快照类型服务aoIpxSapEnet 20 Sap Enet类型服务aoDHCPXID 21 DHCP事务ID AOIPMCASTX 22 IP类D接收器aoIpMcastTx 23 IP类D发送方aoIpxRip8022 24 Ipx Rip 8022类型服务aoIpxRipSnap 25 Ipx Rip类型服务AOIPxRIPET 26 Ipx Rip Enet服务aoATM 27 ATM aoATMELAN 28 ATM LAN仿真名称
Value length
值长度
This 1-octet field contains the length of the value of the address. The value here depends on the address type and actual value.
此1-octet字段包含地址值的长度。此处的值取决于地址类型和实际值。
Address value
地址值
This variable-length field contains the value of the address. The length of this field is stored in the Value length field.
此可变长度字段包含地址的值。此字段的长度存储在值长度字段中。
The SFVLAN software executes in the switch CPU and consists of the following elements as shown in Figure 1:
SFVLAN软件在交换机CPU中执行，由以下元素组成，如图1所示：
- The SFVLAN base services that handles traffic intercepted by the switch hardware. The base services are described in Section 3.
- 处理交换机硬件截获的流量的SFVLAN基本服务。第3节介绍了基本服务。
+------------------------------------------------------+
| +-----+ |
| +------------+ | I | |
| | CALL TAP <--(8)--> N | |
| +------------+ | T | |
| | E | |
| +-----------+ +------------+ | R | |
| | PATH | | TOPOLOGY | | S | |
| | | | | | W | |
| | Lnk state <------> Lnk state <--(3)--> I | | Flood path
| | | | | | T <----(5,7,8)-->
| | Span tree <------> Span tree <--(4)--> C | |
| +--^--------+ | | | H | |
| | | Discovery <--(2)--> | |
| | +------------+ | M | |
| | | E | |
| +------^--+ +--------+ | S | |
| | CONNECT >---------+--> FILTER | | S | |
| +--^------+ | +--------+ | A | | specific
| | | | G | | netwrk lnks
| | +--------^-+ +-------+ | E <----(2,3,4)-->
| +-------< POLICY | | FLOOD >--(7)--> | |
| +------^---+ +-^-----+ | P | |
| | | | R | |
| +-----------+ +-^-----------V-+ | O | |
| | DIRECTORY <----> RESOLVE <------(5)--> T | |
| +-----^-----+ +---^-----------+ | O | |
| | | | C | |
| | +---------^-----------+ | O | |
| +----< Base Services | | L | |
| +-----^---------------+ +-----+ |
+------------------|-----------------------------------+
Switch CPU |
| Host control port
+-----O----------------+
| ^ no cnx |
Layer 2 | | |
---------->O-----+--------------->O----------->
SA/DA pr | known cnx |
+----------------------+
Switch hardware
+------------------------------------------------------+
| +-----+ |
| +------------+ | I | |
| | CALL TAP <--(8)--> N | |
| +------------+ | T | |
| | E | |
| +-----------+ +------------+ | R | |
| | PATH | | TOPOLOGY | | S | |
| | | | | | W | |
| | Lnk state <------> Lnk state <--(3)--> I | | Flood path
| | | | | | T <----(5,7,8)-->
| | Span tree <------> Span tree <--(4)--> C | |
| +--^--------+ | | | H | |
| | | Discovery <--(2)--> | |
| | +------------+ | M | |
| | | E | |
| +------^--+ +--------+ | S | |
| | CONNECT >---------+--> FILTER | | S | |
| +--^------+ | +--------+ | A | | specific
| | | | G | | netwrk lnks
| | +--------^-+ +-------+ | E <----(2,3,4)-->
| +-------< POLICY | | FLOOD >--(7)--> | |
| +------^---+ +-^-----+ | P | |
| | | | R | |
| +-----------+ +-^-----------V-+ | O | |
| | DIRECTORY <----> RESOLVE <------(5)--> T | |
| +-----^-----+ +---^-----------+ | O | |
| | | | C | |
| | +---------^-----------+ | O | |
| +----< Base Services | | L | |
| +-----^---------------+ +-----+ |
+------------------|-----------------------------------+
Switch CPU |
| Host control port
+-----O----------------+
| ^ no cnx |
Layer 2 | | |
---------->O-----+--------------->O----------->
SA/DA pr | known cnx |
+----------------------+
Switch hardware
Figure 1: SFVLAN Architectural Overview
图1:SFVLAN体系结构概述
- Eight call processing service centers that provide the essential services required to process call connections. The call processing service centers are described in Section 4.
- 八个呼叫处理服务中心，提供处理呼叫连接所需的基本服务。第4节介绍了呼叫处理服务中心。
- A Call Tap module that supports the monitoring of call connections. The Call Tap module is described in Section 5.
- 支持呼叫连接监控的呼叫转接模块。第5节介绍了呼叫抽头模块。
- The InterSwitch Message Protocol (ISMP) that provides a consistent method of encapsulating and transmitting control messages exchanged between SFVLAN switches. (Note that ISMP is not a discrete software module. Instead, its functionality is distributed among those service centers and software modules that need to communicate with other switches in the fabric.) The Interswitch Message Protocol and the formats of the individual interswitch messages are described in Section 6.
- 交换机间消息协议（ISMP），提供封装和传输SFVLAN交换机之间交换的控制消息的一致方法。（请注意，ISMP不是一个离散的软件模块。相反，它的功能分布在需要与结构中的其他交换机通信的服务中心和软件模块之间。）第6节介绍了交换机间消息协议和各个交换机间消息的格式。
The SFVLAN base services act as the interface between the switch hardware and the SFVLAN service centers running on the switch CPU. This relationship is shown in Figure 2. This figure is a replication of the bottom portion of Figure 1.
SFVLAN基本服务充当交换机硬件和在交换机CPU上运行的SFVLAN服务中心之间的接口。这种关系如图2所示。此图是图1底部部分的复制。
| Directory Resolve |
| ^ ^ |
| | | |
| | +---------^-----------+ |
| +----< Base Services | |
| +-----^---------------+ |
+-------------------|--------------------------+
Switch CPU |
| Host control port
+-----O----------------+
| ^ no cnx |
Layer 2 | | |
---------->O-----+--------------->O----------->
SA/DA pr | known cnx |
+----------------------+
Switch hardware
| Directory Resolve |
| ^ ^ |
| | | |
| | +---------^-----------+ |
| +----< Base Services | |
| +-----^---------------+ |
+-------------------|--------------------------+
Switch CPU |
| Host control port
+-----O----------------+
| ^ no cnx |
Layer 2 | | |
---------->O-----+--------------->O----------->
SA/DA pr | known cnx |
+----------------------+
Switch hardware
Figure 2: Base Services
图2：基本服务
During normal operation of the switch, data packets arriving at any one of the local switch ports are examined in the switch hardware. If the packet's source and destination address (SA/DA) pair match a known connection, the hardware simply forwards the packet out the outport specified by the connection.
在交换机正常运行期间，在交换机硬件中检查到达任何一个本地交换机端口的数据包。如果数据包的源地址和目标地址（SA/DA）对与已知连接匹配，则硬件只需将数据包转发到连接指定的输出端口。
If the SA/DA pair do not match any known connection, the hardware diverts the packet to the host control port where it is picked up by the SFVLAN base services. The base services generate a structure known as a state box that tracks the progress of the call connection request as the request moves through the call processing service centers.
如果SA/DA对与任何已知连接不匹配，则硬件将数据包转移到主机控制端口，由SFVLAN基本服务在该端口拾取数据包。基本服务生成一个称为状态框的结构，在请求通过呼叫处理服务中心时跟踪呼叫连接请求的进度。
After creating the call's state box, the base services check to determine if the call is a duplicate of a call already being processed. If not, a request is issued to the Directory Service Center (Section 4.1) to add the call's source address to the local Node and Alias Tables. The base services then hand the call off to the Resolve Service Center (Section 4.3) for further processing.
创建呼叫状态框后，基本服务将检查以确定呼叫是否与已处理的呼叫重复。否则，将向目录服务中心（第4.1节）发出请求，将呼叫的源地址添加到本地节点和别名表中。然后，基础服务部门将呼叫转交给解决服务中心（第4.3节）进行进一步处理。
Call connection processing is handled by a set of eight service centers, each with one or more servers. The servers within a service center are called in a particular sequence. Each server records the results of its processing in the call connection request state box and passes the state box to the next server in the sequence.
呼叫连接处理由一组八个服务中心处理，每个中心有一个或多个服务器。服务中心内的服务器按特定顺序调用。每台服务器在“呼叫连接请求状态”框中记录其处理结果，并将状态框按顺序传递给下一台服务器。
In the sections that follow, servers are listed in the order in which they are called.
在下面的部分中，服务器按调用顺序列出。
The Directory Service Center is responsible for cataloging the MAC addresses and alias information for both local and remote endstations. The information is stored in two tables -- the Node Table and the Alias Table.
目录服务中心负责编目本地和远程终端站的MAC地址和别名信息。信息存储在两个表中——节点表和别名表。
- The Node Table contains the MAC addresses of endstations attached to the local switch. It also contains a cache of remote endstations detected by the Resolve Service Center (Section 4.3). Every entry in the Node Table has one or more corresponding entries in the Alias Table.
- 节点表包含连接到本地交换机的终端站的MAC地址。它还包含解析服务中心检测到的远程端站缓存（第4.3节）。节点表中的每个条目在别名表中都有一个或多个对应条目。
- The Alias Table contains protocol alias information for each endstation. An endstation alias can be a network address (such as an IP or IPX address), a VLAN identifier, or any other protocol identifier. Since every endstation is a member of at least one VLAN (the default VLAN for the port), there is always at least one entry in the Alias Table for each entry in the Node Table.
- 别名表包含每个端站的协议别名信息。端站别名可以是网络地址（如IP或IPX地址）、VLAN标识符或任何其他协议标识符。由于每个端站都是至少一个VLAN（端口的默认VLAN）的成员，因此对于节点表中的每个条目，别名表中始终至少有一个条目。
Note:
注:
The Node and Alias Tables must remain synchronized. That is, when an endstation's final alias is removed from the Alias Table, the endstation entry is removed from the Node Table.
节点表和别名表必须保持同步。也就是说，当从别名表中删除终点站的最终别名时，终点站条目将从节点表中删除。
Note that the total collection of all Node Tables and Alias Tables across all switches is known as the "virtual" directory of the switch fabric. The virtual directory contains address mappings of all known endstations in the fabric.
请注意，所有交换机上所有节点表和别名表的总集合称为交换机结构的“虚拟”目录。虚拟目录包含结构中所有已知端站的地址映射。
The Directory Local Add server adds entries to the local Node or Alias Tables. It is called by the base services (Section 3) to add a local endstation and by the Interswitch Resolve (Section 4.3.4) server to add an endstation discovered on a remote switch.
目录本地添加服务器向本地节点或别名表添加条目。基本服务（第3节）调用它来添加本地端站，Interswitch Resolve（第4.3.4节）服务器调用它来添加在远程交换机上发现的端站。
The Directory Inverse Resolve server is invoked when a new endstation has been discovered on the local switch (that is, when the Local Add server was successful in adding the endstation). The server provides two functions:
当在本地交换机上发现新的端站时（即，当本地添加服务器成功添加端站时），将调用目录反向解析服务器。服务器提供两个功能：
- It populates the Node and Alias Tables with local entries during switch initialization.
- 它在交换机初始化期间使用本地条目填充节点和别名表。
- It processes a new endstation discovered after the fabric topology has converged to a stable state.
- 它处理在结构拓扑收敛到稳定状态后发现的新端站。
In both instances, the processing is identical.
在这两种情况下，处理是相同的。
When a new endstation is detected on one of the switch's local ports, the Inverse Resolve server sends an Interswitch New User request message (Section 6.5) over the switch flood path to all other switches in the fabric. The purpose of the Interswitch New User request is two-fold:
当在交换机的一个本地端口上检测到新的端站时，反向解析服务器通过交换机泛用路径向结构中的所有其他交换机发送交换机间新用户请求消息（第6.5节）。Interswitch新用户请求的目的有两个：
- It informs the other switches of the new endstation address. Any entries for that endstation in the local databases of other switches should be dealt with appropriately.
- 它通知其他交换机新的端站地址。应适当处理其他交换机本地数据库中该终端站的任何条目。
- It requests information about any static VLAN(s) to which the endstation has been assigned.
- 它请求有关终端站已分配到的任何静态VLAN的信息。
When a switch receives an Interswitch New User request message from one of its upstream neighbors, it first forwards the message to all its downstream neighbors. No actual processing or VLAN resolution is attempted until the message reaches the end of the switch flood path and begins its trip back along the return path. This ensures that all switches in the fabric receive notification of the new user and have synchronized their databases.
当交换机从其一个上游邻居接收到交换机间新用户请求消息时，它首先将该消息转发给其所有下游邻居。在消息到达交换机泛用路径的末尾并开始沿返回路径返回之前，不会尝试实际处理或VLAN解析。这可确保结构中的所有交换机都接收到新用户的通知，并已同步其数据库。
If a switch receives an Interswitch New User request message but has no downstream neighbors, it does the following:
如果交换机接收到交换机间新用户请求消息，但没有下游邻居，则会执行以下操作：
- If the endstation was previously connected to one of the switch's local ports, the switch formulates an Interswitch New User Response message by loading the VLAN identifier(s) of the static VLAN(s) to which the endstation was assigned, along with its own MAC address. (VLAN identifiers are stored in Tag/Length/Value (TLV) format. See Section 2.3.) The switch then sets the message status field to NewUserAck, and returns the message to its upstream (requesting) neighbor.
- 如果终端站以前连接到交换机的一个本地端口，交换机将通过加载终端站分配到的静态VLAN的VLAN标识符及其自己的MAC地址来生成交换机间新用户响应消息。（VLAN标识符以Tag/Length/Value（TLV）格式存储。请参阅第2.3节。）然后交换机将消息状态字段设置为NewUserAck，并将消息返回给其上游（请求）邻居。
Otherwise, the switch sets the status field to NewUserUnknown and returns the message to its upstream neighbor.
否则，交换机将状态字段设置为NewUserUnknown，并将消息返回给其上游邻居。
- The switch then deletes the endstation from its local database, as well as any entries associated with the endstation in its connection table.
- 然后，交换机从其本地数据库中删除端站，以及在其连接表中与端站关联的任何条目。
When a switch forwards an Interswitch New User 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 requests have been responded to.
当交换机将交换机间新用户请求消息转发给其下游邻居时，它会跟踪已发送的请求数量，并且在所有请求都得到响应之前不会回复其上游邻居。
- As each response is received, the switch checks the status field of the message. If the status is NewUserAck, the switch retains the information in that response. When all requests have been responded to, the switch returns the NewUserAck response to its upstream neighbor.
- 收到每个响应时，开关检查消息的状态字段。如果状态为NewUserAck，则开关将保留该响应中的信息。当所有请求都已响应时，交换机将NewUserAck响应返回给其上游邻居。
- If all the Interswitch New User Request messages have been responded to with a status of NewUserUnknown, the switch checks to see if the endstation was previously connected to one of its local ports. If so, the switch formulates an Interswitch New User Response message by loading the VLAN identifier(s) of the static VLAN(s) to which the endstation was assigned, along with its own MAC address. The switch then sets the message status field to NewUserAck, and returns the message to its upstream (requesting) neighbor.
- 如果所有Interswitch New User Request（交换机间新用户请求）消息都已响应，且状态为NewUserUnknown，则交换机将检查端站之前是否连接到其一个本地端口。如果是这样，交换机通过加载终端站被分配到的静态VLAN的VLAN标识符及其自己的MAC地址来制定交换机间新用户响应消息。然后，交换机将消息状态字段设置为NewUserAck，并将消息返回给其上游（请求）邻居。
Otherwise, the switch sets the status field to NewUserUnknown and returns the message to its upstream neighbor.
否则，交换机将状态字段设置为NewUserUnknown，并将消息返回给其上游邻居。
- The switch then deletes the endstation from its local database, as well as any entries associated with the endstation in its connection table.
- 然后，交换机从其本地数据库中删除端站，以及在其连接表中与端站关联的任何条目。
When the originating switch has received responses to all the Interswitch New User Request messages it has sent, it does the following:
当发起交换机收到对其发送的所有交换机间新用户请求消息的响应时，它将执行以下操作：
- If it has received a response message with a status of NewUserAck, it loads the new VLAN information into its local database.
- 如果收到状态为NewUserAck的响应消息，则会将新VLAN信息加载到其本地数据库中。
- If all responses have been received with a status of NewUserUnknown, the originating switch assumes that the endstation was not previously connected anywhere in the network and assigns it to a VLAN according to the VLAN membership rules and order of precedence.
- 如果接收到状态为NewUserUnknown的所有响应，则发起交换机假定终端站以前未连接到网络中的任何位置，并根据VLAN成员规则和优先顺序将其分配给VLAN。
If any Interswitch New User Request message has not been responded to within a certain predetermined time (currently 5 seconds), the originating switch recalculates the switch flood path and resends the Interswitch New User Request message.
如果任何交换机间新用户请求消息在某个预定时间（当前为5秒）内未响应，则发起交换机将重新计算交换机泛用路径并重新发送交换机间新用户请求消息。
The Directory Local Delete server removes entries (both local and remote) from the local Node and Alias Tables. It is invoked when an endstation, previously known to be attached to one switch, has been moved and discovered on another switch.
目录本地删除服务器从本地节点和别名表中删除条目（本地和远程）。当先前已知连接到一个交换机的端站在另一个交换机上被移动和发现时，将调用该命令。
Note also that remote entries are cached and are purged from the tables on a first-in/first-out basis as space is needed in the cache.
还请注意，远程条目是缓存的，并根据先进先出的原则从表中清除，因为缓存中需要空间。
The Topology Service Center is responsible for maintaining three databases relating to the topology of the switch fabric:
拓扑服务中心负责维护与交换机结构拓扑相关的三个数据库：
- The topology table of SFVLAN switches that are physical neighbors to the local switch.
- 作为本地交换机物理邻居的SFVLAN交换机的拓扑表。
- The spanning tree that defines the loop-free switch flood path used for transmitting undirected interswitch messages.
- 定义用于传输无向交换机间消息的无环路交换机泛洪路径的生成树。
- The directed graph that is used to calculate the best path(s) for call connections.
- 用于计算呼叫连接的最佳路径的有向图。
The Topology Neighbor Discovery server uses Interswitch Keepalive messages to detect the switch's neighbors and establish the topology of the switching fabric. Interswitch Keepalive messages are exchanged in accordance with Cabletron's VlanHello protocol, described in detail in [IDhello].
拓扑邻居发现服务器使用交换机间保持消息来检测交换机的邻居并建立交换机结构的拓扑。交换机间的Keepalive消息根据Cabletron的VlanHello协议进行交换，详见[IDhello]。
The Topology Spanning Tree server is invoked by the Topology Neighbor Discovery server when a neighboring SFVLAN switch is either discovered or lost -- that is, when the operational status of a network link changes.
当发现或丢失相邻SFVLAN交换机时，即当网络链路的操作状态发生变化时，拓扑邻居发现服务器将调用拓扑生成树服务器。
The Spanning Tree server exchanges interswitch messages with neighboring SFVLAN switches to calculate the switch flood path over which undirected interswitch messages are sent. There are two parts to this process:
生成树服务器与相邻的SFVLAN交换机交换交换机间消息，以计算发送无向交换机间消息的交换机泛洪路径。此过程分为两部分：
- Creating and maintaining the spanning tree - Remote blocking
- 创建和维护生成树-远程阻塞
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 networking 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.
在具有冗余网络链路的网络中，在交换机之间传输的数据包可能会被捕获在无限循环中，这在网络环境中是无法容忍的。但是，可以将网络拓扑简化为单个配置（称为生成树），以便在任意两个交换机之间最多有一条路径。
Within the SFVLAN product, the spanning tree is created and maintained using the Spanning Tree Algorithm defined by the IEEE 802.1d standard.
在SFVLAN产品中，使用IEEE 802.1d标准定义的生成树算法创建和维护生成树。
Note:
注:
A detailed discussion of this algorithm is beyond the scope of this document. See [IEEE] for more information.
对该算法的详细讨论超出了本文档的范围。有关更多信息，请参见[IEEE]。
To implement the Spanning Tree Algorithm, SFVLAN switches exchange Interswitch BPDU messages (Section 6.2) containing encapsulated IEEE-compliant 802.2 Bridge Protocol Data Units (BPDUs). There are two types of BPDUs:
为了实现生成树算法，SFVLAN交换机交换交换机间BPDU消息（第6.2节），其中包含封装的符合IEEE标准的802.2网桥协议数据单元（BPDU）。BPDU有两种类型：
- Configuration (CFG) BPDUs are exchanged during the switch discovery process, following the receipt of an Interswitch Keepalive message. They are used to create the initial the spanning tree.
- 在收到交换机间Keepalive消息后，在交换机发现过程中交换配置（CFG）BPDU。它们用于创建生成树的初始值。
- Topology Change Notification (TCN) BPDUs are exchanged when changes in the network topology are detected. They are used to redefine the spanning tree to reflect the current topology.
- 当检测到网络拓扑中的更改时，将交换拓扑更改通知（TCN）BPDU。它们用于重新定义生成树以反映当前拓扑。
See [IEEE] for detailed descriptions of these BPDUs.
有关这些BPDU的详细说明，请参见[IEEE]。
After the spanning tree has been computed, each network port on an SFVLAN switch will be in one of two states:
计算生成树后，SFVLAN交换机上的每个网络端口将处于以下两种状态之一：
- Forwarding. A port in the Forwarding state will be used to transmit all ISMP messages.
- 转发。处于转发状态的端口将用于传输所有ISMP消息。
- Blocking. A port in the Blocking state will not be used to forward undirected ISMP messages. Blocking the rebroadcast 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.
- 舞台调度。处于阻塞状态的端口将不用于转发无向ISMP消息。阻止在选定端口上重播这些消息可防止网络拓扑中存在的多条路径导致的消息复制。请注意，将传输所有其他类型的ISMP消息。
Note:
注:
The IEEE 802.1d standard specifies other port states used during the initial creation of the spanning tree. These states are not relevant to the discussion here.
IEEE 802.1d标准规定了初始创建生成树期间使用的其他端口状态。这些国家与这里的讨论无关。
Note that 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.
请注意，尽管处于阻塞状态的端口不会转发无向ISMP消息，但它仍然可以接收这些消息。接收到的任何此类消息最终都将被丢弃，但代价是处理数据包所需的CPU时间。
To prevent the transmission of undirected messages to a port, the port's owner switch can set remote blocking on the link by sending an Interswitch Remote Blocking message (Section 6.3) out over the port. This notifies the switch on the other end of the link that undirected messages should not be sent over the link, regardless of the state of the sending port.
为了防止无向消息传输到端口，端口的所有者交换机可以通过在端口上发送交换机间远程阻塞消息（第6.3节），在链路上设置远程阻塞。这会通知链路另一端的交换机，无论发送端口的状态如何，都不应通过链路发送无向消息。
Each SFVLAN switch sends an Interswitch Remote Blocking message out over all its blocked network ports every 5 seconds. A flag within the message indicates whether remote blocking should be turned on or off over the link.
每个SFVLAN交换机每5秒通过其所有被阻止的网络端口发送一条交换机间远程阻止消息。消息中的标志指示是否应通过链路打开或关闭远程阻止。
The Topology Link State server is invoked by any process that detects a change in the state of the network links of the local switch. These changes include (but are not limited to) changes in operational or administrative status of the link, path "cost" or bandwidth.
拓扑链路状态服务器由检测到本地交换机网络链路状态变化的任何进程调用。这些变更包括（但不限于）链路的操作或管理状态、路径“成本”或带宽的变更。
The Link State server runs Cabletron's Virtual LAN Link State (VLS) protocol which exchanges interswitch messages with neighboring SFVLAN switches to calculate the set of best paths between the local switch and all other switches in the fabric. (The VLS protocol is described in detail in [IDvlsp].)
链路状态服务器运行Cabletron的虚拟LAN链路状态（VLS）协议，该协议与相邻SFVLAN交换机交换交换机间消息，以计算本地交换机与结构中所有其他交换机之间的最佳路径集。（VLS协议在[IDvlsp]中有详细描述。）
The Link State server also notifies the Connect Service Center (Section 4.5) of any remote links that have failed, thereby necessitating potential tear-down of current connections.
链路状态服务器还通知连接服务中心（第4.5节）任何发生故障的远程链路，因此可能需要中断当前连接。
The Resolve Service Center is responsible for resolving the destination address of broadcast data packets (such as an IP ARP packet) to a unicast MAC address to be used in mapping the call connection. To do this, the Resolve Service Center attempts to resolve such broadcast packets directly at the access port of the ingress switch.
解析服务中心负责将广播数据包（如IP ARP包）的目标地址解析为单播MAC地址，以用于映射呼叫连接。为此，解析服务中心尝试直接在入口交换机的接入端口解析此类广播分组。
Address resolution is accomplished as follows:
地址解析的实现如下：
1) First, an attempt is made to resolve the address from the switch's local databases by calling the following servers:
1) 首先，尝试通过调用以下服务器从交换机的本地数据库解析地址：
- The Table server attempts to resolve the address from the Resolve Table (Section 4.3.1).
- 表服务器尝试从解析表解析地址（第4.3.1节）。
- Next, the Local server attempts to resolve the address from the Node and Alias Tables (Section 4.3.2).
- 接下来，本地服务器尝试从节点和别名表解析地址（第4.3.2节）。
- If the address is not found in these tables but is an IP address, the Resolve Subnet server (Section 4.3.3) is also called.
- 如果在这些表中找不到该地址，但该地址是IP地址，则还将调用解析子网服务器（第4.3.3节）。
2) If the address cannot be resolved locally, the Interswitch Resolve server (Section 4.3.4) is called to access the "virtual directory" by sending an Interswitch Resolve request message out over the switch flood path.
2) 如果无法在本地解析地址，将调用交换机间解析服务器（第4.3.4节），通过交换机泛洪路径发送交换机间解析请求消息来访问“虚拟目录”。
3) If the address cannot be resolved either locally or via an Interswitch Resolve message -- that is, the destination endstation is unknown to any switch, perhaps because it has never transmitted a packet to its switch -- the following steps are taken:
3) 如果无法在本地或通过交换机间解析消息解析地址——也就是说，任何交换机都不知道目标端站，可能是因为它从未向其交换机发送数据包——将采取以下步骤：
- The Unresolvable server (Section 4.3.5) is called to record the unresolved packet.
- 调用无法解析的服务器（第4.3.5节）来记录无法解析的数据包。
- The Block server (Section 4.3.6) is called to determine whether the address should be added to the Block Table.
- 调用块服务器（第4.3.6节）以确定是否应将地址添加到块表中。
- The Flood Service Center (Section 4.8) is called to broadcast the packet to other SFVLAN switches using a tag-based flooding mechanism.
- 呼叫泛洪服务中心（第4.8节）使用基于标签的泛洪机制向其他SFVLAN交换机广播数据包。
The Resolve Table server maintains the Resolve Table which contains a collection of addresses that might not be resolvable in the normal fashion. This table typically contains such things as the addresses of "quiet" devices that do not send data packets or special mappings of IP addresses behind a router. Entries can be added to or deleted from the Resolve Table via an external management application.
解析表服务器维护解析表，其中包含可能无法以正常方式解析的地址集合。此表通常包含不发送数据包的“安静”设备的地址或路由器后面IP地址的特殊映射。可以通过外部管理应用程序在解析表中添加或删除条目。
The Resolve Local server checks the Node and Alias Tables maintained by the Directory Service Center (Section 4.1) to determine if it can resolve the address.
解析本地服务器检查目录服务中心维护的节点和别名表（第4.1节），以确定是否可以解析地址。
If the address to be resolved is an IP address but cannot be resolved via the standard processing described above, the Resolve Subnet server applies the subnet mask to the IP address and then does a lookup in the Resolve Table.
如果要解析的地址是IP地址，但无法通过上述标准处理进行解析，则解析子网服务器将子网掩码应用于IP地址，然后在解析表中进行查找。
If the address cannot be resolved locally, the Interswitch Resolve server accesses the "virtual directory" by sending an Interswitch Resolve request message (Section 6.4) out over the switch flood path. The Interswitch Resolve request message contains the destination address as it was received within the packet, along with a list of requested addressing information.
如果无法在本地解析地址，则交换机间解析服务器通过交换机泛洪路径发送交换机间解析请求消息（第6.4节）来访问“虚拟目录”。Interswitch Resolve请求消息包含在数据包中接收到的目标地址，以及请求的地址信息列表。
When a switch receives an Interswitch Resolve request message from one of its upstream neighbors, it checks to see if the destination endstation is connected to one of its local access ports. If so, it formulates an Interswitch Resolve response message by filling in the requested address information, along with its own MAC address. It then sets the message status field to ResolveAck, and returns the message to its upstream (requesting) neighbor.
当交换机从其一个上游邻居接收到交换机间解析请求消息时，它会检查目标端站是否连接到其一个本地访问端口。如果是这样，它将通过填写请求的地址信息以及自己的MAC地址来生成交换机间解析响应消息。然后，它将消息状态字段设置为ResolveAck，并将消息返回给其上游（请求）邻居。
If the receiving switch cannot resolve the address, it forwards the Interswitch Resolve request message to its downstream neighbors. If the switch has no downstream neighbors, it sets the message status field to Unknown, and returns the message to its upstream (requesting) neighbor.
如果接收交换机无法解析地址，则会将交换机间解析请求消息转发给其下游邻居。如果交换机没有下游邻居，它会将消息状态字段设置为未知，并将消息返回给其上游（请求）邻居。
When a switch forwards an Interswitch Resolve request message to its downstream neighbors, it keeps track of the number of requests it has sent out and received back. It will only respond back to its upstream (requesting) neighbor when one of the following conditions occurs:
当交换机将交换机间解析请求消息转发给其下游邻居时，它会跟踪其发送和接收的请求数。当出现以下情况之一时，它将只回复其上游（请求）邻居：
- It receives any response with a status of ResolveAck
- 它接收状态为ResolveAck的任何响应
- All downstream neighbors have responded with a status of Unknown
- 所有下游邻居都以未知状态响应
Any Interswitch Resolve request message that is not responded to within a certain predetermined time (currently 5 seconds) is assumed to have a response status of Unknown.
假定在特定预定时间（当前为5秒）内未响应的任何交换机间解析请求消息的响应状态为未知。
When the Interswitch Resolve server receives a successful Interswitch Resolve response message, it records the resolved address information in the remote cache of its local directory for use in resolving later packets for the same endstation. Note that this process results in each switch building its own unique copy of the virtual directory containing only the endstation addresses in which it is interested.
当Interswitch Resolve server接收到成功的Interswitch Resolve响应消息时，它将解析的地址信息记录在其本地目录的远程缓存中，以用于解析同一终端站的后续数据包。请注意，此过程导致每个交换机构建其自己的唯一虚拟目录副本，其中仅包含其感兴趣的端站地址。
The Unresolvable server is called when a packet destination address cannot be resolved. The server records the packet in a table that can then be examined to determine which endstations are generating unresolvable traffic.
当无法解析数据包目标地址时，将调用无法解析的服务器。服务器将数据包记录在一个表中，然后可以检查该表以确定哪些终端站正在生成无法解决的流量。
Also, if a particular destination is repeatedly seen to be unresolvable, the server calls the Block server (Section 4.3.6) to determine whether the address should be blocked.
此外，如果某个特定目的地被反复认为无法解析，服务器将调用块服务器（第4.3.6节），以确定是否应阻止该地址。
The Resolve Block server is called when a particular destination has been repeatedly seen to be unresolvable. This typically happens when, unknown to the packet source, the destination endstation is either not currently available or no longer exists.
当某个特定目的地被反复视为无法解析时，将调用解析块服务器。这通常发生在数据包源未知的情况下，目标端站当前不可用或不再存在。
If the Block server determines that the unresolved address has exceeded a configurable request threshold, the address is added to the server's Block Table. Interswitch Resolve request messages for addresses listed in the Block Table are sent less frequently, thereby reducing the amount of Interswitch Resolve traffic throughout the fabric.
如果块服务器确定未解析的地址已超过可配置的请求阈值，则该地址将添加到服务器的块表中。块表中列出的地址的交换机间解析请求消息发送频率较低，从而减少整个结构中的交换机间解析通信量。
If an address listed in the Block Table is later successfully resolved by and Interswitch Resolve request message, the address is removed from the table.
如果块表中列出的地址后来通过和交换机间解析请求消息成功解析，则该地址将从表中删除。
Once the destination address of the call packet has been resolved, the Policy Service Center is called to determine the validity of the requested call connection based on the VLAN policy of the source and destination VLANs.
解析呼叫数据包的目标地址后，将调用策略服务中心，以根据源和目标VLAN的VLAN策略确定请求的呼叫连接的有效性。
The Policy Unicast Rules server recognizes two VLAN policy values: Open or Secure. The default policy for all VLANs is Open.
策略单播规则服务器识别两个VLAN策略值：打开或安全。所有VLAN的默认策略都是开放的。
The policy value is used as follows when determining the validity of a requested call connection:
在确定请求的呼叫连接的有效性时，策略值使用如下：
- If the VLAN policy of either the source or destination cannot be determined, the Filter Service Center is called to establish a filter (i.e., blocked) for the SA/DA pair.
- 如果无法确定源或目标的VLAN策略，则会调用筛选器服务中心为SA/DA对建立筛选器（即阻止）。
- If the source and destination endstations belong to the same VLAN, then the connection is permitted regardless of the VLAN policy.
- 如果源和目标端站属于同一VLAN，则无论VLAN策略如何，都允许连接。
- If the source and destination endstations belong to different VLANs, but both VLANs are running with an Open policy, then the connection is permitted, providing cut-through switching between different VLAN(s).
- 如果源和目标端站属于不同的VLAN，但两个VLAN都以开放策略运行，则允许连接，在不同VLAN之间提供直通切换。
- If the source and destination endstations belong to different VLANs and one or both of the VLANs are running with a Secure policy, then the Flood Service Center (Section 4.8) is called to broadcast the packet to other SFVLAN switches having ports or endstations that belong to the same VLAN as the packet source.
- 如果源端站和目标端站属于不同的VLAN，并且其中一个或两个VLAN以安全策略运行，则调用洪水服务中心（第4.8节）将数据包广播到其他SFVLAN交换机，这些交换机的端口或端站属于与数据包源相同的VLAN。
Note that if any of the VLANs to which the source or destination belong has a Secure policy, then the policy used in the above algorithm is Secure.
请注意，如果源或目标所属的任何VLAN具有安全策略，则上述算法中使用的策略是安全的。
Once the Policy Service Center (Section 4.4) has determined that a requested call connection is valid, the Connect Service Center is called to set up the connection. Note that connectivity between two endstations within the fabric is established on a switch-by-switch basis as the call progresses through the fabric toward its destination. No synchronization is needed between switches to establish an end-to-end connection.
一旦策略服务中心（第4.4节）确定请求的呼叫连接有效，将调用Connect服务中心建立连接。请注意，当呼叫通过结构向其目的地进行时，结构内两个终端站之间的连接是在交换机对交换机的基础上建立的。交换机之间不需要同步来建立端到端连接。
The Connect Service Center maintains a Connection Table containing information for all connections currently active on the switch's local ports.
Connect Service Center维护一个连接表，其中包含交换机本地端口上当前活动的所有连接的信息。
Connections are removed from the Connection Table when one of the endstations is moved to a new switch (Section 4.1.2) or when the Topology Link State server (Section 4.2.3) notifies the Connect Service Center that a network link has failed. Otherwise, connections are not automatically aged out or removed from the Connection Table until a certain percentage threshold (HiMark) of table capacity is reached and resources are needed. At that point, some number of connections (typically 100) are aged out and removed at one time.
当其中一个终端站移动到新交换机（第4.1.2节）或拓扑链路状态服务器（第4.2.3节）通知Connect Service Center网络链路出现故障时，将从连接表中删除连接。否则，在达到表容量的某个百分比阈值（HiMark）并且需要资源之前，连接不会自动老化或从连接表中删除。此时，一些连接（通常为100个）会老化并一次删除。
If the destination endstation resides on the local switch, the Connect Local server establishes a connection between the source and destination ports. Note that if the source and destination both reside on the same physical port, a filter connection is established by calling the Filter Service Center (Section 4.6).
如果目标端站位于本地交换机上，则连接本地服务器将在源端口和目标端口之间建立连接。请注意，如果源和目标都位于同一物理端口上，则通过调用筛选器服务中心（第4.6节）建立筛选器连接。
The Connect Link State server is called if the destination endstation of the proposed connection does not reside on the local switch.
如果建议连接的目标端站不在本地交换机上，则调用连接链路状态服务器。
The server executes a call to the Path Link State server (Section 4.7.1) which returns up to three "best" paths of equal cost from the local switch to the destination switch. If more than one path is returned, the server chooses a path that provides the best load balancing of user traffic across the fabric.
服务器执行对路径链接状态服务器（第4.7.1节）的调用，该服务器返回从本地交换机到目标交换机的三条成本相等的“最佳”路径。如果返回多条路径，服务器将选择一条路径，该路径可在整个结构中提供用户流量的最佳负载平衡。
The Connect Directory server is called if the Connect Link State server is unable to provide a path for some reason.
如果连接状态服务器由于某种原因无法提供路径，则调用连接目录服务器。
The server examines the local directory to determine on which switch the destination endstation resides. If the port of access to the destination switch is known, then a connection is established using that port as the outport of the connection.
服务器检查本地目录以确定目标端站所在的交换机。如果目标交换机的访问端口已知，则使用该端口作为连接的输出端口建立连接。
The Filter Service Center is responsible for establishing filtered connections. This service center is called by the Connect Local server (Section 4.5.1) if the source and destination endstations reside on the same physical port, and by the Policy Service Center (Section 4.4) if the VLAN of either the source or destination is indeterminate.
过滤器服务中心负责建立过滤连接。如果源和目标端站位于同一物理端口上，则由连接本地服务器（第4.5.1节）调用此服务中心；如果源或目标的VLAN不确定，则由策略服务中心（第4.4节）调用此服务中心。
A filter connection is programmed in the switch hardware with no specified outport. That is, the connection is programmed to discard any traffic for that SA/DA pair.
滤波器连接在开关硬件中编程，没有指定的输出端口。也就是说，连接编程为丢弃该SA/DA对的任何通信量。
The Path Service Center is responsible for determining the path from a source to a destination.
路径服务中心负责确定从源到目标的路径。
The Path Link State server is called by the Connect Link State server (Section 4.5.2) to return up to three best paths of equal cost between a source and destination pair of endstations. These best paths are calculated by the Topology Link State server (Section 4.2.3).
连接链路状态服务器（第4.5.2节）调用路径链路状态服务器，以在端站的源和目标对之间返回最多三条成本相等的最佳路径。这些最佳路径由拓扑链路状态服务器计算（第4.2.3节）。
The Path Link State server is also called by the Connect Service Center to return a complete source-to-destination path consisting of a list of individual switch port names. A switch port name consists of the switch base MAC address and a port instance relative to the switch.
连接服务中心也会调用路径链接状态服务器，以返回由单个交换机端口名称列表组成的完整源到目标路径。交换机端口名称由交换机基本MAC地址和与交换机相关的端口实例组成。
The Path Spanning Tree server is called by any server needing to forward an undirected message out over the switch flood path. The server returns a port mask indicating which local ports are currently enabled as outports of the switch flood path. The switch flood path is calculated by the Topology Spanning Tree server (Section 4.2.2).
任何需要通过交换机泛洪路径转发无向消息的服务器都会调用路径生成树服务器。服务器返回一个端口掩码，指示当前启用哪些本地端口作为交换机泛用路径的输出端口。交换机泛洪路径由拓扑生成树服务器计算（第4.2.2节）。
If the Resolve Service Center (Section 4.3) is unable to resolve the destination address of a packet, it invokes the Flood Service Center to broadcast the unresolved packet.
如果解析服务中心（第4.3节）无法解析数据包的目标地址，它将调用泛洪服务中心来广播未解析的数据包。
The Tag-Based Flood server encapsulates the unresolved packet into an Interswitch Tag-Based Flood message (Section 6.6), along with a list of Virtual LAN identifiers specifying those VLANs to which the source endstation belongs. The message is then sent out over the switch flood path to all other switches in the fabric.
基于标签的泛洪服务器将未解析的数据包封装到基于交换机间标签的泛洪消息（第6.6节）中，以及指定源端站所属VLAN的虚拟LAN标识符列表。然后，该消息通过交换机泛洪路径发送到结构中的所有其他交换机。
When a switch receives an Interswitch Tag-Based Flood message, 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).
当交换机接收到基于交换机间标签的泛洪消息时，它会检查封装的报头以确定数据包应发送到的VLAN。如果交换机的任何本地访问端口属于一个或多个指定VLAN，则交换机将剥离基于标记的报头，并将原始数据包转发到适当的访问端口。
The switch also forwards the entire encapsulated packet along the switch flood path to its downstream neighboring switches, if any.
交换机还沿着交换机泛洪路径将整个封装包转发给其下游相邻交换机（如果有）。
The SecureFast VLAN product permits monitoring of user traffic moving between two endstations by establishing a call tap on the connection between the two stations. Traffic can be monitored in one or both directions along the connection path.
SecureFast VLAN产品通过在两个终端站之间的连接上建立呼叫抽头，允许监控两个终端站之间移动的用户流量。可以沿连接路径的一个或两个方向监控流量。
In addition to the terms defined in Section 1.2, the following terms are used in this description of the call tap process.
除第1.2节中定义的术语外，以下术语用于呼叫抽头过程的描述。
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.
发起交换机是请求呼叫分接的交换机。沿着呼叫连接路径的任何交换机都可以请求对该呼叫连接进行轻触。
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.
tap探针是接收呼叫连接数据副本的设备。探头连接到探头交换机上的端口。
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.
探针开关（也称为终端开关）是探针连接到的开关。探测器开关可以位于拓扑中的任何位置。
A request to tap a call connection between two endstations 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.
在两个终端站之间点击呼叫连接的请求可以在沿着呼叫连接路径的任何交换机上发起——入口交换机、出口交换机或任何中间交换机。必须先建立呼叫连接，然后才能发出呼叫转接请求。探针设备可以连接到拓扑中的任何交换机。
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:
因此，在沿抽头路径的每个开关上，通过以下三种方式之一建立抽头连接：
- The existing call connection is used with no modification.
- 使用现有呼叫连接时不作任何修改。
When both the call path and tap path pass through the switch, and the inport and outports 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 outport is different from the tap path outport, the switch enables an extra outport 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 outport is enabled to the probe.
- 如果开关也是探头开关，则会为探头启用一个额外的输出端口。
- If the switch is the point at which the call path and the tap path diverge, an extra outport is enabled to the downstream neighbor on that leg of the switch 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.
如果呼叫路径未通过开关（因为抽头路径已偏离呼叫路径），则为抽头建立全新的连接。
To establish a call tap, the originating switch formats an Interswitch Tap request message (Section 6.7) and sends it out over the switch flood path to all other switches in the topology.
为了建立呼叫分接，发起交换机格式化交换机间分接请求消息（第6.7节），并通过交换机泛洪路径将其发送到拓扑中的所有其他交换机。
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 switch 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 5.2.1). 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.
- 如果开关为探针开关，则通过建立新连接或修改呼叫连接（视情况而定）建立抽头连接（见第5.2.1节）。然后，它将Tap请求消息重新格式化为Tap响应消息，状态指示已找到探测器，并将消息发送回其上游邻居。
- If the switch is not the probe switch, it forwards the Tap request message to all its downstream neighbors (if any).
- 如果交换机不是探测交换机，它将Tap请求消息转发给其所有下游邻居（如果有）。
- 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
- 如果交换机不是探测交换机，并且没有下游邻居，它将Tap请求消息重新格式化为Tap响应消息，状态指示探测器不是
located on that leg of the switch flood path. 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.
当交换机将交换机间Tap请求消息转发给其下游邻居时，它会跟踪已发送的请求数。
- 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 5.2.1). 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.
- 如果收到一个状态指示探针开关位于下游某处的响应，开关将建立适当类型的抽头连接（见第5.2.1节）。然后，它格式化一条Tap响应消息，该消息的状态指示已找到探测器，并将该消息传递给其上游邻居。
- 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.
- 如果未接收到状态指示探测器开关位于下游的响应，则开关会格式化状态指示探测器未找到的Tap响应消息，并将该消息传递给其上游邻居。
The status field of the Interswitch 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:
开关间分接请求/响应消息的状态字段包含有关分接状态的信息。其中一些状态值是暂时的，仅用于跟踪tap请求的进度。其他状态值存储在沿抽头路径的每个开关的抽头表中，以便在拆卸抽头时使用。可能的状态值如下所示：
- StatusUnassigned. This is the initial status of the Interswitch Tap request message.
- 状态未分配。这是开关间抽头请求消息的初始状态。
- OutportDecisionUnknown. The tap request is still moving downstream along the switch flood path. The probe switch had not yet been found.
- OutportDecisionUnknown。tap请求仍沿交换机泛洪路径向下游移动。尚未找到探针开关。
- ProbeNotFound. The probe switch is not located on this leg of the switch flood path.
- ProbeNotFound。探头开关不位于开关泛光路径的该支腿上。
- DisableOutport. The probe switch is located on this leg of the switch flood path, and the switch has had to either modify the call connection or establish a new connection to implement the tap (see Section 5.2.1). When the tap is torn down, the switch will have to disable any additional outports that have been enabled for the tap.
- 禁用输出端口。探头开关位于开关通电路径的该支路上，开关必须修改呼叫连接或建立新连接以实现分接（见第5.2.1节）。当分接头被拆除时，开关必须禁用为分接头启用的任何其他输出。
- KeepOutport. The probe switch is located on this leg of the switch flood path, and the switch was able to route the tap over the existing call path (see Section 5.2.1). Any ports used for
- 禁止通行。探测开关位于开关泛光路径的这一分支上，开关能够在现有呼叫路径上路由分接头（见第5.2.1节）。任何用于
the tap will remain enabled when the tap is torn down.
拆卸分接头时，分接头将保持启用状态。
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.
解除接入呼叫连接的请求必须在tap始发交换机上发出，即发出tap请求的同一交换机。
To untap a call connection, the originating switch sends an Interswitch Untap request message (Section 6.7) out over the switch flood path to all other switches in the topology. The message is sent over the switch 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.
为了解除呼叫连接的接入，发起交换机通过交换机泛洪路径向拓扑中的所有其他交换机发送交换机间解除接入请求消息（第6.7节）。该消息通过交换机泛洪路径而不是分接连接路径发送，以确保所有知道分接的交换机都得到正确通知，即使自分接建立以来交换机拓扑已发生更改。
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:
当交换机收到交换机间Untap请求消息时，它会检查是否正在处理指定呼叫连接的抽头。如果是，开关将禁用抽头连接，如下所示：
- 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 Interswitch 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.
然后，交换机将交换机间Untap请求消息转发给其下游邻居（如果有）。如果交换机没有下游邻居，它将格式化untap响应并将消息发送回其上游邻居。
When a switch forwards an Interswitch 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 Interswitch Untap response message to its upstream neighbor.
当交换机将交换机间Untap请求消息转发给其下游邻居时，它会跟踪其发出的请求数，并且在所有Untap请求都得到响应之前不会回复其上游邻居。收到所有响应后，交换机将处理抽头的任何最终清理，然后向其上游邻居发送单个开关间Untap响应消息。
The InterSwitch Message protocol (ISMP) provides a consistent method of encapsulating and transmitting messages exchanged between switches to create and maintain the databases and provide other control services and functionality required by the SFVLAN product.
交换机间消息协议（ISMP）提供了封装和传输交换机间交换的消息的一致方法，以创建和维护数据库，并提供SFVLAN产品所需的其他控制服务和功能。
ISMP packets are of variable length and have the following general structure:
ISMP数据包长度可变，一般结构如下：
- Frame header - ISMP packet header - ISMP message body
- 帧头-ISMP报文头-ISMP报文正文
Each of these packet segments is discussed separately in the following subsections.
以下小节将分别讨论这些数据包段中的每一个。
ISMP packets are encapsulated within an IEEE 802-compliant frame using a standard header as shown below:
ISMP数据包使用标准报头封装在符合IEEE 802标准的帧内，如下所示：
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 | |
+ +
: :
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. Except where otherwise noted, this field
此6-octet字段包含多播信道的媒体访问控制（MAC）地址，结构中的所有交换机通过该地址接收ISMP数据包。除非另有说明，否则此字段
contains the multicast address of the control channel over which all switches in the fabric receive ISMP packets -- a value of 01- 00-1D-00-00-00.
包含控制通道的多播地址，结构中的所有交换机通过该地址接收ISMP数据包——值为01-00-1D-00-00-00。
Source address
源地址
Except where otherwise noted, this 6-octet field contains the physical (MAC) address of the switch originating the ISMP packet.
除非另有说明，否则此6-octet字段包含发起ISMP数据包的交换机的物理（MAC）地址。
Type
类型
This 2-octet field identifies the type of data carried within the frame. Except where otherwise noted, the type field of ISMP packets contains the value 0x81FD.
此2个八位组字段标识帧内所携带的数据类型。除非另有说明，否则ISMP数据包的类型字段包含值0x81FD。
There are two versions of the ISMP packet header in use by the SecureFast VLAN product.
SecureFast VLAN产品正在使用两种版本的ISMP数据包头。
The version 2 ISMP packet header consists of 6 octets, as shown below:
版本2 ISMP数据包头由6个八位字节组成，如下所示：
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 | |
+ +
: :
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 (Section 6.1.1).
该14个八位字节字段包含帧头（第6.1.1节）。
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.
此2-octet字段包含此ISMP数据包所遵循的交换机间消息协议的版本号。本文档介绍ISMP 2.0版。
ISMP message type
ISMP消息类型
This 2-octet field contains a value indicating which type of ISMP message is contained within the message body. The following table lists each ISMP message, along with its message type and the section within this document that describes the message in detail:
此2-octet字段包含一个值，该值指示消息正文中包含哪种类型的ISMP消息。下表列出了每个ISMP消息及其消息类型，以及本文档中详细描述消息的部分：
Message Name Type Description
消息名称类型描述
Interswitch Link State message 3 See note below Interswitch BPDU message 4 Section 6.2 Interswitch Remote Blocking message 4 Section 6.3 Interswitch Resolve message 5 Section 6.4 Interswitch New User message 5 Section 6.5 Interswitch Tag-Based Flood message 7 Section 6.6 Interswitch Tap/Untap message 8 Section 6.7
交换机间链路状态消息3请参见以下注释交换机间BPDU消息4第6.2节交换机间远程阻塞消息4第6.3节交换机间解决消息5第6.4节交换机间新用户消息5第6.5节交换机间基于标签的泛洪消息7第6.6节交换机间分接/解除接入消息8第6.7节
Note:
注:
The Link State messages used by the VLS Protocol are not described in this document. For a detailed description of these messages, see [IDvlsp].
VLS协议使用的链路状态消息未在本文档中描述。有关这些消息的详细说明，请参阅[IDvlsp]。
Sequence number
序列号
This 2-octet field contains an internally generated sequence number used by the various protocol handlers for internal synchronization of messages.
此2-octet字段包含内部生成的序列号，由各种协议处理程序用于消息的内部同步。
The version 3 ISMP packet header is used only by the Interswitch Keepalive message. That message is not described in this document. For a detailed description of the version 3 ISMP packet header, see [IDhello].
版本3 ISMP数据包头仅由交换机间Keepalive消息使用。本文档中未描述该消息。有关版本3 ISMP数据包头的详细说明，请参阅[IDhello]。
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.
ISMP消息正文是一个可变长度字段，包含ISMP消息的实际数据。此字段的长度和内容由消息类型字段中的值确定。
See the following sections for the exact format of each message type.
有关每种消息类型的确切格式，请参见以下部分。
The Interswitch BPDU message consists of a variable number of octets, as shown below:
交换机间BPDU消息由可变数量的八位字节组成，如下所示：
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 (type 4) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | Version | Opcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | Message flags | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
28 | |
: BPDU packet :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (type 4) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | Version | Opcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | Message flags | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
28 | |
: BPDU packet :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame header/ISMP packet header
帧报头/ISMP数据包报头
This 20-octet field contains the frame header and the ISMP packet header.
此20个八位字节字段包含帧头和ISMP数据包头。
Version
版本
This 2-octet field contains the version number of the message type. This document describes ISMP message type 4, version 1.
此2-octet字段包含消息类型的版本号。本文档介绍ISMP消息类型4，版本1。
Opcode
操作码
This 2-octet field contains the operation type of the message. For an Interswitch BPDU message, the value should be 1.
此2-octet字段包含消息的操作类型。对于交换机间BPDU消息，该值应为1。
Message flags
消息标志
This 2-octet field is currently unused. It is reserved for future use.
此2-octet字段当前未使用。这是留作将来使用的。
BPDU packet
BPDU包
This variable-length field contains an IEEE-compliant 802.2 Bridge Protocol Data Unit. See [IEEE] for a detailed description of the contents of this field.
此可变长度字段包含符合IEEE标准的802.2网桥协议数据单元。有关此字段内容的详细说明，请参见[IEEE]。
The Interswitch Remote Blocking message consists of 30 octets, as shown below:
交换机间远程阻塞消息由30个八位字节组成，如下所示：
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 (type 4) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | Version | Opcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | Message flags | Blocking flag ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 | ... Blocking flag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (type 4) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | Version | Opcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | Message flags | Blocking flag ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 | ... Blocking flag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame header/ISMP packet header
帧报头/ISMP数据包报头
This 20-octet field contains the frame header and the ISMP packet header.
此20个八位字节字段包含帧头和ISMP数据包头。
Version
版本
This 2-octet field contains the version number of the message type. This document describes ISMP message type 4, version 1.
此2-octet字段包含消息类型的版本号。本文档介绍ISMP消息类型4，版本1。
Opcode
操作码
This 2-octet field contains the operation type of the message. Valid values are as follows:
此2-octet字段包含消息的操作类型。有效值如下所示：
2 Enable/disable remote blocking 3 Acknowledge previously received Remote Blocking message
2启用/禁用远程阻止3确认以前收到的远程阻止消息
Message flags
消息标志
This 2-octet field is currently unused. It is reserved for future use.
此2-octet字段当前未使用。这是留作将来使用的。
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 should be sent over the link. A value of 0 indicates remote blocking is off. This flag is irrelevant if the operation type (Opcode) of the message has a value of 3.
此4-octet字段包含一个标志，指示接收消息的链路上的远程阻塞状态。值1表示远程阻塞已打开，不应通过链路发送无向ISMP消息。值为0表示远程阻止已关闭。如果消息的操作类型（操作码）的值为3，则此标志不相关。
There are two versions of the Interswitch Resolve message used by the SecureFast VLAN product.
SecureFast VLAN产品使用两种版本的交换机间解析消息。
The Interswitch Resolve message used by SFVLAN prior to version 1.8 consists of a variable number of octets, as shown below:
版本1.8之前的SFVLAN使用的交换机间解析消息由可变数量的八位字节组成，如下所示：
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 (type 5) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | Version | Opcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | Status | Call Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 | |
+ Source MAC of packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
32 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Originating switch MAC +
36 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
40 | |
+ Owner switch MAC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
44 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
48 | |
: Known destination address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n | Count | |
+-+-+-+-+-+-+-+-+ +
n+4 | Resolve list |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (type 5) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | Version | Opcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | Status | Call Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 | |
+ Source MAC of packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
32 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Originating switch MAC +
36 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
40 | |
+ Owner switch MAC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
44 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
48 | |
: Known destination address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n | Count | |
+-+-+-+-+-+-+-+-+ +
n+4 | Resolve list |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n = 46 + length of known address TLV
n=46+已知地址TLV的长度
In the following description of the message fields, the term "originating" switch refers to the switch that issued the original Interswitch Resolve request. The term "owner" switch refers to that switch to which the destination endstation is attached. And the term "responding" switch refers to either the "owner" switch or to a switch at the end of the switch flood path that does not own the endstation but issues an Interswitch Resolve response because it has no downstream neighbors.
在以下消息字段的描述中，术语“始发”交换机指发出原始交换机间解析请求的交换机。术语“所有者”交换机是指目标端站所连接的交换机。术语“响应”交换机指的是“所有者”交换机或交换机泛洪路径末端的交换机，该交换机不拥有终端站，但发出交换机间解析响应，因为它没有下游邻居。
With the exception of the resolve list (which has a different size and format in a Resolve response message), all fields of an Interswitch Resolve message are allocated by the originating switch, and unless otherwise noted below, are written by the originating switch.
除解析列表（在解析响应消息中具有不同的大小和格式）外，交换机间解析消息的所有字段均由发起交换机分配，除非下文另有说明，否则由发起交换机写入。
Frame header/ISMP packet header
帧报头/ISMP数据包报头
This 20-octet field contains the frame header and the ISMP packet header.
此20个八位字节字段包含帧头和ISMP数据包头。
Version
版本
This 2-octet field contains the version number of the message type. This document describes ISMP message type 5, version 1.
此2-octet字段包含消息类型的版本号。本文档介绍ISMP消息类型5，版本1。
Opcode
操作码
This 2-octet field contains the operation code of the message. Valid values are as follows:
此2-octet字段包含消息的操作代码。有效值如下所示：
1 The message is a Resolve request. 2 The message is a Resolve response. 3 (unused in Resolve messages) 4 (unused in Resolve messages)
1该消息是一个解决请求。2该消息是一个解析响应。3（在解析消息中未使用）4（在解析消息中未使用）
The originating switch writes a value of 1 to this field, while the responding switch writes a value of 2.
发起开关将值1写入此字段，而响应开关将值2写入。
Status
地位
This 2-octet field contains the status of a Resolve response message. Valid values are as follows:
此2-octet字段包含解析响应消息的状态。有效值如下所示：
0 The Resolve request succeeded (ResolveAck). 1 (unused) 2 The Resolve request failed (Unknown).
0解析请求成功（ResolveAck）。1（未使用）2解析请求失败（未知）。
This field is written by the responding switch.
此字段由响应开关写入。
Call tag
呼叫标签
This 2-octet field contains the call tag of the endstation packet for which this Resolve request is issued. The call tag is a 16- bit value (generated by the originating switch) that uniquely identifies the packet.
此2-octet字段包含发出此解析请求的端站数据包的调用标记。呼叫标签是一个16位的值（由发起交换机生成），它唯一地标识数据包。
Source MAC of packet
包的源MAC
This 6-octet field contains the physical (MAC) address of the endstation that originated the packet identified by the call tag.
此6位字节字段包含发起由呼叫标签标识的数据包的终端站的物理（MAC）地址。
Originating switch MAC
始发交换机MAC
This 6-octet field contains the physical (MAC) address of the switch that issued the original Resolve request.
此6位字节字段包含发出原始解析请求的交换机的物理（MAC）地址。
Owner switch MAC
所有者交换MAC
This 6-octet field contains the physical (MAC) address of the switch to which the destination endstation is attached -- that is, the switch that was able to resolve the requested addressing information. This field is written by the owner switch.
此6位字节字段包含目标端站连接到的交换机的物理（MAC）地址，即能够解析请求的寻址信息的交换机。此字段由所有者开关写入。
If the status of the response is Unknown, this field is irrelevant.
如果响应的状态未知，则此字段不相关。
Known destination address
已知目的地址
This variable-length field contains the known attribute of the destination endstation address. This address is stored in Tag/Length/Value format. (See Section 2.3.)
此可变长度字段包含目标端站地址的已知属性。此地址以标记/长度/值格式存储。（见第2.3节。）
Count
计数
This 1-octet field contains the number of address attributes requested or returned. This is the number of items in the resolve list.
此1-octet字段包含请求或返回的地址属性数。这是“解决”列表中的项数。
Resolve list
解析列表
This variable-length field contains a list of the address attributes either requested by the originating switch or returned by the owner switch. Note that in a Resolve request message, this list contains only the tags of the requested address attributes (see Section 2.3). On the other hand, a Resolve response message with a status of ResolveAck contains the full TLV of each resolved address attribute. The number of entries in the list is specified in the count field.
此可变长度字段包含由原始交换机请求或由所有者交换机返回的地址属性列表。请注意，在解析请求消息中，此列表仅包含请求地址属性的标记（请参阅第2.3节）。另一方面，状态为ResolveAck的Resolve响应消息包含每个已解析地址属性的完整TLV。列表中的条目数在“计数”字段中指定。
In an Interswitch Resolve response message, this field is irrelevant if the status of the response is Unknown.
在交换机间解析响应消息中，如果响应状态未知，则此字段不相关。
The Interswitch Resolve message used by SFVLAN version 1.8 consists of a variable number of octets, as shown below:
SFVLAN版本1.8使用的交换机间解析消息由可变数量的八位字节组成，如下所示：
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 (type 5) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | Version | Opcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | Status | Call Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 | |
+ Source MAC of packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
32 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Originating switch MAC +
36 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
40 | |
+ Owner switch MAC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
44 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
48 | |
: Known destination address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n | Count | |
+-+-+-+-+-+-+-+-+ +
n+4 | Resolve list |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n1 | |
+ Actual dest switch MAC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Downlink chassis MAC +
n1+8 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n1+12 | |
+ Actual chassis MAC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
n1+20 | |
+ Domain name +
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n = 46 + length of known address TLV
n1 = n + length of Resolve list
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 (type 5) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | Version | Opcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | Status | Call Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 | |
+ Source MAC of packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
32 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Originating switch MAC +
36 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
40 | |
+ Owner switch MAC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
44 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
48 | |
: Known destination address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n | Count | |
+-+-+-+-+-+-+-+-+ +
n+4 | Resolve list |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n1 | |
+ Actual dest switch MAC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Downlink chassis MAC +
n1+8 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n1+12 | |
+ Actual chassis MAC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
n1+20 | |
+ Domain name +
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n = 46 + length of known address TLV
n1 = n + length of Resolve list
In the following description of the message fields, the term "originating" switch refers to the switch that issued the original Interswitch Resolve request. The term "owner" switch refers to that switch to which the destination endstation is attached. And the term "responding" switch refers to either the "owner" switch or to a switch at the end of the switch flood path that does not own the endstation but issues an Interswitch Resolve response because it has no downstream neighbors.
在以下消息字段的描述中，术语“始发”交换机指发出原始交换机间解析请求的交换机。术语“所有者”交换机是指目标端站所连接的交换机。术语“响应”交换机指的是“所有者”交换机或交换机泛洪路径末端的交换机，该交换机不拥有终端站，但发出交换机间解析响应，因为它没有下游邻居。
With the exception of the resolve list (which has a different size and format in a Resolve response message) and the four fields following the resolve list, all fields of an Interswitch Resolve message are allocated by the originating switch, and unless otherwise noted below, are written by the originating switch.
除解析列表（在解析响应消息中具有不同的大小和格式）和解析列表后面的四个字段外，交换机间解析消息的所有字段均由发起交换机分配，除非下文另有说明，否则由发起交换机写入。
Frame header/ISMP packet header
帧报头/ISMP数据包报头
This 20-octet field contains the frame header and the ISMP packet header.
此20个八位字节字段包含帧头和ISMP数据包头。
Version
版本
This 2-octet field contains the version number of the message type. This section describes version 3 of the Interswitch Resolve message.
此2-octet字段包含消息类型的版本号。本节介绍交换机间解析消息的版本3。
Opcode
操作码
This 2-octet field contains the operation code of the message. Valid values are as follows:
此2-octet字段包含消息的操作代码。有效值如下所示：
1 The message is a Resolve request. 2 The message is a Resolve response. 3 (unused in Resolve messages) 4 (unused in Resolve messages)
1该消息是一个解决请求。2该消息是一个解析响应。3（在解析消息中未使用）4（在解析消息中未使用）
The originating switch writes a value of 1 to this field, while the responding switch writes a value of 2.
发起开关将值1写入此字段，而响应开关将值2写入。
Status
地位
This 2-octet field contains the status of a Resolve response message. Valid values are as follows:
此2-octet字段包含解析响应消息的状态。有效值如下所示：
0 The Resolve request succeeded (ResolveAck). 1 (unused) 2 The Resolve request failed (Unknown).
0解析请求成功（ResolveAck）。1（未使用）2解析请求失败（未知）。
This field is written by the responding switch.
此字段由响应开关写入。
Call tag
呼叫标签
This 2-octet field contains the call tag of the endstation packet for which this Resolve request is issued. The call tag is a 16- bit value (generated by the originating switch) that uniquely identifies the packet.
此2-octet字段包含发出此解析请求的端站数据包的调用标记。呼叫标签是一个16位的值（由发起交换机生成），它唯一地标识数据包。
Source MAC of packet
包的源MAC
This 6-octet field contains the physical (MAC) address of the endstation that originated the packet identified by the call tag.
此6位字节字段包含发起由呼叫标签标识的数据包的终端站的物理（MAC）地址。
Originating switch MAC
始发交换机MAC
This 6-octet field contains the physical (MAC) address of the switch that issued the original Resolve request.
此6位字节字段包含发出原始解析请求的交换机的物理（MAC）地址。
Owner switch MAC
所有者交换MAC
This 6-octet field contains the physical (MAC) address of the switch to which the destination endstation is attached -- that is, the switch that was able to resolve the requested addressing information. This field is written by the owner switch.
此6位字节字段包含目标端站连接到的交换机的物理（MAC）地址，即能够解析请求的寻址信息的交换机。此字段由所有者开关写入。
If the status of the response is Unknown, this field is irrelevant.
如果响应的状态未知，则此字段不相关。
Known destination address
已知目的地址
This variable-length field contains the known attribute of the destination endstation address. This address is stored in Tag/Length/Value format.
此可变长度字段包含目标端站地址的已知属性。此地址以标记/长度/值格式存储。
Count
计数
This 1-octet field contains the number of address attributes requested or returned. This is the number of items in the resolve list.
此1-octet字段包含请求或返回的地址属性数。这是“解决”列表中的项数。
Resolve list
解析列表
This variable-length field contains a list of the address attributes either requested by the originating switch or returned by the owner switch. Note that in a Resolve request message, this list contains only the tags of the requested address attributes. On the other hand, a Resolve response message with a status of ResolveAck contains the full TLV of each resolved address attribute. The number of entries in the list is specified in the count field.
此可变长度字段包含由原始交换机请求或由所有者交换机返回的地址属性列表。请注意，在解析请求消息中，此列表仅包含请求的地址属性的标记。另一方面，状态为ResolveAck的Resolve响应消息包含每个已解析地址属性的完整TLV。列表中的条目数在“计数”字段中指定。
In an Interswitch Resolve response message, this field is irrelevant if the status of the response is Unknown.
在交换机间解析响应消息中，如果响应状态未知，则此字段不相关。
Actual destination switch MAC
实际目的地交换机MAC
This 6-octet field contains the physical (MAC) address of the actual switch within the chassis to which the endstation is attached. If the status of the response is Unknown, this field is irrelevant.
此6-octet字段包含终端站所连接机箱内实际交换机的物理（MAC）地址。如果响应的状态未知，则此字段不相关。
Downlink chassis MAC
下行机箱MAC
This 6-octet field contains the physical (MAC) address of the downlink chassis. If the status of the response is Unknown, this field is irrelevant.
此6位字节字段包含下行链路机箱的物理（MAC）地址。如果响应的状态未知，则此字段不相关。
Actual chassis MAC
实际机箱MAC
This 6-octet field contains the physical (MAC) address of the uplink chassis. If the status of the response is Unknown, this field is irrelevant.
此6位字节字段包含上行链路机箱的物理（MAC）地址。如果响应的状态未知，则此字段不相关。
Domain name
域名
This 16-octet field contains the ASCII name of the domain. If the status of the response is Unknown, this field is irrelevant.
此16个八位字节字段包含域的ASCII名称。如果响应的状态未知，则此字段不相关。
The Interswitch New User message consists of a variable number of octets, as shown below:
Interswitch新用户消息由可变数量的八位字节组成，如下所示：
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 (type 5) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | Version | Opcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | Status | Call Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 | |
+ Source MAC of packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
32 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Originating switch MAC +
36 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
40 | |
+ Previous owner switch MAC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
44 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
48 | :
: MAC address of new user +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
70 | Count | |
+-+-+-+-+-+-+-+-+ +
74 | Resolve list |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (type 5) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | Version | Opcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | Status | Call Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 | |
+ Source MAC of packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
32 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Originating switch MAC +
36 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
40 | |
+ Previous owner switch MAC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
44 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
48 | :
: MAC address of new user +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
70 | Count | |
+-+-+-+-+-+-+-+-+ +
74 | Resolve list |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the following description of the message fields, the term "originating" switch refers to the switch that issued the original Interswitch New User request. The term "previous owner" switch refers to that switch to which the endstation was previously attached. And the term "responding" switch refers to either the "previous owner" switch or to a switch at the end of the switch flood path that did not own the endstation but issues an Interswitch New User response because it has no downstream neighbors.
在以下消息字段的描述中，术语“始发”交换机指发出原始交换机间新用户请求的交换机。术语“先前所有者”开关指终端站先前连接的开关。术语“响应”交换机指的是“以前的所有者”交换机或交换机泛洪路径末端的交换机，该交换机不拥有终端站，但发出交换机间新用户响应，因为它没有下游邻居。
With the exception of the resolve list, all fields of an Interswitch New User message are allocated by the originating switch, and unless otherwise noted below, are written by the originating switch.
除解析列表外，交换机间新用户消息的所有字段均由发起交换机分配，除非下文另有说明，否则由发起交换机写入。
Frame header/ISMP packet header
帧报头/ISMP数据包报头
This 20-octet field contains the frame header and the ISMP packet header.
此20个八位字节字段包含帧头和ISMP数据包头。
Version
版本
This 2-octet field contains the version number of the message type. This document describes ISMP message type 5, version 1.
此2-octet字段包含消息类型的版本号。本文档介绍ISMP消息类型5，版本1。
Opcode
操作码
This 2-octet field contains the operation code of the message. Valid values are as follows:
此2-octet字段包含消息的操作代码。有效值如下所示：
1 (unused in a New User message) 2 (unused in a New User message) 3 The message is a New User request. 4 The message is a New User response.
1（在新用户消息中未使用）2（在新用户消息中未使用）3该消息是新用户请求。4该消息是一个新的用户响应。
The originating switch writes a value of 3 to this field, while the responding switch writes a value of 4.
发起开关将值3写入此字段，而响应开关将值4写入。
Status
地位
This 2-octet field contains the status of a New User response message. Valid values are as follows:
此2-octet字段包含新用户响应消息的状态。有效值如下所示：
0 VLAN resolution successful (NewUserAck) 1 (unused) 2 VLAN resolution unsuccessful (NewUserUnknown)
0 VLAN解析成功（NewUserAck）1（未使用）2 VLAN解析失败（NewUserUnknown）
This field is written by the responding switch.
此字段由响应开关写入。
Call tag
呼叫标签
This 2-octet field contains the call tag of the endstation packet for which this New User request is issued. The call tag is a 16- bit value (generated by the originating switch) that uniquely identifies the packet that caused the switch to identify the endstation as a new user.
此2-octet字段包含发出此新用户请求的终端站数据包的呼叫标签。呼叫标签是一个16位的值（由发起交换机生成），它唯一地标识导致交换机将终端站标识为新用户的数据包。
Source MAC of packet
包的源MAC
This 6-octet field contains the physical (MAC) address of the endstation that originated the packet identified by the call tag.
此6位字节字段包含发起由呼叫标签标识的数据包的终端站的物理（MAC）地址。
Originating switch MAC
始发交换机MAC
This 6-octet field contains the physical (MAC) address of the switch that issued the original New User request.
此6位字节字段包含发出原始新用户请求的交换机的物理（MAC）地址。
Previous owner switch MAC
前所有者交换机MAC
This 6-octet field contains the physical (MAC) address of the switch to which the endstation was previously attached -- that is, the switch that was able to resolve the VLAN information. This field is written by the previous owner switch.
此6-octet字段包含终端站先前连接到的交换机的物理（MAC）地址，即能够解析VLAN信息的交换机。此字段由上一个所有者开关写入。
If the status of the response is Unknown, this field is irrelevant.
如果响应的状态未知，则此字段不相关。
MAC address of new user
新用户的MAC地址
This 24-octet field contains the physical (MAC) address of the new user endstation, stored in Tag/Length/Value format.
此24个八位字节字段包含新用户端站的物理（MAC）地址，以Tag/Length/Value格式存储。
Count
计数
This 1-octet field contains the number of VLAN identifiers returned. This is the number of items in the resolve list. This field is written by the previous owner switch.
此1-octet字段包含返回的VLAN标识符的数量。这是“解决”列表中的项数。此字段由上一个所有者开关写入。
If the status of the response is Unknown, this field and the resolve list are irrelevant.
如果响应的状态未知，则此字段和解决列表无关。
Resolve list
解析列表
This variable-length field contains a list of the VLAN identifiers of all static VLANs to which the endstation belongs, stored in Tag/Length/Value format (see Section 2.3). The number of entries in the list is specified in the count field. This list is written by the previous owner switch.
此可变长度字段包含终端站所属的所有静态VLAN的VLAN标识符列表，以标记/长度/值格式存储（见第2.3节）。列表中的条目数在“计数”字段中指定。此列表由上一个所有者开关写入。
If the status of the response is Unknown, this field is irrelevant.
如果响应的状态未知，则此字段不相关。
There are two versions of the Interswitch Tag-Based Flood message used by the SecureFast VLAN product.
SecureFast VLAN产品使用两种版本的基于交换机间标签的泛洪消息。
The Interswitch Tag-Based Flood message used by SFVLAN prior to version 1.8 consists of a variable number of octets, as shown below:
SFVLAN在版本1.8之前使用的基于交换机间标签的泛洪消息由可变数量的八位字节组成，如下所示：
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 (type 7) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | Version | Opcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | Status | Call Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 | |
+ Source MAC of packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
32 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Originating switch MAC +
36 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
40 | Count | |
+-+-+-+-+-+-+-+-+ +
44 | VLAN list |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n | |
+ +
: Original packet :
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (type 7) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | 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
n=41+VLAN列表的长度
Frame header/ISMP packet header
帧报头/ISMP数据包报头
This 20-octet field contains the frame header and the ISMP packet header.
此20个八位字节字段包含帧头和ISMP数据包头。
Version
版本
This 2-octet field contains the version number of the message type. This document describes ISMP message type 7, version 1.
此2-octet字段包含消息类型的版本号。本文档介绍ISMP消息类型7，版本1。
Opcode
操作码
This 2-octet field contains the operation code of the message. The value here should be 1, indicating the message is a flood request.
此2-octet字段包含消息的操作代码。此处的值应为1，表示消息是洪水请求。
Status
地位
This 2-octet field is currently unused. It is reserved for future use.
此2-octet字段当前未使用。这是留作将来使用的。
Call tag
呼叫标签
This 2-octet field contains the call tag of the endstation 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.
此2-octet字段包含封装在此基于标记的泛洪消息中的终端站数据包的呼叫标记。呼叫标签是一个16位值（由发起交换机生成），它唯一地标识数据包。
Source MAC of packet
包的源MAC
This 6-octet field contains the physical (MAC) address of the endstation that originated the packet identified by the call tag.
此6位字节字段包含发起由呼叫标签标识的数据包的终端站的物理（MAC）地址。
Originating switch MAC
始发交换机MAC
This 6-octet field contains the physical (MAC) address of the switch that issued the original tag-based flooded message.
此6-octet字段包含发出原始基于标记的消息的交换机的物理（MAC）地址。
Count
计数
This 1-octet field contains the number of VLAN identifiers included in the VLAN list.
此1-octet字段包含VLAN列表中包含的VLAN标识符的数量。
VLAN list
VLAN列表
This variable-length field contains a list of the VLAN identifiers of all VLANs to which the source endstation belongs. Each entry in this list has the following format:
此可变长度字段包含源端站所属的所有VLAN的VLAN标识符列表。此列表中的每个条目的格式如下：
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 |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
1-octet值长度字段包含VLAN标识符的长度。VLAN标识符的长度可以是1到16个字符。
Original packet
原始数据包
This variable-length field contains the original packet as sent by the source endstation.
此可变长度字段包含源端站发送的原始数据包。
The Interswitch Tag-Based Flood message used by SFVLAN version 1.8 consists of a variable number of octets, as shown below:
SFVLAN版本1.8使用的基于交换机间标签的泛洪消息由可变数量的八位字节组成，如下所示：
Note:
注:
SFVLAN version 1.8 also recognizes the Interswitch Tag-Based Flood message as described in Section 6.6.1.
SFVLAN版本1.8还可识别第6.6.1节所述的基于交换机间标签的泛洪消息。
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 (type 7) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | VLAN identifier | Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | Opcode | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 | Call tag | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source MAC of packet +
32 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
36 | |
+ Originating switch MAC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
40 | | Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
44 | |
: VLAN list :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n | |
+ +
: Original packet :
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (type 7) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | VLAN identifier | Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | Opcode | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 | Call tag | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source MAC of packet +
32 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
36 | |
+ Originating switch MAC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
40 | | Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
44 | |
: VLAN list :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n | |
+ +
: Original packet :
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n = 41 + length of VLAN list
n=41+VLAN列表的长度
Frame header/ISMP packet header
帧报头/ISMP数据包报头
This 20-octet field contains the frame header and the ISMP packet header.
此20个八位字节字段包含帧头和ISMP数据包头。
- The frame header source address contains a value of 02-00-1D-00-xx-yy, where xx-yy is a value set by the VLAN Manager application to tag the frame header with the VLAN identifier. This value ranges from 2 to 4095. For example, a value of 100 would be set as 00-64.
- 帧头源地址包含值02-00-1D-00-xx-yy，其中xx yy是VLAN管理器应用程序设置的值，用于用VLAN标识符标记帧头。该值的范围为2到4095。例如，值100将设置为00-64。
- The frame header type field contains a value of 0x81FF. Note that this differs from all other ISMP messages.
- 帧头类型字段包含值0x81FF。请注意，这与所有其他ISMP消息不同。
VLAN identifier
VLAN标识符
This 2-octet field contains the VLAN identifier of the packet source.
此2-octet字段包含数据包源的VLAN标识符。
Version
版本
This 2-octet field contains the version number of the message type. This section describes version 2 of the Interswitch Tag-Based Flood message.
此2-octet字段包含消息类型的版本号。本节介绍基于交换机间标签的泛洪消息的版本2。
Opcode
操作码
This 2-octet field contains the operation code of the message. Valid values here are as follows:
此2-octet字段包含消息的操作代码。此处的有效值如下所示：
1 The message is a flood request. The original packet is complete within this message.
1该消息是一个泛洪请求。原始数据包在此消息中已完成。
2 The message is a fragmented flood request. The first portion of the original packet is contained in this message.
2该消息是一个分段的泛洪请求。原始数据包的第一部分包含在此消息中。
3 The message is a fragmented flood request. The second portion of the original packet is contained in this message.
3该消息是一个分段洪水请求。原始数据包的第二部分包含在此消息中。
Status
地位
This 2-octet field is currently unused. It is reserved for future use.
此2-octet字段当前未使用。这是留作将来使用的。
Call tag
呼叫标签
This 2-octet field contains the call tag of the endstation 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.
此2-octet字段包含封装在此基于标记的泛洪消息中的终端站数据包的呼叫标记。呼叫标签是一个16位值（由发起交换机生成），它唯一地标识数据包。
Source MAC of packet
包的源MAC
This 6-octet field contains the physical (MAC) address of the endstation that originated the packet identified by the call tag.
此6位字节字段包含发起由呼叫标签标识的数据包的终端站的物理（MAC）地址。
Originating switch MAC
始发交换机MAC
This 6-octet field contains the physical (MAC) address of the switch that issued the original tag-based flooded message.
此6-octet字段包含发出原始基于标记的消息的交换机的物理（MAC）地址。
Count
计数
This 1-octet field contains the number of VLAN identifiers included in the VLAN list.
此1-octet字段包含VLAN列表中包含的VLAN标识符的数量。
VLAN list
VLAN列表
This variable-length field contains a list of the VLAN identifiers of all VLANs to which the source endstation belongs. Each entry in this list has the following format:
此可变长度字段包含源端站所属的所有VLAN的VLAN标识符列表。此列表中的每个条目的格式如下：
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 |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
1-octet值长度字段包含VLAN标识符的长度。VLAN标识符的长度可以是1到16个字符。
Original packet
原始数据包
This variable-length field contains the original packet as sent by the source endstation.
此可变长度字段包含源端站发送的原始数据包。
The Interswitch Tap/Untap message consists of a variable number of octets, as shown below:
开关间Tap/Untap消息由可变数量的八位字节组成，如下所示：
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 (type 8) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | Version | Opcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24 | Status | Error code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28 | Header type | Header length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
32 | Direction | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Probe switch MAC +
36 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
40 | Probe port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
44 | |
+ +
48 | (Reserved) |
+ +
52 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
56 | |
+ +
| Header |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (type 8) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20 | Version | Opcode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
帧报头/ISMP数据包报头
This 20-octet field contains the frame header and the ISMP packet header.
此20个八位字节字段包含帧头和ISMP数据包头。
Version
版本
This 2-octet field contains the version number of the message type. This document describes ISMP message type 8, version 1.
此2-octet字段包含消息类型的版本号。本文档介绍ISMP消息类型8，版本1。
Opcode
操作码
tet field contains the operation type of the message. ues are as follows:
tet字段包含消息的操作类型。用途如下:
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.
1该消息是一个点击请求。2该消息为点击响应。3该消息是Untap请求。4该消息是Untap响应。
Status
地位
This 2-octet field contains the current status of the tap request. Valid values are as follows:
此2-octet字段包含tap请求的当前状态。有效值如下所示：
1 Switch must disable outport on untap. (DisableOutport) 2 Switch must keep outports on untap. (KeepOutport) 3 Probe not found this leg of spanning tree. (ProbeNotFound) 4 Still searching for probe switch. (OutportDecisionUnknown) 5 Unassigned. (StatusUnassigned) 6 (reserved) 7 (reserved) 8 (reserved) 9 (reserved)
1开关必须禁用untap上的输出端口。（禁用输出端口）2开关必须将输出端口保持在untap上。（KeepOutport）3探测器未找到生成树的此分支。（ProbeNotFound）4仍在搜索探针开关。（OutportDecisionUnknown）5未分配。（未分配状态）6（保留）7（保留）8（保留）9（保留）
See Section 5.2.3 for details on the use of this field.
有关该字段使用的详细信息，请参见第5.2.3节。
Error code
错误代码
This 2-octet field contains the response message error code of the requested operation. Valid values are as follows:
此2-octet字段包含请求操作的响应消息错误代码。有效值如下所示：
1 Operation successful. (NoError) 2 No response heard from downstream neighbor. (Timeout) 3 Port does not exist on probe switch. (BadPort) 4 Message invalid. (InvalidMessage) 5 Version number invalid. (IncompatibleVersions)
1手术成功。（无错误）2未听到下游邻居的响应。（超时）探测器交换机上不存在3端口。（BadPort）4消息无效。（InvalidMessage）5版本号无效。（不兼容）
Header type
标题类型
This 2-octet field contains the type of information contained in the header field. Currently, valid values are as follows:
此2-octet字段包含标头字段中包含的信息类型。目前，有效值如下所示：
1 (reserved) 2 Header contains destination and source endstation MAC addresses.
1（保留）2报头包含目标和源端站MAC地址。
Header length
首部长度
This 2-octet field contains the length of the header field. Currently, this field always contains a value of 12.
此2-octet字段包含标题字段的长度。当前，此字段始终包含值12。
Direction
方向
This 2-octet field contains a value indicating the type of tap. Valid values are as follows:
此2-octet字段包含一个指示抽头类型的值。有效值如下所示：
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.
1（保留）2抽头是双向的，应在连接的任意方向捕获数据流。3 Tap是单向的，仅当数据从源流向目标时才应捕获数据。
Probe switch MAC
探测开关MAC
This 6-octet field contains the physical (MAC) address of the switch to which the probe is attached.
此6-octet字段包含探测器连接到的交换机的物理（MAC）地址。
Probe port
探测端口
This 4-octet field contains the logical port number (on the probe switch) to which the probe is attached.
此4-octet字段包含探测器连接到的逻辑端口号（位于探测器交换机上）。
Reserved
含蓄的
These 12 octets are reserved.
这12个八位组是保留的。
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.
此可变长度字段包含标识正在分接的连接的标头。标题的长度存储在长度字段中。
Currently, this field is 12 octets long and contains the 6-octet physical address of the connection's destination endstation, followed by the 6-octet physical address of the connection's source endstation, as shown below:
当前，此字段的长度为12个八位字节，包含连接的目标端站的6个八位字节的物理地址，后跟连接的源端站的6个八位字节的物理地址，如下所示：
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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Requested call connections are established or denied based on the VLAN policy of the source and destination addresses specified within the packet. Section 4.4.1 discusses this process in detail.
根据数据包中指定的源地址和目标地址的VLAN策略建立或拒绝请求的呼叫连接。第4.4.1节详细讨论了该过程。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[RFC1700]Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。
[IEEE] "IEEE Standard 802.1d -- 1990"
[IEEE]“IEEE标准802.1d--1990”
[IDvlsp] Kane, L., "Cabletron's VLS Protocol Specification", RFC 2642, August 1999.
[IDvlsp]Kane，L.，“Cabletron的VLS协议规范”，RFC 26421999年8月。
[IDhello] Hamilton, D. and D. Ruffen, "Cabletron's VlanHello Protocol Specification", RFC 2641, August 1999.
[IDhello]Hamilton，D.和D.Ruffen，“Cabletron的VlanHello协议规范”，RFC 26411999年8月。
Dave Ruffen Cabletron Systems, Inc. Post Office Box 5005 Rochester, NH 03866-5005
Dave Ruffen Cabletron Systems，Inc.新罕布什尔州罗切斯特市邮政信箱5005号，邮编03866-5005
Phone: (603) 332-9400 EMail: ruffen@ctron.com
电话：（603）332-9400电子邮件：ruffen@ctron.com
Ted Len Cabletron Systems, Inc. Post Office Box 5005 Rochester, NH 03866-5005
Ted Len Cabletron Systems，Inc.新罕布什尔州罗切斯特市邮政信箱5005号，邮编03866-5005
Phone: (603) 332-9400 EMail: len@ctron.com
电话：（603）332-9400电子邮件：len@ctron.com
Judy Yanacek Cabletron Systems, Inc. Post Office Box 5005 Rochester, NH 03866-5005
Judy Yanacek Cabletron Systems，Inc.新罕布什尔州罗切斯特市邮政信箱5005号，邮编03866-5005
Phone: (603) 332-9400 EMail: jyanacek@ctron.com
电话：（603）332-9400电子邮件：jyanacek@ctron.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。