POS-PHY Level 3: Enabling High-Speed Networking Applications

The call is out for a jack-of-all-trades that will be able to handle the sheer variety of services such as ATM, packet over SONET/SDH (POS), Frame Relay, and Gigabit Ethernet. The POS-PHY Level 3 interface is a robust, nonblocking interface that is flexible enough to answer that call.

The unrelenting demand for Internet-based services is driving network equipment designers to develop an array of new switch and router port cards to support multiservice traffic and aggregate bandwidths up to OC-48 (2.488 Gbps) and beyond. These new products must support the existing frame relay and ATM infrastructure as well as emerging traffic types such as POS and Gigabit Ethernet. Building next-generation multiservice switches and routers possessing these attributes requires a protocol agnostic physical to data link layer interface such as POS-PHY Level 3 (PL3). ¹ The PL3 chip-to-chip interface has received substantial industry backing from the SATURN development group and semiconductor and equipment vendors, as it provides a robust and efficient means to connect a variety of different physical layer devices to data link layer devices using a single common PL3 bus (see Figure 1 ). ² A more detailed technical description of the PL3 interface is presented in the sidebar .

When networkers and carriers became interested in creating systems capable of supporting mixed-media traffic at OC-48 line rates, the SATURN development group realized the need to define an interface capable of interconnecting a variety of cell and packet-based media-processing devices. During the development of this agnostic interface, it became apparent that simply frame-extending the UTOPIA-style interface to provide robust multiservice support was not satisfactory. A novel approach would be required to create an interface flexible enough to support both ATM cells and packets. The SATURN development group spent considerable time and effort in developing the current PL3 interface bus specification.

First-generation PBX systems lacked scaleability, forcing customers to conduct expensive forklift upgrades. This led to new system design attributes like standard OSes (Windows NT), client/server control, mixed-media switching (circuit ATM and IP), and diversified desktop transmissions (analog, digital, and IP). Today’s PBXs are designed for voice traffic and are not equipped to handle data, video, and image traffic. In adopting IP, PBX designers are forced to deal with performance problems caused by process-intensive protocols (H.323) that touch and shape the media. OEMs have addressed these problem areas by offering patchwork solutions, a stop-gap strategy until the next-generation designs are available.

Previously, proprietary-based legacy PBX systems utilized voice and control buses to process the call traffic. But with the advent of the PC and a little help from industry standards like H.100/110, CompactPCI (CPCI), the Ether-net, hot swap, and software like Windows NT, OEMs are migrating from proprietary to open systems. PBX equipment once designed using proprietary components, architectures, and software is now designed using standard, off-the-shelf PC technology adapted for the high reliability requirements of today’s telephone infrastructure. OEMs can begin to focus more of their efforts on developing the next generation of applications instead of worrying about integrating closed-system architecture from various manufacturers.

When designing a system’s PHY link layer interface to support multiple services, three key factors must be considered. First, the interface must be able to transfer both packets and cells (ATM) to support a variety of multiservice port cards. Second, the simpler the PHY-link layer protocol, the less problematic it will be to interface the system’s physical and link layer devices. Finally, widespread vendor support and standardization is important. The PL3 interface addresses all of these design requirements.

PL3 can be used to design an agnostic interface to carry both packets and cells, or it can be used to develop separate packet or cell cards. As a result, the PL3 interface offers system developers a common line-card interface that yields considerable time-to-market and design reuse advantages. For example, if a first-generation switch only supports ATM (or only packets), the design can be easily iterated to provide multiservice capability, since the same PL3 interface can be used for packet, ATM, or mixed traffic. The PL3 interface can be viewed as a superset of UL3 in its ability to agnostically accommodate both ATM and packet traffic. Since UL3 does not define how to manage the transfer of variable-length packets, use of the PL3 interface is a necessity in these types of systems.

The transmit interface for PL3 can support both cells and packets. It is similar to UL3 in operation with the exception that PL3 employs a port address prepend that is inserted in the dead cycle used by UL3 to implement PHY selection. The timing diagram in Figure 2 illustrates the dual-mode PL3/ UL3 transmit support feature. The receive PL3 interface can be thought of as a UL3 interface with the polling/selection state machine disabled and replaced by a port address prepend reader.

