Multi-link transport protocol translation

A device may receive a packet at a network device, and may retrieve from a table, by using information in a header of the packet as keys, records that include communication performance statistics associated with transport protocols. In addition, the device may select, based on the records, a transport protocol with an optimum communication performance statistics among the transport protocols and send the packet in accordance with the selected transport protocol from the network device.

BACKGROUND

Typically, one endpoint of a communication link may send packets and/or messages to the other endpoint in accordance with communication protocols. The endpoints may enforce the protocols at different layers of communication.

SUMMARY

According to one aspect, a method may include receiving a packet at a network device and retrieving from a table, by using information in a header of the packet as keys, records that include communication performance statistics associated with transport protocols. In addition, the method may include selecting, based on the records, a transport protocol with an optimum communication performance statistics among the transport protocols and sending the packet in accordance with the selected transport protocol from the network device.

DETAILED DESCRIPTION

The term “packet,” as used herein, may refer to a packet, datagram, cell; a fragment of a packet, datagram or cell; or other types or arrangements of data (e.g., a message).

As described below, a device may receive a packet, select a transport protocol for sending the packet, perform what is herein referred to as a “transport protocol translation” (e.g., substituting one transport protocol for another) on the packet, and send the packet. In selecting the transport protocol, the device may evaluate a number of different transport protocols based on communication performance statistics (e.g., packet latency, error rate, etc.). In sending the packet, the device may signal information related to the transport protocols to an adjacent upstream device that is to send the packet to the device.

FIG. 1is an exemplary network100in which concepts described herein may be implemented. As shown, network100may include networks102-1and102-2(herein collectively referred to as networks102) and devices104-1through104-N (herein collectively referred to as devices104and individually as device104-x). Although not shown, network100may include additional networks, such the Internet, an intranet, an ad hoc network a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a cellular network, a wireless network (e.g., Wireless LAN), a public switched telephone network (PSTN), or a combination of networks.

Each of networks102may include a LAN, a MAN, a WAN, a cellular network, and/or any other network that may communicate with one or more other networks. Each of devices104may include a gateway, a switch, and/or a router that may relay packets from one device to another device. In relaying the packets, devices104may translate transport protocols of the packets. Although network100may include other types of devices, for the purpose of simplicity, they are not illustrated inFIG. 1.

As further shown inFIG. 1, network102-1may include a client endpoint106-1and a device108-1(e.g., an edge router, a gateway, a proxy server, a firewall, etc.). Network102-1may include additional devices that are interposed between client endpoint106-1and device108-1, even though they are not illustrated inFIG. 1.

Client endpoint106-1may include a computing device, such as a workstation, a personal computer, a laptop, a personal digital assistant, an electronic notepad, a mobile telephone, and/or any other computing device that has the ability to or is adapted to communicate and interact with other devices in network100.

Device108-1may relay packets that are received from devices inside/outside network102-1to devices outside/inside network102-1. In relaying the packets, device108-1may translate network transport protocols of the relayed packets.

Network102-2may include a client endpoint106-2, a device108-2(e.g., an edge router) and/or additional devices (not shown). Client endpoint106-2and device108-2may include similar devices as client endpoint106-1and device108-1and may operate similarly.

Exemplary Network Device Configuration

FIG. 2illustrates an exemplary network device200. Network device200may represent any one of devices104, client endpoints106-1and106-2, and devices108-1and108-2. As shown, network device200may include a processor202, a memory204, input/output components206, a network interface208, and a communication path210. In different implementations, network device200may include additional, fewer, or different components than the ones illustrated inFIG. 2. For example, network device200may include additional network interfaces, such as line interfaces for receiving and forwarding packets.

Processor202may include a processor, a microprocessor, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), and/or other processing logic capable of controlling network device200. Memory204may include static memory, such as read only memory (ROM), and/or dynamic memory, such as random access memory (RAM), or onboard cache, for storing data and machine-readable instructions. Memory204may also include storage devices, such as a floppy disk, CD ROM, CD read/write (R/W) disc, and/or flash memory, as well as other types of storage devices.

Input/output components206may include a display screen, a keyboard, a button, a light-emitting diode (LED), a mouse, a speaker, a microphone, a Digital Video Disk (DVD) writer, a DVD reader, Universal Serial Bus (USB) lines, and/or other types of components for converting physical events or phenomena to and/or from digital signals that pertain to network device200.

Network interface208may include any transceiver-like mechanism that enables network device200to communicate with other devices and/or systems. For example, network interface208may include mechanisms for communicating via a network, such as the Internet, a wireless network, a LAN, a MAN, a WAN, etc. Additionally or alternatively, network interface208may include a modem, an Ethernet interface to a LAN, a line card, and/or an interface/connection for connecting network device200to other devices.

Communication path210may provide an interface through which components of network device200can communicate with one another.

FIG. 3is a functional block diagram of one implementation of exemplary network device200. In this implementation, network device200may take the form of a server, a gateway, etc. As shown, network device200may include an operating system302, an application304, a statistics module306, and a protocol adaptor308.

Operating system302may manage resources (e.g., processing cycles, memory, etc.) of network device200and may provide support for other components of network device200(e.g., an application). For example, operating system200may provide a Transmission Control Protocol (TCP)/IP stack. Application304may perform a specific task and/or provide a service to a user (e.g., an email client service).

Statistics module306may collect statistics (e.g., communication performance statistics) of packets that network device200relays. In some implementations, statistics module306may obtain packet statistics for each of network interfaces (e.g., line interfaces) in network device200. In other implementations, statistics module306may collect packet statistics that pertain to network device200as a whole (e.g., a total number of packets that are received at or sent by network device200).

The packet statistics may include information, such as network latency, types of application-level protocols (e.g., the hypertext transfer protocol (HTTP), the file transfer protocol (FTP), telnet, etc.) with which the packets comply, an average length of the packets, deep inspection properties (e.g., packet parameters that are associated with layers 2-7 of Open System Interconnectivity (OSI) model of network communication), etc.

In one implementation, statistics module306may obtain packet statistics from a flow table included in statistics module306. The flow table may provide statistics about a flow (e.g., a stream of packets from a source to a destination). In another implementation, statistics module306may obtain the packet statistics based on deep packet inspections. The deep packet inspections may involve obtaining samples of packets, correlating packets of a two-way conversation between two endpoints, identifying application-layer protocols for each of the packets, detecting potential security violations, error rates, etc.

Protocol adaptor308may update a transport protocol information table (TPIT), which will be described below in greater detail. In addition, protocol adaptor308may send the information in TPIT to other protocol adaptors in other devices in network100and consult a transport protocol translation table (TTPT) to translate transport protocols. The TTPT will be described below in greater detail, to translate transport protocols.

FIG. 4shows an exemplary TPIT400. TPIT400may be included in one or more of the components inFIG. 2and/orFIG. 3(e.g., memory204). As shown inFIG. 4, TPIT400may include records402-1through402-M (hereinafter collectively referred to as records402and individually as record402-x). As further shown, each record402-xmay include an interface identifier field404, a protocol field406, an application-layer protocol field408, a latency field410, and a packet count/length field412. Depending on the implementation, record402-xmay include additional, fewer, or different fields than those illustrated inFIG. 4(e.g., an error rate field, a bandwidth field, a desired or required quality-of-service (QoS) field, an overall latency of network100field, etc.).

Interface identifier field404may identify an interface (e.g., a line interface) where packets whose statistics are stored in record402-xare received/sent. Protocol field406may identify a transport protocol for which record402-xincludes the packet statistics. Application-layer protocol field408may indicate an application-layer communication protocol under which the packets originate (e.g., the HTTP, the FTP, the telnet, etc.). Latency field410may indicate an average delay that is associated with conveying the packets from an upstream device in network100to network device200. Packet count/length field412may indicate the number of packets/average lengths of packets that are received at the line interface from the upstream device.

In one implementation, protocol adaptor308may update TPIT400based on flow records (e.g., records about flows), deep packet inspection properties, and/or sampled packets (e.g., copies of the packets). For example, when protocol adaptor308receives a packet, protocol adaptor308may identify an interface at which the packet is received, and may obtain, from the packet's header, a transport protocol and an application-layer protocol. Furthermore, protocol adaptor308may locate record402-xbased on an interface identifier (e.g., a line card number) associated with the identified interface, the transport protocol, and the application-layer protocol. Once record402-xis retrieved, protocol adaptor308may update latency field410or packet count/length field412with new values of latency, packet counts, and/or average packet lengths.

Protocol adaptor308may exchange information related to transport protocols (e.g., information in a TPIT) with other protocol adaptors in devices that are adjacent to network device200at the transport layer. In exchanging the information, protocol adaptor308may follow a specific signaling protocol. For example, assume that protocol adaptor308determines an average latency of packets that are routed from an upstream device to network device200. In such a case, protocol adaptor308may signal (e.g., send) the average latency to the upstream device. The upstream device may use the latency information to select a transport protocol under which packets may be conveyed to network device200in the shortest amount of time.

