CA2264461C - Ieee-1394 serial bus network capable of multicast communication - Google Patents
Ieee-1394 serial bus network capable of multicast communication Download PDFInfo
- Publication number
- CA2264461C CA2264461C CA002264461A CA2264461A CA2264461C CA 2264461 C CA2264461 C CA 2264461C CA 002264461 A CA002264461 A CA 002264461A CA 2264461 A CA2264461 A CA 2264461A CA 2264461 C CA2264461 C CA 2264461C
- Authority
- CA
- Canada
- Prior art keywords
- channel
- node
- multicast
- isochronous
- manager
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/40052—High-speed IEEE 1394 serial bus
- H04L12/40058—Isochronous transmission
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/40052—High-speed IEEE 1394 serial bus
- H04L12/40065—Bandwidth and channel allocation
Abstract
In a communication network where IEEE-1394 nodes are connected to a serial bus, each node functions as a source or a destination for signaling an asynchronous channel setup request containing a multicast address and signaling an asynchronous channel release request. A multicast manager, connected to the bus, includes a channel allocation table having a number of entries each mapping a channel number to a multicast address. The multicast manager responds to the setup request for making a search through the allocation table, setting a node count value to 1, acquiring ownership of a channel number from an isochronous resource manager and mapping the acquired channel number to the multicast address of the request in a corresponding entry of the allocation table if no channel number was mapped to the multicast address or incrementing the node count value by 1 if a channel number is mapped to the multicast address, and then signaling a reply message. The source node responds to this reply message by multicasting asynchronous stream packets to the serial bus. The multicast manager further responds to the asynchronous channel release request for decrementing the node count value by 1. When the node count value equals zero, the ownership of the channel number is restored to the isochronous resource manager and the corresponding entry of the channel allocation table is cleared.
Description
2 "IEEE-1 394 Serial Bus Network Capable of Multicast Communication"
4 Field of the Invention The present invention relates generally to IEEE-1394 serial bus systems 6 and more specifically to a serial bus communication on which multicast packets '7 are transmitted over an assigned channel.
8 Description of the Related Art 9 IEEE Standard for a High Performance Serial Bus (IEEE Std. 1 394-1995) specifies broadcast communication using a particular address reserved 11 for this purpose as well as unicast communication by specifying a target node 12 with an identifier assigned to that node. Asynchronous and isochronous data 13 transfer types are available for different types of traffic... Control data traffic is 14 supported by asynchronous packets, while high-volume traffic is carried on i5 isochronous packets at a constant rate.
16 Study is currently undertaken by a body known as IETF (Internet i'7 Engineering Task Force) to enable transmission of connectionless packets such 18 as IP (Internet Protocol) datagrams over the IEEE-1394 serial bus.
According 19 to the proposed method for sending a datagram to a destination node having an IP address, the source node first broadcasts the IP address of the 21 destination node to all nodes of the bus. A node having the broadcast 22 address knows that it is targeted and returns a node identifier corresponding 23 to that IP address to the source node. At the source node, the informed node 24 identifier is registered as a destination address of an asynchronous packet, which is transmitted as an IP datagram. While all nodes of the bus can be 26 addressed with the specified broadcast address and each node can be 2~ specified for unicast transmission, it is currently impossible to specify a 28 particular group of nodes for multicast transmission.
29 Asynchronous stream packets are defined by the IEEE-1 394 standard as a special case of asynchronous transmission. Similar to the isochronous 31 packet, the asynchronous stream packet uses a channel number rather than a 32 destination node address. It can be transmitted as a multicast packet during a -2_ "fairness interval". Possibility thus exists that a single channel is shared by 2 more than one node. In such a multicast mode, however, there is a need to 3 provide some means for communicating the channel number of either 4 asynchronous stream packets or isochronous packets between nodes for the purpose of dynamically setting or releasing a channel.
It is therefore an object of the present invention to provide a 8 communication network and a method to implement multicast communication 9 for IEEE-1394 nodes.
According to one aspect, the present invention provides a network comprising a plurality of IEEE-1394 nodes connected to a serial bus, each of ~2 the nodes functioning as a source node or a destination node for signaling an 13 asynchronous channel setup request containing a multicast address and signaling an asynchronous channel release request. A multicast manager is connected to the serial bus. The multicast manager comprises a channel allocation table having a plurality of entries each mapping a channel number to n7 a multicast address. The multicast manager is responsive to the asynchronous 18 channel setup request for making a search through the table, setting a node 19 count value to 1, acquiring ownership of a channel number from an IEEE-1394 isochronous resource manager and mapping the acquired channel number to 21 the multicast address of the request in a corresponding entry of the allocation 22 table if no channel number was mapped to the multicast address during the 23 search or incrementing the node count value by 1 if a channel number is 24 mapped to the multicast address, and then signaling a reply message. The source node is responsive to the reply message from the multicast manager for 26 multicasting asynchronous stream packets to the serial bus. The multicast 2~ manager is further responsive to the asynchronous channel release request for 28 decrementing the node count value by 1. When the node count value equals 29 zero, the multicast manager restores the ownership of the channel number to the isochronous resource manager and clears the corresponding entry of the 31 channel allocation table.
32 According to a second aspect, the present invention provides a 1 communication network comprising a plurality of IEEE-1 394 nodes connected 2 to a serial bus, each of the nodes functioning as a source node or a destination 3 node for signaling an isochronous channel setup request containing session data and signaling an isochronous channel release request, and a multicast manager connected to the serial bus. The multicast manager comprises a 6 channel allocation table having a plurality of entries each mapping a channel number to session data. The multicast manager is responsive to the 8 isochronous channel setup request for making a search through the table, 9 setting a node count value to 1, acquiring ownership of a channel number and i0 necessary channel resource from an IEEE-1 394 isochronous resource manager and mapping the channel number and the necessary channel resource to the ~2 session data of the request in a corresponding entry of the table if no channel 13 number was mapped to the session data during the search or incrementing the t4 node count value by 1 if a channel number is mapped to the session data ~5 during the search, and signaling a reply message. The source node is 16 responsive to the reply message for multicasting isochronous packets to the bus. The multicast manager is responsive to the isochronous channel release ~8 packet for decrementing the node count value by 1. When the node count 19 value equals zero, the multicast manager restores the ownership of the channel 20 number and the channel resource to the isochronous resource manager and 21 clears the corresponding entry of the table.
22 According to a further aspect, the present invention provides a 23 communication network comprising a plurality of IEEE-1 394 nodes connected 24 to a serial bus, each of the nodes functioning as a source node for signaling a 25 path message indicating session data and functioning as a destination node for 26 receiving the path message and signaling a first isochronous channel setup 27 request containing the session data indicated in the path message, each of the 28 source and destination nodes signaling an isochronous channel release request, 29 and a multicast manager connected to the serial bus. The multicast manager 30 comprises a channel allocation table having a plurality of entries each mapping 3 ~ a channel number to session data. The multicast manager is responsive to the 32 first isochronous channel setup packet for making a search through the table, setting a node count value to 1, acquiring ownership of an isochronous channel number from an IEEE-1394 isochronous resource manager and mapping the acquired channel number to the session data of the packet in a corresponding entry of the table if no channel number was mapped to the session data during the search or incrementing the node count value by 1 if a channel number is mapped to the session data during the search, and signaling a first reply message. The destination node is responsive to the first reply message for signaling a reservation message indicating a desired channel resource, and the source node is responsive to the reservation message for signaling a second isochronous channel setup request containing the channel resource indicated in the reservation message. The multicast manager is responsive to the second isochronous channel setup request for determining necessary channel resource from a resource value in the corresponding entry of the allocation table, acquiring ownership of the necessary channel resource from the isochronous resource manager and updating the resource value with the acquired channel resource and signaling a second reply message. The source node is responsive to the second reply message from the multicast manager for multicasting isochronous packets to the bus.
The multicast manager is responsive to the isochronous channel release request for decrementing the node count value by 1. When the node count value equals zero, the multicast manager restores the ownership of the channel number and the channel resource to the isochronous resource manager and clears the corresponding entry of the table.
In accordance with the present invention, there is provided a communication network comprising: a plurality of network nodes connected to a serial bus, each of the nodes functioning as a source node or a destination node for i -4a-signaling a channel setup request containing an identification of a multicast communication and a channel release request; and a multicast manager connected to said serial bus, said multicast manager comprising a channel allocation table having a plurality of entries, said multicast manager being responsive to said channel setup request for making a search through said table, setting a node count value to 1 in an entry of said table, acquiring ownership of a channel number from an isochronous resource manager and mapping the acquired channel number to the identification of said multicast communication in said table entry if said search indicates that no channel number is mapped in said table entry or incrementing the node count value of said table entry by 1 if said search indicates that a channel number is mapped to the identification of said multicast communication, and signaling a reply message on said bus, said source node being responsive to said reply message from the multicast manager for multicasting packets to said bus, said multicast manager being responsive to said channel release request for decrementing the node count value of said table entry by 1, said multicast manager restoring the ownership of said channel number to said isochronous resource manager and clearing said table entry when said node count value equals zero.
In accordance with the present invention, there is also provided a communication method for a network including a plurality of network nodes connected to a serial bus, one of said nodes comprising a channel allocation table having a plurality of entries, the method comprising the steps of: a) signaling a request for a communication channel from one of said nodes either functioning as a source node or a destination node; b) making a search through said table in response to the request; c) if no channel number is mapped -4b-in an entry of said table to an identification of multicast communication contained in said request, setting a node count value to 1 in said table entry, acquiring ownership of a channel number from an isochronous resource manager and mapping the acquired channel number to the identification of the multicast communication in said table entry; d) if a channel number is mapped to the identification of said multicast communication, incrementing the node count value by 1 in said table entry; e) multicasting packets from said source node to said bus; f) requesting release of the channel from one of said nodes; g) decrementing the node count value of said table entry by 1; and h) repeating steps (a) to (g), restoring the ownership of said channel number to said isochronous resource manager and clearing said table entry when said node count value equals zero.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention will be described in further detail with reference to the accompanying drawings, in which:
Fig. 1 is a block diagram of an IEEE 1394 serial bus network embodying the present invention;
Fig. 2 is an illustration of a channel allocation table resident in a multicast manager;
Fig. 3 is an illustration of a control register resident in the multicast manager to be directly set by a requesting node and read by the multicast 1 manager when establishing an asynchronous multicast-mode channel or an 2 isochronous multicast-mode channel;
3 Fig. 4 is an illustration of an control register resident in an IEEE-1394 4 node to be directly set by the multicast manager and read by the requesting node when establishing an asynchronous multicast-mode channel or an isochronous multicast-mode channel;
'7 Fig. 5A is a flowchart of the operation of a source node of the 8 network when requesting the transmission of multicast asynchronous stream 9 packets according to a first embodiment of the present invention;
Fig. 5B is a flowchart of the operation of a destination node when requesting the reception of multicast asynchronous stream packets according ~2 to the first embodiment of the present invention;
~3 Fig. 6 is a flowchart of the operation of the multicast manager co-~4 operating with requesting nodes which operates according to the flowchart of Fig. 5;
Figs. 7 to 10 are sequence diagrams illustrating asynchronous transactions associated with the flowcharts of Figs. 5 and 6;
18 Figs. 1 1 A and 1 1 B are flowcharts of the operation of a source node requesting an isochronous channel according to a second embodiment of the present invention;
21 Fig. 12 is a flowchart of the operation of a destination node 22 requesting the reception of multicast isochronous packets according to the 23 second embodiment of the present invention;
24 Fig. 13 is a flowchart of the operation of the multicast manager co-operating with the nodes operating according to the flowcharts of Figs. 1 1 A, 26 1 1 B and 12; and 2'7 Figs. 14 to 16 are sequence diagrams illustrating isochronous 28 transactions associated with the flowcharts of Figs. 1 1 A, 1 1 B, 12 and 13.
In Fig. 1 , a typical example of the IEEE 1 394 serial bus system is 31 illustrated, in which five nodes 1 OA to 1 OE are provided. Each node has a 32 communication protocol such as the Internet Protocol. In the following description, the node 1 OA will be explained as a source node, 1 OC as a 2 destination node with the intermediate node 1 OB functioning as a repeater 3 between nodes 1 OA and 1 OC. Node 1 OC also functions as a repeater when a packet (asynchronous) is exchanged between nodes 1 OA and 1 OD. Node 1 OD is a multicast manager that performs the management of channels 6 allocated for multicast communications and quality-of-service parameters 7 (such as the bandwidth of allocated channels) by co-operating with a node 8 1 OE that assumes the role of an isochronous resource manager. Note that 9 these manager functions may be combined and implemented in a single node.
to Although not shown in Fig. 1, each node has a physical layer connected to the 1 ~ 1394 serial bus, a link layer, and a transaction layer. The link layer is i2 connected to an application layer for isochronous transactions as well as to 13 the transaction layer for asynchronous transactions.
14 According to the present invention, the multicast manager 1 OD is ~ 5 provided with a channel allocation table 20, as illustrated in Fig. 2.
Channel 16 allocation table 20 has a plurality of channel entries corresponding to channel 17 numbers "0" to u63".
~8 Each channel entry of the channel allocation table 20 is divided into 19 fields 21 to 24. Field 21 is a packet type field that is used for indicating 2o whether the packet to be used for a data transfer is an isochronous packet 21 that is transmitted at a constant rate in a multicast mode within nominal cycle 22 period of 125 ~.s or an asynchronous stream packet that is transmitted in a 23 multicast mode within an interval known as "fairness interval" between two 24 arbitration reset gaps. Field 22 is a bandwidth field in which allocated 25 bandwidth is indicated if the packet is of isochronous type. A node count is 26 given in the field 23 to indicate the number of nodes participating in a single 27 data transfer, regardless of the types of packets being used. Field 24 is an 28 address field in which a multicast address is indicated if data transfer involves 29 the use of asynchronous stream packets. If data transfer mode is isochronous, 30 session data (destination node address, protocol number and port number) 3 ~ are indicated in the address field 24.
32 Multicast manager 1 OD is further provided with a control register 30 1 as shown in Fig. 3. Control register 30 is defined in the CSR (control and 2 status register) architecture register space of the IEEE 1394 standard and has 3 a command field 31 for giving one of a predefined set of indications (asynchronous-mode channel setup and release and isochronous-mode channel setup and release) and an address field 32 in which a multicast 6 address is indicated when data transfer mode is asynchronous or session data (destination node address, protocol number and port number) when the 8 transfer mode is isochronous. Control register 30 is written directly by a 9 node requesting the starting or ending of a communication and the multicast manager 1 OD reads the contents of the register 30 and knows that a request 11 is made from one of the nodes of the network.
~2 Each of the nodes 1 OA to 1 OC is provided with a control register 40, ~ 3 which is also defined in the CSR architecture register space, as shown in Fig. 4.
~4 This control register has a response field 41, an address field 42 and a channel number field 43. Response field 41 is used to indicate multicast 16 (asynchronous-mode) channel setup indication or isochronous-mode channel setup indication, and the address field 42 is used to store a multicast address 18 in the case of asynchronous mode and session data during isochronous transfer mode. Control register 40 of each node is directly written by the 2o multicast manager 1 OD and the node reads the contents of the register 40 2~ and knows that a response action is taken by the multicast manager 1 OD.
22 Fig. 5A is the flowchart of the operation of the transaction layer of 23 source node 1 OA when transmission of asynchronous stream packets is 24 initiated from the application layer of the node, and Fig. 5B is the flowchart of the operation of the transaction layer of destination node 1 OC when reception 26 of such multicast packets is requested from the application layer of the node.
2'7 Specifically, in Fig. 5A, the transaction layer at the source node checks 28 for the presence of IP multicast data from the application layer software (step 29 501 ). If IP multicast data is detected, the transaction layer proceeds from 3o step SO1 to step 502 to send a request containing a multicast address for 3 ~ setting up an asynchronous-mode channel. This is done by directly setting the 32 control register 30 of the multicast manager 1 OD with an asynchronous mode _g_ 1 indication and a multicast address. Multicast manager 1 OD knows that it has 2 received a request from a node, and sends a reply to the requesting node.
3 This is achieved by the multicast manager 1 OD by directly setting the control 4 register 40 of the requesting node with a response indication, the multicast address of the node and a channel number obtained from the isochronous 6 resource manager 1 OE. When the reply indication is set in the control register 40 (step 503), the source node 1 OA is conditioned to send asynchronous 8 stream packets containing the assigned channel number in their channel 9 number field. At step 504, an asynchronous stream packet is sent during a "fairness interval" which is designed into the transaction layer of the node by 11 the 1394 Standard so that each node wishing to initiate a transaction is given ~2 fair access to the bus.
13 Following the transmission of an asynchronous stream packet, a timer 14 is started (step 505) and a test is made at step 506 for the presence of an outstanding asynchronous stream packet of the same multicast address as one transmitted at step 504. If there is one, the decision at step 506 is affirmative 1'7 and flow proceeds to step 507 to clear the timer and returns to step 504 to ~ 8 repeat the asynchronous stream packet transmission, timer start-up and packet 19 presence test. If there is no outstanding asynchronous stream packet, the decision at step 506 is negative and flow proceeds to step 508 to check to 21 see if the timer has timed out. If the timer is still running, flow loops steps 22 506 and 508 so that, if an asynchronous stream packet occurs before the 23 timer times out, it is transmitted in a fairness interval. If the timer times, it is 24 concluded that there are no more packets to transmit and flow proceeds from step 508 to step 509 to set a channel release indication into the control 26 register 30 of the multicast manager 1 OD.
2~ In Fig. 5B, the operation of the destination node 1 OC begins at step 28 51 1 when the transaction layer of the node receives a data reception 29 indication from its application layer. The transaction layer of node 1 OC
proceeds from step 51 1 to step 512 to send a request containing a multicast 3 ~ address for setting up an asynchronous-mode channel. This is done by 32 directly setting the control register 30 of the multicast manager 1 OD with an asynchronous mode indication and a multicast address in the same manner as 2 performed by the source node at step 502. Multicast manager 1 OD knows 3 that it has received a request from a node, and sends a reply to the destination 4 node. This is also achieved by the multicast manager by directly setting the control register 40 of the destination node with a response indication, the 6 multicast address of the destination node and a channel number obtained from 7 the isochronous resource manager 1 OE. When the reply indication is set in the 8 control register 40 (step 513), the destination node 1 OC is conditioned to 9 receive asynchronous stream packets containing the assigned channel number 1o in their channel number field (step 514). If an end-of-reception indication is 1 ~ given by the application layer of the destination node (step 51 5), the 12 transaction layer terminates the routine by setting a channel release indication 13 into the control register 30 of the multicast manager (step 516).
~4 The operation of the multicast manager 1 OD in response to the requests for asynchronous stream packets from the source and destination nodes will be explained with the aid of the flowchart of Fig. 6.
Multicast manager 1 OD starts its operation at step 601 at which it ~ 8 checks to see if an asynchronous-mode channel setup request or an asynchronous-mode channel release request is received from a node. This is achieved by checking the contents of the control register 30 to see whether 21 necessary data are set by a requesting node. If an asynchronous-mode 22 channel setup indication is set in the register 30, flow proceeds from step 23 to step 602 to make a search through the channel allocation table 20 for a 24 channel entry in which received multicast address is registered.
If there is no channel entry containing that multicast address, flow 26 proceeds from step 603 to step 604 to send a channel assignment request to 27 the isochronous resource manager 1 OE to acquire ownership of a channel. If a 28 channel is available, a channel number is assigned by the isochronous resource 29 manager and the multicast manager 1 OD is informed of the assigned channel number.
31 At step 605, an asynchronous packet type indication is set into the 32 packet type field 21 of a channel entry of the allocation table 20 that i corresponds to the assigned channel number and the multicast address stored 2 in the control register 30 is set into the address field 24 of that channel entry 3 and a "1 " is set into the node count field 23. In this way, a channel number is mapped to the multicast address of an asynchronous channel setup request.
At step 606, the multicast manager sends a reply packet to the source 6 node to inform it of the channel number mapped in the corresponding entry '7 of the allocation table 20, and returns to the starting point of the routine.
8 If an asynchronous-mode channel setup request is received from 9 another node, the multicast manager will repeat steps 602 and 603, so that a 1o new multicast address is set by that node into the address field 32 of register i i 30. If the new multicast address is the same as the one set in the address field ~2 24 of allocation table 20, the decision at step 603 will be affirmative, and 13 flow proceeds to step 607 to increment the value of node count field 23 by 14 one, and proceeds to step 606 to send a reply message to the requesting ~5 node by setting its control register 40 with the channel number already 16 assigned to the node 1 OA. In this manner, the node count value represents 17 the number of nodes using the same asynchronous channel.
18 If the source node ceases to send asynchronous stream packets, it sends a channel release request by setting the control register 30 with a 2o release indication (step 509, Fig. 5A). In a similar manner, when the 21 destination node ceases to receive asynchronous stream packets, it sends a 22 channel release request by setting the control register 30 with a release 23 indication (step 516, Fig. 5B).
24 In response to each of such release requests, the multicast manager 25 1 OD, which is looping step 601, proceeds to step 608 to decrement the 26 value in the node count field 23 by one and checks to see if the node count 2~ equals zero (step 609). If the node count is not equal to zero, flow returns 28 from step 609 to step 601. If the node count is zero, flow proceeds to step 29 610 to send a channel release packet to the isochronous resource manager 3o 1 OE to restore the ownership of the assigned channel, and concludes the 31 routine with step 61 1 by clearing the contents of the appropriate channel 32 entry of allocation table 20.
8 Description of the Related Art 9 IEEE Standard for a High Performance Serial Bus (IEEE Std. 1 394-1995) specifies broadcast communication using a particular address reserved 11 for this purpose as well as unicast communication by specifying a target node 12 with an identifier assigned to that node. Asynchronous and isochronous data 13 transfer types are available for different types of traffic... Control data traffic is 14 supported by asynchronous packets, while high-volume traffic is carried on i5 isochronous packets at a constant rate.
16 Study is currently undertaken by a body known as IETF (Internet i'7 Engineering Task Force) to enable transmission of connectionless packets such 18 as IP (Internet Protocol) datagrams over the IEEE-1394 serial bus.
According 19 to the proposed method for sending a datagram to a destination node having an IP address, the source node first broadcasts the IP address of the 21 destination node to all nodes of the bus. A node having the broadcast 22 address knows that it is targeted and returns a node identifier corresponding 23 to that IP address to the source node. At the source node, the informed node 24 identifier is registered as a destination address of an asynchronous packet, which is transmitted as an IP datagram. While all nodes of the bus can be 26 addressed with the specified broadcast address and each node can be 2~ specified for unicast transmission, it is currently impossible to specify a 28 particular group of nodes for multicast transmission.
29 Asynchronous stream packets are defined by the IEEE-1 394 standard as a special case of asynchronous transmission. Similar to the isochronous 31 packet, the asynchronous stream packet uses a channel number rather than a 32 destination node address. It can be transmitted as a multicast packet during a -2_ "fairness interval". Possibility thus exists that a single channel is shared by 2 more than one node. In such a multicast mode, however, there is a need to 3 provide some means for communicating the channel number of either 4 asynchronous stream packets or isochronous packets between nodes for the purpose of dynamically setting or releasing a channel.
It is therefore an object of the present invention to provide a 8 communication network and a method to implement multicast communication 9 for IEEE-1394 nodes.
According to one aspect, the present invention provides a network comprising a plurality of IEEE-1394 nodes connected to a serial bus, each of ~2 the nodes functioning as a source node or a destination node for signaling an 13 asynchronous channel setup request containing a multicast address and signaling an asynchronous channel release request. A multicast manager is connected to the serial bus. The multicast manager comprises a channel allocation table having a plurality of entries each mapping a channel number to n7 a multicast address. The multicast manager is responsive to the asynchronous 18 channel setup request for making a search through the table, setting a node 19 count value to 1, acquiring ownership of a channel number from an IEEE-1394 isochronous resource manager and mapping the acquired channel number to 21 the multicast address of the request in a corresponding entry of the allocation 22 table if no channel number was mapped to the multicast address during the 23 search or incrementing the node count value by 1 if a channel number is 24 mapped to the multicast address, and then signaling a reply message. The source node is responsive to the reply message from the multicast manager for 26 multicasting asynchronous stream packets to the serial bus. The multicast 2~ manager is further responsive to the asynchronous channel release request for 28 decrementing the node count value by 1. When the node count value equals 29 zero, the multicast manager restores the ownership of the channel number to the isochronous resource manager and clears the corresponding entry of the 31 channel allocation table.
32 According to a second aspect, the present invention provides a 1 communication network comprising a plurality of IEEE-1 394 nodes connected 2 to a serial bus, each of the nodes functioning as a source node or a destination 3 node for signaling an isochronous channel setup request containing session data and signaling an isochronous channel release request, and a multicast manager connected to the serial bus. The multicast manager comprises a 6 channel allocation table having a plurality of entries each mapping a channel number to session data. The multicast manager is responsive to the 8 isochronous channel setup request for making a search through the table, 9 setting a node count value to 1, acquiring ownership of a channel number and i0 necessary channel resource from an IEEE-1 394 isochronous resource manager and mapping the channel number and the necessary channel resource to the ~2 session data of the request in a corresponding entry of the table if no channel 13 number was mapped to the session data during the search or incrementing the t4 node count value by 1 if a channel number is mapped to the session data ~5 during the search, and signaling a reply message. The source node is 16 responsive to the reply message for multicasting isochronous packets to the bus. The multicast manager is responsive to the isochronous channel release ~8 packet for decrementing the node count value by 1. When the node count 19 value equals zero, the multicast manager restores the ownership of the channel 20 number and the channel resource to the isochronous resource manager and 21 clears the corresponding entry of the table.
22 According to a further aspect, the present invention provides a 23 communication network comprising a plurality of IEEE-1 394 nodes connected 24 to a serial bus, each of the nodes functioning as a source node for signaling a 25 path message indicating session data and functioning as a destination node for 26 receiving the path message and signaling a first isochronous channel setup 27 request containing the session data indicated in the path message, each of the 28 source and destination nodes signaling an isochronous channel release request, 29 and a multicast manager connected to the serial bus. The multicast manager 30 comprises a channel allocation table having a plurality of entries each mapping 3 ~ a channel number to session data. The multicast manager is responsive to the 32 first isochronous channel setup packet for making a search through the table, setting a node count value to 1, acquiring ownership of an isochronous channel number from an IEEE-1394 isochronous resource manager and mapping the acquired channel number to the session data of the packet in a corresponding entry of the table if no channel number was mapped to the session data during the search or incrementing the node count value by 1 if a channel number is mapped to the session data during the search, and signaling a first reply message. The destination node is responsive to the first reply message for signaling a reservation message indicating a desired channel resource, and the source node is responsive to the reservation message for signaling a second isochronous channel setup request containing the channel resource indicated in the reservation message. The multicast manager is responsive to the second isochronous channel setup request for determining necessary channel resource from a resource value in the corresponding entry of the allocation table, acquiring ownership of the necessary channel resource from the isochronous resource manager and updating the resource value with the acquired channel resource and signaling a second reply message. The source node is responsive to the second reply message from the multicast manager for multicasting isochronous packets to the bus.
The multicast manager is responsive to the isochronous channel release request for decrementing the node count value by 1. When the node count value equals zero, the multicast manager restores the ownership of the channel number and the channel resource to the isochronous resource manager and clears the corresponding entry of the table.
In accordance with the present invention, there is provided a communication network comprising: a plurality of network nodes connected to a serial bus, each of the nodes functioning as a source node or a destination node for i -4a-signaling a channel setup request containing an identification of a multicast communication and a channel release request; and a multicast manager connected to said serial bus, said multicast manager comprising a channel allocation table having a plurality of entries, said multicast manager being responsive to said channel setup request for making a search through said table, setting a node count value to 1 in an entry of said table, acquiring ownership of a channel number from an isochronous resource manager and mapping the acquired channel number to the identification of said multicast communication in said table entry if said search indicates that no channel number is mapped in said table entry or incrementing the node count value of said table entry by 1 if said search indicates that a channel number is mapped to the identification of said multicast communication, and signaling a reply message on said bus, said source node being responsive to said reply message from the multicast manager for multicasting packets to said bus, said multicast manager being responsive to said channel release request for decrementing the node count value of said table entry by 1, said multicast manager restoring the ownership of said channel number to said isochronous resource manager and clearing said table entry when said node count value equals zero.
In accordance with the present invention, there is also provided a communication method for a network including a plurality of network nodes connected to a serial bus, one of said nodes comprising a channel allocation table having a plurality of entries, the method comprising the steps of: a) signaling a request for a communication channel from one of said nodes either functioning as a source node or a destination node; b) making a search through said table in response to the request; c) if no channel number is mapped -4b-in an entry of said table to an identification of multicast communication contained in said request, setting a node count value to 1 in said table entry, acquiring ownership of a channel number from an isochronous resource manager and mapping the acquired channel number to the identification of the multicast communication in said table entry; d) if a channel number is mapped to the identification of said multicast communication, incrementing the node count value by 1 in said table entry; e) multicasting packets from said source node to said bus; f) requesting release of the channel from one of said nodes; g) decrementing the node count value of said table entry by 1; and h) repeating steps (a) to (g), restoring the ownership of said channel number to said isochronous resource manager and clearing said table entry when said node count value equals zero.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention will be described in further detail with reference to the accompanying drawings, in which:
Fig. 1 is a block diagram of an IEEE 1394 serial bus network embodying the present invention;
Fig. 2 is an illustration of a channel allocation table resident in a multicast manager;
Fig. 3 is an illustration of a control register resident in the multicast manager to be directly set by a requesting node and read by the multicast 1 manager when establishing an asynchronous multicast-mode channel or an 2 isochronous multicast-mode channel;
3 Fig. 4 is an illustration of an control register resident in an IEEE-1394 4 node to be directly set by the multicast manager and read by the requesting node when establishing an asynchronous multicast-mode channel or an isochronous multicast-mode channel;
'7 Fig. 5A is a flowchart of the operation of a source node of the 8 network when requesting the transmission of multicast asynchronous stream 9 packets according to a first embodiment of the present invention;
Fig. 5B is a flowchart of the operation of a destination node when requesting the reception of multicast asynchronous stream packets according ~2 to the first embodiment of the present invention;
~3 Fig. 6 is a flowchart of the operation of the multicast manager co-~4 operating with requesting nodes which operates according to the flowchart of Fig. 5;
Figs. 7 to 10 are sequence diagrams illustrating asynchronous transactions associated with the flowcharts of Figs. 5 and 6;
18 Figs. 1 1 A and 1 1 B are flowcharts of the operation of a source node requesting an isochronous channel according to a second embodiment of the present invention;
21 Fig. 12 is a flowchart of the operation of a destination node 22 requesting the reception of multicast isochronous packets according to the 23 second embodiment of the present invention;
24 Fig. 13 is a flowchart of the operation of the multicast manager co-operating with the nodes operating according to the flowcharts of Figs. 1 1 A, 26 1 1 B and 12; and 2'7 Figs. 14 to 16 are sequence diagrams illustrating isochronous 28 transactions associated with the flowcharts of Figs. 1 1 A, 1 1 B, 12 and 13.
In Fig. 1 , a typical example of the IEEE 1 394 serial bus system is 31 illustrated, in which five nodes 1 OA to 1 OE are provided. Each node has a 32 communication protocol such as the Internet Protocol. In the following description, the node 1 OA will be explained as a source node, 1 OC as a 2 destination node with the intermediate node 1 OB functioning as a repeater 3 between nodes 1 OA and 1 OC. Node 1 OC also functions as a repeater when a packet (asynchronous) is exchanged between nodes 1 OA and 1 OD. Node 1 OD is a multicast manager that performs the management of channels 6 allocated for multicast communications and quality-of-service parameters 7 (such as the bandwidth of allocated channels) by co-operating with a node 8 1 OE that assumes the role of an isochronous resource manager. Note that 9 these manager functions may be combined and implemented in a single node.
to Although not shown in Fig. 1, each node has a physical layer connected to the 1 ~ 1394 serial bus, a link layer, and a transaction layer. The link layer is i2 connected to an application layer for isochronous transactions as well as to 13 the transaction layer for asynchronous transactions.
14 According to the present invention, the multicast manager 1 OD is ~ 5 provided with a channel allocation table 20, as illustrated in Fig. 2.
Channel 16 allocation table 20 has a plurality of channel entries corresponding to channel 17 numbers "0" to u63".
~8 Each channel entry of the channel allocation table 20 is divided into 19 fields 21 to 24. Field 21 is a packet type field that is used for indicating 2o whether the packet to be used for a data transfer is an isochronous packet 21 that is transmitted at a constant rate in a multicast mode within nominal cycle 22 period of 125 ~.s or an asynchronous stream packet that is transmitted in a 23 multicast mode within an interval known as "fairness interval" between two 24 arbitration reset gaps. Field 22 is a bandwidth field in which allocated 25 bandwidth is indicated if the packet is of isochronous type. A node count is 26 given in the field 23 to indicate the number of nodes participating in a single 27 data transfer, regardless of the types of packets being used. Field 24 is an 28 address field in which a multicast address is indicated if data transfer involves 29 the use of asynchronous stream packets. If data transfer mode is isochronous, 30 session data (destination node address, protocol number and port number) 3 ~ are indicated in the address field 24.
32 Multicast manager 1 OD is further provided with a control register 30 1 as shown in Fig. 3. Control register 30 is defined in the CSR (control and 2 status register) architecture register space of the IEEE 1394 standard and has 3 a command field 31 for giving one of a predefined set of indications (asynchronous-mode channel setup and release and isochronous-mode channel setup and release) and an address field 32 in which a multicast 6 address is indicated when data transfer mode is asynchronous or session data (destination node address, protocol number and port number) when the 8 transfer mode is isochronous. Control register 30 is written directly by a 9 node requesting the starting or ending of a communication and the multicast manager 1 OD reads the contents of the register 30 and knows that a request 11 is made from one of the nodes of the network.
~2 Each of the nodes 1 OA to 1 OC is provided with a control register 40, ~ 3 which is also defined in the CSR architecture register space, as shown in Fig. 4.
~4 This control register has a response field 41, an address field 42 and a channel number field 43. Response field 41 is used to indicate multicast 16 (asynchronous-mode) channel setup indication or isochronous-mode channel setup indication, and the address field 42 is used to store a multicast address 18 in the case of asynchronous mode and session data during isochronous transfer mode. Control register 40 of each node is directly written by the 2o multicast manager 1 OD and the node reads the contents of the register 40 2~ and knows that a response action is taken by the multicast manager 1 OD.
22 Fig. 5A is the flowchart of the operation of the transaction layer of 23 source node 1 OA when transmission of asynchronous stream packets is 24 initiated from the application layer of the node, and Fig. 5B is the flowchart of the operation of the transaction layer of destination node 1 OC when reception 26 of such multicast packets is requested from the application layer of the node.
2'7 Specifically, in Fig. 5A, the transaction layer at the source node checks 28 for the presence of IP multicast data from the application layer software (step 29 501 ). If IP multicast data is detected, the transaction layer proceeds from 3o step SO1 to step 502 to send a request containing a multicast address for 3 ~ setting up an asynchronous-mode channel. This is done by directly setting the 32 control register 30 of the multicast manager 1 OD with an asynchronous mode _g_ 1 indication and a multicast address. Multicast manager 1 OD knows that it has 2 received a request from a node, and sends a reply to the requesting node.
3 This is achieved by the multicast manager 1 OD by directly setting the control 4 register 40 of the requesting node with a response indication, the multicast address of the node and a channel number obtained from the isochronous 6 resource manager 1 OE. When the reply indication is set in the control register 40 (step 503), the source node 1 OA is conditioned to send asynchronous 8 stream packets containing the assigned channel number in their channel 9 number field. At step 504, an asynchronous stream packet is sent during a "fairness interval" which is designed into the transaction layer of the node by 11 the 1394 Standard so that each node wishing to initiate a transaction is given ~2 fair access to the bus.
13 Following the transmission of an asynchronous stream packet, a timer 14 is started (step 505) and a test is made at step 506 for the presence of an outstanding asynchronous stream packet of the same multicast address as one transmitted at step 504. If there is one, the decision at step 506 is affirmative 1'7 and flow proceeds to step 507 to clear the timer and returns to step 504 to ~ 8 repeat the asynchronous stream packet transmission, timer start-up and packet 19 presence test. If there is no outstanding asynchronous stream packet, the decision at step 506 is negative and flow proceeds to step 508 to check to 21 see if the timer has timed out. If the timer is still running, flow loops steps 22 506 and 508 so that, if an asynchronous stream packet occurs before the 23 timer times out, it is transmitted in a fairness interval. If the timer times, it is 24 concluded that there are no more packets to transmit and flow proceeds from step 508 to step 509 to set a channel release indication into the control 26 register 30 of the multicast manager 1 OD.
2~ In Fig. 5B, the operation of the destination node 1 OC begins at step 28 51 1 when the transaction layer of the node receives a data reception 29 indication from its application layer. The transaction layer of node 1 OC
proceeds from step 51 1 to step 512 to send a request containing a multicast 3 ~ address for setting up an asynchronous-mode channel. This is done by 32 directly setting the control register 30 of the multicast manager 1 OD with an asynchronous mode indication and a multicast address in the same manner as 2 performed by the source node at step 502. Multicast manager 1 OD knows 3 that it has received a request from a node, and sends a reply to the destination 4 node. This is also achieved by the multicast manager by directly setting the control register 40 of the destination node with a response indication, the 6 multicast address of the destination node and a channel number obtained from 7 the isochronous resource manager 1 OE. When the reply indication is set in the 8 control register 40 (step 513), the destination node 1 OC is conditioned to 9 receive asynchronous stream packets containing the assigned channel number 1o in their channel number field (step 514). If an end-of-reception indication is 1 ~ given by the application layer of the destination node (step 51 5), the 12 transaction layer terminates the routine by setting a channel release indication 13 into the control register 30 of the multicast manager (step 516).
~4 The operation of the multicast manager 1 OD in response to the requests for asynchronous stream packets from the source and destination nodes will be explained with the aid of the flowchart of Fig. 6.
Multicast manager 1 OD starts its operation at step 601 at which it ~ 8 checks to see if an asynchronous-mode channel setup request or an asynchronous-mode channel release request is received from a node. This is achieved by checking the contents of the control register 30 to see whether 21 necessary data are set by a requesting node. If an asynchronous-mode 22 channel setup indication is set in the register 30, flow proceeds from step 23 to step 602 to make a search through the channel allocation table 20 for a 24 channel entry in which received multicast address is registered.
If there is no channel entry containing that multicast address, flow 26 proceeds from step 603 to step 604 to send a channel assignment request to 27 the isochronous resource manager 1 OE to acquire ownership of a channel. If a 28 channel is available, a channel number is assigned by the isochronous resource 29 manager and the multicast manager 1 OD is informed of the assigned channel number.
31 At step 605, an asynchronous packet type indication is set into the 32 packet type field 21 of a channel entry of the allocation table 20 that i corresponds to the assigned channel number and the multicast address stored 2 in the control register 30 is set into the address field 24 of that channel entry 3 and a "1 " is set into the node count field 23. In this way, a channel number is mapped to the multicast address of an asynchronous channel setup request.
At step 606, the multicast manager sends a reply packet to the source 6 node to inform it of the channel number mapped in the corresponding entry '7 of the allocation table 20, and returns to the starting point of the routine.
8 If an asynchronous-mode channel setup request is received from 9 another node, the multicast manager will repeat steps 602 and 603, so that a 1o new multicast address is set by that node into the address field 32 of register i i 30. If the new multicast address is the same as the one set in the address field ~2 24 of allocation table 20, the decision at step 603 will be affirmative, and 13 flow proceeds to step 607 to increment the value of node count field 23 by 14 one, and proceeds to step 606 to send a reply message to the requesting ~5 node by setting its control register 40 with the channel number already 16 assigned to the node 1 OA. In this manner, the node count value represents 17 the number of nodes using the same asynchronous channel.
18 If the source node ceases to send asynchronous stream packets, it sends a channel release request by setting the control register 30 with a 2o release indication (step 509, Fig. 5A). In a similar manner, when the 21 destination node ceases to receive asynchronous stream packets, it sends a 22 channel release request by setting the control register 30 with a release 23 indication (step 516, Fig. 5B).
24 In response to each of such release requests, the multicast manager 25 1 OD, which is looping step 601, proceeds to step 608 to decrement the 26 value in the node count field 23 by one and checks to see if the node count 2~ equals zero (step 609). If the node count is not equal to zero, flow returns 28 from step 609 to step 601. If the node count is zero, flow proceeds to step 29 610 to send a channel release packet to the isochronous resource manager 3o 1 OE to restore the ownership of the assigned channel, and concludes the 31 routine with step 61 1 by clearing the contents of the appropriate channel 32 entry of allocation table 20.
The operation of the asynchronous transactions will be fully 2 understood by the following description with the aid of the sequence diagrams 3 of Figs. 7 to 10.
4 In Fig. 7, when the application layer of source node 1 OA generates IP
multicast data 71, its transaction layer sends an asynchronous-mode channel 6 setup packet 72 to the multicast manager 1 OD. In response, the multicast manager searches the channel allocation table 20 and sends a channel request 8 73 to the isochronous resource manager 1 OE if no channel number is assigned 9 to the multicast address sent with the setup packet from node 1 OA. If the source node 1 OA is the first to send the asynchronous-mode channel setup ~ 1 packet, a channel number is assigned and informed to the multicast manager ~2 1 OD via a reply packet 74. Multicast manager 1 OD sets a u1 " into the node ~3 count field of the allocation table and sends a reply packet 75 to the source ~4 node 1 OA to inform it of the assigned channel number. Source node 1 OA
sends asynchronous stream packets 76 during fairness intervals to the application layer of destination node 1 OC, using the assigned channel.
17 In Fig. 8, with an asynchronous channel being established as described 18 above, if the application layer of another source node generates IP
multicast 19 data 81, its transaction layer sends an asynchronous-mode channel setup packet 82 to the multicast manager 1 OD, containing the same multicast 2~ address as that used by the node 1 OA. In response, the multicast manager 22 searches the channel allocation table 20, knows that the multicast address just 23 received is already assigned a channel number, increments the node count by 24 one and sends a reply packet 83 to the new source node to inform it of the already assigned channel number. The new source node sends asynchronous 26 stream packets 84 during fairness intervals to the application layer of 2~ destination node 1 OC, using the assigned channel.
28 In Fig. 9, when the application layer of destination node 1 OC gives an 29 indication 91 to the transaction layer that IP multicast data be received from a 3o source node, the transaction layer sends an asynchronous-mode channel setup 31 packet 92 to the multicast manager 1 OD, containing a multicast address. In 32 response, the multicast manager searches the channel allocation table 20 and sends a channel request 93 to the isochronous resource manager 1 OE if no 2 channel number is assigned to the multicast address sent with the setup packet 3 from node 1 OC. If the destination node 1 OC is the first to send the 4 asynchronous-mode channel setup packet, a channel number is assigned and informed to the multicast manager 1 OD via a reply packet 94. Multicast 6 manager 1 OD sets a "1 " into the node count field of the allocation table and sends a reply packet 95 to the destination node 1 OC to inform it of the 8 assigned channel number. Destination node 1 OC is now ready to receive 9 asynchronous stream packets which contains the channel number indicated by the reply packet 95 from the multicast manager 1 OE.
In Fig. 10, when the application layer of another destination node gives ~2 an indication 1 O1 to its transaction layer that IP multicast data be received 13 from a source node, the transaction layer sends an asynchronous-mode channel setup packet 102 to the multicast manager 1 OD, containing a multicast address. In response, the multicast manager searches the channel i6 allocation table 20 and knows that the multicast address just received is 17 already assigned a channel number, and it increments the node count by one ~ 8 and sends a reply packet 103 to the new destination node to inform it of the 19 already assigned channel number.
2o The value in the node count field 23 of allocation table 20 in the 21 multicast manager 1 OD is decremented by one in response to an 22 asynchronous-mode channel release packet received from the transaction layer 23 of a source node if asynchronous stream packets are not transmitted for a 24 predetermined interval or from the transaction layer of a destination node if it is notified with an end-of-communication indication from the application layer 26 of the node. When the node count value is reduced to zero, the multicast 2'7 manager requests the isochronous resource manager to release the 28 asynchronous multicast channel.
29 Figs. 1 1 A and 1 1 B are the flowcharts of the operation of the link layer of source node 1 OA when transmission of multicast isochronous packets is 31 initiated from the application layer of the node, using a bandwidth control 32 protocol such as RSVP (resource reservation protocol). Fig. 12 is the flowchart of the operation of the link layer of destination node 1 OC when 2 reception of such isochronous packets is requested from the application layer 3 of the node 1 OC.
In Fig. 1 1 A, the application layer of node 1 OA sends a message known as "path" message to the application layer of destination node 1 OC to inform 6 it of path data of the source-destination communication link (step 1 1 O1 ).
7 In Fig. 12, when the application layer of node 1 OC receives the path 8 message from the source node 1 OA, it applies a session (isochronous-mode) 9 channel setup indication to the link layer (step 1201 ). When the link layer 1 o receives this session setup indication (step 1202), it sends a session setup ~ 1 request to the multicast manager 1 OD by setting its control register 30 with 12 an isochronous channel setup indication (step 1203). If the request is ~ 3 granted, a channel number is sent from the multicast manager with a reply message which is set into the control register 40 of node 1 OC (step 1204).
Therefore, a channel setup indication, session data (destination node address, 16 protocol number and port number) and the assigned channel number are respectively stored in the fields 41, 42 and 43 of control register 40.
18 Flow proceeds to step 1205 to send a reservation message from the application layer of destination node 1 OC to the application layer of source node 1 OA, indicating the bandwidth the destination node wishes to receive 2~ through the assigned channel. Reservation is "refreshed" by repeatedly 22 transmitting reservation messages. For this purpose, a timer is started (step 23 1206) following the execution of step 1205.
24 At step 1207, the reception of a session release indication from the application layer is checked. If the decision at step 1207 is negative, the timer 26 is checked at step 1208 for expiration. When the timer expires, flow returns 27 from step 1208 to step 1205 to repeat the transmission of a reservation 28 message and start the timer again.
29 When no reservation message is transmitted during the time-out period of the timer, a session release indication will be issued from the application 31 layer and flow exits the loop and enters step 1209 to terminate the routine by 32 sending a session release request from the destination node 1 OC to the multicast manager 1 OD by appropriately setting its control register 30.
2 Returning to Fig. 1 1 A, a reservation message from the destination node 3 is received by the application layer of the source node and a session channel setup indication is issued to the link layer (step 1 102).
At step 1 103, the source node 1 OA sends a session channel setup 6 request to the multicast manager 1 OD for requesting the bandwidth desired '7 by the destination node 1 OC. This is done by setting the control register 8 of manager 1 OD with the session data and the bandwidth data received with 9 the reservation message from the destination node. If the request is granted, a reply packet is transmitted from the multicast manager to the source node 11 where the control register 40 is set with the assigned channel number (step 12 1 104).
13 At step 1 105, the source node begins sending isochronous packets 14 with the assigned channel number to the destination node.
~5 After sending isochronous packets, the source node checks to see if session release indication is received from its application layer (step 1 1 1 1, 1'7 Fig. 1 1 B). If so, flow proceeds to step 1 1 12 to send a session release request 18 to the multicast manager 1 OD by setting its control register 30 with a session 19 release indication and the session data.
2o The operation of the multicast manager 1 OD in response to the 21 request for isochronous packets will be explained with the aid of the flowchart 22 of Fig. 1 3.
23 The operation of multicast manager 1 OD begins with step 1301 by 24 checking the receipt of a session setup request or a session release request 25 from the destination node 1 OC by examining its control register 30. When a 26 session setup request is received from the destination node 1 OC, flow 2~ proceeds from step 1 301 to step 1302 to search through the channel 28 allocation table 20 for a channel entry in which the session data now stored in 29 the control register 30 are registered. If they are not registered in the 30 allocation table (step 1303), flow proceeds to step 1304 to send a request 31 to the isochronous resource manager 1 OE to acquire ownership of a channel 32 number. When a channel number is granted from the isochronous resource manger, the multicast manager proceeds to step 1 305 to set an isochronous 2 packet type indication into the packet type field 21 of the allocation-table 3 channel entry corresponding to the assigned channel number, a N1 " into the 4 node count field 23 and session data into the address field 24 (step 1306).
Following the execution of step 1305, flow proceeds to step 1306 to send a 6 reply message to the destination node by setting its control register 40 with the assigned channel number, and then returns to the beginning of the routine 8 for looping steps 1 301 and 1310 to check for the arrival of a further request 9 from a source or a destination node.
If the decision at step 1 303 is affirmative in response to receipt of a subsequent packet from another destination node, the node count value of the 12 allocation table 20 is incremented by one at step 1307 and a reply message ~3 containing the assigned channel number is set into the control register 40 of 14 the requesting destination node (step 1 306).
I S The application layer at the destination node 1 OC will then repeatedly 16 send a reservation message to the application layer of source node 1 OA to 17 inform the bandwidth the destination node is ready to receive (step 1206, 18 Fig. 12). In response to each reservation message, the source node 1 OA
sends a session setup request to the multicast manager 1 OD according to the resource reservation protocol (steps 1 1 O1 to 1 103, Fig. 1 1 A).
21 The session setup request from the source node 1 OA is detected at 22 step 1310. Since the resource reservation protocol is a receiver-oriented 23 protocol, this request contains the bandwidth the destination node 1 OC is 24 ready to receive as well as the session data. In response to this request, the multicast manager 1 OD proceeds to step 131 1 to compare the bandwidth 26 requested by the destination node with a value currently set in the bandwidth 2'7 field of the corresponding entry of allocation table 20.
28 If the source node 1 OA is the first to send a path message for the 29 current session, the value set in the bandwidth field of the corresponding entry is zero, and hence the decision at step 1 31 1 is negative and flow proceeds to 3 ~ step 1312 to secure ownership of the requested bandwidth from the 32 isochronous resource manager 1 OE. When the requested bandwidth is 1 granted, the bandwidth field of the corresponding allocation channel entry is 2 updated with the granted channel resource (step 131 3). Flow proceeds to 3 step 1306 to send a reply message to the source node 1 OA to inform the assigned channel number. This channel number and the corresponding session data are set into the control register 40 of the source node.
6 If the source node 1 OA is not the first to send a path message. the compared values at step 1 31 1 may be equal to each other, and flow returns 8 from step 131 1 to step 1306 to send a reply message to the source node to 9 indicate the channel number which has already been assigned. If the requested 1o bandwidth is greater than the currently allocated value, the multicast manager t i determines the deficit channel resource and request it from the isochronous ~2 resource manager (step 1312), updates the bandwidth field of the 13 corresponding channel entry (step 1 313) and informs the source node of the ~a channel number and the session data (step 1306). If the requested ~5 bandwidth is smaller than the currently allocated value, the multicast manager determines a surplus value and restores the ownership of the surplus resource 17 to the isochronous resource manager (step 1312) and updates the bandwidth ~8 field of the corresponding channel entry (step 1313) and proceeds to step 19 1 306 to inform the channel number and session data .
2o At the end of a session, either a source node or a destination node 21 issues a session release request. After looping steps 1301 and 1310, the 22 multicast manager 1 OD proceeds exits from step 1301 in response to receipt 23 of a session release request from a destination node or from step 1310 in 24 response to receipt of a session release request from a source node and enters 25 step 1 314 to decrement the node count value by one.
26 At step 131 5, the node count is examined. If it is not equal to zero, 27 flow returns to step 1 301. Otherwise, flow proceeds to step 1 316 to send a 28 channel release message to the isochronous resource manager 1 OE to restore 29 the ownership of the assigned channel, and terminates the routine after 3o clearing the corresponding channel entry of the allocation table 20 (step 31 1 31 7).
32 The operation of the isochronous transactions will be fully 1 understood by the following description with the aid of the sequence diagrams 2 of Figs. 14 to 16.
3 In Fig. 14, the application layer of source node 1 OA initially transmits a "path" message 1401 to the application layer of destination node 1 OC, which responds by issuing to its link layer a session setup indication 1402.
6 The link layer of destination node 1 OC sends a session (isochronous-mode) '7 channel setup packet 1403 to the multicast manager 1 OD. In response, the 8 multicast manager searches the channel allocation table 20 and sends a 9 channel request 1404 to the isochronous resource manager 1 OE since no channel number is assigned to the session. A channel number is assigned by 11 the isochronous resource manager and informed to the multicast manager 1 OD
12 via a reply packet 1 405. Multicast manager 1 OD sets a "1 " into the node ~3 count field of allocation table 20 and sends a reply packet 1406 to the destination node 1 OC to inform it of the assigned channel number. A
reservation message 1407 is then sent from the application layer of destination node 1 OC to the application layer of source node 1 OA to inform it of the bandwidth the destination node wishes to receive.
~ 8 The application layer of source node 1 OA issues a session setup 19 indication 1408 to its link layer, which responds with the transmission of a 2o session channel setup packet 1409 to the multicast manager for requesting 21 the bandwidth desired by the destination node 1 OC. Multicast manager 1 OD
22 requests with a message 1410 to the isochronous resource manager to obtain 23 the necessary bandwidth with a reply message 1 41 1. The allocated 24 bandwidth is informed with a reply packet 1412 to the requesting source node 1 OA, whose application layer is now conditioned to send isochronous 26 packets 141 3 at constant rate to the application layer of destination node 2'7 1 OC. Destination node 1 OC receives isochronous packets if they contain the 28 same channel number and session values as those indicated by the reply 29 packet 1406.
3o In Fig. 1 5, with a session being established as described above, if the 31 application layer of another source node sends a "path" message 1 501 to the 32 destination node 1 OC, the link layer of destination node 1 OC sends a session 1 channel setup packet 1503 to the multicast manager 1 OD in response to a 2 session setup indication 1502 from the application layer of node 1 OC.
3 Multicast manager then searches the channel allocation table 20 and sends no 4 channel request to the isochronous resource manager since a channel number has been assigned to the session. Multicast manager 1 OD increments the node 6 count by one and sends a reply packet 1 504 to the destination node 1 OC to 7 inform it of the assigned channel number and the session values (source node 8 address, protocol number and port number). A reservation message 1 505 is 9 then sent from the application layer of destination node 1 OC to the application layer of source node to inform it of the bandwidth it wishes to receive. The application layer of source node responds with a session setup 12 indication 1506 issued to its link layer, which responds with the transmission ~ 3 of a session channel setup packet 1 507 to the multicast manager for 14 requesting the bandwidth desired by the destination node 1 OC. Multicast manager 1 OD requests with a message 1508 to the isochronous resource manager to increase or decrease the allocated bandwidth depending on the bandwidth requested by the destination node. The reallocated bandwidth is 18 communicated with a reply message 1509 to the source node, whose application layer is now conditioned to send isochronous packets 1510 at 2o constant rate to the application layer of destination node. Destination node 2i receives isochronous packets if they contain the same channel number and 22 session values as those indicated by the reply packet 1504.
23 As illustrated in Fig. 16, a session release indication 1601 is issued 24 from the application layer of a destination node to its link layer, which responds with the transmission of a session release packet 1602 to the 26 multicast manager 1 OD. The node count value at the multicast manager is 2'7 decremented by one. The application layer at a source node monitors the 28 arrival of reservation messages. If they do not arrive for a predetermined 29 interval, the source node application layer issues a session release indication 1603 to its link layer, which responds with the transmission of a session 3 ~ release packet 1604 to the multicast manager, which decrements the node 32 count value by one. If the node count value reduces to zero, the multicast 1 manager sends a channel release packet 1605 to the isochronous resource 2 manager to release the ownership of the allocated channel number and 3 bandwidth.
4 In Fig. 7, when the application layer of source node 1 OA generates IP
multicast data 71, its transaction layer sends an asynchronous-mode channel 6 setup packet 72 to the multicast manager 1 OD. In response, the multicast manager searches the channel allocation table 20 and sends a channel request 8 73 to the isochronous resource manager 1 OE if no channel number is assigned 9 to the multicast address sent with the setup packet from node 1 OA. If the source node 1 OA is the first to send the asynchronous-mode channel setup ~ 1 packet, a channel number is assigned and informed to the multicast manager ~2 1 OD via a reply packet 74. Multicast manager 1 OD sets a u1 " into the node ~3 count field of the allocation table and sends a reply packet 75 to the source ~4 node 1 OA to inform it of the assigned channel number. Source node 1 OA
sends asynchronous stream packets 76 during fairness intervals to the application layer of destination node 1 OC, using the assigned channel.
17 In Fig. 8, with an asynchronous channel being established as described 18 above, if the application layer of another source node generates IP
multicast 19 data 81, its transaction layer sends an asynchronous-mode channel setup packet 82 to the multicast manager 1 OD, containing the same multicast 2~ address as that used by the node 1 OA. In response, the multicast manager 22 searches the channel allocation table 20, knows that the multicast address just 23 received is already assigned a channel number, increments the node count by 24 one and sends a reply packet 83 to the new source node to inform it of the already assigned channel number. The new source node sends asynchronous 26 stream packets 84 during fairness intervals to the application layer of 2~ destination node 1 OC, using the assigned channel.
28 In Fig. 9, when the application layer of destination node 1 OC gives an 29 indication 91 to the transaction layer that IP multicast data be received from a 3o source node, the transaction layer sends an asynchronous-mode channel setup 31 packet 92 to the multicast manager 1 OD, containing a multicast address. In 32 response, the multicast manager searches the channel allocation table 20 and sends a channel request 93 to the isochronous resource manager 1 OE if no 2 channel number is assigned to the multicast address sent with the setup packet 3 from node 1 OC. If the destination node 1 OC is the first to send the 4 asynchronous-mode channel setup packet, a channel number is assigned and informed to the multicast manager 1 OD via a reply packet 94. Multicast 6 manager 1 OD sets a "1 " into the node count field of the allocation table and sends a reply packet 95 to the destination node 1 OC to inform it of the 8 assigned channel number. Destination node 1 OC is now ready to receive 9 asynchronous stream packets which contains the channel number indicated by the reply packet 95 from the multicast manager 1 OE.
In Fig. 10, when the application layer of another destination node gives ~2 an indication 1 O1 to its transaction layer that IP multicast data be received 13 from a source node, the transaction layer sends an asynchronous-mode channel setup packet 102 to the multicast manager 1 OD, containing a multicast address. In response, the multicast manager searches the channel i6 allocation table 20 and knows that the multicast address just received is 17 already assigned a channel number, and it increments the node count by one ~ 8 and sends a reply packet 103 to the new destination node to inform it of the 19 already assigned channel number.
2o The value in the node count field 23 of allocation table 20 in the 21 multicast manager 1 OD is decremented by one in response to an 22 asynchronous-mode channel release packet received from the transaction layer 23 of a source node if asynchronous stream packets are not transmitted for a 24 predetermined interval or from the transaction layer of a destination node if it is notified with an end-of-communication indication from the application layer 26 of the node. When the node count value is reduced to zero, the multicast 2'7 manager requests the isochronous resource manager to release the 28 asynchronous multicast channel.
29 Figs. 1 1 A and 1 1 B are the flowcharts of the operation of the link layer of source node 1 OA when transmission of multicast isochronous packets is 31 initiated from the application layer of the node, using a bandwidth control 32 protocol such as RSVP (resource reservation protocol). Fig. 12 is the flowchart of the operation of the link layer of destination node 1 OC when 2 reception of such isochronous packets is requested from the application layer 3 of the node 1 OC.
In Fig. 1 1 A, the application layer of node 1 OA sends a message known as "path" message to the application layer of destination node 1 OC to inform 6 it of path data of the source-destination communication link (step 1 1 O1 ).
7 In Fig. 12, when the application layer of node 1 OC receives the path 8 message from the source node 1 OA, it applies a session (isochronous-mode) 9 channel setup indication to the link layer (step 1201 ). When the link layer 1 o receives this session setup indication (step 1202), it sends a session setup ~ 1 request to the multicast manager 1 OD by setting its control register 30 with 12 an isochronous channel setup indication (step 1203). If the request is ~ 3 granted, a channel number is sent from the multicast manager with a reply message which is set into the control register 40 of node 1 OC (step 1204).
Therefore, a channel setup indication, session data (destination node address, 16 protocol number and port number) and the assigned channel number are respectively stored in the fields 41, 42 and 43 of control register 40.
18 Flow proceeds to step 1205 to send a reservation message from the application layer of destination node 1 OC to the application layer of source node 1 OA, indicating the bandwidth the destination node wishes to receive 2~ through the assigned channel. Reservation is "refreshed" by repeatedly 22 transmitting reservation messages. For this purpose, a timer is started (step 23 1206) following the execution of step 1205.
24 At step 1207, the reception of a session release indication from the application layer is checked. If the decision at step 1207 is negative, the timer 26 is checked at step 1208 for expiration. When the timer expires, flow returns 27 from step 1208 to step 1205 to repeat the transmission of a reservation 28 message and start the timer again.
29 When no reservation message is transmitted during the time-out period of the timer, a session release indication will be issued from the application 31 layer and flow exits the loop and enters step 1209 to terminate the routine by 32 sending a session release request from the destination node 1 OC to the multicast manager 1 OD by appropriately setting its control register 30.
2 Returning to Fig. 1 1 A, a reservation message from the destination node 3 is received by the application layer of the source node and a session channel setup indication is issued to the link layer (step 1 102).
At step 1 103, the source node 1 OA sends a session channel setup 6 request to the multicast manager 1 OD for requesting the bandwidth desired '7 by the destination node 1 OC. This is done by setting the control register 8 of manager 1 OD with the session data and the bandwidth data received with 9 the reservation message from the destination node. If the request is granted, a reply packet is transmitted from the multicast manager to the source node 11 where the control register 40 is set with the assigned channel number (step 12 1 104).
13 At step 1 105, the source node begins sending isochronous packets 14 with the assigned channel number to the destination node.
~5 After sending isochronous packets, the source node checks to see if session release indication is received from its application layer (step 1 1 1 1, 1'7 Fig. 1 1 B). If so, flow proceeds to step 1 1 12 to send a session release request 18 to the multicast manager 1 OD by setting its control register 30 with a session 19 release indication and the session data.
2o The operation of the multicast manager 1 OD in response to the 21 request for isochronous packets will be explained with the aid of the flowchart 22 of Fig. 1 3.
23 The operation of multicast manager 1 OD begins with step 1301 by 24 checking the receipt of a session setup request or a session release request 25 from the destination node 1 OC by examining its control register 30. When a 26 session setup request is received from the destination node 1 OC, flow 2~ proceeds from step 1 301 to step 1302 to search through the channel 28 allocation table 20 for a channel entry in which the session data now stored in 29 the control register 30 are registered. If they are not registered in the 30 allocation table (step 1303), flow proceeds to step 1304 to send a request 31 to the isochronous resource manager 1 OE to acquire ownership of a channel 32 number. When a channel number is granted from the isochronous resource manger, the multicast manager proceeds to step 1 305 to set an isochronous 2 packet type indication into the packet type field 21 of the allocation-table 3 channel entry corresponding to the assigned channel number, a N1 " into the 4 node count field 23 and session data into the address field 24 (step 1306).
Following the execution of step 1305, flow proceeds to step 1306 to send a 6 reply message to the destination node by setting its control register 40 with the assigned channel number, and then returns to the beginning of the routine 8 for looping steps 1 301 and 1310 to check for the arrival of a further request 9 from a source or a destination node.
If the decision at step 1 303 is affirmative in response to receipt of a subsequent packet from another destination node, the node count value of the 12 allocation table 20 is incremented by one at step 1307 and a reply message ~3 containing the assigned channel number is set into the control register 40 of 14 the requesting destination node (step 1 306).
I S The application layer at the destination node 1 OC will then repeatedly 16 send a reservation message to the application layer of source node 1 OA to 17 inform the bandwidth the destination node is ready to receive (step 1206, 18 Fig. 12). In response to each reservation message, the source node 1 OA
sends a session setup request to the multicast manager 1 OD according to the resource reservation protocol (steps 1 1 O1 to 1 103, Fig. 1 1 A).
21 The session setup request from the source node 1 OA is detected at 22 step 1310. Since the resource reservation protocol is a receiver-oriented 23 protocol, this request contains the bandwidth the destination node 1 OC is 24 ready to receive as well as the session data. In response to this request, the multicast manager 1 OD proceeds to step 131 1 to compare the bandwidth 26 requested by the destination node with a value currently set in the bandwidth 2'7 field of the corresponding entry of allocation table 20.
28 If the source node 1 OA is the first to send a path message for the 29 current session, the value set in the bandwidth field of the corresponding entry is zero, and hence the decision at step 1 31 1 is negative and flow proceeds to 3 ~ step 1312 to secure ownership of the requested bandwidth from the 32 isochronous resource manager 1 OE. When the requested bandwidth is 1 granted, the bandwidth field of the corresponding allocation channel entry is 2 updated with the granted channel resource (step 131 3). Flow proceeds to 3 step 1306 to send a reply message to the source node 1 OA to inform the assigned channel number. This channel number and the corresponding session data are set into the control register 40 of the source node.
6 If the source node 1 OA is not the first to send a path message. the compared values at step 1 31 1 may be equal to each other, and flow returns 8 from step 131 1 to step 1306 to send a reply message to the source node to 9 indicate the channel number which has already been assigned. If the requested 1o bandwidth is greater than the currently allocated value, the multicast manager t i determines the deficit channel resource and request it from the isochronous ~2 resource manager (step 1312), updates the bandwidth field of the 13 corresponding channel entry (step 1 313) and informs the source node of the ~a channel number and the session data (step 1306). If the requested ~5 bandwidth is smaller than the currently allocated value, the multicast manager determines a surplus value and restores the ownership of the surplus resource 17 to the isochronous resource manager (step 1312) and updates the bandwidth ~8 field of the corresponding channel entry (step 1313) and proceeds to step 19 1 306 to inform the channel number and session data .
2o At the end of a session, either a source node or a destination node 21 issues a session release request. After looping steps 1301 and 1310, the 22 multicast manager 1 OD proceeds exits from step 1301 in response to receipt 23 of a session release request from a destination node or from step 1310 in 24 response to receipt of a session release request from a source node and enters 25 step 1 314 to decrement the node count value by one.
26 At step 131 5, the node count is examined. If it is not equal to zero, 27 flow returns to step 1 301. Otherwise, flow proceeds to step 1 316 to send a 28 channel release message to the isochronous resource manager 1 OE to restore 29 the ownership of the assigned channel, and terminates the routine after 3o clearing the corresponding channel entry of the allocation table 20 (step 31 1 31 7).
32 The operation of the isochronous transactions will be fully 1 understood by the following description with the aid of the sequence diagrams 2 of Figs. 14 to 16.
3 In Fig. 14, the application layer of source node 1 OA initially transmits a "path" message 1401 to the application layer of destination node 1 OC, which responds by issuing to its link layer a session setup indication 1402.
6 The link layer of destination node 1 OC sends a session (isochronous-mode) '7 channel setup packet 1403 to the multicast manager 1 OD. In response, the 8 multicast manager searches the channel allocation table 20 and sends a 9 channel request 1404 to the isochronous resource manager 1 OE since no channel number is assigned to the session. A channel number is assigned by 11 the isochronous resource manager and informed to the multicast manager 1 OD
12 via a reply packet 1 405. Multicast manager 1 OD sets a "1 " into the node ~3 count field of allocation table 20 and sends a reply packet 1406 to the destination node 1 OC to inform it of the assigned channel number. A
reservation message 1407 is then sent from the application layer of destination node 1 OC to the application layer of source node 1 OA to inform it of the bandwidth the destination node wishes to receive.
~ 8 The application layer of source node 1 OA issues a session setup 19 indication 1408 to its link layer, which responds with the transmission of a 2o session channel setup packet 1409 to the multicast manager for requesting 21 the bandwidth desired by the destination node 1 OC. Multicast manager 1 OD
22 requests with a message 1410 to the isochronous resource manager to obtain 23 the necessary bandwidth with a reply message 1 41 1. The allocated 24 bandwidth is informed with a reply packet 1412 to the requesting source node 1 OA, whose application layer is now conditioned to send isochronous 26 packets 141 3 at constant rate to the application layer of destination node 2'7 1 OC. Destination node 1 OC receives isochronous packets if they contain the 28 same channel number and session values as those indicated by the reply 29 packet 1406.
3o In Fig. 1 5, with a session being established as described above, if the 31 application layer of another source node sends a "path" message 1 501 to the 32 destination node 1 OC, the link layer of destination node 1 OC sends a session 1 channel setup packet 1503 to the multicast manager 1 OD in response to a 2 session setup indication 1502 from the application layer of node 1 OC.
3 Multicast manager then searches the channel allocation table 20 and sends no 4 channel request to the isochronous resource manager since a channel number has been assigned to the session. Multicast manager 1 OD increments the node 6 count by one and sends a reply packet 1 504 to the destination node 1 OC to 7 inform it of the assigned channel number and the session values (source node 8 address, protocol number and port number). A reservation message 1 505 is 9 then sent from the application layer of destination node 1 OC to the application layer of source node to inform it of the bandwidth it wishes to receive. The application layer of source node responds with a session setup 12 indication 1506 issued to its link layer, which responds with the transmission ~ 3 of a session channel setup packet 1 507 to the multicast manager for 14 requesting the bandwidth desired by the destination node 1 OC. Multicast manager 1 OD requests with a message 1508 to the isochronous resource manager to increase or decrease the allocated bandwidth depending on the bandwidth requested by the destination node. The reallocated bandwidth is 18 communicated with a reply message 1509 to the source node, whose application layer is now conditioned to send isochronous packets 1510 at 2o constant rate to the application layer of destination node. Destination node 2i receives isochronous packets if they contain the same channel number and 22 session values as those indicated by the reply packet 1504.
23 As illustrated in Fig. 16, a session release indication 1601 is issued 24 from the application layer of a destination node to its link layer, which responds with the transmission of a session release packet 1602 to the 26 multicast manager 1 OD. The node count value at the multicast manager is 2'7 decremented by one. The application layer at a source node monitors the 28 arrival of reservation messages. If they do not arrive for a predetermined 29 interval, the source node application layer issues a session release indication 1603 to its link layer, which responds with the transmission of a session 3 ~ release packet 1604 to the multicast manager, which decrements the node 32 count value by one. If the node count value reduces to zero, the multicast 1 manager sends a channel release packet 1605 to the isochronous resource 2 manager to release the ownership of the allocated channel number and 3 bandwidth.
Claims (11)
1. A communication network comprising:
a plurality of network nodes connected to a serial bus, each of the nodes functioning as a source node or a destination node for signaling a channel setup request containing an identification of a multicast communication and a channel release request; and a multicast manager connected to said serial bus, said multicast manager comprising a channel allocation table having a plurality of entries, said multicast manager being responsive to said channel setup request for making a search through said table, setting a node count value to 1 in an entry of said table, acquiring ownership of a channel number from an isochronous resource manager and mapping the acquired channel number to the identification of said multicast communication in said table entry if said search indicates that no channel number is mapped in said table entry or incrementing the node count value of said table entry by 1 if said search indicates that a channel number is mapped to the identification of said multicast communication, and signaling a reply message on said bus, said source node being responsive to said reply message from the multicast manager for multicasting packets to said bus, said multicast manager being responsive to said channel release request for decrementing the node count value of said table entry by 1, said multicast manager restoring the ownership of said channel number to said isochronous resource manager and clearing said table entry when said node count value equals zero.
a plurality of network nodes connected to a serial bus, each of the nodes functioning as a source node or a destination node for signaling a channel setup request containing an identification of a multicast communication and a channel release request; and a multicast manager connected to said serial bus, said multicast manager comprising a channel allocation table having a plurality of entries, said multicast manager being responsive to said channel setup request for making a search through said table, setting a node count value to 1 in an entry of said table, acquiring ownership of a channel number from an isochronous resource manager and mapping the acquired channel number to the identification of said multicast communication in said table entry if said search indicates that no channel number is mapped in said table entry or incrementing the node count value of said table entry by 1 if said search indicates that a channel number is mapped to the identification of said multicast communication, and signaling a reply message on said bus, said source node being responsive to said reply message from the multicast manager for multicasting packets to said bus, said multicast manager being responsive to said channel release request for decrementing the node count value of said table entry by 1, said multicast manager restoring the ownership of said channel number to said isochronous resource manager and clearing said table entry when said node count value equals zero.
2. The communication network of claim 1, wherein said channel setup request is an asynchronous channel setup request containing a multicast address, and wherein said manager maps said acquired channel number to the multicast address in said table entry, and wherein said source node multicasts asynchronous stream packets in response to said reply message.
3. The communication network of claim 2, wherein said source node is arranged to signal said channel release request on said serial bus if there is no asynchronous stream packet to be sent to said serial bus for a predetermined period of time.
4. The communication network of claim 1, wherein said channel setup request is an isochronous channel setup request containing an identification of session data, and wherein said manager maps said acquired channel number to the multicast address in said table entry.
5. The communication network of claim 4, wherein said multicast manager is responsive to said isochronous channel setup request for acquiring ownership of a channel resource from said isochronous resource manager and mapping a channel number of said acquired channel resource to the identification of the session data in said table entry if said search indicates that no channel number is mapped to the identification of said session data or incrementing the node count value by 1 if a channel number is mapped to the identification of said session data, and signaling a reply message on said bus.
6. The communication network of claim 1, wherein each of the nodes functions as a source node for signaling a path message indicating an identification of session data and functions as a destination node for receiving said path message and signaling a first isochronous channel setup request containing the session data and the identification of the session data indicated in the path message from said source node, each of said source and destination nodes signaling an isochronous channel release request; and said multicast manager being responsive to said first isochronous channel setup request for making a search through said table, setting a node count value to 1 in an entry of said table, acquiring ownership of an isochronous channel number from said isochronous resource manager and mapping the acquired channel number to the identification of the session data in said table entry if said search indicates that no channel number is mapped in said table entry or incrementing the node count value of said table entry by 1 if said search indicates that a channel number is mapped to the identification of said session data, and signaling a first reply message, said destination node being responsive to said first reply message for signaling a reservation message indicating a desired channel resource, and said source node being responsive to said reservation message for signaling a second isochronous channel setup request containing the channel resource indicated in said reservation message, said multicast manager being responsive to said second isochronous channel setup request for determining necessary channel resource from a resource value in said table entry, acquiring ownership of the necessary channel resource from said isochronous resource manager and updating the resource value of said table entry with the acquired channel resource and signaling a second reply message on said bus, said source node being responsive to said second reply message from the multicast manager for multicasting isochronous packets to said bus.
7. The communication network of claim 6, wherein said source node is arranged to signal said channel release request when said reservation message is not produced on said bus for a predetermined interval of time.
8. A communication method for a network including a plurality of network nodes connected to a serial bus, one of said nodes comprising a channel allocation table having a plurality of entries, the method comprising the steps of:
a) signaling a request for a communication channel from one of said nodes either functioning as a source node or a destination node;
b) making a search through said table in response to the request;
c) if no channel number is mapped in an entry of said table to an identification of multicast communication contained in said request, setting a node count value to 1 in said table entry, acquiring ownership of a channel number from an isochronous resource manager and mapping the acquired channel number to the identification of the multicast communication in said table entry;
d) if a channel number is mapped to the identification of said multicast communication, incrementing the node count value by 1 in said table entry;
e) multicasting packets from said source node to said bus;
f) requesting release of the channel from one of said nodes;
g) decrementing the node count value of said table entry by 1; and h) repeating steps (a) to (g), restoring the ownership of said channel number to said isochronous resource manager and clearing said table entry when said node count value equals zero.
a) signaling a request for a communication channel from one of said nodes either functioning as a source node or a destination node;
b) making a search through said table in response to the request;
c) if no channel number is mapped in an entry of said table to an identification of multicast communication contained in said request, setting a node count value to 1 in said table entry, acquiring ownership of a channel number from an isochronous resource manager and mapping the acquired channel number to the identification of the multicast communication in said table entry;
d) if a channel number is mapped to the identification of said multicast communication, incrementing the node count value by 1 in said table entry;
e) multicasting packets from said source node to said bus;
f) requesting release of the channel from one of said nodes;
g) decrementing the node count value of said table entry by 1; and h) repeating steps (a) to (g), restoring the ownership of said channel number to said isochronous resource manager and clearing said table entry when said node count value equals zero.
9. The communication method of claim 8, wherein said request is for an asynchronous channel and said identification is a multicast address of said multicast communication.
10. The communication method of claim 9, further comprising the steps of:
A) signaling a request for setting up an isochronous channel from one of said nodes either functioning as a source node or a destination node, said request containing an identification of session data;
B) making a search through said table in response to the request;
C) if no channel number is mapped to said identification of session data, setting a node count value to 1 in an entry of said table, acquiring ownership of an isochronous channel resource and a channel number of said resource from said isochronous resource manager, and mapping said channel number and said channel resource to the identification of session data in said table entry;
D) if a channel number is mapped to said identification of session data, incrementing the node count value of said table entry by 1;
E) multicasting isochronous packets from said source node to said bus;
F) signaling a request for releasing said channel from one of said nodes;
G) decrementing the node count value of said table entry by 1; and H) repeating steps (A) to (G), restoring the ownership of said channel resource and said channel number to said isochronous resource manager and clearing the corresponding entry of said table when said node count value equals zero.
A) signaling a request for setting up an isochronous channel from one of said nodes either functioning as a source node or a destination node, said request containing an identification of session data;
B) making a search through said table in response to the request;
C) if no channel number is mapped to said identification of session data, setting a node count value to 1 in an entry of said table, acquiring ownership of an isochronous channel resource and a channel number of said resource from said isochronous resource manager, and mapping said channel number and said channel resource to the identification of session data in said table entry;
D) if a channel number is mapped to said identification of session data, incrementing the node count value of said table entry by 1;
E) multicasting isochronous packets from said source node to said bus;
F) signaling a request for releasing said channel from one of said nodes;
G) decrementing the node count value of said table entry by 1; and H) repeating steps (A) to (G), restoring the ownership of said channel resource and said channel number to said isochronous resource manager and clearing the corresponding entry of said table when said node count value equals zero.
11. The communication method of claim 9, further comprising the steps of:
A) sending a path message indicating an identification of session data from one of said nodes when functioning as a source node;
B) receiving, at one of said nodes when functioning as a destination node, said path message and signaling a first request for setting up an isochronous channel;
C) making a search through said table in response to the path message;
D) if no channel number is mapped to said identification of session data, setting a node count value to 1 in an entry of said table, acquiring ownership of an isochronous channel number from said isochronous resource manager and mapping the acquired channel number to the identification of session data in said table entry;
E) if a channel number is mapped to said identification of session data, incrementing the node count value of said table entry by 1;
F) sending a reservation message from the destination node to said source node, said message containing a channel resource which the destination node wishes to receive;
G) signaling from said source node a second request containing the channel resource indicated in said reservation message;
H) determining necessary channel resource from the channel resource contained in said second request and from a resource value in said table entry, acquiring ownership of the necessary channel resource from said isochronous resource manager and updating the resource value of the table entry with the acquired channel resource;
I) multicasting isochronous multicast packets from said source node to said bus;
J) signaling from either of said source or destination node a request for releasing the channel;
K) decrementing the node count value of said table entry by 1; and L) repeating steps (A) to (K), restoring the ownership of said channel number and said channel resource to said isochronous resource manager and clearing the corresponding entry of said table when said node count value equals zero.
A) sending a path message indicating an identification of session data from one of said nodes when functioning as a source node;
B) receiving, at one of said nodes when functioning as a destination node, said path message and signaling a first request for setting up an isochronous channel;
C) making a search through said table in response to the path message;
D) if no channel number is mapped to said identification of session data, setting a node count value to 1 in an entry of said table, acquiring ownership of an isochronous channel number from said isochronous resource manager and mapping the acquired channel number to the identification of session data in said table entry;
E) if a channel number is mapped to said identification of session data, incrementing the node count value of said table entry by 1;
F) sending a reservation message from the destination node to said source node, said message containing a channel resource which the destination node wishes to receive;
G) signaling from said source node a second request containing the channel resource indicated in said reservation message;
H) determining necessary channel resource from the channel resource contained in said second request and from a resource value in said table entry, acquiring ownership of the necessary channel resource from said isochronous resource manager and updating the resource value of the table entry with the acquired channel resource;
I) multicasting isochronous multicast packets from said source node to said bus;
J) signaling from either of said source or destination node a request for releasing the channel;
K) decrementing the node count value of said table entry by 1; and L) repeating steps (A) to (K), restoring the ownership of said channel number and said channel resource to said isochronous resource manager and clearing the corresponding entry of said table when said node count value equals zero.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP05516698A JP3171241B2 (en) | 1998-03-06 | 1998-03-06 | Communication method |
| JP10-055166 | 1998-03-06 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2264461A1 CA2264461A1 (en) | 1999-09-06 |
| CA2264461C true CA2264461C (en) | 2003-09-09 |
Family
ID=12991162
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002264461A Expired - Fee Related CA2264461C (en) | 1998-03-06 | 1999-03-05 | Ieee-1394 serial bus network capable of multicast communication |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US6434117B1 (en) |
| EP (1) | EP0940946B1 (en) |
| JP (1) | JP3171241B2 (en) |
| CA (1) | CA2264461C (en) |
| DE (1) | DE69922072T2 (en) |
Families Citing this family (50)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100354740B1 (en) | 1998-10-15 | 2002-12-18 | 삼성전자 주식회사 | Channel extension method for IEEE 1394 serial bus |
| KR100323770B1 (en) * | 1999-03-08 | 2002-02-19 | 서평원 | Channel Structure for Multicast Service, and Method for operating the service using the channel |
| JP3436174B2 (en) | 1999-03-09 | 2003-08-11 | 日本電気株式会社 | Communication method |
| US6810452B1 (en) * | 1999-03-19 | 2004-10-26 | Sony Corporation | Method and system for quarantine during bus topology configuration |
| FI108694B (en) * | 1999-05-24 | 2002-02-28 | Nokia Oyj | connection Handle |
| EP1059588A1 (en) * | 1999-06-09 | 2000-12-13 | Texas Instruments Incorporated | Multi-channel dma with request scheduling |
| US7143166B1 (en) * | 1999-07-12 | 2006-11-28 | Lucent Technologies Inc. | Dynamic bandwidth allocation in a reservation system |
| KR100644559B1 (en) * | 1999-07-26 | 2006-11-13 | 삼성전자주식회사 | Method for allocating channel in device having digital interface |
| US7068674B1 (en) * | 1999-08-23 | 2006-06-27 | Lg Electronics Inc. | Method of controlling connection between nodes in digital interface |
| US6910090B1 (en) | 1999-09-21 | 2005-06-21 | Sony Corporation | Maintaining communications in a bus bridge interconnect |
| US6718282B1 (en) * | 1999-10-20 | 2004-04-06 | Cisco Technology, Inc. | Fault tolerant client-server environment |
| DE60035912T2 (en) | 1999-10-29 | 2008-04-30 | Sony Corp. | Method and system for using a plurality of transmission lines and setting the connection operation method |
| US6728821B1 (en) | 1999-11-29 | 2004-04-27 | Sony Corporation | Method and system for adjusting isochronous bandwidths on a bus |
| US6647020B1 (en) * | 1999-12-17 | 2003-11-11 | Motorola, Inc. | Methods for implementing a talkgroup call in a multicast IP network |
| US20020046357A1 (en) * | 1999-12-28 | 2002-04-18 | Jiandong Huang | Software-based fault tolerant networking using a single LAN |
| JP3454217B2 (en) | 1999-12-28 | 2003-10-06 | 日本電気株式会社 | Communication path control method, device control device, and bridge |
| DE69940781D1 (en) * | 1999-12-30 | 2009-06-04 | Sony Deutschland Gmbh | Interface connection layer device for establishing a distributed network |
| IL150919A0 (en) * | 2000-01-27 | 2003-02-12 | Thomson Licensing Sa | Method for isochronous resource management in a network based on hiperlan 2 technology |
| US6738823B1 (en) * | 2000-01-31 | 2004-05-18 | Microsoft Corporation | Use of isochronous packets to eliminate redundant acknowledgments |
| US6977928B1 (en) * | 2000-04-13 | 2005-12-20 | International Business Machines Corporation | Method and system for data flow multicasting |
| US6704819B1 (en) * | 2000-04-19 | 2004-03-09 | Microsoft Corporation | Method and apparatus for device sharing and arbitration |
| US7002928B1 (en) * | 2000-06-21 | 2006-02-21 | Sony Corporation | IEEE 1394-based protocol repeater |
| US6757773B1 (en) | 2000-06-30 | 2004-06-29 | Sony Corporation | System and method for determining support capability of a device coupled to a bus system |
| CN100420211C (en) * | 2000-08-23 | 2008-09-17 | 皇家菲利浦电子有限公司 | Communication system and device |
| KR20020059722A (en) * | 2000-09-13 | 2002-07-13 | 요트.게.아. 롤페즈 | Communication system and device |
| US6725311B1 (en) | 2000-09-14 | 2004-04-20 | Microsoft Corporation | Method and apparatus for providing a connection-oriented network over a serial bus |
| JP3896784B2 (en) * | 2000-10-10 | 2007-03-22 | 日本電気株式会社 | Packet communication method and apparatus |
| US6647447B1 (en) * | 2000-12-29 | 2003-11-11 | Sony Corporation | Allocating isochronous channel numbers to devices on an IEEE-1394 bus |
| US6977939B2 (en) * | 2001-01-26 | 2005-12-20 | Microsoft Corporation | Method and apparatus for emulating ethernet functionality over a serial bus |
| US7542474B2 (en) * | 2001-02-26 | 2009-06-02 | Sony Corporation | Method of and apparatus for providing isochronous services over switched ethernet including a home network wall plate having a combined IEEE 1394 and ethernet modified hub |
| US6820150B1 (en) * | 2001-04-11 | 2004-11-16 | Microsoft Corporation | Method and apparatus for providing quality-of-service delivery facilities over a bus |
| US7149195B2 (en) * | 2001-08-28 | 2006-12-12 | Nokia Corporation | Apparatus, and associated method, for multicasting data in a radio communications system |
| JP2003110651A (en) * | 2001-10-01 | 2003-04-11 | Canon Inc | Data processing method, data processing apparatus, communication protocol and program |
| CN1181648C (en) | 2002-09-06 | 2004-12-22 | 联想(北京)有限公司 | Method for automatic searching between devices on network |
| US7653012B2 (en) * | 2002-09-26 | 2010-01-26 | Sharp Laboratories Of America, Inc. | Relay transmission of data in a centralized network |
| US20040081089A1 (en) * | 2002-09-26 | 2004-04-29 | Sharp Laboratories Of America, Inc. | Transmitting data on scheduled channels in a centralized network |
| JP2005012260A (en) * | 2003-06-16 | 2005-01-13 | Matsushita Electric Ind Co Ltd | Data transmission control method |
| DE10337699B4 (en) * | 2003-08-16 | 2006-01-12 | Phoenix Contact Gmbh & Co. Kg | Method and device for transmitting data over a bus network using the broadcast principle |
| US7349436B2 (en) * | 2003-09-30 | 2008-03-25 | Intel Corporation | Systems and methods for high-throughput wideband wireless local area network communications |
| MXPA06007673A (en) * | 2004-01-22 | 2006-09-04 | Ericsson Telefon Ab L M | Access control for multicast channel request. |
| US7505751B1 (en) | 2005-02-09 | 2009-03-17 | Autocell Laboratories, Inc. | Wireless mesh architecture |
| JP4432814B2 (en) * | 2005-03-25 | 2010-03-17 | ヤマハ株式会社 | Performance data communication management system and performance data communication management device |
| FR2887107B1 (en) * | 2005-06-10 | 2007-12-14 | Canon Kk | METHOD AND DEVICE FOR TRANSMITTING, STORING AND READING MULTIPLEXED OR MULTIPLEXED VIDEO FLOWS IN THE COMMUNICATION NETWORK |
| JP4846381B2 (en) * | 2006-02-08 | 2011-12-28 | 富士通セミコンダクター株式会社 | BAND ALLOCATION METHOD, COMMUNICATION CONTROL DEVICE, AND COMMUNICATION DEVICE |
| US8929360B2 (en) * | 2006-12-07 | 2015-01-06 | Cisco Technology, Inc. | Systems, methods, media, and means for hiding network topology |
| JP4764811B2 (en) * | 2006-12-14 | 2011-09-07 | 富士通株式会社 | Relay device and communication path management method |
| US8345553B2 (en) * | 2007-05-31 | 2013-01-01 | Broadcom Corporation | Apparatus and methods for reduction of transmission delay in a communication network |
| US8051232B2 (en) * | 2007-06-25 | 2011-11-01 | Intel Corporation | Data storage device performance optimization methods and apparatuses |
| US8537844B2 (en) * | 2009-10-06 | 2013-09-17 | Electronics And Telecommunications Research Institute | Ethernet to serial gateway apparatus and method thereof |
| CN104022915B (en) * | 2014-05-19 | 2017-07-14 | 华为技术有限公司 | A kind of flow rate adjusting method and device |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1146431A3 (en) * | 1992-12-21 | 2001-12-19 | Apple Computer, Inc. | Method for tranforming an arbitrary topology collection of nodes into an acyclic directed graph |
| EP1083703B1 (en) * | 1994-03-09 | 2003-06-04 | Matsushita Electric Industrial Co., Ltd. | Data transmission system and method |
| JP3291926B2 (en) | 1994-07-07 | 2002-06-17 | ソニー株式会社 | Electronic device control method |
| JP3271493B2 (en) * | 1995-09-26 | 2002-04-02 | ヤマハ株式会社 | Network and data transmission method |
| US5841989A (en) * | 1996-04-08 | 1998-11-24 | Apple Computer, Inc. | System and method for efficiently routing data packets in a computer interconnect |
| US5978578A (en) * | 1997-01-30 | 1999-11-02 | Azarya; Arnon | Openbus system for control automation networks |
-
1998
- 1998-03-06 JP JP05516698A patent/JP3171241B2/en not_active Expired - Fee Related
-
1999
- 1999-03-05 CA CA002264461A patent/CA2264461C/en not_active Expired - Fee Related
- 1999-03-05 EP EP99103913A patent/EP0940946B1/en not_active Expired - Lifetime
- 1999-03-05 US US09/264,189 patent/US6434117B1/en not_active Expired - Lifetime
- 1999-03-05 DE DE69922072T patent/DE69922072T2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| CA2264461A1 (en) | 1999-09-06 |
| US6434117B1 (en) | 2002-08-13 |
| EP0940946B1 (en) | 2004-11-24 |
| EP0940946A1 (en) | 1999-09-08 |
| JP3171241B2 (en) | 2001-05-28 |
| JPH11261606A (en) | 1999-09-24 |
| DE69922072D1 (en) | 2004-12-30 |
| DE69922072T2 (en) | 2005-11-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2264461C (en) | Ieee-1394 serial bus network capable of multicast communication | |
| US6031841A (en) | RSVP support for upstream traffic | |
| US6092113A (en) | Method for constructing a VPN having an assured bandwidth | |
| JP3216120B2 (en) | Multi-access communication method | |
| EP1031224B1 (en) | Packet network | |
| US7453885B2 (en) | Network connection device | |
| EP1428356B1 (en) | Method and arrangements to achieve a dynamic resource distribution policy in packet based communication networks | |
| US7158531B2 (en) | Method and apparatus implementing a multimedia digital network | |
| US6678252B1 (en) | Method and apparatus for dynamic source routing in ad hoc wireless networks | |
| US6745246B1 (en) | Apparatus and method in a network switch for modifying a bandwidth request between a requestor and a router | |
| EP0603099A2 (en) | A method and system of requesting resources in a packet-switched network with minimal latency | |
| JP3436174B2 (en) | Communication method | |
| JPH1185632A (en) | Data communication method | |
| EP0921655A3 (en) | Multicast transmission method | |
| US6490622B1 (en) | Node device and scheme for sharing common virtual connection indentifier between end-nodes | |
| US5390182A (en) | System for synchronous bandwidth allocation in token ring networks | |
| US7643492B2 (en) | Network bandwidth reservation method | |
| JP3547887B2 (en) | Node device and network resource reservation method | |
| JP2928882B1 (en) | Local area network bandwidth control | |
| JPH10126430A (en) | Cable network system | |
| US6587472B1 (en) | Fair channel allocation protocol for DTM networks | |
| JP3555514B2 (en) | Quality assurance type network system and quality assurance type communication method | |
| JP2002359621A (en) | Broadcast communication method | |
| Jeng | RSVP Code Explained | |
| Foudriat et al. | Combining two media access protocols to support integrated traffic on high data rate networks |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |