|Publication number||US7120146 B2|
|Application number||US 09/972,947|
|Publication date||Oct 10, 2006|
|Filing date||Oct 10, 2001|
|Priority date||Oct 10, 2000|
|Also published as||EP1198095A2, EP1198095A3, US20020041594|
|Publication number||09972947, 972947, US 7120146 B2, US 7120146B2, US-B2-7120146, US7120146 B2, US7120146B2|
|Inventors||Johji Suzuki, Morihisa Momona|
|Original Assignee||Nec Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (10), Referenced by (3), Classifications (16), Legal Events (3)|
|External Links: USPTO, USPTO Assignment, Espacenet|
1. Field of the Invention
The present invention relates generally to serial bus networks, and more specifically to a standardized serial bus network such as IEEE Std 1394-1995 or IEEE Std 1394a-2000 (hereinafter IEEE 1394 standard) in which bus bridges are used to interconnect serial buses and TCP/IP protocol is used for inter-bridge communications.
2. Description of the Related Art
Recent attentions have increasingly been focused on the high speed transport capability of the IEEE 1394 serial bus network to promote multimedia communications. One such effort has culminated in the IP over IEEE 1394 protocol (RFC 2734) developed by the IETF (Internet Engineering Task Force) to support the Internet Protocol. The IP over IEEE 1394 protocol defines a method in which IP packets are transmitted in unicast, multicast and broadcast modes. According to the IP over IEEE 1394 protocol, “asynchronous packets” are used for transmitting unicast messages and “asynchronous stream channels” are used for transmitting multicast and broadcast messages. Multicast channel allocation protocol is also defined for allocating an asynchronous stream channel to a number of nodes attached to a common bus.
The Serial Bus architecture supports multiple bus networks via bus bridges. A bus bridge normally eavesdrops on the bus, ignoring all transactions between local addresses but listening for remote transactions. When the bus bridge receives a packet for a remote address, it forwards the packet to an adjacent bus. After initialization, the bus bridges are transparent to the system. Bus bridges are also used to segment a large system into a number of small bus systems.
However, the multicast channel allocation protocol limits the reachable extent of multicast transmissions to only one bus system. While unicast and broadcast messages can be transmitted between multiple bus system via bus bridges, the bus bridges allow no inter-bridge multicast transmissions.
Therefore, there exists a need to provide bus bridges capable of retransmitting multicast packets from a multicast group of one bus system to a multicast group of another bus system. If a multiple bus network has three or more bus systems, intermediate bus systems must be capable of acquiring an asynchronous stream channel for retransmitting multicast messages from source to destination bus systems. In addition, such intermediate bus systems must also be capable of acquiring an asynchronous stream channel for multicast transmission even if their nodes are all receive-only nodes which are currently not designed to acquire an asynchronous stream channel.
It is therefore an object of the present invention to provide a packet communication method and network for transmitting multicast packets across bus systems.
According to a first aspect of the present invention, there is provided a packet communication method for a network having a plurality of bus systems interconnected by at least one bus bridge, each of the bus systems including at least one node, wherein the bus systems, the bridge and the node are in compliance to a serial bus standard. The method is characterized in that the bus bridge establishes a connection between a first channel used in a first bus system for transmission of packets to a first multicast address and a second channel used in a second bus system for transmission of packets to a second multicast address if the first and second multicast addresses are equal to each other.
According to a second aspect, the present invention provides a packet communication method for a network having a plurality of bus systems interconnected by at least one bus bridge, each of the bus systems including at least one node, wherein the bus systems, the bridge and the node are in compliance to a serial bus standard. The method is characterized in that at least one node on each of the bus systems, when initiating a multicast packet transmission to a multicast group of the bus system, acquires a channel to be used for the multicast packet transmission and broadcasts a message pertaining to the channel, and the bus bridge establishes a connection between channels acquired for different bus systems when the message is received from each of the different bus systems.
According to a third aspect, the present invention provides a packet communication method for a network having an intermediate bus system connected between first and second bus systems by first and second bus bridges, each of the bus systems including at least one node, wherein the bus systems, the bridge and the node are in compliance to a serial bus standard. The method is characterized in that at least one node on each of the bus systems acquires a channel to be used for multicast packet transmission and broadcasts a message pertaining to the channel and a multicast group when initiating a multicast packet transmission to the multicast group. The first bus bridge acquires an interconnection channel if there is no node in the intermediate bus system participating in the multicast group and if two of the message having an identical multicast: address are received, one from the first bus system and the other from the second bus system, broadcasts a message pertaining to the interconnection channel and the multicast group and connects a first end of the interconnection channel to the channel acquired for the first bus system. The second bus bridge connects a second end of the interconnection channel to the channel acquired for the second bus system when the message is received from the first bus bridge.
According to a fourth aspect of the present invention, there is provided a bus bridge for interconnecting a plurality of bus systems of a packet communication network. Each of the bus systems includes at least one node, wherein the bus systems, the bridge and the node are in compliance to a serial bus standard. The bus bridge establishes a connection between a first channel used in a first bus system of the plurality of bus systems for transmission of packets to a first multicast address and a second channel used in a second bus system of the bus systems for transmission of packets to a second multicast address if the first and second multicast addresses are equal to each other and the first and second channels have different channel identifiers from each other.
The present invention will be described in detail further with reference to the following drawings, in which:
Referring now to
As shown in
Each node of the multiple bus network operates in compliance with TCP/IP and IP over IEEE 1394 protocol (RFC 2734) to transfer IP packets within its own bus system. Each bus bridge has the ability to retransmit unicast packets and broadcast packets between neighboring bus systems.
Each node of the network is assigned an IP address “A1” which is used as a member address of a multicast group in which the node desires to participate. User datagram protocol (UDP) will be used to transmit multicast packets. A multicast group is therefore identified by the IP address A1 and the user datagram protocol.
Control messages used by the nodes and bus bridges include a number of control data fields as shown in
A channel number set in the channel number field 203 ranges from “0” to “63” except for the number “31”. The destination address field 204 contains an IP address selected from the range between “224. 0. 0.1” to “239. 255. 255. 255”.
The following is a description of the transaction sequence of the multiple bus system between bus systems 109 and 110 with the aid of a sequence diagram shown in
As shown in
If no reply is returned from the network, the node 101 sends a channel request packet to the IRM node 102 to acquire a channel “C1” for multicast transmission (procedure 302).
As shown in
Bus bridges 107 and 108 each receive the mapping data packet through their port A and map the contents of the mapping data packet to the port A in their mapping tables shown in
Node 101 then starts multicasting asynchronous stream packets over the assigned channel C1 (procedure 305). Although these multicast packets are received and retransmission by the node 102 to the bus bridge 107, they are not repeated by the bus bridge 107, as illustrated in
When the node 103 wishes to send packets to a multicast group during the time the node 101 continues its multicast transmissions, the node 103 broadcasts a channel acquisition enquiry packet to determine if a channel has been acquired for the multicast group (procedure 306). If the multicast group of node 103 has the same multicast address A1, the channel acquisition enquiry packet contains the same information as those of the channel acquisition enquiry packet used by the node 101 except that its node number field 201 contains the identifiers of bus 110 and node 103, as shown in
As shown in
Bus bridge 107 receives the mapping data packet from the node 103 through its port B and updates its own mapping table (
Referring to the flowchart of
Since the “report from receive node” message indicates that there is no sender at all, no packets exist for multicast transmission. Therefore, if such a message is contained in at least one of these mapping tables, the bus bridge returns from step 404 to the starting point of the routine.
Following the transmission of the mapping data packet (procedure 408), the node 103 proceeds to start transmitting asynchronous stream packets (procedure 311). These multicast packets are retransmitted by bridge 107 to the nodes on the bus system 109 by performing the channel number conversion process described above. Likewise, the multicast packets which are subsequently transmitted from the node 101 are repeated through the bridge 107 to the bus system 110 (procedure 312).
Upon receipt of the transfer enquiry packet at procedure 502, the bus bridge 107 performs a routine as shown in
In the sequence diagram of
On the other hand, the node 101 started its own timer (procedure 502). This timer is set to expire when timeout period “Td” greater than “Ta” has elapsed. Therefore, this timer expires after the bus bridge 107 cleared the inter-bus connection. In response to the running out of its own timer, the node 101 sends a channel transfer request packet to the IRM node 102 to restore the ownership of the acquired channel (procedure 504). The reason for the earlier occurrence of the channel clear-down by bridge 107 than the restoration of channel ownership by node 101 is to ensure against possible delivery of packets from the bus system 110 to wrong destinations on the bus 109.
In a second embodiment of the present invention, the bus bridges 107 and 108 operate to establish inter-channel connections between the terminal bus systems 109 and 111 via the intermediate bus system 110.
The description of the operation of the second embodiment proceeds with the aid of a sequence diagram of
Since the node 101 is the first to initiate channel acquisition, procedures 301 through 305 of
Thus, the bus bridges 107 and 108 store the contents of mapping data packet broadcast from node 101 in the port-A entry of a mapping table as shown in
Node 105 then broadcasts a channel acquisition enquiry packet for multicast transmission (procedure 701), acquires a channel C3 from the IRM node 106 (procedure 702), and broadcasts a mapping data packet (procedure 703). As a result, the bus bridges 107 and 108 store the contents of mapping data packet broadcast from the node 105 in the port-B entry of the mapping table of
Bus bridges 107 and 108 then attempt to establish a connection between the bus systems 109 and 111 by initially sending channel acquisition enquiry packets in sequence (procedure 705, 706), mutually examining the contents of their packets to determine the bridge to acquire a channel from the IRM node (procedure 707), and broadcasting a mapping data packet from that bridge (procedure 708) and finally establishing inter-channel connections (procedure 709).
If this is the case, each bus bridge proceeds to step 804 to broadcast a channel acquisition enquiry packet and receives a channel acquisition enquiry packet sent from another bridge (step 805). The details of the channel acquisition enquiry packets sent from bridges 107 and 108 are shown in
At step 806, each bus bridge compares the contents of its own broadcast channel acquisition enquiry packet with those of the received C.A.E. packet and determines whether they have the same bus identifier and multicast address. If the decision at step 806 is affirmative, flow proceeds to step 807 to check to see if the local node (bridge) identifier is greater than the node identifier of the remote bridge. If so, the local bridge acquires a channel (C2) from the IRM node (step 808) and broadcasts a mapping data packet (step 809).
Therefore, if the node identifier of bridge 107 is greater than that of bridge 108, the bridge 107 is given higher priority to acquire a channel from the IRM node 104, as indicated by procedure 707 in
The bridge to which higher priority is assigned establishes an inter-channel connection (step 810) by converting the channel identifier given in the mapping table of
Conversely, if the node identifier of the local bridge is not greater than that of the remote bridge, the local bridge is given lower priority and proceeds from step 807 to step 811 to check to see if a mapping data packet is received from the remote bridge within a specified time interval. If the decision at step 811 is affirmative, flow proceeds to step 810 to establish an inter-channel connection. If no mapping data packet is received, the decision at step 811 is negative and the bridge of the lower priority proceeds to step 808 to acquire a channel C2 from the IRM node 104 and broadcasts a mapping data packet (step 809). The priority can be alternatively determined by having the bridges 107 and 108 select a random number. The bridge that selected a greater value of random number is given the higher priority.
With the inter-channel connections being established at bridges 107 and 108, the nodes 101 and 105 transmit their multicast packets to the network (procedures 710, 711).
A procedure for restoring the ownership of channels C1 and C2 respectively acquired by the node 101 and the bridge 107 is illustrated in
The operation of the network starts with the node 101 broadcasting a channel acquisition enquiry packet (
As indicated by procedure 1001 in the sequence diagram of
Upon receipt of the mapping data packet (procedure 1007), the bridge 107 stores the contents of the received packet into the port-B entry of the mapping table as shown in
In the sequence diagram of
Multicast transmission from the transmit node 101 to the bus system 110 (procedure 1009). Node 103 is now able to receive multicast packets from the transmit node 101.
Receive-only node 103 broadcasts a channel transfer enquiry packet and activates a timer with a timeout period Tc (procedure 1107). During this period, the node 103 monitors the channel for detecting a channel takeover packet from a node containing the identifier of bus 110, either a “report from transmit node” or “report from receive node” message and address A1. If the node 103 fails to detect such a channel takeover packet within the set period Tc, it returns the ownership of the channel C2 to the IRM node 104 (procedure 1108).
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5825752 *||Sep 25, 1996||Oct 20, 1998||Yamaha Corporation||Local area network transferring data using isochronous and asynchronous channels|
|US6230225 *||Dec 1, 1998||May 8, 2001||Compaq Computer Corp.||Method and apparatus for multicasting on a bus|
|US6434117 *||Mar 5, 1999||Aug 13, 2002||Nec Corporation||IEEE-1394 serial bus network capable of multicast communication|
|US6728821 *||Nov 27, 2000||Apr 27, 2004||Sony Corporation||Method and system for adjusting isochronous bandwidths on a bus|
|US6738816 *||Mar 8, 2000||May 18, 2004||Nec Corporation||System and method for reliable real-time communications among a plurality of nodes having functions conforming to IEEE-1394 serial bus and participating in a session of sharing the maximum bandwidth|
|US6751221 *||Mar 6, 1998||Jun 15, 2004||Kabushiki Kaisha Toshiba||Data transmitting node and network inter-connection node suitable for home network environment|
|US6757743 *||Jun 27, 2000||Jun 29, 2004||Sony Corporation||Communication control system and method, communication system, and recording medium|
|US6895456 *||Dec 12, 2000||May 17, 2005||Hewlett-Packard Development Company, L.P.||System supporting multicast master cycles between different busses in a computer system|
|US20010037422 *||Feb 16, 2001||Nov 1, 2001||Thomas Thaler||Multi-portal bridge for providing network connectivity|
|US20030115390 *||May 12, 1999||Jun 19, 2003||Yuko Iijima||Method of reserving bandwidth for an isochronous channel on a serial bus network of devices|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7817647 *||Apr 22, 2005||Oct 19, 2010||Microsoft Corporation||Flower-petal resolutions for PNRP|
|US20060239197 *||Apr 22, 2005||Oct 26, 2006||Microsoft Corporation||Flower-petal resolutions for PNRP|
|US20100023618 *||Jul 28, 2009||Jan 28, 2010||Foundry Networks, Inc.||System and method for supplicant based accounting and access|
|U.S. Classification||370/390, 370/402, 370/432|
|International Classification||H04L12/28, H04L12/44, H04L12/18, H04L12/46, H04L12/64, H04L29/08, H04L12/40|
|Cooperative Classification||H04L12/462, H04L12/6418, H04L12/40052|
|European Classification||H04L12/46B7, H04L12/64B, H04L12/40F|
|Oct 10, 2001||AS||Assignment|
Owner name: NEC CORPORATION, JAPAN
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SUZUKI, JOHJI;MOMONA, MORIHISA;REEL/FRAME:012249/0270
Effective date: 20011009
|Apr 8, 2010||FPAY||Fee payment|
Year of fee payment: 4
|Mar 12, 2014||FPAY||Fee payment|
Year of fee payment: 8