JP2008518531A - Method and apparatus for switching between different protocol implementations - Google Patents

Abstract

  An apparatus for switching between different implementations of a transport protocol is provided. The apparatus includes an upper transport interface for connecting a plurality of different transport protocol implementations to a layer above the transport layer, and the plurality of different transport protocol implementations to a layer below the transport layer. A lower transport interface for connecting to the lower transport interface, the upper transport interface and the lower transport interface switching between the different transport protocol implementations based on switching information It is comprised as follows. The apparatus may also be configured between the upper transport interface and the plurality of different transport protocol implementations so that a transport protocol implementation that provides an optimized data flow for a communication session is selected. And a control module for determining the switching information for switching each of the connections between the lower transport interface and the plurality of different transport protocol implementations.

Description

  The present invention relates to a method and apparatus for switching between different protocol implementations, in particular for switching between different implementations of TCP.

  In recent years, networking between computers and other computing communication devices such as personal digital assistants (PDAs) and mobile phones has become a major issue. In particular, the individual electronic devices that are born as a result of the Internet's explosive growth with emerging mobile networking technologies (eg GSM, WLAN, GPRS, i-mode, UMTS, etc.) can be connected to single or multiple networks. There is an increasing demand to enable them to communicate with each other.

  A wide variety of networking methods and protocols are used to connect the two devices. They use different protocols and comply with different standards (for example, GSM standards for mobile phones, UMTS standards for third generation mobile phones, IEEE 802.11 standards for wireless LANs, to name a few). Probably the most widely used standard for communication between two computers or devices is a protocol commonly used for the Internet called TCP / IP (transmission control protocol / internet protocol).

  To define and describe such standards and protocols, the architecture is usually described with reference to a multi-layer model. The most widely used model among the multi-layer models is the “ISO-OSI layer model”. This model consists of seven layers from the top layer called the application layer to the bottom layer called the physical layer, which defines electrical signals and signal structures at a very low level in the network. FIG. 1 schematically shows this model.

  For the description and definition of TCP / IP, a four-layer model as shown in FIG. 2 is often referred to. This TCP / IP model includes a network layer as the lowest layer. In this network layer, token-ring LAN, Ethernet LAN, X. Specific network specifications such as 25 communications are defined. Other examples not shown include wireless LAN, GSM communication, and the like.

  Above the network layer is an Internet layer that is responsible for processing Internet protocols. A so-called transport layer for processing a transmission control protocol (TCP) is arranged on the Internet layer. FIG. 2 also shows another transport layer protocol. It is called the user datagram protocol (UDP) and works a little differently than the transmission control protocol.

  On the transport layer, as shown in FIG. 2, an application layer in charge of application processing is arranged.

  From these figures, the transport layer having the transmission control protocol (TCP) is a layer specific to the characteristics of the network or the underlaying network (in FIG. 1, the network layer and the data link layer). It can be recognized that it is in the physical layer, or in FIG. 2, on the Internet layer and the network layer. Thanks to this, the transmission control protocol (TCP) in particular is relatively independent from the underlying structure of the network.

  However, because there are still significant differences between networks that can be placed below the transport layer, certain underlay network structures (eg, fixed wired such as GSM networks, wireless LANs, and Ethernet) Optimization for individual networks has resulted in the development of different flavors of TCP adapted to LAN). For these different network structures, slightly different versions of TCP have been developed that are optimized for the structure of individual underlay networks.

  For example, in the case of a fixed wired network, conventional TCP interprets segment loss as an indication of network congestion and adjusts the transmission rate accordingly. However, if the mobile network is an underlying network, there can be other reasons besides network congestion regarding the loss of segments. Therefore, it may be practically unnecessary to adjust the transmission rate in response to lost segments. In order to handle the pure performance of the classic TCP version over weak links and high loss rate links, special flavored TCPs have been developed that can be applied, for example, in the case of weak links.

  Similarly, because TCP has a window size adaptation problem inherent in the conventional TCP implementation, in many cases, it cannot effectively utilize the entire bandwidth available on a link. . Other cases where traditional or classic TCP implementations do not provide optimal performance are, for example, high latency (eg, satellite links). As a result, over the years, a wide variety of different TCP implementations and extensions have been proposed in different contexts, such as vulnerable wireless links, high speed links, and high latency links. These versions result in significant performance improvements in each of these cases. However, these optimizations are limited to the specific application for which they are given.

  Examples of different flavor TCPs include Reno TCP, Tahoe TCP, Las Vegas TCP, and Sack TCP. These flavors of TCP differ, for example, in how lost packets are handled, for example, in different flow rate control mechanisms or restart mechanisms. Reno TCP includes, for example, high-speed retransmission and is therefore generally more efficient than Tahoe TCP for high loss networks. This is because it does not go into slow start for all packet losses as Tahoe TCP does.

  In principle, TCP / IP with different flavors or implementations can communicate with each other, but in the case of communication between two different TCP / IP implementations, the resulting data flow Are not optimized in all cases. These problems are particularly important in recent years as heterogeneous networks and communication links that are even time-varying with respect to the underlying infrastructure (structure) are becoming more common. For example, a notebook computer or PDA may be connected to a fixed wired network at some point in time, but when a user moves, the structure of the underlay network may be a WLAN infrastructure such as a hot spot in a cafeteria or a notebook. May change to a GSM network structure that uses a corresponding adapter card that plugs into a type computer. This means that the appropriateness of a TCP implementation may change over time, and as a result, the resulting data flow may not be optimized.

  In view of the above, it is an object of the present invention to provide a solution for overcoming these drawbacks.

To solve the above problems, the present invention provides an apparatus for switching between different implementations of transport protocols. The device is
Several different transport protocols,
An upper transport interface for connecting the plurality of different transport protocol implementations with a layer above the transport layer;
A lower transport interface for connecting the plurality of different transport protocol implementations with a layer below the transport layer;
The upper transport interface and the lower transport interface are adapted to switch a connection between the different transport protocol implementations based on switching information;
A connection between the upper transport interface and the plurality of different transport protocol implementations such that a transport protocol implementation that provides an optimized data flow for a communication session is selected; And a control module for determining the switching information for switching each of a connection between a lower transport interface and the plurality of different transport protocol implementations.

  The device allows optimization of the data flow of a communication session by switching between different transport protocol implementations. This is because the most suitable transport protocol implementation under a given condition can be determined and selected and the data flow through the selected TCP implementation can be routed. Furthermore, by providing a switching function with the ability to determine switching information, it is possible to use an existing TCP implementation and switch an existing TCP implementation.

  By providing a protocol implementation that is actually different than one general protocol version, the device can take advantage of an existing protocol implementation and is therefore specifically implemented in an existing system (legacy system). Sometimes it is advantageous.

  In this apparatus, as one aspect, the control module determines one or more characteristics representative of the type of network structure implemented below the transport layer, and the transport protocol is underlayed. It includes a module that determines the transport protocol to be selected to accommodate the underlying network structure. By determining the characteristics of the structure of the underlay network, the parameters that have the greatest impact on the performance of a given transport protocol version are determined and used as a basis for determining which TCP version to use. Used. This makes it possible to adapt the switching device to a given network condition particularly effectively.

  In this apparatus, as one aspect thereof, the module for determining the underlying network characteristics includes a module for determining the characteristics of the underlay network using the functions of an existing operating system. It is a waste.

  By utilizing existing operating system functions, the implementation of the module that determines the characteristics of the underlay network is considerably simplified.

  In this apparatus, as one aspect, the module for determining the characteristics of the underlay network transmits a probing signal, evaluates a response to the probing signal, and determines the characteristics of the underlay network based on the evaluation. The module to be included is included.

  Probing mechanisms are advantageous when simpler methods such as operating system queries are not available. In addition, the actual behavior of the network can be determined through probing, rather than just the underlying hardware components or structure, so that the choice of transport protocol implementation is simply a look at the underlying hardware. Sometimes it is possible to adapt to actual behavior that may differ from the expected behavior.

  In this apparatus, as one aspect, the module for determining the characteristics of the underlay network establishes communication with the other endpoint of the communication session, and the corresponding module at the other endpoint of the communication session. And a module for negotiating an appropriate transport protocol implementation session used in the communication session.

  Direct negotiation makes it possible to take into account not only the situation at the communication endpoint where the switching device is located but also the situation at the other communication endpoint. This allows a better adapted selection of the transport protocol to be used, and also prevents the conversion of header parameters, for example, when switching should be performed during runtime. There is an advantage that it becomes necessary.

  In one aspect of the apparatus, the control module is configured to switch between the different transport protocol implementations during runtime (runtime) during a currently running communication session. This is particularly advantageous if, for example, the condition changes because one of the communicating parties has moved and a switch to another transport protocol implementation becomes necessary or at least desirable.

In this apparatus, as one aspect thereof, the control module is
A module for triggering the start of the new transport protocol implementation used to switch to a new transport protocol implementation during runtime;
Transforms the contents of the TCP header of the currently running transport protocol session so that the header sent to the newly started TCP implementation and the header sent from the newly started TCP are currently executed A module for matching with the TCP header sent and received by the transport protocol implementation at the other communication endpoint of the middle communication session.

  Using such independent switching requires only minor modifications to existing systems and makes the switching mechanism relatively easy to implement. Furthermore, this independent switching can be performed in a manner that is transparent to the application layer so that the application layer is unaware of the underlying changes. This means that the “session” being executed in the application layer does not change and is not interrupted. In addition to the transport protocol implementation used by the other communication endpoint, the application layer at both communication endpoints is also unaware of switching between different transport protocol implementations.

In this apparatus, as one aspect thereof, the control module is
A module that extracts header data from a pre-switch transport protocol session that is to be switched to a different transport protocol implementation;
Inserting the extracted transport protocol session header data into the newly opened transport protocol session so that the newly opened transport protocol session has a different transport protocol implementation. And a module that enables the transport protocol session before switching to be resumed.

  By directly injecting the transport protocol header parameters into the new transport protocol connection, transcoding of the header data becomes unnecessary. Furthermore, this can be done in a manner that is transparent to the application layer. In other words, the application layer at the top of the TCP layer is unaware of changes in the underlying TCP implementation being used.

In this apparatus, as one aspect thereof, the control module is
If the currently executing transport protocol session is switched to a different transport protocol implementation at the first communication endpoint, the corresponding at the corresponding second communication endpoint at which switching should be performed. Negotiating with the module, both control modules at their communication endpoints open a new transport protocol session targeting a different transport protocol implementation, and the traffic in progress is It comprises a module that allows it to be resumed through a newly opened transport protocol session and the different transport protocol implementations at both communication endpoints.

  Such fully coordinated switching eliminates the need to insert header data into a new transport protocol session. This is because it is possible to establish completely new (TCP) sessions on both communication endpoints. This can also be done in a manner that is executed at the application layer and remains sufficiently transparent to the application using the communication session.

  In this apparatus, as one aspect thereof, the control module is configured to receive a trigger signal for triggering switching to a different transport protocol implementation.

  By receiving the trigger signal, it is possible to deal with external effects, such as any other conditions that may affect handover, service quality change, or switching decisions.

