G.8032
Last updated
Last updated
G.8032 is an ITU-T standard for loop prevention in simple ring topologies. A fully closed ring is a collection of devices which have exactly two connections in the topology: an east interface and a west interface. This of course forms a loop, for which STP would traditionally be used to block a port. However, even RSTP convergence is not fast enough for service provider access networks. G.8032 gives you about 50msec convergence time.
In G.8032, you manually specify which link you want blocked under normal conditions. This link is called the RPL (ring protection link). One device on this link is designated as the RPL owner. This device sends R-APS (Ring-Automation Protection Switching) messages every few seconds indicating that no changes have occured. The device on the other end of the link is optionally designated as the RPL neighbor, which would also block the port.
At its most basic level, G.8032 is simply a technology which turns on/off the RPL port. If a link fails anywhere in the ring, the RPL owner is alerted to turn the RPL port on. A switch does this using an R-APS SF (Signal Failure) message. When a link comes back up, by default G.8032 operates in revertive mode. A count down timer starts, and once the timer expires, the RPL owner turns its port back off. The switch then unblocks the port that previously had failed.
G.8032 must use CFM for fast convergence. CFM runs on each link individually, as if each link is a separate CFM domain. Each device must have a unique MPID. CFM can be tuned as low as 3.3msec to provide very fast convergence.
G.8032 can also use open rings, which are rings that connect to a closed ring. For example, in the diagram below, there is a full ring and an open ring below it. A port in the open ring must still be blocked, because node 3-4-5, although in a different ring, end up closing the open ring.
When a link fails in the ring, a holdoff timer runs to handle link flaps. By default this timer is 0. Once the timer expires, an R-APS SF message is sent by each switch that detects the link failure (two devices will detect a single link failure). All devices, upon generating/receiving the SF message will flush their MAC tables. When the RPL owner receives the SF message, it unblocks its RPL. The devices continue generating SF messages, but now they don’t trigger any further action.
Once the link comes back up, the devices detecting this start a guard timer and generate R-APS NR (no request) messages. The guard timer prevents reception of any R-APS, and by default is 500ms. It might be helpful to consider the NR message as “I’m not requesting you to unblock the port anymore.” The RPL owner receives this and starts a WTR (wait to restore) timer, which prevents constant topology changes if a link flaps. This timer is by default 5 minutes. Meanwhile, the guard timer expires on the two nodes that sent the NR message. They receive the NR message over the previously-failed link. Whichever node has a higher ID unblocks the port, but the lower ID continues with the block. Once the WTR timer expires, the RPL owner blocks its RPL and sends its own R-APS NR message. This prompts a MAC flush on all devices. When the node with the lower ID connected to the previously-failed link receives this, it removes the block on the port and stops sending R-APS NR messages. The RPL neighbor blocks its port in response to this message as well.
As an operator, you can also forcefully block a ring port to force a topology change. This is called a FS (force switch). You can also do a manual switch (MS) which will not work if there is already an existing FS or SF condition in the ring. If you do either of these operations, a WTB (wait to block) timer runs before performing the block. However, the config guide doesn’t show how to actually perform this action.
G.8032 can only handle at most one link failure. If a second link fails, the ring will be partitioned.
G.8032 can run different instances for a set of data VLANs. This allows you to load balance on a per-VLAN basis, similar to MST.
To configure G.8032, you must first configure CFM. G.8032 is configured as a registered client of CFM.
Next, a g8032 ring profile is created. The ring is defined, and associated with exactly two ports (if a closed ring), or exactly one port on two devices in an open ring. An instance defines the RPL port and which data vlans are used. A separate VLAN is used as the APS channel for R-APS messages.
Typically the same service instance used for CFM would be used for both the monitor service config and the aps-channel. I’m not clear whether you would need separate EFPs for multiple instances, one EFP for each instance?
