Electrical computers and digital data processing systems: input/ – Intrasystem connection – Bus interface architecture
Reexamination Certificate
1999-11-24
2004-01-13
Lefkowitz, Sumati (Department: 2189)
Electrical computers and digital data processing systems: input/
Intrasystem connection
Bus interface architecture
C710S110000, C710S311000
Reexamination Certificate
active
06678781
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a communication network based on IEEE 1394 Serial Bus Standard and in particular to a network configuration method and management method of a network composed of a plurality of IEEE 1394 serial buses joined by one or more bridges.
2. Description of the Related Art
The IEEE 1394 standard defined in 1995 is an international standard for implementing a cost-effective and high-speed digital interface. The IEEE 1394 serial bus provides high-speed data transport of several hundreds of megabits per second and therefore enables real-time transport required for digital video data transmission. The IEEE 1394 further provides so-called plug-and-play function by which devices can be added or removed by users without initial settings. These advantages cause the IEEE 1394 digital interface to provoke widespread attention as a digital interconnect for both computer peripherals and consumer electronics including digital video cameras and digital television sets.
A device connected to the IEEE 1394 serial bus is called “node” and an identifier called node ID is assigned to each node. The plug-and-play is realized by an ID assignment function. More specifically, when detecting that a node is added to or removed from an IEEE 1394 bus, the IEEE 1394 bus is reset and thereafter reconfigured using the ID assignment function of automatically assigning a different ID to each node.
A node ID is written onto a 16-bit field, which is further divided into 10 bits of higher order as a bus ID of and 6 bits of lower order as a physical ID. The bus ID is used to identify each IEEE 1394 bus. The physical ID is used to identify each node connected to an IEEE bus. The present IEEE 1394 standard defines a bus configuration method of configuring a single bus by using only physical ID, resulting in a maximum of 63 nodes connected to the bus.
A bridge is a node capable of connecting two or more IEEE 1394 buses into a network in which each IEEE bus is uniquely identified by its bus ID. Such a bridge enables packet transfer between different IEEE 1394 buses, resulting in the increased number of nodes available in the whole network. In the case of a 10-bit bus ID used, a maximum of 1023 buses is available and therefore about 64,000 nodes can be connected in all. Further, in the case where the network is segmented by bridges, the reconfiguration of the IEEE 1394 bus caused by addition/removal of a node can be restricted within that segment and furthermore the traffic is also restricted within the segment. Therefore, the use efficiency of the network is expected to be improved.
A conventional network connection device has been proposed in Japanese Patent Unexamined Publication No. 10-200583. In this prior art, a plurality of IEEE 1394 networks are joined through a backbone network, where topology information for each network is recognized to produce a new topology information to allow easy data transfer between them.
IEEE P1394.1 working group is now extending IEEE 1394-1995 beyond a local bus by means of an IEEE 1394 bridge. Since the P1394.1 draft 0.03 has been published so far, hereafter this draft 0.03 is referenced to describe the model and operation of a bridge.
FIG. 1
shows a logical mode of a bridge, as currently defined in the P1394.1 draft 0.03. A connection between a bridge
10
and an IEEE 1394 bus is called “portal”. A bridge consisting of two portals
20
and
21
is mainly considered. Each portal serves as a node on the corresponding IEEE 1394 bus and monitors a packet on the bus to determine whether the packet on the bus is to be transferred to another bus. In the case of asynchronous packet, the bus ID field of the destination ID included in its header is checked to perform the determination. In the case of isochronous packet, the channel number of its header is checked to perform the determination.
When receiving a packet to be transferred to another bus, one portal transfers the received packet to a switching fabric
30
installed in the bridge
10
. The switching fabric
30
connects the portals
20
and
21
to route the transferred packet to the other portal. A cycle clock
40
is a common resource to which both portals shall be synchronized to perform the isocnronous (real-time) transfer between buses, which is a feature of the IEEE 1394.
In the P1394.1 draft 0.03, a bridge manager is now proposed as a network management node. The role of the bridge manager is not explicitly defined in the P1394.1 draft 0.03 but several functions are proposed, for example, assignment of a bus ID to each bus, setting of routing map used to determine whether an asynchronous packet is permitted to be transferred, and network topology management.
In order to realize the IEEE 1394 multi-bus network using bridges as described above, the configuration procedure of the network is needed, including bus-ID assignment, the routing map setup of a portal, and the like. About this configuration procedure, the outline defined in the P1394.1 draft 0.03 will be explained with reference to FIG.
2
.
Referring to
FIG. 2
, a bridge manager is selected as a network management node from the network (step S
201
). It should be noted that a selection method is not concretely described in the P1394.1 draft 0.03.
If there is at least one a not-configured bus which has not been set to allow packet transfer to and from another bus (YES in step S
202
), the selected bridge manager assigns a bus ID to the not-configured bus (step S
203
). More specifically, the bridge manager writes the bus ID onto a NODE_IDS register of each node connected to the not-configured bus. The NODE_IDS register is a register for scoring its own node ID.
Thereafter, the bridge manager initializes the routing information of all the bridges connected to the bus to which the node ID is assigned (step S
204
). In this stage, only part of the routing information is initialized to the extent that a packet sent by the bridge manager is allowed to be transferred.
Then, the steps S
203
and S
204
are repeatedly performed until all buses have been configured. When the configuration of all buses has been completed (NO in step S
202
), the bridge manager sets the routing information of the bridges to allow packet transfer between any of the buses (step S
205
).
Further, a method called Reset Notification is also proposed to suit to Bus Reset defined in IEEE 1394. In the case where a network consists of a single bus, it is possible to recognize the occurrence of bus reset in all the nodes connected to the bus. Contrarily, in the case where a network consists of two or more buses joined by one or more bridge, a node connected to a bus cannot be informed of the occurrence of bus reset in another bus because the bus reset is blocked by the bridge.
After bus reset, the respective node IDs of nodes connected to the bus are probably changed due to the reconfiguration of the bus. Therefore, packet transfer cannot be successfully performed without knowing the occurrence of the bus reset and the reassigned node IDs.
Although the reset notification method has not been finally defined, it would be basically such a scheme that, when bus reset occurs in a bus, a bridge connected to the bus informs another bus of the bus reset.
However, the above-mentioned IEEE 1394 network configuration procedure has the following disadvantages regarding bridge manager selection and the routing map setting in a portal,
First, it is difficult to select a bridge manager with reliability. Since bus IDs have not been assigned, it is impossible to normally transfer packets between buses. Further, each candidate for bridge manager does not grasp the network topology and the number of candidates for bridge manager.
Secondly, the procedure of setting the routing map of a portal is divided into a first step and a second step. The first step is to perform the routing map setting to the extent that transaction from a bridge manager can be transferred. The second step is to perform the whole routing map setting after a bus ID has b
Lee Christopher E.
Lefkowitz Sumati
NEC Corporation
Young & Thompson
LandOfFree
Network configuration method does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Network configuration method, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Network configuration method will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3220840