Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.

0+suggested changes
November 4, 2008

1 13. Spanning Tree Protocols

2
3 The spanning tree algorithms and protocols specified by this standard provide simple and full connectivity
4 throughout a Bridged Local Area Network comprising arbitrarily interconnected bridges. Each bridge can
5 use the Rapid Spanning Tree Protocol (RSTP), Multiple Spanning Tree Protocol (MSTP), or SPB (Shortest
6 Path Bridging) protocols.
7
8 NOTE 1—The spanning tree protocols specified by this standard supersede the Spanning Tree Protocol (STP) specified
9 in IEEE Std 802.1D revisions prior to 2004, but facilitate migration by interoperating with the latter without
10 configuration restrictions beyond those previously imposed by STP. However networks that include bridges using STP
can reconfigure slowly and constrain active topologies.
11
12
NOTE 2—Although the active topologies determined by the spanning tree protocols connect all the components of a
13 Bridged Local Area Network, filtering (MVRP, etc.) can restrict frames to a subset of each active topology.
14
15 RSTP assigns all frames to a Common Spanning Tree (CST), without being aware of the active topology
16 assignments made by MSTP or SPB that allow frames to follow separate paths within Multiple Spanning
17 Tree (MST) or Shortest Path Tree (SPT) Regions. Each of these regions comprises MST or SPT Bridges that
18 consistently assign any given frame to the same active topology (see 8.4) and the LANs that interconnect
19 those bridges. These regions and other bridges and LANs are connected into the CST, to provide loop free
20 network wide connectivity even if active topology assignments or spanning tree protocols differ locally.
21
22 MSTP and SPB connect all bridges and LANs with a single Common and Internal Spanning Tree (CIST)
23 that supports the automatic determination of each region, choosing its maximum possible extent. The
24 connectivity calculated for the CIST provides the CST for interconnecting the regions, and an Internal
25 Spanning Tree (IST) within each region. MSTP calculates a number of independent Multiple Spanning Tree
26 Instances (MSTIs) within each region, and ensures that frames with a given VID are assigned to one and
27 only one of the MSTIs or the IST within the region (or reserved for use by SPB or PBB-TE), that the
28 assignment is consistent among all bridges within the region, and that the stable connectivity of each MSTI
29 and the IST at the boundary of the region matches that of the CST. SPB calculates symmetric sets of Shortest
30 Path Trees (SPTs), each rooted at a bridge within a region, and ensures that frames for any given VLAN are
31 assigned to the same symmetric SPT set within the region (or to the IST, an MSTI, or PBB-TE). Within an
32 SPT Region, each shortest path bridged frame is assigned to the SPT rooted at the bridge providing ingress
33 to the region for that frame, either by replacing the frame’s Base VID (3.1) with one of a number of Shortest
34 Path VIDs (SPVIDs) that support its VLAN within the region, or (when its VLAN is supported by shortest
35 path backbone bridging) by using the frame’s source address in conjunction with the Base VID. SPB
36 protocols can dynamically allocate SPVIDs and ensure that their allocation is consistent within a region.
37
38 Spanning tree protocol entities transmit and receive BPDUs (Clause 14) to convey parameters used by RSTP
39 and MSTP to calculate CST, CIST, and MSTI spanning trees. BPDUs also convey parameters that are used
40 by all spanning tree protocols to interoperate with each other and with STP, that determine the extent of
41 MST and SPT Regions, and that ensure that temporary loops are not created because neighbouring bridges
42 are not yet acting on the same topology information. SPB uses ISIS (see Clause 29) to disseminate the
43 information used to calculate the IST and SPTs, and to perform that calculation, and Tree Agreement
44 Protocol (TAP, 13.17) to ensure loop-free connectivity. TAP Messages are conveyed within BPDUs.
45
46 This clause
47
48 a) Specifies protocol design and support requirements (13.1, 13.2) and design goals (13.3).
49 b) Provides an overview of RSTP (13.4), MSTP (13.5), SPB and SPBB (13.6) operation.
50 c) Describes how the spanning tree protocols interoperate and coexist (13.7)
51 d) Specifies how spanning tree priority vectors (13.9) are calculated (13.10, 13.11) and used to assign
52 the Port Roles (13.12) that determine the Port States, i.e. forwarding and learning (8.4), for each tree.
53 e) Shows that RSTP, MSTP, and the SPB protocols provide stable connectivity (13.13).
54 f) Describes how spanning tree priority vectors are communicated (13.14) and changed (13.15).

Copyright © 2008 IEEE. All rights reserved. 3

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 g) Describes how Port Role are used to change Port States without introducing loops (13.16, 13.17).
2 h) Recommends defaults and ranges for the parameters that determine each tree’s topology (13.18).
3 i) Describes the updating of learned station location information when a tree reconfigures (13.19).
4 j) Specifies additional controls that can speed reconfiguration or prevent unwanted outcomes (13.20).
5 k) Describes how loops are prevented when a LAN is only providing one-way connectivity (13.21),
6 and can be prevented when the network includes bridges whose protocol operation can fail (13.22).
7 l) Describes how a bridge’s protocol processing can be ‘hot upgraded’ in an active network (13.23).
8 m) Specifies RSTP, MSTP, and TAP using state machines (13.24–13.40).
9 n) Specifies the use and configuration of the spanning tree protocols for the special cases of a Provider
10 Edge Bridge’s Customer Edge Ports (13.41), a Backbone Edge Bridge’s Virtual Instance Ports
11 (13.42), and an L2 Gateway Port connecting a customer to a provider (13.43).
12
13 NOTE 3—Readers of this specification are urged to begin by familiarizing themselves with RSTP.
14
15 Clause 14 specifies the format of BPDUs. Clause 27 describes the uses of Shortest Path Bridging. Clause 29
16 specifies ISIS-SPB. The text of this clause (Clause 13) takes precedence should any conflict be apparent
17 between it and the text in other parts of this standard (in particular, Clause 12, Clause 14, and Annex A).
18
19
13.1 Protocol design requirements
20
21
The Spanning Tree Algorithm and its associated protocols operate in Bridged Local Area Networks of
22
arbitrary physical topology comprising SPT, MST, RST, or STP Bridges connecting shared media or point-
23
to-point LANs, so as to support, preserve, and maintain the quality of the MAC Service in all its aspects as
24
specified by Clause 6.
25
26
RSTP configures the Port State (7.4) of each Bridge Port. MSTP configures the Port State for the CIST and
27
each MSTI, and verifies the allocation of VIDs to FIDs and FIDs to trees. SPB protocols configure the Port
28
State for the CIST and each SPT, the VID Translation Table for each Bridge Port, allocate FIDs to SPT sets,
29
and assigns frames to SPTs by SPVIDs and/or source address. Operating both independently and together
30
RSTP, MSTP, and SPB protocols meet the following requirements:
31
32
a) They configure one or more active topologies that fully connect all physically connected LANs and
33
bridges, and stabilize (with high probability) within a short, known bounded interval after any
34
change in the physical topology, maximising service availability (6.5.1).
35
b) The active topology for any given frame remains simply connected at all times (6.5.3, 6.5.4), and
36
will (with high probability) continue to provide simple and full connectivity for frames even in the
37
presence of administrative errors (e.g. in the allocation of VLANs to MSTIs).
38
c) The configured stable active topologies are unicast multicast congruent, downstream congruent, and
39
reverse path congruent (symmetric) (3.2, 6.3).
40
d) The same symmetric active topology is used, in a stable network, for all frames using the same FID,
41
i.e. between any two LANs all such frames are forwarded through the same Bridge Ports (6.3).
42
e) The active topology for a given VLAN can be chosen by the network administrator to be a common
43
spanning tree, one of multiple spanning trees (if MSTP is implemented), or shortest path (if SPB
44
protocols are implemented).
45
f) Each active topology is predictable, reproducible, and manageable, allowing Configuration
46
Management (following traffic analysis) to meet Performance Management goals (6.3 and 6.3.10).
47
g) The configured network can support VLAN-unaware end stations, such that they are unaware of
48
their attachment to a single LAN or a Bridged Local Area Network, or their use of a VLAN (6.2).
49
h) The communications bandwidth on any particular LAN is always a small fraction of the total
50
available bandwidth (6.5.10).
51
52
NOTE—The spanning tree protocols cannot protect against temporary loops caused by the interconnection of LANs by
53 devices other than bridges (e.g., LAN repeaters) that operate invisibly with respect to support of the MAC Internal
54 Sublayer Service and the MAC_Operational status parameter (6.6.2).

4 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 13.2 Protocol support requirements

2
3
In order for the spanning tree protocols to operate, the following are required:
4
5
6 a) A unique Group MAC Address used by the Spanning Tree Protocol Entities (8.10) of participating
7 bridges or bridge components (5.2), and recognized by all the bridges attached to a LAN.
8 b) An identifier for each bridge or bridge component, unique within the Bridged Local Area Network.
9
10 c) A identifier for each Bridge Port, unique within a bridge or bridge component.
11
12 Values for each of these parameters shall be provided by each bridge. The unique MAC Address that
13 identifies the Spanning Tree Protocol Entities of MAC Bridges, VLAN Bridges (5.9), and C-VLAN
14 components (5.5) is the Bridge Group Address (Table 8-1). The unique MAC Address that identifies the
15 Spanning Tree Protocol Entities of S-VLAN components is the Provider Bridge Group Address (Table 8-2).
16
17
To allow management of active topology (for RSTP, MSTP, or SPB) means of assigning values to the
18
following are required:
19
20
21 d) The relative Bridge Priority of each bridge in the network.
22 e) A Port Path Cost for each Bridge Port.
23
24 f) The relative Port Priority of each Bridge Port.
25
26 13.2.1 MSTP support requirements
27
28
MSTP does not require any additional configuration, provided that communication between end stations is
29
supported by a number of VLANs. However, to realize the improved throughput and associated frame loss
30
and transit delay performance improvements made possible by the use of multiple spanning trees, the
31
following are required:
32
33
34 a) Assessment of the probable distribution of traffic between VLANs and between sets of
35 communicating end stations using those VLANs.
36 b) Per MSTI assignment of Bridge Priority and Internal Port Path Costs to configure the MSTIs.
37
38 c) Consistent assignment of VIDs to MSTIDs within each potential MST Region.
39 d) Administrative agreement on the Configuration Name and Revision Level used to represent the
40 assignments of VIDs to MSTIDs.
41
42
13.2.2 SPB support requirements
43
44
45 SPB protocols can provide both common spanning tree and shortest path support for VLANs without further
46 configuration (except as required for ISIS-SPB). To support such operation this standard specifies:
47
48 a) A Configuration Name and Revision Level used to represent the assignment of VLAN 1 to the SPT
49 Primary Set, VLAN 2 to the SPT Alternate Set, and all other VIDs to the CIST.
50
51
52 Use of Shortest Path Backbone Bridging (SPBB) requires the following:
53
54 b) Explicit identification of each VLAN to be shortest path backbone bridged.

Copyright © 2008 IEEE. All rights reserved. 5

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 13.3 Protocol design goals

2
3 All the spanning tree protocols meet the following goal, which simplifies operational practice:
4
5 a) Bridges do not have to be individually configured before being added to the network, other than
6 having their MAC Addresses assigned through normal procedures.
7 b) In normal operation, the time taken to configure the active topology of a network comprising point-
8 to-point LANs is independent of the timer values of the protocol.
9
10
RSTP and MSTP meet the following goal, which limits the complexity of bridges and their configuration:
11
12
13 c) The memory requirements associated with each Bridge Port are independent of the number of
14 bridges and LANs in the network.
15
16 It is highly desirable that the operation of SPB protocols support updating of the SPB configuration, so that:
17
18 d) SPT Bridges can be added to a region without disrupting communication for existing VLANs.
19 e) Additional VLANs can be supported by SPB without disrupting communication for the VLANs that
20 are already supported by SPB, or for those VLANs that supported by RSTP or MSTP.
21 f) Shortest path bridging support can be enabled or disabled for individual VLANs that are being used
22 to support user communication, with the minimum of frame loss on those VLANs.
23
24
25 13.4 RSTP overview
26
27 The Rapid Spanning Tree Protocol (RSTP) configures the Port State (3.5, 8.4) of each Bridge Port in the
28 Bridge Local Area Network. RSTP ensures that the stable connectivity provided by each bridge between its
29 ports and by the individual LANs attached to those ports is predictable, manageable, full, simple, and
30 symmetric. RSTP further ensures that temporary loops in the active topology do not occur if the network has
31 to reconfigure in response to the failure, removal, or addition of a network component, and that erroneous
32 station location information is removed from the Filtering Database after reconfiguration.
33
34 Each of the bridges in the network transmits Configuration Messages (13.14). Each message contains
35 spanning tree priority vector (13.9) information that identifies one bridge as the Root Bridge of the network,
36 and allows each bridge to compute its own lowest path cost to that Root Bridge before transmitting its own
37 Configuration Messages. A Port Role (13.12) of Root Port is assigned to the one port on each bridge that
38 provides that lowest cost path to the Root Bridge, and a Port Role of Designated Port to the one Bridge Port
39 that provides the lowest cost path from the attached LAN to the Root Bridge. Alternate Port and Backup Port
40 roles are assigned to Bridge Ports that can provide connectivity if other network components fail.
41
42 State machines associated with the Port Roles maintain and change the Port States that control forwarding
43 (8.6) and learning (8.7) of frames. In a stable network, Root Ports and Designated Ports are Forwarding,
44 while Alternate, Backup, and Disabled Ports are Discarding. Each Port’s role can change if a Bridge, Bridge
45 Port, or LAN fails, is added to, or removed from network. Port state transitions to Learning and Forwarding
46 are delayed, and ports can temporarily transition to the Discarding state prevent loops and to ensure that
47 misordering (6.5.3) and duplication (6.5.4) rates remain negligible.
48
49 RSTP provides rapid recovery of connectivity to minimize frame loss (6.5.2). A new Root Port, and
50 Designated Ports attached to point-to-point LANs, can transition to Forwarding without waiting for protocol
51 timers to expire. A Root Port can transition to Forwarding without transmitting or receiving messages from
52 other bridges, while a Designated Port attached to a point-to-point LAN can transition when it receives an
53 explicit agreement transmitted by the other bridge attached to that LAN. The forwarding transition delay
54 used by a Designated Port attached to a shared media LAN is long enough for other bridges attached to that

6 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 LAN to receive and act on transmitted messages, but is independent of the overall network size. If all the
2 LANs in a network are point-to-point, RSTP timers define worst-case delays that only occur if protocol
3 messages are lost or rate transmission limits are exceeded.
4
5
6 A Bridge Port attached to a LAN that has no other bridges attached to it may be administratively configured
7 as an Edge Port. RSTP monitors the LAN to ensure that no other bridges are connected, and may be
8 configured to automatically detect an Edge Port. Each Edge Port transitions directly to the Forwarding Port
9 State, since there is no possibility of it participating in a loop.
10
11 13.4.1 Computation of the active topology
12
13
14 The bridge with the best Bridge Identifier is selected as the Root Bridge. The unique Bridge Identifier for
15 each bridge is derived, in part, from the Bridge Address (8.13.8) and, in part, from a manageable priority
16 component (13.26). The relative priority of bridges is determined by the numerical comparison of the unique
17 identifiers, with the lower numerical value indicating the better identifier.
18
19
Every bridge has a Root Path Cost associated with it. For the Root Bridge this is zero. For all other bridges,
20
21 it is the sum of the Port Path Costs on the least cost path to the Root Bridge. Each port’s Path Cost may be
22 managed, 13.18 recommends default values for ports attached to LANs of various speeds.
23
24 The Bridge Port on each bridge with the lowest Root Path Cost is assigned the role of Root Port for that
25 bridge (the Root Bridge does not have a Root Port). If a bridge has two or more ports with the same Root
26 Path Cost, then the port with the best Port Identifier is selected as the Root Port. Part of the Port Identifier is
27 fixed and different for each port on a bridge, and part is a manageable priority component (13.26). The
28
relative priority of Bridge Ports is determined by the numerical comparison of the unique identifiers, with
29
the lower numerical value indicating the better identifier.
30
31
32 Each LAN in the Bridged Local Area Network also has an associated Root Path Cost. This is the Root Path
33 Cost of the lowest cost bridge with a Bridge Port connected to that LAN. This bridge is selected as the
34 Designated Bridge for that LAN. If there are two or more bridges with the same Root Path Cost, then the
35 bridge with the best priority (least numerical value) is selected as the Designated Bridge. The Bridge Port on
36 the Designated Bridge that is connected to the LAN is assigned the role of Designated Port for that LAN. If
37 the Designated Bridge has two or more ports connected to the LAN, then the Bridge Port with the best
38
priority Port Identifier (least numerical value) is selected as the Designated Port.
39
40
41 In a Bridged Local Area Network whose physical topology is stable, i.e RSTP has communicated consistent
42 information throughout the network, every LAN has one and only one Designated Port, and every bridge
43 with the exception of the Root Bridge has a single Root Port connected to a LAN. Since each bridge
44 provides connectivity between its Root Port and its Designated Ports, the resulting active topology connects
45 all LANs (is “spanning”) and will be loop free (is a “tree”).
46
47
48 Any Bridge Port that is enabled, but not a Root or Designated Port, is a Backup Port if that bridge is the
49 Designated Bridge for the attached LAN, and an Alternate Port otherwise. An Alternate Port offers an
50 alternate path in the direction of the Root Bridge to that provided by the bridge’s own Root Port, whereas a
51 Backup Port acts as a backup for the path provided by a Designated Port in the direction of the leaves of the
52 Spanning Tree. Backup Ports exist only where there are two or more connections from a given bridge to a
53 given LAN; hence, they (and the Designated Ports that they back up) can only exist where the bridge has
54 two or more ports attached to a shared media LAN, or directly connected by a point-to-point LAN.

Copyright © 2008 IEEE. All rights reserved. 7

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 13.4.2 Example topologies

2
3 The spanning tree examples in this clause use the conventions of Figure 13-1.
4
5 p.p, pc p.p, pc 0.1,10 0.2,10
A
6
7 A LAN
8 B.b 0.75 Connections between Bridges and LANs
9 indicate the Port Role and Port State by
10
R.r, RC 0.42, 15 means of their end point symbols, and in
some examples, may show the
11 transmission of BPDUs from a Port onto a
12 LAN by means of arrowheads, as shown in
p.p, pc p.p, pc 0.3,10 0.4,10 the following table.
13
14 A template for and example of an STP Bridge. B.b is the Bridge Port Role Port State Legend
15 Identifier (including the manageable priority component B.). R.r and
16 RC are the Root Identifier, Root Path Cost, and the Designated Bridge Designated Discarding
Identifier, for the Root Port. p.p, pc are the Port Identifier (with Learning
17 Forwarding
manageable priority p.) and the Port Path Cost for a Bridge Port.
18 & operEdge Forwarding
19
Root Port Discarding
20 p.p, pc p.p, pc 0.1,10 0.2,10 or Learning
21 Master Port Forwarding
22 Alternate Discarding
23 B.b 0.52 Learning
Forwarding
24
25
R.r, RC 0.42, 5 Backup Discarding

26 "RSTP" RSTP Learning

Forwarding
27 Disabled -
28 p.p, pc p.p, pc 0.3,10 0.4,10
Transmitted Bpdus
29
A template for and example of an RSTP Bridge. Designated
30
Designated Proposal
31 0:p.p,epc,ipc 0:p.p,epc,ipc 0:8.1,10,5 0:8.2,25,5
32 Root
T:p.p,ipc T:p.p,ipc 2:4.1,5 2:4.2,5
Root Agreement
33 B.b 3.65
34 NOTE—These diagrammatic conventions
R.r, ERC 0.42, 10
35 allow the representation of Alternate and
36 "RG"CI RG2 Backup Ports that are in Learning or
37 RR.rr, IRC 3.57, 2 Forwarding states; this can happen as a
T:RR.rr, IRC, B.b 2:3.61, 3, 5.65 transitory condition due to implementation-
38 dependent delays in switching off Learning
0:p.p,epc,ipc 0:p.p,epc,ipc 0:8.3,15,5 0:8.4,15,10
39 T:p.p,ipc T:p.p,ipc 2:4.3,5 2:4.4,5 and/or Forwarding on a Port that changes
40 role from Designated or Root to Alternate
or Backup.
41 A template for and an example of an MSTP Bridge. B.b is the CIST
42 Bridge Identifier. R.r, ERC, RR.rr are the CIST Root Identifier, External
Root Path Cost, and Regional Root Identifier. CI identifies the
43
Configuration Identifier for the Bridge. RR.rr, IRC the CIST Regional
44 Root Identifier and the Internal Root Path Cost. T:RR.rr, IRC, B.b, is
45 the Regional Root Identifier, Internal Root Path Cost IRC, and Bridge
46 Identifier for the MSTI with MSTID T.
-p.p, epc, ipc are the CIST Port Identifier, External Port Path Cost,
47 and Internal Port Path Cost for a Bridge Port. T:p.p, ipc are the Port
48 Identifiers and their Regional Costs for MSTI T.
49 Any of the above information may be selectively omitted if deemed
50 irrelevant for the purposes of a diagram.
51
52 Figure 13-1—Diagrammatic conventions for spanning tree topologies
53
54

8 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 Figure 13-2 shows a simple, redundantly connected, structured wiring configuration, with bridges connected
2 by point-to-point LANs A through N, and a possible spanning tree active topology of the same network.
3 bridge 111 has been selected as the Root (though one cannot tell simply by looking at the active topology
4 which bridge is the Root).
5
A A
6 111 1 1 222 111 1 1 222
7 2 2 2 2
B B
4 3 3 4 4 3 3 4
8
9
10
C D E F C D E F
11
12
1 2 1 2 1 2 1 2
13
333 444 333 444
14 6 3 6 3 6 3 6 3
15 5 4 5 4 5 4 5 4

16
17
18 G I H K J M L N G I H K J M L N
19
20 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2
21 555 666 777 888 555 666 777 888
22
4 3 4 3 4 3 4 3 4 3 4 3 4 3 4 3
23
24
25 Figure 13-2—Physical topology and active topology
26
27 Figure 13-3 shows the Port Roles and Port States of each Bridge Port. It can be seen that bridge 111 is the
28 Root, as its Ports are all Designated Ports, each of the remaining bridges have one Root Port.
29
30 A
111 1 1 222
31 111, 0 2 B 2 111, 10
4 3 3 4
32
33
34
35 C D E F
36
37
38 2 2
1 1
39 333 444
40 6 111, 10 3 6 111, 10 3
5 4 5 4
41
42
43
44 G I H K J M L N
45
46
47 2 2 2 2
1 1 1 1
48 555 666 777 888
49 111, 20 111, 20 111, 20 111, 20
4 3 4 3 4 3 4 3
50
51
52
53
54 Figure 13-3—Port Roles and Port States

Copyright © 2008 IEEE. All rights reserved. 9

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 Figure 13-4 shows the result of connecting two of the ports of bridge 888 to the same LAN. As port 4 of
2 bridge 888 has worse priority than port 3 and both offer the same Root Path Cost, port 4 will be assigned the
3 Backup Port Role and will therefore be in the Discarding Port State. Should port 3 or its connection to LAN
4 O fail, port 4 will be assigned the Designated Port Role and will transition to the Forwarding Port State.
5 A
6 111 1 1 222
111, 0 2 B 2 111, 10
7 4 3 3 4
8
9
10
C D E F
11
12
13
14 1 2 1 2

15 333 444
6 111, 10 3 6 111, 10 3
16 5 4 5 4
17
18
19
G I H K J M L N
20
21
22
23 1 2 1 2 1 2 1 2

24 555 666 777 888

111, 20 111, 20 111, 20 111, 20
25 4 3 4 3 4 3 4 3
26
27
28
O
29
30 Figure 13-4—A Backup Port
31
32
33 Figure 13-5 shows a “ring” topology constructed from point-to-point links, as in some resilient backbone
34 configurations. Bridge 111 is the Root, as in previous examples.
35
36 1 222 2
37 G 3
111 2 A 111, 10 B 1
333 3 I
111, 0 3 111, 20
38 1 2
39
40
41 H
F C
42 K
43
44
45 2 1

46 L 3 666 1 E
3
D 2
444 3 J
111, 10 2
555 1
111, 30
47 111, 20
48
49
50 Figure 13-5—“Ring Backbone” example
51
52
53
54

10 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 13.5 MSTP overview

2
3 The Multiple Spanning Tree Protocol specifies:
4
5 a) An MST Configuration Identifier (13.8) that allows each bridge to advertise its assignment, to a
6 specified MSTI or to the IST, of frames with any given VID.
7 b) A priority vector (13.9) that comprises bridge identifier and path cost information for constructing a
8 deterministic and manageable single spanning tree active topology, the CIST, that:
9 1) Fully and simply connects all bridges and LANs in a Bridged Local Area Network.
10 2) Permits the construction and identification of MST Regions of bridges and LANs that are
11 guaranteed fully connected by the bridges and LANs within each region.
12 3) Ensures that paths within each MST Region are always preferred to paths outside the region.
13 c) An MSTI priority vector (13.9), comprising information for constructing a deterministic and
14 independently manageable active topology for any given MSTI within each region.
15 d) Comparisons and calculations performed by each bridge in support of the distributed spanning tree
16 algorithm (13.10). These select a CIST priority vector for each Bridge Port, based on the priority
17 vectors and MST Configuration Identifiers received from other bridges and on an incremental Path
18 Cost associated with each receiving port. The resulting priority vectors are such that in a stable
19 network:
20 1) One bridge is selected to be the CIST Root of the Bridged Local Area Network as a whole.
21 2) A minimum cost path to the CIST Root is selected for each bridge and LAN, thus preventing
22 loops while ensuring full connectivity.
23 3) The one bridge in each MST Region whose minimum cost path to the Root is not through
24 another bridge using the same MST Configuration Identifier is identified as its region’s CIST
25 Regional Root.
26 4) Conversely, each bridge whose minimum cost path to the Root is through a bridge using the
27 same MST Configuration Identifier is identified as being in the same region as that bridge.
28 e) Priority vector comparisons and calculations performed by each bridge for each MSTI (13.11). In a
29 stable network:
30 1) One bridge is independently selected for each MSTI to be the MSTI Regional Root.
31 2) A minimum cost path to the MSTI Regional Root that lies wholly within the region is selected
32 for each bridge and LAN.
33 f) CIST Port Roles (13.12) that identify the role in the CIST active topology played by each port on a
34 bridge.
35 1) The Root Port provides the minimum cost path from the bridge to the CIST Root (if the bridge
36 is not the CIST Root) through the Regional Root (if the bridge is not a Regional Root).
37 2) A Designated Port provides the least cost path from the attached LAN through the bridge to the
38 CIST Root.
39 3) Alternate or Backup Ports provide connectivity if other bridges, Bridge Ports, or LANs fail or
40 are removed.
41 g) MSTI Port Roles (13.12) that identify the role played by each port on a bridge for each MSTI’s
42 active topology within and at the boundaries of a region.
43 1) The Root Port provides the minimum cost path from the bridge to the MSTI Regional Root (if
44 the bridge is not the Regional Root for this MSTI).
45 2) A Designated Port provides the least cost path from the attached LAN though the bridge to the
46 Regional Root.
47 3) A Master Port provides connectivity from the region to a CIST Root that lies outside the region.
48 The Bridge Port that is the CIST Root Port for the CIST Regional Root is the Master Port for all
49 MSTIs.
50 4) Alternate or Backup Ports provide connectivity if other bridges, Bridge Ports, or LANs fail or
51 are removed.
52 h) State machines and state variables associated with each spanning tree (CIST or MSTI), port, and
53 port role, to select and change the Port State (8.4, 13.24) that controls the processing and forwarding
54 of frames assigned to that tree by a MAC Relay Entity (8.3).

Copyright © 2008 IEEE. All rights reserved. 11

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 13.5.1 Example topologies

2
3 Figure 13-6 is an example Bridged Local Area Network, using the conventions of Figure 13-1, and chosen to
4 illustrate MSTP calculations rather than as an example of a common or desirable physical topology.
5
6 42
7
8 RG1
57 A B 83
9
E D
10 RG1 RG1
11 C
12
13
14
86
15 53
16 RG2
17 G 97 H I 84
18 RG2 RG2
19 65 K J
20
RG2
21 M
22
23
24
77 N 72 L
25
26 F
RG2 RG2
27
28
29
P
30
31
32 94 69 O
75 Q
33 RG3 RG3
34
35
36
S T U
37
38
39 Figure 13-6—An MST Bridge network
40
41 Figure 13-8 is the same network showing bridges and LANs with better CIST spanning tree priorities higher
42 on the page, and including CIST priority vectors, port roles, and MST Regions. In this example:
43
44
a) Bridge 0.42 is the CIST Root because it has the best (numerically lowest) Bridge Identifier.
45
46 b) Bridges 0.57 and 2.83 are in the same MST Region (1) as 0.42, because they have the same MST
47 Configuration Identifier as the latter. Because they are in the same MST Region as the CIST Root,
48 their External Root Path Cost is 0, and their CIST Regional Root is the CIST Root.
49 c) LANs A, B, C, and D are in Region 1 because their CIST Designated Bridge is a Region 1 MST
50 Bridge, and no STP bridges are attached to those LANs. LAN E is not in an MST Region (or in its
51 own region—an equivalent view) because it is attached to bridge 0.53, which is not an MST Bridge.
52 d) Bridges 0.77, 0.65, 0.97, 0.86, 3.84, and 3.72 are in the same MST Region (2) since they have the
53 same MST Configuration Identifier and are interconnected by LANs for which one of them is the
54 CIST Designated Bridge.

12 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1
2 REGION 1
0.42
3 0.42, 0
A B
4 RG1
0.42, 0
5
6 0.1, 5, 1

7 C 2.83
0.1,10, 2
0.42, 0
8
0.57 RG1
9 0.42, 0 D 0.42, 1
E
10 RG1
0.42, 2
11
12
13
0.1, 5, 1
14
F REGION 2
15 0.53 G
16 0.42, 5

17
18
19
0.1,10, 2
20
H 0.86
21 0.42, 10
I
22 RG2
0.86, 0
23
24 0.2,10, 2 0.1, 5, 1

25 0.97 J
0.1, 5, 1
0.42, 10
26 K
RG2 3.84
27 0.86, 1 0.42, 10
L
28 RG2
0.1, 5, 1 0.86, 1
29
M 0.65
30 0.42, 10
N
31 RG2
0.86, 2 0.1, 5, 1
32
3.72
33 0.42, 10
34 RG2
35
0.1, 5,1
O 0.86, 2
P 0.77
36 0.42, 10
37 RG2
0.86, 3
38
39
40 REGION 3 REGION 4
0.1,10, 2 0.2,10, 2
41
42 0.75 0.1, 5,1
Q
43 0.42, 15 0.94
0.42, 15
44
RG3
45 S 0.94, 0
46
0.1,10, 2 0.2,15, 1
47
0.69
48 0.42, 20
T
49 RG3
50 0.69, 2 U
51
52
53 Figure 13-7—CIST Priority Vectors, Port Roles, and MST Regions
54

Copyright © 2008 IEEE. All rights reserved. 13

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 e) Bridge 0.86 is the CIST Regional Root for Region 2 because it is has the lowest External Root Path
2 Cost through a Boundary Port.
3 f) LAN N is in Region 2 because its CIST Designated Bridge is in Region 2. Frames assigned to
4 different MSTIDs may reach N from bridge 0.86 (for example) by either bridge 0.65 or bridge 3.72,
5 even though bridges 0.94 and 0.69 with MST Configuration Identifiers that differ from those for
6 bridges in Region 2 are attached to this shared LAN.
7
8 g) Bridges 0.94 and 0.69 are in different regions, even though they have the same MST Configuration
9 Identifier, because the LAN that connects them (N) is in a different region.
10
11 Figure 13-8 shows a possible active topology of MSTI 2 within Region 2.
12 D
13
14 REGION 2
15
16 G
17
18
19
20 N
21 M 0.65 K
22 0.42, 10

23 RG2
2:0.65, 0, 0.65 2:0.1,1 J
24
0.97 H
25 0.42, 10
26 RG2
2:0.65, 1, 0.97
27 2:0.1, 2 2:0.1,1

28 0.77 0.86 I
0.42, 10 0.42, 10
29 RG2 RG2
30 2:0.65, 2, 0.77 2:0.65, 2, 0.86 2:0.1,1 2:0.2,1

31 3.84 L
32 0.42, 10

33 RG2
2:0.65, 2, 3.84 2:0.1,1 2:0.2, 2
34
35 3.72
0.42, 10
36 RG2
37 O 2:0.65, 2, 3.72

38
39
40
41 Connections to other MST regions
42 Figure 13-8—MSTI Active Topology in Region 2
43
44
45
h) Bridge 0.65 has been chosen as the MSTI Regional Root because it has the best (numerically the
46
lowest) Bridge Identifier of all bridges in the region for this MSTI.
47
48 i) The connectivity between the whole of Region 2 and Region 1 is provided through a single Bridge
49 Port, the Master Port on bridge 0.86. This port was selected for this role because it is the CIST Root
50 Port on the CIST Regional Root for the region (see Figure 13-6).
51 j) The connectivity between the whole of Region 2 and LANs and bridges outside the region for the
52 MSTI is the same as that for the CIST. This connectivity is similar to that which might result by
53 replacing the entire region by a single SST Bridge. The region has a single Root Port (this port is the
54 Master Port for each MSTI) and a number of Designated Ports.

14 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 13.5.2 Relationship of MSTP to RSTP

2
3 MSTP is based on RSTP, extended so frames for different VLANs can follow different trees within regions.
4
5 a) The same fundamental spanning tree algorithm selects the CIST Root Bridge and Port Roles, but
6 extended priority vector components are used within (13.9, 13.10) in each region. As a result each
7 region resembles a single bridge from the point of view of the CST as calculated by RSTP.
8 b) Each MSTI’s Regional Root Bridge and Port Roles are also computed using the same fundamental
9 spanning tree algorithm with modified priority vector components (13.11).
10 c) Different bridges may be selected as the Regional Root for different MSTIs by modifying the
11 manageable priority component of the Bridge Identifier differently for the MSTIs.
12
d) MST Configuration Identification is specific to MSTP.
13
e) The Port Roles used by the CIST (Root, Designated, Alternate, Backup or Disabled Port) are the
14
same as those of RSTP. The MSTIs use the additional port role Master Port. The Port States
15
associated with each spanning tree and bridge port are the same as those of RSTP.
16
17 f) The state variables for each Bridge Port for each tree and for the bridge itself are those specified for
18 RSTP as per bridge port and per bridge with a few exceptions, additions, and enhancements.
19 g) The performance parameters specified for RSTP apply to the CIST, with a few exceptions,
20 additions, and enhancements. A simplified set of performance parameters apply to the MSTIs.
21 h) This standard specifies RSTP state machines and procedures as a subset of MSTP.
22
23 13.5.3 Modeling an MST or SPT Region as a single bridge
24
25 The nominal replacement of an entire region by a single RSTP Bridge leads to little impact on the remainder
26 of the Bridged Local Area Network. This design is intended to assist those familiar with RSTP to
27 comprehend and verify MSTP, and to administer networks using MSTP. Treating the MST Regions as single
28 bridges provides the network administrator with a natural hierarchy. The internal management of MST
29 Regions can be largely separated from the management of the active topology of the network as a whole.
30
31 The portion of the active topology of the network that connects any two bridges in the same MST Region
32 traverses only MST Bridges and LANs in that region and never bridges of any kind outside the region; in
33 other words, connectivity within the region is independent of external connectivity. This is because the
34 protocol parameters that determine the active topology of the network as a whole, the Root Identifier and
35 Root Path Cost (known in the MSTP specification as the CIST Root Identifier and CIST External Root Path
36 Cost) are carried unchanged throughout and across the MST Region, so bridges within the region will
37 always prefer spanning tree information that has been propagated within the region to information that has
38 exited the region and is attempting to re-enter it.
39
40 NOTE 1—No LAN can be in more than one MST Region at a time, so two bridges (0.11 and 0.22 say) that would
41 otherwise be in the same region by virtue of having the same MST Configuration and of being directly connected by a
42 LAN, may be in distinct regions if that is a shared LAN with other bridges attached (having a different MST
Configuration) and no other connectivity between 0.11 and 0.22 and lying wholly within their region is available. The
43
region that the shared LAN belongs to may be dynamically determined. No such dynamic partitioning concerns arise
44 with single bridges. Obviously the sharing of LANs between administrative regions militates against the partitioning of
45 concerns and should only be done following careful analysis.
46
47 The Port Path Cost (MSTP’s External Port Path Cost) is added to the Root Path Cost just once at the Root
48 Port of the CIST Regional Root, the closest bridge in the region to the Root Bridge of the entire network.
49 The Message Age used by STP and RSTP is also only incremented at this port. If the CIST Root is within an
50 MST Region, it also acts as the Regional Root, and the Root Path Cost and Message Age advertised are zero,
51 just as for a single bridge.
52
53 Within an MST Region, each MSTI operates in much the same way as an independent instance of RSTP
54 with dedicated Regional Root Identifier, Internal Root Path Cost, and Internal Port Path Cost parameters.

Copyright © 2008 IEEE. All rights reserved. 15

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 Moreover, the overall spanning tree (the CIST) includes a fragment (the IST) within each MST Region that
2 can be viewed as operating in the same way as an MSTI with the Regional Root as its root.
3
4 NOTE 2—Since an MST Region behaves like a single bridge and does not partition (except in the unusual configuration
5 involving shared LANs noted above), it has a single Root Port in the CST active topology. Partitioning a network into
6 two or more regions can therefore force non-optimal blocking of Bridge Ports at the boundaries of those regions.
7
8
13.6 SPB overview
9
10
11 Clause 27 provides a comprehensive overview of SPB and SPBB operation. This clause (13.6) summarizes
12 aspects of SPB operation that relate to the transmission and reception of BPDUs, and their role in providing
13 interoperability with MSTP, RSTP, and MSTP and in carrying the Tree Agreement Protocol (TAP) messages
14 that ensure that each Shortest Path Tree (SPT) provides loop-free connectivity throughout an SPT Region.
15 The details of TAP are considered in 13.17, the assignment of frames to SPTs in 8.4 and Clause 27, and
16 protocols and procedures to allow plug-and-play generation of SPVIDs in Clause 27.
17
18 Considerations of backward and forward compatibility and interoperability figure largely in this clause
19 (Clause 13) and to some extent these consideration revolve around the notion of MST or SPT Region, with
20 each region capable of using different protocols or different configurations. These considerations should not
21 be allowed to obscure the fact that the ideal network configuration (from the point of view of connectivity
22 and bandwidth efficiency) comprises a single region, or possibly one core region with RSTP bridges
23 attached, and that separate regions are most likely to arise when continued connectivity is being provided by
24 the CST as configuration changes are made to bridges in the network. If an SPT Region is bounded by
25 Backbone Edge Bridges or LAN with no other bridges attached, B-VLANs can be supported by SPBB, with
26 frames assigned to SPTs using their source address, while other B-VLANs and S-VLANs can be supported
27 by SPB, with frames assigned to each SPT by SPVID. In both cases, however, SPTs are calculated in the
28 same way and the effects on this clause (Clause 13) are limited to allowing loop mitigation (6.5.4.2) for
29 unicast frames supported by SPBB as well as loop prevention (6.5.4.1). The need for unicast multicast
30 congruence (3.2), the simplification possible by not introducing differences between SPBB unicast
31 forwarding and the other uses of SPTs, and the need for source address lookup to support loop mitigation
32 means that all shortest path bridged frames are assigned to an SPT rooted at the source bridge and follow the
33 standard bridging paradigm of multicast distribution with filtering, even when the frame has a single
34 destination and the path to the destination is known through the use of routing protocol (ISIS-SPB).
35
36 SPT Bridges send and receive BPDUs in order to advertise their presence to, and recognize the presence of,
37 other bridges. The requirement for loop-free SPT connectivity also means that SPT Bridges have to
38 communicate with their nearest neighbors, when calculations that follow the reception of ISIS-SPB
39 messages have been completed rather than as a part of the ISIS protocol itself. The Tree Agreement Protocol
40 (TAP, 13.17) that satisfies this requirement can be separated conceptually from other uses of BPDUs, but the
41 opportunity to share common information elements, synchronization of neighbor state, and an overall
42 reduction in the number of protocol frames sent means that it is conveniently carried in BPDUs and its
43 specification in terms of protocol variables, procedures, and state machines is integrated with the other
44 provisions of this clause (13.24–13.40).
45
46 SPT Bridges use the configuration and active topology management parameters (Bridge Identifiers, Port
47 Path Costs) already required for the CIST. They also retain MSTP capabilities as a subset of their operation,
48 though it is always possible to configure zero MSTIs.
49
50
51 13.7 Compatibility and interoperability
52
53 RSTP, MSTP, and the SPB protocols are designed to interoperate with each other and with STP. This clause
54 (13.7) reviews aspects of their design that are important to meeting that requirement. The SPB protocols and

16 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 SPT BPDUs include the functionality provided by MSTP and MST BPDUs, so the compatibility with RSTP
2 and STP provided by the latter extends to SPB.
3
4 13.7.1 Designated Port selection
5
6
Correct operation of the spanning tree protocols requires that all Bridge Ports attached to any given LAN
7
agree on a single CIST Designated Port after a short interval sufficient for any Bridge Port to receive a
8
configuration message from that Designated Port.
9
10
11 A unique spanning tree priority (13.9) is required for each Bridge Port for STP, which has no other way of
12 communicating port roles. Since port numbers on different bridges are not guaranteed to be unique, this
13 necessitates the inclusion of the transmitting bridge’s Bridge Identifier in the STP BPDU. RSTP and
14 MSTP’s Port Protocol Migration state machines (13.32) ensure that all bridges attached to any LAN with an
15 attached STP bridge send and receive STP BPDUs exclusively.
16
17 NOTE 1—This behavior satisfies the requirement for unique, agreed Designated Port for LANs with attached STP
18 bridges, but means that an MST Region cannot completely emulate a single bridge since the transmitted Designated
Bridge Identifier can differ on Bridge Ports at the region’s boundary.
19
20
21 MSTP transmits and receives the Regional Root Identifier and not the Designated Bridge Identifier in the
22 BPDU fields recognized by RSTP (14.9) to allow both the MSTP and the RSTP Bridges potentially
23 connected to a single LAN to perform comparisons (13.9, 13.10) between all spanning tree priority vectors
24 transmitted that yield a single conclusion as to which RSTP Bridge or MST Region includes the Designated
25 Port. MST and RST BPDUs convey the transmitting port’s CIST Port Role. This is checked on receipt by
26 RSTP when receiving messages from a Designated Bridge (17.21.8 of IEEE Std 802.1D), thus ensuring that
27 an RSTP Bridge does not incorrectly identify one MST Bridge Port as being Designated rather than another,
28 even while omitting the competing Bridge Ports’ Designated Bridge Identifiers from comparisons.
29
30 NOTE 2—This ability of MSTP Bridges to communicate the full set of MSTP information on shared LANs to which
31 RSTP Bridges are attached avoids the need for the Port Protocol Migration machines to detect RSTP Bridges. Two or
more MSTP and one or more RSTP Bridges may be connected to a shared LAN, with full MSTP operation. This
32 includes the possibility of different MSTI Designated Ports (see 13.5.1).
33
34
13.7.2 Force Protocol Version
35
36
37 A Force Protocol Version parameter, controlled by management, permits emulation of aspects of the
38 behavior of earlier versions of spanning tree protocol that are not strictly required for interoperability. The
39 value of this parameter applies to all Bridge Ports.
40
41 a) STP BPDUs, rather than MST BPDUs, are transmitted if Force Protocol Version is 0. RST BPDUs
42 omit the MST Configuration Identifier and all MSTI Information.
43 b) RST BPDUs, rather than MST BPDUs, are transmitted if Force Protocol Version is 2. RST BPDUs
44 omit the MST Configuration Identifier and all MSTI Information.
45 c) All received BPDUs are treated as being from a different MST Region if Force Protocol Version is 0
46 or 2.
47
d) Rapid transitions are disabled if Force Protocol Version is 0. This allows MSTP Bridges to support
48
applications and protocols that can be sensitive to the increased rates of frame duplication and
49
misordering that can arise under some circumstances, as discussed in Annex K of IEEE Std 802.1D.
50
51 e) The MSTP state machines allow full MSTP behavior if Force Protocol Version is 3 or more.
52 f) SPT BPDUs are transmitted if Force Protocol Version is 4 or more.
53
54 NOTE— Force Protocol Version does not support multiple spanning trees with rapid transitions disabled.

Copyright © 2008 IEEE. All rights reserved. 17

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 13.8 MST Configuration Identifier

2
3 It is essential that all bridges within an MST or SPT Region agree on the allocation of VIDs to spanning
4 trees. If the allocation differs, frames for some VIDs may be duplicated or not delivered to some LANs at all.
5 MST and SPT Bridges check that they are allocating VIDs to the same spanning trees as their neighbors in
6 the same region by transmitting and receiving MST Configuration Identifiers in BPDUs. Each MST
7 Configuration Identifier includes a Configuration Digest that is compact but designed so that two matching
8 identifiers have a very high probability of denoting the same allocation of VIDs to MSTIDs (3.n, 8.4) even if
9 the identifiers are not explicitly managed. Suitable management practices for equipment deployment and for
10 choosing Configuration Names and Revision Levels (see below) can guarantee that the identifiers will differ
11 if the VID to tree allocation differs within a single administrative domain.
12
13
14 An MST or SPT Region comprises one or more MST or SPT Bridges with the same MST Configuration
15 Identifiers, interconnected by and including LANs for which one of those bridges is the Designated Bridge
16 for the CIST and which have no bridges attached that cannot receive and transmit RST BPDUs.
17
18 SPT BPDUs are a superset of MST BPDUs received and validated by MST Bridges as if they were MST
19 BPDUs, so MSTP operates within an SPT Region just as if it were an MST Region. However, each SPT Set
20 is represented by a reserved MSTID value that is included in the Configuration Digest, so when shortest path
21 bridging is used an SPT Region contains only SPT Bridges.
22
23 Each MST Configuration Identifier contains the following components:
24
25
1) A Configuration Identifier Format Selector, the value 0 encoded in a fixed field of one octet to
26
indicate the use of the following components as specified in this standard.
27
28 2) The Configuration Name, a variable length text string encoded within a fixed field of 32 octets,
29 conforming to RFC 2271’s definition of SnmpAdminString. If the Configuration Name is less
30 than 32 characters, the text string should be terminated by the NUL character, with the
31 remainder of the 32-octet field filled with NUL characters. Otherwise the text string is encoded
32 with no terminating NUL character.
33 3) The Revision Level, an unsigned integer encoded within a fixed field of 2 octets.
34 4) The Configuration Digest, a 16-octet signature of type HMAC-MD5 (see IETF RFC 2104)
35 created from the MST Configuration Table (3.86, 8.9). To calculate the digest, the table is
36 considered to contain 4096 consecutive two octet elements, where each element of the table
37 (with the exception of the first and last) contains an MSTID value encoded as a binary number,
38 with the first octet being most significant. The first element of the table contains the value 0,
39 the second element the MSTID value corresponding to VID 1, the third element the MSTID
40 value corresponding to VID 2, and so on, with the next to last element of the table containing
41 the MSTID value corresponding to VID 4094, and the last element containing the value 0. The
42 key used to generate the signature consists of the 16-octet string specified in Table 13-1.
43
44
45 Table 13-1—Configuration Digest Signature Key
46
47
Parameter Mandatory value
48
49 Configuration Digest Signature Key 0x13AC06A62E47FD51F95D2BA243CD0346
50
51
52 NOTE—The formulation of the signature as described above does not imply that a separate VID to MSTID translation
table has to be maintained by the implementation; rather that it should be possible for the implementation to derive the
53 logical contents of such a table, and the signature value as specified above, from the other configuration information
54 maintained by the implementation, as described in Clause 12.

18 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 The Configuration Digests of some VID to MSTID translations are shown in Table 13-2 to help verify
2 implementations of this specification.
3
4
5 Table 13-2—Sample Configuration Digest Signature Keys
6
7 VID to MSTID translation Configuration Digest
8
9 All VIDs map to the CIST, 0xAC36177F50283CD4B83821D8AB26DE62
10 no VID mapped to any MSTI
11 All VIDs map to MSTID 1 0xE13A80F11ED0856ACD4EE3476941C73B
12
13 Every VID maps to the MSTID 0x9D145C267DBE9FB5D893441BE3BA08CE
equal to (VID modulo 32) + 1
14
15
16 It is recommended that MST and SPT Bridge implementations provide an easily selectable or default
17 configuration comprising a Configuration Name of the Bridge Address as a text string using the
18 Hexadecimal Representation specified in IEEE Std 802, a Revision Level of 0, and a Configuration Digest
19 representing a VID to MSTID translation table containing the value 0 for every element. Such a table
20 represents the mapping of all VLANs to the CIST. Since the Bridge Address is unique to each bridge, no two
21 bridges using this default configuration will be identified as belonging to the same region.
22
23
13.9 Spanning Tree Priority Vectors
24
25
26 Priority vectors permit concise specification of each protocol’s computation of the active topology, both in
27 terms of the entire network and of the operation of individual bridges in support of the distributed algorithm.
28 MST, RST, and STP bridges use spanning tree priority vector information in Configuration Messages
29 (13.14), sent and received from neighbouring bridges, to assign Port Roles that determine each port’s
30 participation in a fully and simply connected active topology based on one or more spanning trees. SPT
31 Bridges use ISS-SPB to disseminate the information necessary to calculate Port Roles throughout SPT
32 Regions, and to perform those calculations, but also implement a Tree Agreement Protocol (TAP) that uses
33 this Configuration Message information for the CIST to ensure that neighbouring bridges agree on that
34 active topology, and to receive the information if the CIST Root lies outside their SPT Region.
35
36 CIST priority vectors comprise the following components:
37
38 a) CIST Root Identifier, the Bridge Identifier of the CIST Root;
39 b) CIST External Root Path Cost, the inter-regional cost from the transmitting bridge to the CIST Root;
40 c) CIST Regional Root Identifier, the Bridge Identifier of the single bridge in a region whose CIST
41 Root Port connects to a LAN in a different region, or of the CIST Root if that is within the region;
42 d) CIST Internal Root Path Cost, the cost to the CIST Regional Root;
43 e) CIST Designated Bridge Identifier, the Bridge Identifier for the transmitting bridge for the CIST;
44 f) CIST Designated Port Identifier, the Port Identifier for the transmitting port for the CIST;
45 g) CIST Receiving Port Identifier (not conveyed in Configuration Messages, used as tie-breaker
46 between otherwise equal priority vectors within a receiving bridge).
47
48 The first two components of the CIST priority vector are significant throughout the network. The CIST
49 External Root Path Cost transmitted by a bridge is propagated along each path from the CIST Root, is added
50 to at Bridge Ports that receive the priority vector from a bridge in a different region, and thus accumulates
51 costs at the Root Ports of bridges that are not MST or SPT Bridges or are CIST Regional Roots and is
52 constant within a region. The CIST Internal Root Path Cost is only significant and defined within a region.
53 The last three components are used as locally significant tie breakers, not propagated within or between
54 regions. The set of all CIST spanning tree priority vectors is thus totally ordered.