A simple polling and selection protocol can bypass the design complexities associated with interrupts, addressing, and scheduling. In the PL3 transmit interface, the selection of the PHY and polling of the PHY to determine its ability to accept a packet occur independently. In practice, the selection of the PHY is achieved by inserting an in-band PHY address. The in-band insertion of the prepend address utilizes a single clock cycle. This implementation simplifies the interface design of the link layer device by requiring a simple polling state machine.

The PL3 receive interface does not require polling or selection by the link layer device. Instead, the PHY device pushes data to the link layer device by sending a port address prepend. As with the transmit interface, the port address prepend only consumes a single clock cycle. The “push” approach provides several advantages that simplify design of the link layer device. The design complexity of the receive data link is greatly reduced by the transfer of the PHY selection protocol to the physical layer device. Fewer device pins are required since there is no need to provision for address and receive packet-available signals. Finally, the architecture scales easily for a large number of ports since there is no need to poll a large number of PHY devices.

Implementing a UL3 extension-style transmit interface requires interrupts to the polling sequence to insert the selected PHY port address. This complicates the design of the link layer device and reduces the available polling bandwidth. In the receive mode, the extended UL3 interface polls and then selects the appropriate PHY. Aside from its complexity, this process also introduces a minimum latency of 4 clock cycles between packet transfers. To avoid this 4-cycle dead period, the link layer device could absorb the first 4 cycles of the next packet in the same port before selecting another port. However, this proposal complicates the link layer device by requiring additional packet buffer management and overhead functions to handle the 4-cycle fragments.

Short packets (ACK/RST/SYN, for example) comprise a significant amount of packet traffic on the Internet. The corresponding minimum bus clock frequencies for packet lengths around the short-packet peak of the bimodal distribution of Internet traffic are shown in Table 2 . The clock frequency is not monotonic with packet length, because the number of valid bytes occupying the last cycle on an end-of-packet occurrence affects the utilization of the available bus bandwidth. To prevent packet blocking on the bus, the PHY device must be selected and written to as quickly as possible. The PL3 interface has a single cycle of overhead latency between back-to-back packet transfers. The minimum bus clock frequency associated with the single-cycle overhead of PL3 is well within maximum acceptable limits. As a result, the PL3 interface provides a nonblocking bus in multiservice applications like ATM, Gigabit Ethernet, and POS. Additionally, developers can either design to a lower bus clock frequency to simplify board implementation, or design to a higher frequency when greater bandwidth is needed to carry application-specific overhead, with packets transferred over the interface.

With frame-extended UL3, there is a latency of at least 4 cycles between the end-of-packet and the start-of-next-packet transfer. At least 2 clock cycles are required for the link layer device to respond to an end-of-packet signal and select the next port. An additional 2 cycles are required for the PHY to respond to the link layer device. This implies a 4-cycle dead time, which adds bus overhead and becomes significant for short-packet transfers. As a result, the minimum clock frequency typically runs very close to the maximum UL3 clock rate of 104 MHz, exceeding the maximum clock rate in some cases. This condition is undesirable because once the maximum clock rate is exceeded, blocking will occur on the bus. In addition, the significantly higher clock frequency of such frame-extended UL3 interfaces makes for a more complex circuit-board implementation.

The PL3 interface has been standardized by the SATURN development group and is publicly available at www.pmc-sierra.com/posphylevel3. While PL3 has gained de facto acceptance in the industry for interfacing 2.5-Gbps data link and PHY layer devices, it will benefit the industry to have PL3 adopted by an open standards body for further maintenance, dissemination, and reference for any subsequent work. Accordingly, the PL3 interface has been submitted to the ATM Forum and Optical Internetworking Forum (OIF) and is presently under review. In particular, the PL3 specification has been adopted as a baseline draft document for System Packet Interface Level 3 (SPI-3) for 2.5-Gbps aggregate bandwidths at the OIF. The PL3 specification has also been accepted and approved for straw ballot at the ATM Forum (Frame-based ATM Interface extension to UL3, STR-PHY-FATM-01.00).