Techniques for packet data conversion
阅读说明:本技术 用于分组数据转换的技术 (Techniques for packet data conversion ) 是由 M·阿门德 E·波根菲尔德 于 2019-02-21 设计创作,主要内容包括:本公开涉及用于网络协议转换的技术,尤其涉及用于发送器的第一分组数据转换设备(810),该分组数据转换设备(810)包括:数据接口(811),该数据接口(811)被配置成根据第一网络协议(814),特别是根据数据报拥塞控制协议DCCP提供第一分组数据(813),其中该第一分组数据(813)的每个分组都包括第一分组报头(815);以及转换器(812),该转换器(812)被配置成将该第一分组数据(813)转换成第二分组数据(817);其中该转换基于对该第一分组报头(815)的内容的重新布置,其中该经重新布置的第一分组报头(819)指示该第二分组数据(817)是根据第二网络协议(818)生成的,特别是根据用户数据报协议UDP或根据UDP-Lite协议生成的。(The present disclosure relates to a technique for network protocol conversion, and more particularly, to a first packet data conversion device (810) for a transmitter, the packet data conversion device (810) including: a data interface (811), the data interface (811) being configured to provide first packet data (813) according to a first network protocol (814), in particular according to a datagram congestion control protocol, DCCP, wherein each packet of the first packet data (813) comprises a first packet header (815); and a converter (812), the converter (812) configured to convert the first packet data (813) into second packet data (817); wherein the conversion is based on a rearrangement of the content of the first packet header (815), wherein the rearranged first packet header (819) indicates that the second packet data (817) is generated according to a second network protocol (818), in particular according to a user datagram protocol, UDP, or according to a UDP-Lite protocol.)
1. A first packet data conversion device (810) for a transmitter, the packet data conversion device (810) comprising:
a data interface (811), the data interface (811) being configured to provide first packet data (813) according to a first network protocol (814), in particular according to a datagram congestion control protocol, DCCP, wherein each packet of the first packet data (813) comprises a first packet header (815); and
a converter (812), the converter (812) configured to convert the first packet data (813) into second packet data (817),
wherein the conversion is based on a rearrangement of the content of the first packet header (815), wherein the rearranged first packet header (819) indicates that the second packet data (817) is generated according to a second network protocol (818), in particular according to a user datagram protocol, UDP, or UDP-Lite protocol.
2. The first packet data conversion device (810) of claim 1,
characterized in that a length of the rearranged first packet header (819) is equal to a length of the first packet header (815).
3. The first packet data conversion device (810) of claim 1 or 2,
characterized in that the length of the packet of the second packet data (817) is equal to the length of the corresponding packet of the first packet data (813).
4. The first packet data conversion device (810) of one of the preceding claims,
wherein the converting is further based on changing a protocol field (501) of the first packet header (815, 703) from indicating the first network protocol (814) to indicating the second network protocol (818).
5. The first packet data conversion device (810) of claim 4,
characterized in that said first packet header (815) comprises an internet protocol, IP, header (703) and
wherein the protocol field (501) is a protocol field of the IP header (703).
6. The first packet data conversion device (810) of claim 4 or 5,
characterized in that the converter (812) is configured to change the protocol field (501) from a value of 33 indicating the DCCP protocol to a value of 17 indicating the UDP protocol or to a value of 136 indicating the UDP-Lite protocol.
7. The first packet data conversion device (810) of one of the preceding claims,
characterized in that the conversion is further based on a checksum coverage field CsCov (301) extending a respective packet of the first packet data (813), wherein the CsCov (301) indicates a range of the respective packet covered by a checksum (302).
8. The first packet data conversion device (810) of claim 7,
wherein the CsCov (301) is extended to the size of a length field (401) comprised in a packet header (400) of the second network protocol, in particular a packet header of the UDP protocol or a packet header of the UDP-Lite protocol.
9. The first packet data conversion device (810) of one of the preceding claims,
wherein the converting is further based on rearranging at least one of a type field (305, 605), a CCVal field (306, 606), and a data offset field (307, 607) of the first packet header (815) to another location in the rearranged first packet header (819).
10. The first packet data conversion device (810) of one of the preceding claims,
wherein the rearranged first packet header (819) comprises the following data fields, in particular in the following order: source port (601), destination port (602), checksum override CsCov (603), checksum (604), type (605), CCVal (606), data offset (607), and sequence number (608, 609).
11. The first packet data conversion device (810) of one of the preceding claims,
characterized in that said first packet data (813) and said second packet data (817) are segmented data streams according to the OSI layer 4 representation.
12. A second packet data conversion device (820) for a receiver, the second packet data conversion device (820) comprising:
a data interface (821), the data interface (821) being configured to receive second packet data (817) according to a second network protocol (818), in particular according to a user datagram protocol, UDP, or according to a UDP-Lite protocol, wherein each packet of the second packet data (817) comprises a second packet header (819); and
a converter (822) configured to convert the second packet data (817) into first packet data (813),
wherein the conversion is based on a rearrangement of content of the second packet header (819), wherein the rearranged second packet header (815) indicates that the first packet data (813) was generated according to a first network protocol (814), in particular according to a datagram congestion control protocol, DCCP.
13. A transmission system (800), comprising:
a transmitter configured to transmit first packet data (813) over a transmission channel, wherein the transmitter comprises a first packet data conversion device (810) according to one of claims 1 to 11, the first packet data conversion device (810) being configured to convert the first packet data (813) into second packet data (817) before transmission; and
a receiver configured to receive second packet data (817) via the transmission channel, wherein the receiver comprises a second packet data conversion device (820) according to claim 12, the second packet data conversion device (820) being configured to convert the second packet data (817) into first packet data (813) after reception.
14. The transmission system (800) of claim 13, comprising:
a middlebox between the sender and the receiver, wherein the middlebox is configured to transmit data according to the second network protocol (818), in particular according to a UDP protocol or according to a UDP-Lite protocol, and to block data according to the first network protocol (814), in particular according to a DCCP protocol.
15. A method (900) for packet data conversion, the method comprising:
providing (901) first packet data according to a first network protocol, in particular according to a datagram congestion control protocol, DCCP, wherein each packet of the first packet data comprises a first packet header; and
converting (902) the first packet data into second packet data,
wherein the conversion is based on a rearrangement of the content of the first packet header, wherein the rearranged first packet header indicates that the second packet data is generated according to a second network protocol, in particular according to a user datagram protocol, UDP, or according to a UDP-Lite protocol.
Technical Field
The present invention relates to a technique for packet data conversion, and more particularly, to a technique for conversion of DCCP (datagram congestion control protocol) packet data such that it looks like UDP (user datagram protocol) packet data in order to transmit the converted DCCP packet data on a middlebox (middle box) supporting only UDP packet data. The invention further relates to a DCCP header converter device for UDP like appearance.
Background
The Transmission Control PROTOCOL (TCP) according to "University of Southern California", "trans missi on control PROTOCOL" RFC793, 9 months 1981 "is widely used in today's computer networks to ensure reliable data transmission over OSI (open systems interconnection)
In principle, DCCP seems to be a good choice for many applications today that use UDP and implement its own congestion control. However, DCCP has a classic "chicken and egg" problem. Since DCCP is not widely deployed, middleboxes often block DCCP on its way to the destination, which in turn becomes a reason for not using DCCP as an application developer. Only TCP and UDP are protocols that the middlebox is expected to reasonably accept.
Disclosure of Invention
It is an object of the present invention to provide a concept for solving the above mentioned problem, i.e. how to efficiently distribute DCCP data traffic over middleboxes designed for UDP or TCP data traffic.
It is another object of the present invention to introduce a concept for efficiently transmitting data traffic on network devices that support only specific network protocols.
The above and other objects are achieved by the subject matter of the independent claims. Further implementations are apparent from the dependent claims, the description and the drawings.
To overcome the challenges of traversing firewalls and middleboxes like NAT (network address translation), the only reasonable solution is to translate DCCP into a general protocol like TCP or UDP without trusting that it will be allowed to pass through these middleboxes. Since DCCP wants to avoid TCP behavior, the solution space is limited to UDP only.
The present disclosure focuses on two different types of converter devices that convert DCCP datagrams to look like UDP. A DCCP connection requires at least two converter devices, one for converting it into UDP and another for de-converting, as shown in fig. 1. The first solution is to encapsulate each DCCP datagram first into a UDP datagram at the sending converter and then strip it off again at the receiving converter, which can also be described as UDP over UDP transmission (DCCP over UDP transmission) as shown in fig. 2 and is rather simple. However, in addition to simplicity, this first solution also has an impact on the size ratio due to the injection of at least one additional UDP header, and ultimately on the size ratio of the headers of the OSI-network layer (e.g. IP). Thus, overhead is introduced that at least needs to be transmitted and may also result in other overhead besides fragmentation and/or payload reduction. The second solution, which is a more elegant solution, is mainly based on converting the DCCP header (see fig. 3) to look like UDP, as exemplarily shown in fig. 6 and 7. A general representation of this second solution is shown in fig. 8.
The methods and systems presented below may be of various types. The individual elements described may be implemented by hardware or software components, e.g. electronic components manufactured by various techniques, and including, for example, semiconductor chips, ASICs, microprocessors, digital signal processors, integrated circuits, electro-optical circuits and/or passive components.
The devices, systems, and methods presented below are capable of communicating information over a communication network. The term communication network refers to the technical infrastructure over which the transmission of signals takes place. The communication network mainly includes a switching network in which signal transmission and exchange are performed between a stationary device and a platform of a mobile radio network or a fixed network, and an access network in which signal transmission is performed between a network access device and a communication terminal. The communication network may comprise both components of the mobile radio network as well as components of the fixed network. In mobile networks, the access network is also referred to as the air interface and comprises e.g. base stations (node B, evolved node B, radio cell) with mobile antennas to establish communication to communication terminals as described above, e.g. mobile phones or mobile devices or machine terminals with mobile adapters. In a fixed network, the access network comprises, for example, a DSLAM (digital subscriber line access multiplexer) to connect the communication terminals of a plurality of participants on a cable basis. Via the switching network, the communication may be passed to other networks, such as other network operators, e.g. foreign networks.
In the following, a network protocol, also referred to as communication protocol, is described. A network protocol is a system of rules that allow two or more entities of a communication system to communicate information over a communication channel or transmission medium. The network protocol defines the rules "syntax", "semantics" and "synchronization" of the communication and possible error detection and correction. The network protocols may be implemented by computer hardware, software, or a combination of both. Communication systems exchange various messages using well-defined formats. Each message has an exact meaning intended to elicit a response from a predetermined series of possible responses for that particular situation. The specified behavior is generally independent of how it is implemented. The communication protocol must be agreed upon by the relevant parties. To reach an agreement, network protocols may be developed as technical standards. Multiple protocols generally describe different aspects of a single communication. A set of (network) protocols designed to work together is called a (network) protocol suite; when implemented in software, they are (network) protocol stacks. Internet communication protocols are promulgated by the Internet Engineering Task Force (IETF). IEEE handles wired and wireless networking, while the international organization for standardization (ISO) handles other types.
In communication and computing systems, the open systems interconnection model (OSI model) defines a conceptual model that characterizes and standardizes communication functions without regard to the underlying internal structure and technology. The goal is interoperability of a wide variety of communication systems with a wide variety of standard protocols. The model divides the communication system into abstraction layers. The original version of the model defines seven layers: a physical layer (layer 1), a data link layer (layer 2), a network layer (layer 3), a transport layer (layer 4), a session layer (layer 5), a presentation layer (layer 6), and an application layer (layer 7).
According to a first aspect, the present invention relates to a first packet data conversion device for a transmitter, the packet data conversion device comprising: a data interface configured to provide first packet data according to a first network protocol, in particular according to a datagram congestion control protocol, DCCP, wherein each packet of the first packet data comprises a first packet header; and a converter configured to convert the first packet data into second packet data, wherein the conversion is based on a rearrangement of contents of the first packet header, wherein the rearranged first packet header indicates that the second packet data is generated according to a second network protocol, in particular according to a user datagram protocol, UDP, or UDP-Lite protocol.
Such a first packet data conversion device provides an efficient distribution of DCCP data traffic through a middlebox designed for UDP (or UDP-Lite) or TCP data traffic, because the rearranged first packet header indicates that the second packet data is generated according to the second network protocol, in particular according to UDP or according to UDP-Lite. In particular, such a first packet data conversion device provides for efficient transmission of data traffic by a network device that supports only a particular network protocol, i.e., the second network protocol, but blocks data traffic according to the first network protocol. UDP-Lite is easier to rearrange because it already contains data fields for port, CsCov and Chksum (checksum).
In an exemplary implementation form of the first packet data conversion device, the length of the rearranged first packet header is equal to the length of the first packet header.
This provides the advantage that the switch does not change the size of the first packet header and avoids introducing overhead. Thus, overhead does not have to be additionally transmitted, which may result in fragmentation and/or payload reduction.
In an exemplary implementation form of the first packet data conversion apparatus, a length of a packet of the second packet data is equal to a length of a corresponding packet of the first packet data.
This provides the advantage that the converter does not change the size of the overall first packet data and avoids introducing overhead. Thus, overhead does not have to be additionally transmitted, which may result in fragmentation and/or payload reduction.
In an exemplary implementation form of the first packet data conversion device, the conversion is further based on changing a protocol field of the first packet header from indicating the first network protocol to indicating the second network protocol.
This provides the following advantages: network devices (so-called middleboxes) within the transmission path between the sender and the receiver may detect the second network protocol in the protocol field and will therefore deliver the first packet data if they are designed to transmit data traffic according to the second network protocol, e.g. UDP data traffic or UDP-Lite data traffic.
In an exemplary implementation form of the first packet data conversion device, the first packet header comprises an internet protocol, IP, header and the protocol field is a protocol field of the IP header.
This provides the advantage that the internet router and/or gateway can detect the protocol field of the IP header and can forward the first packet data.
In an exemplary implementation form of the first packet data conversion device, the converter is configured to change the protocol field from a value 33 indicating the DCCP protocol to a value 17 indicating the UDP protocol or to a value 136 indicating the UDP-Lite protocol.
This provides the advantage that a typical middlebox designed to transport UDP (or UDP-Lite) or TCP data traffic can detect the first packet data as UDP (or UDP-Lite) data traffic. Therefore, the first packet data is not blocked by such a middlebox.
In an exemplary implementation form of the first packet data conversion device, the conversion is further based on extending a checksum coverage field CsCov of a corresponding packet of the first packet data, wherein the CsCov indicates a range of the corresponding packet covered by the checksum.
This provides the advantage that the checksum can be extended over a wider range of the first packet data, thereby enabling a more reliable transmission.
In an exemplary implementation form of the first packet data conversion device, the CsCov is extended to a size of a length field included in a packet header of the second network protocol, in particular a packet header of a UDP protocol or a UDP-Lite protocol.
This provides the advantage that CsCov can be interpreted as a UDP (or UDP-Lite) length field and thus the first packet data is interpreted as UDP (or UDP-Lite) traffic by a conventional middlebox designed to forward UDP (or UDP-Lite) traffic but block DCCP or other traffic.
In an exemplary implementation form of the first packet data conversion device, the converting is further based on rearranging at least one of a type field, a CCVal field, and a data offset field of the first packet header to another location in the rearranged first packet header.
This provides the following advantages: these type, CCVal, and data offset fields may be shifted further back in the first packet header, e.g., to a location that is not checked by the middlebox, to identify UDP (or UDP-Lite) data traffic.
In an exemplary implementation form of the first packet data conversion device, the rearranged first packet header comprises the following data fields, in particular in the following order: source port, destination port, checksum override CsCov, checksum, type, CCVal, data offset, and sequence number.
This provides the advantage that the rearranged first part of the first packet header, including the source port, the destination port, the checksum overlay CsCov and the checksum, looks like a UDP (or UDP-Lite) header. When this first portion is examined by the exemplary middlebox, the first packet data is identified as UDP data traffic.
In an exemplary implementation form of the first packet data conversion device, the first packet data and the second packet data are segmented data streams according to
This provides the advantage that services according to the transport layer (layer 4) of the OSI specification can be provided, such as connection oriented communication, in-order delivery, reliability, flow control, congestion control and multiplexing.
According to a second aspect, the invention relates to a second packet data conversion device for a receiver, the second packet data conversion device comprising: a data interface configured to receive second packet data according to a second network protocol, in particular according to a user datagram protocol, UDP, or according to a UDP-Lite protocol, wherein each packet of the second packet data comprises a second packet header; and a converter configured to convert the second packet data into first packet data; wherein the conversion is based on a rearrangement of contents of a second packet header, wherein the rearranged second packet header indicates that the first packet data was generated according to the first network protocol, in particular according to the datagram congestion control protocol DCCP.
Such second packet data conversion device provides an efficient distribution of DCCP data traffic through middleboxes designed for UDP (or UDP-Lite) or TCP data traffic, because the second packet header indicates that the second packet data is generated according to the second network protocol, in particular according to UDP (or UDP-Lite) and can thus pass through these middleboxes. The converter of the second packet data conversion device reconverts the transmitted data traffic back to its original network protocol, i.e. back to the first network protocol, in particular DCCP. Such a second packet data conversion device (along with the first packet data conversion device described above) provides for efficient transmission of data traffic through a network device that supports only a particular network protocol, i.e., the second network protocol, but blocks data traffic according to the first network protocol.
According to a third aspect, the invention relates to a transmission system comprising: a transmitter configured to transmit first packet data over a transmission channel, wherein the transmitter includes a first packet data conversion device according to the first aspect, the first packet data conversion device being configured to convert the first packet data into second packet data before transmission; and a receiver configured to receive second packet data via the transmission channel, wherein the receiver comprises a second packet data conversion device according to the second aspect, the second packet data conversion device being configured to convert the second packet data into the first packet data after reception.
Such a transmission system provides an efficient distribution of first packet data generated according to a first network protocol over a transmission channel having a transmission path supporting only transmission of data traffic generated according to a second network protocol, since the first packet header looks like a packet header of the second network protocol.
In an exemplary implementation form, the transmission system comprises a middlebox between the sender and the receiver, wherein the middlebox is configured to transmit data according to the second network protocol, in particular according to the UDP (or UDP-Lite)) protocol, and to block data according to the
Such transmission systems provide efficient distribution of DCCP data traffic over middleboxes that only support UDP (or UDP-Lite) or TCP data traffic, since the DCCP header is rearranged like a UDP header.
According to a fourth aspect, the invention relates to a method for packet data conversion, the method comprising: providing first packet data according to a first network protocol, in particular according to a datagram congestion control protocol DCCP, wherein each packet of the first packet data comprises a first packet header; and converting the first packet data into second packet data, wherein the conversion is based on a rearrangement of the content of the first packet header, wherein the rearranged first packet header indicates that the second packet data is generated according to a second network protocol, in particular according to a user datagram protocol, UDP, or according to a UDP-Lite protocol.
Such an approach provides for an efficient distribution of DCCP data traffic through middleboxes designed for UDP (or UDP-Lite) or TCP data traffic, since the rearranged first packet header indicates that the second packet data is generated according to the second network protocol, in particular according to UDP (or UDP-Lite). In particular, such methods provide for efficient transmission of data traffic by a network device that supports only a particular network protocol, i.e., the second network protocol, but blocks data traffic according to the first network protocol.
According to a fifth aspect, the invention relates to a computer program product comprising program code for performing the method according to the fourth aspect of the invention, when the program code is executed on a computer or processor.
Embodiments of the invention may be implemented in hardware and/or software.
The following acronyms apply in this disclosure:
API application interface
DCCP datagram congestion control protocol
IP internet protocol
OSI open system interconnection
TCP transmission control protocol
UDP user datagram protocol
Drawings
Further embodiments of the invention will be described with respect to the following drawings, in which:
fig. 1 shows a block diagram illustrating an exemplary DCCP UDP converter architecture 100;
fig. 2 shows a block diagram illustrating an OSI-layer view of a UDP-based
fig. 3 shows a bitmap illustrating a DCCP header structure 300 according to RFC 4340;
fig. 4 shows a bitmap illustrating a UDP header structure 400 according to RFC 768;
fig. 5 shows a bitmap illustrating an IP header structure 400 according to RFC 791;
FIG. 6 illustrates a bitmap understanding an exemplary DCCP to UDP header conversion 600 according to the present disclosure;
fig. 7 shows a block diagram illustrating an OSI layer view of a transmission system 700 with an exemplary DCCP to UDP header conversion in accordance with the present disclosure;
fig. 8 shows a block diagram illustrating a
fig. 9 shows a schematic diagram illustrating a
Detailed Description
In the following detailed description, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration specific aspects in which the invention may be practiced. It is to be understood that other aspects may be utilized and structural or logical changes may be made without departing from the scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense, because the scope of the present invention is defined by the appended claims.
For example, it is to be understood that the disclosure relating to the method may also be true for a corresponding device or system configured to perform the method, and vice versa. For example, if particular method steps are described, the respective apparatus may comprise means for performing the described method steps, even if such means are not explicitly described or illustrated in the figures. Furthermore, it is to be understood that features of the various exemplary aspects described herein may be combined with each other, unless specifically noted otherwise.
Fig. 1 shows a block diagram illustrating an exemplary DCCP UDP converter architecture 100. A DCCP connection requires at least two
The
Fig. 2 shows a block diagram illustrating an OSI-layer view of a UDP-based
In the example of fig. 2,
The solution according to fig. 2 is very simple. However, in addition to simplicity, this first solution also has an impact on the size ratio due to the injection of at least one
Fig. 3 shows a bitmap illustrating a DCCP header structure 300 of the DCCP network protocol according to RFC 4340. The Datagram Congestion Control Protocol (DCCP) is a message-oriented transport layer protocol. The DCCP enables reliable connection setup, teardown, Explicit Congestion Notification (ECN), congestion control, and feature negotiation. DCCP provides a way to access congestion control mechanisms without having to implement them at a layer higher than
The DCCP header 300 includes a source port (16 bits), a destination port (16 bits), a data offset (8 bits) 307, a CCVal (4 bits) 306, a checksum cover CsCov (4 bits) 301, a checksum (16 bits), a reserved bit field (3 bits), a type field (4 bits), an X ═ 1 field (1 bits), another reserved bit field (8 bits), a sequence number (upper bits) (16 bits), and a sequence number (lower bits) (32 bits).
According to the second solution described above with reference to fig. 1, the contents of the DCCP header, in particular the data offset 307, the CCVal 306, the CsCov 301 and the type 305 bit field are rearranged in such a way that the DCCP header looks like a UDP header described below. In some embodiments, the CsCov 301 bit field must additionally be converted into a corresponding length and/or value field of the UDP header. The checksum overlay CsCov determines the portion of the packet that is covered by the checksum field. This second solution does not have the disadvantage of injecting extra information as in the first solution described above with reference to fig. 2, but instead utilizes the already used space of the DCCP header and rearranges the header content.
Fig. 4 shows a bitmap illustrating the UDP header structure 400 of the UDP network protocol according to RFC 768. Using the User Datagram Protocol (UDP), computer applications can send messages (referred to as datagrams in this case) to other hosts on an Internet Protocol (IP) network. A communication channel or data path can be established without prior communication. UDP uses a simple connectionless communication model with minimal protocol mechanisms. UDP provides a checksum for data integrity and port numbers for addressing different functions at the source and destination of the datagram. It has no handshake dialog and therefore exposes the user program to any unreliability of the underlying network. There is no guarantee of delivery, order or duplicate protection.
UDP header 400 includes a source port (16 bits), a destination port (16 bits), a length field 401, and a checksum. In some embodiments, the source port, destination port, and checksum may be the same as in DCCP header 300 shown in fig. 3, depending on CsCov. In some embodiments, the checksum may have to be recalculated due to the rearrangement. If the CsCov field 301 of the DCCP header 300 is expanded to a 16-bit value and the CCVal 306 and the data offset 307 are shifted to some other location in the rearranged DCCP header, the rearranged DCCP header looks like the UDP header 400 shown in fig. 4. Furthermore, it behaves like a valid UDP packet in case the middlebox checks the length and checksum.
Fig. 5 shows a bitmap illustrating an
The IP header includes different bit fields such as version, IHL, type of service, total length, identification, flags, segment offset, time to live, protocol, header checksum, source address, destination address, options, and padding. For the second solution described above with reference to fig. 1, together with the rearrangement of the header content, the converter device has to change the "protocol"
Fig. 5 shows the original IP header (IPv4) according to RFC 791. This solution can also be applied to the IP header of IPv6 according to RFC 2460. The protocol fields must be changed accordingly.
Fig. 6 illustrates a bitmap understanding an exemplary DCCP to UDP header conversion 600 in accordance with the present disclosure. Translated header 600 includes the following bit fields:
Thus, each datagram looks like UDP between the converters without losing DCCP related information. Along with the rearrangement, the converter device has to change the "protocol" field in the IP header as described above with reference to fig. 5 to 17; UDP (transmit converter) or 33; DCCP (receiver converter). In an alternative embodiment using the UDP-Lite protocol according to RFC3828, the translator device must change the "protocol" field in the IP header as described above with reference to figure 5 to 136; UDP-Lite (transmit converter) or 33; DCCP (receiver converter). Furthermore, it behaves like a valid UDP (or UDP-Lite) packet in case the middlebox checks the length and checksum. The final architecture and related OSI layer changes are shown in fig. 7.
Fig. 7 shows a block diagram illustrating an OSI layer view of a transmission system 700 with an exemplary DCCP to UDP header conversion in accordance with the present disclosure.
The transmission system 700 corresponds to the system described above with reference to fig. 1, wherein the
In the example of fig. 7,
Fig. 8 shows a block diagram illustrating a
The first packet
The conversion is performed such that the lengths of the
The conversion may be further based on changing the
The
The translation may further be based on a checksum coverage field CsCov, such as CsCov 301 described above with reference to fig. 3, extending the corresponding packet of
The conversion may be further based on rearranging at least one of the
The rearranged
The first and
On the receiver side (right hand side), a second packet
The
The transmitter may be implemented, for example, in a mobile device such as a smartphone (e.g., a smartphone application), and the receiver may be implemented, for example, in a server (e.g., a download server). The sender may trigger the download server to download the data. In an exemplary implementation, both the sender and the receiver may be implemented in a smartphone, and both the sender and the receiver may be implemented in a download server to enable duplex transmission.
In another example, the sender may be implemented in a first network node and the receiver may be implemented in a second network node, e.g. a gateway or a router in the internet. In this example, data traffic according to a first network protocol may be converted into data traffic according to a second network protocol for passing through a transmission path between the first network node and the second network node designed to transmit data traffic according to the second network protocol but block data traffic according to the first network protocol. In this example, the first network node and the second network node may also comprise both a transmitter and a receiver for duplex transmission.
In an exemplary embodiment, the
Fig. 9 shows a schematic diagram illustrating a
The
The
The
Another aspect of the invention relates to a computer program product comprising program code for performing the
While a particular feature or aspect of the disclosure may have been disclosed with respect to only one of several implementations or embodiments, such feature or aspect may be combined with one or more other features or aspects of the other implementations or embodiments as may be desired and advantageous for any given or particular application. Furthermore, to the extent that the term "includes," including, "" has, "" with, "or other variants thereof are used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term" comprising. Also, the terms "exemplary," for example, "and" for example (e.g.) are meant only as examples, and not as best or optimal. The terms "coupled" and "connected," along with derivatives, may have been used. It will be understood that these terms may have been used to indicate that two elements co-operate or interact with each other, whether or not they are in direct physical or electrical contact, or not in direct contact with each other.
Although specific aspects have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that a variety of alternate and/or equivalent implementations may be substituted for the specific aspects shown and described without departing from the scope of the present disclosure. This application is intended to cover any adaptations or variations of the specific aspects discussed herein.
Although the elements in the following claims are described in a particular order, unless the claim description otherwise suggests a particular order for implementing some or all of the elements, these elements are not necessarily intended to be limited to being implemented in that particular order.
Many alternatives, modifications, and variations will be apparent to those skilled in the art in light of the above teachings. Of course, those skilled in the art will readily recognize that there are numerous applications for the present invention other than those described herein. While the invention has been described with reference to one or more particular embodiments, those skilled in the art will recognize that many changes may be made thereto without departing from the scope of the invention. It is therefore to be understood that, within the scope of the appended claims and equivalents thereto, the invention may be practiced otherwise than as specifically described herein.
- 上一篇:一种医用注射器针头装配设备
- 下一篇:网络系统