Copyright © 2008 IEEE. All rights reserved. 19

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 Since RSTP is not aware of regions, RSTP specifications also refer to the CIST Root Identifier and CIST
2 External Root Path Cost simply as the Root Bridge Identifier and Root Path Cost, respectively, and omit the
3 CIST Internal Root Path Cost (as does STP). MSTP encodes the CIST Regional Root Identifier in the BPDU
4 field used by RSTP to convey the Designated Bridge Identifier (14.5), so an entire region appears to an
5 RSTP capable bridge as a single bridge. RSTP’s CST use of CIST priority vectors can be conveniently
6 specified by the use of the zero for the Internal Root Path Cost and the same values for both the Regional
7 Root Identifier and Designated Bridge Identifier.
8
9 NOTE 1—The path to the CIST Root from a bridge with a CIST Root Port within a region always goes to or through the
10 CIST Regional Root.
11
12 NOTE 2—STP lacks the fields necessary for MST Bridges to communicate the Designated Bridge Identifier to resolve a
potential priority vector tie, and MSTP BPDUs are not sent on a LAN to which an STP bridge is attached.
13
14 Each MSTI priority vector comprises the following components for the particular MSTI in a given region:
15
16
h) MSTI Regional Root Identifier, the Bridge Identifier of the MSTI Regional Root;
17
i) MSTI Internal Root Path Cost, the path cost to the MSTI Regional Root;
18
j) MSTI Designated Bridge Identifier, the Bridge Identifier for the transmitting bridge for this MSTI;
19
k) MSTI Designated Port Identifier, the Port Identifier for the transmitting port for this MSTI;
20
l) MSTI Receiving Port Identifier (not conveyed in Configuration Messages).
21
22
The set of priority vectors for a given MSTI is only defined within a region. Within each region they are
23
totally and uniquely ordered. A CIST Root Identifier, CIST External Root Path Cost, and CIST Regional
24
Root Identifier tuple defines the connection of the region to the external CST and is required to be associated
25
with the source of the MSTI priority vector information when assessing the agreement of information for
26
rapid transitions to forwarding, but plays no part in priority vector calculations.
27
28
As each bridge and Bridge Port receives priority vector information from bridges and ports closer to the
29
Root, calculations and comparisons are made to decide which priority vectors to record, and what
30
information to pass on. Decisions about a given port’s role are made by comparing the priority vector
31
components that could be transmitted with that received by the port. For all components, a lesser numerical
32
value is better, and earlier components in the above lists are more significant. As each Bridge Port receives
33
information from ports closer to the Root, additions are made to one or more priority vector components to
34
yield a worse priority vector for potential transmission through other ports of the same bridge.
35
36
NOTE 3—The consistent use of lower numerical values to indicate better information is deliberate as the Designated
37 Port that is closest to the Root Bridge, i.e., has a numerically lowest path cost component, is selected from among
38 potential alternatives for any given LAN (13.9). Adopting the conventions that lower numerical values indicate better
39 information, that where possible more significant priority components are encoded earlier in the octet sequence of a
40 BPDU (14.3), and that earlier octets in the encoding of individual components are more significant (14.2) allow
41 concatenated octets that compose a priority vector to be compared as if they were a multiple octet encoding of a single
number, without regard to the boundaries between the encoded components. To reduce the confusion that naturally arises
42 from having the lesser of two numerical values represent the better of the two, i.e., that chosen all other factors being
43 equal, this clause uses the following consistent terminology. Relative numeric values are described as “least,” “lesser,”
44 “equal,” and “greater,” and their comparisons as “less than,” “equal to,” or “greater than,” while relative Spanning Tree
45 priorities are described as “best,” “better,” “the same,” “different,” and “worse” and their comparisons as “better than,”
46 “the same as,” “different from,” and “worse than.” The operators “<” and “=” represent less than and equal to,
respectively. The terms “superior” and “inferior” are used for comparisons that are not simply based on priority but
47 include the fact that a priority vector can replace an earlier vector transmitted by the same Bridge Port. All of these terms
48 are defined for priority vectors in terms of the numeric comparison of components below (13.10, 13.11).
49
50 NOTE 4—To ensure that the CIST and each MSTI’s view of the boundaries of each region remain in synchronization at
51 all times, each BPDU carries priority vector information for the CIST as well as for MSTIs. Associating the CIST Root
52 Identifier, External Path Cost, and Regional Root Identifier with the priority vector information for each MSTI does not
therefore raise a requirement to transmit these components separately. A single bit per MSTI vector, the Agreement flag,
53 satisfies the requirement to indicate that the vector beginning with the MSTI Regional Root Identifier for that specific
54 MSTI has always been associated with the single CIST Root Identifier, etc. transmitted in the BPDU.

20 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 To allow the active topology to be managed for each tree through adjusting the relative priority of different
2 bridges and Bridge Ports for selection as the CIST Root, a CIST or MSTI Regional Root, Designated
3 Bridge, or Designated Port, the priority component of the bridge’s Bridge Identifier can be independently
4 chosen for the CIST and for each MSTI. The priority component used by the CIST for its CIST Regional
5 Root Identifier can also be chosen independently of that used for the CIST Root Identifier. Independent
6 configuration of Port Path Cost and Port Priority values for the CIST and for each MSTI can also be used to
7 control selection of the various roles for the CIST and for each MSTI.
8
9 In principle an SPT priority vector could be defined within an SPT Region, comprising a Regional Root
10 Identifier and Internal Root Path Cost, and reflects the construction of each SPT (lowest Internal Root Path
11 Cost from each bridge and LAN to the Regional Root). However the set of such vectors cannot be totally
12 ordered by the addition of purely local tie-breaker components: as each SPT Set has to be symmetric. Clause
13 29 specifies ISIS-SPB’s calculation of SPTs.
14
15
16 13.10 CIST Priority Vector calculations
17
18 The port priority vector is the priority vector held for the port when the reception of BPDUs and any
19 pending update of information has been completed:
20
21 port priority vector = {RootID : ExtRootPathCost :
22 RRootID : IntRootPathCost :
23 DesignatedBridgeID : DesignatedPortID : RcvPortID}
24
25 The message priority vector is the priority vector conveyed in a received Configuration Message. For a
26 bridge with Bridge Identifier B receiving a Configuration Message on a port PB from a Designated Port PD
27 on bridge D claiming a CIST Root Identifier of RD, a CIST External Root Path Cost of ERCD, a CIST
28 Regional Root Identifier of RRD, and a CIST Internal Root Path Cost of IRCD:
29
30 message priority vector = {RD : ERCD : RRD : IRCD : D : PD : PB}
31
32 If B is not in the same region as D, the Internal Root Path Cost has no meaning to B and is set to 0.
33
34 NOTE—If a Configuration Message is received in an RST or STP BPDU, both the Regional Root Identifier and the
Designated Bridge Identifier are decoded from the single BPDU field used for the Designated Bridge Parameter (the
35 MST BPDU field in this position encodes the CIST Regional Root Identifier). An STP or RSTP bridge is always treated
36 by MSTP as being in an region of its own, so the Internal Root Path Cost is decoded as zero.
37
38 The received CIST message priority vector is the same as B’s port priority vector if:
39
40 (RD == RootID) && (ERCD == ExtRootPathCost) && (RRD == RRootID) &&
41 (IRCD == IntRootPathCost) && (D == DesignatedBridgeID) && (PD == DesignatedPortID)
42
43 and is better if:
44
45 ((RD < RootID)) ||
46 ((RD == RootID) && (ERCD < ExtRootPathCost)) ||
47 ((RD == RootID) && (ERCD == ExtRootPathCost) && (RRD < RRootID)) ||
48 ((RD == RootID) && (ERCD == ExtRootPathCost) && (RRD == RRootID)
49 && (IRCD < IntRootPathCost)) ||
50 ((RD == RootID) && (ERCD == ExtRootPathCost) && (RRD == RRootID)
51 && (IRCD == IntRootPathCost) && (D < DesignatedBridgeID)) ||
52 ((RD == RootID) && (ERCD == ExtRootPathCost) && (RRD == RRootID)
53 && (IRCD == IntRootPathCost) && (D == DesignatedBridgeID)
54 && (PD < DesignatedPortID))

Copyright © 2008 IEEE. All rights reserved. 21

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 A received CIST message priority vector is superior to the port priority vector if, and only if, the message
2 priority vector is better than the port priority vector, or the Designated Bridge Identifier Bridge Address and
3 Designated Port Identifier Port Number components are the same; in which case, the message has been
4 transmitted from the same Designated Port as a previously received superior message, i.e., if:
5
6 ({RD : ERCD : RRD : IRCD : D : PD : PB}
7 is better than
8 {RootID : ExtRootPathCost : RRootID : IntRootPathCost :
9 DesignatedBridgeID : DesignatedPortID : RcvPortID}
10 )|| ((D.BridgeAddress == DesignatedBridgeID.BridgeAddress) &&
11 (PD.PortNumber == DesignatedPortID.PortNumber))
12
13 If the message priority vector received in a Configuration Message from a Designated Port is superior, it will
14 replace the current port priority vector.
15
16 A root path priority vector for a port can be calculated from a port priority vector that contains information
17 from a message priority vector, as follows.
18
19 If the port priority vector was received from a bridge in a different region (13.26.4), the External Port Path
20 Cost EPCPB is added to the External Root Path Cost component, and the Regional Root Identifier is set to
21 the value of the Bridge Identifier for the receiving bridge. The Internal Root Path Cost component will have
22 been set to zero on reception.
23
24 root path priority vector = {RD : ERCD + EPCPB : B : 0 : D : PD : PB)
25
26 If the port priority vector was received from a bridge in the same region (13.26.4), the Internal Port Path
27 Cost IPCPB is added to the Internal Root Path Cost component.
28
29 root path priority vector = {RD : ERCD : RRD : IRCD + IPCPB : D : PD : PB)
30
31 The bridge priority vector for a bridge B is the priority vector that would, with the Designated Port Identifier
32 set equal to the transmitting Port Identifier, be used as the message priority vector in Configuration
33 Messages transmitted on bridge B's Designated Ports if B was selected as the Root Bridge of the CIST.
34
35
bridge priority vector = {B : 0 : B : 0 : B : 0 : 0}
36
37
The root priority vector for bridge B is the best priority vector of the set of priority vectors comprising:
38
39
a) the bridge priority vector; plus
40
b) all root path priority vectors that:
41
42 1) have a Designated Bridge Identifier D that is not equal to B, and
43 2) were received from a Bridge Port attached to a LAN that is not in the same SPT Region as B;
44 plus
45 c) the root path priority vector calculated by ISIS-SPB (if SPB is enabled, and the attached LAN is
46 within the bridge’s SPT Region).
47
48 NOTE—The BPDUs sent and received by all bridges attached to a LAN allow MST and SPT Bridges to determine
whether each attached LAN is within their region independently of priority vector values. SPT Bridges take advantage of
49 this fact by using ISIS-SPB to communicate the CST priority vector for each of SPT Region’s potential Master Ports
50 throughout the region, at the same time as ISIS-SPB calculates the Port Roles for each SPT (see Clause 29).
51
52 If the bridge priority vector is the best of this set of priority vectors, Bridge B has been selected as the CIST
53 Root. Otherwise the root priority vector will only be that calculated by ISIS-SPB if the Root Bridge or
54 Regional Root is within the bridge’s SPT Region.

22 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 The designated priority vector for a port Q on bridge B is the root priority vector with B’s Bridge Identifier B
2 substituted for the DesignatedBridgeID and Q’s Port Identifier QB substituted for the DesignatedPortID and
3 RcvPortID components. If Q is attached to a LAN that has one or more STP bridges attached (as determined
4 by the Port Protocol Migration state machine), B’s Bridge Identifier B is also substituted for the the RRootID
5 component.
6
7 If the designated priority vector is better than the port priority vector and the LAN attached to the port is not
8 within the bridge’s SPT Region (possibly because SPB is not enabled), the port will be the Designated Port
9 for that LAN and the current port priority vector will be updated. If the attached LAN is within the bridge’s
10 SPT Region, then the Port Role is as calculated by ISIS-SPB and the port priority vector will be updated
11 with the designated priority vector if and only if the port is a Designated Port. The message priority vector in
12 Configuration Messages transmitted by a port always comprises the components of the designated priority
13 vector for the port, even if the port is a Root Port.
14
15
16 13.11 MST Priority Vector calculations
17
18 The port priority vector is the priority vector held for the port when the reception of BPDUs and any
19 pending update of information has been completed:
20
21 port priority vector = {RRootID : IntRootPathCost :
22 DesignatedBridgeID : DesignatedPortID : RcvPortID}
23
24 The message priority vector is the priority vector conveyed in a received Configuration Message. For a
25 bridge with Bridge Identifier B receiving a Configuration Message on a Regional Port PB from a Designated
26 Port PD on bridge D belonging to the same MST Region and claiming an Internal Root Path Cost of IRCD:
27
28 message priority vector = {RRD : IRCD : D : PD : PB}
29
30
An MSTI message priority vector received from a bridge not in the same MST Region is discarded.
31
32
An MSTI message priority vector received from a Bridge Port internal to the region is the same as the port
33
priority vector if:
34
35
36 ((RRD == RRootID) && (IRCD == IntRootPathCost) && (D == DesignatedBridgeID)
37 && (PD == DesignatedPortID))
38
39 and is better if:
40
41 ((RRD < RRootID)) ||
42 ((RRD == RRootID) && (IRCD < IntRootPathCost)) ||
43 ((RRD == RRootID) && (IRCD == IntRootPathCost) && (D < DesignatedBridgeID)) ||
44 ((RRD == RRootID) && (IRCD == IntRootPathCost) && (D == DesignatedBridgeID)
45 && (PD < DesignatedPortID))
46
47 An MSTI message priority vector is superior to the port priority vector if, and only if, the message priority
48 vector is better than the port priority vector, or the Designated Bridge Identifier Bridge Address and
49 Designated Port Identifier Port Number components are the same; in which case, the message has been
50 transmitted from the same Designated Port as a previously received superior message, i.e., if:
51
52 ({RRD : IRCD : D : PD : PB}
53 is better than
54 {RRootID : IntRootPathCost : DesignatedBridgeID : DesignatedPortID : RcvPortID}

Copyright © 2008 IEEE. All rights reserved. 23

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 ) || ((D.BridgeAddress == DesignatedBridgeID.BridgeAddress) &&

2 (PD.PortNumber == DesignatedPortID.PortNumber))
3
4 If the message priority vector received in a Configuration Message from a Designated Port for the MSTI is
5 superior, it will replace the current port priority vector.
6
7 NOTE 1—The agree flag (13.27.4) for the port and this MSTI will be cleared if the CIST Root Identifier, CIST External
8 Root Path Cost, and CIST Regional Root Identifier in the received BPDU are not better than or the same as those for the
9 CIST designated priority vector for the port following processing of the received BPDU.
10
11 A root path priority vector for a given MSTI can be calculated for a port that has received a port priority
12 vector from a bridge in the same region by adding the Internal Port Path Cost IPCPB to the Internal Root
13 Path Cost component.
14
15 root path priority vector = {RRD : IRCD + IPCPB : D : PD : PB)
16
17 NOTE 2—Internal Port Path Costs are independently manageable for each MSTI, as are the priority components of the
Bridge and Port Identifiers. The ability to independently manage the topology of each MSTI without transmitting
18 individual Port Path Costs is a key reason for retaining the use of a Distance Vector protocol for constructing MSTIs. A
19 simple Link State Protocol requires transmission (or a priori sharing) of all Port Costs for all links.
20
21 The bridge priority vector for a bridge B is the priority vector that would, with the Designated Port Identifier
22 set equal to the transmitting Port Identifier, be used as the message priority vector in Configuration
23 Messages transmitted on bridge B’s Designated Ports if B was selected as the Root Bridge of a given tree.
24
25 bridge priority vector = {B : 0 : B : 0}
26
27 The root priority vector for bridge B is the best priority vector of the set of priority vectors comprising the
28 bridge priority vector plus all root path priority vectors whose Designated Bridge Identifier D is not equal to
29 B. If the bridge priority vector is the best of this set of priority vectors, Bridge B has been selected as the
30 Root of the tree.
31
32 The designated priority vector for a port Q on bridge B is the root priority vector with B’s Bridge Identifier B
33 substituted for the DesignatedBridgeID and Q’s Port Identifier QB substituted for the DesignatedPortID and
34 RcvPortID components.
35
36 If the designated priority vector is better than the port priority vector, the port will be the Designated Port for
37 the attached LAN and the current port priority vector will be updated. The message priority vector in MSTP
38 BPDUs transmitted by a port always comprises the components of the designated priority vector of the port,
39 even if the port is a Root Port.
40
41 Figure 13-8 shows the priority vectors and the active topology calculated for an MSTI in a region of the
42 example network of Figure 13-6.
43
44
45 13.12 Port Role assignments
46
47 Each bridge assigns CIST Port Roles (when new information becomes available as specified in this clause,
48 13.12) before assigning MSTI or SPT Port Roles. The calculations specified in 13.10 are used to assign a
49 role to each Bridge Port that is enabled as follows:
50
51 a) If the bridge is not the CIST Root, the source of the root priority vector is the Root Port.
52 b) Each port whose port priority vector is the designated priority vector is a Designated Port.
53 c) Each port, other than the Root Port, with a port priority vector received from another bridge is a
54 Alternate Port.

24 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 d) Each port with a port priority vector received from another port on this bridge is a Backup Port.
2
3 If the port is not enabled, i.e. its MAC_Operational status is FALSE or its Administrative Bridge Port state is
4 Disabled (8.4), it is assigned the Disabled Port role for the CIST, all MSTIs, and all SPTs, to identify it as
5 having no part in the operation of any of the spanning trees or the active topology of the network.
6
7 If the bridge is an MST or SPT Bridge, the calculations specified in 13.11 are used to assign a role to each
8 enabled Bridge Port for each MSTI as follows:
9
10 e) If the port is the CIST Root Port and the CIST port priority vector was received from a bridge in
11 another MST or SPT Region, the port is the Master Port.
12
f) If the bridge is not the MSTI Regional Root, the port that is the source of the MSTI root priority
13
vector is the Root Port.
14
15 g) Each port whose port priority vector is the designated priority vector derived from the root priority
16 vector is a Designated Port.
17 h) Each port, other than the Master Port or the Root Port, with a port priority vector received from
18 another bridge or a CIST port priority vector from a bridge in another region, is an Alternate Port.
19 i) Each port that has a port priority vector that has been received from another port on this bridge is a
20 Backup Port.
21
22 Independently of priority vector values and active topology calculations, each SPT Bridge Port determines
23 from received BPDUs whether all the bridges attached to its LAN are in the same SPT Region. If not, the
24 port is a Boundary Port, and its role for each SPT is determined by its CIST Port Role as follows:
25
26 j) If the port is the CIST Root Port, the port is the Master Port for all SPTs.
27 k) If the port is not the CIST Root Port, the port’s role is the same as that for the CIST.
28
29 By excluding Boundary Ports from the physical topology used to calculate SPTs, and adopting CIST
30 connectivity at those ports, ISIS-SPB ensures that the use of SPVIDs (rather than each VLAN’s Base VID)
31 is not required on shared media LANs attached to bridges in other regions.
32
33
SPT Bridges use ISIS-SPB to assign Port Roles for each SPT to non-Boundary Ports as follows:
34
35
36 l) If the bridge is not the SPT Root Bridge, the port that ISIS-SPB has calculated as providing the path
37 for frames assigned to the SPT and forwarded to the bridge from that SPT Root is the Root Port.
38 m) Each port, other than the Root Port, that ISIS-SPB has calculated as providing a path for frames
39 forwarded from the SPT Root to the attached LAN is a Designated Port.
40 n) Each port that is attached to the same LAN as a Designated Port for the SPT is a Backup Port.
41 o) Each port not assigned a Root, Designated, or Backup Port role is an Alternate Port.
42
43
44 13.13 Stable connectivity
45
46 This clause provides an analysis to show that RSTP, MSTP, and SPB protocols meets the goal of providing
47 full and simple connectivity for frames assigned to any given VLAN in a stable network, i.e., where the
48 physical topology has remained constant for long enough that the spanning tree information communicated
49 and processed by bridges is not changing.
50
51 NOTE 1—The FDB can be configured to prevent connectivity, in particular this analysis assumes that every Bridge Port
52 is a member of every VLAN’s Member Set (8.8.9). Spanning tree protocol controls can also be used to prevent new
connectivity (to allow for upgrades), or to disallow certain topologies (restricting the location of the CIST Root, for
53 example). This analysis assumes that those controls are not being used, that all the bridges are using conformant protocol
54 implementations and that the LANs are providing omnidirectional connectivity.

Copyright © 2008 IEEE. All rights reserved. 25

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 Every LAN provides connectivity for all frames between all attached Bridge Ports. Every bridge provides
2 connectivity between and only between its CIST Root and Designated Ports for frames assigned to the CIST,
3 between the Root, Designated, and Master Ports for a given MSTI for frames assigned to that MSTI, and
4 between Root and Designated Ports for a given SPT for frames assigned to that SPT. Any given bridge does
5 not assign frames to more than one tree and has one Root Port per tree, unless it is the Root of that tree.
6
7 Every LAN has one and only one CIST Designated Port, and every bridge apart from the CIST Root has one
8 and only one CIST Root Port. The CIST spanning tree priority vector of the Designated Port attached to the
9 LAN that is a bridge’s Root Port is better than of any Designated Port of that bridge. The CIST thus connects
10 all bridges and LANs (is “spanning”) and loop free (is a “tree”).
11
12 Each MST or SPT Region is bounded by CST Root and Alternate Ports. At the CST Root Ports connectivity
13 for frames assigned to MSTIs or SPTs within the connected regions is the same as that for the CIST. Every
14 region apart from that containing the CIST Root has a single CST Root Port, identified as the Master Port for
15 each MSTI. The CIST spanning tree priority vector of the LAN attached to the region’s CST Root Port is
16 better than that of any CST Designated Port of a bridge in the region attached to a LAN also attached to the
17 CST Root Port of another region. The CST thus provides loop free connectivity between all regions.
18
19 NOTE—The term “Common Spanning Tree (CST)” refers to the CIST connectivity between regions, and the term
20 “Internal Spanning Tree (IST)” to the CIST connectivity within each region. An RSTP bridge and the LANs for which it
21 is the Designated Bridge are conveniently considered as forming an MST region of limited extent.
22
23 Within each region each frame is consistently assigned to the CIST, an MSTI, or an SPT, and each of these
24 spanning trees provides full loop-free connectivity to each of the bridges within the region, just as the CIST
25 does for the network as a whole, including connectivity between the CST Root Port (Master Port) and the
26 CST Designated Ports. Since each bridge or LAN is in one and only one region, and it has already been
27 shown that loop free connectivity is provided between regions, loop free connectivity is thus provided
28 between all the bridges and LANs in the network.
29
30 Figure 13-9 illustrates the above connectivity with the simple example of Region 1 from the example
31 network of Figure 13-6 and Figure 13-8. Bridge 0.42 has been selected as the CIST Root and Regional Root,
32 bridge 0.57 as the Regional Root for MSTI 1, and bridge 2.83 for MSTI 2 by management of the per MSTI
33 Bridge Identifier priority component. The potential loop through the three bridges in the region is blocked at
34 different Bridge Ports for the CIST, and each MSTI, but the connectivity across the region and from each
35 LAN and bridge in the region through the boundaries of the region is the same in all cases.
36
37
38
13.14 Communicating Spanning Tree information
39
40 A Spanning Tree Protocol Entity transmit and receive group addressed BPDUs (Clause 14, 8.13.5) through
41 each of its Bridge Ports to communicate with the Spanning Tree Protocol Entities of the other bridges
42 attached to the same LAN. The group address used is one of a small number of addresses that identify
43 frames that are not directly forwarded by bridges (8.6.3), but the information contained in the BPDU can be
44 used by a bridge in calculating its own BPDUs to transmit and can stimulate that transmission.
45
46 BPDUs are used to convey the following types of messages:
47
48 a) Configuration Messages
49 b) Topology Change Notification (TCN) Messages
50 c) MST Configuration Identifiers
51 d) TAP Messages
52
53 Designated Ports also transmit BPDUs at intervals to guard against loss and to assist in the detection of
54 failed components (LANs, bridges, or Bridge Ports), so all messages are designed to be idem potent.

26 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1
2 REGION 1 : CIST
3 0.42
0.42, 0
4 RG1
5 0.57
0.1,10, 2
A 0.42, 0 B 0.1, 5, 1
2.83
6 0.42, 0 0.42, 0
D
RG1 RG1
7 0.42, 2 C 0.42, 1
8
9
10
11
12 REGION 1 : MSTI 1
13
1:1.42
14 0.42, 0
15 RG1
16 1:0.57
0.1,10, 2
A 1:0.57, 1 B 1:2.83
0.1, 5, 1

0.42, 0 0.42, 0
17 D
RG1 RG1
18 1:0.57, 0 C 1:0.57, 1

19
20
21
22
23 REGION 1 : MSTI 2
24 2:1.42
25 0.42, 0
RG1
26 2:1.57
0.1,10, 2
A 2:0.83, 1 B 2:0.83
0.1, 5, 1

27 0.42, 0 0.42, 0
D
28 RG1 RG1
2:0.83, 1 C 2:0.83, 0
29
30
31
32 Figure 13-9—CIST and MSTI active topologies in Region 1 of the example network
33
34 A Configuration Message for the CIST can be encoded in an STP Configuration BPDU (14.3.1), an RST
35 BPDU (14.3.2), an MST BPDU (14.3.3), or an SPT BPDU(<>). A TCN Message for the CIST can be
36 encoded in an STP Topology Change Notification BPDU (14.3.1), or an RST, MST, or SPT BPDU with the
37 TC flag set. Configuration and TCN Messages for the CIST and for all MSTIs in an MST Region are
38 encoded in a single MST or SPT BPDU, as is the MST Configuration Identifier. No more than 64 MSTI
39 Configuration Messages shall be encoded in an MST BPDU, and no more than 64 MSTIs shall be supported
40 by an MST Bridge.
41
42 When SPB is enabled, ISIS-SPB is used to communicate CST priority vectors, IST topology information,
43 and CST topology change information to and from the other bridges in the SPT Region and to calculate IST
44 and SPT Port Roles and designated priority vectors. However the full CIST priority information is still
45 conveyed in SPT BPDUs, partly to encode TAP message information for the IST, but principally to support
46 interoperability at the boundaries of each region without having to assess whether the transmitting port is at
47 a boundary before deciding what to encode in each BPDU. TAP messages are encoded in SPT BPDUs.
48
49 Configuration and Topology Change Notification BPDUs are distinguished from each other and from RST
50 and MST BPDUs by their BPDU Type (Clause 14). RST and MST BPDUs share the same BPDU Type and
51 are distinguished by their version identifiers.
52
53 Bridges implementing STP (Clause 8 of IEEE Std 802.1D, 1998 Edition) transmit and decode Configuration
54 and Topology Change Notification BPDUs, and ignore RST and MST BPDUs on receipt. This ensures that

Copyright © 2008 IEEE. All rights reserved. 27

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 connection of a Bridge Port of such a bridge to a LAN that is also attached to by a bridge implementing
2 RSTP or MSTP is detected, as transmission of RSTP or MSTP BPDUs does not suppress regular
3 transmissions by the STP bridge. This functionality is provided by the Port Protocol Migration state machine
4 for RSTP (13.32). The Port Protocol Migration state machines select the BPDU types used to encode
5 Spanning Tree messages so that all bridges attached to the same LAN participate in a spanning tree protocol,
6 while maximizing the available functionality. If one or more attached bridges only implement STP, only
7 Configuration and Topology Change Notification BPDUs will be used and the functionality provided by the
8 protocol will be constrained.
9
10
11 13.15 Changing Spanning Tree information
12
13 Addition, removal, failure, or management of the parameters of bridges and LAN connectivity can change
14 spanning tree information and require Port Role changes in all or part of the network (for the CIST) or all or
15 part of an MST or SPT Region (for an MSTI or SPT Set). A CIST or MSTI configuration message received
16 in a BPDU is considered superior to, and will replace, that recorded in the receiving port’s port priority
17 vector if its message priority vector is better, or if it was transmitted by the same Designated Bridge and
18 Designated Port and the message priority vector, timer, or hop count information differ from those recorded.
19
20
21 RSTP and MSTP propagate new information rapidly from bridge to bridge, superseding prior information
22 and stimulating further transmissions until it reaches either Designated Ports that have already received the
23 new information through redundant paths in the network or the leaves of the Spanning Tree, as defined by
24 the new configuration. Configuration Message transmissions will then once more occur at regular intervals
25 from ports selected as Designated Ports.
26
27 To ensure that old information does not endlessly circulate through redundant paths in the network,
28 preventing the effective propagation of the new information, MSTP associates a hop count with the
29 information for each spanning tree. The hop count is assigned by the CIST Regional Root or the MSTI
30 Regional Root and decremented by each receiving port. Received information is discarded and the port
31 made a Designated Port if the hop count reaches zero.
32
33
RSTP and MSTP’s CST processing, does not use an explicit hop count (for reasons of STP compatibility)
34
but detect circulating aged information by treating the BPDU Message Age parameter as an incrementing
35
hop count with Max Age as its maximum value. MSTP increments Message Age for information received at
36
the boundary of an MST Region, discarding the information if necessary.
37
38
39 If a Bridge Port’s MAC_Operational parameter becomes FALSE, the port becomes a Disabled Port and
40 received information is discarded. Spanning tree information for the tree can be recomputed, the bridge’s
41 Port Roles changed, and new spanning tree information transmitted if necessary. Not all component failure
42 conditions can be detected in this way, so each Designated Port transmits BPDUs at regular intervals and a
43 receiving port will discard information and become a Designated Port if two transmissions are missed.
44
45 NOTE—Use of a separate hop count and message loss detection timer provides superior reconfiguration performance
46 compared with the original use of Message Age and Max Age by STP. Connectivity loss detection is not compromised
47 by the need to allow for the overall diameter of the network, nor does the time allowed extend the number of hops
48 permitted to aged recirculating information. Management calculation of the necessary parameters for custom topologies
49 is also facilitated, as no allowance needs to be made for relative timer jitter and accuracy in different bridges.
50
51 ISIS-SPB communicates CST, IST, and SPT information throughout an SPT Region using link state
52 procedures specified in Clause 29. In addition to the normal hop-by-hop distribution of this information,
53 which is essential to guarantee its dissemination, each link state PDU is also distributed on the SPT rooted at
54 the originating bridge, so new information can reach bridges in the region with the same delay as data.

28 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 13.16 Changing Port States with RSTP or MSTP

2
3
4 The Port State for the CIST and each MSTI for each Bridge Port is controlled by state machines whose goal
5 is to maximize connectivity without introducing temporary loops in each of these active topologies. Root
6 Ports, Master Ports, and Designated Ports are transitioned to the Forwarding Port State, and Alternate Ports
7 and Backup Ports to the Discarding Port State, as rapidly as possible. Transitions to the Discarding Port State
8 can be simply effected without the risk of data loops. This clause (13.16) describes the conditions for RSTP
9 or MSTP to transition the Port State for a given spanning tree to Forwarding.
10
11 Starting with the assumption that any connected fragment of a network is composed of bridges, Bridge
12 Ports, and connected LANs that form a subtree of a spanning tree, conditions are derived for transitioning
13 ports with Root Port, Master Port, or Designated Port roles, such that the newly enlarged fragment continues
14 to form either a subtree or the whole of the spanning tree. Since these conditions are applied every time a
15 fragment is enlarged, it is possible to trace the growth of a fragment from a single bridge, which is clearly a
16 consistent, if small, subtree of a spanning tree, to any sized fragment—thus justifying the initial assumption.
17
18
19 Port States in two subtrees, each bounded by ports that are not forwarding or are attached to LANs not
20 attached to any other bridge, can be made consistent by waiting for any changes in the priority vector
21 information used to assign Port Roles to reach all bridges in the network, thus ensuring that the subtrees are
22 not, and are not about to be, joined by other Forwarding Ports. However, it can be shown that a newly
23 selected Root Port can forward frames as soon as prior recent root ports on the same bridge cease to do so,
24 without further communication from other bridges. Rapid transitions of Designated Ports and Master Ports
25 do require an explicit Agreement from the bridges in the subtrees to be connected. The Agreement
26 mechanism is described, together with a Proposal mechanism that forces satisfaction of the conditions if
27 they have not already been met by blocking Designated Ports connecting lower subtrees that are not yet in
28 agreement. The same Agreement mechanism is then used to transition the newly blocked ports back to
29 forwarding, advancing any temporary cut in the active topology toward the edge of the network.
30
31
13.16.1 Subtree connectivity and priority vectors
32
33
34 Any given bridge B, the LANs connected through its Forwarding Designated Ports, the further bridges
35 connected to those LANs through their Root Ports, the LANs connected to their Forwarding Designated
36 Ports, and so on, recursively, comprise a subtree SB. Any LAN L that is part of SB will be connected to B
37 through a Forwarding Designated Port PCL on a bridge C also in SB. L cannot be directly connected to any
38 port PB on bridge B unless B and C are one and the same, since the message priority vector for PB is better
39 than that of any port of any other bridge in SB, and prior to Forwarding PCL will have advertised its spanning
40 port priority vector for long enough for it to receive any better message priority vector (within the design
41 probabilities of protocol failure due to repeated BPDU loss) or will have engaged in an explicit confirmed
42 exchange (see below) with all other Bridge Ports attached to that LAN.
43
44
NOTE—The analysis for the distance vector based RSTP and MSTP differs from that for the link state based ISIS-SPB
45 (see 13.17). In the latter C’s priority vector can become better than B’s while C remains in SB, without B being aware of
46 the improvement first.
47
48
49 13.16.2 Root Port transition to Forwarding
50
51 It follows from the above that B’s Root Port can be transitioned to Forwarding immediately whether it is
52 attached to a LAN in SB or in the rest of the network, provided that all prior recent Root Ports on B (that
53 might be similarly arbitrarily attached) have been transitioned to Discarding and the Root Port was not a
54 Backup Port recently (B and C the same as above).

Copyright © 2008 IEEE. All rights reserved. 29

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1
2 agreed proposing
BRIDGE A
3
4
5
6
7 Agreement M Proposal
8
9
10
11
12 agree proposed BRIDGE B
13
14 allSynced
15 setSyncBridge()
16
17
18 synced sync synced sync synced sync
19
20 OR Discard OR Discard Discard
21
22 Discarding Discarding Discarding
23 agreed proposing agreed proposing
24 agree
25
26
27
28
Agreement O Proposal Agreement N Proposal
29
30
31
32
33 agree proposed agree proposed BRIDGE C
34
35
36 Figure 13-10—Agreements and Proposals
37
38 13.16.3 Designated Port transition to Forwarding
39
40 On any given bridge A, the Designated Port PAM connected to a LAN M can be transitioned to Forwarding
41 provided that the message priority advertised by the Designated Port PCL on any LAN L in any subtree SM1,
42 SM2, etc. connected to M is worse than that advertised by PAM; that any bridge D attached to L has agreed
43 that PCL is the Designated Port; and that only the Root Port and Designated Ports on D are Forwarding. A
44 sufficient condition for PAM to transition to Forwarding is that M is a point-to-point link attached to the Root
45 Port PBM of a bridge B, that the port priority of PBM is same as or worse than that of PAM, and any port PBN
46 on B is Discarding or similarly attached to a bridge C. PBM signals this condition to PAM by setting the
47 Agreement flag in a Configuration Message carrying PBM’s designated priority and Port Role.
48
49
NOTE 1—RSTP and MSTP use adminPointToPointMAC and operPointToPointMAC (6.6.3) to allow the point-to-point
50 status of LANs to be managed and used by the Port Role Transition state machines for Designated Ports. A newly
51 selected Root Port can be transitioned to Forwarding rapidly, even if attached to a shared media LAN.
52
53 Figure 13-10 illustrates the generation of an Agreement at a bridge’s Root Port from an Agreement received
54 or a Port State of Discarding at each of its Designated Ports, and a Port State of Discarding at each of its

30 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 Alternate and Backup Ports. A bridge receiving a Proposal transitions any Designated Port not already
2 synchronized to Discarding so it can send the Agreement, and that port solicits an Agreement by sending a
3 Proposal in its turn.
4
5 NOTE 2—Agreements can be generated without prior receipt of a Proposal as soon as the necessary conditions are met.
6 Subsequent receipt of a Proposal serves to elicit a further Agreement. If all other ports have already been synchronized
7 (allSynced in Figure 13-10) and the Proposal’s priority vector does not convey worse information, synchronization is
maintained and there is no need to transition Designated Ports to Discarding once more, or to transmit further Proposals.
8
9
10 13.16.4 Master Port transition to Forwarding
11
12 While the connectivity of the CIST from the CIST Regional Root through the MST Region to the rest of the
13 CIST comprises a subtree rooted in the CIST Regional Root, the connectivity of the MSTI from the Master
14 Port includes both a subtree below the CIST Regional Root and a subtree rooted in the MSTI Regional Root
15 and is connected to the CIST Regional Root by an MSTI Root Port. Figure 13-11 illustrates this connectivity
16 for both part of the CIST and an MSTI through a region in the example network of Figure 13-6. (In the
17 example, this latter subtree provides connectivity from the Master Port through LAN N to the subtree of the
18 CIST outside the region). Prior to the Master Port’s transition to Forwarding, it is possible that either MSTI
19 subtree is providing connectivity to a prior Master Port. Before the Master Port can transition, the
20 connectivity of both subtrees has to agree with the new CIST Regional Root.
21
22 NOTE 1—The physical layout shown in the two halves of Figure 13-11 differs in order to reflect the different priorities
23 and logical topologies for the two spanning tree instances. The layout convention is that Designated Ports are shown as
horizontal lines, Root Ports as vertical lines, and Alternate Ports as diagonal lines.
24
25
26 Figure 13-12 illustrates the extension of the Agreement mechanism to signal from Designated Ports to Root
27 Ports as well as vice versa. To ensure that an MSTI does not connect alternate Master Ports, an Agreement is
28 only recognized at an MSTI Port when the associated CIST Regional Root information matches that selected
29 by the receiving port. Proposals, eliciting Agreements, necessarily flow from Designated Ports to Root Ports
30 with the propagation of spanning tree information, so a new CIST Regional Root cannot transmit a Proposal
31 directly on its MSTI Root Ports. However, updating a CIST Designated Port’s port priority vector with a
32 new Regional Root Identifier forces the port to discard frames for all MSTIs, thus initiating the Proposal
33 from the first bridge nearer the MSTI Regional Root that learns of the new Regional Root.
34
35 When an Agreement AMR is sent by a Root Port PMR on a Regional Root M, it attests that the CIST Root
36 Identifier and External Root Path Cost components of the message priority advertised on all LANs
37 connected to the CIST by PMR through M are the same as or worse than those accompanying AMR. The
38 connectivity provided by each MSTI can be independent of that provided by the CIST within the MST
39 Region and can therefore connect PMR and one or more CIST Root Ports external to but attached at the
40 boundary of the region even as CIST connectivity within the region is interrupted in order to satisfy the
41 conditions for generating AMR. The Agreement cannot therefore be generated unless all MSTI subtrees as
42 well as the CIST subtree internal to the region are in Agreement. To ensure that an MSTI does not connect to
43 a CIST subtree external to the region that does not meet the constraints on the CST priority vector
44 components, an Agreement received at an MSTI Designated Port from a Bridge Port not internal to the
45 region is only recognized if the CIST Root Identifier and External Root Path Cost of the CIST root priority
46 vector selected by the transmitting Bridge Port are equal to or worse than those selected by the receiver.
47 Updating of a CIST Designated Port’s port priority vector with a worse CIST Root Identifier and External
48 Root Path Cost forces the port to discard frames for all MSTIs, thus initiating a Proposal that will elicit
49 agreement.
50
51 NOTE 2—MSTI Designated Ports are prompted to discard frames, as required above, as follows. The CIST Port
52 Information state machine sets sync for all MSTIs on a transition into the UPDATE state if updating the port priority
with the designated priority changes the Regional Root Identifier or replaces the CIST Root Identifier or External Path
53 Cost with a worse tuple. The MSTI’s Port Role Transition machine acts on the sync, instructing the port to discard
54 frames, and setting synced and cancelling sync when the port is discarding or an agreement is received.

Copyright © 2008 IEEE. All rights reserved. 31

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1
2 H
3 86
I
4
5
6 J 97
K
7
84
8 L
9
10 M
11 N 65
12 72
13
14
77 P
15 CIST
16
17
18 MSTI
19 K
65 M
20
21 N
22
H
23 97
24 J
25
26
27 86 77 P
I
28
29
30
31 84 L
32
33 72
34
35 Figure 13-11—CIST and MSTI Active Topologies in Region 2 of Figure 13-6—
36
37
38 NOTE 3—A “cut” in an MSTI can be transferred to the CST, either at a Designated Port attached to the same LAN as an
39 STP bridge or at the Root Port of a bridge in an adjacent region. If the CST priority components have already been
synced, as is likely if the original cut was caused by changes in physical topology within the region, the cut will
40 terminate there. Otherwise the transferred cut precedes a cut in the CIST, and the synced port may terminate the latter.
41 In that way, cuts in the CST will proceed through an MST Region by the quickest tree that will carry them.
42
43 NOTE 4—In the important topology where the CIST Root Bridge is within an MST Region, cuts are not transferred
44 from the region’s IST to any MSTI. CIST cuts propagating in the region will not disrupt MSTI connectivity.
45
46
47
48
49
50
51
52
53
54

32 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1
2
agreed proposing
3
agree
4
5
6
7
8 Agreement L Proposal
9
10
11
12
agree proposed
13
agreed
14 reRooted
15
16 AND
17
18 synced
19
20 allSynced
21 setSyncBridge()
22
23
24 synced sync synced sync synced sync
25
26 OR Discard OR Discard OR Discard
27
28 Discarding Discarding Discarding
29 agreed proposing agreed proposing agreed proposing
30 agree agree agree
31
32
33
34
Agreement L Proposal Agreement L Proposal
35
36
37
38
39 agree proposed agree proposed
40 agreed agreed
41
42
43 Figure 13-12—Enhanced Agreements
44
45
46
47
48
49
50
51
52
53
54

Copyright © 2008 IEEE. All rights reserved. 33

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 13.17 Changing Port States with SPB

2
3 While the link state routing protocols are less likely to create temporary loops than distance vector based
4 protocols, loops are still possible if, for example, two links fail about the same time. Any potential loop is a
5 serious problem for bridged networks, as a frame that is multicast or whose destination has not been learned
6 and is travelling around a loop is copied to each of the connected subtrees on every circuit, consuming
7 bandwidth throughout the network. Each SPT Bridge Port participates in Tree Agreement Protocol (TAP)
8 that ensures that additions to each active topology do not occur unless there is sufficient agreement between
9 neighbouring bridges (with some ports temporarily transitioned to Discarding if necessary) to ensure that a
10 temporary loop will not be created.
11
12
Like RSTP and MSTP, TAP uses Agreements (see 13.16, Figure 13-12) to ensure that ports that transition to
13
forwarding do not create loops. However, ISIS distributes information in parallel with computation, rather
14
than computing a new active topology hop-by-hop as priority vector information is passed from the Root
15
Bridge to members of a potential subtree. Moreover the distribution path is not restricted to the potential
16
subtree. Arbitrary distribution and parallel computation means that different bridges can complete topology
17
calculations at quite different times, with two major consequences as follows.
18
19
20 First, each bridge is not necessarily aware of priority vector improvements passed to any subtree connected
21 through one of its Designated Ports before any other bridge in that subtree. TAP cannot rely (like RSTP)
22 only on Agreements that propagate towards the Root of a tree, but needs (like MSTP) to use Agreements
23 that propagate both up and down the tree. TAP ensures that new connectivity only occurs between a
24 Designated Port (PA, say) and a Root Port (PB, say), when all Root Ports that are forwarding parents of PA,
25 i.e. connected through bridges from forwarding Designated Port to forwarding Root Port and through LANs
26 from Root Port to Designated Port, are each associated with a better priority vector than any of the Root
27 Ports that are forwarding children of PB, i.e. that are connected through bridges from forwarding Root Port
28 to forwarding Designated Port and through LANs from Designated Port to Root Port. Since a bridge has at
29 most one forwarding Root Port these constraints are sufficient to ensure loop-free connectivity.
30
31 The second major consequence of arbitrary distribution and parallel computation, is that received
32 Agreements that can appear to contradict the results of the last local link state computation still need to be
33 held by the receiving port in case they become applicable after a future computation completes. This in turn
34 means that a port PA needs to know that any outdated Agreement sent to a neighbor PB has been discarded
35 by PB, before PA can take any action on an Agreement from PB that would be inconsistent with the outdated
36 Agreement. The explicit discard prevents two Designated Ports attached to the same LAN (for example)
37 from both transitioning to forwarding, each using an old Agreement with a Root Port role from the other. To
38 minimize the number of message exchanges necessary to create new connectivity, unsatisfactory received
39 Agreements are voluntarily discarded when a link state topology calculation completes. TAP supports the
40 necessary communication, allowing for the possibility of TAP message loss and buffering prior to
41 transmission and before processing on receipt.
42
43 TAP supports the IST using CIST information present in both MST and SPT BPDUs, minimizing active
44 topology disruption while allowing parallel adoption of a new topology by allowing neighbouring bridges to
45 communicate IST priority vectors, propagate agreements, and signal the need for temporary cuts to speed
46 transitions to forwarding, even while those neighbors’ views of the entire active topology differ with
47 differences in their knowledge of the latest physical topology changes. A single BPDU cannot convey the
48 same per tree state for all possible SPTs, so the input to their link state calculation is summarized in a TAP
49 Digest (13.17.1). If a received digest matches the bridge’s own digest, the bridge can compute the implied
50 received Agreements. Using the TAP Digest means neighbouring bridges cannot synchronize their local
51 views of any SPT’s active topology until they have synchronized their views of the physical topology of the
52 entire SPT Region, and increases per tree computation, but reducing the number of messages is worthwhile.
53
54 NOTE—Management VLANs with modest bandwidth needs should be allocated to the IST in SPT Regions.

34 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 TAP messages contain a two-bit Agreement Number and a Discarded Agreement Number, that apply to IST
2 Agreements (indicated by the CIST Agreement flag). Once an Agreement has been sent it is considered
3 outstanding until a matching or more recent Discarded Agreement Number is received. SPT Agreements,
4 implied by the transmission of a TAP Digest, are outstanding until the transmitting Bridge Port has received
5 digests, from all the other bridges attached to the LAN, that match a subsequently calculated digest.
6
7 NOTE—TAP assumes that any two digests representing the same physical topology will differ with high probability,
8 through inclusion of ISIS sequence number is the digest calculation, if the physical topology changed in the period
9 between their generation, unless that period significantly exceeds any communication delays due to loss and buffering of
TAP messages between nearest neighbors. Since a bridge only acts on received digests that match its own latest
10 calculated digest, all digests can be treated as ordered in time.
11
12 The per-port per-tree state machine variable agreed is recomputed whenever ISIS-SPB’s link state
13 calculation provides a new root priority vector, designated priority vectors (13.10), and Port Roles (13.12)
14 for the relevant tree (IST or SPT). If there are no outstanding Agreements for a different role (as recorded by
15 a chgdRole parameter), then agreed is set for each Root and Alternate Port that holds a received Agreement
16 (from a Designated Port) that is better than the bridge’s root priority vector, and set for each Designated Port
17 that holds a received Agreement (from a Root, Alternate, or Backup Port on every other bridge attached to
18 the LAN) that is worse than any Agreement outstanding for that port and the root priority vector. Otherwise
19 agreed is cleared. Received IST Agreements that would not result in setting agreed (if the receiving port had
20 no outstanding agreements) are discarded, and a TAP message sent with the Discarded Agreement Number.
21
22 The agreed variables for each port are used, in conjunction with Discarding Port States and reRooted, to set
23 synced for each port and hence to set allSynced, allowing the conditions for Port Role and Port State
24 transitions and the transmission of Agreements to be the same as for MSTP (see Figure 13-12, 13-23, 13-24,
25 and 13-24) with the additional requirement that allSynced be set for any port to transition to Learning or
26 Forwarding, just as required by MSTP for Master Port state transitions. If agreed is set for an IST Root Port,
27 but allSynced is not, and the Agreement for that Root Port was accompanied by a Proposal, then sync is set
28 for the Designated Ports to force those without applicable Agreements to Discard, so that the Root Port can
29 be allSynced and send an Agreement up the tree. The TAP Digest cannot signal per-SPT Agreements, so the
30 Designated Ports that are not agreed are always made Discarding so that the digest (with its implied
31 Agreements) can be sent.
32
33 13.17.1 TAP Digest
34
35 <<t.b.s. Should have format selector, like MST Configuration Digest.>>
36
37
38
39
40
41
42 13.18 Managing spanning tree topologies
43
44 The active topology of the CIST, and the topologies that can result after the failure or addition of network
45 components, may be managed by assigning values to some or all of the following:
46
47 — The Bridge Priority component of the CIST Bridge Identifier for one or more bridges.
48 — The External Port Path Cost (also referred to as the Port Path Cost for RSTP) for some Bridge Ports.
49 — Components of the MST Configuration Identifier for bridges with the same Configuration Digest.
50 — The CIST Internal Port Path Cost Port (for MSTP and SPB protocols) for some Bridge Ports.
51 — The Port Priority component of the Port Identifier for some Bridge Ports.
52
53 Within an MST Region, the active topology of each MSTI may be managed by assigning values to some or
54 all of the following:

Copyright © 2008 IEEE. All rights reserved. 35

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 — The Bridge Priority component of the MSTI Regional Root Identifier.

2 — The Internal Port Path Cost for the MSTI for some Bridge Ports,
3 — The Port Priority component of the MSTI’s Port Identifier for some Bridge Ports.
4
5 In general topology management objectives can be met by modifying only a few parameter values in a few
6 bridges in the network. Table 13-3 specifies default values and ranges for Bridge Priorities and Port
7 Priorities. If these parameters can be updated by management, the bridge shall have the capability to use the
8 full range of values with the granularity specified.
9
10 Table 13-3—Bridge and Port Priority values
11
Recommended or
12 Parameter Range
default value
13
14 Bridge Priority 32 768 0–61 440 in steps of 4096
15 Port Priority 128 0–240 in steps of 16
16
17 NOTE 1—The stated ranges and granularities for Bridge Priority and Port Priority differ from those in IEEE Std 802.1D,
18 1998 Edition and earlier revisions of that standard. Expressing these values in steps of 4096 and 16 allows consistent
19 management of old and new implementations of this standard; the steps chosen ensure that bits that have been re-
20 assigned are not modified, but priority values can be directly compared.
21
22 Table 13-4 recommends defaults and ranges for Port Path Cost and Internal Port Path Cost values, chosen
23 according to the speed of the attached LAN, to minimize the administrative effort required to provide
24 reasonable active topologies. If these values can be set by management, the bridge shall be able to use the
25 full range of values in the parameter ranges specified, with a granularity of 1.
26
Table 13-4—Port Path Cost values
27
28 Recommended Recommended
Link Speed Range
29 value range
30 <=100 Kb/s 200 000 000 20 000 000–200 000 000 1–200 000 000
31
1 Mb/s 20 000 000 2 000 000–200 000 000 1–200 000 000
32
33 10 Mb/s 2 000 000 200 000–20 000 000 1–200 000 000
34 100 Mb/s 200 000 20 000–2 000 000 1–200 000 000
35 1 Gb/s 20 000 2 000–200 000 1–200 000 000
36
10 Gb/s 2 000 200–20 000 1–200 000 000
37
38 100 Gb/s 200 20–2 000 1–200 000 000
39 1 Tb/s 20 2–200 1–200 000 000
40 10 Tb/s 2 1–20 1–200 000 000
41
42
43 When two or more links are aggregated (see IEEE 802.1AX), Port Path Cost and Internal Port Path Cost
44 values can be modified to reflect the actual throughput. However, as the primary purpose of Path Cost is to
45 select active topologies, it can be inappropriate to track throughput too closely, as the resultant active
46 topology could fluctuate or differ from that intended by the network administrator. For example, if the
47 network administrator had chosen aggregated links for resilience (rather than for increased data rate), it
48 would be inappropriate to change topology as a result of one of the links in an aggregation failing. Similarly,
49 with links that can autonegotiate their data rate, reflecting such changes of data rate in changes to Path Cost
50 is not necessarily appropriate. As a default behavior, dynamic changes of data rate should not automatically
51 cause changes in Port Path Cost.
52
NOTE 2—BPDUs are capable of carrying 32 bits of Root Path Cost information, though IEEE Std 802.1D-1998 and its
53 earlier revisions limited the range of the Port Path Cost parameter to a 16-bit unsigned integer value. Table 13-4 uses the
54 full 32-bit range to extend the range of supported link speeds. Additional recommended values can be calculated as 20

