Source: http://patents.com/us-10142119.html
Timestamp: 2019-01-18 16:38:28
Document Index: 752793208

Matched Legal Cases: ['arts 33', 'art 33', 'art 33', 'arts 33', 'arts 33', 'arts 33', 'arts 33', 'arts 33', 'arts 33', 'art 33', 'art 33', 'art 33']

US Patent # 1,014,2119. Communication method and apparatus using changing destination and return destination ID's - Patents.com
United States Patent 10,142,119
De Jong November 27, 2018
De Jong; Eduard K. (Amsterdam, NL)
Family ID: 1000003676763
14/841,185
US 20160006572 A1 Jan 7, 2016
11987659 Dec 3, 2007 9137212
60872507 Dec 4, 2006
Current CPC Class: H04L 12/18 (20130101); H04L 63/08 (20130101); H04L 63/0428 (20130101); G06F 11/1004 (20130101)
Current International Class: G06F 15/16 (20060101); G06F 11/10 (20060101); H04L 12/18 (20060101); H04L 29/06 (20060101)
5592488 January 1997 Thomann
5802519 September 1998 De Jong
5941988 August 1999 Bhagwat
6058483 May 2000 Vannel
6157955 December 2000 Narad
6172972 January 2001 Birdwell
6359886 March 2002 Ujihara
6725272 April 2004 Susai
6842446 January 2005 Everson
6963982 November 2005 Brustoloni
7046625 May 2006 Kasper
7215684 May 2007 Rosen
7555608 June 2009 Naik
7565463 July 2009 Johnsen
7710978 May 2010 Signaoff
7821931 October 2010 Swenson
7936682 May 2011 Singh
2001/0023460 September 2001 Boucher
2003/0076794 April 2003 Kawasaki
2003/0210663 November 2003 Everson
2004/0049596 March 2004 Schuehler
2004/0123221 June 2004 Huffman
2004/0151109 August 2004 Batra
2005/0122986 June 2005 Starr
2005/0278459 December 2005 Boucher
2006/0098585 May 2006 Singh
2007/0192543 August 2007 Naik
2007/0242696 October 2007 Signaoff
2008/0049774 February 2008 Swenson
8902140 Mar 1989 WO
9935791 Jul 1999 WO
PCT/NL00/00510 Jul 2000 WO
0172012 Sep 2001 WO
1. A method of communicating a series of communication primitives during a multicast communication session between an originating communication unit and listening communication units, the method comprising: with an originating communication unit executing on an originating computer, sending at least a first and a second multicast communication primitive, as part of the series of communication primitives, to the listening communication units via a network, wherein each listening communication unit is executing on a respective one of a plurality of listening computers, and each one of the listening communication units being a receiver of the series of communication primitives; and with the originating communication unit prior to the sending of the second multicast communication primitive, changing the multicast destination ID during the multicast communication session to generate a changed multicast destination ID, the first multicast communication primitive comprising at least the multicast destination ID, the second multicast communication primitive comprising at least the changed multicast destination ID, wherein the changing of the multicast destination ID during the multicast session further comprises: with the originating communication unit determining that the multicast destination ID has been used a predetermined number of times in multicast communication primitives during the multicast communication session; and with the originating communication unit sending a pseudo random number employable to derive the changed multicast destination ID in a given multicast communication primitive, as part of the series of communication primitives, the given multicast communication primitive comprising the multicast destination ID; and with the originating communication unit sending data in the series of communication primitives, the series of communication primitives being recognized by the listening communication units during the multicast communication session before and after sending the second multicast communication primitive.
2. The method of claim 1, further comprising: sending a requesting communication primitive by a sending communication unit to the originating communication unit, the requesting communication primitive specifying that the sending communication unit requests to become a listening communication unit in a specified multicast communication session.
3. The method of claim 1, further comprising: sending an initiating communication primitive by the originating communication unit to a communication unit, the initiating communication primitive specifying that the communication unit is invited to join as a listening communication unit in a specified multicast communication session.
4. The method of claim 1, the method further comprising: calculating the changed multicast destination ID by each one of the plurality of the listening communication units using the pseudo random number in the given multicast communication primitive rendering a calculated changed multicast destination ID; and storing the calculated changed multicast destination ID in memory of each one of the listening communication units.
5. The method of claim 1, wherein the communication primitive includes a checksum and the method further comprises: receiving, by a receiving communication unit, the communication primitive; and verifying, by the receiving communication unit, the checksum during a process of accepting the communication primitive by the receiving communication unit.
6. The method of claim 1, further comprising: with each of the listening communication units applying a predetermined computational rule on the pseudo random number in the given multicast communication primitive to derive the changed multicast destination ID.
7. A method of communicating a series of communication primitives during a multicast communication session between an originating communication unit and listening communication units, the method comprising: with an originating communication unit executing on an originating computer, sending multicast communication primitives, as part of the series of communication primitives, to listening communication units via a network, wherein each listening communication unit is executing on a respective one of a plurality of listening computers, wherein each of the multicast communication primitives comprises at least a multicast destination ID, and each one of the listening communication units being a receiver of the series of communication primitives and wherein each of the multicast communication primitives includes a checksum; receiving, by a receiving one of the listening communication units, one of the multicast communication primitives; verifying, by the receiving one of the listening communication units, the checksum during a process of accepting the received one of the multicast communication primitives; with the originating communication unit, sending data relating to a changed multicast destination ID generated by the originating communication unit during the multicast communication session to each one of the plurality of listening communication units, wherein the sending data related to the changed multicast destination ID during the multicast session further comprises: determining, by the originating communication unit, that the multicast destination ID has been used a predetermined number of times in multicast communication primitives during the multicast communication session, wherein the data relating to the changed multicast destination ID comprises a pseudo random number employable to derive the changed multicast destination ID; with each one of the plurality of the listening communication units, calculating the changed multicast destination ID using the data relating to the changed multicast destination ID rendering a calculated changed multicast destination ID; and with the originating communication unit sending data in the series of communication primitives, the series of communication primitives being recognized by the listening communication units during the multicast communication session before and after sending the data relating to the changed multicast destination ID.
8. The method of claim 7, further comprising: sending a requesting communication primitive by a sending communication unit to the originating communication unit, the requesting communication primitive specifying that the sending communication unit requests to become a listening communication unit in a specified multicast communication session.
9. The method of claim 7, further comprising: sending an initiating communication primitive by the originating communication unit to a communication unit, the initiating communication primitive specifying that the communication unit is invited to join as a listening communication unit in a specified multicast communication session.
11. The method of claim 7, further comprising: applying, by each of the listening communication units, a predetermined computational rule on the pseudo random number of the data relating to the changed multicast destination ID to derive the changed multicast destination ID.
12. A computer system: an originating communication unit executing on an originating computer; and a plurality of listening communication units each executing on a respective one of a plurality of listening computers, wherein the originating communication unit sends at least a first and a second multicast communication primitive, as part of a series of communication primitives, to the listening communication units via a network during a multicast communication session, wherein each one of the listening communication units being a receiver of the series of communication primitives, wherein, during the multicast communication session and prior to the sending of the second multicast communication primitive, the originating communication unit changes the multicast destination ID during the multicast communication session to generate a changed multicast destination ID, the first multicast communication primitive comprising at least the multicast destination ID, the second multicast communication primitive comprising at least the changed multicast destination ID, wherein the changing of the multicast destination ID during the multicast session further comprises: applying, by the originating communication unit, a cryptographic hash function on a given portion of a given multicast communication primitive of the multicast session to derive the changed multicast ID, the given multicast communication primitive comprising data indicating an intended change in the multicast destination ID; and sending, by the originating communication unit, the given multicast communication primitive, as part of the series of communication primitives, to the listening communication units, the given multicast communication primitive comprising the multicast destination ID, wherein the originating communication unit sends data in the series of communication primitives, the series of communication primitives being recognized by the listening communication units during the multicast session before and after sending the second multicast communication primitive.
17. The computer system of claim 12, wherein each of the listening communication units applies the cryptographic hash function on the given portion of the given multicast communication primitive to derive the changed multicast destination ID.
Data transportation devices may be shared, e.g., they may be used at the same time by different communication devices. Shared transportation devices are typically connected to more than two communication devices and/or interconnection nodes. The communication devices or interconnection nodes perform amongst themselves an arbitration protocol to allocate communication capacity of the shared data transportation devices to each of the connected communication devices or interconnection nodes. Ethernet.TM. is a type of communication architecture that uses shared data transportation devices.
Data communication between communication devices typically involves the sending and subsequently receiving of data unites often referred to as "packets" or "messages" comprising a message header and some additional data. The message header typically comprises a part to identify a communication unit that is intended as receiver and further data indicating the manner to correctly interpret and process the message header and the additional data being transmitted. For example, in TCP/IP network communication, the IP number of the recipient is part of the message header. The additional data comprises "pure" data or instructions, or both.
Typically, a communication device, or equally, a collection of collaborating communication devices, takes part in a communication either in a role of initiator, commonly referred to as "client," or in a role of respondent, commonly referred to as "server." However, because a communication device may participate in multiple simultaneous communications, it may operate in any combination of these two roles.
Functionally, a communication message may be defined as a unit of data sent by a communication device acting as client, commonly referred to as "request," or sent by a communication device acting as server, commonly referred to as "response." A request-and-response type communication is typical for communications between computer programs using Remote Procedure Calls (RPC) or Remote Method Invocation (RMI), or for communication on the World Wide Web (e.g., HTTP), or many other TCP/IP protocols.
Another type of communication includes "message passing" between communication devices. In message passing, a response is required although such a response is typically restricted to only contain an acknowledgement of the reception of a communication message. Such a restricted response is sent by a receiver to a sender. Typically, in this type of communication, a subsequent response message may also be sent to the sender by the receiver.
In general, a computer program may be designed based on a plurality of software units, such as "objects," e.g., Java.TM. Enterprise Beans. Java.TM. Enterprise Beans are developed by Sun Microsystems, Inc. The software units may be designed to execute in separate controlling threads. Data communication may be performed between programs and, in particular, between specific controlling threads in these programs.
Some communication sessions between controlling threads require security. Communicating devices, or, communicating computer programs, may be implemented to protect communication between themselves and one or more other devices or computer programs. For a secured communication at least one of the following may be required: 1. Establishing an appropriateness of a communicating device, or program, to take part in the communication; 2. Controlling authenticity; 3. Maintaining confidentiality of the existence of the communication; and 4. Maintaining confidentially of data exchanged in the communication.
It is to be understood that the term "random" not necessarily refers to pure random. The random value may, for example, be dependent on one or more other numbers in the communication message that further includes either pure random data or pseudo randomly computed data. In one embodiment, the random number used in the communication primitive is unpredictable.
In the context of certain embodiments of the present invention, a "communication primitive" may reflect a "communication message." In this regard, a communication primitive comprises a header and a payload as described above in connection with a communication message.
Further, in the context of certain embodiments of the present invention, the terms "process" or "programmed process` may refer to any set of operations that are deployed for an intended functional purpose, such as a software program or hard-wired logic, configured to perform the functional purpose.
Moreover, in the context of certain embodiments of the present invention, "communication units" may reflect communication devices. A communication unit may reflect one or more physical entities capable of doing something. A communication unit may also reflect distinct programmed "processes," or threads of control, on a computer that share one or more processors and may communicate amongst themselves as well as communicate with other processors over a communication infrastructure using, for example, shared data transportation devices. Shared data transportation devices may be communication channels shared by two or more communication units. In embodiments where communication is performed between "processes" executed by a single processor, the shared data transportation devices may be implemented as shared memory.
In certain embodiments, communication units may not be directly interconnected. Instead, additional communication units may be used to function as interconnection nodes that interface the communication between indirectly connecting communicate units. The functionality provided by a communication unit that functions as an interconnection node is related to the capacity to receive a message from some sending communication unit and transmit it to some destination communication unit. In one embodiment, the sending and/or receiving communication units may be a communication unit functioning as an interconnection node. In accordance with the disclosed embodiments, a communication unit functioning as an interconnection node is referred to herein as an "interconnection node."
An interconnection node may be implemented in one or more separate hardware devices that contain in memory, one or more programs that perform communication mediating functions. In one embodiment, interconnection nodes may operate as a "hub", "bridge" or a "router."
FIG. 1 shows an embodiment of an exemplary computer arrangement. The communication unit shown in FIG. 1 may also reflect an embodiment in which the communication unit relates to a "process," such as a computer program, e.g. stored in memory. A "process" may be associated with the execution of a set of instructions present in or a part of, a computer program. The computer program may be executed by the computer arrangement shown in FIG. 1. The computer arrangement of FIG. 1 may comprise any number of communication units operating in a request-and-response type communication with another communication unit configured similar to or beneficial to the other communicate unit. FIG. 1 also shows an executing interconnection node 50 being in accordance with certain embodiments of the present invention.
The processor 1 may be arranged to communicate with a tamper resistant storage 29', e.g. a smart card, for storing cryptographic keys that may be used to generate communication protection keys. Moreover, the processor 1 may be connected to a secrecy device 29'' used as a user authentication device and that may perform cryptographic operations, possibly providing additional security in communications.
The processor 1 may be connected to one or more communication networks 27, 27', 27'', for instance, the Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), the Internet, etc. by means of 1/O units 25, 25', 25''. The processor 1 is arranged to communicate with other communication units through the networks 27, 27', 27'', as determined by a computer program stored in memory 5, 7, 9, 11.
The processor 1 may be implemented as stand alone system, or as a plurality of parallel operating processors each arranged to carry out subtasks of a larger computer program, or as one or more main processors with several sub-processors. Parts of the functionality of the invention may even be carried out by remote processors communicating with processor 1 through the networks 27, 27', 27''. Other such remote processors may be computer 2 communicating in a wireless way via network 27' controlled by communication unit 4, or computer 6 communicating with network 27'' controlled by two (or more) communication units 8, 10.
Although the I/O units 25, 25', 25'' are shown as physical boxes, communication between the computer arrangement and the networks 27, 27', 27'' may be performed in a wireless fashion. This observation also holds for any other data transportation line shown in any of the figures: they may be either implemented as a physical line (copper or optical wire) or as a wireless connection.
FIG. 2 shows an exemplary configuration of communication networks comprising several communication units. As shown, communication units may be configured to communicate with one another via the networks 27, 27', 27''. Further as shown, one or more of the communication units may be arranged to communicate directly with another one without using one of those networks 27, 27', 27''.
FIG. 7 shows a further embodiment of a hardware device 20(6). This hardware device 20(6) comprises a communication unit that operates as an interconnection node 45 that is controlled by a further communication unit that operates as an interconnection controlling device ICD 63, and is connected to a plurality of communication units 4(8), 4(9). Moreover, the interconnection node ICN 45 is connected to a communication unit 4(10) configured to support hardware configuration of one or more plug-in hardware devices 112(1), 112(2). This communication unit 4(10) is indicated in FIG. 7 with the label "HW CONFIG." The interconnection node ICN 45 is also connected to an internal bus 120. This bus 120 may be a PCI (peripheral component interconnect) bus, an IEEE USB (Universal Serial Bus), etc. As shown, the hardware device 20(6) is designed to allow insertion of one or more plug-in hardware devices 112(1), 112(2). After plug-in, these plug-in hardware devices 112(1), 112(2) connect to the internal bus 120 of the hardware device 20(6). Each of the plug-in hardware devices 112(1), 112(2) includes a communication unit designed to support the hardware device configuration after the plug-in hardware device has been connected to the bus 120. In operation, the hardware device configuration will start automatically by suitable communications with the communication unit designed to support the hardware configuration present within the hardware device, as known to persons skilled in the art. The interconnection node ICN 45 is also provided with a separate port 22 to support communication with other communication units and/or interconnection nodes external to the hardware device 20(6) itself.
FIGS. 8a, 8b and 8c show examples of the content of a communication primitive 31 in accordance with an example of the invention. As FIG. 8A shows, the communication primitive 31 comprises a header 33 and a payload 35. In an embodiment, the communication primitive header 33 contains at least three distinct data units: a destination ID 33(1), a return destination ID 33(2), and a "nonce" 33(3). The header 33 may also contain communication parameters 33(4). The communication parameters 33(4) may, among others, comprise data specifying a type of protection. They may also include data indicating a routing priority or data necessary to reserve resources in a network for a communication between two or more communication units. Embodiments of the present invention are not restricted in any way to any specific type of communication parameters 33(4) used.
FIGS. 9a and 9b show possible arrangements for the data parts 33, 35 in a communication primitive 31 in the order they may be transmitted in accordance with embodiments. Ordering arrangements for data parts of the communication primitive may facilitate the use of stream encryption in allowing it to be applied selectively for parts of the header 33 and payload 35, by placing unencrypted data at the very start or end of the transmitted data stream. Such data at the end or start may then be consulted while the communication primitive is in transit, without requiring decryption. A dotted line in FIG. 9b indicates symbolically which parts of communication primitive 31 may be encrypted. FIG. 9b shows that the boundary of encryption may not align with the boundary between data parts in the header (or trailer). As an example, a first nonce part 33(3)' and a second nonce part 33(3)'' are single contiguous data parts of header 33 yet split when applying encryption.
FIG. 9a shows an embodiment in which the communication primitive 31 comprises a header field 33(x), a payload comprising data 35 and a trailer field 33(y). Trailer field 33(y) may comprise some of the header data parts 33(4a . . . 4d, 4r . . . 4z) shown in FIG. 8b. Moreover, the data parts 33(4a . . . 4d, 4r . . . 4z) in the header may not be contiguous in either header field 33(x) or trailer field 33(y) and parts of the data parts 33(4a . . . 4d, 4r . . . 4z) may be present in the communication primitive in any suitable order. For the embodiment shown in FIG. 9b, data parts 33(4a . . . 4d, 4r . . . 4z), at least in part, are transmitted at the end. Different portions are indicated with 33(4)', 33(4)'', 33(4)''', Also the nonce may be split in parts 33(3)', 33(3)'' and 33(3)''', The same holds for the destination ID 33(1) and return destination ID 33(2). Splitting header data in several parts may facilitate the implementation on computing architectures with moderate width of their processing data path for instance 16 or 32 bits. Then, parts of the data parts of the header 33 may be read from a received communication primitive 31 in an order that they are required for processing before and after encryption or decryption.
As illustrated in the FIGS. 9a and 9b, in a further embodiment, the destination ID 33(1) is, at least in part, the first data transmitted in the communication primitive. In yet a further embodiment, the at least first part of the destination ID is followed in the transmission by at least a part of the communication parameters 33(4). In yet another further embodiment the return destination ID 33(2), at least in part, is transmitted immediately after transmission of the destination ID 33(1). In yet another further embodiment, the return destination ID 33(2), at least in part, is transmitted after transmission of a first part of the destination ID 33(1) and a first part of the communication parameters 33(4). In another embodiment at least a part of the communication parameters 33(4) is transmitted following the payload 35. In yet another embodiment, at least a part of the nonce 33(3) is transmitted following the payload 35. In yet a further embodiment, the initially transmitted parts of the destination ID 33(1), communication parameters 33(4)', return destination ID 33(2) and nonce 33(3)' are of equal size, e.g. 32 bit. The different parts are indicated with accent marks in FIG. 9b, where appropriate.
Assembling the return destination ID 33(2) in a communication primitive are explained in detail with reference to FIGS. 10A, 10B, 11A and 11B. In these figures, a communication unit 37 is engaged in a communication session with a communication unit 39. At a certain stage in the communication session, the communication unit 37 sends a request to communication unit 39. The communication unit 37 acts thus as "client", whereas the communication unit 39 acts as "server". Earlier communication primitives exchanged between the communication units 37, 39 are indicated with leading ellipses in FIGS. 10A and 10B and dashed lines in FIGS. 11A and 11B. The earlier communication primitives may include ones according to a predetermined initiation protocol to establish a first random destination ID. After the exchange of communication primitives described by FIGS. 10A, 10B, 11A and 11B further communication primitives may be exchanged as is indicated with the trailing ellipsis in FIGS. 10A and 10B and dashed lines in FIGS. 11A and 11B. FIG. 11B resembles FIG. 11A similarly as FIG. 10A resembles FIG. 10B. FIGS. 10A and 11A illustrate the use of a communication primitive 31 with a structure shown in FIG. 8A whereas FIGS. 10B and 11B relate to FIG. 8C.
FIGS. 10A and 10B show communication unit 37 sending a communication primitive CP(1) to communication unit 39. Communication unit 39 then is shown sending a response as a second communication primitive CP(2). Upon receiving communication primitive CP(2); communication unit 37 then proceeds with sending a third communication primitive CP(3). The dashed lines in FIGS. 10A, 10B show that the communication unit 37, 39 determines the data in the header of the communication primitive. FIG. 10A shows the sending communication unit determining a new value for the return destination ID 33(2) RD(i) (i=1, 2, 3, . . . ) and determining the destination ID(1) D(i+1) as the value of the return destination ID RD(i) in the previously received communication primitive CP(i). FIG. 10B shows the sending communication unit determining the value for data in the header of communication primitive CP(i+I), like checksum 33(5) CS(i+I) or nonce 33(3) hdr(i+I) and determining the destination 1D D(i+I) as the value of the return destination 1D RD(i) assembled from data, e.g. CS(i) and hdr(i), in the header of the previously received communication primitive CP(i-1) by a return destination assembly process AP(i). By means of dashed arrows, FIG. 10B also shows how the return destination assembly process AP(i) may involve use of data available to the communication unit 37, 39. In FIGS. 10A, 10B reference sign PL(i) refers to payload 35 of communication primitive CP(i).
Then, in stage F11A(7), the server 39 assembles a communication primitive 31 CP(2). The communication primitive 31 CP(2) comprises a payload 35 PL(2), a destination ID 33(1) D(2) identifying the communication unit 37 as receiver. This destination ID 33(1) D(2) is set to be equal to the value of return destination ID RD(1) stored in stage F11A(5) (D(2)=RD(1)). Moreover, the second communication primitive CP(2) will comprise a return destination ID 33(2) RD(2), identifying the communication unit 39 as return address, specifically determined by communication unit 39 for communication primitive CP(2), e.g. in accordance with a predetermined rule. Here, the value of the return destination ID RD(2) in general differs from the value of the destination ID D(1) in communication primitive CP(1) (RD2.noteq.D(1)). In stage F11A(8), the value of the return destination ID RD(2) is stored by the communication unit 39 to allow later messages received to be recognized by the communication unit 39 to have the communication unit 39 as intended receiver. In stage F11A(9), the communication primitive 31 CP(2) thus assembled is sent back to the communication unit 37.
Then, in stage FLAB(7), the server 39 assembles a communication primitive 31 CP(2). The communication primitive 31 CP(2) comprises a payload 35 PL(2), a destination ID 33(1) D(2) identifying the communication unit 37 as receiver. This destination ID 33(1) D(2) is set to be equal to the value of the return destination H) RD(1) assembled and stored in stage FLAB-6 (D(2)=RD(1)). Moreover, the second communication primitive will comprise data in the header 33 to assemble a return destination ID 33(2) RD(2), identifying the communication unit 39 as return address, specifically determined by communication unit 39 for communication primitive CP(2), e.g. in accordance with a predetermined rule. Here, the data in the header to assemble the return destination ID RD(2) in general differs from the data in the header of communication primitive 31 CP(1) (RD2.noteq.D(1)). In stage FLAB(8), the value of the return destination ID RD(2) is assembled form the determined header data and stored by communication unit 39 to allow it to be used in recognizing later messages received as to having communication unit 39 as intended receiver. In stage F1 1B(9), the communication primitive 31 CP(2) thus assembled is sent back to the communication unit 37.
FIG. 12 shows an exemplary communication unit 37 in accordance with embodiments of the present invention. In one embodiment, communication unit 37 may include a central processing unit 32 that may be used to execute general programs and programs engaged in communication. Communication unit 37 may also include a communication port 22 for exchanging communication primitives with other communication units possibly via communication network 27. The communication unit 37 further comprises memory 30. FIG. 12 relates to FIG. 1 and shows in more detail data structures that may be present in the memory means 5, 7, 9 and 11 in FIG. 1. Communication port 22 functionally comprises I/O device 25 (or 25', 25'') as will be explained below in the section "communication port."
It is to be understood that the term "unique" as used with reference to a return destination ID, does not mean that the value occurs only once and is never repeated. "Unique" is intended to refer to return destination ID values used only once within a limited time frame in a limited area of the communication network. To that purpose, the determination of the value of the nonce 33(3), or any other random data included in assembling the return destination ID with the purpose of creating uniqueness of the result, may not require very good randomness, or be a value expressed in many bits.
Turning to FIG. 14, a communication unit 4(11) is shown as the originator in a communication session in a multicast fashion. Also shown are three of the plurality of other listening communication units 4(12, 13, 14, . . . ), that are the intended recipients of multicast transmissions from the originating communication unit 4(11). As example, communication unit 4(12) is shown as joining the multicast communication session as a listener on its own initiative, that is to say in the role referred to above as "client". As a further example, communication unit 4(13) is shown as joining the multicast communication session as listener on the initiative of the originating communication unit 4(11), that is to say in the role referred to above as "server". As will be explained below, both client and server roles are possible for any of the listening communication units partaking in the same multicast communication session. Notably, after the exchange of initiating communication primitives there is no longer a distinction between joining as listener as a client or joining as listener as server.
In one embodiment, a "peer group" consisting of communication units performing similar or closely related functions is realized where each member is an originating communication unit in a multicast communication session in which the other communication units are listeners.
In stage F16-7, a session starting communication primitive 31(3) is sent by communication unit 4(12), that includes data in the header of the communication primitive 31(3) to assemble a return destination ID RD(3), e.g., assembled from information received in the earlier communication primitive 31(2), e.g. the nonce N(2). In FIG. 15, this is exemplary indicated as "RD(3)=N(2)=multicast destination ID". After having sent this communication primitive 31(3), the data included in the header, e.g. RD(3), is used by communication unit 4(12) to assemble the multicast destination ID RD(3), which is then stored in its memory. Communication unit 4(12) is now capable to recognize future communication primitives with the multicast destination ID RD(3) as destination ID as addressed to itself. In effect, communication unit 4(12) has become a listening communication unit in the multicast communication session. The stored multicast destination ID RD(3) is marked to the effect that multiple received communication primitives may be recognized as all validly addressed and will be received for possible processing.
In stage F16-12, which may actually be before sending the first multicast communication primitive 31(4) in stage F16-10 as shown in FIG. 15, the originating communication unit 4(11) makes a determination to invite a further communication unit to join a multicast communication session for which it is the originator. For example, the determination is made to invite communication unit 4(13). Then, in stage F16-13 an initiating communication primitive 31(5) is sent by communication unit 4(11) to communication unit 4(13). The destination ID D(5) used in communication primitive 31(5) may have a pre-arranged value or it may be dynamically assembled based on data in an earlier communication primitive received from communication unit 4(13) as is explained above. Such an earlier communication primitive from communication unit 4(13) to communication unit 4(11) has not been shown in FIG. 14. The initiating communication primitive 31(5) comprises information to assemble the multicast destination ID=nonce N(2), as was explained in some detail with respect to stage F16-10 above. In FIG. 15, this is exemplary indicated as "N(5)=N(2)=Multicast destination ID."
It is noted--that depending on the actual assembling process that will be used by communication unit 4(13), the data comprised in initiating communication primitive 31(5) may differ from similar data sent in other initiating communication primitives (like 31(2)) to other prospective listing communication units 4(12, 14, . . . ) as long as applying the possibly various assembly processes results in the same value to be used as multicast destination ID. In stage F16-14, the initiating communication primitive 31(5) is received by communication unit 4(13).
If, in stage F16-15 it is determined to join the multicast session, then, in stage F16-17, a session starting communication primitive 31(6) is sent by communication unit 4(13) to communication unit 4(11) which comprises data in the header that indicate that the multicast destination ID N(2) must be used in any communication primitive intended as reply to communication unit 4(13). In FIG. 15, this is exemplary indicated as "RD(6)=N(5)=Multicast destination ID." As a result of sending session starting communication primitive 31(6), communication unit 4(13) is a listening communication unit in the multicast communication session originated by communication unit 4(11). This stage is similar to stage F16-7 above where a session starting communication primitive 31(3) was sent by communication unit 4(12) to communication unit 4(11).
In stage F16-20, each listening communication unit 4(12, 13, 14, . . . ) makes a determination to send a communication primitive 31(7) intended as input to the multicast communication session originating in communication unit 4(11). In stage F16-21, if the determination is positive as indicated for communication unit 4(13) in FIG. 15, the communication primitive 31(7) is sent to originating communication unit 4(11). The destination ID D(7) in communication primitive 31(7) is assembled from data comprised by a communication primitive previously received from communication unit 4(11), e.g. communication primitive 31(4). In FIG. 15, this is exemplary indicated with "D(7)=RD(4)". Using data comprised in a previously received multicast communication primitive, e.g. RD(4) in communication primitive 31(4), will facilitate the receiving communication unit 4(11) to recognize the payload data as input to the multicast communication session. Functionally, stage F16-21 is very similar to stages F16-7 and F16-17, where also input to the multicast session is provided in a communication primitive 31(3), 31(6) to originating communication unit 4(11). In these earlier stages, the session starting communication primitives 31(3), 31(6) are the very first one in joining the multicast communication session and the specific data comprised in their headers, e.g. RD(3), RD(6), that can be used to assemble the destination ID in a reply by communication unit 4(11), effectively establish the communication units 4(12), 4(13) as listeners. In the current stage, communication units 4(12, 13, 14, . . . ) have been established as listeners and the data in the header that can be used to assemble the destination ID in a reply may be different. In FIG. 15, the optional values for these data are exemplary indicated with "RD(7)=multicast destination ID or random return destination ID". If RD(7)=multicast destination ID, then, this indicates that communication unit 13 wishes to continue to be a listening communication unit in the multicast communication session. If, however, RD(7)=random return destination ID, then, this indicates that communication unit 13 does not wish to continue in the multicast communication session but wishes to start a private communication session with originating communication unit 4(11). In this private communication session, use can be made of (randomly) dynamically changing destination It's and/or return destination It's, as explained above.
The multicast destination ID will in general be used by originating communication unit 4(11) for at least one of a series of multicast communication primitives. Then, at some point in time, originating communication unit 4(11) may determine that a change of the multicast destination II) is in order. Alternatively, originating communication unit 4(11) may determine to invite the listening communication units 4(12, 13, 14, . . . ) as participants to a second multicast communication session for which it is the originating communication unit. To effect such determinations, the originating communication unit 4(11) then includes in a multicast communication primitive 31(8) data that can be assembled into the new multicast destination ID. In FIG. 15, this is exemplary indicated as "N(8)=random or multicast destination ID 2" where N(8) is the nonce of communication primitive 31(8). Typically, the payload PL(8) of the multicast communication primitive 31(8) will contain information regarding the intended change of multicast destination ID or the other multicast communication session. Listening communication units 4(12, 13, 14, . . . ) upon receiving the multicast communication primitive 31(8) with this information make a determination to accept the invitation and the information comprised in the received multicast primitive, e.g. in the nonce N(8), will be used to send a second session starting communication primitive as is explained above with respect to stages F16-7 and F16-17. Such a second session starting communication primitive is referred to with numeral 31(10) in FIG. 15.
It is noted that FIG. 20 is a schematic representation of embodiments of the invention without limiting other embodiments. In particular the communication accepting gate 54 may be implemented as functions of the port logic controller 46 based on the state of the two control inputs to the port logic controller 46, and that processing an incoming communication primitive may be aborted as soon as it is determined that he destination ID is not present in the destination table 50. The comparator 78 may also be functionally integrated in the authentication hash calculator 100. The figure shows four distinct return destination 1D assemblers 60(1,2,3,4) which may be realized as one functional unit shared between the various tasks, or as two functional units, e.g. one for input and one for output processing. The communication primitive assemblers 52(1, 2) may in some cases be realized by wiring and not be explicitly present. The input buffer 36 and output driver 38 in the figure symbolize the functionality to access a communication medium, e.g. Ethernet.TM., and may be realized in any form appropriate for a particular communication medium.
Input buffer 36 may be configured to partially buffer an incoming communication primitive for the duration of stage F21-2 and possibly F21-4 in order to process the communication primitive once the mode of processing is fully configured. In particular, the input buffer 36 may be absent. Hence, in one embodiment, a communication port processes an incoming communication primitive in a pipe-line fashion, interpreting an initial part of it, including at least one of (i) destination 113 33(1), (ii) a first part of communication parameters and (iii) a first part of a nonce 33(3)', as processing instructions, e.g to decrypt or not to decrypt and process configuration parameters e.g which key to use.
As shown in FIG. 20 and explained with respect to FIGS. 21 and 22, the return destination ID may be determined from an, at least partially, encrypted version of the communication primitive. With reference to FIG. 9B, the encrypted part of the communication primitive, comprising the parts 33(3)'', 33(5), 33(4)'', 35 and 33(3)''', after applying the encryption is represented by nature of the cryptographic process as a string of pseudo-random bits. Yet, for the purpose of assembling the return destination ILK 33(2) pertaining to communication primitive 31 a structure may be imposed on the string of pseudo random bits with a first part being interpreted as second nonce part 33(3)'' and a second part as the checksum 33(5). The return destination ID assembler 60(1) and 60(2) in FIG. 20 are applied on the encrypted version of the communication primitive. Data selectors 70 and 48(3), respectively, in selecting data to use in assembling the return destination ID, perform the interpretation of the encrypted part as header data.
It is noted that the return destination ID resulting from interpreting the encrypted part of the communication primitive as data in the header will always be a pseudo random number. It will also be a unique random number if some unique data is used as input to its assembly, e.g. first nonce part 33(3)'. Hence, in an embodiment the communication primitive 31 comprise a header that comprises at least three data parts, a destination ID, communication parameters and a nonce, and an encrypted payload. In a further embodiment, assembling the return destination ID involves selecting data from the encrypted part of the communication primitive as input. In an other embodiment, a trailer of the communication primitive comprises a nonce 33(3)''' which is included in the encryption and has a size depending on the size of the payload 35 and on the padding that may be required for a particular encryption algorithm used as stream encryptor 44.
It is also noted that the rule for assembling the return destination ID, if indicated by the communication parameters, must be indicated in the unencrypted first communication parameters part 33(4)'. It also noted that the format, size and structure, of at least a first part of the unencrypted part of the header 33 must be agreed between the communication units. It is further noted that interpretation of a first part of the encrypted part of the communication primitive 31 as data in the header 33 to assemble a return destination ID is possible even if in the unencrypted communication primitive this header data is only present in a trailer or not present at all. Also, with part of the communication primitive encrypted it is possible to use larger data sizes for the header data used in assembling the return destination ID then would fit in the header of the unencrypted communication primitive. Hence, in one embodiment, the communication parameters in the unencrypted part of the header indicate at least one of (i) the use of encryption to a part of the communication primitive, (ii) the size of the complete unencrypted header, (iii) the key used for encryption, (iv) the rule to assemble a return destination ID, and (v) the size and offset of data units extracted from the encrypted part of the communication primitive and to be interpreted as header data.
Previous Patent US 10,142,118 | Next Patent US 10,142,120