Packet data flow identification for multiplexing
Abstract
The present invention is directed to the aggregation of data packets and to super packets for transmission across a communication network. In accordance with the present invention, an identifier associated with individual data packets is examined to determine whether such individual packet is suitable for inclusion in a super packet containing data packets associated with individual data flows. The identification may be included within a field established for a purpose other than marking an individual data packet in connection with forming aggregate packets. In particular, preexisting data fields may be utilized to identify packets for purposes of forming aggregate data streams.

Term
Term ended
Projected expiry passed 30 January 2024, 2.7 years ago.
- Priority
- Filed
- Published
- Projected expiry
- Today
20 claims: 7 independent, 13 dependent
- 1A method for multiplexing packet data transmissions, comprising:assigning an identifier to a first network element;associating in at least a second network element said identifier with a plurality of data packets;recognizing in at least a third network element said identifier with respect to said plurality of data packets;aggregating said plurality of data packets together;and addressing said bundle of data packets to said first network element.
- 6A system for multiplexing packet data transmissions, comprising:at least first communication device means for forming data packets and for marking said data packets with an identifier using an existing data field;first means for aggregating first and second data packets associated with said identifier into a super packet;means for interconnecting said first means for aggregating to a communication network, wherein said super packet may be transmitted to a remote subnetwork.
- 9A data packet, comprising:header information, wherein said header information addresses said data packet to a first network element having a first address;a first sub-data packet, wherein said first sub-data packet is addressed to a first data consumer and is associated with said first network element by a first identifier, wherein said first identifier is different from said first address;a second sub-data packet, wherein said second sub-data packet is addressed to a second data consumer and is associated with said first network element by said first identifier.
- 11A data multiplexer comprising:an interface, wherein a plurality of the packets marked with a first identifier and containing a destination address other than said first identifier are received;and a processor running operating code, wherein said plurality of data packets are aggregated with a super packet and provided to said interface for delivery.
- 13A computational component for performing a method, the method comprising:receiving a first data packet containing a first destination address in an address field and a first identifier in a second field, wherein said first identifier identifies a first network element having a second destination address, wherein said second field is defined by at least a first network protocol for purposes other than communicating an identifier identifying a network element;receiving a second data packet containing at least one of said first destination address and a second destination address in an address field and said first identifier in a second field;and forming a super packet containing as a payload said first and second data packets, wherein said super packet contains said second destination address in an address field.
- 16A method for identifying data packets for multiplexing, comprising:receiving at a first multiplexer a first request to reserve resources for a first packet data flow;determining from said request a destination for said first data packet flow;receiving at said first multiplexer a second request to reserve resources for a second packet data flow;determining from said request a destination for said second data packet flow;in response to said first and second data packet flows being addressed to a destination on a first subnetwork, aggregating at least a first data packet from said first data packet flow with a data packet from said second data packet flow to form a super packet;and sending said super packet to a second multiplexer associated with said first subnetwork under a single resource reservation.
- 20A method for identifying data packets for multiplexing, comprising:receiving at a first multiplexer at least a first setup packet associated with a first packet data flow;determining from said at least a first setup packet a destination for said first data packet flow;receiving at said first multiplexer at least a second setup packet associated with a second packet data flow;determining from said at least a second setup packet a destination for said second data packet flow;in response to said first and second data packet flows being addressed to a destination on a first subnetwork, aggregating at least a first data packet from said first data packet flow with a data packet from said second data packet flow to form a super packet;and sending said super packet to a second multiplexer associated with said first subnetwork.
Independent claims7
73 paragraphs in 5 sections, as filed
FIELD OF THE INVENTION
The present invention is directed to the process of multiplexing packet data flows together into a single aggregate flow. In particular, the present application provides for the identification of individual flows suitable for aggregation into a single, combined flow.
BACKGROUND OF THE INVENTION
The concept of multiplexing packet data flows, including realtime transport protocol (RTP) flows together into a single aggregate flow is a concept that is addressed in a number of Internet engineering task force (IETF) Internet drafts. Multiplexing RTP flows would be desirable, because it can reduce the bandwidth usage of wide area network (WAN) links and decrease the RTP packet rate incident on edge routers. In addition, the multiplexing of RTP flows reduces the burden of administering networks, for example in connection with the configuration of quality of service levels. In addition, multiplexing RTP flows can increase the scalability of existing quality of service schemes.
Although IETF Internet drafts specifying packet formats for aggregate flows, header compression algorithms, and packet loss compensation have been proposed, there are no methods discussed for signaling to a multiplexer which RTP flows to aggregate into a single flow. Although a multiplexer could examine individual RTP flows to determine which packets are candidates for aggregation, doing so would be a significant burden on the multiplexer. In particular, an RTP multiplexer in such a system would be required to examine the destination addresses of individual packets to determine whether they could be aggregated with other packets for transport to another multiplexing device for deaggregation back into individual flows or packets. In addition, requiring a multiplexer to consider the destination addresses of individual packets to determine whether aggregation would be beneficial introduces additional latency into data streams. The addition of latency is particularly undesirable in connection with voice over Internet protocol (VoIP) sessions and may require the addition of costly hardware to the multiplexing device to mitigate or avoid. Furthermore, where explicit information regarding the flows that should be aggregated is not provided to a multiplexer, indeterminancy regarding which flows are aggregated is introduced into the system. This indeterminancy can contribute to delays while the multiplexing devices wait for expected packets that never arrive.
SUMMARY OF THE INVENTION
The present invention is directed to solving these and other problems and disadvantages of the prior art. Generally, according to the present invention, an identifier is assigned to a remote subnetwork having an associated multiplexer. The assigned identifier is communicated to communication devices and to a multiplexer associated with a first subnetwork. Packets originating at communication devices on the first subnetwork that are addressed to endpoints associated with a remote subnetwork for which an identifier has been assigned are associated with that identifier, and provided to the multiplexer on the first subnetwork. The multiplexer then bundles together or aggregates packets that are part of individual communication streams and that are associated with the same identifier, to form a super packet or aggregate stream. The aggregate stream is then passed to a second multiplexer associated with the remote subnetwork. At the second multiplexer, the aggregate stream is unbundled, and packets associated with individual streams are delivered to the appropriate endpoint or destination communication device.
In accordance with an embodiment of the present invention, the identifier is associated with an individual data packet or data stream using a pre-existing field. For example, a virtual local area network (VLAN) field that is typically used for the purpose of distinguishing between virtual local area networks (LANs) on the same physical LAN and resides in the Media Access Control (MAC) header is used to identify a multiplexer on a remote subnetwork. In accordance with another embodiment of the present invention, a differentiated services field (DS) that is normally used to define a type of service requirement is used to communicate the identifier. This field is also known as the type of service field (TOS) and resides in the Internet Protocol (IP) header. In accordance with yet another embodiment of the present invention, a resource reservation protocol (RSVP) field that is normally used to reserve resources on routers to ensure adequate quality of service for the bearer channel of a VoIP call over a WAN link is used to communicate the identifier. In accordance with still another embodiment of the present invention, the RSVP DCLASS object is used to communicate a differentiated services code point (DSCP) that is placed in the differentiated services field and used to identify individual flows that may be aggregated into a combined flow. In accordance with still other embodiments of the present invention, individual flows that may be aggregated are identified using information associated with the session initiation protocol (SIP) or H.323 signals to identify the parameters of the channel being negotiated to determine whether flows can be aggregated.
In accordance with an embodiment of the present invention, a system that provides a multiplexer as part of or in cooperation with a subnetwork router is provided. In addition, a control unit may be provided for assigning an identifier to a remote subnetwork. A system in accordance with the present invention may also include a second multiplexer associated with or implemented as a part of a second edge router associated with a remote or second subnetwork. The first and second edge routers may be interconnected to one another by a wide area network (WAN), which may include the Internet.
In a first aspect there is provided a method for multiplexing packet data transmissions, comprising: assigning an identifier to a first network element; associating in at least a second network element said identifier with a plurality of data packets; recognizing in at least a third network element said identifier with respect to said plurality of data packets; aggregating said plurality of data packets together; and addressing said bundle of data packets to said first network element.
Said third network element may comprise a packet data multiplexer. Said packet data multiplexer may comprise a router.
The method may further comprise: deaggregating said plurality of data packets; delivering a first of said plurality of data packets to a first receiving communication device; and delivering a second of said plurality of data packets to a second receiving communication device.
Said identifier may be communicated using a field established in connection with at least a first protocol for a purpose other than communicating said identifier.
Said identifier may comprise a virtual local area network identifier. Said virtual local area network identifier may be associated with said data packets by writing said identifier as part of a medium access control for said data packets.
Said identifier may comprise a DiffServ Code Point.
Said identifier may comprise a resource reservation protocol request.
Said step of associating a plurality of data packets with said identifier may comprise associating said identifier with a first data packet in a first originating communication device and associating said identifier with a second data packet in a second originating communication device.
In a second aspect there is provided a system for multiplexing packet data transmissions, comprising: at least first communication device means for forming data packets and for marking said data packets with an identifier using an existing data field; first means for aggregating first and second data packets associated with said identifier into a super packet; means for interconnecting said first means for aggregating to a communication network, wherein said super packet may be transmitted to a remote subnetwork.
Said existing data field is preferably not an Internet protocol address field.
The system may further comprise means for associating a remote subnetwork with said identifier.
The system may further comprise means for deaggregating said super packet.
In a third aspect there is provided a data packet, comprising: header information, wherein said header information addresses said data packet to a first network element having a first address; a first sub-data packet, wherein said first sub-data packet is addressed to a first data consumer and is associated with said first network element by a first identifier, wherein said first identifier is different from said first address; a second sub-data packet, wherein said second sub-data packet is addressed to a second data consumer and is associated with said first network element by said first identifier.
Said first and second sub-data products may contain said first identifier in a header field that is established for other than identifying a network element.
Said first identifier is preferably not an Internet protocol address.
A payload of said data packet may comprise said first and second sub-packets.
A payload of each of said first and second data packets may comprise data.
Said data payload of each of said first and second data products may comprise voice data.
In a fourth aspect there is provided a data multiplexer comprising: an interface, wherein a plurality of the packets marked with a first identifier and containing a destination address other than said first identifier are received; and a processor running operating code, wherein said plurality of data packets are aggregated with a super packet and provided to said interface for delivery.
Said interface may comprise an input from a first communication network and an output to at least one of a router and a second communication network.
The data multiplexer may further comprise: data storage, wherein said operating code comprises software.
In a fifth aspect there is provided a computational component for performing a method, the method comprising: receiving a first data packet containing a first destination address in an address field and a first identifier in a second field, wherein said first identifier identifies a first network element having a second destination address, wherein said second field is defined by at least a first network protocol for purposes other than communicating an identifier identifying a network element; receiving a second data packet containing at least one of said first destination address and a second destination address in an address field and said first identifier in a second field; and forming a super packet containing as a payload said first and second data packets, wherein said super packet contains said second destination address in an address field.
Said second field may comprise at least one of: a virtual local area network identifier field; a differential service code point field; a resource reservation protocol field; a resource reservation protocol DCLASS object field; or a session initiation protocol field.
Said first network element may comprise a multiplexer on a remote subnetwork. Said first destination address may comprise an endpoint on said remote subnetwork.
Said first and second data packets may each include a payload comprising data.
Said computational component may comprise a computer readable storage medium carrying instructions for performing the method.
In a sixth aspect there is provided a method for identifying data packets for multiplexing, comprising: receiving at a first multiplexer a first request to reserve resources for a first packet data flow; determining from said request a destination for said first data packet flow; receiving at said first multiplexer a second request to reserve resources for a second packet data flow; determining from said request a destination for said second data packet flow; in response to said first and second data packet flows being addressed to a destination on a first subnetwork, aggregating at least a first data packet from said first data packet flow with a data packet from said second data packet flow to form a super packet; and sending said super packet to a second multiplexer associated with said first subnetwork under a single resource reservation.
The method may further comprise in response to receiving said first request to reserve resources, providing a first identifier to a first communication device making said first request, wherein data packets from said first communication device and associated with said first request are marked with said first identifier.
Said single resource reservation may request a first quantity of resources. The method may further comprise receiving at said multiplexer a third request to reserve resources for a third packet data flow, wherein said single reservation requests a second quantity of resources.
In a seventh aspect there is provided a method for identifying data packets for multiplexing, comprising: receiving at a first multiplexer at least a first setup packet associated with a first packet data flow; determining from said at least a first setup packet a destination for said first data packet flow; receiving at said first multiplexer at least a second setup packet associated with a second packet data flow; determining from said at least a second setup packet a destination for said second data packet flow; in response to said first and second data packet flows being addressed to a destination on a first subnetwork, aggregating at least a first data packet from said first data packet flow with a data packet from said second data packet flow to form a super packet; and sending said super packet to a second multiplexer associated with said first subnetwork.
Said setup packet may comprise at least one of a session initiation protocol and an H.323 protocol packet.
These and other advantages and features of the invention will become more apparent from the following discussion, particularly when taken together with the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
<ul id="ul0001" list-style="none" compact="compact"><li>Fig. 1 is a block diagram depicting a communication system in accordance with an embodiment of the present invention;</li><li>Fig. 2 is a diagram depicting packet flow through a subnetwork in accordance with an embodiment of the present invention;</li><li>Fig. 3 is a flow chart illustrating the aggregation of data packets in accordance with an embodiment of the present invention;</li><li>Fig. 4 is a flow chart depicting the identification of packets suitable for aggregation in accordance with an embodiment of the present invention;</li><li>Fig. 5 is a flow chart depicting the identification of packets suitable for aggregation in accordance with another embodiment of the present invention;</li><li>Fig. 6 is a flow chart depicting the identification of packets suitable for aggregation in accordance with another embodiment of the present invention;</li><li>Fig. 7 is a flow chart depicting the identification of packets suitable for aggregation in accordance with another embodiment of the present invention; and</li><li>Fig. 8 is a flow chart depicting the identification of packets suitable for aggregation in accordance with another embodiment of the present invention.</li></ul>
DETAILED DESCRIPTION
The present invention is directed to the identification of data packets suitable for aggregation into a combined flow.
In <b>Fig. 1</b>, a communication system <b>100</b> in accordance with an embodiment of the present invention is illustrated. In general, the communication system <b>100</b> includes a first subnetwork <b>104</b> and a second or remote subnetwork <b>108</b>. The first subnetwork <b>104</b> is interconnected to the second subnetwork <b>108</b> by a communication network <b>112.</b> The communication network <b>112</b> generally comprises a packet data network or combination of packet data and switched circuit networks. As an example, the communication network <b>112</b> may comprise the Internet, an intranet, or a combination of one or more intranets and the Internet.
The first subnetwork <b>104</b> generally includes a plurality of communication devices <b>116.</b> The communication devices <b>116</b> are each interconnected to a multiplexer <b>120</b>. A control unit <b>124</b> may be provided for coordinating activity between or among the communication devices <b>116</b> and the multiplexer <b>120</b>. The first subnetwork <b>104</b> additionally includes an edge router <b>128</b> that interconnects the first subnetwork <b>104</b> to the communication network <b>112</b>.
Like the first subnetwork <b>104</b>, the second subnetwork <b>108</b> may include a plurality of communication devices <b>132,</b> a multiplexer <b>136,</b> a control <b>140,</b> and an edge router <b>144.</b>
In accordance with an embodiment of the present invention, the subnetworks <b>104, 108</b> may comprise local area networks (LANs). Accordingly, one or both subnetworks <b>104,108</b> may be implemented as Ethernet networks.
The communication devices <b>116, 132</b> associated with the system <b>100</b> may include any device suitable for sending packet data across a communication network or subnetwork. Accordingly, the communication devices <b>116, 132</b> may comprise Internet protocol telephones, general purpose computers, personal digital assistants (PDAs) or other computing devices configured to function in connection with media communications, including communications that occur in realtime. The multiplexers <b>120</b>, <b>136</b> generally function to aggregate media or data streams into bundled streams comprising super packets containing data packets that may originate from a number of communication devices (e.g., communication devices <b>116</b>) associated with the first subnetwork <b>104</b> and that are addressed to one or more communication devices (e.g., communication devices <b>132</b>) associated with a remote subnetwork <b>108</b>. In connection with the receipt of aggregated data streams, a multiplexer (e.g., the second multiplexer <b>136</b>) unbundles the aggregated streams to allow delivery of individual streams to recipient communication devices <b>132</b>. As can be appreciated, the above described functions are generally reversed in connection with data packets originating at or through communication devices <b>132</b> associated with the second subnetwork <b>108</b> that are transmitted to communication devices <b>116</b> associated with the first subnetwork <b>104</b>. In accordance with embodiments of the present invention, the multiplexers <b>120, 136</b> are implemented as general purpose or server computers running software implementing the bundling and unbundling functions. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement a multiplexer <b>120, 136</b>. In accordance with another embodiment of the present invention, the multiplexers <b>120, 136</b> may be implemented as a part of the respective edge routers <b>128</b> or <b>144.</b> In accordance with yet another embodiment the multiplexers <b>120, 136</b> may be implemented as a specialized device employing appropriate specialized hardware and configured as the network gateway for other VoIP devices to provide transparent access to those devices' data streams (<i>e.g.</i>, RTP streams) if necessary.
The controls <b>124, 140</b> generally function to coordinate activity between the communication devices <b>116, 132</b> and the associated multiplexer <b>120</b> or <b>136</b>. For example, the first control <b>124</b> may assign an identifier for use in connection with packets originating at or through communication devices <b>116</b> associated with the first subnetwork <b>104</b> that are addressed to communication devices <b>132</b> associated with the second subnetwork <b>108</b>. The controls <b>124, 140</b> may be implemented as general purpose computers. In accordance with a further embodiment of the present invention, each control <b>124, 140</b> may be implemented as part of the corresponding multiplexer <b>120, 136</b> and/or edge router <b>128, 144</b>.
The edge routers <b>128, 144</b> generally function to interconnect the respective subnetwork <b>104</b> or <b>108</b> to a communication network <b>112</b>. In addition, an edge router <b>128, 144</b> in accordance with an embodiment of the present invention may incorporate the multiplexer <b>120, 136</b> and/or control <b>124, 140</b> of the respective subnetwork <b>104,108</b>.
With reference now to <b>Fig. 2</b>, the composition of data packets transmitted in accordance with an embodiment of the present invention are illustrated. In general, each of the communication devices <b>116, 132</b> is capable of transmitting (or receiving) data packets that include various fields. In particular, each of the data packets or individual data streams <b>204</b> includes various header information fields <b>208,</b> such as the medium access control, Internet protocol, universal datagram protocol (UDP), realtime transport protocol (RTP), and medium access control cyclic redundancy check (MAC CRC) fields. In addition, each of the data packets <b>204</b> generally contains a payload <b>212</b>, such as a G.729 payload. Furthermore, in accordance with the present invention, each of the data packets <b>204</b> includes a destination subnetwork Id <b>216</b>. As will be described in greater detail below, the destination subnetwork Id <b>216</b> may be included within another of the fields, including any of the header information fields <b>208</b>. The individual data packets <b>204</b> are provided to (or received from) the multiplexer <b>120, 136</b> associated with the subnetwork <b>104, 108</b>.
The multiplexer <b>120, 136</b> aggregates the individual data packets <b>204</b> together into one or more super packets or aggregate data streams <b>220</b>. As can be seen from <b>Fig. 2</b>, the super packet <b>220</b> includes its own header information. In addition, the super packet <b>220</b> includes the header information <b>208</b> and payloads <b>212</b> from the individual data packets <b>204</b>. The super packet <b>220</b> is provided to (or received from) the edge router <b>128, 136</b>.
As can be appreciated by one of skill in the art, the aggregation of individual data packets <b>204</b> into a super packet <b>220</b> generally reduces the burden on the edge router <b>128</b>, <b>136</b>. In particular, by aggregating multiple individual packets <b>204</b> into a lesser number of super packets <b>220</b>, the number of individual packets that must be routed by the edge router <b>128, 136</b> is reduced. Furthermore, because it is the ability of a router <b>128, 136</b> to classify and route data packets, and not the bandwidth of the router's interfaces <b>128, 136</b> that typically limits a router's effective bandwidth, the present invention can increase the data transmission capabilities of a network or subnetwork <b>104, 108</b> carrying data streams having a large number of small packets.
With reference now to <b>Fig. 3,</b> a flow chart depicting the operation of a system <b>100</b> in accordance with an embodiment of the present invention is shown. Initially, at step <b>300</b>, an identifier <b>216</b> is assigned to a remote subnetwork <b>108</b>. At step <b>304a</b>, voice data addressed to a first communication device <b>132a</b> on the remote subnetwork <b>108</b> is received at a first communication device <b>116a</b> on the first subnetwork <b>104</b>. Similarly, at step <b>304b</b>, voice data addressed to a second communication device <b>132b</b> on the remote subnetwork <b>108</b> is received at a second communication device <b>116b</b> on the first subnetwork <b>104.</b> In addition, voice data may be received at an n<sup>th</sup> communications device <b>116n</b> that is addressed to an n<sup>th</sup> communication device <b>132n</b> on the remote subnetwork <b>108</b> (step <b>304n).</b> At steps <b>308a-308n,</b> the received data is packetized by the respective communication device <b>116a-116n.</b> At steps <b>312a-312n,</b> the assigned identifier <b>216</b> for the remote subnetwork <b>108</b> is associated with the packetized data by the respective communication device <b>116a-116n,</b> and the communication devices <b>116a-116n</b> send their data packets <b>204</b> to the multiplexer <b>120.</b>
At step <b>316</b>, the multiplexer <b>120</b> on the first subnetwork <b>104</b> bundles the packets <b>204</b> associated with the same identifier <b>216</b> together with one or more super packets or flows <b>220</b>, and sends them to the remote subnetwork <b>108</b> across the communication network <b>112</b>. As can be appreciated by one of skill in the art, by sending the various data packets <b>204</b> received from the communication devices <b>116a-116n</b> as a single super packet <b>220</b>, the processing load placed on the edge routers <b>128, 124</b> and the switches and routers associated with the communication network <b>112</b> is lessened. For instance, in the example illustrated in <b>Fig. 3</b>, instead of the three individual packets <b>204</b>, only the header information associated with the single super packet must be considered by the routers and switches.
At step <b>320</b>, the multiplexer <b>136</b> on the remote subnetwork <b>108</b> receives the super packet <b>220,</b> unbundles the aggregate flow, and sends the individual flows (i.e., the individual packets <b>204)</b> to the destination communication devices <b>132a-132n.</b> At steps <b>324a-324n,</b> the packetized voice data is received at the appropriate communication device <b>132a-132n</b> on the remote subnetwork <b>108.</b>
With reference now to <b>Fig. 4,</b> the operation of a system <b>100</b> in accordance with an embodiment of the present invention is illustrated. In general, the embodiment illustrated in connection with <b>Fig. 4</b> utilizes the virtual local area network (VLAN) identification field provided in connection with data packets <b>204</b> transmitted across the subnetwork <b>104</b> or <b>108</b> to associate or identify individual packets <b>204</b> with a multiplexer <b>136</b> at a remote subnetwork <b>108</b>. More particularly, the VLAN Id field in the MAC header is used to identify a data packet <b>204</b> as being addressed to a communication device <b>132</b> associated with a remote subnetwork <b>108</b> having a multiplexer <b>136</b> in accordance with the present invention. As can further be appreciated, the assigned VLAN Id is selected so that it does not correspond to a valid virtual local area network established in connection with the first <b>104</b> or second <b>108</b> subnetworks.
Initially, at step <b>400</b>, a VLAN Id is assigned in connection with a remote subnetwork <b>108</b>. In particular, the first control <b>124</b> may function to select a VLAN Id to identify a remote subnetwork <b>108</b> having a multiplexer <b>136</b> in accordance with the present invention. Furthermore, the control <b>124</b> communicates the assigned identifier to each of the communication devices <b>116</b> on the first subnetwork <b>104</b>, so that the communication devices <b>116</b> may utilize the identifier when they have data packets <b>204</b> addressed to communication devices <b>132</b> on the remote subnetwork <b>108</b>.
At step <b>404</b>, the first multiplexer <b>120</b> receives data packets <b>204</b> addressed to communication devices <b>132</b> on the remote subnetwork <b>108</b> that are marked with the assigned VLAN Id associated with the remote subnetwork <b>108.</b> The mutliplexer <b>120</b> aggregates packets <b>204</b> having the same VLAN Id together into one or more super packets <b>220</b> (step <b>408</b>).
The first multiplexer <b>120</b> then sends the super packet <b>220</b> to the second multiplexer <b>136</b> on the remote subnetwork <b>108</b>. The second multiplexer <b>136</b> deaggregates the super packet <b>220</b>, and sends the individual packets <b>204</b> to the appropriate communication devices <b>132</b> on the remote subnetwork <b>108</b> (step <b>416</b>) as individual streams.
As can be appreciated from the description given herein in connection with <b>Fig. 4</b>, the transmitting multiplexer <b>120</b> is not required to consider whether the destination addresses of the individual packets <b>204</b> make those packets <b>204</b> suitable for aggregation into a super packet <b>220.</b> Instead, the multiplexer <b>120</b> is only required to consider the relatively short VLAN Id field within each packet <b>204</b> to determine whether it contains an identifier associated with a second multiplexer <b>136</b> on a remote subnetwork <b>108</b>. Furthermore, it can be appreciated that an embodiment in accordance with that described in connection with <b>Fig. 4</b> does not require the definition of new data packet <b>204</b> information or header fields. Instead, a preexisting field is utilized. As can also be appreciated, the super packet <b>220</b> is sent to an address associated with the second multiplexer <b>136</b>. Upon receiving a super packet <b>220</b> addressed directly to it, the second multiplexer <b>136</b> then unbundles the individual data streams <b>204</b> of the super packet <b>220</b> and delivers the individual packets <b>204</b> as noted above.
With reference now to <b>Fig. 5</b>, the operation of a system <b>100</b> in accordance with another embodiment of the present invention is illustrated. In general, the embodiment illustrated in <b>Fig. 5</b> utilizes the differentiated services field (DS) or Type of Service (TOS) field in the IP Header in order to identify individual data streams <b>204</b> that are addressed to communication devices <b>132</b> on a remote subnetwork <b>108</b> having a multiplexer <b>136</b> in accordance with the present invention.
At step <b>500</b>, a Diffserv Code Point (DSCP) is assigned to the remote subnetwork <b>108.</b> At step <b>508</b>, the first multiplexer <b>120</b> receives data packets <b>204</b> addressed to communication devices <b>132</b> on the remote subnetwork <b>108</b> and marked with the DSCP assigned to that remote subnetwork <b>108</b>. The first multiplexer <b>120</b> then aggregates the individual data packets or flows <b>204</b> having a common DSCP into one or more super packets or aggregate flows <b>220</b> addressed to the second multiplexer <b>136</b> (step <b>512</b>). The super packet <b>220</b> is then sent to the second multiplexer <b>136</b> on the remote subnetwork <b>108</b> (step <b>516</b>). The multiplexer <b>136</b> on the remote subnetwork <b>108</b> deaggregates the super packet <b>220</b>, and sends the individual packets <b>204</b> comprising individual data streams to the appropriate communication devices <b>132</b> on the remote subnetwork <b>108</b> (step <b>520</b>).
From the description given herein with respect to <b>Fig. 5</b>, it can be appreciated that an embodiment utilizing the DS field allows a multiplexer <b>120</b> to identify data packets <b>204</b> suitable for aggregation into a super packet <b>220</b> simply by considering the relatively short DSCP field associated with such data packets. Upon identifying multiple data packets <b>204</b> associated with a DSCP that has been assigned to a remote subnetwork <b>108</b>, the multiplexer <b>120</b> bundles the individual packets <b>204</b> together, and addresses the resulting super packet <b>220</b> to the multiplexer <b>136</b> associated with the remote subnetwork <b>108.</b> The multiplexer can place an appropriate DSCP value in the DS field of the super packet to nominate the required per hop behavior for the WAN portion of the communications network.
With reference now to <b>Fig. 6</b>, the operation of a system <b>100</b> in accordance with yet another embodiment of the present invention is illustrated. In general, the embodiment described with reference to <b>Fig. 6</b> utilizes the resource reservation protocol (RSVP) protocol to identify the source and destination address and port associated with individual data packets <b>204</b> in order to determine what RTP data flows can be expected. Individual data packets <b>204</b> that are part of such flows and that are addressed to communication devices <b>132</b> on the same subnetwork <b>108</b> are then aggregated into one or more super packets <b>220</b>.
As an example of the operation of such an embodiment, an RSVP enabled VOIP communication device <b>116</b> is configured to use the first multiplexer <b>120</b> on the first subnetwork <b>104</b> as its default IP gateway (step <b>600</b>). At step <b>604</b>, a voice over Internet protocol session or other communication session is initiated. At step <b>608</b>, an RSVP request (PATH message) to provide a certain quality of service for the RTP stream is sent to the multiplexer <b>120</b> by the communication device <b>116</b>.
The multiplexer <b>120</b> determines the destination of the individual flow or RTP stream that will be received from the communication device <b>116</b>, and assigns that flow to a new or existing aggregate flow (step <b>612).</b> At step <b>616,</b> a return reservation message (RESV message) to the communication device <b>116</b> is emulated by the multiplexer <b>120</b> and delivered to the communication device <b>116.</b> The communication device <b>116</b> then sends individual packets <b>204</b> to the multiplexer <b>120.</b> The individual packets <b>204</b> are received at the multiplexer <b>120</b>, and are placed in a super packet <b>220</b> for delivery to the remote subnetwork <b>108</b> under a single RSVP reservation (step <b>620</b>) that is maintained between the multiplexer and the remote multiplexer. The parameters of the RSVP reservation may be changed to accommodate the different requirements of the aggregate flows. The super packet <b>220</b> is received at the multiplexer <b>136</b> associated with the remote subnetwork <b>108</b>, which deaggregates the super packet <b>220,</b> and sends the individual packets <b>204</b> to the appropriate communication device or devices <b>132</b> on the remote subnetwork <b>108</b> (step <b>624</b>).
As can be appreciated from the description set forth herein, an embodiment of the present invention utilizing the RSVP field allows the multiplexer <b>120</b> to know what VoIP flows to expect from the communication devices <b>116</b>. However, the multiplexer <b>120</b> must examine the destination address of at least one individual packet <b>204</b> within an identified flow to determine the destination address of that flow. Therefore, the destination address serves as the initial identifier of individual data packets <b>204</b>. RSVP information may then be used to identify packets suitable for aggregation. The information provided as part of the RSVP request also communicates when the individual flows begin and end, so that the multiplexer <b>120</b> can determine how many resources must be requested in connection with the created super packet <b>220</b> in order to ensure a desired level of service.
In <b>Fig. 7</b>, a flow chart depicting the operation of a system <b>100</b> in accordance with yet another embodiment of the present invention is illustrated. In general, the embodiment illustrated in <b>Fig. 7</b> utilizes the DS field to identify flows, and also uses information included as part of RSVP requests provided in connection with individual data streams to make a single RSVP request for an aggregate stream. According to such an embodiment, at step <b>700,</b> a DSCP is assigned to identify a remote subnetwork <b>108.</b> At step <b>704,</b> an RSVP enabled VoIP communication device <b>116</b> is configured with the multiplexer <b>120</b> on the first subnetwork <b>104</b> as the device's default IP gateway. The VoIP session is then initiated (step <b>708</b>).
At step <b>712</b>, the communication device <b>116</b> sends an RSVP request to the multiplexer <b>120</b> on the first subnetwork <b>104</b> (step <b>712</b>). The multiplexer <b>120</b> then assigns the flow <b>204</b> associated with the RSVP request to a position within a new or existing aggregate flow <b>220</b> (step <b>716).</b>
At step <b>720,</b> the multiplexer <b>120</b> requests an RSVP reservation for the aggregate flow <b>220.</b> The multiplexer <b>120</b> receives a return RSVP message, emulates the correct reservation message back to the communication device <b>116,</b> and inserts a DCLASS object containing the assigned DSCP (step <b>724</b>).
The communication device <b>116</b> then marks individual packets with the assigned DSCP, and sends the packets <b>204</b> to the multiplexer <b>120</b> (step <b>728</b>). The multiplexer <b>120</b> aggregates the packets <b>204</b> having common DSCPs into one or more super packets <b>220</b>, and delivers the super packets <b>220</b> to the remote subnetwork <b>108</b> under a single RSVP reservation (step <b>732</b>). The super packets <b>220</b> are received at the second multiplexer <b>136</b> on the remote subnetwork <b>108</b>, which deaggregates the super packets <b>220</b>, and sends the individual packets <b>204</b> to the appropriate communication devices <b>132</b> on the remote subnetwork <b>108</b> (step <b>736</b>).
From the above description, it can be appreciated that the multiplexer <b>120</b> is only required to consider the DS fields in order to determine whether an individual data packet <b>204</b> is suitable for aggregation into a super packet <b>220</b>. In addition, the embodiment discussed in connection with <b>Fig. 7</b> allows a single RSVP reservation to be established in connection with a super packet <b>220.</b> Accordingly, a desired level of service may be maintained, without requiring that a separate RSVP reservation be established for each of the individual data packets <b>220.</b>
With reference now to <b>Fig. 8</b>, a flow chart illustrating the operation of a system <b>100</b> in accordance with another embodiment of the present invention is illustrated. Initially, at step <b>800</b>, packets associated with an RTP flow are received at a first multiplexer <b>120</b>. The first multiplexer <b>120</b> inspects setup packets, defined according to any telephony signaling protocol, such as session initiation protocol (SIP) or H.323, used to initiate the media channel associated with the received packets (step <b>804</b>). For example, in connection with a flow utilizing the session initiation protocol, the INVITE and ACK packets would be inspected to determine the parameters of the channel being negotiated. The multiplexer <b>120</b> then aggregates individual packets <b>204</b> that are addressed to a common remote subnetwork into one or more super packets <b>220</b> (step <b>808).</b> The super packet <b>220</b> is then delivered to the remote subnetwork <b>108</b> (step <b>812)</b>. The multiplexer <b>136</b> associated with the remote subnetwork <b>108</b> then deaggregates the super packet <b>220</b>, and sends the individual packets <b>204</b> to the appropriate communication devices <b>132</b> on the remote subnetwork <b>108</b> (step <b>816</b>). The embodiment described in connection with <b>Fig. 8</b> allows a router <b>128, 144</b> to identify individual flows <b>204</b> that are suitable for aggregation into a super packet <b>220</b>, and also explicitly signals, according to the particular telephony signaling protocol used, the start and end of a realtime transport protocol flow.
Although the descriptions given above in connection with the various embodiments of the present invention have generally used the transmission of voice data in accordance with voice over Internet protocols or other realtime transfer protocols as examples, it should be appreciated that the present invention is not so limited. In particular, the present invention may be applied in connection with any transmission of data across a packet data network.
The foregoing discussion of the invention has been presented for purposes of illustration and description. Further, the description is not intended to limit the invention to the form disclosed herein. Consequently, variations and modifications commensurate with the above teachings, within the skill and knowledge of the relevant art, are within the scope of the present invention. The embodiments described hereinabove are further intended to explain the best mode presently known of practicing the invention and to enable others skilled in the art to utilize the invention in such or in other embodiments with various modifications required by their particular application or use of the invention. It is intended that the appended claims be construed to include the alternative embodiments to the extent permitted by the prior art.
Contents5
8 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| EP1985028A1 | Cited by | European Patent Office (EPO) | Search report |
| EP3007393A4 | Cited by | European Patent Office (EPO) | Search report |
| WO2006104772A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| WO2008112466A3 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US7489702B2 | Cited by | United States of America | Applicant |
| US11997005B2 | Cited by | United States of America | Search report |
| US7729328B2 | Cited by | United States of America | Applicant |
| EP1985028A4 | Cited by | European Patent Office (EPO) | Search report |
| WO2008112466A2 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US9876734B2 | Cited by | United States of America | Applicant |
12 members in 4 offices
Priority claims5
| Document | Office | Kind | Date |
|---|---|---|---|
| 355542 | United States of America | – | |
| 35554203 | United States of America | A | |
| 35554203 | United States of America | A | |
| 355542 | – | – | – |
| US20030355542 | – | – | – |
Members12
| Document | Office | Kind | |
|---|---|---|---|
| CA2454997A1 | Canada | A1 | |
| EP1443733A2This record | European Patent Office (EPO) | A2 | |
| US2004151206A1 | United States of America | A1 | |
| JP2004236332A | Japan | A | |
| EP1443733A3 | European Patent Office (EPO) | A3 | |
| CA2454997C | Canada | C | |
| JP4030968B2 | Japan | B2 | |
| US7525994B2 | United States of America | B2 | |
| EP2259549A1 | European Patent Office (EPO) | A1 | |
| EP2259549B1 | European Patent Office (EPO) | B1 | |
| EP1443733B1 | European Patent Office (EPO) | B1 | |
| EP1443733B8 | European Patent Office (EPO) | B8 |
52 legal events, as 4 offices reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | Office | |
|---|---|---|---|
| Lapsed in a contracting state [announced via postgrant information from national office to epo]LapsedPG25 | PG25 | EP | |
| Patent expired after termination of 20 yearsExpiredPE20 | PE20 | GB | |
| Expiry of rightR071 | R071 | DE | |
| Opt-out of the competence of the unified patent court (upc) registeredP01 | P01 | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Annual fee paid to national office [announced via postgrant information from national office to epo]GrantedPGFP | PGFP | EP | |
| Amendment of ipc main classPREVIOUS MAIN CLASS: H04L0029060000R079 | R079 | DE | |
| No opposition filedOpposition26N | 26N | EP | |
| No opposition filed within time limitOppositionORIGINAL CODE: 0009261PLBE | PLBE | EP | |
| Information on the status of an ep patent application or granted ep patentGrantedSTATUS: NO OPPOSITION FILED WITHIN TIME LIMITSTAA | STAA | EP | |
| Fee paymentPLFP | PLFP | FR | |
| No opposition filed against granted patent, or epo opposition proceedings concluded without decisionGrantedR097 | R097 | DE | |
| Amendments to the register in respect of changes of name or changes affecting rights (sect. 32/1977)REGISTERED BETWEEN 20171005 AND 20171011732E | 732E | GB | |
| Change of applicant/patenteeR081 | R081 | DE | |
| Change of representativeR082 | R082 | DE | |
| Dpma publication of mentioned ep patent grantGrantedR096 | R096 | DE | |
| Party data changed (patent owner data changed or rights of a patent transferred)RAP2 | RAP2 | EP | |
| Party data changed (patent owner data changed or rights of a patent transferred)RAP2 | RAP2 | EP | |
| Change of applicant/patenteeR081 | R081 | DE | |
| Designated contracting statesAK | AK | EP | |
| European patent grantedGrantedFG4D | FG4D | GB | |
| Intention to grant announcedINTG | INTG | EP | |
| (expected) grantORIGINAL CODE: 0009210GRAA | GRAA | EP | |
| Information on the status of an ep patent application or granted ep patentGrantedSTATUS: THE PATENT HAS BEEN GRANTEDSTAA | STAA | EP | |
| Intention to grant announced (deleted)INTC | INTC | EP | |
| Information related to intention to grant a patent recordedORIGINAL CODE: EPIDOSNIGR71GRAR | GRAR | EP | |
| Information on the status of an ep patent application or granted ep patentGrantedSTATUS: GRANT OF PATENT IS INTENDEDSTAA | STAA | EP | |
| Information related to disapproval of communication of intention to grant by the applicant or resumption of examination proceedings by the epo deletedORIGINAL CODE: EPIDOSDIGR1GRAJ | GRAJ | EP | |
| Information related to payment of fee for publishing/printing deletedORIGINAL CODE: EPIDOSDIGR3GRAL | GRAL | EP | |
| Information on the status of an ep patent application or granted ep patentGrantedSTATUS: EXAMINATION IS IN PROGRESSSTAA | STAA | EP | |
| Grant fee paidORIGINAL CODE: EPIDOSNIGR3GRAS | GRAS | EP | |
| Information on the status of an ep patent application or granted ep patentGrantedSTATUS: GRANT OF PATENT IS INTENDEDSTAA | STAA | EP | |
| Intention to grant announcedINTG | INTG | EP | |
| Despatch of communication of intention to grant a patentORIGINAL CODE: EPIDOSNIGR1GRAP | GRAP | EP | |
| Information provided on ipc code assigned before grantRIC1 | RIC1 | EP | |
| Information provided on ipc code assigned before grantRIC1 | RIC1 | EP | |
| Information provided on ipc code assigned before grantRIC1 | RIC1 | EP | |
| Party data changed (applicant data changed or rights of an application transferred)RAP1 | RAP1 | EP | |
| Party data changed (applicant data changed or rights of an application transferred)RAP1 | RAP1 | EP | |
| Party data changed (applicant data changed or rights of an application transferred)RAP1 | RAP1 | EP | |
| Designation fees paidAKX | AKX | EP | |
| Request for examination filed17P | 17P | EP | |
| Designated contracting statesAK | AK | EP | |
| Request for extension of the european patentAX | AX | EP | |
| Information provided on ipc code assigned before grantRIC1 | RIC1 | EP | |
| Information provided on ipc code assigned before grantRIC1 | RIC1 | EP | |
| Information provided on ipc code assigned before grantRIC1 | RIC1 | EP | |
| Search report despatchedORIGINAL CODE: 0009013PUAL | PUAL | EP | |
| Designated contracting statesAK | AK | EP | |
| Request for extension of the european patentAX | AX | EP | |
| Public reference made under article 153(3) epc to a published international application that has entered the european phaseORIGINAL CODE: 0009012PUAI | PUAI | EP |
Numbers
- Publication
- 1443733
- Publication, DOCDB
- 1443733
- Publication, EPODOC
- EP1443733
- Application
- 4250532
- Application, DOCDB
- 04250532
- Application, EPODOC
- EP20040250532
Titles3
- German
- Identifizierung von Paketdatenflüssen zum Multiplexen
- English
- Packet data flow identification for multiplexing
- French
- Identification de flux de données par paquets pour multiplexage
Classification
- CPC, 16
- H04L47/2441
- H04L47/2408
- H04L47/2416
- H04L47/41
- H04L47/724
- H04L47/801
- H04L65/80
- H04L69/22
- H04L69/10
- H04L2212/00
- Y02D30/50
- H04L65/765
- H04L65/65
- H04L65/1104
- H04L47/10
- H04L65/1101
- IPC, 3
- H04J3 24
- H04L12 56
- H04L47 41
Designated states2
- Contracting states, 1
- Türkiye
- Extension states, 1
- North Macedonia