36 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 000 000 000/(Link Speed in Kb/s). Limiting the range of the Path Cost parameter to 1–200 000 000 ensures that the
2 accumulated Path Cost cannot exceed 32 bits over a concatenation of 20 hops. Where bridges using the IEEE Std
802.1D-1998 recommendations and others using Table 13-4 are mixed in the same Bridged Local Area Network,
3
explicit configuration is likely to be necessary to obtain reasonable CST topologies.
4
5
6 13.19 Updating learned station location information
7
8 In normal stable operation, learned station location information held in the Filtering Database need only
9 change as a consequence of the physical relocation of stations. It is therefore desirable to employ a long
10 aging time for Dynamic Filtering Entries (8.8.3), especially as many end stations transmit frames following
11 power-up causing the information to be relearned.
12
13 However, when the active topology reconfigures, stations can appear to move from the point of view of any
14 given bridge even if that bridge’s Port States have not changed. If a Bridge Port is no longer part of an active
15 topology, stations are no longer reachable through that port, and its Dynamic Filtering Entries are removed
16 from that bridge’s Filtering Database. Conversely, stations formerly reachable through other ports might be
17 reachable through a newly active port. Dynamic Filtering Entries for the other ports are removed, and RSTP
18 and MSTP transmit Topology Change Notification Messages both through the newly active Port and
19 through the other active Ports on that Bridge. TCNs signal additional connectivity, not just changes in
20 connectivity as relearning a station’s location is only possible if it can be reached, and if that is possible
21 when a port is removed from the active topology another port will be added. A TCN is sent when a Bridge
22 Port joins the active topology, and not before, so that bridges that can relearn removed station location
23 information and minimize unnecessary flooding of frames. A bridge that receives a TCN on an active port
24 removes Dynamic Filtering Entries for their other active Ports and propagates the TCN through those ports.
25
26 NOTE 1—STP allowed for the presence of LAN repeaters that could partition a shared media LAN, thus causing
27 stations to appear to move when the partition was repaired later—with the only Bridge Port changing Port Role or Port
28 State transitioning to Discarding at that time. This scenario does not occur with current technology, and its future
29 likelihood does not justify the use of TCNs to signal connectivity loss. Bridge Ports that participate in the MAC status
propagation protocol should be capable of originating TCNs when that protocol signals additional connectivity.
30
31
The Topology Change state machine (13.39) avoids removing learned information when ports temporarily
32
revert to Discarding to suppress loops. It treats a port as joining the active topology when it becomes
33
forwarding, and no longer active when it becomes an Alternate, Backup, or Disabled Port and stops
34
forwarding and learning. The Topology Change state machine does not generate TCNs following Edge Port
35
(operEdge,<>) Port State changes, as these do not affect connectivity or station location information in the
36
rest of the network, nor does it remove Dynamic Filtering Entries for Edge Ports when TCNs are received.
37
38
39 Dynamic Filtering Entries for MAC addresses previously learned on a Root Port may be modified to move
40 those addresses to an Alternate Port that becomes the new Root Port and a TCN sent only through the new
41 Root Port (and not through other active ports), reducing the need to flood frames. This optimization is
42 possible because a retiring Root Port that becomes Discarding temporarily partitions the active topology into
43 two subtrees, one including all bridges and LANs hitherto reachable through the retiring Root Port, and the
44 other including all the others. If the new Root Port simply provides a new path to the first of these subtrees,
45 its stations will not appear to move from the point of view of bridges in the other subtree. Alternatively if a
46 the tree reconfiguration is more complex one or more newly Designated Port will become active and will
47 transmit the necessary TCNs.
48
49 NOTE 2—The rules described require removal of potentially invalid learned information for a minimum set of ports on
each bridge. A bridge implementation can flush information from more ports than strictly necessary, removing (for
50 example) all Dynamic Filtering Entries rather than just those for the specified ports. This does not result in incorrect
51 operation, but will result in more flooding of frames with unknown destination addresses.
52
53 Changes in the active topology of any given MSTI or SPT do not change Dynamic Filtering Entries for the
54 CIST or any other MSTI or SPT, unless the underlying changes in the physical topology that gave rise to the

Copyright © 2008 IEEE. All rights reserved. 37

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 reconfiguration also cause those trees to reconfigure. Changes to the CST, i.e., the connectivity provided
2 between regions, can cause end station location changes for all trees. Changes to an IST can cause CST end
3 station location changes but do not affect MSTIs in that region unless those trees also reconfigure.
4
5 On receipt of a CIST TCN Message from a Bridge Port not internal to the region, or on a change in Port Role
6 for a Bridge Port at the region boundary:
7
8 — TCN Messages are transmitted through each of the other ports of the receiving bridge for each MSTI
9 and the Dynamic Filtering Entries for those ports are removed.
10 — ISIS-SPB communicates the change to each bridge within the SPT Region, and Dynamic Filtering
11 Entries learned for all SPTs for each port that is a Designated Port for the SPT rooted at the bridge
12 receiving the CIST TCN are removed.
13
14 NOTE 3—TCN Messages for the CIST are always encoded in the same way, irrespective of whether they are perceived
15 to have originated from topology changes internal to the region or outside it. This allows RSTP Bridges whose Root
16 Ports attach to a LAN within an MST Region to receive these TCN Messages correctly.
17
NOTE 4—The port receiving a CIST TCN Message from another Bridge Port external to the region can be a Master
18 Port, a Designated Port attached to the same LAN as an STP bridge, or a Designated Port attached to a LAN that is
19 within the region but is attached to by the Root Ports of bridges in other regions.
20
21 NOTE 5—Dynamic Filtering Entries created by ISIS-SPB as a result of that protocols direct knowledge of the location
22 of some stations are not removed when a TCN is received, but can be changed by ISIS-SPB as result of its calculations.
23
24 NOTE 6—Topology changes for the IST are always propagated by TCNs received and transmitted in BPDUs, and are
not injected as a result of ISIS-SPB calculations as the latter complete prior to new connectivity being established.
25
26
27 13.20 Managing reconfiguration
28
29
30
31
13.21 One-way connectivity
32
33
34
35
36 13.22 Fragile bridges
37
38
39
40
41 13.23 Hot upgrades
42
43
44
45 13.24 Spanning tree protocol state machines
46
47 Each Spanning Tree Protocol Entity’s operation of the protocols specified in this clause (Clause 13) is
48 specified by the following state machines:
49
50 a) Port Role Selection (PRS, 13.36)
51
52 with the following state machines for each Bridge Port:
53
54 b) Port Timers (PTI, 13.30)

38 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 c) Port Protocol Migration (PPM, 13.32)

2 d) Port Receive (PRX, 13.31)
3 e) Port Transmit (PRT, 13.34)
4 f) Bridge Detection (BDM, 13.33)
5
6 and the following optional state machine for each Bridge Port:
7
8 g) Layer 2 Gateway Port Receive (L2GPRX, 13.40)
9
10 and the following state machines for each Bridge Port for the CIST and for each MSTI:
11
12 h) Port Information (PIM, 13.35)
13 i) A Topology Change (TCM, 13.39)
14
15 and the following state machines for each Bridge Port for the CIST, for each MSTI, and for each SPT:
16
17 j) Port Role Transitions (PRT, 13.37)
18 k) Port State Transition (PST, 13.38)
19
20 Each state machine and its associated variable and procedural definitions is specified in detail in 13.25
21 through 13.40. The state machine notation is specified in Annex P. Figure 13-13 is not itself a state machine
22 but provides an overview of the state machines, their state variables, and communication between machines.
23 Figure 13-14 describes its notation.
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

Copyright © 2008 IEEE. All rights reserved. 39

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1
2 BEGIN tick
portEnabled, MigrateTime
MigrateTime
3 ForceVersion, mcheck

4 rcvdRSTP
PORT RECEIVE (PER PORT) PORT PROTOCOL
5 operEdge rcvdBpdu, rcvdSTP, rcvdRSTP, rcvdSTP MIGRATION
edgeDelayWhile rcvdInternal (PER PORT)
6 per tree: rcvdMsg mcheck, sendRSTP
7 MIGRATION TIMER
8 rcvdMsg rcvdInternal
(PER PORT)
portEnabled, isL2gp rcvdBpdu MstConfigId mdelayWhile
9
10
L2 GATEWAY PORT RECEIVE (PER PORT)
11
12 PSEUDO RECEIVE TIMER
13 pseudoInfoHelloWhen
14
15 portEnabled PORT INFORMATION (PER TREE PER PORT)
infoIs, portId, portPriority, portTimes, designatedPriority,
16 rcvdTc, rcvdTcn, rcvdTcAck designatedTimes, msgPriority, msgTimes, rcvdInfo, reselect, selected,
17 proposed, agreed, agree, updtInfo, changedMaster
MaxHops per port: infoInternal, rcvdTc, rcvdTcn, rcvdTcAck
18 AGEING TIMER
19 rcvdInfoWhile

20 portPriority, portTimes
infoIs, infoInternal designatedPriority,
reselect
21 MigrateTime selected
designatedTimes
updtInfo
AutoEdge selected
22 AdminEdge
23 sendRSTP PORT ROLE SELECTION
(PER TREE)
24 BRIDGE DETECTION
rootPortId, rootPriority, rootTimes,
BridgeIdentifier, bridgePriority, bridgeTimes, proposed
25 (PER PORT)
selectedRole proposing
operEdge, synced
26 selectedRole agreed
EDGE TIMER
27 proposing selected reRoot sync agree
(PER PORT) forwardDelay
edgeDelayWhile updtInfo disputed
28
operEdge
29 PORT ROLE TRANSITIONS
learn (PER TREE PER PORT)
30 PORT STATE
TRANSITION forward role, sync, synced, reRoot, proposing, learn, forward
31 (PER TREE PER PORT) learning
32 learning, forwarding forwarding

33 learn, learning, forward

ROLE TIMERS
34 TOPOLOGY CHANGE role fdWhile, rrWhile, rbWhile
(PER TREE PER PORT)
35 fdbFlush
role newInfo
per port: tcAck
36 tcProp synced
TxHoldCount proposing
37 TC TIMER
HelloTime agree
tcWhile
38
39 PORT TRANSMIT (PER PORT) newInfoXst
tcWhile txCount, newInfoCist, newInfoMsti
40 designatedPriority,
newInfoXst, tcAck designatedTimes
41 sendRSTP
TRANSMIT TIMER (PER PORT)
42 helloWhen
43
44 NOTE: For convenience all timers are collected together into one state machine.
45
Figure 13-13—Spanning tree protocol state machines—overview and relationships
46
47
48
49
50
51
52
53
54

40 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 NOTATION: ABBREVIATIONS:
Variables are shown both within the machine where they are principally BDM: Bridge Detection Machine
2 used and between machines where they are used to communicate PIM: Port Information Machine
3 information. In the latter case they are shown with a variety of arrow PPM: Port Protocol Migration Machine
styles, running from one machine to another , that provide an overview of PRS: Port Role Selection Machine
4 how the variables are typically used: PRT: Port Role Transitions Machine
5 PRX: Port Receive Machine
Not changed by the target machine . Where the state machines are both PST: Port State Transitions Machine
6 per Port, this variable communicates between machine instances for the PTI: Port TImers Machine
same port. PTX: Port Transmit Machine
7 TCM: Topology Change Machine
8 Set (or cleared) by the originating machine, cleared (or set) by the target
machine. Where the state machines are both per Port , this variable
9 communicates between machine instances for the same port .
10 As above except that the originating per port machine instance
11 communicates with multiple port machine instances (by setting or
clearing variables owned by those Ports ).
12
13 As above except that multiple per Port instances communicate with
(an)other instance(s) (by setting or clearing variables owned by the
14 originating Ports).
15
16 Figure 13-14—MSTP overview notation
17
18
19 13.25 State machine timers
20
21 The timer variables declared in this subclause are part of the specification. The accompanying descriptions
22 are provided to aid in the comprehension of the protocol only, and are not part of the specification. Each
23 timer variable represents an integral number of seconds before timer expiry.
24
25
One instance of the following shall be implemented per-port:
26
27
28 a) edgeDelayWhile (13.25.1)
29 b) helloWhen (13.25.3)
30 c) mdelayWhile (13.25.4)
31
32
33 One instance of the following shall be implemented per-port when L2GP functionality is provided:
34
35 d) pseudoInfoHelloWhen (13.25.9)
36
37 One instance per-port of the following shall be implemented for the CIST and one per-port for each MSTI:
38
39
e) fdWhile (13.25.1)
40
41 f) rrWhile (13.25.1)
42 g) rbWhile (13.25.1)
43 h) tcWhile (13.25.1)
44
45 i) rcvdInfoWhile (13.25.1)
46 j) tcDetected. The Topology Change timer for MRP application usage. New messages are sent while
47 this timer is running (see 10.2).
48
49 Table 13-5 specifies values and ranges for the initial values of timers and for transmission rate limiting
50 performance parameters. Default values are specified to avoid the need to set values prior to operation in
51 most cases, and are widely applicable to networks using the spanning tree protocols specified in this
52 standard. The table recommends Bridge Hello Time, Bridge Max Age, and Bridge Forward Delay values
53 that maximise interoperability in networks that include bridges using STP as specified in IEEE Std 802.1D-
54 1998. Ranges are specified to ensure that the protocols operate correctly.

Copyright © 2008 IEEE. All rights reserved. 41

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1
2
3 Table 13-5—Timer and related parameter values
4
Interoperability
5 Parameter Default Permitted Range
recommendations
6
7 Migrate Time 3.0 —a —a
a
8 Hello Time 2.0 — —a
9 Bridge Max Age 20.0 6.0–40.0 20.0
10
Bridge Forward Delay 15.0 4.0–30.0 15.0
11
12 Transmit Hold Count 6 1–10 6
13 Max Hops 20 6–40 —
14 All times are in seconds. —a Not applicable, value is fixed.
15
16
NOTE—Changes to Bridge Forward Delay do not affect reconfiguration times, unless the network includes bridges that
17 do not conform to this revision of this standard. Changes to Bridge Max Age can have an effect, as it is possible for old
18 information to persist in loops in the physical topology for a number of “hops” equal to the value of Max Age in seconds,
19 and thus exhaust the Transmit Hold Count in small loops.
20
21 Bridge Max Age, Bridge Forward Delay, and Transmit Hold Count may be set by management, if this
22 capability is provided the bridge shall have the capability to use the full range of values in the parameter
23 ranges specified in the Permitted Range column of Table 13-5, with a timer resolution of r seconds, where 0
24 < r <= 1. To support interoperability with previous revisions of this standard and IEEE Std 802.1D, a bridge
25 shall enforce the following relationships:
26
27 2 × (Bridge_Forward_Delay – 1.0 seconds) >= Bridge_Max_Age
28
29 Bridge_Max_Age >= 2 × (Bridge_Hello_Time + 1.0 seconds)
30
31 13.25.1 edgeDelayWhile
32
33 The Edge Delay timer. The time remaining, in the absence of a received BPDU, before this port is identified
34 as an operEdgePort.
35
36 13.25.2 fdWhile
37
38 The Forward Delay timer. Used to delay Port State transitions until other Bridges have received spanning
39 tree information.
40
41 13.25.3 helloWhen
42
43 The Hello timer. Used to ensure that at least one BPDU is transmitted by a Designated Port in each
44 HelloTime period.
45
46 13.25.4 mdelayWhile
47
48 The Migration Delay timer. Used by the Port Protocol Migration state machine to allow time for another
49 RSTP Bridge on the same LAN to synchronize its migration state with this Port before the receipt of a
50 BPDU can cause this Port to change the BPDU types it transmits. Initialized to MigrateTime (13.26.5).
51
52 13.25.5 rbWhile
53
54 The Recent Backup timer. Maintained at its initial value, twice HelloTime, while the Port is a Backup Port.

42 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 13.25.6 rcvdInfoWhile
2
3 The Received Info timer. The time remaining before information, i.e. portPriority (13.27.32) and portTimes
4 (13.27.33), received in a Configuration Message is aged out if a further message is not received.
5
6 13.25.7 rrWhile
7
8 The Recent Root timer.
9
10 13.25.8 tcWhile
11
12 The Topology Change timer. TCN Messages are sent while this timer is running.
13
14 13.25.9 pseudoInfoHelloWhen
15
16 The Pseudo Info Hello When timer. Used to ensure that at least one Pseudo Info BPDU is presented to the
17 spanning tree (as if it had been received on the physical port on which preparePseudoInfo() was invoked) by
18 a Layer Two Gateway Port in a designated role in each HelloTime period.
19
20
21 13.26 Per-bridge variables
22
23 The variables declared in this clause (13.26) are part of the specification. The accompanying descriptions are
24 provided to aid in the comprehension of the protocol only, and are not part of the specification.
25
26 There is one instance per-bridge component of the following variable(s):
27
28 a) ForceProtocolVersion (13.7.2)
29 b) Transmit Hold Count ()
30 c) MigrateTime (13.26.5)
31
32 One instance of the following shall be implemented per-bridge component if MSTP or SPB protocols are
33 implemented:
34
35 d) MstConfigId (13.26.6)
36
37 The above parameters ((a) through (d)) are not modified by the operation of the spanning tree protocols, but
38 are treated as constants by the state machines. If ForceProtocolVersion or MSTConfigId are modified by
39 management, BEGIN shall be asserted for all state machines.
40
41 There is one instance per-bridge of each of the following for the CIST, and one for each MSTI.
42
43 e) BridgeIdentifier (13.26.1)
44 f) BridgePriority (13.26.2)
45 g) BridgeTimes (13.26.3)
46 h) rootPortId (13.26.7)
47 i) rootPriority (13.26.8)
48 j) rootTimes (13.26.9)
49
50 BridgeIdentifier, BridgePriority, and BridgeTimes are not modified by the operation of the spanning tree
51 protocols but are treated as constants by the state machines. If they are modified by management, spanning
52 tree priority vectors and Port Role assignments for shall be recomputed, as specified by the operation of the
53 Port Role Selection state machine (13.36) by clearing selected (13.27) and setting reselect (13.27) for all
54 Bridge Port(s) for the relevant MSTI and for all trees if the CIST parameter is changed.

Copyright © 2008 IEEE. All rights reserved. 43

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 13.26.1 BridgeIdentifier
2
3 The unique Bridge Identifier assigned to this bridge for this tree (CIST or MSTI).
4
5 The 12-bit system ID extension component of a Bridge Identifier (9.2.5 of IEEE Std 802.1D) shall be set to
6 zero for the CIST, and to the value of the MSTID for an MSTI, thus allocating distinct Bridge Identifiers to
7 the CIST and each MSTI all based on the use of a single Bridge Address component value for the MST
8 Bridge as a whole.
9
10 NOTE—This convention is used to convey the MSTID for each MSTI Configuration Message encoded in an MST
11 BPDU.
12
13 The four most significant bits of the Bridge Identifier (the settable Priority component) for the CIST and for
14 each MSTI can be modified independently of the setting of those bits for all other trees, as a part of allowing
15 full and independent configuration control to be exerted over each Spanning Tree instance.
16
17 13.26.2 BridgePriority
18
19
For the CIST, the value of the CIST bridge priority vector, as defined in 13.10. The CIST Root Identifier,
20
CIST Regional Root Identifier, and Designated Bridge Identifier components are all equal to the value of the
21
CIST Bridge Identifier. The remaining components (External Root Path Cost, Internal Root Path Cost, and
22
Designated Port Identifier) are set to zero.
23
24
For a given MSTI, the value of the MSTI bridge priority vector, as defined in 13.11. The MSTI Regional
25
Root Identifier and Designated Bridge Identifier components are equal to the value of the MSTI Bridge
26
Identifier (13.26.1). The remaining components (MSTI Internal Root Path Cost, Designated Port Identifier)
27
are set to zero.
28
29
30 BridgePriority is used by updtRolesTree() in determining the value of the rootPriority variable (see 13.26.8).
31
32 13.26.3 BridgeTimes
33
34 For the CIST, BridgeTimes comprises:
35
36 a) The current values of Bridge Forward Delay and Bridge Max Age (13.25, Table 13-5).
37 b) A Message Age value of zero.
38 c) The current value of Max Hops (13.26.3). This parameter value is determined only by management.
39
40
For a given MSTI, BridgeTimes comprises:
41
42
d) The current value of MaxHops (Max Hops in Table 13-5), the initial value of remainingHops for
43
MSTI information generated at the boundary of an MSTI region (see 13.26.9).
44
45
46 BridgeTimes is used by updtRolesTree() in determining the value of the RootTimes variable (13.26.9).
47
48 13.26.4 ForceProtocolVersion
49
50 The Force Protocol Version parameter for the Bridge (13.7.2).
51
52 13.26.5 MigrateTime
53
54 The value of the Migrate Time parameter as specified in Table 13-5. This value shall not be changed.

44 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 13.26.6 MstConfigId
2
3 The current value of the bridge’s MST Configuration Identifier (13.8). Changes in this parameter cause
4 BEGIN to be asserted for the state machines for the bridge, for all trees, and for each port.
5
6 13.26.7 rootPortId
7
8 For the CIST, the Port Identifier of the Root Port, and a component of the CIST root priority vector (13.10).
9
10 For a given MSTI, the Port Identifier of the Root Port, and a component of the MSTI root priority vector
11 (13.11).
12
13 13.26.8 rootPriority
14
15 For the CIST: the Root Identifier, External Root Path Cost, Regional Root Identifier, Internal Root Path
16 Cost, Designated Bridge Identifier, and Designated Port Identifier components of the bridge’s CIST root
17 priority vector (13.10).
18
19 For a given MSTI: the MSTI Regional Root Identifier, Internal Root Path Cost, Designated Bridge
20 Identifier, and Designated Port Identifier components of the bridge’s MSTI root priority vector (13.11).
21
22 13.26.9 rootTimes
23
24 For the CIST, the Bridge’s timer parameter values (Message Age, Max Age, Forward Delay, and
25 remainingHops). The values of these timers are derived (see 13.29.33) from the values stored in the CIST’s
26 portTimes parameter (13.27.33) for the Root Port or from BridgeTimes (13.26.3).
27
28 For a given MSTI, the value of remainingHops derived (13.29.33) from the value stored in the MSTI’s
29 portTimes parameter (13.27.33) for the Root Port or from BridgeTimes (13.26.3).
30
31 13.26.10 TxHoldCount
32
33 The value of Transmit Hold Count (Table 13-5) for the bridge. If this is modified, the value of txCount
34 (13.27) for all ports shall be set to zero.
35
36
37 13.27 Per-port variables
38
39 The variables declared in this clause (13.27) are part of the specification. The accompanying descriptions are
40 provided to aid in the comprehension of the protocol only, and are not part of the specification.
41
42 There is one instance per port of each of the following variables:
43
44 a) AdminEdge (13.27.1)
45 b) ageingTime (13.27.2)
46 c) AutoEdge (13.27.5)
47 d) enableBPDUrx (13.29)
48 e) enableBPDUtx (13.27.10)
49 f) isL2gp (13.27.12)
50 g) mcheck (13.27.23)
51 h) newInfo (13.27.26)
52 i) operEdge (13.27.28)
53 j) portEnabled (13.27.29)
54 k) portHelloTime (13.27.30)

Copyright © 2008 IEEE. All rights reserved. 45

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 l) rcvdBpdu (13.27.37)
2 m) rcvdRSTP (13.27.41)
3 n) rcvdSTP (13.27.42)
4 o) rcvdTcAck (13.27.44)
5 p) rcvdTcn (13.27.45)
6 q) restrictedRole (13.28.19)
7 r) restrictedTcn (13.27.49)
8 s) sendRSTP (13.27.53)
9 t) tcAck (13.27.53)
10 u) tick (13.27.58)
11 v) txCount (13.27.59)
12
13 If MSTP or the SPB protocols are implemented there is one instance per-port, applicable to the CIST and to
14 all MSTIs and SPTs, of the following variable(s):
15
16 w) rcvdInternal (13.27.50)
17
18 If MSTP or the SPB protocols are implemented there is one instance per-port of each of the following
19 variables for the CIST:
20
21 x) ExternalPortPathCost ()
22 y) infoInternal (13.27.16)
23 z) master (13.27.21)
24 aa) mastered (13.27.22)
25
26 A single per-port instance of the following variable(s) applies to all MSTIs:
27
28 ab) newInfoMsti (13.27.27)
29
30 If the SPB protocols are implemented there is one instance per-port, of the following variable(s):
31
32 ac) chgdRole ()
33 ad) discardedPromiseNumber ()
34 ae) promiseNumber ()
35 af) ownTAPDigest ()
36 ag) rcvdTAPDigest ()
37
38 There is one instance per-port of each of the following variables for the CIST, one per-port for each MSTI,
39 and one per-port for each SPT:
40
41 ah) agree (13.27.3)
42 ai) agreed (13.27.4)
43 aj) designatedPriority (13.27.6)
44 ak) designatedTimes (13.27.7)
45 al) disputed (13.27.8)
46 s) fdbFlush (13.27.13)
47 t) forward (13.27.14)
48 u) forwarding (13.27.15)
49 v) infoIs (13.27.17)
50 w) InternalPortPathCost ()
51 x) learn (13.27.19)
52 y) learning (13.27.13)
53 z) msgPriority (13.27.24)
54 aa) msgTimes (13.27.25)

46 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 ab) portId (13.27.31)

