Abstract:
A method for formatting ATM cells compliant with SPI-4 Phase 2 specification is presented. The method enables selection among various cell formats depending on the devices employed, and enables use of a payload-only test format, a typical format having payload and header data, a format having header error correction (HEC) data and dummy data, and a format having HEC data and user data.

Description:
BACKGROUND OF THE INVENTION 
   1. Field of the Invention 
   The present invention relates generally to the field of high speed data transfer, and more specifically to cell formatting for the asynchronous transfer mode (ATM) in accordance with the SPI-4 phase 2 specification. 
   2. Description of the Related Art 
   Data communication networks receive and transmit ever increasing amounts of data. Data is transmitted from an originator or requester through a network to a destination, such as a router, switching platform, other network, or application. Along this path may be multiple transfer points, such as hardware routers, that receive data typically in the form of packets or data frames. At each transfer point data must be routed to the next point in the network in a rapid and efficient manner. 
   Data transmission over fiber optics networks may conform to the SONET and/or SDH standards. As used herein, the SONET/SDH concepts are more fully detailed in various ANSI, ITU, and ITU-T standards, including but not limited to the discussion of SPI-4, Phase 2, in the Optical Internetworking Forum (OIF Document) OIF-SPI4-02.1 and ITU-T G.707 2000, T1.105-2001 (draft), T1.105.02-1995, and ITU-T recommendations G.7042 and G.707. 
   SPI-4 Phase II is an interface for packet and cell transfer between a physical layer (PHY) device and a link layer device, for aggregate bandwidths of OC-192 ATM and Packet over SONET/SDH (POS), as well as 10 Gb/s Ethernet applications. 
   The problem with the current interface scheme for ATM mapping over SONET/SPI-4 Phase 2 is that different devices employing the ATM mapping may have different requirements for data transmission. Certain devices can benefit from test modes, while other devices have uniform size payloads but employ different types of overhead data or administrative data. With odd sized data, transmission over the SPI-4 Phase 2 16 bit bus may present problems, such that a uniform cell format may require the transmitting entity to omit data or the transmission process itself may truncate data or provide an error indication in the case of a data mismatch, i.e. when more or less data is transmitted than fits across the interface. Any such truncation or error indication is highly undesirable. 
   Further, certain test modes may be employed, such as for purposes of evaluating system performance, where it may be desirable to omit data or otherwise transmit random payloads or data over the network. This data must also conform to the 16 bit bus requirement, or the result may be a loss of data or error indication. 
   A design that provides a cell format or set of cell formats may enable straightforward transmission of data in common formats so that different devices can be employed while simultaneously conforming to the SPI-4 Phase 2 standard, and particularly the 16 bit bus requirement. 

   
     DESCRIPTION OF THE DRAWINGS 
     The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which: 
       FIG. 1  is a conceptual illustration of a SONET/SDH system data flow model in accordance with SPI-4 Phase 2; 
       FIG. 2  illustrates the SPI-4 mapping of packets and ATM cells onto a payload stream; 
       FIG. 3  shows an SPI-4 52 byte payload and header cell format; 
       FIG. 4  is an SPI-4 53 byte payload, header, HEC and dummy data cell format; 
       FIG. 5  illustrates an SPI-4 54 byte payload, header, HEC, and user data cell format; and 
       FIG. 6  is a SPI-4 48 byte cell format used primarily for testing purposes. 
   

   DETAILED DESCRIPTION OF THE INVENTION 
   The present design provides for a set of cell formats applicable to various situations employing the SPI-4 Phase 2 interface. Cell formats for 52, 53, and 54 byte transmissions are provided, as well as a stripped payload-only test version having 48 bytes. In operation, the system evaluates the devices involved and selects a cell format appropriate for the situation. In all cell formats, data is transmissible over the SPI-4 Phase 2 16 bit bus. 
   SPI-4 Phase 2 is an interface for packet and cell transfer between a physical layer (PHY) device and a link layer device, for aggregate bandwidths of OC-192 ATM and Packet over SONET/SDH (POS), as well as 10 Gb/s Ethernet applications.  FIG. 1  illustrates a conceptual interface diagram between the PHY device  101  and the transmit link layer device  102  and receive link layer device  103 . Within system  100 , data flows from transmit link layer device  102  through the transmit interface  104  and in SPI-4 Phase 2 format to the PHY device  101 , and flow control flows from the PHY device in SPI-4 to transmit interface  104  to transmit link layer device  102 . Receive link layer device receives data from receive interface  105  via SPI-4 compliant PHY device  101  data. Flow control originates at receive link layer device  103  and passes through the receive interface  105  to SPI-4 format and PHY device  101 . SPI-4 offers point to point connectivity, such as between a single PHY and a single link layer device, and supports 256 ports, suitable for STS-1 in SONET/SDH applications. The transmit/receive data path is 16 bits wide. 
   Data is transferred in SPI-4 Phase 2 operation in bursts having a provisionable maximum length and either a fixed or a provisionable minimum length. Both the minimum and maximum burst transfer lengths are typically multiples of 16 bytes. The actual burst transfer length is typically a multiple of 16 bytes, with the exception of transfers that terminate with an EOP (end of packet indication). The system sends information associated with each transfer (port address, start/end-of-packet indication and error-control coding) in 16-bit control words.  FIG. 2  shows a mapping of ATM cells and variable-length packets onto the data stream. 
   The format used to transfer ATM cells across the interface has not been established. When the network transfers ATM cells from an ATM-layer device, such as a network processor, to an ATM physical layer device, such as a mapper of ATM data over SONET, various possibilities for ATM cell format may be employed. 
   The present design uses four different implementations to map ATM cells into SONET/SDH payloads. The different formats can be employed based on desired configuration. 
     FIG. 3  shows a transferred cell comprising a four byte header  301  and the 48 byte payload  302 . The total length for the arrangement illustrated in  FIG. 3  is 52 bytes, which fits exactly into the 16 bit bus. As shown in  FIG. 3 , the header  301  comprises stacked bytes, specifically two bytes of data h 1  and h 3  atop two additional bytes of data, h 2  and h 4 . The payload comprises twenty four bytes of data atop twenty four additional bytes of data in this arrangement. 
     FIG. 4  illustrates a full 53 byte cell for transfer, including the aforementioned four byte header  401 , the 48 byte payload  402 , as well as the header error control byte (HEC)  403 . Presence of the HEC  403  unbalances the cell, where unbalancing means that the cell will not readily be transmissible over the 16 bit bus. In such a situation, the system adds a dummy byte  404  to balance the cell and enable 16 bit bus transmission. 
     FIG. 5  shows an alternate construction employing the previously mentioned four byte header  501 , the 48 byte payload  502 , as well as the header error control byte (HEC)  503  and user data  504 . The present configuration orders the header  501  first, followed by the HEC  503  atop the user data  504 , and the payload  503  last. Again, with this 54 byte cell format, the information fits across the 16 bit bus. In this implementation, the user data  504  is one byte of data employed in the transmit direction to enable insertion of an error mask 
   In certain circumstances, it may be useful to only transfer the payload without transferring the header data or other overhead or associated data. Such a payload transfer mechanism can be employed in test situations, where a fixed or constant header is inserted at the physical layer device or stripped out by the physical layer device. In such an arrangement, the payload may be generated or analyzed on the other side of the interface using a PRBS (pseudorandom bit sequence) generator. 
     FIG. 6  illustrates the cell format for transmission of only payload data, and shows the construction of the stripped 48 byte cell all-payload format. From  FIG. 6 , only payload  601  is available and transmitted, and this arrangement fits across the 16 bit bus and can be processed for testing or other appropriate data subsequent to transmission. 
   In operation, the network may evaluate the devices operating in the SPI-4 Phase II environment. If a device is employed that requires HEC data, the 53 byte or 54 byte implementation may be employed. If a device is employed that requires HEC data and user data, the 54 byte implementation may be employed. If no device uses either HEC or user data, the 52 byte implementation may be employed. If testing is being performed or to be performed, the 48 byte cell format may be employed. Thus the system may perform an initial evaluation and set the cell format based on the components used, or this may be known to the operator or hardware installer and the format set at initial startup. 
   It will be appreciated to those of skill in the art that the present design may be applied to other systems that perform data processing, and is not restricted to the communications structures and processes described herein. Further, while specific hardware elements and related structures have been discussed herein, it is to be understood that more or less of each may be employed while still within the scope of the present invention. Accordingly, any and all modifications, variations, or equivalent arrangements which may occur to those skilled in the art, should be considered to be within the scope of the present invention as defined in the appended claims.