Abstract:
A method of converting a data packet that has a header includes storing the data packet and generating a header template having a plurality of static fields. The method further includes generating at least one dynamic field and merging the header template with the header. The method further includes inserting the at least one dynamic field to form a converted header.

Description:
FIELD OF THE INVENTION  
         [0001]    One embodiment of the present invention is directed to digital data. More particularly, one embodiment of the present invention is directed to a conversion of a digital data packet header.  
         BACKGROUND INFORMATION  
         [0002]    Voice telephone calls have traditionally been carried over circuit-based transmission facilities on the Public Switched Telephone Network (“PSTN”). However, increasingly more and more voice telephone calls are carried over the Internet and other similarly structured packet-based networks, and are referred to as Voice over Internet Protocol (“VoIP”) telephone calls. In addition, many voice telephone calls are carried over a combination of the PSTN and the Internet.  
           [0003]    The telephone calls that are carried over both the PSTN and the Internet require format changes as the voice data switches between networks. For example, data going from the PSTN to the Internet must be broken up into packets and the appropriate header must be created and appended to each packet. Since any VoIP implementation is constrained by real-time limitations, it is extremely important to create or convert the packet headers in the most efficient way possible.  
           [0004]    Based on the foregoing, there is a need for a method and apparatus to efficiently create and convert headers for VoIP and other packets. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0005]    [0005]FIG. 1 is a block diagram of a communication system that includes one embodiment of the present invention.  
         [0006]    [0006]FIG. 2 illustrates the format of a super-header that includes an IP header, a UDP header, and an RTP header.  
         [0007]    [0007]FIG. 3 illustrates the format of an IP header.  
         [0008]    [0008]FIG. 4 illustrates the format of a UDP header.  
         [0009]    [0009]FIG. 5 illustrates the format of a RTP header.  
         [0010]    [0010]FIG. 6 illustrates the format of a DSP header in accordance with one embodiment of the present invention.  
         [0011]    [0011]FIG. 7 illustrates an example of packet buffer data and a header template in accordance with one embodiment of the present invention.  
         [0012]    [0012]FIG. 8 illustrates an example of packet buffer data and a header template in accordance with one embodiment of the present invention. 
     
    
     DETAILED DESCRIPTION  
       [0013]    One embodiment of the present invention is a packet processor that converts propriety headers to VoIP headers by using a pre-formatted header template. The header template includes data that does not change during the conversion.  
         [0014]    [0014]FIG. 1 is a block diagram of a communication system that includes one embodiment of the present invention. The communication system includes two networks: a time division multiplex (“TDM”) network  10  and an Internet Protocol (“IP”) network  16 . TDM network  10  could be any circuit-switched telephone network such as the PSTN. IP network  16  in one embodiment is the Internet.  
         [0015]    The devices  12 ,  14 ,  18 ,  20  and  22  of FIG. 1 are used to convert voice data from TDM network  10  to packets that are transmitted on IP network  16 , and vice versa. A digital signal processor (“DSP”)  12  and supporting logic receives voice samples on TDM network  10  and converts the samples into data packets that represent the level and frequency information of the TDM data. In one embodiment, DSP  12  is the IXS1000 DSP from Intel Corp. The data packets that are output from DSP  12  have a proprietary header that can vary in format depending on the type of DSP that is implemented.  
         [0016]    Packet traffic on the Internet is typically carried using the Transmission Control Protocol/Internet Protocol (“TCP/IP”) end-to-end protocol. Rather than using TCP as the transport protocol, Internet telephony applications typically use the much simpler User Datagram Protocol (“UDP”) to provide the transport layer function. The delivery monitoring function, supported by sequence numbering and time stamping, is provided by the Real-time Transport Protocol (“RTP”), including its performance monitoring partner protocol RTP Control Protocol (“RTCP”).  
         [0017]    The communication system of FIG. 1 further includes a packet processor  14  that receives data packets from DSP  12  that have a proprietary header, and that converts the packets into standard packets that are compatible with IP network  16 . In one embodiment, the data portion of the packets remain the same after conversion, and the header is converted. In one embodiment, packet processor  14  is the IXP 1200 packet processor from Intel Corp.  
         [0018]    A control processor  22  assists packet processor  14  in the set up and tear down of VoIP telephone calls. A memory  20  stores programming functionality and buffers packets that are to be converted by packet processor  14 . An IP network interface  18  transmits packets to IP network  16 , and vice versa.  
         [0019]    In one embodiment, Internet telephony packets transmitted over IP network  16  are prepended with a “super-header” that includes headers defined by the IP, UDP, and RTP standards. FIG. 2 illustrates the format of a super-header  30  that includes an IP header, a UDP header, and an RTP header that are generated by packet processor  14 . Super-header  30  can be appended onto a payload  32  to form a complete packet.  
         [0020]    [0020]FIG. 3 illustrates the format of an IP header  35 . IP header  35  is defined in Request for Comment (“RFC”)  791 .  
         [0021]    [0021]FIG. 4 illustrates the format of a UDP header  40 . UDP header  40  is defined in RFC  768 .  
         [0022]    [0022]FIG. 5 illustrates the format of a RTP header  45 . RTP header  45  is defined in RFC  1889 .  
         [0023]    In addition to converting data coming from TDM network  10  and destined for IP network  16 , packet processor  14  also receives IP packets from IP network  16  and converts them so that they can be received by DSP  12  and transmitted to TDM network  10 . In this direction, packet processor  14  must convert the super-header of the IP network packets to the proprietary header used by DSP  12 . FIG. 6 illustrates the format of a DSP header  50  in accordance with one embodiment of the present invention.  
         [0024]    Each of the headers illustrated in FIGS.  3 - 6  are formed by header fields (e.g., the “Version”, “IHL” and “Type of Service” header fields of the IP header of FIG. 3). In one embodiment, each header field falls into one of three categories:  
         [0025]    1) Header fields that are the same for ALL packets sent by the VoIP application. In FIGS.  3 - 6 , these fields are illustrated as underlined italic type;  
         [0026]    2) Header fields that are connection-specific (i.e., they are constant for a specific telephone call, but may change between calls). In FIGS.  3 - 6 , these fields are illustrated as underlined regular type; and  
         [0027]    3) Header fields that may change from one packet to the next on the same telephone call. In FIGS.  3 - 6 , these fields are shown in regular type and can be referred to as “dynamic fields”.  
         [0028]    In other embodiments, different applications will divide the header fields differently among the above categories, but the categories themselves will remain the same.  
         [0029]    One embodiment of the present invention creates packet headers in the most efficient way possible through the use of a “header template” that contains the unchanging data in header fields from categories  1  and  2  above (referred to as “static fields”). The header template is positioned so that it can be written directly to the packet buffer, with modifications limited to the category  3  fields above. In one embodiment in which the IXP1200 packet processor is used, the field modifications are made in the Synchronous Dynamic Random Access Memory (“SDRAM”) transfer registers of the IXP 1200 before writing the completed header to the packet buffer.  
         [0030]    In the direction towards IP network  16 , the header fields are populated by packet processor  14  from one of two different sources: (1) the internal header prepended to each voice data payload by DSP  12 ; or (2) the header template stored in shared memory  20 .  
         [0031]    Packets received from DSP  12  by packet processor  14  are stored in packet buffers. In one embodiment, since the IPX1200 packet processor addresses these buffers in dynamic RAM with a 64-bit(“quadword”) granularity, and the DSP header is not an integral multiple of 64 bits in length, the payload of packets written with the DSP header on a quadword alignment will not begin on a quadword boundary. Because of the byte alignment restrictions imposed by the IXP1200 (and similar limitations imposed by other packet processors) efficient transmission requires that the resulting IP/UDP/RTP header must be contiguous with the packet data in the packet buffer. Therefore, in one embodiment the header template is stored so that is aligned to match the payload. The header template includes data for all the underlined fields in FIGS.  3 - 5  (i.e., category 1 and 2 fields) and zeros for the other fields (i.e., category 3 fields).  
         [0032]    [0032]FIG. 7 illustrates an example of packet buffer data  55  and a header template  60  in accordance with one embodiment of the present invention in the direction towards IP network  16 . The alignment of packet buffer data  55  and header template  60  allows header template  60  to be copied over the first five quadwords of packet buffer data  55  and “ORed” with the sixth quadword (after setting the lowest four octets of the sixth quadword to zero) to create the basic header that includes category 1 and 2 fields. Individual category 3 dynamic fields that are needed to create the final IP/UDP/RTP header are also written into the packet buffer data. In one embodiment, the DSP header information in quadwords  5  and  6  of packet buffer data  55  must be saved in registers before the copy operation, since this information is required to create the final header. The transmission of the final packet after packet buffer data  55  is merged with header template  60  begins with octet  4  of the first word in the embodiment shown in FIG. 7.  
         [0033]    In the direction toward TDM network  10 , the changing fields are populated by packet processor  14  from either: (1) the IP/UDP/RTP header of each received packet; or (2) a header template stored in shared memory  20  by control processor  22 .  
         [0034]    Packets received from IP network  16  and IP network interface  18  by packet processor  14  are stored in packet buffers. In one embodiment, since the IXP 1200 addresses these buffers in dynamic RAM with a 64-bit quadword granularity, and the IP/UDP/RTP header is an integral multiple (i.e., multiple of 5) of 64 bits in length, the payload of packets written with the IP/UDP/RTP header on a quadword alignment will begin on a quadword boundary. Because of the byte alignment restrictions imposed by the IXP1200 (and similar limitations imposed by other packet processors) efficient transmission requires that the resulting DSP header must be contiguous with the packet data in the packet buffer. Therefore, in one embodiment the header template is stored so that is aligned to match the payload. The header template includes data for all the underlined fields in FIGS.  3 - 5  (i.e., category 1 and 2 fields) and zeros for the other fields (i.e., category 3 fields).  
         [0035]    [0035]FIG. 8 illustrates an example of packet buffer data  65  and a header template  70  in accordance with one embodiment of the present invention in the direction toward TDM network  10 . The alignment of packet buffer data  65  and header template  70  allows header template  70  to be copied over the first five quadwords of packet buffer data  55  to create the basic header that includes category 1 and 2 fields. Individual category 3 dynamic fields that are needed to create the final DSP header are also written into the packet buffer data. In one embodiment, the IP/UDP/RTP header information in quadwords  1 - 5  of packet buffer data  65  must be saved in registers before the copy operation, since this information is required to create the final header. The transmission of the final packet after packet buffer data  65  is merged with header template  70  begins with octet  4  of the fourth word in the embodiment shown in FIG. 8.  
         [0036]    As described, embodiments of the present invention use a header template to create or convert headers. The use of a stored header template allows greater real-time efficiency and therefore greater throughput of packets for the Internet telephony communication system. The byte alignment of the template obviates the need to read, shift and write each word in the buffer to create alignment with the incoming packet payload. Since this header creation must be done for each packet, it has a substantial impact on real-time system performance.  
         [0037]    The header pre-formatting implementation of embodiments of the present invention is applicable to any packet processing system in which the converted packets are formatted with a header that must be created with a fixed byte alignment in order to match the alignment of the payload data. This could apply to any voice-over-packet system.  
         [0038]    Several embodiments of the present invention are specifically illustrated and/or described herein. However, it will be appreciated that modifications and variations of the present invention are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention.