Methods for communication in a multi-cluster network, device for connection to a network of clusters and bridge for connecting clusters

• US 20050165965A1
• Filed: 04/09/2003
• Published: 07/28/2005
• Est. Priority Date: 04/09/2002
• Status: Abandoned Application

• Current Assignee: Thomson Licensing SA (Vantiva SA)
• Original Assignee: Thomson Licensing SA (Vantiva SA)
• Inventors: Sirot, Joel, Bichot, Guillaume, Henry, Jean-Baptiste
• Application Number:
  US10/510,536
• Publication Number:
  US 20050165965A1
• Time in Patent Office: Days
• US Class Current: 709/249
• CPC Class Codes: H04L 12/2805 Home Audio Video Interoperability [HAVI] networks
• CPC Class Codes: H04L 12/2809 indicating that an appliance service is present in a home automation network monitoring functionality H04L43/0817; discovery or management thereof, e.g. service location protocol [SLP] or web services, H04L67/51
• CPC Class Codes: H04L 12/283 Processing of data at an internetworking point of a home automation network
• CPC Class Codes: H04L 12/40091 Bus bridging LAN interconnection over a bridge based backbone H04L12/462; single bridge functionality H04L12/462
• CPC Class Codes: H04L 12/40117 Interconnection of audio or video/imaging devices home automation networks H04L12/2803; bitstream network arrangements specially adapted for distribution of digital video signals H04N7/24
• CPC Class Codes: H04L 12/4625 Single bridge functionality, e.g. connection of two networks over a single bridge
• CPC Class Codes: H04L 67/14 Session management for real-time applications in data packet communications networks H04L65/1066
• CPC Class Codes: H04L 69/329 in the application layer [OSI layer 7]
• CPC Class Codes: H04L 9/40 Network security protocols

Abstract

Bridge device comprising at least two interfaces for interfacing respective clusters of network devices in a network wherein said bridge device comprises at least two interface portals for connecting clusters. The bridge device comprises for each portal a first software component (SDDM) for receiving from an internal client requests for device describing configuration memory data (SDD) of at least one network device, said first software component being adapted to retrieve device describing data from other devices through a function call of a similar software component in the other devices. The invention also concerns a device in a multi-clustered network, the device comprising a software component as above, as well as a device discovery method and a method for establishing a connection between devices.

Claims

1. Bridge device comprising at least two interfaces for interfacing respective clusters of network devices in a network wherein said bridge device comprises at least two interface portals for connecting clusters,

wherein the bridge device comprises for each portal a first software component for receiving from an internal client requests for device describing configuration memory data of at least one network device, said first software component being adapted to retrieve device describing data from other devices through a function call of a similar software component in the other devices.

2. Bridge device according to claim 1, wherein the first software component is adapted to retrieve data for a remote cluster device without similar software component through a function call to a similar software component of a bridge device on the path to the remote cluster device.

3. Bridge device according to claim 1, wherein the first software component is adapted to retrieve data for a device without similar software component on the same cluster as itself by issuing a medium dependent request message to the device.

4. Bridge device according to claim 1, wherein the first software component is adapted to maintain at least one of:

a. a list of identifiers of first software components of other devices on the network;

b. a list of devices devoid of similar first software components, associated with respective identifiers of the nearest portals on the paths to the devices in the list.

5. Bridge device according to claim 1, wherein the first software component is adapted to monitor changes in the device describing data of devices devoid of a first software component on its portals local cluster and to generate corresponding device describing data change events on the clusters connected to other portals of the bridge device.

6. Bridge device according to claim 1, further comprising for each portal a second software component for interfacing the portal'"'"'s other software components of the respective portal with the portal cluster'"'"'s communication medium, said second software component comprising an application programmable interface of which at least certain methods are globally accessible to software components of other devices of the network, for remotely accessing the communication medium.

7. Bridge device according to claim 6, wherein the globally accessible methods comprise at least one among write, read, lock, enroll, drop, indication.

8. Bridge device according to claim 1, further comprising for each portal a third software component for maintaining a list of all devices on all clusters of the network.

9. Bridge device according to claim 8, wherein the third software component is adapted to generate, upon detection of a change on any cluster of the network, a first event informing software components of its portal of the nature of the change.

10. Bridge device according to claim 8, wherein the third software component is adapted to generate a second event for informing the third software components of other portals only of the state of the event issuing portal'"'"'s a remote device list.

11. Bridge device according to claim 10, wherein the second event comprises a potentially incomplete list of remote devices compared to the event-issuing portal, i.e. devices reachable through the co-portals of the event issuing portal.

12. Bridge device according to claim 8, wherein the third software component is adapted to generate a third event for informing the third software components of all devices on the cluster that the hosting portal'"'"'s remote device list is stable.

13. Bridge device according to claim 12, wherein the third event comprises a complete list of remote devices compared to the event-issuing portal, i.e. devices reachable through the co-portals of the event-issuing portal.

14. Bridge device according to claim 1, wherein each portal comprises a fourth software component for forwarding to co-portals event messages detected on a portal'"'"'s local cluster.

15. Bridge device according to claim 1, wherein each portal comprises a fifth software component for receiving, on one of the bridge'"'"'s clusters, a request from a fifth software component of another device, and means for forwarding said request to fifth software elements on its other clusters, with the initial requester'"'"'s identifier as source address, and for forwarding the non-concatenated responses to this request back to initial requesting device.