2 ac) portPriority (13.27.32)
3 ad) portTimes (13.27.33)
4 ae) proposed (13.27.34)
5 af) proposing (13.27.35)
6
ag) pseudoRootId (13.29)
7
8 ah) rcvdInfo (13.27.38)
9 ai) rcvdMsg (13.27.40)
10 aj) rcvdTc (13.27.43)
11 ak) reRoot (13.27.46)
12 al) reselect (13.27.46)
13 am) role (13.27.50)
14 an) selected (13.27.51)
15 ao) selectedRole (13.27.52)
16
ap) sync (13.27.54)
17
aq) synced (13.27.55)
18
19 ar) tcProp (13.27.57)
20 as) updtInfo (13.27.60)
21
22 If the SPB protocol are implemented there is one instance per-port of the following variables for the CIST:
23
24 at) latestRole
25 au) latestContract
26
27 If the SPB protocol are implemented there is one instance per-port of the following variables for each SPT:
28
29 av) latestRole
30 aw) latestContract
31
32
13.27.1 AdminEdge
33
34
The AdminEdgePort parameter for the Port (12.n.n). The recommended default value is FALSE.
35
36
37 13.27.2 ageingTime
38
39 Filtering database entries for this Port are aged out after ageingTime has elapsed since they were first created
40 or refreshed by the Learning Process. The value of this parameter is normally Ageing Time (8.8.3, Table 8-
41 4), and is changed to FwdDelay (13.28.8) for a period of FwdDelay after fdbFlush (13.27.13) is set by the
42 topology change state machine if stpVersion (13.28.18) is TRUE.
43
44 13.27.3 agree
45
46 A Boolean. See 13.16.
47
48 13.27.4 agreed
49
50 A Boolean. Indicates that a Configuration Message has been received from another bridge attached to the
51 same LAN indicating Agreement that all Port States for the given tree of all other bridges attached to the
52 same LAN as this port are known to be likewise compatible with a loop free active topology determined by
53 this bridge’s priority vectors and, in the absence of further communication with this bridge, will remain
54 compatible within the design probabilities of protocol failure due to repeated BPDU loss (13.16, 13.24).

Copyright © 2008 IEEE. All rights reserved. 47

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 13.27.5 AutoEdge
2
3 The AutoEdgePort parameter for the Port (12.n.n).
4
5
13.27.6 designatedPriority
6
7
8 For the CIST and a given port, the CIST Root Identifier, External Root Path Cost, Regional Root Identifier,
9 Internal Root Path Cost, Designated Bridge Identifier, and Designated Port Identifier components of the
10 port’s CIST designated priority vector, as defined in 13.10.
11
12 For a given MSTI and port, the Regional Root Identifier, Internal Root Path Cost, Designated Bridge
13 Identifier, and Designated Port Identifier components of the port’s designated priority vector, as defined in
14 13.11.
15
16 13.27.7 designatedTimes
17
18
For the CIST and a given port, the set of timer parameter values (Message Age, Max Age, Forward Delay,
19
and remainingHops) that are used to update Port Times when updtInfo is set. These timer parameter values
20
are used in BPDUs transmitted from the port. The value of designatedTimes is copied from the CIST
21
rootTimes Parameter (13.26.9) by the operation of the updtRolesTree() procedure.
22
23
24 For a given MSTI and port, the value of remainingHops used to update this MSTI’s portTimes parameter
25 when updtInfo is set. This timer parameter value is used in BPDUs transmitted from the port. The value of
26 designatedTimes is copied from this MSTI’s rootTimes parameter (13.26.9) by the operation of the
27 updtRolesTree() procedure.
28
29 13.27.8 disputed
30
31 A Boolean. See 13.29.15.
32
33
13.27.9 enableBPDUrx
34
35
36 A Boolean. This per port management parameter is set by default, and should not be clear unless the port is
37 configured as a Layer Two Gateway Port (i.e. isL2gp is set). When clear it can allow loops to be created, or
38 can result in no connectivity. When cleared, BPDUs received on the port are discarded and not processed.
39
40 13.27.10 enableBPDUtx
41
42 A Boolean. This per port management parameter is set by default, and should not be clear unless the port is
43 configured as a Layer Two Gateway Port (i.e. isL2gp is set). When clear it can allow loops to be created, or
44 can result in no connectivity. When cleared, BPDUs received on the port are discarded and not processed.
45
46
13.27.11 ExternalPortPathCost
47
48
49 <>
50
51 13.27.12 isL2gp
52
53 A Boolean. Set by management to identify a port functioning as a Layer Two Gateway Port. This parameter
54 is set to FALSE by default. When set, enableBPDUtx should be cleared.

48 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 13.27.13 fdbFlush
2
3 A Boolean. Set by the topology change state machine to instruct the filtering database to remove entries for
4 this port, immediately if rstpVersion (17.20.9 of IEEE Std 802.1D) is TRUE, or by rapid ageing (17.19.1 of
5 IEEE Std 802.1D) if stpVersion (17.20.10 of IEEE Std 802.1D) is TRUE. Reset by the filtering database
6 once the entries are removed if rstpVersion is TRUE, and immediately if stpVersion is TRUE. Setting the
7 fdbFlush variable does not result in removal of filtering database entries in the case that the port is an Edge
8 Port (i.e., operEdge is TRUE). The filtering database removes entries only for those VLANs that have a
9 fixed registration (see 10.7.2) on any port of the bridge that is not an Edge Port.
10
11 NOTE—If MVRP is in use, the topology change notification and flushing mechanisms defined in MRP (Clause 10) and
12 MVRP (11.2.5) are responsible for filtering entries in the Filtering Database for VLANs that are dynamically registered
13 using MVRP (i.e., for which there is no fixed registration in the bridge on non-Edge Ports).
14
15 13.27.14 forward
16
17 A Boolean. See 13.38.
18
19 13.27.15 forwarding
20
21 A Boolean. See 13.38.
22
23 13.27.16 infoInternal
24
25 If infoIs is Received, indicating that the port has received current information from the Designated Bridge
26 for the attached LAN, infoInternal is set if that Designated Bridge is in the same MST Region as the
27 receiving bridge and reset otherwise.
28
29 13.27.17 infoIs
30
31 A variable that takes the values Mine, Aged, Received, or Disabled, to indicate the origin/state of the Port’s
32 Spanning Tree information (portInfo) held for the Port, as follows:
33
34 a) If infoIs is Received, the port has received current (not aged out) information from the Designated
35 Bridge for the attached LAN (a point-to-point bridge link being a special case of a LAN).
36 b) If infoIs is Mine, information for the port has been derived from the Root Port for the Bridge (with
37 the addition of root port cost information). This includes the possibility that the Root Port is
38 “Port 0,” i.e., the bridge is the Root Bridge for the Bridged Local Area Network.
39 c) If infoIs is Aged, information from the Root Bridge has been aged out. Just as for “reselect” (see
40 13.27.47), the state machine does not formally allow the “Aged” state to persist. However, if there is
41 a delay in recomputing the new root port, correct processing of a received BPDU is specified.
42 d) Finally if the port is disabled, infoIs is Disabled.
43
44 13.27.18 InternalPortPathCost
45
46 <>
47
48 13.27.19 learn
49
50 A Boolean. See 13.38.
51
52 13.27.20 learning
53
54 A Boolean. See 13.38.

Copyright © 2008 IEEE. All rights reserved. 49

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 13.27.21 master
2
3 A Boolean. Used to determine the value of the Master flag for this MSTI and port in transmitted MST
4 BPDUs.
5
6 Set TRUE if the Port Role for the MSTI and Port is Root Port or Designated Port, and the bridge has selected
7 one of its ports as the Master Port for this MSTI or the mastered flag is set for this MSTI for any other
8 Bridge Port with a Root Port or Designated Port Role. Set FALSE otherwise.
9
10 13.27.22 mastered
11
12 A Boolean. Used to record the value of the Master flag for this MSTI and port in MST BPDUs received
13 from the attached LAN.
14
15 NOTE—master and mastered signal the connection of the MSTI to the CST via the Master Port throughout the MSTI.
16 These variables and their supporting procedures do not affect the connectivity provided by this standard but permit
17 future enhancements to MSTP providing increased flexibility in the choice of Master Port without abandoning plug-and-
18 play network migration. They are, therefore, omitted from the overviews of protocol operation, including Figure 13-13.
19
20 13.27.23 mcheck
21
22 A Boolean. May be set by management to force the Port Protocol Migration state machine to transmit RST
23 (MST, or SPT) BPDUs for a MigrateTime (13.26.5, Table 13-5) period, to test whether all STP Bridges on
24 the attached LAN have been removed and the Port can continue to transmit RSTP BPDUs. Setting mcheck
25 has no effect if stpVersion (13.28.18) is TRUE.
26
27 13.27.24 msgPriority
28
29 For the CIST and a given port, the CIST Root Identifier, External Root Path Cost, Regional Root Identifier,
30 Internal Root Path Cost, Designated Bridge Identifier, and Designated Port Identifier components of the
31 CIST message priority vector conveyed in a received BPDU, as defined in 13.10.
32
33 For a given MSTI and port, the Regional Root Identifier, Internal Root Path Cost, Designated Bridge
34 Identifier, and Designated Port Identifier components of the MSTI message priority vector, as defined in
35 13.11 and conveyed in a received BPDU for this MSTI.
36
37 13.27.25 msgTimes
38
39 For the CIST and a given port, the timer parameter values (Message Age, Max Age, Forward Delay, Hello
40 Time, and remainingHops) conveyed in a received BPDU. If the BPDU is an STP or RST BPDU without
41 MSTP parameters, remainingHops is set to the value of the MaxHops component of BridgeTimes (13.26.3).
42
43 For a given MSTI and port, the value of remainingHops received in the same BPDU as the message priority
44 components of this MSTI’s msgPriority parameter.
45
46 13.27.26 newInfo
47
48 A Boolean. Set TRUE if a BPDU conveying changed CIST information is to be transmitted. It is set FALSE
49 by the Port Transmit state machine.
50
51 13.27.27 newInfoMsti
52
53 A Boolean. Set TRUE if a BPDU conveying changed MSTI information is to be transmitted. It is set FALSE
54 by the Port Transmit state machine.

50 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 13.27.28 operEdge
2
3 A Boolean. The value of the operEdgePort parameter, as determined by the operation of the Bridge
4 Detection state machine (13.33).
5
6
13.27.29 portEnabled
7
8
9 A Boolean. Set if the Bridge’s MAC Relay Entity and Spanning Tree Protocol Entity can use the MAC
10 Service provided by the Bridge Port’s MAC entity to transmit and receive frames to and from the attached
11 LAN, i.e., portEnabled is TRUE if and only if:
12
13 a) MAC_Operational (6.6.2) is TRUE; and
14 b) Administrative Bridge Port State (8.4, 13.12) for the port is Enabled.
15
16 13.27.30 PortHelloTime
17
18
PortHelloTime takes the recommended default value given in Table 13-5
19
20
21 13.27.31 portId
22
23 The Port Identifier for this port. This variable forms a component of the port priority and designated priority
24 vectors (13.10,13.11).
25
26 The four most significant bits of the Port Identifier (the settable Priority component) for the CIST and for
27 each MSTI can be modified independently of the setting of those bits for all other trees, as a part of allowing
28 full and independent configuration control to be exerted over each Spanning Tree instance.
29
30 13.27.32 portPriority
31
32
For the CIST and a given port, the CIST Root Identifier, External Root Path Cost, Regional Root Identifier,
33
Internal Root Path Cost, Designated Bridge Identifier, and Designated Port Identifier components of the
34
port’s port priority vector (13.10).
35
36
37 For a given MSTI and port, the Regional Root Identifier, Internal Root Path Cost, Designated Bridge
38 Identifier, and Designated Port Identifier components of the port’s MSTI port priority vector (13.11).
39
40 13.27.33 portTimes
41
42 For the CIST and a given port, the port’s timer parameter values (Message Age, Max Age, Forward Delay,
43 Hello Time, and remainingHops). The Hello Time timer parameter value is used in transmitted BPDUs.
44
45 For a given MSTI and port, the value of remainingHops for this MSTI in transmitted BPDUs.
46
47
13.27.34 proposed
48
49
50 A Boolean. See 13.16.
51
52 13.27.35 proposing
53
54 A Boolean. See 13.16.

Copyright © 2008 IEEE. All rights reserved. 51

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 13.27.36 pseudoRootId
2
3 A Bridge Identifier configured by management on a per port and per instance basis. By default, it is set to the
4 BridgeIdentifier (13.26.1). <<This “per instance basis” does not makes sense.>>
5
6 13.27.37 rcvdBPDU
7
8
A Boolean. Set by system dependent processes, this variable notifies the Port Receive state machine (13.31)
9
when a valid (Clause 14) Configuration, TCN, RST, MST, or SPT BPDU (14.3) is received on the Port.
10
Reset by the Port Receive state machine.
11
12
13.27.38 rcvdInfo
13
14
15 Set to the result of the rcvInfo() procedure (13.29.13).
16
17 13.27.39 rcvdInternal
18
19 A Boolean. Set TRUE by the Receive Machine if the BPDU received was transmitted by a bridge in the
20 same MST Region as the receiving bridge.
21
22 13.27.40 rcvdMsg
23
24 A Boolean. See 13.31.
25
26 13.27.41 rcvdRSTP
27
28
A Boolean. See 13.31.
29
30
31 13.27.42 rcvdSTP
32
33 A Boolean. See 13.31.
34
35 13.27.43 rcvdTc
36
37 A Boolean. See 13.29.24 and 13.39.
38
39 13.27.44 rcvdTcAck
40
41 A Boolean. See 13.29.24 and 13.39.
42
43
13.27.45 rcvdTcn
44
45
46 A Boolean. See 13.29.24 and 13.39.
47
48 13.27.46 reRoot
49
50 A Boolean. See 13.38.
51
52 13.27.47 reselect
53
54 A Boolean. See 13.36.

52 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 13.27.48 restrictedRole
2
3 A Boolean. Set by management. If TRUE causes the port not to be selected as Root Port for the CIST or any
4 MSTI, even it has the best spanning tree priority vector. Such a port will be selected as an Alternate Port
5 after the Root Port has been selected. This parameter should be FALSE by default. If set, it can cause lack of
6 spanning tree connectivity. It is set by a network administrator to prevent bridges external to a core region of
7 the network influencing the spanning tree active topology, possibly because those bridges are not under the
8 full control of the administrator.
9
10 13.27.49 restrictedTcn
11
12 A Boolean. Set by management. If TRUE causes the port not to propagate received topology change
13 notifications and topology changes to other ports. This parameter should be FALSE by default. If set it can
14 cause temporary loss of connectivity after changes in a spanning trees active topology as a result of
15 persistent incorrectly learned station location information. It is set by a network administrator to prevent
16 bridges external to a core region of the network, causing address flushing in that region, possibly because
17 those bridges are not under the full control of the administrator or MAC_Operational for the attached LANs
18 transitions frequently.
19
20 13.27.50 role
21
22
The current Port Role. DisabledPort, RootPort, DesignatedPort, AlternatePort, BackupPort, or MasterPort.
23
24
NOTE—The MasterPort role applies each MSTI when the CIST Port Role is RootPort and connects to another MST
25 Region. An MSTI Master Port is part of the stable active topology for frames assigned to that MSTI, just as the CIST
26 Root Port forwards frames for the IST. The Port State for each MSTI may differ as required to suppress temporary loops.
27
28 13.27.51 selected
29
30 A Boolean. See 13.36, 13.29.22.
31
32 13.27.52 selectedRole
33
34
A newly computed role for the port.
35
36
13.27.53 sendRSTP
37
38
39 A Boolean. See 13.32, 13.34.
40
41 13.27.54 sync
42
43 A Boolean. Set to force the Port State to be compatible with the loop free active topology determined by the
44 priority vectors held by this bridge (13.16, 13.24) for this tree (CIST, or MSTI), transitioning the Port State
45 to Discarding, and soliciting an Agreement if possible, if the port is not already synchronized (13.27.55).
46
47 13.27.55 synced
48
49 A Boolean. TRUE only if the Port State is compatible with the loop free active topology determined by the
50 priority vectors held by this bridge for this tree (13.16, 13.24).
51
52 13.27.56 tcAck
53
54 A Boolean. Set to transmit a Configuration Message with a topology change acknowledge flag set.

Copyright © 2008 IEEE. All rights reserved. 53

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 13.27.57 tcProp
2
3 A Boolean. Set by the Topology Change state machine of any other port, to indicate that a topology change
4 should be propagated through this port.
5
6 13.27.58 tick
7
8 A Boolean. See the Port Timers state machine (13.30).
9
10 13.27.59 txCount
11
12 A counter. Incremented by the Port Transmission (13.34) state machine on every BPDU transmission, and
13 decremented used by the Port Timers state machine (13.30) once a second. Transmissions are delayed if
14 txCount reaches TxHoldCount ().
15
16 13.27.60 updtInfo
17
18 A boolean. Set by the Port Role Selection state machine (13.36, 13.29.33) to tell the Port Information state
19 machine that it should copy designatedPriority to portPriority and designatedTimes to portTimes.
20
21
22 13.28 State machine conditions and parameters
23
24 The following variable evaluations are defined for notational convenience in the state machines:
25
26 a) allSynced (13.28.1)
27 b) allTransmitReady (13.28.2)
28 c) cist (13.28.3)
29 d) cistRootPort (13.28.4)
30 e) cistDesignatedPort (13.28.5)
31 f) EdgeDelay (13.28.6)
32 g) forwardDelay (13.28.7)
33 h) FwdDelay (13.28.8)
34
i) HelloTime (13.28.9)
35
j) MaxAge (13.28.10)
36
k) mstiDesignatedOrTCpropagatingRootPort (13.28.11)
37
38 l) mstiMasterPort (13.28.12)
39 m) rcvdAnyMsg (13.28.13)
40 n) rcvdCistMsg (13.28.14)
41 o) rcvdMstiMsg (13.28.15)
42 p) reRooted (13.28.16)
43 q) rstpVersion (13.28.17)
44 r) stpVersion (13.28.18)
45 s) updtCistInfo (13.28.19)
46 t) updtMstiInfo (13.28.20)
47
48 13.28.1 allSynced
49
50 The condition allSynced is TRUE for a given port, for a given tree, if and only if
51
52 a) For all ports for the given tree, selected is TRUE, the port’s role is the same as its selectedRole, and
53 updtInfo is FALSE; and
54 b) The role of the given port is

54 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 1) Root Port or Alternate Port and synced is TRUE for all ports for the given tree other than the
2 Root Port; or
3 2) Designated Port and synced is TRUE for all ports for the given tree other than the given port; or
4 3) Master Port and synced is TRUE for all ports for the given tree other than the given port.
5
6 13.28.2 allTransmitReady
7
8
TRUE, if and only if, for the given port for all trees
9
10
11 a) selected is TRUE; and
12 b) updtInfo is FALSE.
13
14 13.28.3 cist
15
16 TRUE only for CIST state machines; i.e., FALSE for MSTI state machine instances.
17
18 13.28.4 cistRootPort
19
20 TRUE if the CIST role for the given port is RootPort.
21
22 13.28.5 cistDesignatedPort
23
24
TRUE if the CIST role for the given port is DesignatedPort.
25
26
27 13.28.6 EdgeDelay
28
29 Returns the value of MigrateTime if operPointToPointMAC is TRUE, and the value of MaxAge otherwise.
30
31 13.28.7 forwardDelay
32
33 Returns the value of HelloTime if sendRSTP is TRUE, and the value of FwdDelay otherwise.
34
35 13.28.8 FwdDelay
36
37 The Forward Delay component of the CIST’s designatedTimes parameter (13.27.7).
38
39 13.28.9 HelloTime
40
41
The Hello Time component of the CIST’s portTimes parameter (13.27.33) with the recommended default
42
value given in Table 13-5.
43
44
13.28.10 MaxAge
45
46
47 The Max Age component of the CIST’s designatedTimes parameter (13.27.7).
48
49 13.28.11 mstiDesignatedOrTCpropagatingRootPort
50
51 TRUE if the role for any MSTI for the given port is either:
52
53 a) DesignatedPort; or
54 b) RootPort, and the instance for the given MSTI and port of the tcWhile timer is not zero.

Copyright © 2008 IEEE. All rights reserved. 55

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 13.28.12 mstiMasterPort
2
3 TRUE if the role for any MSTI for the given port is MasterPort.
4
5 13.28.13 rcvdAnyMsg
6
7 TRUE for a given port if rcvdMsg is TRUE for the CIST or any MSTI for that port.
8
9 13.28.14 rcvdCistMsg
10
11 TRUE for a given port if and only if rcvdMsg is TRUE for the CIST for that port.
12
13 13.28.15 rcvdMstiMsg
14
15 TRUE for a given port and MSTI if and only if rcvdMsg is FALSE for the CIST for that port and rcvdMsg is
16 TRUE for the MSTI for that port.
17
18 13.28.16 reRooted
19
20 TRUE if the rrWhile timer is clear (zero) for all Ports for the given tree other than the given Port.
21
22 13.28.17 rstpVersion
23
24 TRUE if ForceProtocolVersion (13.7.2) is greater than or equal to 2.
25
26 13.28.18 stpVersion
27
28 TRUE if Force Protocol Version (13.7.2) is less than 2.
29
30 13.28.19 updtCistInfo
31
32 TRUE for a given port if and only if updtInfo is TRUE for the CIST for that port.
33
34 13.28.20 updtMstiInfo
35
36 TRUE for a given port and MSTI if and only if updtInfo is TRUE for the MSTI for that port or updtInfo is
37 TRUE for the CIST for that port.
38
39 NOTE—The dependency of rcvdMstiMsg and updtMstiInfo on CIST variables for the port reflects the fact that MSTIs
40 exist in a context of CST parameters. The state machines ensure that the CIST parameters from received BPDUs are
41 processed and updated prior to processing MSTI information.
42
43 13.29 State machine procedures
44
45 The following procedures perform the functions specified for both the CIST and the MSTI state machines or
46 specifically for the CIST or a given MSTI:
47
48 a) betterorsameInfo(newInfoIs) (13.29.1)
49 b) checkBPDUconsistency() (13.29.2)
50 c) clearAllRcvdMsgs() (13.29.3)
51 d) clearReselectTree() (13.29.4)
52 e) disableForwarding(13.29.5)
53 f) disableLearning(13.29.6)
54 g) enableForwarding(13.29.7)

56 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 h) enableLearning(13.29.8)
2 i) fromSameRegion() (13.29.9)
3 j) newTcDetected() (13.29.10)
4 k) newTcWhile() (13.29.11)
5 j) checkBPDUConsistency() (13.29.2)
6 k) preparePseudoInfo() (13.29.12)
7 l) rcvInfo() (13.29.13)
8 m) recordAgreement() (13.29.14)
9 n) recordDispute() (13.29.15)
10 o) recordMastered() (13.29.16)
11 p) recordPriority()
12 q) recordProposal() (13.29.18)
13 r) recordTimes() (13.29.19)
14 s) setRcvdMsgs() (13.29.20)
15 t) setReRootTree(13.29.21)
16 u) setSelectedTree() (13.29.22)
17 v) setSyncTree() (13.29.23)
18 w) setTcFlags() (13.29.24)
19 x) setTcPropTree() (13.29.25)
20 y) syncMaster() (13.29.26)
21 z) txConfig() (13.29.27)
22 aa) txMstp() (13.29.28)
23 ab) txRstp() (13.29.29)
24 ac) txTcn() (13.29.30)
25
ad) updtBPDUVersion() (13.29.31)
26
ae) updtRcvdInfoWhile() (13.29.32)
27
af) updtRolesTree() (13.29.33)
28
ag) updtRolesDisabledTree() (13.29.34)
29
30
All references to named variables in the specification of procedures are to instances of the variables
31
corresponding to the instance of the state machine using the function, i.e., to the CIST or the given MSTI as
32
appropriate. References to forwarding and learning apply to frames assigned to the specified tree.
33
34
13.29.1 betterorsameInfo(newInfoIs)
35
36
Returns TRUE if, for a given port and tree (CIST, or MSTI), either
37
38
a) The procedure’s parameter newInfoIs is Received, and infoIs is Received and the msgPriority vector
39
is better than or the same as (13.10) the portPriority vector; or,
40
b) The procedure’s parameter newInfoIs is Mine, and infoIs is Mine and the designatedPriority vector
41
is better than or the same as (13.10) the portPriority vector.
42
43
44 Returns False otherwise.
45
NOTE—This procedure is not invoked (in the case of a MSTI) if the received BPDU carrying the MSTI information was
46 received from another MST Region. In that event, the Port Receive Machine (using setRcvdMsgs()) does not set
47 rcvdMsg for any MSTI, and the Port Information Machine’s SUPERIOR_DESIGNATED state is not entered.
48
49 13.29.2 checkBPDUConsistency()
50
51 This procedure compares the message priority vector of the information received on the port with the port
52 priority vector for the port, and:
53
54 a) If the received message priority vector is superior to the port priority vector; and

Copyright © 2008 IEEE. All rights reserved. 57

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 b) The BPDU is an STP BPDU (version 0 or version 1); or

2 c) The BPDU is an RST or MST BPDU (type 2, version 2 or above) and its Port Role values indicates
3 Designated and its Learning flag is set;
4
5
then, for the CIST and all the MSTIs on this port the disputed flag is set and agreed is cleared.
6
7
8 13.29.3 clearAllRcvdMsgs()
9
10 Clears rcvdMsg for the CIST and all MSTIs, for this port.
11
12 13.29.4 clearReselectTree()
13
14
Clears reselect for the tree (the CIST or a given MSTI) for all ports of the bridge.
15
16
17 13.29.5 disableForwarding()
18
19 An implementation dependent procedure that causes the Forwarding Process (7.7) to stop forwarding frames
20 through the Port. The procedure does not complete until forwarding has stopped.
21
22 13.29.6 disableLearning()
23
24
25 An implementation dependent procedure that causes the Learning Process (7.8) to stop learning from the
26 source address of frames received on the Port. The procedure does not complete until learning has stopped.
27
28 13.29.7 enableForwarding()
29
30 An implementation dependent procedure that causes the Forwarding Process (7.7) to start forwarding frames
31 through the Port. The procedure does not complete until forwarding has been enabled.
32
33 13.29.8 enableLearning()
34
35
36 An implementation dependent procedure that causes the Learning Process (7.8) to start learning from frames
37 received on the Port. The procedure does not complete until learning has been enabled.
38
39 13.29.9 fromSameRegion()
40
41 Returns TRUE if rcvdRSTP is TRUE, and the received BPDU conveys a MST Configuration Identifier that
42 matches that held for the bridge. Returns FALSE otherwise.
43
44 13.29.10 newTcDetected()
45
46
47 If the value of tcDetected is zero and sendRSTP is TRUE, this procedure sets the value of tcDetected to
48 HelloTime plus one second. The value of HelloTime is taken from the CIST’s portTimes parameter
49 (13.27.33) for this port.
50
51 If the value of tcDetected is zero and sendRSTP is FALSE, this procedure sets the value of tcDetected to the
52 sum of the Max Age and Forward Delay components of rootTimes.
53
54 Otherwise the procedure takes no action.

58 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 13.29.11 newTcWhile()
2
3 If the value of tcWhile is zero and sendRSTP is TRUE, this procedure sets the value of tcWhile to
4 HelloTime plus one second and sets either newInfo TRUE for the CIST or newInfoMsti TRUE for a given
5 MSTI. The value of HelloTime is taken from the CIST’s portTimes parameter (13.27.33) for this port.
6
7 If the value of tcWhile is zero and sendRSTP is FALSE, this procedure sets the value of tcWhile to the sum
8 of the Max Age and Forward Delay components of rootTimes and does not change the value of either
9 newInfo or newInfoMsti.
10
11 Otherwise the procedure takes no action.
12
13 13.29.12 preparePseudoInfo()
14
15 Using local parameters, this procedure creates a Pseudo Info BPDU that will be presented to the spanning
16 tree as if it had been received from the physical port on which it was invoked. The components of this BPDU
17 are as follows:
18
19 a) This is an MST BPDU: Protocol Identifier 0, Protocol Version Identifier 3 and BPDU Type 2;
20 b) Message Age, Max Age, Hello Time and Forward Delay are derived from BridgeTimes (13.26.3);
21 c) The CIST information carries the message priority vector (13.10) with a value of {pseudoRootId, 0,
22 pseudoRootId, 0, 0, 0};
23 d) CIST Flags with the Port Role flags indicating Designated, and the Learning and Forwarding flags
24 set;
25 e) The Version 1 Length is 0 and Version 3 Length calculated appropriately;
26 f) For each MSTI configured on the bridge, the corresponding MSTI Configuration Message carries:
27 1) a message priority vector with a value of {pseudoRootId, 0, 0, 0};
28 2) MSTI Flags with the Port Role flags indicating Designated, and the Learning and Forwarding
29 flags set;
30 3) MSTI Remaining Hops set to the value of the MaxHops component of BridgeTimes (13.26.3).
31
32 13.29.13 rcvInfo()
33
34 Decodes received BPDUs. Sets rcvdTcn and sets rcvdTc for each and every MSTI if a TCN BPDU has been
35 received, and extracts the message priority and timer values from the received BPDU storing them in the
36 msgPriority and msgTimes variables.
37
38 Returns SuperiorDesignatedInfo if, for a given port and tree (CIST, or MSTI):
39
40 a) The received CIST or MSTI message conveys a Designated Port Role, and
41 1) The message priority (msgPriority—13.27.24) is superior (13.10 or 13.11) to the port’s port
42 priority vector, or
43 2) The message priority is the same as the port’s port priority vector, and any of the received timer
44 parameter values (msgTimes—13.27.25) differ from those already held for the port
45 (portTimes—13.27.33).
46
47 Otherwise, returns RepeatedDesignatedInfo if, for a given port and tree (CIST, or MSTI):
48
49 b) The received CIST or MSTI message conveys a Designated Port Role, and
50 1) A message priority vector and timer parameters that are the same as the port’s port priority
51 vector and timer values; and
52 2) infoIs is Received.
53
54 Otherwise, returns InferiorDesignatedInfo if, for a given port and tree (CIST, or MSTI):

Copyright © 2008 IEEE. All rights reserved. 59

This is an unapproved IEEE Standards Draft, subject to change.
 P802.1aq/D1.0+suggested changes LOCAL AND METROPOLITAN AREA NETWORKS
November 4, 2008

1 c) The received CIST or MSTI message conveys a Designated Port Role.

2
3 Otherwise, returns InferiorRootAlternateInfo if, for a given port and tree (CIST, or MSTI):
4
5 d) The received CIST or MSTI message conveys a Root Port, Alternate Port, or Backup Port Role and
6 a CIST or MSTI message priority that is the same as or worse than the CIST or MSTI port priority
7 vector.
8
9 Otherwise, returns OtherInfo.
10
11
NOTE—A Configuration BPDU implicitly conveys a Designated Port Role.
12
13
13.29.14 recordAgreement()
14
15
16 For the CIST and a given port, if rstpVersion is TRUE, operPointToPointMAC (6.6.3) is TRUE, and the
17 received CIST Message has the Agreement flag set, the CIST agreed flag is set, and the CIST proposing flag
18 is cleared. Otherwise the CIST agreed flag is cleared. Additionally, if the CIST message was received from a
19 bridge in a different MST Region, i.e., the rcvdInternal flag is clear, the agreed and proposing flags for this
20 port for all MSTIs are set or cleared to the same value as the CIST agreed and proposing flags. If the CIST
21 message was received from a bridge in the same MST Region, the MSTI agreed and proposing flags are not
22 changed.
23
24 For a given MSTI and port, if operPointToPointMAC (6.6.3) is TRUE, and
25
26 a) The message priority vector of the CIST Message accompanying the received MSTI Message (i.e.,
27 received in the same BPDU) has the same CIST Root Identifier, CIST External Root Path Cost, and
28 Regional Root Identifier as the CIST port priority vector, and
29 b) The received MSTI Message has the Agreement flag set,
30
31 the MSTI agreed flag is set and the MSTI proposing flag is cleared. Otherwise the MSTI agreed flag is
32 cleared.
33
34 NOTE—MSTI Messages received from bridges external to the MST Region are discarded and not processed by
35 recordAgreeement() or recordProposal().
36
37 13.29.15 recordDispute()
38
39 For the CIST and a given port, if the CIST message has the learning flag set:
40
41 a) The disputed variable is set; and
42 b) The agreed variable is cleared.
43
44
Additionally, if the CIST message was received from a bridge in a different MST region (i.e., if the
45
rcvdInternal flag is clear), then for all the MSTIs:
46
47
48 c) The disputed variable is set; and
49 d) The agreed variable is cleared.
50
51 For a given MSTI and port, if the received MSTI message has the learning flag set:
52
53 e) The disputed variable is set; and
54 f) The agreed variable is cleared.

60 Copyright © 2008 IEEE. All rights reserved.

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 13.29.16 recordMastered()
2
3 For the CIST and a given port, if the CIST message was received from a bridge in a different MST Region,
4 i.e. the rcvdInternal flag is clear, the mastered variable for this port is cleared for all MSTIs.
5
6 For a given MSTI and port, if the MSTI message was received on a point-to-point link and the MSTI
7 Message has the Master flag set, set the mastered variable for this MSTI. Otherwise reset the mastered
8 variable.
9
10 13.29.17 recordPriority()
11
12
Sets the components of the portPriority variable to the values of the corresponding msgPriority components.
13
14
15 13.29.18 recordProposal()
16
17 For the CIST and a given port, if the received CIST Message conveys a Designated Port Role, and has the
18 Proposal flag set, the CIST proposed flag is set. Otherwise the CIST proposed flag is not changed.
19 Additionally, if the CIST Message was received from a bridge in a different MST Region, i.e., the
20 rcvdInternal flag is clear, the proposed flags for this port for all MSTIs are set or cleared to the same value as
21 the CIST proposed flag. If the CIST message was received from a bridge in the same MST Region, the
22 MSTI proposed flags are not changed.
23
24 For a given MSTI and port, if the received MSTI Message conveys a Designated Port Role, and has the
25 Proposal flag set, the MSTI proposed flag is set. Otherwise the MSTI proposed flag is not changed.
26
27 13.29.19 recordTimes()
28
29 For the CIST and a given port, sets portTimes’ Message Age, Max Age, Forward Delay, and remainingHops
30 to the received values held in msgTimes and portTimes’ Hello Time to msgTimes’ Hello Time if that is
31 greater than the minimum specified in the Compatibility Range column of Table 17-1 of IEEE Std 802.1D,
32 and to that minimum otherwise.
33
34 For a given MSTI and port, sets portTime’s remainingHops to the received value held in msgTimes.
35
36 13.29.20 setRcvdMsgs()
37
38
Sets rcvdMsg for the CIST, and makes the received CST or CIST message available to the CIST Port
39
Information state machines.
40
41
42 Additionally, and if and only if rcvdInternal is set, sets rcvdMsg for each and every MSTI for which a MSTI
43 message is conveyed in the BPDU, and makes available each MSTI message and the common parts of the
44 CIST message priority (the CIST Root Identifier, External Root Path Cost, and Regional Root Identifier) to
45 the Port Information state machine for that MSTI.
46
47 13.29.21 setReRootTree()
48
49 Sets reRoot TRUE for this tree (the CIST or a given MSTI) for all ports of the bridge.
50
51 13.29.22 setSelectedTree()
52
53 Sets selected TRUE for this tree (the CIST or a given MSTI) for all ports of the bridge if reselect is FALSE
54 for all ports in this tree. If reselect is TRUE for any port in this tree, this procedure takes no action.

Copyright © 2008 IEEE. All rights reserved. 61

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 13.29.23 setSyncTree()
2
3 Sets sync TRUE for this tree (the CIST or a given MSTI) for all ports of the bridge.
4
5 13.29.24 setTcFlags()
6
7 For the CIST and a given port:
8
9 a) If the Topology Change Acknowledgment flag is set for the CIST in the received BPDU, sets
10 rcvdTcAck TRUE.
11 b) If rcvdInternal is clear and the Topology Change flag is set for the CIST in the received BPDU, sets
12 rcvdTc TRUE for the CIST and for each and every MSTI.
13 c) If rcvdInternal is set, sets rcvdTc for the CIST if the Topology Change flag is set for the CIST in the
14 received BPDU.
15
16 For a given MSTI and port, sets rcvdTc for this MSTI if the Topology Change flag is set in the
17 corresponding MSTI message.
18
19 13.29.25 setTcPropTree()
20
21 If and only if restrictedTcn is FALSE for the port that invoked the procedure, sets tcProp TRUE for the given
22 tree (the CIST or a given MSTI) for all other ports.
23
24 13.29.26 syncMaster()
25
26 For all MSTIs, for each port that has infoInternal set:
27
28 a) Clears the agree, agreed, and synced variables; and
29 b) Sets the sync variable.
30
31 13.29.27 txConfig()
32
33 Transmits a Configuration BPDU. The first four components of the message priority vector (13.27.24)
34 conveyed in the BPDU are set to the value of the CIST Root Identifier, External Root Path Cost, Bridge
35 Identifier, and Port Identifier components of the CIST’s designatedPriority parameter (13.27.6) for this port.
36 The topology change flag is set if (tcWhile != 0) for the port. The topology change acknowledgment flag is
37 set to the value of TcAck for the port. The remaining flags are set to zero. The value of the Message Age,
38 Max Age, and Fwd Delay parameters conveyed in the BPDU are set to the values held in the CIST’s
39 designatedTimes parameter (13.27.7) for the port. The value of the Hello Time parameter conveyed in the
40 BPDU is set to the value held in the CIST’s portTimes parameter (13.27.33) for the port.
41
42 13.29.28 txMstp()
43
44 Transmits a MST BPDU (14.5), encoded according to the specification contained in 14.9. The first six
45 components of the CIST message priority vector (13.27.24) conveyed in the BPDU are set to the value of the
46 CIST’s designatedPriority parameter (13.27.6) for this port. The Port Role in the BPDU (14.2.1) is set to the
47 current value of the role variable for the transmitting port (13.27.50). The Agreement and Proposal flags in
48 the BPDU are set to the values of the agree (13.27 of this standard, 17.19 of IEEE Std 802.1D) and
49 proposing (13.27 of this standard, 17.19.24 of IEEE Std 802.1D) variables for the transmitting port,
50 respectively. The CIST topology change flag is set if (tcWhile != 0) for the port. The topology change
51 acknowledge flag in the BPDU is never used and is set to zero. The learning and forwarding flags in the
52 BPDU are set to the values of the learning (13.27 of this standard, 17.19.12 of IEEE Std 802.1D) and
53 forwarding (13.27 of this standard, 17.19.9 of IEEE Std 802.1D) variables for the CIST, respectively. The
54 value of the Message Age, Max Age, and Fwd Delay parameters conveyed in the BPDU are set to the values

Copyright © 2008 IEEE. All rights reserved. 62

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 held in the CIST’s designatedTimes parameter (13.27.7) for the port. The value of the Hello Time parameter
2 conveyed in the BPDU is set to the value held in the CIST’s portTimes parameter (13.27.33) for the port.
3
4 If the value of the Force Protocol Version parameter is less than 3, no further parameters are encoded in the
5 BPDU and the protocol version parameter is set to 2 (denoting a RST BPDU). Otherwise, the protocol
6 version parameter is set to 3 and the remaining parameters of the MST BPDU are encoded:
7
8 a) The version 3 length.
9 b) The MST Configuration Identifier parameter of the BPDU is the value of MstConfigId (13.26.6).
10 c) The CIST Internal Root Path Cost (13.27.6).
11 d) The CIST Bridge Identifier (CIST Designated Bridge Identifier—13.27.6).
12
e) The CIST Remaining Hops (13.27.7).
13
f) The parameters of each MSTI message, encoded in MSTID order.
14
15
NOTE—No more than 64 MSTIs may be supported. The parameter sets for all of these can be encoded in a standard-
16 sized Ethernet frame.
17
18 13.29.29 txRstp()
19
20
Transmits an RST BPDU. The values of the message priority vector components conveyed in the BPDU are
21
those of designatedPriority (13.27.6) for this Port. The Port Role in the BPDU (9.3.3) is set to the current
22
value of the role variable for the transmitting port (13.27.50). The Agreement and Proposal flags in the
23
BPDU are set to the values of the agree (13.27.3) and proposing (13.27.35) variables for the transmitting
24
Port, respectively. The topology change flag is set if (tcWhile ! = 0) for the Port. The topology change
25
acknowledge flag in the BPDU is never used and is set to zero. The Learning and Forwarding flags in the
26
BPDU are set to the values of the learning (13.27.20) and forwarding (13.27.15) variables for the
27
transmitting Port, respectively. The value of the Message Age, Max Age, Fwd Delay, and Hello Time
28
parameters conveyed in the BPDU are set to the values held in designatedTimes (13.27.7) for the Port.
29
30
13.29.30 txTcn()
31
32
Transmits a TCN BPDU.
33
34
35 13.29.31 updtBPDUVersion()
36
37 Sets rcvdSTP TRUE if the BPDU received is a version 0 or version 1 TCN or a Config BPDU. Sets
38 rcvdRSTP TRUE if the received BPDU is a RST BPDU or a MST BPDU.
39
40 13.29.32 updtRcvdInfoWhile()
41
42 Updates rcvdInfoWhile (13.25). The value assigned to rcvdInfoWhile is three times the Hello Time, if
43 either:
44
45 a) Message Age, incremented by 1 second and rounded to the nearest whole second, does not exceed
46 Max Age and the information was received from a bridge external to the MST Region (rcvdInternal
47 FALSE);
48
49 or
50
51 b) remainingHops, decremented by one, is greater than zero and the information was received from a
52 bridge internal to the MST Region (rcvdInternal TRUE);
53
54 and is zero otherwise.

Copyright © 2008 IEEE. All rights reserved. 63

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 The values of Message Age, Max Age, remainingHops, and Hello Time used in these calculations are taken
2 from the CIST’s portTimes parameter (13.27.33) and are not changed by this procedure.
3
4 13.29.33 updtRolesTree()
5
6 This procedure calculates the following priority vectors (13.9, 13.10 for the CIST, 13.11 for a MSTI) and
7 timer values, for the CIST or a given MSTI:
8
9 a) The root path priority vector for each Bridge Port that is not Disabled and has a port priority vector
10 (portPriority plus portId—see 13.27.32 and 13.27.31) that has been recorded from a received
11 message and not aged out (infoIs == Received); and
12 b) The Bridge’s root priority vector (rootPortId, rootPriority—13.26.7, 13.26.8), chosen as the best of
13 the set of priority vectors comprising the bridge’s own bridge priority vector (BridgePriority—
14 13.26.2) plus all calculated root path priority vectors whose:
15
1) DesignatedBridgeID Bridge Address component is not equal to that component of the bridge’s
16
own bridge priority vector (13.10) and,
17
2) Port’s restrictedRole parameter is FALSE; and
18
19 c) The bridge’s root times, (rootTimes—13.26.9), set equal to:
20 1) BridgeTimes (13.26.3), if the chosen root priority vector is the bridge priority vector;
21 otherwise,
22 2) portTimes (13.27.33) for the port associated with the selected root priority vector, with the
23 Message Age component incremented by 1 second and rounded to the nearest whole second if
24 the information was received from a bridge external to the MST Region (rcvdInternal FALSE),
25 and with remainingHops decremented by one if the information was received from a bridge
26 internal to the MST Region (rcvdInternal TRUE).
27 d) The designated priority vector (designatedPriority—13.27.6) for each port; and
28 e) The designated times (designatedTimes—13.27.7) for each port set equal to the value of root times.
29
30 If the root priority vector for the CIST is recalculated, and has a different Regional Root Identifier than that
31 previously selected, and has or had a non-zero CIST External Root Path Cost, the syncMaster() procedure
32 (13.29.26) is invoked.
33
34 NOTE—Changes in Regional Root Identifier will not cause loops if the Regional Root is within an MST Region, as is
35 the case if and only if the MST Region is the Root of the CST. This important optimization allows the MSTIs to be fully
36 independent of each other in the case where they compose the core of a network.
37
38 The CIST or MSTI port role for each port is assigned, and its port priority vector and timer information are
39 updated as follows:
40
41 f) If the port is Disabled (infoIs = Disabled), selectedRole is set to DisabledPort.
42 g) Otherwise, if this procedure is invoked for a given MSTI:
43 1) If the port is not Disabled, the selected CIST Port Role (calculated for the CIST prior to
44 invoking this procedure for a given MSTI) is RootPort, and the CIST port priority information
45 was received from a bridge external to the MST Region (infoIs == Received and infoInternal
46 == FALSE), selectedRole is set to MasterPort. Additionally, updtInfo is set if the port priority
47 vector differs from the designated priority vector or the port’s associated timer parameter
48 differs from the one for the Root Port;
49 2) If the port is not Disabled, the selected CIST Port Role (calculated for the CIST prior to
50 invoking this procedure for a given MSTI) is AlternatePort, and the CIST port priority
51 information was received from a bridge external to the MST Region (infoIs == Received and
52 infoInternal == FALSE), selectedRole is set to AlternatePort. Additionally, updtInfo is set if the
53 port priority vector differs from the designated priority vector or the port’s associated timer
54 parameter differs from the one for the Root Port.

Copyright © 2008 IEEE. All rights reserved. 64

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 Otherwise, for each port of the CIST, or for each port of a given MSTI that is not Disabled and whose CIST
2 port priority information was not received from a bridge external to the Region (infoIs != Received or
3 infoInternal == TRUE), the CIST or MSTI port role for each port is assigned, and its port priority vector and
4 timer information are updated as follows:
5
6 h) If the port priority vector information was aged (infoIs = Aged), updtInfo is set and selectedRole is
7 set to DesignatedPort;
8
i) If the port priority vector was derived from another port on the bridge or from the bridge itself as the
9
Root Bridge (infoIs = Mine), selectedRole is set to DesignatedPort. Additionally, updtInfo is set if
10
the port priority vector differs from the designated priority vector or the port’s associated timer
11
parameter(s) differ(s) from the Root Port’s associated timer parameters;
12
13 j) If the port priority vector was received in a Configuration Message and is not aged
14 (infoIs == Received), and the root priority vector is now derived from it, selectedRole is set to
15 RootPort, and updtInfo is reset;
16 k) If the port priority vector was received in a Configuration Message and is not aged
17 (infoIs == Received), the root priority vector is not now derived from it, the designated priority
18 vector is not better than the port priority vector, and the designated bridge and designated port
19 components of the port priority vector do not reflect another port on this bridge, selectedRole is set
20 to AlternatePort, and updtInfo is reset;
21 l) If the port priority vector was received in a Configuration Message and is not aged
22 (infoIs == Received), the root priority vector is not now derived from it, the designated priority
23 vector is not better than the port priority vector, and the designated bridge and designated port
24 components of the port priority vector reflect another port on this bridge, selectedRole is set to
25 BackupPort, and updtInfo is reset;
26 m) If the port priority vector was received in a Configuration Message and is not aged
27 (infoIs == Received), the root priority vector is not now derived from it, the designated priority
28 vector is better than the port priority vector, selectedRole is set to DesignatedPort, and updtInfo is
29 set.
30
31
13.29.34 uptRolesDisabledTree()
32
33
34 This procedure sets selectedRole to DisabledPort for all ports of the bridge for a given tree (CIST or MSTI).
35
36
37
13.30 The Port Timers state machine
38
39 The Port Timers state machine shall implement the function specified by the state diagram in Figure 13-15
40 and the attendant definitions contained in 13.25 through 13.29.
41 BEGIN

42 ONE_SECOND The following abbreviation is used in

43 tick = FALSE; this state diagram:
dec(x)
44 tick == TRUE { if (x !=0) x= x-1;
}
45 TICK
46 dec(helloWhen); dec(tcWhile); dec(fdWhile); dec(rcvdInfoWhile); dec(rrWhile);
If there is more than one instance of
x, e.g. per port, all instances are
47 dec(rbWhile);dec(mdelayWhile); dec(edgeDelayWhile); dec(txCount); dec(pseudoInfoHelloWhen);
separately decremented.
UCT <<802.1-2003 PTI 1.0>>
48
49
Figure 13-15—Port Timers state machine
50
51
52 The state machine uses tick (13.27), a signal set by an implementation-specific system clock function at one
53 second intervals, to decrement the timer variables for the CIST and all MSTIs for the port. The state machine
54 that uses a given timer variable is responsible for setting its initial value.

Copyright © 2008 IEEE. All rights reserved. 65

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 13.31 Port Receive state machine

2
3 The Port Receive state machine shall implement the function specified by the state diagram contained in
4 Figure 13-16 and the attendant definitions contained in 13.25 through 13.29.
5 BEGIN || ((rcvdBpdu || edgeDelayWhile != MigrateTime)) && !portEnabled)
6
7
8 DISCARD
rcvdBpdu = rcvdRSTP = rcvdSTP = FALSE;
9 clearAllRcvdMsgs();
10 edgeDelayWhile = MigrateTime;

11 rcvdBpdu && portEnabled

12
13 RECEIVE
14 updtBPDUVersion();
rcvdInternal = fromSameRegion();
15 setRcvdMsgs();
16 operEdge = rcvdBpdu = FALSE;
edgeDelayWhile = MigrateTime;
17 rcvdBpdu && portEnabled && !rcvdAnyMsg
18
19 Figure 13-16—Port Receive state machine
20
21 This state machine is responsible for receiving each BPDU. The next BPDU is not processed until all
22 rcvdMsg flags have been cleared by the per-tree state machines.
23
24
25 13.32 Port Protocol Migration state machine
26
27 The Port Protocol Migration state machine shall implement the function specified by the state diagram
28 contained in Figure 13-18 and the attendant definitions contained in 13.25 through 13.29.
29 BEGIN (mdelayWhile != MigrateTime)
30 && !portEnabled
31
CHECKING_RSTP
32 mcheck = FALSE;
33 sendRSTP = (rstpVersion);
mdelayWhile = Migrate Time;
34
(mdelayWhile == 0)
35
36
37 SELECTING_STP
sendRSTP = FALSE;
38 mdelayWhile = Migrate Time;
39 (mdelayWhile == 0) ||
40 !portEnabled || mcheck

41
42 SENSING
43 rcvdRSTP = rcvdSTP = FALSE;

44
sendRSTP && rcvdSTP
45 !portEnabled || mcheck ||
46 ((rstpVersion) && !sendRSTP && rcvdRSTP))

47
Figure 13-17—Port Protocol Migration state machine
48
49
50
51
52
53
54

Copyright © 2008 IEEE. All rights reserved. 66

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 13.33 Bridge Detection state machine

2
3 The Bridge Detection state machine shall implement the function specified by the state diagram contained in
4 Figure 13-18 and the attendant definitions contained in 13.25 through 13.29.
5
6 BEGIN && !AdminEdge

7
NOT_EDGE
8
operEdge = FALSE; isolate = FALSE;
9
10 (!portEnabled && AdminEdge) ||
((edgeDelayWhile == 0) && AutoEdge &&sendRstp && proposing)
11
12 BEGIN && AdminEdge

13
EDGE
14
operEdge = TRUE; isolate = FALSE;
15
16 ((!portEnabled || !AutoEdge) && !AdminEdge) || !operEdge

17 (edgeDelayWhile == 0) && !AdminEdge && !AutoEdge && sendRstp && proposing &&operPointToPoint
18 ISOLATED

19 operEdge = FALSE; isolate = TRUE;

20 AdminEdge || AutoEdge || !isolate || !operPointToPoint
21
22 Mick : Updated 28SEPT08

23 Figure 13-18—Bridge Detection state machine

24
25
26
13.34 Port Transmit state machine
27
28
The Port Transmit state machine shall implement the function specified by the state diagram contained in
29
Figure 13-19 and the attendant definitions contained in 13.25 through 13.29.
30
BEGIN || !portEnabled || !enableBPDUtx
31
32
33 TRANSMIT_INIT TRANSMIT_CONFIG
34 newInfo = newInfoMsti = TRUE;
newInfo = FALSE;
txConfig(); txCount +=1;
35 txCount = 0;
tcAck = FALSE;
36 UCT UCT
(helloWhen == 0)
37
TRANSMIT_TCN
38 TRANSMIT_PERIODIC
39 newInfo = FALSE;
txTcn(); txCount +=1;
40 newInfo = newInfo || (cistDesignatedPort ||
(cistRootPort && (tcWhile !=0))); UCT
41
42 newInfoMsti = newInfoMsti || TRANSMIT_RSTP
mstiDesignatedOrTCpropagatingRootPort;
43 newInfo = newInfoMsti = FALSE;
txMstp(); txCount +=1;
44 tcAck = FALSE;
UCT
45 UCT
46
IDLE
47
helloWhen = HelloTime;
48
49 sendRSTP && (newInfo || (newInfoMsti && !mstiMasterPort)) && (txCount < TxHoldCount) && (helloWhen !=0)

50 !sendRSTP && newInfo && cistRootPort && (txCount < TxHoldCount) && (helloWhen != 0)
51 !sendRSTP && newInfo && cistDesignatedPort && (txCount < TxHoldCount) && (helloWhen != 0)
52 All transtions, except UCT, are qualified by "&& allTransmitReady".
53
54 Figure 13-19—Port Transmit state machine

Copyright © 2008 IEEE. All rights reserved. 67

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 This state machine is responsible for transmitting BPDUs.

2
3 NOTE 1—Any single received BPDU that changes the CIST Root Identifier, CIST External Root Path Cost, or CIST
4 Regional Root associated with MSTIs should be processed entirely, or not at all, before encoding BPDUs for
transmission.This recommendation minimizes the number of BPDUs to be transmitted following receipt of a BPDU with
5
new information. It is not required for correctness and has not therefore been incorporated into the state machines.
6
7 NOTE 2—If a CIST state machine sets newInfo, this machine will ensure that a BPDU is transmitted conveying the new
8 CIST information. If MST BPDUs can be transmitted through the port, this BPDU will also convey new MSTI
9 information for all MSTIs. If a MSTI state machine sets newInfoMsti, and MST BPDUs can be transmitted through the
10 port, this machine will ensure that a BPDU is transmitted conveying information for the CIST and all MSTIs. Separate
newInfo and newInfoMsti variables are provided to avoid requiring useless transmission of a BPDU through a port that
11
can only transmit STP BPDUs (as required by the Force Protocol Version parameter or Port Protocol Migration
12 machine) following a change in MSTI information without any change to the CIST.
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

Copyright © 2008 IEEE. All rights reserved. 68

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 13.35 Port Information state machine

2
3
The Port Information state machine for each tree shall implement the function specified by the state diagram
4
contained in Figure 13-20 and the attendant definitions contained in 13.25 through 13.29.
5
6
rcvdMsg (!portEnabled && (infoIs != Disabled)) ||
7 BEGIN rcvdInfo == SuperiorDesignatedInfo
8
DISABLED SUPERIOR_DESIGNATED
9
infoInternal = rcvdInternal;
10 rcvdMsg = FALSE; agreed = proposing = FALSE;
recordProposal(); setTcFlags();
11 proposing = proposed = agree = agreed = FALSE;
agree = agree && betterorsameInfo(Received);
rcvdInfoWhile = 0;
12 infoIs = Disabled; reselect = TRUE; selected = FALSE; recordAgreement(); synced = synced && agreed;
recordPriority(); recordTimes();
13 updtRcvdInfoWhile();
portEnabled infoIs = Received; reselect = TRUE; selected = FALSE;
14 rcvdMsg = FALSE;

15 UCT
rcvdInfo == RepeatedDesignatedInfo
16
17 REPEATED_DESIGNATED
infoInternal = rcvdInternal;
18 recordProposal(); setTcFlags();
recordAgreement();
19 updtRcvdInfoWhile();
20 rcvdMsg = FALSE;
UCT
21 rcvdInfo == InferiorDesignatedInfo
22
INFERIOR_DESIGNATED
23 recordDispute();
24 rcvdMsg = FALSE;
AGED UCT
25 infoIs = Aged;
26 reselect = TRUE; selected = FALSE; rcvdInfo == InferiorRootAlternateInfo
(selected && updtInfo)
27 NOT DESIGNATED
28
recordAgreement(); setTcFlags();
29 UPDATE
rcvdMsg = FALSE;
proposing = proposed = FALSE;
30 agreed = agreed && betterorsameInfo(Mine); UCT
31 synced = synced && agreed; portPriority = designatedPriority; rcvdInfo == OtherInfo
portTimes = designatedTimes;
32 updtInfo = FALSE; infoIs = Mine; newInfoXst = TRUE;
OTHER
33 UCT rcvdMsg = FALSE
UCT
34 CURRENT
35
(selected && updtInfo) rcvdXstMsg && !updtXstInfo
36
37 (infoIs == Received) && (rcvdInfoWhile == 0) &&
RECEIVE

38 !updtInfo && !rcvdXstMsg

rcvdInfo = rcvInfo();
39 recordMastered();

40
41
42
43
44
45 Figure 13-20—Port Information state machine
46
47
48 This state machine is responsible for recording the spanning tree information currently in use by the CIST or
49 a given MSTI for a given port, ageing that information out if it was derived from an incoming BPDU, and
50 recording the origin of the information in the infoIs variable. The selected variable is cleared and reselect set
51 to signal to the Port Role Selection machine that port roles need to be recomputed. The infoIs and
52 portPriority variables from all ports are used in that computation and, together with portTimes, determine
53 new values of designatedPriority and designatedTimes. The selected variable is set by the Port Role
54 Selection machine once the computation is complete.

Copyright © 2008 IEEE. All rights reserved. 69

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 13.36 Port Role Selection state machine

2
3 The Port Role Selection state machine shall implement the function specified by the state diagram contained
4 in Figure 13-21 and the attendant definitions contained in 13.25 through 13.29.
5 BEGIN
6
INIT_TREE
7
8 updtRoleDisabledTree();
9
10 UCT

11 ROLE_SELECTION
12
clearReselectTree();
13 updtRolesTree();
14 setSelectedTree();

15 reselect1 || reselect2 || ... reselectN

16
17
Figure 13-21—Port Role Selection state machine
18
19
20 13.37 Port Role Transitions state machine
21
22
The Port Role Transitions state machine shall implement the function specified by the state diagram
23
contained in the following figures:
24
25
a) Part 1: Figure 13-22 for both the initialization of this state machine and the states associated with the
26
DisabledPort role; and
27
b) Part 2: Figure 13-23 for the states associated with the MasterPort role; and
28
c) Part 3: Figure 13-24 for the states associated with the RootPort role; and
29
d) Part 4: Figure 13-25 for the states associated with the DesignatedPort role; and
30
e) Part 5: Figure 13-26 for the states associated with the AlternatePort and BackupPort roles;
31
32
and the attendant definitions contained in 13.25 through 13.29.
33
34
As Figure 13-22, Figure 13-23, Figure 13-24, Figure 13-25, and Figure 13-26 are component parts of the
35
same state machine, the global transitions associated with these diagrams are possible exit transitions from
36
the states shown in any of the diagrams.
37
38
Figure 13-22 and Figure 13-26 show the Port Roles for ports that do not form part of the active topology of
39
the given tree.
40
41
Figure 13-23, Figure 13-24, and Figure 13-25 show the Port Roles that form part of the active topology.
42
43
44
45
46
47
48
49
50
51
52
53
54

Copyright © 2008 IEEE. All rights reserved. 70

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 BEGIN
2 ((selectedRole == DisabledPort) ||
INIT_PORT
3 role =DisabledPort;
&& (role != selectedRole)

4 learn= forward = FALSE;

synced = FALSE;
5 sync = reRoot = TRUE;
rrWhile = FwdDelay; All transtions, except UCT,
6 fdWhile = MaxAge; are qualified by:
"&& selected && !updtInfo".
7 rbWhile = 0;
UCT
8
9 DISABLE_PORT
10
11 role = selectedRole;
learn= forward = FALSE;
12
13 !learning &&
14 !forwarding

15
16
17
DISABLED_PORT
18
19 fdWhile = MaxAge;
synced = TRUE; rrWhile = 0;
20 sync = reRoot = FALSE;
21
(fdWhile != MaxAge) ||
22 sync || reRoot || !synced
23
24
Figure 13-22—Disabled Port role transitions
25
26 proposed && !agree (selectedRole == MasterPort) &&
27 (role != selectedRole)

28 MASTER_PROPOSED MASTER_FORWARD
29 setSyncTree(); forward = TRUE; fdWhile = 0;
(allSynced && !agree) || proposed = FALSE; agreed = sendRSTP;
30 (proposed && agree)
UCT UCT
31
32 MASTER_AGREED MASTER_LEARN
(!learning && !forwarding
&& !synced) || learn = TRUE;
33 (agreed && !synced) ||
proposed = sync = FALSE; fdWhile= forwardDelay;
agree = TRUE;
34 (operEdge && !synced) || UCT
(sync && synced)
35 UCT
MASTER_DISCARD
36 MASTER_SYNCED learn = forward = disputed = FALSE;
37 rrWhile = 0;
fdWhile= forwardDelay;

38 synced = TRUE; UCT

reRoot && sync = FALSE;
39 (rrWhile == 0)
UCT
40
41 MASTER_RETIRED

42 reRoot = FALSE;

43 UCT

44
MASTER_PORT
45
role = MasterPort;
46
((sync && !synced) || (reRoot && (rrWhile != 0)) || disputed) && !operEdge && (learn || forward)
47
((fdWhile == 0) || allSynced) && !learn
48 ((fdWhile == 0) || allSynced) && (learn && !forward)
49 All transitions, except UCT, are qualified by "&& selected && !updtInfo".
50
51 Figure 13-23—Port Role Transitions state machine—MasterPort
52
53
54

Copyright © 2008 IEEE. All rights reserved. 71

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 proposed && !agree

(selectedRole == RootPort) &&
(role !=selectedRole)
2
3 ROOT_PROPOSED ROOT_FORWARD
setSyncTree(); fdWhile = 0;
4 proposed = FALSE; forward = TRUE;
(allSynced && !agree) ||
5 (proposed && agree) UCT UCT

6
ROOT_AGREED ROOT_LEARN
7 proposed = sync = FALSE; fdWhile= forwardDelay;
8 agree = TRUE; learn = TRUE;
newInfoXst = TRUE; UCT
9 (agreed && !synced) ||
(sync && synced) UCT
10 REROOTED
11 ROOT_SYNCED
reRoot = FALSE;
synced = TRUE;
12 !forward && sync = FALSE; UCT
13 !reRoot UCT

14 REROOT
15 setReRootTree();
16
UCT
17
18 ROOT_PORT
role = RootPort;
19 rrWhile = FwdDelay;
20 rrWhile != FwdDelay
21 reRoot && forward
((fdWhile == 0) || (reRooted && (rbWhile == 0)) && (rstpVersion)) && !learn
22 ((fdWhile == 0) || (reRooted && (rbWhile == 0)) && (rstpVersion)) && learn && !forward
23 All transitions, except UCT, are qualified by "&& selected && !updtInfo".
24
25
Figure 13-24—Port Role Transitions state machine—RootPort
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

Copyright © 2008 IEEE. All rights reserved. 72

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1
2 (selectedRole == DesignatedPort)
&& (role != selectedRole)
3
4 DESIGNATED_FORWARD

5 forward = TRUE; fdWhile = 0;

!forward && !agreed && agreed = sendRSTP;
6 !proposing && !operEdge
UCT
7
DESIGNATED_PROPOSE DESIGNATED_LEARN
8
proposing = TRUE; learn = TRUE;
9 if (cist) { edgeDelayWhile = EdgeDelay; } fdWhile= forwardDelay;
10 allSynced && newInfoXst = TRUE; UCT
(proposed || !agree)
11 UCT
DESIGNATED_DISCARD
12 DESIGNATED_AGREED learn = forward = disputed = FALSE;
(!learning && !forwarding
13 && !synced) || proposed = sync = FALSE; fdWhile = forwardDelay;
14 (agreed && !synced) || agree = TRUE; UCT
(operEdge && !synced) || newInfoXst = TRUE;
15 (sync && synced)
UCT
16
17 DESIGNATED_SYNCED
rrWhile = 0; synced = TRUE;
18 reRoot && sync = FALSE;
19 (rrWhile == 0)
UCT
20
DESIGNATED_RETIRED
21
22 reRoot = FALSE;

23 UCT

24
DESIGNATED_PORT
25
role = DesignatedPort;
26
27 ((sync && !synced) || (reRoot && (rrWhile != 0)) || disputed) && !operEdge && (learn || forward)
((fdWhile == 0) || agreed || operEdge) && ((rrWhile ==0) || !reRoot) && !sync && !learn
28 ((fdWhile == 0) || agreed || operEdge) && ((rrWhile ==0) || !reRoot) && !sync && (learn && !forward)
29 All transitions, except UCT, are qualified by "&& selected && !updtInfo".
30
31 Figure 13-25—Port Role Transitions state machine—DesignatedPort
32
33
34
35
((selectedRole == AlternatePort) || (selectedRole == BackupPort))
36 && (role !=selectedRole)
37 proposed && !agree

38 ALTERNATE_PROPOSED BLOCK_PORT
39 setSyncTree(); role = selectedRole;
40 proposed = FALSE; learn = forward = FALSE;
(allSynced && !agree) ||
(proposed && agree) UCT !learning &&
41 !forwarding (rbWhile != 2*HelloTime) &&
42 (role == BackupPort)
ALTERNATE_AGREED
43 proposed = FALSE;
agree = TRUE; BACKUP_PORT
44 newInfoXst = TRUE; rbWhile = 2*HelloTime;
45 UCT UCT
46
47 ALTERNATE_PORT

48 fdWhile = forwardDelay; synced = TRUE; rrWhile = 0; sync = reRoot = FALSE;

49 (fdWhile != forwardDelay) || sync || reRoot || !synced

50
All transitions, except UCT, are qualified by "&& selected && !updtInfo".
51
52 Figure 13-26—Port Role Transitions state machine—AlternatePort and BackupPort
53
54

Copyright © 2008 IEEE. All rights reserved. 73

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 13.38 Port State Transition state machine

2
3 The Port State Transition state machine shall implement the function specified by the state diagram
4 contained in Figure 13-27 and the attendant definitions contained in 13.25 through 13.29.
5 BEGIN
6
7 DISCARDING
8 disableLearning(); learning = FALSE;
disableForwarding(); forwarding = FALSE;
9
learn
10
11 LEARNING
12 enableLearning(); learning = TRUE;
13
!learn
14 forward
15 FORWARDING
16 enableForwarding(); forwarding = TRUE;
17
!forward
18
19
20 Figure 13-27—Port State Transition state machine
21
22 NOTE—A small system-dependent delay may occur on each of the transitions shown in the referenced state machine.
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

Copyright © 2008 IEEE. All rights reserved. 74

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 13.39 Topology Change state machine

2
3 The Topology Change state machine for each tree shall implement the function specified by the state
4 diagram contained in Figure 13-28 and the attendant definitions contained in 13.25 through 13.29.
5
6 (role != RootPort) &&
(role != DesignatedPort) &&
7 (role != MasterPort) &&
rcvdTcn
8 !(learn || learning) &&
BEGIN
!(rcvdTc || rcvdTcn || rcvdTcAck || tcProp)
9 NOTIFIED_TCN

10 INACTIVE newTcWhile();
11 fdbFlush = TRUE; tcDetected = 0; UCT
tcWhile = 0; if (cist) tcAck = FALSE;
12 rcvdTc
learn && !fdbFlush
13
NOTIFIED_TC
14 LEARNING if (cist) rcvdTcn = FALSE;
15 if (cist) { rcvdTc = rcvdTcn = rcvdTcAck = FALSE; } rcvdTc = FALSE;
rcvdTc = tcProp = FALSE; if (cist && (role == DesignatedPort)) tcAck = TRUE;
16 setTcPropTree();
rcvdTc ||
17 rcvdTcn || UCT
18 rcvdTcAck || tcProp && !operEdge
tcProp
19
((role == RootPort) || PROPAGATING
20 (role == DesignatedPort) ||
(role == MasterPort)) && newTcWhile(); fdbFlush = TRUE;
21 forward && !operEdge tcProp = FALSE;
22 DETECTED UCT rcvdTcAck
23
newTcWhile(); setTcPropTree();
24 newTcDetected(); newInfoXst = TRUE;
ACKNOWLEDGED

25 tcWhile = 0; rcvdTcAck = FALSE;

UCT
26 UCT
27
ACTIVE
28
29
30 ((role != RootPort) && (role != DesignatedPort) && (role != MasterPort)) || operEdge

31
32 Figure 13-28—Topology Change state machine
33
34 NOTE—MRP (Clause 10) uses the tcDetected variable maintained by this state machine.
35
36
37 13.40 L2 Gateway Port Receive state machine
38
39 If implemented, the L2 Gateway Port state machine for each port shall implement the function specified by
40 the state diagram contained in Figure 13-29 and the attendant definitions contained in 13.25 through 13.29.
41 When activated, by setting isL2gp, it simulates continuous reception of BPDU carrying a spanning tree
42 priority vector based on a configured pseudoRootID (13.27.36). As a result, an L2 Gateway Port that
43 provides connectivity to a given service instance (3.117, 3.7) can only play one of two different roles:
44
45 a) If the information is the best in the instance, the Layer Two Gateway Port is elected root port and
46 will be in forwarding state; <<This is just utterly and completely wrong. It’s backwards. If the
47 information is better than any on the attached customer network the L2GP will be elected Rot Port
48 and will be Forwarding.>>
49 b) Else, the port will have its disputed flag set and will remain in designated role discarding state.
50
51 A maximum of one Layer Two Gateway Port can thus be forwarding at a given time, provided its pseudo
52 information is the best information advertised in the instance. A bridged network can be redundantly
53 attached to a Provider Backbone Bridged Network (PBBN) (Clause 26) by the means of several Layer Two
54 Gateway Ports. By way of communication within their region and without any influence from the PBBN,

Copyright © 2008 IEEE. All rights reserved. 75

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 those ports will provide connectivity to the PBBN through a single Layer Two Gateway Port, thus avoiding
2 any bridging loop between the PBBN and the instance.
3
4 Proper configuration of a Layer Two Gateway Port requires setting the isL2gp and clearing the
5 enableBPDUtx on that port. The variable enableBPDUrx for the port can be cleared on the port to provide
6 complete independence from the information received from the PBBN. Else, the state machine ensures that
7 the CIST information received is inferior to the pseudo information the Layer Two Gateway Port presents to
8 itself on the CIST, and will block all instances (CIST and MSTIs) otherwise. This mechanism will prevent a
9 misconfiguration from introducing a loop in the instance, but adds a dependency to the information
10 circulating outside of the region.
11
12 BEGIN || !isL2gp || !portEnabled
13
14
INIT
15
pseudoInfoHelloWhen = 0;
16
17 UCT

18 PSEUDO_RECEIVE
19 preparePseudoInfo(); rcvdRSTP = rcvdInternal = TRUE; rcvdSTP = FALSE;
20 setRcvdMsgs(); edgeDelayWhile = MigrateTime;
pseudoInfoHelloWhen = HelloTime;
21 UCT
22
23 CHECK
L2gpReceiveCheck();
24 rcvdBpdu = False;
25 UCT
26
DISCARD
27
rcvdBpdu = False;
28
29 UCT

30 L2GP
31
32 Mick : Updated 08OCT08 !enableBPDUrx && rcvdBpdu && !rcvdAnyMsg
enableBPDUrx && rcvdBpdu && !rcvdAnyMsg
33 (pseudoInfoHelloWhen ==0) && !rcvdAnyMsg
34
35 Figure 13-29—L2 Gateway Port Receive state machine
36
37
38 13.41 Customer Edge Port Spanning Tree operation
39
40
41 This subclause specifies the operation of the Spanning Tree Protocol Entity within a C-VLAN component
42 that supports a Customer Edge Port (Figure 15-4) of a Provider Edge Bridge. The Customer Edge Port and
43 each Provider Edge Port are treated as separate Bridge Ports by the spanning tree protocol.
44
45 If the C-VLAN component connects to the S-VLAN component with a single Provider Edge Port, and the
46 associated service instance supports no more than two customer interfaces, then all frames (including
47 Spanning Tree BPDUs) addressed to the Bridge Group Address may be relayed between the two ports of the
48 C-VLAN component without modification. Otherwise, the Spanning Tree Protocol Entity shall execute
49 RSTP, as modified by the provisions of this clause (13.41).
50
51 The RSTP enhancements specified do not reduce Provider Bridged Network connectivity between Customer
52 Edge Ports to a single spanning tree of service instances but ensure that connectivity for frames assigned to
53 any given C-VLAN is loop free. In this respect, the C-VLAN component’s spanning tree protocol operation
54 is equivalent to, but simpler to manage than, the operation of MSTP.

Copyright © 2008 IEEE. All rights reserved. 76

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 13.41.1 Provider Edge Port operPointToPointMAC and operEdge

2
3 The value of the adminPointToPointMAC parameter for a Provider Edge Port is always Auto, and no
4 management control over its setting is provided. The value of the operPointToPointMAC parameter, used by
5 the RSTP state machines, shall be true if the service instance corresponding to the Provider Edge Port
6 connects at most two customer interfaces, and false otherwise.
7
8 The value of the adminEdge, autoEdge, and operEdge parameters for a Provider Edge Port are always false,
9 true, and false, respectively. No management control over their setting is provided.
10
11
12 13.41.2 updtRolesTree()
13
14 The spanning tree priority vectors and timer values are calculated as specified for the updtRolesTree()
15 procedure in IEEE Std 802.1D. The port role for each port, its port priority vector, and timer information are
16 also updated as specified by IEEE Std 802.1D, with one exception. If selectedRole was to be set to
17 AlternatePort, the port is an Provider Edge Port, and the root priority vector was derived from another
18 Provider Edge Port, then the selectedRole shall be set to Root Port.
19
20 NOTE—The effect of this enhancement is to allow the C-VLAN component to have multiple Root Ports (just as if
21 separate per S-VLAN trees were being provided), if they are all Provider Edge Ports. As the C-VLAN component
22 assigns each frame to a single C-VLAN and maps any given C-VLAN to and from at most one Provider Edge Port, no
loop is created.
23
24
13.41.3 setReRootTree(), setSyncTree(), setTcPropTree()
25
26
27 IEEE Std 802.1D specifies that the setReRootTree() and setSyncTree() procedures set the reRoot and sync
28 variables for all ports of the bridge, and the setTcPropTree() sets the tcProp variable for all ports other than
29 the port that invoked the procedure. If the port invoking the procedure is a Customer Edge Port, then this
30 behavior is unchanged; if it is a Provider Edge Port, then the behavior of each procedure shall be as follows.
31
32 The setReRootTree() procedure sets reRoot for the port invoking the procedure and for the Customer Edge
33 Port.
34
35 The setSyncTree() procedure sets sync for the port invoking the procedure and for the Customer Edge Port.
36
37 The setTcPropTree() procedure sets tcProp for the Customer Edge Port.
38
39
13.41.4 allSynced, reRooted
40
41
42 RSTP specifies a single value of the allSynced and reRooted state machine conditions for all Bridge Ports.
43 This specification requires an independent value of each of these conditions for each port of the C-VLAN
44 component. If that port is the Customer Edge Port, then allSynced shall be true if and only if synced is true
45 for all Provider Edge Ports, and reRooted shall be true if and only if rrWhile is zero for all Provider Edge
46 Ports. If the port for which the condition is being evaluated is a Provider Edge Port, then allSynced shall take
47 the value of synced for the Customer Edge Port, and reRooted shall be true if and only if rrWhile is zero for
48 the Customer Edge Port.
49
50 13.41.5 Configuration parameters
51
52 All configuration parameters for RSTP should be set to their recommended defaults, with the exception of
53 the following, which are chosen to minimize the chance of interfering with the customer’s configuration
54 (e.g., by the C-VLAN component becoming the root of the customer spanning tree), as follows:

Copyright © 2008 IEEE. All rights reserved. 77

This is an unapproved IEEE Standards Draft, subject to change.
 Supplement to Virtual Bridged Local Area Networks: Shortest Path Bridging P802.1aq/D1.0+suggested changes
November 4, 2008

1 c) The Bridge Priority (13.18, Table 13-3, 13.26.1) should be set to 61 440. This sets the priority part of
2 the Bridge Identifier (the most significant 4 bits) to hex F.
3 d) The following 12 bits (the Bridge Identifier system ID extension) should be set to hex FFF.
4 e) The Port Priority (13.18, Table 13-3, 13.27.32) should be set to 32. This sets the priority part of the
5 Port Identifier (the most significant 4 bits) to hex 2, a higher priority than the default (128, or hex 8).
6 f) The Port Path Cost values for Provider Edge Ports should be set are to 128.
7
8 All BPDUs generated by the Spanning Tree Protocol Entity within a C-VLAN component use the MAC
9 address of the Customer Edge Port as a source address. For each internal Provider Edge Port, the protocol
10 uses the S-VID associated with the corresponding internal Customer Network Port on the S-VLAN
11 component as a port number. For the Customer Edge Port, the value 0xFFF is used as the port number.
12
13
14
13.42 Virtual Instance Port Spanning Tree operation
15
16 This subclause specifies the operation of the Spanning Tree Protocol Entity within an I-component in a
17 Backbone Edge Bridge. The Customer Network Ports (CNP) and Virtual Instance Ports (VIP) are treated as
18 separate Bridge Ports by the spanning tree protocol.
19
20 If the I-component has a single CNP and a single VIP supported by a point-to-point backbone service
21 instance, then all frames (including Spanning Tree BPDUs) addressed to the Bridge Group address may be
22 relayed between the two ports of the I-component without modification. Otherwise, the Spanning Tree
23 Protocol Entity shall execute RSTP, as modified by the provisions of this subclause.
24
25 The RSTP enhancements specified ensure that connectivity for frames assigned to any given S-VLAN is
26 loop free.
27
28 The parameters and functions of the RSTP protocol used on the VIPs get the same values and functionality
29 as defined for Provider Edge Ports of a C-VLAN component as defined in 13.41. The Bridge Identifier
30 Priority and system ID extension get the values specified in 13.41.5. These changes in the RSTP protocol
31 ensure that no VIP is blocked due to the operation of the RSTP protocol and the I-component will never be
32 elected as root.
33
NOTE—The effect of not blocking any VIP in the I-component (never set the port role alternate to a VIP) will not cause
34 a loop since the I-component maps any given S-VID to at most one VIP.
35
36
37 13.43 L2 Gateway Ports
38
39 <<place-holder, to be consistent with the other state machines the general description of L2GP should move
here, just leaving the L2GPRX machine where it is>>
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

Copyright © 2008 IEEE. All rights reserved. 78

This is an unapproved IEEE Standards Draft, subject to change.