RPR Soups Up Sonet and Ethernet: Page 2 of 5

Including RPR on an Ethernet network is slightly different and may require a new network on top of the existing Ethernet. RPR rides on Ethernet's Layer 1 and can encapsulate Ethernet frames within an RPR frame. However, most Ethernet devices expect Ethernet to be the Layer 1 and the Layer 2 protocol of the frame, and won't carry RPR. Instead, the RPR equipment must be the core of the network, with Ethernet devices feeding in to or out of the RPR network.

Because RPR is a Layer 2 protocol, it defines a new MAC (Media Access Control) format into which data packets are placed (see chart "The RPR Header"). The RPR MAC header comprises 24 bytes. The first two bytes are for the ring control field, which is divided into seven subfields: TTL (time to live), P (parity), WE (wrap eligible), FT (frame type), FE (fairness eligible), RI (ring ID) and SC (service class). Service class determines the packet's priority on the network, while frame type determines whether the frame contains user data, fairness requests or control data for other nodes. Control frames contain node changes and other data. RPR supports network device and node autodiscovery; new network nodes announce themselves to their direct neighbors with control messages and distribute changes in their settings or topologies.

The next two fields are six bytes each and contain 48-bit destination and source addresses. These are hardware addresses as defined in section 5.2 of IEEE Std 802-1990. The Extended Ring Control takes up the next two bytes. The first eight bits contain the TTL Base. This is the original value of the TTL and is not decremented. The last byte contains the EF (extended frame), FF (flooding form), PS (past source), SO (strict order) and three reserved bits at the end, which should be 0s.

The EF field indicates whether the frame is a Base Data Frame or an Extended Data Frame. The Base Data Frame is used by all data traffic that travels from start to finish on the same ring. If data needs to travel from one ring to another to get to its destination, an Extended Data Frame, which includes the original source address and final destination address after the HEC (header error check), is used. The FF bits indicate whether data is flooded unidirectionally, bidirectionally or not at all. The PS bit is used during a wrap function to indicate the frame has traveled past the source address on its way back to the destination. SO is used when frames need to be kept in order.

The next two bytes contain the HEC, or header CRC (cyclical redundancy check). The protocol field takes up two bytes. When the value of the field is less than 1,535, the field indicates the length of the frame. If the value is equal to or greater than 1,536, it indicates the MAC client protocol. This value is designated by the IEEE Type Field Register. The protocol bytes determine type or length, never both. Finally, after the actual payload, a four-byte FCS (frame check sequence) is placed at the end.

Like Sonet, RPR operates within rings. But RPR differs from Sonet in how traffic is placed onto the rings. In most Sonet setups, traffic flows in only one direction around the ring; RPR lets traffic be provisioned in both directions, thereby doubling the amount of traffic that can traverse the rings. Data is taken off the ring at its destination, which keeps the maximum amount of bandwidth between nodes available at all times. Some ring topologies, such as FDDI, keep data on the ring until it returns to the source, where it's finally removed. This would be a huge waste of bandwidth if the destination is nearby because the data would pass the destination and make its way all around the loop to be taken off the ring by the source node. (For a better understanding of Sonet and ring networks, see "Going Toward the Light," and "Sonet From Scratch.")