Protocol adaptor308may consult a transport protocol translation table (TPTT) for translating transport protocols. A TPTT may include TPIT400that has been transferred from an adjacent downstream device. When protocol adaptor308receives a packet, protocol adaptor308may locate, within the TPTT, records402that match information in the packet's header, such as, for example, a length of the packet, an application-layer protocol, etc. Furthermore, among the matching records, protocol adaptor308may select record402-xthat optimally satisfies a set of criteria (e.g., a least latency, a fewest number of errors, etc.). Subsequently, protocol adaptor308may send the packet in accordance with a transport protocol that is indicated in protocol field406of selected record402-x.

Prior to sending the packet, protocol adaptor308may modify the packet in a number of different ways.FIG. 5Ais a block diagram of a packet502before the packet is sent by protocol adaptor308. As shown, packet502may include headers504and a payload506. Headers504may include information about packet502(e.g., a source address, a destination address, a port number, a protocol, a length, etc.) at different layers of communication. Payload506may include packet data.

FIG. 5Bis a block diagram of headers504. As shown, headers504may include an IP header508and a transport protocol header510. IP header508may include information that pertains to layer 3 of the OSI model (e.g., a source IP address, a destination IP address, etc.). Transport protocol header510may include information for layer 4 of the OSI model or layer 4 of the TCP/IP reference model of communication. Examples of information that may be included in transport protocol header510include a TCP header, a User Datagram Protocol (UDP) header, a Stream Control Transmission Protocol (SCTP) header, a Datagram Congestion Control Protocol (DCCP) header, etc.

In one implementation, before sending the packet, protocol adaptor308may modify the packet by replacing transport protocol header510with a header of its own, herein referred to as “adaptor header,” to convey, to a downstream device, information related to transport protocol translation.FIG. 5Cshows header504after protocol adaptor308replaces transport protocol header510with adaptor header512. In one implementation, adaptor header512may include a header for a selected transport protocol under which the packet will be sent from network device200to the downstream device.

In a different implementation, protocol adaptor308may insert an adaptor header between IP header508and transport protocol header510.FIG. 5Dshows header504after protocol adaptor308inserts adaptor header512in header504. As inFIG. 5C, adaptor header512may include header512for the selected transport protocol. For example, assuming that protocol adaptor308selects the TCP, adaptor header512may include a TCP header.

InFIGS. 5C and 5D, depending on the specifics of how network device200exchanges information related to transport protocol translation with other devices in network100, adaptor header512may or may not include information in addition to a header for the selected protocol, such as the time that adaptor header512is created, an identifier for adaptor header512, etc. For example, in one implementation, assume that protocol adaptor308indicates to an adjacent downstream device that protocol adaptor308will insert adaptor header512between IP header508and transport protocol header510in packets that are to be sent to the downstream device. Based on the indication, when the downstream device receives a packet from protocol adaptor308, the downstream device may correctly handle adaptor header512(e.g., remove adaptor header) in the packet even if adaptor header512is indistinguishable from a transport protocol header (e.g., a UDP header, a TCP header, etc.).

When network device200receives a packet that has been modified by protocol adaptor308within an upstream device, protocol adaptor308in network device200may replace an adaptor header that is present in the packet with its own adaptor header512, or may remove the adaptor header.

FIG. 6is a functional block diagram of another implementation of exemplary network device200. In the implementation, network device200may take the form of a router or a switch. As shown, network device200may include a buffer manager602, routing logic604, and forwarding logic606. Depending on specifics of the implementation, network device200may include additional, fewer, or different components than the ones illustrated inFIG. 6.

Buffer manager602may provide a buffer for queuing incoming packets. If packets arrive simultaneously, one or more of the packets may be stored in the buffer until higher priority packets are processed and/or transmitted. Routing logic604may include hardware and/or software for communicating with routing logic of other devices to gather and store routing information in a routing information base (RIB). In one implementation, routing logic604may also include TPIT400and may provide functionalities for sending/receiving TPIT400or information that is included in TPIT400to another device in network100. In some implementations, when routing logic604receives TPIT400or information in TPIT400from a downstream device, routing logic604may distribute the information to line interfaces in network device200. Such mechanisms may improve transport protocol translation speed.

Forwarding logic606may include hardware and/or software for directing a packet to a proper output port on one of line interfaces (not shown) based on routing information. Forwarding logic606may be implemented on multiple components, such as network interfaces (e.g., line interfaces) in network device200.

FIG. 7is a functional block diagram of forwarding logic606that may be implemented on a line interface. As shown, forwarding logic606may include a forwarding module702, a classification table704, a forwarding table706, TPTT708, and a fabric interface710. Depending on the implementation, forwarding logic606may include fewer, additional, or different components than those illustrated inFIG. 7.

Forwarding module702may include hardware and/or software for forwarding and/or classifying a packet that is received at the line interface. When forwarding module702receives a packet, forwarding module702may perform a lookup of information related to the packet in classification table704, process the packet based on the information, and forward the packet in accordance with information in forwarding table706.

As further shown inFIG. 7, forwarding module702may include a protocol adaptor712. Protocol adaptor712may be implemented similarly and operate similarly as protocol adaptor308. In some implementations, however, protocol adaptor400's ability to exchange TPIT information may be incorporated in routing logic604(FIG. 6) rather than in protocol adaptor712.

Classification table704may include rules for categorizing a packet based on a packet header. Examples of classification rules may include rules for performing a firewall rule lookup (e.g., access control list (ACL) lookup) for performing a policy based routing (e.g., if a packet header indicates that the packet is a telephony packet, route the packet from X to Y via an asynchronous transfer mode (ATM) circuit), and for rendering differentiated quality of service (QoS). Forwarding table706may include information for identifying an egress line interface to forward an incoming packet to a device based on the packet's network destination address.

TPTT708may include similar fields and/or information as TPIT400or the TPTT that has been described above in connection with protocol adaptor308(FIG. 3). In some implementations, because TPTT708is located within a line interface, records in TPTT708may not include one or more fields in records402, such as an interface identifier field404.

Fabric interface710may include hardware and/or software for providing an interface to a switch fabric (not shown) that interconnects the line interfaces within network device200. Fabric interface710may include one or more interfacing buffers (not shown) for temporarily storing packets from forwarding module702. The buffers may prevent the packets from being dropped if a bottleneck (e.g., a processing delay) develops on a line interface-to-line interface path during packet transport.

As further shown inFIG. 7, fabric interface710may include a statistics module714. Statistics module714may include similar functional components and may operate similarly as statistics module306. AlthoughFIG. 7shows statistics module714as being included in fabric interface710, in different implementations, statistics module714may be physically positioned in forwarding module702or elsewhere on a signal path between forwarding module702and fabric interface710.

Exemplary Process for Translating Transport Protocols

FIG. 8is a flow chart of an exemplary process800for translating transport protocols. Depending on the implementation, process800may be performed by one or more components of network device200.

As shown, process800may begin when a packet is received (block902). In one implementation, network device200may receive the packet from an upstream, adjacent device (e.g., a router, gateway, or an endpoint).

Statistics may be collected based on the packet (block804). Network device200may collect the statistics in a number of different ways. For example, statistics module306may obtain information about a flow to which the packet belongs (e.g., a number of packets that belong to the flow) from a flow table. In another example, statistics module306may identify an application-layer protocol (e.g., TCP, SCTP, UDP, etc.) of the packet from the packet's header. In still another example, statistics module306may obtain latency between an upstream device that sent the packet and network device200based on a time stamp included in adaptor header512and the time when the packet is received at network device200. In yet another example, statistics module306may determine the length of payload506of the packet.

TPIT400may be updated (block806). To update TPIT400, protocol adaptor308/712may access record402-xof TPIT400(FIG. 4) based the packet's transport protocol and/or packet's application-layer protocol. If protocol adaptor308/712is not implemented on a line interface, but on a centralized memory, an identifier associated with a line interface that receives the packet may also be useful for locating record402-x. Subsequently, protocol adaptor308/712may update various fields in record402-x, as described above with reference to TPIT400.

For example, protocol adaptor308/712may update packet count/length field412in record402-x. Assume that protocol adaptor308/712is implemented on a line interface, as shown inFIG. 7. In such an instance, protocol adaptor308/712may lookup, in the flow table in statistics module714, a number of packets/bytes that have been sent by an upstream device under a specific transport protocol and at a particular port number. Based on information retrieved from the lookup, protocol adaptor308/712may determine a packet count and/or an average packet length to update packet count/length field412.

In another example, protocol adaptor308/712may update latency field410. To update latency field410, protocol adaptor308/712may determine if the packet has been sent from an upstream device that includes a protocol adaptor, by determining whether protocol adaptor308/712has been signaled by a protocol adaptor in the upstream device. If the packet has been sent from an upstream device that includes the protocol adaptor, protocol adaptor308/712may examine adaptor header512to identify the time when adaptor header512in the packet was created in the upstream device. By comparing the time at which the packet is received at network device200to the time when adaptor512was created, protocol adaptor308/712may determine the latency associated with sending the packet from the upstream device to network device200. The latency may be used to adjust the value of average latency that is stored in latency field410.