In this apparatus, as one aspect thereof, the trigger signal is:
Handover between mobile communication sessions;
Quality of service changes during the currently running communication session;
Generated in response to any one of the hardware or software module changes used in the currently executing communication session.

In order to solve the above problems, the present invention also provides a method for switching between different implementations of the transport protocol. This method
Connecting the different transport protocol implementations with an upper transport interface to connect the different implementations of the transport protocol with a layer above the transport layer;
Connecting the plurality of different transport protocol implementations with a lower transport interface to connect the plurality of different implementations of the transport protocol with a layer below a transport layer;
Switching between a connection between the upper transport interface and the different transport protocol implementation and a connection between the lower transport interface and the different transport protocol implementation based on switching information, respectively. When,
A connection between the upper transport interface and the plurality of different transport protocol implementations such that a transport protocol implementation that provides an optimized data flow for a communication session is selected; Determining the switching information for switching each of a connection between a lower transport interface and the plurality of different transport protocol implementations.

  The above method can be performed by the apparatus of the present invention.

  FIG. 3 schematically shows a general protocol stack in a TCP / IP network. An IP (Internet Protocol) layer L3 exists above the lower two layers L1 (physical layer) and L2 (network layer), and a transport layer that implements TCP according to the present embodiment is disposed on the uppermost layer. Has been. One or more sessions are maintained through corresponding socket interfaces located above the transport layer implementing TCP.

  According to an embodiment of the present invention, the transport layer shown in FIG. 3 is implemented by a switching device described next with reference to FIG. FIG. 4 shows a communication link between communication endpoint A and another communication endpoint B. Both endpoints in this embodiment are located above the application layer, which can be a process running on a computer, a mobile phone, a PDA, a notebook computer with a WLAN interface, or a desktop computer, a smartphone, etc. Can be provided. A device or process that implements the communication end point A passes through the switching device SWA that implements the transport layer, passes through the Internet protocol stack layers L1 to L3 on the A side, and the general Internet IN as shown in FIG. Devices or processes that implement a communication endpoint B, typically through multiple nodes, through B-side Internet protocol stack layers L1-L3, and through switch B and finally to endpoint B Connected to.

  The switching devices SWA and SWB each implement a plurality of different transport protocol implementations optimized for different underlay network structures. Switching devices SWA and SWB switch between these different implementations so that traffic from A to B and from B to A is through the TCP implementation most suitable for the characteristics of a given underlying network. It can be routed. For example, device A is a laptop computer connected to a fixed wired Ethernet (Ethernet) to establish a previous connection with device B, which may be, for example, a company server of an employer of a user who owns device A There are cases. However, the user leaves the office and as a result the fixed wired connection is disconnected and then the user provides a WLAN hotspot (through which the user wants to connect to Server B over the Internet) You may end up in the area that is being used. This means that the characteristics of the A side underlay network can change, which can be advantageous in changing the TCP implementation used for the connection. The switching device in one embodiment detects the characteristics of the underlay network and appropriately selects one of the provided TCP implementations used for the communication session. It should be noted that this determination and selection can be performed even if no switching device SWB is provided on the B side. This means that switching is performed without the user being aware that the upper and lower layers of the transport layer on the A side and also on the B side are unaware of the switching.

  In the case where both communication endpoints are equipped with switching devices as shown in FIG. 4, adaptation can be performed on both sides of the communication link.

  Furthermore, as a further embodiment, the switching device SWA can connect to the switching device SWB and negotiate an appropriate TCP implementation to be used for the communication session between A and B. is there.

  Referring now to FIG. 5, one embodiment of a switching device according to the present invention (eg, devices SWA and SWB in FIG. 4) will be described in more detail. As can be seen from FIG. 5, the present embodiment has two different TCP implementations labeled TCPx and TCPy. They may indicate, for example, a TCP implementation (TCPx) optimized for a fixed wired LAN and a further TCP implementation (TCPy) optimized for a wireless LAN. Under these two TCP implementations, an interface labeled “LTI (lower transport interface)” that connects two implementations having different TCP flavors with the IP layer is placed. Similarly, on top of the two TCP implementations, there is another labeled "UTI (upper transport interface)" that connects the two TCP implementations with a socket interface that establishes a connection to the application layer. An interface exists. The two TCP implementations TCPx and TCPy may be standard TCP implementations connected to the lower transport interface LTI and the upper transport interface UTI, respectively.

  In a configuration such as that shown in FIG. 5, the segments arriving via layer L1, layer L2, and layer L3 are routed and made “correct” or “optimized” through the lower transport interface LTI. “It can lead to TCP implementation. This “correct” or “optimized” TCP implementation can be either TCPx or TCPy, depending on the network characteristics of the lower layers below the transport layer. As can be seen from FIG. 5, the upper and lower transport interfaces can “switch” different TCP implementations depending on which is most appropriate. The decision as to which TCP implementation is used can be made depending on the characteristics of the lower layer underlay network. Here, the characteristic may mean, for example, what kind of network connection (for example, fixed wired Ethernet, WLAN, Gigabit Ethernet, GSM, etc.) is used with the communication partner. Based on the characteristics of these underlay networks, a TCP implementation is chosen, and data is sent from the chosen TCP implementation to the upper interface and from there to the socket interface.

  In the reverse case, packets or segments arriving via the socket interface pass through the upper transport interface UTI. In UTI, a packet or segment is routed to either implementation TCPx or implementation TCPy depending on the upper network characteristics, from there downstream to the lower transport interface LTI, and as already shown in FIG. To L3, L2, and L1, and from there to the other communication partner (not shown) via the Internet IN.

  It must be determined by the upper and lower interfaces which TCP implementation should be used, respectively, in order to choose the correct path for the segment. This determination is performed by the control module CM shown in FIG. This will be described next.

  According to one embodiment, the control module includes lower layers L1,. . . , An interface with one or more of L3 (LLI in FIG. 5). This interface LLI can retrieve information about the types of lower layers by directly communicating with one or more of the lower layers. For that purpose, it utilizes one (not shown) API (application programming interface) in the lower layer, thereby contacting one or more of the lower layers to derive information about the structure of the underlay network be able to.

  The information thus extracted regarding the characteristics of the underlay network is then sent to an evaluation module (EVAL), which determines which TCP implementation to use based on the extracted information. . The control module CM notifies the upper transport interface UTI and the lower transport interface LTI which of TCPy and TCPx should be used as the TCP implementation. Then communication starts as follows.

  In the case of outgoing communication, the socket interface will initiate a new session. An application that intends to use the communication session designates a destination (destination) IP address and a port number like a normal TCP / IP connection, and is given a temporary source IP port number. This information uniquely identifies the session to be opened. A request to open a new session is considered by the UTI as a request to determine an appropriate TCP version. The UTI then informs the control module, which performs the determination procedure described above to determine the most appropriate TCP version for the session to be opened. When this information is obtained, the UTI is notified of the information by the control module CM, and the LTI is not directly or alternatively shown by the control module CM in FIG. 5, but between the UTI and the LTI. Notified by the direct interface. Using this information, the upper transport interface UTI and the lower transport interface LTI can route the TCP segment to the appropriate TCP implementation. This can be performed by the UTI and LTI checking the TCP header for outgoing packets and incoming packets, respectively. It is then possible to find information about the source / destination IP address and the source / destination port quadruple, which is most appropriate for this session as well as the communication session. Also identify the TCP version determined to be. Thus, based on this header information, UTI and LTI can send packets to the correct TCP implementation.

  It should be noted that UTI and LTI can be given a “default TCP version” which is the version to use unless explicitly notified by the control module to use a different version. For example, the default TCP version can be used for the first step to open a session, eg, a session opening request, assigning a temporary port number, etc. These are the steps necessary to define a session so that it can be identified later and to be assigned a specific TCP version determined by the control module.

  Next, how packet routing works in the case of an incoming session, in other words, a session initiated by the other communication endpoint will be described. In this case, first, the lower transport interface LTI receives a request to open a session. Since LTI is necessary to uniquely identify a newly identified session, it uses the default TCP version to send the request through communication. The appropriate TCP version is then determined by the control module as already described above, and the resulting information is communicated to the LTI and UTI. LTI and UTI can use this information to route incoming and outgoing packets to the appropriate selected TCP implementation. As already mentioned, routing can be performed by checking the TCP header. Routing is performed by the lower transport interface LTI for incoming packets and by the upper transport interface UTI for outgoing packets.

  In FIG. 5, the control module CM is shown as a single module that is separate from the UTI and LTI, but the control module CM may be an upper transport interface UTI, a lower transport interface LTI, or both. Note that it can be implemented as part. The operation of the control module CM can be triggered by either UTI or LTI. This UTI or LTI may be interpreted as a session opening request as a trigger to trigger the operation of the control module to determine the appropriate TCP version.

  According to a further embodiment of the implementation in FIG. 6, the control module CM is a query module for querying operating system primitives of the operating system (OS) on which the communication endpoint is based. QM (query module) is provided. The response to the query can be used by the evaluation module (EVAL) to determine which is the structure of the underlay network and, consequently, which TCP flavor should be used. The determined TCP implementation is notified as in the previous embodiment.

  One such query can be an “ipconfig” or “ifconfig” that later returns information about the underlay network, eg, operating system commands, eg Ethernet, WLAN, Gigabit Ethernet, GSM lines, etc. It is. Based on information stored in a lookup table that associates network characteristics with the appropriate TCP flavor, the evaluation module EVAL can determine which TCP flavor to use to optimize communication efficiency.

  A further embodiment will now be described with reference to FIG. According to this further embodiment, the structure of the underlay network and the appropriate TCP flavor for it can be determined by a probing mechanism. For this purpose, the TCP interface can include a probing module PM (probing module) shown in FIG. The probing module PM functions as follows.

  The probing module PM sends a probing signal to a probing partner X, which may be the communication endpoint B with which it is communicating, or a specific node dedicated to become the target of a probing mechanism in the network. Send. By sending a probing signal and evaluating the corresponding response from the desired communication partner in the evaluation module EVAL, the control module determines the nature of the structure of the underlay network and based on it the type of TCP to be used. Judgment can be made. For example, a “ping” command can be used to send a probing signal. Each ping command will trigger a response from the corresponding communication partner (addressed to that communication partner if it is reachable). The probing module PM then measures the time until a response is received. Response times for certain individual ping requests may not be characteristic, as response times may depend on actual network load, the specific route a packet can take through the Internet, and other variables. In one embodiment, it is possible to use multiple ping requests that result in a certain distribution of response times. This distribution may vary around an average response time and / or have a statistical distribution around this average response time. This distribution can be viewed as characterizing the structure of the underlay network. In the case of fixed wired Ethernet networks, for example, a shorter average response time and a small variance around this average response time can be expected, whereas in the case of GSM connections it shows a wider distribution A longer average response time can be expected. The evaluation module EVAL evaluates the response distribution and determines which TCP implementation to use.

  FIG. 8 shows an example of a response time distribution of a fixed wired Ethernet (for example, (a)) and a GSM connection (for example, (b)). By evaluating the response time distribution and comparing it with some standard pattern characteristic of the structure of the underlay network (eg by calculating the mean and variance, or more like a neural network By using a sophisticated pattern evaluation mechanism, the evaluation module can conclude what underlay network structure exists and therefore what TCP version should be used.

  According to a further embodiment of the implementation, other probing methods can also be used alone or in combination with those already mentioned. One other probing method, for example, can measure the throughput that can be achieved over a connection. In one embodiment, for that purpose, the “ping” function is used, for example, by sending ping commands while increasing their frequency and simultaneously seeing at which point maximum throughput is reached. It is possible. The result can be evaluated and used to determine the most appropriate TCP version.

  Another approach can be to vary the packet size to look for achievable results as well. Based on that, the TCP version to be used can be selected. For example, as the possible packet size increases, the use of a TCP version designed specifically for such conditions (large packet size) may be allowed.

  According to one embodiment, the signal strength of the connection can be checked as information on which the appropriate TCP version is determined. For example, this can be executed by using an operating system function such as “iwconfig” which is a UNIX command and returns information on signal strength in the wireless LAN connection as one embodiment.

  In one particular embodiment, the signal strength information or other parameters or connection quality reflecting network characteristics are continuously monitored at predetermined time intervals, thereby causing any degradation or major changes in the basic parameters. It is possible to detect and trigger different TCP version changes based on it.

  According to a further embodiment of the implementation, the control module may comprise a module for determining the characteristics of the application (at the application layer level) requesting a communication session. The module can determine the type of application and, for example, refer to a priori knowledge stored in the form of a look-up table to determine which is the most appropriate TCP implementation for this type of application.

  According to one embodiment, the control module is a combination of the mechanisms described above, for example querying operating system primitives, or probing or checking the type of application requesting a communication session. A combination of can be used. In this case, the a priori knowledge considered in selecting the most appropriate TCP implementation can include information about all these types of information to consider. In this case, for example, if the conclusion collides when only one type of information is considered (for example, the search proposes TCP implementation A, whereas the application type requesting the communication session is TCP implementation B There may be rules for making final decisions (such as proposing the use of). A rule-based knowledge base can be set to define which TCP implementation should be selected based on this information for each possible combination of input information.

  According to a further embodiment, the control module may comprise a negotiating module NM instead of or in addition to the probing module. Thanks to the negotiating module NM, it is possible to communicate directly with the corresponding interface at the other end of the communication link. Hereinafter, the operation of this negotiating module NM will be described with reference to FIG.

  FIG. 9 shows communication endpoints A and B between which a communication session is to be established. These devices A and B can be computers, mobile phones, PDAs, smartphones, notebook computers. Alternatively, they can be applications or processes that can run on these devices and open and maintain a communication session.

  The device elements A and B shown in FIG. 9 are each connected to a fronted module SWA or SWB capable of switching between different TCP implementations. These modules SWA and SWB include negotiating modules NMA and NMB, respectively.

  Here, it is assumed that device A intends to establish communication to device B. At this time, the device A transmits a request for requesting a communication session established through a certain port to the IP address of the device B. This request is sent via the switching module SWA, and the switching module SWA attempts to establish a communication session with the counterpart SWB by this request, and negotiates a TCP application to be used by each of the SWA and SWB. Is triggered. When this communication session is established to negotiate, the module SWA notifies the module SWB about the structure of the underlay network on the SWA side. This information may be derived from the querying mechanism described in the previous embodiment, or it may already exist in the status register of module SWA. If device A is a mobile phone, this means that module SWA sends corresponding information to the module SWB that the A side underlay network infrastructure is a GSM infrastructure.

  The corresponding module SWB may retrieve or store information about the infrastructure of the underlay network on the device B side in a similar manner. Based on this information, both negotiating modules NMA and NMB can negotiate for the TCP implementation used by the switching modules SWA and SWB, respectively. For example, if the TCP implementation suitable for GSM as the structure of the underlay network is available not only in the switching device SWA but also in the switching device SWB, the negotiating module NMB is changed to the negotiating module NMA accordingly. In contrast, both switch modules can be notified to use such a TCP implementation most appropriate for GSM as the structure of the underlay network.

  In the case of an underlay network structure that is heterogeneous, for example, when the underlay network structure is a GSM structure on the A side and a WLAN infrastructure on the B side, The module NMB can determine the most appropriate TCP implementation in such a case based on a priori knowledge that can be stored in a lookup table. This selected TCP implementation can be proposed to the negotiating module NMA and can be used for the communication session between A and B if it is available on the A side. If the proposed TCP implementation is not available on the switching device SWA, the negotiating module NMA can re-propose further alternatives of the TCP implementation to use. At this time, the module NMA can transmit the corresponding information to the corresponding negotiation NMB, and the availability of the TCP implementation proposed by the negotiating module NMA can be checked again in the negotiation NMB. is there. By repeating this procedure, an appropriate and usable TCP implementation can be finally selected.

  Next, another alternative for negotiating an appropriate TCP implementation according to a further embodiment of the invention will be described. When notifying the negotiating module NMB about the structure of the underlay network, the negotiating module NMA sends information about the TCP implementation available in the switching device SWA. Then, based on the transmitted information, the negotiating module NMB refers to a knowledge base (eg in the form of a lookup table) and selects the most appropriate TCP implementation under a given environment. can do. The module NMB then informs the negotiating module NMA of the selected TCP implementation, which is the communication session between endpoint A and endpoint B (this session is the appropriate TCP implementation). After closing the communication session between SWA and SWB used to negotiate the implementation, it can thus be opened using the selected TCP implementation).

  A further embodiment will now be described in which the TCP implementation can be switched by two communication endpoints A and B or at least the endpoint A initiating a communication session. According to this further embodiment, a support node B 'is provided that can function as a proxy for the other Node B in the network. The support node B 'can negotiate with the initiating endpoint A for an appropriate TCP implementation.

  This scenario will be described in more detail with reference to FIG. Initiating endpoint A and support node B 'in this example are both within the scope of an underlay network structure (eg, a high quality, high speed infrastructure provided by a provider). In FIG. 9, the range is shown as an area including A and B ′. Here, it is assumed that the end point A intends to establish a communication session with the end point B outside the coverage of the high-quality and high-speed provider mentioned above (the portion surrounded by a dotted line in FIG. 9). Here, in order to negotiate an appropriate TCP implementation between endpoint A and support node B ', endpoint A first connects to support node B'. Subsequently, support node B 'contacts endpoint B and, if possible, negotiates an appropriate TCP implementation between support node B' and endpoint B. After the negotiation process, direct communication between endpoint A and endpoint B can be established based on the result of the negotiation, or communication is established from endpoint A to the supporting node B ′, To endpoint B. Meanwhile, based on the result of the negotiation, the first appropriate TCP implementation is used for path A-B 'and the second appropriate TCP implementation is used for path B'-B.

  Next, further embodiments of the present invention for switching between different TCP implementations during execution time (runtime) will be described. In the above example, it is assumed that the control module first determines the most appropriate TCP implementation, after which actual communication is initiated and routed through the selected TCP implementation. However, today's networks are not only heterogeneous in many cases, but can change over time, so that ongoing communication sessions face changes in the infrastructure of the underlay network There is a possibility. One reason for such a change is handover in a mobile network. A base station of a mobile network has a certain coverage area, and so-called handover may be required when a user comes near the boundary of the coverage area. That is, an ongoing communication session is “handed over” to a different base station. Such a handover may result in a change in the characteristics of the underlay network, for example because the new base station uses a different network platform. For example, when a user enters an area covered by a WLAN hotspot (eg, an airport, a restaurant, or other location where such a hotspot is provided), an ongoing communication session may be a “traditional” mobile phone base station. To the WLAN hotspot. Conversely, the user may leave such a hot spot coverage area. At this time, the ongoing communication session needs to be handed over to the mobile phone base station. Each of these handovers means that the characteristics of the underlay network change, and as a result, this is preferably reflected in changes in the TCP implementation applied to the ongoing communication session.

  Next, an embodiment for performing such ongoing switching (runtime switching) between different TCP implementations will be described. This embodiment is hereinafter referred to as “independent switching” because there is no external coordination between the old and new TCP connections between the upper / lower transport interfaces.

  Here, it is assumed that the communication endpoint A has a running session with the other communication endpoint B. Thereafter, a handover occurs where the endpoint A moves and the characteristics of the underlay network of the communication endpoint A change. In the present embodiment, the pair of upper and lower transport interfaces on the endpoint A side is transparent (not noticed) between the actual TCP implementation and the other endpoint B, and the current TCP implementation. To start another TCP implementation.

  It should be pointed out here that this form of switching does not require any hardware or software changes in any component except the connection between the control module and a different TCP implementation. The current TCP implementation ends when the control module terminates the session by sending a signal to the lower transport interface LTI indicating that the other endpoint B has closed the connection. The corresponding signal sent from the current TCP implementation on the A side to the application is consequently intercepted and not forwarded. Similarly, a new TCP implementation is initiated by the control module using a similar technique by triggering another TCP implementation module to initiate a new TCP connection to the application. In this embodiment, since there is no interface other than the ability to open and close connections, it cannot be guaranteed that TCP parameters such as sequence numbers or window sizes can be exchanged between different implementations. Thus, the TCP implementation at the other endpoint continues at the current sequence number x of the session, whereas the newly started implementation starts at sequence number 0. As a result, conversion of port numbers and other fields in the TCP header by upper / lower transport interface pairs or control modules may be required for future segments. In particular, the sequence number and ACK (acknowledgement) number in the TCP header need to be adjusted to compensate for the offset x between the newly started TCP implementation and the TCP implementation at the other endpoint that continues with the old sequence number. There is. For example, a sequence number a from a newly started implementation must be converted to a + x (x is the last sequence sent from the other endpoint B) in order to be correctly processed at endpoint A of the TCP connection. I must. Furthermore, the TCP segment check-sum needs to be recalculated. Therefore, in the present embodiment, the control module or the lower transport interface LTI modifies the TCP header parameter in the newly opened TCP connection so that the ongoing communication session can continue even after switching (illustrated). Not included).

  Next, a slightly different embodiment called “loosely co-ordinated switching” in runtime switching between different TCP implementations will be described. According to this embodiment, the control module can insert TCP parameters into the local TCP implementation through the interface. In addition, a module is provided for extracting relevant TCP parameters in an ongoing communication session. For this reason, the state from the current TCP session (sequence number and other related parameters necessary to ensure that the current TCP connection is correctly restarted with a different TCP implementation) is retrieved and a new TCP implementation Inserted into. In such a case, the new local TCP implementation can receive the current TCP sequence number of the session as input, making it unnecessary to transfer the TCP header field by the upper / lower transport interface. .

  Next, a further embodiment called “fully co-ordinated switching” in runtime switching between different TCP implementations will be described. In this embodiment, in addition to the end point A, the other end point B, or in other words, the front end connected to it to realize the TCP implementation switching mechanism can also switch the TCP implementation during execution. Is assumed. This switching mechanism can be executed in the same manner as the switching mechanism described in connection with the switching by negotiation in the previous embodiment. Therefore, details will be omitted here, since those skilled in the art can easily understand. Coordinated simultaneous switching performed on both sides of A and B by such a mechanism that can be switched by negotiation may be facilitated after successful negotiation of the TCP implementation used on both sides. Communication can proceed using a newly negotiated and negotiated TCP implementation, but the conversion of TCP header information described in the previous embodiment, the TCP header data described in another previous embodiment. Either the insertion of a new one or the establishment of a completely new TCP session can be used.

  As already mentioned, a change to a different TCP version can be triggered by an external action, such as a handover is performed that results in an underlay network infrastructure change of the running connection. Other environments that can trigger changes to another TCP version include, for example, changes in connection or service quality, such as signal strength. According to one embodiment, some or all of the parameters considered in determining which TCP version to use may be continually determined, for example by sampling relevant data at regular time intervals. Monitored. This allows for a quick response to any change in the parameters considered in determining which TCP version to use.

  It should be noted that the present invention that has been outlined so far is not limited to TCP. The present invention is applicable to switching between other transport protocols in addition to on-the-fly switching between TCP and other types of transport protocols. In such a case, the upper / lower transport interface receives all IP packets whose payload type is TCP or one of the other transport protocols. It is possible to infer that switching between transport protocols is performed in a well-coordinated manner as well, however, the header of the new transport protocol connection and the original transport protocol connection When transcoding with the header is possible, it is possible to perform switching by loose adjustment or independent adjustment.

  Furthermore, although the control module has been described as a module that interacts with and interacts with the upper and lower transport interfaces in the examples described so far, in some embodiments, the control module may be an LTI or UTI or It can also be implemented as part or all of both.

  It will be readily appreciated that the switching device according to the present invention can be realized by any computer or computing device suitably programmed to operate as described in the above embodiments. Furthermore, the switching device according to the embodiment of the present invention can also be realized by a computer program or computer program code that, when executed, enables a computer or computing device to function as the switching device according to the above-described embodiment. . A computer or computing device may thus mean any device comprised of one or more microprocessors that can be programmatically controlled such that the device is executed as described above. Examples of such devices include personal computers, notebook computers, PDAs, mobile phones, smartphones, and the like. Furthermore, the above-described individual modules of the embodiment of the present invention can be realized by program modules including computer program codes that realize the functions of the above-described modules when executed. A product implementing an embodiment of the present invention is a data carrier or any data carrier that stores or embodies computer program code that enables a computer or computing device to function as the apparatus described in connection with the above-described embodiments. A storage medium may be provided.