16. Bridge device according to claim 1, wherein each portal comprises a fifth software component for receiving, on one of the bridge'"'"'s clusters, a request from a fifth software component of another device, and means for forwarding said request to fifth software elements on its other clusters, wherein the forwarded request contains as a parameter the address of the forwarding portal, for receiving and concatenating responses to the forwarded request and for forwarding the concatenated responses to this request back to the initial requesting device.

17. Bridge device according to claim 16, wherein said means for forwarding said request are adapted to use a first message type for forwarding the request to fifth software elements of bridge devices and a second message type for forwarding the request to fifth software elements of non bridge devices, wherein the identifier of the forwarding portal is a parameter in the first message and not in the second message¹.

18. Bridge device according to claim 1, wherein each portal comprises a fifth software component for receiving, on one of the bridge'"'"'s clusters, a request from a fifth software component of another device, and means for forwarding said request with the initial requester'"'"'s identifier as source address to fifth software elements on its other clusters, for intercepting responses to this forwarded request, for concatenating the contents of these responses and for sending a single concatenated response to the initial request back to the initial requesting device.

19. Bridge device according to claim 1, further comprising means for converting the transport type of packets between the communication mediums of its clusters.

20. Bridge device according to claim 1, wherein each portal comprises a sixth software element for establishing connection segments on local clusters for a connection crossing the bridge upon reception of a connection establishment request from a sixth software element of another device.

21. Bridge device according to claim 20, wherein the sixth software element of a portal is adapted to establish a connection on its local cluster and of its local cluster to carry out the next segment establishment on the path to a connection end device.

22. Device for connection to a cluster in a multi-cluster network, wherein clusters are connected through bridge devices, each bridge device comprising at least two cluster interfaces, wherein each interface is considered as a network device on its respective cluster wherein the network device comprises a first software component for receiving from an internal client requests for device describing configuration memory data of at least a second device, said first software component being adapted to retrieve device describing data from the at least one other device through a function call of a similar software component in the at least one device.

23. Device according to claim 22, wherein the first software component is adapted to retrieve data for a remote cluster device without similar software component through a function call to a similar software component of a bridge device on the path to the remote cluster device.

24. Device according to claim 22, wherein the first software component is adapted to retrieve data for a second device without similar software component on the same cluster as itself by issuing a medium dependent request message to the second device.

25. Device according to claim 22, wherein the first software component is adapted to maintain at least one of:

a list of identifiers of first software components of other devices on the network;

a list of devices devoid of similar first software components, associated with respective identifiers of the nearest portals on the paths to the devices in the list.

26. Device according to claim 22, further comprising a third software component for maintaining a list of all devices on all clusters of the network, wherein said third software component comprises means for retrieving remote device lists from portals connected to its local cluster, and for concatenating the remote device lists with a local cluster device list.

27. Device according to claim 26, wherein the third software component is further adapted to maintain in the network device list an indication of the closest portal on the path for a remote device compared to the device'"'"'s own local cluster.

28. Device according to claim 25, wherein the third software component is adapted to generate, upon detection of a change on any cluster of the network, a first event informing components of its local device of the nature of the change.

29. Device according to claim 22, comprising a fifth software component for receiving from a local client, a request for a list of remote software elements and for forwarding said request to fifth software elements of devices of the local cluster only.

30. Device according to claim 22 comprising a sixth software element including an application programmable interface for clients of the same device, adapted to receive a request for establishing a connection between a sink device and a source device, said sixth software element being adapted to determine, on the path between the source and the sink device, the portal closest to the source device on the path to the sink device, and for sending an appropriate request to that portal for establishing the connection on its local clusters and for propagating this request to other appropriate portals on the path.

31. Method for discovering devices in a network comprising at least two device clusters and at least one bridge, wherein at least two clusters are connected by a bridge, each bridge comprising at least two interface portals for connection to respective clusters, said process comprising the steps of:

having each portal obtain a list of identifiers (GUID) of its local cluster'"'"'s devices;

having each portal request remote device lists from each portal of the same cluster as itself;

having each portal build its own remote device list by requesting from its co-portals the list of their local devices and of remote devices reachable through the co-portals.

32. Method according to claim 31, further comprising the step of making a bridge passing to messages destined to a given device if it is on the shortest path to that device.

33. Method according to claim 32, wherein the shortest path is the path with the lowest number of portals to be crossed.

34. Method for establishing a connection between a source device and a sink device in a network comprising a plurality of device clusters connected by bridge devices, wherein each bridge device comprises interface portals for connection to clusters, said method comprising the steps of:

(a) providing stream manager software elements in portals of bridges and in other bridge aware devices of the network;

(b) receiving, at the level of a stream manager software element of a device, request from a connection from local client;

(c) identifying, on the path between the sink device and the source device, the portal closest to the source device, and sending a connection request to that portal;

(d) having the portal receiving the connection request establish a segment of the connection between the source device and the portal'"'"'s bridge;

(e) having the portal receiving the connection request have the next portal of its bridge on the path to the source device establish the next segment of the connection on the next portal'"'"'s local cluster;

(f) identify the next bridge, if any, on the path to the sink instruct the remote portal of the next bridge on the path to the sink device to establish the appropriate segment of the connection;

(g) go to step (e) until the segment of the connection to the sink device has been established.