Information that is related to transport protocol translation may be exchanged (block808). For example, protocol adaptor308/712may send TPIT400or information included in TPIT400to an adjacent upstream device. If protocol adaptor308/712is located in processor202/memory204, rather than in a line interface, protocol adaptor308/712may send TPIT400/information in TPIT400to each of the devices that are adjacent to each of line interfaces in network device200.

Depending on the implementation, protocol adaptor308/712may send the TPIT periodically, based on a demand, or based on TPIT information from other devices in network100. In addition, when network device200receives the TPIT information from one or more devices in network100, protocol adaptor308/712may use the TPIT information to update a TPTT in network device200(e.g., TPTT708).

A new transport protocol for the packet may be selected based on a lookup within the TPTT (block810). For example, in one implementation, protocol adaptor308/712may access the TPTT and examine latencies for different protocols based on information included in the packet header (e.g., an application-layer protocol (e.g., HTTP, Simple Mail Transfer Protocol (SMTP), telnet, Post Office Protocol (POP), Real-time Transport Protocol (RTP), Session Initiation Protocol (SIP), Internet Message Access Protocol (IMAP), FTP, Gopher, Network News Transfer Protocol (NNTP), etc.), the length of payload506, an overall latency of the network, and/or other information (e.g., QoS)). Subsequently, protocol adaptor308/712may dynamically select a transport protocol that optimally satisfies a set of criteria (e.g., the least latency, error rate, etc.).

In the above, one reason for selecting the transport protocol may be that the selected transport protocol may allow the packet to reach a next-hop device with superior performance statistics than the original transport protocol, depending on network traffic conditions, the size of payload506of the packet, and/or any other properties that are associated with network100or the packet. For example, a large packet under the SCTP may exhibit less latency than large packets under other transport protocols. A small FTP packet under the TCP may be communicated faster than similar packets under the SCTP or the UDP. A packet under the UDP may be conveyed quickly for medium-sized payloads (e.g., less than 1500 bytes).

Adaptor header512may be inserted in, replaced in, or removed from header504of the packet (block812). Based on the specific transport protocol that is selected at block810, protocol adaptor308/712may create adaptor header512that includes a header for the selected transport protocol. Furthermore, protocol adaptor308/712may insert adaptor header512in packet header504. If the packet already includes an adaptor header, protocol adaptor308/712may replace the adaptor header in packet header504with adaptor header512.

If the packet at network device200is one hop away from an endpoint (e.g., a client endpoint or a server endpoint), protocol adaptor308/712may remove adaptor header512from the packet.

Once packet header502is properly modified, the packet may be sent (block814). For example, protocol adaptor308/712may send the packet to a device in network100. The device may be similar to network device200(e.g., a gateway, a router, a switch, etc.) or an endpoint (e.g., a client endpoint or a server endpoint). The packet may be sent in accordance with adaptor header512or transport protocol of transport protocol header510.

Example

FIG. 9illustrates an example for translating transport protocols. The example is consistent with exemplary process800described above with respect toFIG. 8.

Assume that network900includes LAN902and LAN904, LAN902includes a personal computer906(e.g., a client endpoint) and an edge router908, and LAN904includes an edge router910and a web server912(e.g., a server endpoint). In addition, assume that packets under the UDP are conveyed more optimally (e.g., less latency, fewer bit errors, etc.) than packets under other transport protocols when the packets are relayed from edge router908to edge router910.

In the example, a user at personal computer906sends a HTTP packet over the TCP via a browser. The packet is transmitted to edge router908. Protocol adaptor712in edge router908looks up records402in a TPTT based on a header of the packet, and selects the UDP as a transport protocol that is best for sending the packet to edge router910. Based on the protocol selection, protocol adaptor712creates and inserts adaptor header512for the UDP in the packet header.

Edge router910receives the packet with adaptor header512from to edge router908. Based on a prior exchange of information related to transport protocol translation between edge router908and edge router910, protocol adaptor712in edge router910knows that the packet may include adaptor header512.

Protocol adaptor712in edge router910uses the packet header to update TTIP400. In particular, protocol adaptor712looks up a record402-xthat matches UDP protocol and the application-layer protocol (e.g., HTTP) and updates latency field410and packet count/length field412of record402-xwith new values of latency, packet counts, and average packet lengths. The new values of latency, packet counts, and average packet lengths may be determined based on statistics that are collected for the packet.

Edge router912removes adaptor header512from the packet header and relays the packet to web server912.

Conclusion

The foregoing description of implementations provides illustration, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the teachings.

For example, while a series of blocks has been described with regard to an exemplary process illustrated inFIG. 8, the order of the blocks may be modified in other implementations. In addition, non-dependent blocks may represent acts that can be performed in parallel to other blocks.