US20110142063A1 - Multi-link transport protocol translation - Google Patents
Multi-link transport protocol translation Download PDFInfo
- Publication number
- US20110142063A1 US20110142063A1 US13/035,679 US201113035679A US2011142063A1 US 20110142063 A1 US20110142063 A1 US 20110142063A1 US 201113035679 A US201113035679 A US 201113035679A US 2011142063 A1 US2011142063 A1 US 2011142063A1
- Authority
- US
- United States
- Prior art keywords
- protocol
- packet
- header
- transport
- adaptor
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/326—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/165—Combined use of TCP and UDP protocols; selection criteria therefor
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
Definitions
- 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.
- 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.
- 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.
- FIG. 1 is a diagram of an exemplary network in which concepts described herein may be implemented
- FIG. 2 is a block diagram of an exemplary device of FIG. 1 ;
- FIG. 3 is a functional block diagram of one implementation of the exemplary device of FIG. 2 ;
- FIG. 4 is a block diagram of an exemplary transport protocol information table (TPIT);
- TPIT transport protocol information table
- FIG. 5A is a block diagram of an exemplary packet
- FIG. 5B is a block diagram of a header of the exemplary packet of FIG. 6A ;
- FIG. 5C is a block diagram of the header of FIG. 5B after a transport protocol header is replaced with an adaptor header;
- FIG. 5D is a block diagram of the header of FIG. 5B after an adaptor header is inserted between a transport protocol header and an Internet Protocol (IP) header;
- IP Internet Protocol
- FIG. 6 is a functional block diagram of another implementation of the exemplary device of FIG. 2 ;
- FIG. 7 is a functional block diagram of forwarding logic of FIG. 6 ;
- FIG. 8 is a flow chart of an exemplary process for translating transport protocols.
- FIG. 9 is a block diagram of another network in which the concepts described herein may be implemented.
- packet 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).
- 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.
- a transport protocol translation e.g., substituting one transport protocol for another
- the device may evaluate a number of different transport protocols based on communication performance statistics (e.g., packet latency, error rate, etc.).
- 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. 1 is an exemplary network 100 in which concepts described herein may be implemented.
- network 100 may include networks 102 - 1 and 102 - 2 (herein collectively referred to as networks 102 ) and devices 104 - 1 through 104 -N (herein collectively referred to as devices 104 and individually as device 104 - x ).
- network 100 may 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.
- LAN local area network
- WAN wide area network
- MAN metropolitan area network
- PSTN public switched telephone network
- Each of networks 102 may 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 devices 104 may include a gateway, a switch, and/or a router that may relay packets from one device to another device. In relaying the packets, devices 104 may translate transport protocols of the packets.
- network 100 may include other types of devices, for the purpose of simplicity, they are not illustrated in FIG. 1 .
- network 102 - 1 may include a client endpoint 106 - 1 and a device 108 - 1 (e.g., an edge router, a gateway, a proxy server, a firewall, etc.).
- Network 102 - 1 may include additional devices that are interposed between client endpoint 106 - 1 and device 108 - 1 , even though they are not illustrated in FIG. 1 .
- Client endpoint 106 - 1 may 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 network 100 .
- 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 network 100 .
- Device 108 - 1 may relay packets that are received from devices inside/outside network 102 - 1 to devices outside/inside network 102 - 1 . In relaying the packets, device 108 - 1 may translate network transport protocols of the relayed packets.
- Network 102 - 2 may include a client endpoint 106 - 2 , a device 108 - 2 (e.g., an edge router) and/or additional devices (not shown).
- Client endpoint 106 - 2 and device 108 - 2 may include similar devices as client endpoint 106 - 1 and device 108 - 1 and may operate similarly.
- FIG. 2 illustrates an exemplary network device 200 .
- Network device 200 may represent any one of devices 104 , client endpoints 106 - 1 and 106 - 2 , and devices 108 - 1 and 108 - 2 .
- network device 200 may include a processor 202 , a memory 204 , input/output components 206 , a network interface 208 , and a communication path 210 .
- network device 200 may include additional, fewer, or different components than the ones illustrated in FIG. 2 .
- network device 200 may include additional network interfaces, such as line interfaces for receiving and forwarding packets.
- Processor 202 may 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 device 200 .
- Memory 204 may 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.
- Memory 204 may 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 components 206 may 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 device 200 .
- LED light-emitting diode
- DVD Digital Video Disk
- USB Universal Serial Bus
- Network interface 208 may include any transceiver-like mechanism that enables network device 200 to communicate with other devices and/or systems.
- network interface 208 may include mechanisms for communicating via a network, such as the Internet, a wireless network, a LAN, a MAN, a WAN, etc.
- network interface 208 may include a modem, an Ethernet interface to a LAN, a line card, and/or an interface/connection for connecting network device 200 to other devices.
- Communication path 210 may provide an interface through which components of network device 200 can communicate with one another.
- FIG. 3 is a functional block diagram of one implementation of exemplary network device 200 .
- network device 200 may take the form of a server, a gateway, etc.
- network device 200 may include an operating system 302 , an application 304 , a statistics module 306 , and a protocol adaptor 308 .
- Operating system 302 may manage resources (e.g., processing cycles, memory, etc.) of network device 200 and may provide support for other components of network device 200 (e.g., an application). For example, operating system 200 may provide a Transmission Control Protocol (TCP)/IP stack. Application 304 may perform a specific task and/or provide a service to a user (e.g., an email client service).
- resources e.g., processing cycles, memory, etc.
- IP stack e.g., IP stack
- Application 304 may perform a specific task and/or provide a service to a user (e.g., an email client service).
- Statistics module 306 may collect statistics (e.g., communication performance statistics) of packets that network device 200 relays. In some implementations, statistics module 306 may obtain packet statistics for each of network interfaces (e.g., line interfaces) in network device 200 . In other implementations, statistics module 306 may collect packet statistics that pertain to network device 200 as a whole (e.g., a total number of packets that are received at or sent by network device 200 ).
- statistics module 306 may collect statistics (e.g., communication performance statistics) of packets that network device 200 relays. In some implementations, statistics module 306 may obtain packet statistics for each of network interfaces (e.g., line interfaces) in network device 200 . In other implementations, statistics module 306 may collect packet statistics that pertain to network device 200 as a whole (e.g., a total number of packets that are received at or sent by network device 200 ).
- 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.
- HTTP hypertext transfer protocol
- FTP file transfer protocol
- telnet e.g., a packet transfer protocol
- OSI Open System Interconnectivity
- statistics module 306 may obtain packet statistics from a flow table included in statistics module 306 .
- the flow table may provide statistics about a flow (e.g., a stream of packets from a source to a destination).
- statistics module 306 may 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 adaptor 308 may update a transport protocol information table (TPIT), which will be described below in greater detail.
- protocol adaptor 308 may send the information in TPIT to other protocol adaptors in other devices in network 100 and consult a transport protocol translation table (TTPT) to translate transport protocols.
- TTPT transport protocol translation table
- FIG. 4 shows an exemplary TPIT 400 .
- TPIT 400 may be included in one or more of the components in FIG. 2 and/or FIG. 3 (e.g., memory 204 ).
- TPIT 400 may include records 402 - 1 through 402 -M (hereinafter collectively referred to as records 402 and individually as record 402 - x ).
- each record 402 - x may include an interface identifier field 404 , a protocol field 406 , an application-layer protocol field 408 , a latency field 410 , and a packet count/length field 412 .
- record 402 - x may include additional, fewer, or different fields than those illustrated in FIG. 4 (e.g., an error rate field, a bandwidth field, a desired or required quality-of-service (QoS) field, an overall latency of network 100 field, etc.).
- QoS quality-of-service
- Interface identifier field 404 may identify an interface (e.g., a line interface) where packets whose statistics are stored in record 402 - x are received/sent.
- Protocol field 406 may identify a transport protocol for which record 402 - x includes the packet statistics.
- Application-layer protocol field 408 may indicate an application-layer communication protocol under which the packets originate (e.g., the HTTP, the FTP, the telnet, etc.).
- Latency field 410 may indicate an average delay that is associated with conveying the packets from an upstream device in network 100 to network device 200 .
- Packet count/length field 412 may indicate the number of packets/average lengths of packets that are received at the line interface from the upstream device.
- protocol adaptor 308 may update TPIT 400 based 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 adaptor 308 receives a packet, protocol adaptor 308 may 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 adaptor 308 may locate record 402 - x based on an interface identifier (e.g., a line card number) associated with the identified interface, the transport protocol, and the application-layer protocol. Once record 402 - x is retrieved, protocol adaptor 308 may update latency field 410 or packet count/length field 412 with new values of latency, packet counts, and/or average packet lengths.
- flow records e.g., records about flows
- sampled packets e.g., copies of the packets.
- protocol adaptor 308 may identify an interface at which the packet is received
- Protocol adaptor 308 may exchange information related to transport protocols (e.g., information in a TPIT) with other protocol adaptors in devices that are adjacent to network device 200 at the transport layer. In exchanging the information, protocol adaptor 308 may follow a specific signaling protocol. For example, assume that protocol adaptor 308 determines an average latency of packets that are routed from an upstream device to network device 200 . In such a case, protocol adaptor 308 may 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 device 200 in the shortest amount of time.
- transport protocols e.g., information in a TPIT
- protocol adaptor 308 may follow a specific signaling protocol. For example, assume that protocol adaptor 308 determines an average latency of packets that are routed from an upstream device to network device 200 . In such a case, protocol adaptor 308 may signal (e.g.,
- Protocol adaptor 308 may consult a transport protocol translation table (TPTT) for translating transport protocols.
- TPTT transport protocol translation table
- a TPTT may include TPIT 400 that has been transferred from an adjacent downstream device.
- protocol adaptor 308 may locate, within the TPTT, records 402 that match information in the packet's header, such as, for example, a length of the packet, an application-layer protocol, etc.
- protocol adaptor 308 may select record 402 - x that optimally satisfies a set of criteria (e.g., a least latency, a fewest number of errors, etc.). Subsequently, protocol adaptor 308 may send the packet in accordance with a transport protocol that is indicated in protocol field 406 of selected record 402 - x.
- FIG. 5A is a block diagram of a packet 502 before the packet is sent by protocol adaptor 308 .
- packet 502 may include headers 504 and a payload 506 .
- Headers 504 may include information about packet 502 (e.g., a source address, a destination address, a port number, a protocol, a length, etc.) at different layers of communication.
- Payload 506 may include packet data.
- FIG. 5B is a block diagram of headers 504 .
- headers 504 may include an IP header 508 and a transport protocol header 510 .
- IP header 508 may include information that pertains to layer 3 of the OSI model (e.g., a source IP address, a destination IP address, etc.).
- Transport protocol header 510 may 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 header 510 include a TCP header, a User Datagram Protocol (UDP) header, a Stream Control Transmission Protocol (SCTP) header, a Datagram Congestion Control Protocol (DCCP) header, etc.
- UDP User Datagram Protocol
- SCTP Stream Control Transmission Protocol
- DCCP Datagram Congestion Control Protocol
- protocol adaptor 308 may modify the packet by replacing transport protocol header 510 with a header of its own, herein referred to as “adaptor header,” to convey, to a downstream device, information related to transport protocol translation.
- FIG. 5C shows header 504 after protocol adaptor 308 replaces transport protocol header 510 with adaptor header 512 .
- adaptor header 512 may include a header for a selected transport protocol under which the packet will be sent from network device 200 to the downstream device.
- protocol adaptor 308 may insert an adaptor header between IP header 508 and transport protocol header 510 .
- FIG. 5D shows header 504 after protocol adaptor 308 inserts adaptor header 512 in header 504 .
- adaptor header 512 may include header 512 for the selected transport protocol. For example, assuming that protocol adaptor 308 selects the TCP, adaptor header 512 may include a TCP header.
- adaptor header 512 may or may not include information in addition to a header for the selected protocol, such as the time that adaptor header 512 is created, an identifier for adaptor header 512 , etc.
- protocol adaptor 308 indicates to an adjacent downstream device that protocol adaptor 308 will insert adaptor header 512 between IP header 508 and transport protocol header 510 in packets that are to be sent to the downstream device.
- the downstream device may correctly handle adaptor header 512 (e.g., remove adaptor header) in the packet even if adaptor header 512 is indistinguishable from a transport protocol header (e.g., a UDP header, a TCP header, etc.).
- a transport protocol header e.g., a UDP header, a TCP header, etc.
- protocol adaptor 308 in network device 200 may replace an adaptor header that is present in the packet with its own adaptor header 512 , or may remove the adaptor header.
- FIG. 6 is a functional block diagram of another implementation of exemplary network device 200 .
- network device 200 may take the form of a router or a switch.
- network device 200 may include a buffer manager 602 , routing logic 604 , and forwarding logic 606 .
- network device 200 may include additional, fewer, or different components than the ones illustrated in FIG. 6 .
- Buffer manager 602 may 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 logic 604 may 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).
- routing logic 604 may also include TPIT 400 and may provide functionalities for sending/receiving TPIT 400 or information that is included in TPIT 400 to another device in network 100 .
- routing logic 604 may distribute the information to line interfaces in network device 200 . Such mechanisms may improve transport protocol translation speed.
- Forwarding logic 606 may 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 logic 606 may be implemented on multiple components, such as network interfaces (e.g., line interfaces) in network device 200 .
- FIG. 7 is a functional block diagram of forwarding logic 606 that may be implemented on a line interface.
- forwarding logic 606 may include a forwarding module 702 , a classification table 704 , a forwarding table 706 , TPTT 708 , and a fabric interface 710 .
- forwarding logic 606 may include fewer, additional, or different components than those illustrated in FIG. 7 .
- Forwarding module 702 may include hardware and/or software for forwarding and/or classifying a packet that is received at the line interface. When forwarding module 702 receives a packet, forwarding module 702 may perform a lookup of information related to the packet in classification table 704 , process the packet based on the information, and forward the packet in accordance with information in forwarding table 706 .
- forwarding module 702 may include a protocol adaptor 712 .
- Protocol adaptor 712 may be implemented similarly and operate similarly as protocol adaptor 308 . In some implementations, however, protocol adaptor 400 's ability to exchange TPIT information may be incorporated in routing logic 604 ( FIG. 6 ) rather than in protocol adaptor 712 .
- Classification table 704 may 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 table 706 may include information for identifying an egress line interface to forward an incoming packet to a device based on the packet's network destination address.
- TPTT 708 may include similar fields and/or information as TPIT 400 or the TPTT that has been described above in connection with protocol adaptor 308 ( FIG. 3 ). In some implementations, because TPTT 708 is located within a line interface, records in TPTT 708 may not include one or more fields in records 402 , such as an interface identifier field 404 .
- Fabric interface 710 may include hardware and/or software for providing an interface to a switch fabric (not shown) that interconnects the line interfaces within network device 200 .
- Fabric interface 710 may include one or more interfacing buffers (not shown) for temporarily storing packets from forwarding module 702 .
- 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.
- fabric interface 710 may include a statistics module 714 .
- Statistics module 714 may include similar functional components and may operate similarly as statistics module 306 .
- FIG. 7 shows statistics module 714 as being included in fabric interface 710 , in different implementations, statistics module 714 may be physically positioned in forwarding module 702 or elsewhere on a signal path between forwarding module 702 and fabric interface 710 .
- FIG. 8 is a flow chart of an exemplary process 800 for translating transport protocols. Depending on the implementation, process 800 may be performed by one or more components of network device 200 .
- process 800 may begin when a packet is received (block 902 ).
- network device 200 may receive the packet from an upstream, adjacent device (e.g., a router, gateway, or an endpoint).
- adjacent device e.g., a router, gateway, or an endpoint.
- Statistics may be collected based on the packet (block 804 ).
- Network device 200 may collect the statistics in a number of different ways.
- statistics module 306 may 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.
- statistics module 306 may identify an application-layer protocol (e.g., TCP, SCTP, UDP, etc.) of the packet from the packet's header.
- statistics module 306 may obtain latency between an upstream device that sent the packet and network device 200 based on a time stamp included in adaptor header 512 and the time when the packet is received at network device 200 .
- statistics module 306 may determine the length of payload 506 of the packet.
- TPIT 400 may be updated (block 806 ).
- protocol adaptor 308 / 712 may access record 402 - x of TPIT 400 ( FIG. 4 ) based the packet's transport protocol and/or packet's application-layer protocol. If protocol adaptor 308 / 712 is 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 record 402 - x . Subsequently, protocol adaptor 308 / 712 may update various fields in record 402 - x , as described above with reference to TPIT 400 .
- protocol adaptor 308 / 712 may update packet count/length field 412 in record 402 - x . Assume that protocol adaptor 308 / 712 is implemented on a line interface, as shown in FIG. 7 . In such an instance, protocol adaptor 308 / 712 may lookup, in the flow table in statistics module 714 , 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 adaptor 308 / 712 may determine a packet count and/or an average packet length to update packet count/length field 412 .
- protocol adaptor 308 / 712 may update latency field 410 .
- protocol adaptor 308 / 712 may determine if the packet has been sent from an upstream device that includes a protocol adaptor, by determining whether protocol adaptor 308 / 712 has 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 adaptor 308 / 712 may examine adaptor header 512 to identify the time when adaptor header 512 in the packet was created in the upstream device.
- protocol adaptor 308 / 712 may determine the latency associated with sending the packet from the upstream device to network device 200 .
- the latency may be used to adjust the value of average latency that is stored in latency field 410 .
- Protocol adaptor 308 / 712 may send TPIT 400 or information included in TPIT 400 to an adjacent upstream device. If protocol adaptor 308 / 712 is located in processor 202 /memory 204 , rather than in a line interface, protocol adaptor 308 / 712 may send TPIT 400 /information in TPIT 400 to each of the devices that are adjacent to each of line interfaces in network device 200 .
- protocol adaptor 308 / 712 may send the TPIT periodically, based on a demand, or based on TPIT information from other devices in network 100 .
- protocol adaptor 308 / 712 may use the TPIT information to update a TPTT in network device 200 (e.g., TPTT 708 ).
- a new transport protocol for the packet may be selected based on a lookup within the TPTT (block 810 ).
- protocol adaptor 308 / 712 may 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 payload 506 , an overall latency of the network, and/or other information (e.g., QoS)).
- protocol adaptor 308 / 712 may dynamically select a transport protocol that optimally satisfies a set of criteria (e.g., the least latency, error rate, etc.).
- 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 payload 506 of the packet, and/or any other properties that are associated with network 100 or the packet.
- 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 header 512 may be inserted in, replaced in, or removed from header 504 of the packet (block 812 ). Based on the specific transport protocol that is selected at block 810 , protocol adaptor 308 / 712 may create adaptor header 512 that includes a header for the selected transport protocol. Furthermore, protocol adaptor 308 / 712 may insert adaptor header 512 in packet header 504 . If the packet already includes an adaptor header, protocol adaptor 308 / 712 may replace the adaptor header in packet header 504 with adaptor header 512 .
- protocol adaptor 308 / 712 may remove adaptor header 512 from the packet.
- the packet may be sent (block 814 ).
- protocol adaptor 308 / 712 may send the packet to a device in network 100 .
- the device may be similar to network device 200 (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 header 512 or transport protocol of transport protocol header 510 .
- FIG. 9 illustrates an example for translating transport protocols. The example is consistent with exemplary process 800 described above with respect to FIG. 8 .
- network 900 includes LAN 902 and LAN 904
- LAN 902 includes a personal computer 906 (e.g., a client endpoint) and an edge router 908
- LAN 904 includes an edge router 910 and a web server 912 (e.g., a server endpoint).
- 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 router 908 to edge router 910 .
- a user at personal computer 906 sends a HTTP packet over the TCP via a browser.
- the packet is transmitted to edge router 908 .
- Protocol adaptor 712 in edge router 908 looks up records 402 in 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 router 910 . Based on the protocol selection, protocol adaptor 712 creates and inserts adaptor header 512 for the UDP in the packet header.
- Edge router 910 receives the packet with adaptor header 512 from to edge router 908 . Based on a prior exchange of information related to transport protocol translation between edge router 908 and edge router 910 , protocol adaptor 712 in edge router 910 knows that the packet may include adaptor header 512 .
- Protocol adaptor 712 in edge router 910 uses the packet header to update TTIP 400 .
- protocol adaptor 712 looks up a record 402 - x that matches UDP protocol and the application-layer protocol (e.g., HTTP) and updates latency field 410 and packet count/length field 412 of record 402 - x with 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 router 912 removes adaptor header 512 from the packet header and relays the packet to web server 912 .
- edge router 910 sends updated TPIT 400 to edge router 908 .
- edge router 908 receives TPIT 400
- edge router 908 updates the TTPT.
- non-dependent blocks may represent acts that can be performed in parallel to other blocks.
Abstract
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.
Description
- 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.
- 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.
- The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate one or more embodiments described herein and, together with the description, explain the embodiments. In the drawings:
-
FIG. 1 is a diagram of an exemplary network in which concepts described herein may be implemented; -
FIG. 2 is a block diagram of an exemplary device ofFIG. 1 ; -
FIG. 3 is a functional block diagram of one implementation of the exemplary device ofFIG. 2 ; -
FIG. 4 is a block diagram of an exemplary transport protocol information table (TPIT); -
FIG. 5A is a block diagram of an exemplary packet; -
FIG. 5B is a block diagram of a header of the exemplary packet ofFIG. 6A ; -
FIG. 5C is a block diagram of the header ofFIG. 5B after a transport protocol header is replaced with an adaptor header; -
FIG. 5D is a block diagram of the header ofFIG. 5B after an adaptor header is inserted between a transport protocol header and an Internet Protocol (IP) header; -
FIG. 6 is a functional block diagram of another implementation of the exemplary device ofFIG. 2 ; -
FIG. 7 is a functional block diagram of forwarding logic ofFIG. 6 ; -
FIG. 8 is a flow chart of an exemplary process for translating transport protocols; and -
FIG. 9 is a block diagram of another network in which the concepts described herein may be implemented. - The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements.
- 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. 1 is anexemplary network 100 in which concepts described herein may be implemented. As shown,network 100 may include networks 102-1 and 102-2 (herein collectively referred to as networks 102) and devices 104-1 through 104-N (herein collectively referred to asdevices 104 and individually as device 104-x). Although not shown,network 100 may 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 networks 102 may 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
devices 104 may include a gateway, a switch, and/or a router that may relay packets from one device to another device. In relaying the packets,devices 104 may translate transport protocols of the packets. Althoughnetwork 100 may include other types of devices, for the purpose of simplicity, they are not illustrated inFIG. 1 . - As further shown in
FIG. 1 , network 102-1 may include a client endpoint 106-1 and a device 108-1 (e.g., an edge router, a gateway, a proxy server, a firewall, etc.). Network 102-1 may include additional devices that are interposed between client endpoint 106-1 and device 108-1, even though they are not illustrated inFIG. 1 . - Client endpoint 106-1 may 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
network 100. - Device 108-1 may relay packets that are received from devices inside/outside network 102-1 to devices outside/inside network 102-1. In relaying the packets, device 108-1 may translate network transport protocols of the relayed packets.
- Network 102-2 may include a client endpoint 106-2, a device 108-2 (e.g., an edge router) and/or additional devices (not shown). Client endpoint 106-2 and device 108-2 may include similar devices as client endpoint 106-1 and device 108-1 and may operate similarly.
-
FIG. 2 illustrates anexemplary network device 200.Network device 200 may represent any one ofdevices 104, client endpoints 106-1 and 106-2, and devices 108-1 and 108-2. As shown,network device 200 may include aprocessor 202, amemory 204, input/output components 206, anetwork interface 208, and acommunication path 210. In different implementations,network device 200 may include additional, fewer, or different components than the ones illustrated inFIG. 2 . For example,network device 200 may include additional network interfaces, such as line interfaces for receiving and forwarding packets. -
Processor 202 may include a processor, a microprocessor, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), and/or other processing logic capable of controllingnetwork device 200.Memory 204 may 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.Memory 204 may 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 components 206 may 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 tonetwork device 200. -
Network interface 208 may include any transceiver-like mechanism that enablesnetwork device 200 to communicate with other devices and/or systems. For example,network interface 208 may 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 interface 208 may include a modem, an Ethernet interface to a LAN, a line card, and/or an interface/connection for connectingnetwork device 200 to other devices. -
Communication path 210 may provide an interface through which components ofnetwork device 200 can communicate with one another. -
FIG. 3 is a functional block diagram of one implementation ofexemplary network device 200. In this implementation,network device 200 may take the form of a server, a gateway, etc. As shown,network device 200 may include anoperating system 302, anapplication 304, astatistics module 306, and aprotocol adaptor 308. -
Operating system 302 may manage resources (e.g., processing cycles, memory, etc.) ofnetwork device 200 and may provide support for other components of network device 200 (e.g., an application). For example,operating system 200 may provide a Transmission Control Protocol (TCP)/IP stack.Application 304 may perform a specific task and/or provide a service to a user (e.g., an email client service). -
Statistics module 306 may collect statistics (e.g., communication performance statistics) of packets that networkdevice 200 relays. In some implementations,statistics module 306 may obtain packet statistics for each of network interfaces (e.g., line interfaces) innetwork device 200. In other implementations,statistics module 306 may collect packet statistics that pertain to networkdevice 200 as a whole (e.g., a total number of packets that are received at or sent by network device 200). - 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 module 306 may obtain packet statistics from a flow table included instatistics module 306. 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 module 306 may 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 adaptor 308 may update a transport protocol information table (TPIT), which will be described below in greater detail. In addition,protocol adaptor 308 may send the information in TPIT to other protocol adaptors in other devices innetwork 100 and 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. 4 shows anexemplary TPIT 400.TPIT 400 may be included in one or more of the components inFIG. 2 and/orFIG. 3 (e.g., memory 204). As shown inFIG. 4 ,TPIT 400 may include records 402-1 through 402-M (hereinafter collectively referred to asrecords 402 and individually as record 402-x). As further shown, each record 402-x may include aninterface identifier field 404, aprotocol field 406, an application-layer protocol field 408, alatency field 410, and a packet count/length field 412. Depending on the implementation, record 402-x may 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 ofnetwork 100 field, etc.). -
Interface identifier field 404 may identify an interface (e.g., a line interface) where packets whose statistics are stored in record 402-x are received/sent.Protocol field 406 may identify a transport protocol for which record 402-x includes the packet statistics. Application-layer protocol field 408 may indicate an application-layer communication protocol under which the packets originate (e.g., the HTTP, the FTP, the telnet, etc.).Latency field 410 may indicate an average delay that is associated with conveying the packets from an upstream device innetwork 100 tonetwork device 200. Packet count/length field 412 may indicate the number of packets/average lengths of packets that are received at the line interface from the upstream device. - In one implementation,
protocol adaptor 308 may updateTPIT 400 based on flow records (e.g., records about flows), deep packet inspection properties, and/or sampled packets (e.g., copies of the packets). For example, whenprotocol adaptor 308 receives a packet,protocol adaptor 308 may 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 adaptor 308 may locate record 402-x based on an interface identifier (e.g., a line card number) associated with the identified interface, the transport protocol, and the application-layer protocol. Once record 402-x is retrieved,protocol adaptor 308 may updatelatency field 410 or packet count/length field 412 with new values of latency, packet counts, and/or average packet lengths. -
Protocol adaptor 308 may exchange information related to transport protocols (e.g., information in a TPIT) with other protocol adaptors in devices that are adjacent to networkdevice 200 at the transport layer. In exchanging the information,protocol adaptor 308 may follow a specific signaling protocol. For example, assume thatprotocol adaptor 308 determines an average latency of packets that are routed from an upstream device to networkdevice 200. In such a case,protocol adaptor 308 may 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 tonetwork device 200 in the shortest amount of time. -
Protocol adaptor 308 may consult a transport protocol translation table (TPTT) for translating transport protocols. A TPTT may includeTPIT 400 that has been transferred from an adjacent downstream device. Whenprotocol adaptor 308 receives a packet,protocol adaptor 308 may locate, within the TPTT,records 402 that 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 adaptor 308 may select record 402-x that optimally satisfies a set of criteria (e.g., a least latency, a fewest number of errors, etc.). Subsequently,protocol adaptor 308 may send the packet in accordance with a transport protocol that is indicated inprotocol field 406 of selected record 402-x. - Prior to sending the packet,
protocol adaptor 308 may modify the packet in a number of different ways.FIG. 5A is a block diagram of apacket 502 before the packet is sent byprotocol adaptor 308. As shown,packet 502 may includeheaders 504 and apayload 506.Headers 504 may include information about packet 502 (e.g., a source address, a destination address, a port number, a protocol, a length, etc.) at different layers of communication.Payload 506 may include packet data. -
FIG. 5B is a block diagram ofheaders 504. As shown,headers 504 may include anIP header 508 and atransport protocol header 510.IP header 508 may include information that pertains to layer 3 of the OSI model (e.g., a source IP address, a destination IP address, etc.).Transport protocol header 510 may 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 intransport protocol header 510 include 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 adaptor 308 may modify the packet by replacingtransport protocol header 510 with a header of its own, herein referred to as “adaptor header,” to convey, to a downstream device, information related to transport protocol translation.FIG. 5C showsheader 504 afterprotocol adaptor 308 replacestransport protocol header 510 withadaptor header 512. In one implementation,adaptor header 512 may include a header for a selected transport protocol under which the packet will be sent fromnetwork device 200 to the downstream device. - In a different implementation,
protocol adaptor 308 may insert an adaptor header betweenIP header 508 andtransport protocol header 510.FIG. 5D showsheader 504 afterprotocol adaptor 308inserts adaptor header 512 inheader 504. As inFIG. 5C ,adaptor header 512 may includeheader 512 for the selected transport protocol. For example, assuming thatprotocol adaptor 308 selects the TCP,adaptor header 512 may include a TCP header. - In
FIGS. 5C and 5D , depending on the specifics of hownetwork device 200 exchanges information related to transport protocol translation with other devices innetwork 100,adaptor header 512 may or may not include information in addition to a header for the selected protocol, such as the time thatadaptor header 512 is created, an identifier foradaptor header 512, etc. For example, in one implementation, assume thatprotocol adaptor 308 indicates to an adjacent downstream device thatprotocol adaptor 308 will insertadaptor header 512 betweenIP header 508 andtransport protocol header 510 in packets that are to be sent to the downstream device. Based on the indication, when the downstream device receives a packet fromprotocol adaptor 308, the downstream device may correctly handle adaptor header 512 (e.g., remove adaptor header) in the packet even ifadaptor header 512 is indistinguishable from a transport protocol header (e.g., a UDP header, a TCP header, etc.). - When
network device 200 receives a packet that has been modified byprotocol adaptor 308 within an upstream device,protocol adaptor 308 innetwork device 200 may replace an adaptor header that is present in the packet with itsown adaptor header 512, or may remove the adaptor header. -
FIG. 6 is a functional block diagram of another implementation ofexemplary network device 200. In the implementation,network device 200 may take the form of a router or a switch. As shown,network device 200 may include abuffer manager 602, routinglogic 604, and forwardinglogic 606. Depending on specifics of the implementation,network device 200 may include additional, fewer, or different components than the ones illustrated inFIG. 6 . -
Buffer manager 602 may 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 logic 604 may 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 logic 604 may also includeTPIT 400 and may provide functionalities for sending/receivingTPIT 400 or information that is included inTPIT 400 to another device innetwork 100. In some implementations, when routinglogic 604 receivesTPIT 400 or information inTPIT 400 from a downstream device, routinglogic 604 may distribute the information to line interfaces innetwork device 200. Such mechanisms may improve transport protocol translation speed. -
Forwarding logic 606 may 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 logic 606 may be implemented on multiple components, such as network interfaces (e.g., line interfaces) innetwork device 200. -
FIG. 7 is a functional block diagram of forwardinglogic 606 that may be implemented on a line interface. As shown, forwardinglogic 606 may include aforwarding module 702, a classification table 704, a forwarding table 706,TPTT 708, and afabric interface 710. Depending on the implementation, forwardinglogic 606 may include fewer, additional, or different components than those illustrated inFIG. 7 . -
Forwarding module 702 may include hardware and/or software for forwarding and/or classifying a packet that is received at the line interface. When forwardingmodule 702 receives a packet,forwarding module 702 may perform a lookup of information related to the packet in classification table 704, process the packet based on the information, and forward the packet in accordance with information in forwarding table 706. - As further shown in
FIG. 7 ,forwarding module 702 may include aprotocol adaptor 712.Protocol adaptor 712 may be implemented similarly and operate similarly asprotocol adaptor 308. In some implementations, however,protocol adaptor 400's ability to exchange TPIT information may be incorporated in routing logic 604 (FIG. 6 ) rather than inprotocol adaptor 712. - Classification table 704 may 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 table 706 may include information for identifying an egress line interface to forward an incoming packet to a device based on the packet's network destination address.
-
TPTT 708 may include similar fields and/or information asTPIT 400 or the TPTT that has been described above in connection with protocol adaptor 308 (FIG. 3 ). In some implementations, becauseTPTT 708 is located within a line interface, records inTPTT 708 may not include one or more fields inrecords 402, such as aninterface identifier field 404. -
Fabric interface 710 may include hardware and/or software for providing an interface to a switch fabric (not shown) that interconnects the line interfaces withinnetwork device 200.Fabric interface 710 may include one or more interfacing buffers (not shown) for temporarily storing packets from forwardingmodule 702. 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 in
FIG. 7 ,fabric interface 710 may include astatistics module 714.Statistics module 714 may include similar functional components and may operate similarly asstatistics module 306. AlthoughFIG. 7 showsstatistics module 714 as being included infabric interface 710, in different implementations,statistics module 714 may be physically positioned in forwardingmodule 702 or elsewhere on a signal path betweenforwarding module 702 andfabric interface 710. -
FIG. 8 is a flow chart of anexemplary process 800 for translating transport protocols. Depending on the implementation,process 800 may be performed by one or more components ofnetwork device 200. - As shown,
process 800 may begin when a packet is received (block 902). In one implementation,network device 200 may receive the packet from an upstream, adjacent device (e.g., a router, gateway, or an endpoint). - Statistics may be collected based on the packet (block 804).
Network device 200 may collect the statistics in a number of different ways. For example,statistics module 306 may 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 module 306 may identify an application-layer protocol (e.g., TCP, SCTP, UDP, etc.) of the packet from the packet's header. In still another example,statistics module 306 may obtain latency between an upstream device that sent the packet andnetwork device 200 based on a time stamp included inadaptor header 512 and the time when the packet is received atnetwork device 200. In yet another example,statistics module 306 may determine the length ofpayload 506 of the packet. -
TPIT 400 may be updated (block 806). To updateTPIT 400,protocol adaptor 308/712 may access record 402-x of TPIT 400 (FIG. 4 ) based the packet's transport protocol and/or packet's application-layer protocol. Ifprotocol adaptor 308/712 is 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 record 402-x. Subsequently,protocol adaptor 308/712 may update various fields in record 402-x, as described above with reference to TPIT 400. - For example,
protocol adaptor 308/712 may update packet count/length field 412 in record 402-x. Assume thatprotocol adaptor 308/712 is implemented on a line interface, as shown inFIG. 7 . In such an instance,protocol adaptor 308/712 may lookup, in the flow table instatistics module 714, 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 adaptor 308/712 may determine a packet count and/or an average packet length to update packet count/length field 412. - In another example,
protocol adaptor 308/712 may updatelatency field 410. To updatelatency field 410,protocol adaptor 308/712 may determine if the packet has been sent from an upstream device that includes a protocol adaptor, by determining whetherprotocol adaptor 308/712 has 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 adaptor 308/712 may examineadaptor header 512 to identify the time whenadaptor header 512 in the packet was created in the upstream device. By comparing the time at which the packet is received atnetwork device 200 to the time whenadaptor 512 was created,protocol adaptor 308/712 may determine the latency associated with sending the packet from the upstream device to networkdevice 200. The latency may be used to adjust the value of average latency that is stored inlatency field 410. - Information that is related to transport protocol translation may be exchanged (block 808). For example,
protocol adaptor 308/712 may sendTPIT 400 or information included inTPIT 400 to an adjacent upstream device. Ifprotocol adaptor 308/712 is located inprocessor 202/memory 204, rather than in a line interface,protocol adaptor 308/712 may sendTPIT 400/information inTPIT 400 to each of the devices that are adjacent to each of line interfaces innetwork device 200. - Depending on the implementation,
protocol adaptor 308/712 may send the TPIT periodically, based on a demand, or based on TPIT information from other devices innetwork 100. In addition, whennetwork device 200 receives the TPIT information from one or more devices innetwork 100,protocol adaptor 308/712 may use the TPIT information to update a TPTT in network device 200 (e.g., TPTT 708). - A new transport protocol for the packet may be selected based on a lookup within the TPTT (block 810). For example, in one implementation,
protocol adaptor 308/712 may 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 ofpayload 506, an overall latency of the network, and/or other information (e.g., QoS)). Subsequently,protocol adaptor 308/712 may 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
payload 506 of the packet, and/or any other properties that are associated withnetwork 100 or 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 header 512 may be inserted in, replaced in, or removed fromheader 504 of the packet (block 812). Based on the specific transport protocol that is selected atblock 810,protocol adaptor 308/712 may createadaptor header 512 that includes a header for the selected transport protocol. Furthermore,protocol adaptor 308/712 may insertadaptor header 512 inpacket header 504. If the packet already includes an adaptor header,protocol adaptor 308/712 may replace the adaptor header inpacket header 504 withadaptor header 512. - If the packet at
network device 200 is one hop away from an endpoint (e.g., a client endpoint or a server endpoint),protocol adaptor 308/712 may removeadaptor header 512 from the packet. - Once
packet header 502 is properly modified, the packet may be sent (block 814). For example,protocol adaptor 308/712 may send the packet to a device innetwork 100. The device may be similar to network device 200 (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 withadaptor header 512 or transport protocol oftransport protocol header 510. -
FIG. 9 illustrates an example for translating transport protocols. The example is consistent withexemplary process 800 described above with respect toFIG. 8 . - Assume that
network 900 includesLAN 902 andLAN 904,LAN 902 includes a personal computer 906 (e.g., a client endpoint) and anedge router 908, andLAN 904 includes anedge router 910 and a web server 912 (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 fromedge router 908 to edgerouter 910. - In the example, a user at
personal computer 906 sends a HTTP packet over the TCP via a browser. The packet is transmitted to edgerouter 908.Protocol adaptor 712 inedge router 908 looks uprecords 402 in 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 edgerouter 910. Based on the protocol selection,protocol adaptor 712 creates and insertsadaptor header 512 for the UDP in the packet header. -
Edge router 910 receives the packet withadaptor header 512 from toedge router 908. Based on a prior exchange of information related to transport protocol translation betweenedge router 908 andedge router 910,protocol adaptor 712 inedge router 910 knows that the packet may includeadaptor header 512. -
Protocol adaptor 712 inedge router 910 uses the packet header to updateTTIP 400. In particular,protocol adaptor 712 looks up a record 402-x that matches UDP protocol and the application-layer protocol (e.g., HTTP) and updateslatency field 410 and packet count/length field 412 of record 402-x with 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 router 912 removesadaptor header 512 from the packet header and relays the packet toweb server 912. - Later, at a scheduled time,
edge router 910 sends updatedTPIT 400 toedge router 908. Whenedge router 908 receivesTPIT 400,edge router 908 updates the TTPT. - 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 in
FIG. 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. - It will be apparent that aspects described herein may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement aspects does not limit the invention. Thus, the operation and behavior of the aspects were described without reference to the specific software code—it being understood that software and control hardware can be designed to implement the aspects based on the description herein.
- Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the invention. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification.
- No element, act, or instruction used in the present application should be construed as critical or essential to the implementations described herein unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Where one item is intended, the term “one” or similar language is used. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.
Claims (21)
1-20. (canceled)
21. A device comprising:
an interface to:
receive a packet;
access a table that stores communication performance statistics of transport protocols, where one or more of the communication performance statistics stored in the table are based on performance information, received by the device, from one or more other devices that have received data from the device,
where when accessing the table, the interface is to access the table based on at least one of:
a transport protocol associated with the packet,
an application-layer protocol associated with the packet, or
network latency;
compare the communication performance statistics of the transport protocols based on criteria;
select, from the transport protocols and based on the criteria, a transport protocol with an optimum communication performance statistics, of the compared communication performance statistics; and
send the packet, from the device, according to the selected transport protocol.
22. The device of claim 21 , comprising at least one of:
a gateway;
a router;
a proxy server; or
a firewall.
23. The device of claim 21 , where the packet includes at least one of:
an Internet Protocol (IP) header;
a transport protocol header; or
an adaptor header that indicates that the packet is sent according to the selected transport protocol.
24. The device of claim 23 , where the adaptor header includes a transport protocol header and a time stamp that indicates when the adaptor header was created.
25. The device of claim 21 , where when selecting the transport protocol based on the criteria, the interface is further to:
select a transport protocol, of the transport protocols, that conveys, with a least latency compared to other ones of the transport protocols, packets from the device to a downstream device.
26. The device of claim 21 , further comprising:
a processor to:
receive, from a network device, information that is to be incorporated into the table, and
provide the information to the interface; and
where the interface is further to:
incorporate the information into the table.
27. The device of claim 21 , where the transport protocols includes at least one of:
a user datagram protocol (UDP);
a transmission control protocol (TCP);
a stream control transmission protocol (SCTP); or
a datagram congestion control protocol (DCCP).
28. The device of claim 21 , where the application-layer protocol includes one of:
a hypertext transfer protocol (HTTP);
a simple mail transfer protocol (SMTP);
a telnet protocol;
a file transfer protocol (FTP);
a post office protocol (POP);
a Gopher protocol;
an Internet message access protocol (IMAP);
a network news transfer protocol (NNTP);
a real-time transport protocol (RTP); or
a session initiation protocol (SIP).
29. The device of claim 21 , further comprising:
a routing component to:
exchange routing information with other devices in a network; and
exchange information in the table with other devices in the network.
30. The device of claim 21 , where the performance information received from a particular device of the one or more other devices includes at least one of:
network latency of another packet sent from the device to the particular device, or
length of a payload of another packet sent from the device to the particular device.
31. A method, comprising:
receiving, by a device, statistics related to transport protocols;
incorporating, by the device, the received statistics into a table;
receiving, by the device, a packet;
accessing, by the device, the table to retrieve, based on information in a header of the packet, communication performance statistics of transport protocols;
comparing, by the device, the communication performance statistics of the transport protocols based on criteria;
selecting, by the device, a transport protocol with an optimum communication performance statistics based on the criteria;
modifying, by the device, the header of the packet based on the selected transport protocol; and
sending, by the device and in accordance with the selected transport protocol, the packet to a downstream device in a network.
32. The method of claim 31 , where the received and incorporated statistics are received from the downstream device prior to receiving the packet, and where the received and incorporated statistics further relate to packets sent by the device to the downstream device.
33. The method of claim 31 , where the device includes at least one of:
a gateway;
a router;
a proxy server; or
a firewall.
34. The method of claim 31 , where the packet includes at least one of:
an Internet Protocol (IP) header;
a transport protocol header; or
an adaptor header that indicates that the packet is sent according to the selected transport protocol.
35. The method of claim 34 , where the adaptor header includes a transport protocol header and a time stamp that indicates when the adaptor header was created.
36. The method of claim 31 , where selecting the transport protocol based on the criteria includes:
selecting a transport protocol, of the transport protocols, that conveys, with a least latency compared to other ones of the transport protocols, packets from the device to a downstream device.
37. A non-transitory computer-readable memory device, having instructions stored thereon, the instructions comprising:
one or more instructions to receive statistics related to transport protocols;
one or more instructions to incorporate the received statistics into a table;
one or more instructions to receive a packet;
one or more instructions to retrieve, from the table and based on information in a header of the packet, communication performance statistics of transport protocols;
one or more instructions to compare the communication performance statistics of the transport protocols based on criteria;
one or more instructions to select a transport protocol with an optimum communication performance statistics based on the criteria;
one or more instructions to modify the header of the packet based on the selected transport protocol; and
one or more instructions to send, in accordance with the selected transport protocol, the packet to a downstream device in a network.
38. The computer-readable memory device of claim 37 , where the one or more instructions to select the transport protocol based on the criteria include:
one or more instructions to select a transport protocol, of the transport protocols, that conveys, with a least latency compared to other ones of the transport protocols, packets from the device to a downstream device.
39. The computer-readable memory device of claim 37 , where the transport protocols includes at least one of:
a user datagram protocol (UDP);
a transmission control protocol (TCP);
a stream control transmission protocol (SCTP); or
a datagram congestion control protocol (DCCP).
40. The computer-readable memory device of claim 37 , further comprising:
one or more instructions to exchange routing information with other devices in a network; and
one or more instructions to exchange information in the table with other devices in the network.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/035,679 US20110142063A1 (en) | 2008-05-05 | 2011-02-25 | Multi-link transport protocol translation |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/115,058 US7920569B1 (en) | 2008-05-05 | 2008-05-05 | Multi-link transport protocol translation |
US13/035,679 US20110142063A1 (en) | 2008-05-05 | 2011-02-25 | Multi-link transport protocol translation |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/115,058 Continuation US7920569B1 (en) | 2008-05-05 | 2008-05-05 | Multi-link transport protocol translation |
Publications (1)
Publication Number | Publication Date |
---|---|
US20110142063A1 true US20110142063A1 (en) | 2011-06-16 |
Family
ID=43805889
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/115,058 Expired - Fee Related US7920569B1 (en) | 2008-05-05 | 2008-05-05 | Multi-link transport protocol translation |
US13/035,679 Abandoned US20110142063A1 (en) | 2008-05-05 | 2011-02-25 | Multi-link transport protocol translation |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/115,058 Expired - Fee Related US7920569B1 (en) | 2008-05-05 | 2008-05-05 | Multi-link transport protocol translation |
Country Status (1)
Country | Link |
---|---|
US (2) | US7920569B1 (en) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110087795A1 (en) * | 2009-10-13 | 2011-04-14 | Research In Motion Limited | Methods and apparatus for intelligent selection of a transport protocol for content streaming |
US9083605B2 (en) | 2012-04-30 | 2015-07-14 | International Business Machines Corporation | Providing services to virtual overlay network traffic |
US20150326696A1 (en) * | 2014-05-09 | 2015-11-12 | Google Inc. | System and method for adapting to network protocol updates |
US20160316022A1 (en) * | 2015-04-23 | 2016-10-27 | Fujitsu Limited | Communication device, communication processing method, and storage medium |
US10432754B2 (en) | 2015-09-16 | 2019-10-01 | Profire Energy, Inc | Safety networking protocol and method |
US10514683B2 (en) | 2015-09-16 | 2019-12-24 | Profire Energy, Inc. | Distributed networking system and method to implement a safety state environment |
US10949096B2 (en) * | 2017-12-18 | 2021-03-16 | Western Digital Technologies, Inc. | Method using logical based addressing for latency reduction |
US11165893B2 (en) * | 2018-02-28 | 2021-11-02 | Deutsche Telekom Ag | Techniques for packet data conversion |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE102008030939A1 (en) * | 2008-07-02 | 2010-01-07 | Deutsche Thomson Ohg | Method and device for managing data transmission in a network |
US8571049B2 (en) * | 2009-11-24 | 2013-10-29 | Verizon Patent And Licensing, Inc. | Setting and changing queue sizes in line cards |
JPWO2016132899A1 (en) | 2015-02-17 | 2017-11-24 | ソニー株式会社 | Transmission device, transmission method, reception device, and reception method |
US10491525B2 (en) * | 2015-03-10 | 2019-11-26 | Huawei Technologies Co., Ltd. | Traffic engineering feeder for packet switched networks |
JP2021043801A (en) * | 2019-09-12 | 2021-03-18 | 株式会社東芝 | Electronic device, electronic device system, and magnetic disk apparatus |
Citations (27)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5425028A (en) * | 1992-07-16 | 1995-06-13 | International Business Machines Corporation | Protocol selection and address resolution for programs running in heterogeneous networks |
US5805824A (en) * | 1996-02-28 | 1998-09-08 | Hyper-G Software Forchungs-Und Entwicklungsgesellschaft M.B.H. | Method of propagating data through a distributed information system |
US6112226A (en) * | 1995-07-14 | 2000-08-29 | Oracle Corporation | Method and apparatus for concurrently encoding and tagging digital information for allowing non-sequential access during playback |
US6359896B1 (en) * | 1998-02-27 | 2002-03-19 | Avaya Technology Corp. | Dynamic selection of interworking functions in a communication system |
US20020087729A1 (en) * | 2000-09-11 | 2002-07-04 | Edgar David A. | System, method and computer program product for optimization and acceleration of data transport and processing |
US20020169894A1 (en) * | 2001-02-22 | 2002-11-14 | Mourad Takla | Link layer device and method of translating packets between transport protocols |
US20030002438A1 (en) * | 2001-07-02 | 2003-01-02 | Hitachi, Ltd. | Packet forwarding apparatus with packet controlling functions |
US20040028009A1 (en) * | 2002-08-06 | 2004-02-12 | Motorola, Inc. | Method and apparatus for effecting a seamless handoff between IP connections |
US6757255B1 (en) * | 1998-07-28 | 2004-06-29 | Fujitsu Limited | Apparatus for and method of measuring communication performance |
US20040165604A1 (en) * | 2003-02-20 | 2004-08-26 | Jong-Sang Oh | Distributed router with ping-pong preventing function and ping-pong preventing method using the same |
US20060002354A1 (en) * | 2004-07-03 | 2006-01-05 | Samsung Electronics Co., Ltd. | System and method of routing in a router in a communications system |
US7028051B1 (en) * | 2000-09-29 | 2006-04-11 | Ugs Corp. | Method of real-time business collaboration |
US7035207B2 (en) * | 2002-06-05 | 2006-04-25 | Eka Systems, Inc | System and method for forming, maintaining and dynamic reconfigurable routing in an ad-hoc network |
US20060239297A1 (en) * | 2005-04-21 | 2006-10-26 | Microsoft Corporation | Transport abstraction for multiparty replication |
US20060262783A1 (en) * | 2005-05-20 | 2006-11-23 | Plamen Nedeltchev | Approach for implementing IPsec in Performance Enhancing Proxy (PEP) environments |
US20070091918A1 (en) * | 2005-10-21 | 2007-04-26 | Microsoft Corporation | Application-level multicasting architecture |
US20070223379A1 (en) * | 2006-02-07 | 2007-09-27 | Asankya Networks, Inc. | Systems and Methods of Improving Performance of Transport Protocols |
US20070237155A1 (en) * | 2006-04-10 | 2007-10-11 | Network Equipment Technologies, Inc. | Determination of SIP transport to reduce call setup delays |
US20070274219A1 (en) * | 2006-05-26 | 2007-11-29 | Lockheed Martin Corporation | Method and system for routing network communications |
US20080144624A1 (en) * | 2006-12-14 | 2008-06-19 | Sun Microsystems, Inc. | Method and system for time-stamping data packets from a network |
US20080144663A1 (en) * | 2006-12-14 | 2008-06-19 | Sun Microsystems, Inc. | Method and system for using bayesian network inference for selection of transport protocol algorithm |
US20080243579A1 (en) * | 2006-01-19 | 2008-10-02 | International Business Machines Corporation | Methods and Apparatus for Coordinating and Selecting Protocols for Resources Acquisition from Multiple Resource Managers |
US7471669B1 (en) * | 2004-09-30 | 2008-12-30 | Nortel Networks Limited | Routing of protocol data units within a communication network |
US7529255B2 (en) * | 2005-04-21 | 2009-05-05 | Microsoft Corporation | Peer-to-peer multicasting using multiple transport protocols |
US7536466B2 (en) * | 2003-03-18 | 2009-05-19 | Sony Corporation | Sending-receiving system, sender apparatus, sending method, receiver apparatus, receiving method, recording medium, and program for improving communication reliability |
US20090216880A1 (en) * | 2008-02-26 | 2009-08-27 | Viasat, Inc. | Methods and Systems for Dynamic Transport Selection Based on Last Mile Network Detection |
US7653722B1 (en) * | 2005-12-05 | 2010-01-26 | Netapp, Inc. | Server monitoring framework |
-
2008
- 2008-05-05 US US12/115,058 patent/US7920569B1/en not_active Expired - Fee Related
-
2011
- 2011-02-25 US US13/035,679 patent/US20110142063A1/en not_active Abandoned
Patent Citations (27)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5425028A (en) * | 1992-07-16 | 1995-06-13 | International Business Machines Corporation | Protocol selection and address resolution for programs running in heterogeneous networks |
US6112226A (en) * | 1995-07-14 | 2000-08-29 | Oracle Corporation | Method and apparatus for concurrently encoding and tagging digital information for allowing non-sequential access during playback |
US5805824A (en) * | 1996-02-28 | 1998-09-08 | Hyper-G Software Forchungs-Und Entwicklungsgesellschaft M.B.H. | Method of propagating data through a distributed information system |
US6359896B1 (en) * | 1998-02-27 | 2002-03-19 | Avaya Technology Corp. | Dynamic selection of interworking functions in a communication system |
US6757255B1 (en) * | 1998-07-28 | 2004-06-29 | Fujitsu Limited | Apparatus for and method of measuring communication performance |
US20020087729A1 (en) * | 2000-09-11 | 2002-07-04 | Edgar David A. | System, method and computer program product for optimization and acceleration of data transport and processing |
US7028051B1 (en) * | 2000-09-29 | 2006-04-11 | Ugs Corp. | Method of real-time business collaboration |
US20020169894A1 (en) * | 2001-02-22 | 2002-11-14 | Mourad Takla | Link layer device and method of translating packets between transport protocols |
US20030002438A1 (en) * | 2001-07-02 | 2003-01-02 | Hitachi, Ltd. | Packet forwarding apparatus with packet controlling functions |
US7035207B2 (en) * | 2002-06-05 | 2006-04-25 | Eka Systems, Inc | System and method for forming, maintaining and dynamic reconfigurable routing in an ad-hoc network |
US20040028009A1 (en) * | 2002-08-06 | 2004-02-12 | Motorola, Inc. | Method and apparatus for effecting a seamless handoff between IP connections |
US20040165604A1 (en) * | 2003-02-20 | 2004-08-26 | Jong-Sang Oh | Distributed router with ping-pong preventing function and ping-pong preventing method using the same |
US7536466B2 (en) * | 2003-03-18 | 2009-05-19 | Sony Corporation | Sending-receiving system, sender apparatus, sending method, receiver apparatus, receiving method, recording medium, and program for improving communication reliability |
US20060002354A1 (en) * | 2004-07-03 | 2006-01-05 | Samsung Electronics Co., Ltd. | System and method of routing in a router in a communications system |
US7471669B1 (en) * | 2004-09-30 | 2008-12-30 | Nortel Networks Limited | Routing of protocol data units within a communication network |
US20060239297A1 (en) * | 2005-04-21 | 2006-10-26 | Microsoft Corporation | Transport abstraction for multiparty replication |
US7529255B2 (en) * | 2005-04-21 | 2009-05-05 | Microsoft Corporation | Peer-to-peer multicasting using multiple transport protocols |
US20060262783A1 (en) * | 2005-05-20 | 2006-11-23 | Plamen Nedeltchev | Approach for implementing IPsec in Performance Enhancing Proxy (PEP) environments |
US20070091918A1 (en) * | 2005-10-21 | 2007-04-26 | Microsoft Corporation | Application-level multicasting architecture |
US7653722B1 (en) * | 2005-12-05 | 2010-01-26 | Netapp, Inc. | Server monitoring framework |
US20080243579A1 (en) * | 2006-01-19 | 2008-10-02 | International Business Machines Corporation | Methods and Apparatus for Coordinating and Selecting Protocols for Resources Acquisition from Multiple Resource Managers |
US20070223379A1 (en) * | 2006-02-07 | 2007-09-27 | Asankya Networks, Inc. | Systems and Methods of Improving Performance of Transport Protocols |
US20070237155A1 (en) * | 2006-04-10 | 2007-10-11 | Network Equipment Technologies, Inc. | Determination of SIP transport to reduce call setup delays |
US20070274219A1 (en) * | 2006-05-26 | 2007-11-29 | Lockheed Martin Corporation | Method and system for routing network communications |
US20080144624A1 (en) * | 2006-12-14 | 2008-06-19 | Sun Microsystems, Inc. | Method and system for time-stamping data packets from a network |
US20080144663A1 (en) * | 2006-12-14 | 2008-06-19 | Sun Microsystems, Inc. | Method and system for using bayesian network inference for selection of transport protocol algorithm |
US20090216880A1 (en) * | 2008-02-26 | 2009-08-27 | Viasat, Inc. | Methods and Systems for Dynamic Transport Selection Based on Last Mile Network Detection |
Cited By (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8892757B2 (en) * | 2009-10-13 | 2014-11-18 | Blackberry Limited | Methods and apparatus for intelligent selection of a transport protocol for content streaming |
US20110087795A1 (en) * | 2009-10-13 | 2011-04-14 | Research In Motion Limited | Methods and apparatus for intelligent selection of a transport protocol for content streaming |
US9699277B2 (en) | 2012-04-30 | 2017-07-04 | International Business Machines Corporation | Providing services to virtual overlay network traffic |
US9083605B2 (en) | 2012-04-30 | 2015-07-14 | International Business Machines Corporation | Providing services to virtual overlay network traffic |
US9106508B2 (en) | 2012-04-30 | 2015-08-11 | International Business Machines Corporation | Providing services to virtual overlay network traffic |
US20150326696A1 (en) * | 2014-05-09 | 2015-11-12 | Google Inc. | System and method for adapting to network protocol updates |
US9503552B2 (en) * | 2014-05-09 | 2016-11-22 | Google Inc. | System and method for adapting to network protocol updates |
CN106256112A (en) * | 2014-05-09 | 2016-12-21 | 谷歌公司 | For adapting to the system and method that procotol updates |
CN113765892A (en) * | 2014-05-09 | 2021-12-07 | 谷歌有限责任公司 | System, method, and computer readable medium for adapting to network protocol updates |
US20160316022A1 (en) * | 2015-04-23 | 2016-10-27 | Fujitsu Limited | Communication device, communication processing method, and storage medium |
US10432754B2 (en) | 2015-09-16 | 2019-10-01 | Profire Energy, Inc | Safety networking protocol and method |
US10514683B2 (en) | 2015-09-16 | 2019-12-24 | Profire Energy, Inc. | Distributed networking system and method to implement a safety state environment |
US10992787B2 (en) | 2015-09-16 | 2021-04-27 | Profire Energy, Inc. | Safety networking protocol and method |
US11314235B2 (en) | 2015-09-16 | 2022-04-26 | Profire Energy, Inc. | Systems to implement a safety state environment among control modules |
US10949096B2 (en) * | 2017-12-18 | 2021-03-16 | Western Digital Technologies, Inc. | Method using logical based addressing for latency reduction |
US11165893B2 (en) * | 2018-02-28 | 2021-11-02 | Deutsche Telekom Ag | Techniques for packet data conversion |
Also Published As
Publication number | Publication date |
---|---|
US7920569B1 (en) | 2011-04-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7920569B1 (en) | Multi-link transport protocol translation | |
EP3654589B1 (en) | Predicting application quality of experience metrics using adaptive machine learned probes | |
US11575611B2 (en) | Quality of service in packet networks | |
US7746781B1 (en) | Method and apparatus for preserving data in a system implementing Diffserv and IPsec protocol | |
US8432807B2 (en) | Network traffic analysis using a flow table | |
US8942242B2 (en) | Method and apparatus for self-learning of VPNS from combinations of unidirectional tunnels in MPLS/VPN networks | |
US8085775B1 (en) | Identifying flows based on behavior characteristics and applying user-defined actions | |
JP4659116B2 (en) | Closed queue system and method for supporting quality of service | |
CN105337852B (en) | The more method and device of the processing mode of new service flow message | |
JP5966092B2 (en) | Content-based overload protection | |
JP2009542048A (en) | System and method for general data transparent rules to support quality of service | |
CN111788803A (en) | Flow management in a network | |
EP3094053A1 (en) | Predictive egress packet classification for quality of service | |
EP3836498A1 (en) | Combined input and output queue for packet forwarding in network devices | |
US8571049B2 (en) | Setting and changing queue sizes in line cards | |
US11652739B2 (en) | Service related routing method and apparatus | |
KR20090039768A (en) | Methods for providing quality of service by applying back-pressure in sequencing | |
TWI700912B (en) | Queuing system to predict packet lifetime in a computing device | |
WO2019061302A1 (en) | Message processing method and device | |
JP4597102B2 (en) | Packet switching equipment | |
JP3875911B2 (en) | Frame data relay device | |
Shi-Hua et al. | A kind of routing mechanism based on IPv6 and differentiated services |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |