IEEE Standard for Local and metropolitan area networks. The structure of the Filtering Database that is required in order to support Virtual Bridged LANs

Figure 8-8              Example of operation of port-and-protocol based classification

Replace the existing text of 8.6, inserting new subclauses 8.6.1 through 8.6.4, and modifying the existing text of 8.6 to form subclause 8.6.5, as follows:

8.6.1 Protocol Classification

Protocol Classification is not defined for Bridges that support only Port-based VLAN classification.

For frames received from the E-ISS on bridge ports which implement Port-and-Protocol-based VLAN classification, the following procedures are followed in order to classify the frame s format and protocol. These procedures are described as if they assigned values to parameters that are used as input to the Ingress Rules.

The detagged_frame_type parameter indicates the frame format. The value is determined as follows:

a)  If the frame is Untagged or Priority Tagged, this parameter is present and indicates the link-layer encapsulation format of the Detagged Frame. The Detagged Frame of an Untagged Frame is the Frame itself. The Detagged Frame of a Tagged Frame or Priority Tagged Frame is the Frame which results from untagging the Frame by the procedure described in 9.1. The value of detagged_frame_type is as follows:

1)  Ethernet, if the Detagged Frame uses Type-encapsulated 802.3 format

2)  RFC_1042, if the Detagged Frame is of the format specified by 10.5 in IEEE Std 802 for the encoding of an IEEE 802.3 Type Field in an 802.2/SNAP header (this supersedes the original definition, which appeared in RFC 1042)

3)  SNAP_8021H, if the Detagged Frame is of the format specified by IEEE Std. 802.1H for the encoding of an IEEE 802.3 Type Field in an 802.2/SNAP header

4)  SNAP_Other, if the Detagged Frame contains an LLC UI PDU with DSAP and SSAP fields equal to the LLC address reserved for SNAP and the 5-octet SNAP Protocol Identifier (PID) value is not in either of the ranges used for RFC_1042 or SNAP_8021H above

5)  LLC_Other, if the Detagged Frame contains both a DSAP and an SSAP address field in the positions specified by IEEE 802.2 Logical Link Control, but is not any of the formats described for LLC frames above

b)  Else the parameter is not present.

The ethertype parameter is present if the detagged_frame_type parameter is present and has the value Ethernet, RFC_1042, or SNAP_8021H. Its value is the IEEE 802.3 Type Field present in the Detagged Frame.The value is determined as follows:

c)  If the detagged_frame_type parameter is present and has the value Ethernet, RFC_1042, or SNAP_8021H, then this parameter is present and has the value of the IEEE 802.3 Type Field present in the Detagged Frame.

d)  Else the parameter is not present.

The llc_saps parameter is present if the detagged_frame_type parameter is present and has the value LLC_Other. Its value is determined as follows:

e)  If the detagged_frame_type parameter is present and has the value LLC_Other then this parameter is present and its value is the pair of LLC 802.2 DSAP and SSAP address field values.

f)  Else the parameter is not present.

NOTE 1 A frame that is encapsulated using values of hex FF/FF in the position where an LLC header is to be expected (as defined by IEEE Std 802.2, 1998 Edition) is known as a Novell IPX Raw encapsulation. Such frames do not conform to IEEE Std 802.2 in that they do not include some of the other required LLC fields. For the purposes of this standard, they are treated as LLC_Other, regardless of whether they are legal LLC frames or not.

NOTE 2 Bridges are not required, for the purposes of this standard, to completely verify the format of frames as meeting IEEE Std 802.2 or not: they are only required to recognize the DSAP and SSAP fields of such frames.

The snap_pid parameter is present if the detagged_frame_type parameter is present and has the value SNAP_Other. Its value is determined as follows:

g)  If the detagged_frame_type parameter is present and has the value SNAP_Other then the parameter is present and its value is the contents of the 5 octets following the LLC header, i.e., the PID field. h) Else the parameter is not present.

8.6.2 Protocol Templates

Protocol Templates are not defined for Bridges that support only Port-based VLAN classification.

In a Bridge that supports Port-and-Protocol-based VLAN classification, a Protocol Template is a tuple that specifies a protocol to be identified in received frames. A Protocol Template has one of the following formats:

a)  A value Ethernet and a 16-bit IEEE 802.3 Type Field value

b)  A value RFC_1042 and a 16-bit IEEE 802.3 Type Field value

c)  A value SNAP_8021H and a 16-bit IEEE 802.3 Type Field value

d)  A value SNAP_Other and a 40-bit PID value

e)  A value LLC_Other and a pair of IEEE 802.2 LSAP values: DSAP and SSAP

A Protocol Template matches a Frame if

f)  The Frame s detagged_frame_type is Ethernet, the Protocol Template is of type Ethernet, and the frame s IEEE 802.3 Type Field is equal to the value of the IEEE 802.3 Type Field of the Protocol Template, or

g)  The Frame s detagged_frame_type is RFC_1042, the Protocol Template is of type RFC_1042 and the frame s IEEE 802.3 Type Field is equal to the IEEE 802.3 Type Field of the Protocol Template, or

h)  The Frame s detagged_frame_type is SNAP_8021H, the Protocol Template