Advanced protection switching (APS) has always been the feather in the cap of a Sonet/SDH network. Through this switching capability, Sonet/SDH operators and equipment developers can ensure that circuits can quickly flip to a protection channel when a working channel fails.
Sonet/SDH protection has traditionally been one of the main ingredients in ensuring five-nines (99.999%) reliability on today's service-provider networks. But now, protection switching is being asked to take the next step and also protect valuable data traffic as it transverses the network.
In order to minimize the disruption of customer traffic, SONET/SDH standards have defined strict switch completion times. For smaller systems, the processing bandwidth required to meet these standard limits is modest. However, for larger systems, such as those terminating a number of dense wave division multiplexed (DWDM) fibers, a single fiber-cut can result in thousands of customer data streams switching to their protection path. The required burst of processing bandwidth can overwhelm even the most powerful of microprocessors.
Designers can solve these processing bandwidth concerns by tapping into unused Sonet/SDH transport overhead byte positions. By using these byte positions, designers can collapse the traditional control plane into the data plane and, in turn, reduce overall system complexity. Let's see how this can be accomplished.
Existing Protection Implementations
Current protection switching implementations tend to be heavily based on software and thus have speed limitations. For example, in Figure 1, the framer monitors the source fiber for alarms and defects (such as high bit error rates [BERs]). When an error is detected, an interrupt is generated and the companion microprocessor located on the line card with the framer retrieves this status and reports to the central processor that controls the central switch fabric.
Click here for Figure 1
Figure 1: In a traditional ADM, such as the one displayed here, the Sonet/SDH framer device on the line card reports status and error conditions to the co-located processor.
The channel between the line cards and the switch fabric is usually a standard processor channel, such as Ethernet, with a software-oriented protocol. At the switch fabric, another microprocessor terminates the communications channel from all the line cards.
In a large system, the number of line cards can impose a heavy processing burden and a high bandwidth requirement on the communications channel. After all the status reports have been processed, the microprocessor downloads a new configuration setting into the switch fabric to complete the APS action. Clearly, with so much of the processing done in software, the maximum speed at which protection-switching actions can occur will be severely limited.
Further compounding the problem, nodes on the Sonet/SDH network are expected to terminate a large number of fibers without imposing restrictions on the combination of protection-switching architectures employed. Some fibers might be part of a Sonet/SDH ring, while others part of a 1:N linear APS system. Traffic on the fibers may be cross-connected to other fibers or terminated onto local access modules. With these added next-generation requirements, protection operations will be insufficiently supported with this control model.
Evolving Protection Implementations
A step towards making the protection operations simpler is to implement the communication between the line card and a central processing point with messages carried in the data links. Serial system links connecting traffic flows from the framer devices to the cross-connect devices of the fabric have free bandwidth in the form of unused overhead bytes. Messages coded with the same status and error condition content traditionally conveyed over the control plane can be efficiently communicated and centrally collected at the fabric using overhead bytes on the system links. This is referred to as data plane message protection switching and, for convenience of distinction, we will call a system using the traditional control plane to collect status as control plane protection switching.
Within the network element, the Sonet transport overhead/SDH section overhead bytes (3 columns of 9 bytes for each STS-1 and 9 columns of 9 bytes for each STM-1) do not need to have the same assigned standards-defined functionality of the optical links. They can be used to carry protection switching status messages. The numerous unused TOH/SOH bytes make good candidates.
It is desirable for all the STS-1 streams within the ingress flow use the same byte. This limits the byte location possibilities to positions that have undefined functions in the master STS-1 as well as all of the other STS-1 of the flow. In cases of a byte use conflict, tactics such as mapping the ingress byte to a new carry position and returning it to its original position at the egress framer, or terminating it from the carry position at central overhead processing can be used. Two reasonable choices result: the B2 byte locations and the J0/Z0 byte locations.
A B2 location is available in each STS-1 and, in many systems, is not used within the network element. Therefore, the B2 location is unused bandwidth between the framer and the fabric. The J0/Z0 position can be used with remapping of the ingress J0 bytes, or when the J0 is terminated on the line card.
Additional functionality may be chosen to occupy further unused bytes of the within-system transport overhead beyond the functions of protection and restoration. For example, there is sufficient bandwidth within the unused and undefined bytes of the transport overhead to support Ethernet control channels.
As with control plane protection switching, the framer device in a message-enabled system monitors and reports on standards defined alarms and defects. Ideally, the framer is programmable, generating a message appropriate to the condition of the optical interface and contained paths such that the protection subsystem can easily identify the relative status of protection-paired paths or rings. In this case, processor intervention or supervision is not required. Alternatively, the framer needs only to support access to the system-side overhead such that the local processor can retrieve the relevant status, generate and format the message, and insert the message in the overhead bound for the fabric.
The protection status message content can be relatively simple; if attached to each STS-1/AU-3, only the status is required in the message. Each STS-1/AU-3 from the same interface and the same path would be programmed with an identical message for each STS-1 within the same ingress fiber since their status would be the same. The message can be as simple as a byte that indicates the status with a severity value between 0 and 255, where a higher value represents a worse condition.
For example, a signal fail condition (SF) would result in a higher value being programmed into the message than a degrade condition due to a bit error ratio (BER) of 10-8. A path indicating a code equivalent to SF may initiate a switch response to a protection-paired path indicating a BER of 10-8.
Once the messages have been generated, they are transported over the data links to the fabric component for termination and interpretation. Extracting the messages at the fabric is advantageous, since it is the central point for all traffic. The fabric then presents these messages to the central protection engine. Supporting this access is key to next generation architectures.
Making Protection Decisions
The protection decision-making function can be implemented either in hardware using an FPGA or in software using a processor. An FPGA solution is desirable because it can provide potentially higher capability. Therefore, it is an underlying assumption in the following discussion. The FPGA performs the protection-switching role without software interaction and without real-time requirements on software. The goal is to make protection switching deterministic and scalable. The basic decision-making steps the FPGA must perform on the extracted messages follows.
Pre-provisioning of the system identifies which paths or rings are protection associated. This would include 1:N and mesh architectures, as well as paired linear and ring protection schemes.
The messages from protection-associated paths are compared, with the lowest value representing the path of best condition. Included in this comparison function may be filtering of the incoming messages to support switching decision hysteresis and to increase stability of the switching decisions. Care must be taken to consider the system as it is connected when defining the sensitivity of a switch decision (for instance "wait-to-respond" parameters) since two elements should not react to the same condition simultaneously.
Once the change in traffic source has been determined and a protection event is required, the protection subsystem makes the appropriate changes to the connection memory of the cross-connect devices. This is easier to accomplish in a single-stage fabric. Here's why.
Multi-stage fabric systems often require rearrangement to accomplish the new traffic selection. This rearrangement incurs a time penalty of completing a connection setting algorithm for each affected STS and this computation becomes excessive and performance limiting when many paths fail simultaneously. The single-stage switch, on the other hand, has no requirements for rearranging of paths and each path through the fabric is independent from a switch resource perspective. Thus, to develop a fully deterministic protection switch, designers need to employ a single-stage fabric in their system design.
To produce a message-enabled system, the fabric must support transport overhead access to extract the message. For ring protection schemes, the traffic headend must bridge traffic as coordinated through the K-bytes of the APS channel. A more capable system would also require K1 and K2 byte extraction and re-insertion abilities. This K-byte interaction may also be implemented in hardware to further reduce the burden on software resources.
Figure 2 shows the path of a message that is generated by a Sonet/SDH framer when it detects one or more alarms. These alarms and defect status contribute to the G2i message (byte) according to user programming. The message created by the framer and carried in G2i is a programmable single-byte value, based on any alarm or defect. The position of the G2i message in the system side transport overhead is also programmable.
Click here for Figure 2
Figure 2: Example of data plane message protection switching
The G2i message and any other bytes are extracted for all links by a switching device and processed by an FPGA. The values in the G2i message are simply compared for each of the provisioned protection paths and the best path is chosen. This decision results in a possible change to the connection memory of the switch, which is communicated through the microprocessor access port (register control). K1 and K2 bytes are also shown being extracted for protection mechanisms in which headend bridging is required.
Next generation Sonet/SDH transport devices require the development of system-aware features that allow ADM and grooming equipment to be more flexible, scalable and more cost-effective. For cross-connect elements, transport overhead access (both extraction and insertion) provides the needed capability to enhance protection and restoration services. Using single-stage fabrics further enhances these advantages and supports protection-switching implementations for both linear and ring protection architectures.
Framer features such as message generation enable high levels of protection switching integration. Through integration, devices can provide a full view of the attached line and path, and synthesize a prioritized message without processor assistance. This will significantly reduce line-card processing requirements and the associated cost of communicating this status to the protection decision-making device.
About the Author
Eric Eden is senior product manager in PMC-Sierra's Service Provider Division. He graduated with a Bachelor of Science degree in electrical engineering from the University of Waterloo in 1993 and can be reached at email@example.com.