It is a figure which shows the layered architecture of a TCP / IP protocol. It is a figure which shows the layered architecture of the TCP / IP protocol when compared with an ISO / OSI layer model. It is a figure which shows the protocol stack of the conventional TCP / IP connection. 1 is a diagram illustrating a communication link that utilizes an embodiment of the present invention. FIG. It is a schematic block diagram of the switching apparatus by one Embodiment of this invention. It is a schematic block diagram of the switching apparatus by further one form of implementation of this invention. It is a schematic block diagram of the switching apparatus by further one form of implementation of this invention. FIG. 6 is a diagram illustrating result data of a probing mechanism according to an embodiment of the present invention. It is a figure which shows one Embodiment of this invention regarding the switch by negotiation. It is a figure which shows the further one form of implementation of this invention regarding the switch by negotiation.

Claims (31)

A device that switches between different implementations of a transport protocol,
An upper transport interface for connecting several different transport protocol implementations with layers above the transport layer;
A lower transport interface for connecting the plurality of different transport protocol implementations with a layer below the transport layer;
The upper transport interface and the lower transport interface are configured to switch connections between the different transport protocol implementations based on switching information;
A connection between the upper transport interface and the plurality of different transport protocol implementations such that a transport protocol implementation that provides an optimized data flow for a communication session is selected; An apparatus further comprising a control module for determining the switching information for switching each of a connection between a lower transport interface and the plurality of different transport protocol implementations. Each of the upper transport interface and the lower transport interface is:
A module that assigns one of the plurality of different TCP implementations to a particular communication session based on the switching information provided by the control module;
A module that identifies a session by checking a header of an incoming packet and a header of an outgoing packet and, based thereon, determines to which of the different TCP implementations the incoming packet and the outgoing packet should be sent The apparatus according to claim 1, comprising:   The control module determines one or more characteristics representative of the type of network structure implemented below the transport layer so that the transport protocol adapts to the structure of the underlay network. Apparatus according to claim 1 or 2, comprising a module for determining a transport protocol to be selected.   4. The module according to claim 1, wherein the module for determining characteristics of an underlay network includes a module for determining characteristics of an underlay network using an existing operating system function. 5. apparatus.   The module for determining characteristics of an underlay network includes a module for transmitting a probing signal, evaluating a response to the probing signal, and determining a characteristic of the underlay network based on the evaluation. The apparatus of any one of thru | or 4.   The module for determining the characteristics of the underlay network establishes communication with the other endpoint in the communication session and is used in the communication session with the corresponding module at the other endpoint of the communication session. 6. An apparatus according to any one of the preceding claims, comprising a module for negotiating a secure transport protocol implementation session.   The apparatus according to claim 1, wherein the control module includes a module that determines a TCP implementation to be used based on characteristics of an application requesting the communication session.   8. The control module according to claim 1, wherein the control module is configured to determine the switching information before communication using one of the plurality of different transport protocol implementations begins. 9. The device according to item.   9. The control module according to claim 1, wherein the control module is configured to switch between the different transport protocol implementations during execution time in a currently executing communication session. The device described in 1. The control module is
A module that triggers the start of use of the new transport protocol implementation to switch to a new transport protocol implementation during runtime;
The contents of the TCP header of the currently running transport protocol session are converted, and the header sent to the newly started TCP implementation and the header sent from the newly started TCP are The apparatus of claim 9, comprising: a module that aligns with the TCP header sent and received by a transport protocol implementation at the other communication endpoint of an ongoing communication session. The control module is
A module that extracts header data from a pre-switch transport protocol session that is to be switched to a different transport protocol implementation;
Inserting the extracted transport protocol session header data into the newly opened transport protocol session so that the newly opened transport protocol session has a different transport protocol implementation. 11. The apparatus according to claim 9, further comprising: a module capable of resuming the transport protocol session before the switching via the network.   The control module corresponds to a corresponding second to which switching should be performed when a currently running transport protocol session is switched to a different transport protocol implementation at the first communication endpoint. Negotiate with the corresponding module at the communication endpoint so that both control modules at those communication endpoints open and execute a new transport protocol session for a different transport protocol implementation Comprising a module that allows traffic to be resumed through the newly opened transport protocol session and the different transport protocol implementations at both communication endpoints Apparatus according to any one of claims 9 to 11.   13. Apparatus according to any one of claims 9 to 12, wherein the control module is configured to receive a trigger signal for triggering a switch to a different transport protocol implementation. The trigger signal is
Handover between mobile communication sessions;
Quality of service changes during the currently running communication session;
14. The apparatus of claim 13, wherein the apparatus is generated in response to any one of a hardware or software module change used in a currently executing communication session. The control module further comprises a module for continuously monitoring one or more parameters based on which a determination of which of the plurality of different TCP implementations should be used;
The monitoring module suggests that a change of the monitored one or more parameters according to a set predetermined rule suggests that a change from the currently used TCP version to a different TCP version should be performed. 16. A device according to any one of the preceding claims, which in case triggers a change from a currently used TCP version to a different TCP version. A method for switching between different implementations of transport protocols,
Connecting the plurality of different transport protocol implementations with an upper transport interface to connect the plurality of different implementations of the transport protocol with a layer above a transport layer;
Connecting the plurality of different transport protocol implementations with a lower transport interface to connect the plurality of different implementations of the transport protocol with a layer below a transport layer;
Switching between a connection between the upper transport interface and the different transport protocol implementation and a connection between the lower transport interface and the different transport protocol implementation based on switching information, respectively. When,
A connection between the upper transport interface and the plurality of different transport protocol implementations such that a transport protocol implementation that provides an optimized data flow for a communication session is selected; Determining the switching information for each switching between a lower transport interface and a connection between the plurality of different transport protocol implementations. Assigning one of the plurality of different TCP implementations to a particular communication session based on the switching information;
Identifying a session by checking an incoming packet header and an outgoing packet header, and based on that, determining to which of the different TCP implementations the incoming packet and outgoing packet should be sent; The method of claim 16 further comprising:   The one or more characteristics that are representative of the type of network structure implemented below the transport layer are determined so that the transport protocol should be selected so that the transport protocol conforms to the structure of the underlay network. 18. A method according to claim 16 or 17, comprising the step of determining a port protocol.   19. A method according to any one of claims 16 to 18, further comprising the step of determining characteristics of the underlay network utilizing existing operating system functions.   20. A method according to any one of claims 16 to 19, further comprising the steps of transmitting a probing signal, evaluating a response to the probing signal, and determining characteristics of the underlay network based on the evaluation.   Establishing communication with the other endpoint of the communication session and negotiating with a corresponding module at the other endpoint of the communication session for an appropriate transport protocol implementation session to be used in the communication session. 21. A method according to any one of claims 16 to 20 comprising.   The method according to any one of claims 16 to 21, further comprising determining a TCP implementation to be used based on characteristics of an application requesting the communication session.   23. A method as claimed in any one of claims 16 to 22, further comprising the step of determining the switching information before communication using one of the plurality of different transport protocol implementations begins.   24. A method as claimed in any one of claims 16 to 23, further comprising switching the plurality of different transport protocol implementations during execution in a currently executing communication session. Triggering the start of use of the new transport protocol implementation to switch to the new transport protocol implementation during execution;
Transforms the contents of the TCP header of the currently running transport protocol session so that the header sent to the newly started TCP implementation and the header sent from the newly started TCP are currently executed 25. The method of claim 24, further comprising: aligning with the TCP header transmitted / received by a transport protocol implementation at the other communication endpoint of an intermediate communication session. Extracting header data from a pre-switch transport protocol session that is to be switched to a different transport protocol implementation;
Inserting the extracted transport protocol session header data into the newly opened transport protocol session so that the newly opened transport protocol session has a different transport protocol implementation. 26. The method of claim 24 or 25, further comprising: allowing the pre-switching transport protocol session to be resumed via.   When a currently running transport protocol session is switched to a different transport protocol implementation at the first communication endpoint, the corresponding at the corresponding second communication endpoint at which switching should be performed Negotiating with the module, both control modules at their communication endpoints open a new transport protocol session targeting a different transport protocol implementation, and the traffic in progress is 27. The method according to any one of claims 24 to 26, further comprising the step of being resumed through a newly opened transport protocol session and the different transport protocol implementations at both communication endpoints. The method of mounting.   28. A method according to any one of claims 24 to 27, further comprising receiving a trigger signal for triggering a switch to a different transport protocol implementation. The trigger signal is
Handover between mobile communication sessions;
Quality of service changes during the currently running communication session;
Changes to the hardware or software modules used in the currently running communication session;
30. The method of claim 28, generated in response to any one of the mechanisms. Continuously monitoring one or more parameters based on which a determination of which of the plurality of different TCP implementations should be used;
If a change in one or more of the monitored parameters suggests that a change from the currently used TCP version to a different TCP version should be performed according to a set predetermined rule 30. The method of any one of claims 16 to 29, further comprising: triggering a change from one TCP version to a different TCP version.   Computer program comprising computer program code capable of executing the method according to any one of claims 16 to 30 when executed on a computer.

Images