A Bridge Group Address is a universal address, 01-80-C2-00-00-00, and is used as a MAC destination address to carry BPDUs between STP entities. IEEE802.3 frames are used for carrying BPDU frames (Figure B2.1), that is the LLC sublayer and header are used. The address of STP in the LLC layer is 01000010, and BPDU is encapsu-lated in the information fi eld of the Unnumbered Information (UI) LLC command PDU. The BPDU contains a Protocol identifi er, PID, to distinguish BPDU from GARP PDU or other, unsupported protocols.
The fi elds of the BPDU are divided into three parts: the fi rst part identifi es the protocol, the BPDU, and its roles. The second part is the priority vector described in the preceding subsection. The last part of the BPDU is a group of fi elds that are related to the STP and RSTP mechanism, as described in the following.
Appendix B: Spanning Tree Protocols 75
Rapid STP communicates the port role and state in the fl ags fi eld of the RSTP BPDU. These were not communicated in the STP, and they are helpful for faster spanning tree reconfi guration.
The BPDU contains several timer values that are required by the STP and RSTP protocol, such as the “Message Age,” “Max Age,” “Hello Time,” and “Forward Delay.”
These fi elds are fi lled by default values (usually in seconds) and by bridges, accord-ing to the ongoaccord-ing protocol status.
In STP, the RB sends CM BPDU every “Hello Time” with zeroed “Message Age,”
and triggers CM BPDU messages in the bridged LAN. Any bridge that does not receive a CM within the “Max Age” assumes that the RB is dead, declares itself RB, and start transmitting CMs around until the bridged LAN reaches stabilization again. In RSTP, on the other hand, every bridge sends RSTP BPDUs as “keep-alive”
messages, and an adjacent neighbor bridge is considered disconnected after three
“Hello Time” if no RSTP BPDU was received.
When a BPDU is relayed (informing other bridges through the designated ports about a better RB received by the bridge), the “Message Age” increases (usually by 1 s), and the BPDU is treated only if the “Message Age” is less than the “Max Age”
of the BPDU. This ensures the decay of the BPDU in a nonstabilized spanning tree.
Bridges not only relay received BPDUs from their RP to all their DPs, but they also reply to a received BPDU in any of their DPs, with their own BPDU, causing the other bridges connected to the DPs to potentially update their ports’ roles and states. Any transition to forward state occurs only after the bridge waits for the
“Forward Delay” to avoid too-rapid changes that may lead to intermediate loops.
In STP, Topology Change Notifi cation (TCN) BPDUs (Figure B2.2) are sent by the bridges that sense a topology change, toward the root bridge (RB). The RB acknowl-edges the TCN BPDU, and informs all other bridges of the topology change. Follow-ing a topology change, all CM BPDUs sent from the RB will be fl agged by a Topology Change fl ag in the CM BPDUs, for a duration of “Forward Delay” plus “Max Age.”
PID
= 0 Protocol Version BPDU Type Flags
Root Identifier (8 bytes)
Root Path Cost (4 bytes)
Bridge Identifier (8 bytes)
Port Identifier Message Age Max Age Hello Time Forward Delay
Protocol Version ID = 0 (STP), 2 (RSTP) BPDU Type = 0 (STP BPDU), 2 (RSTP BPDU)
Version 1 length (only in RSTP BPDU) = 0
Version 1 Length
Flags bit 8 = topology acknowledgment, bit 1 = topology change, bit 2 = proposal (in RSTP), bit 3–4 = port role (in RSTP, 0-unknown, 1-alternate or backup, 2-root, 3-designated), bit 5 = learning (in RSTP), bit 6 = forwarding (in RSTP), bit 7 = agreement (in RSTP) FIGURE B2.1
STP and RSTP BPDU (from left to right)
In RSTP, every bridge that senses a topology change sends a RSTP BPDU and sets the Topology Change fl ag. Every bridge that receives a RSTP BPDU with the Topology Change fl ag set, forwards this RSTP BPDU.
Lastly, an RSTP port handshake (described previously) for deciding on ports’
roles locally is done by using the RSTP BDPU fl ags bits of “proposal” and “agree-ment” (bits 2 and 7, respectively). In STP, when a port becomes a designated port (DP), it has to wait twice the “Forward Delay,” to shift to a forwarding state (usually about 30 seconds). In RSTP, it simply sends a proposal RSTP BPDU, and the receiv-ing bridge sets its port to a root port (RP) and sends an agreement RSTP BPDU.
PID
= 0
Protocol Version BPDU Type=128 Flags
Protocol Version ID = 0 FIGURE B2.2
Topology change notifi cation BPDU
CHAPTER
3
In the previous chapter we described basic networking, which includes everything from concepts to data networks (e.g., Ethernet and Internet Protocol networks) and telecommunications networks (e.g., PDH and SDH/ONET networks).
This chapter focuses on converged networks. In these networks, data and telecommunications applications interface and mix, despite their very different natures. Data networks are bursty, and oriented toward connectionless traffi c, whereas telecommunications networks are streamed, and connection-oriented.
We divide this chapter into two parts, each of which corresponds to a particular path of evolution: the fi rst, from telecom networks to converged networks, and the second from data networks to converged networks.
We briefl y describe a legacy networking technology called Asynchronous Transfer Mode (ATM), which was used for about a decade in the 1990s as a solution for mixed data, video, and telephony network. We deal with ATM since, fi rst of all, ATM is still with us—and in several places even dominates networking implementations—but more importantly, because ATM has had a signifi cant impact on networking algorithms, standards, and development. The most important technology that absorbed ATM ideas is the Multiprotocol Label Switching (MPLS), which is also described in this chapter.
Metro technologies and Next Generation SONET/SDH technologies are then described, as they seem to be the main transport backbone networks of the future (at least in the view of the telecom industry). Metro technologies as well as IP and Ethernet evolutions are then described, as they seem to be the main information backbone of the future (at least in the view of the datacom industry).
In the next chapter we describe access and home networks. These networks also use converged technologies, and connect customers and their devices to the long-haul networks.
3.1 INTRODUCTION
After describing network fundamentals, models, and pure telecom networks and data (enterprise) networks, we turn to converged networks; that is, data networks that