FR2791501A1 - Bridge identification method, especially in interconnection of serial bus network portions, determining and assigning length of identifier based on characteristics of part of network connected to bridge - Google Patents

Abstract

At least one characteristic of a first part of the network to which a bridge is connected is determined, and based on this, the length of an identifier associated with this part of the network is determined. The identifier is then assigned to at least the one bridge connected to this part of the network. The source and destination fields of an asynchronous packet are analyzed to carry out the routing required via the bridges as necessary. Independent claims are included for : (a) a device for determining an identifier for at least one bridge in a network; (b) a bridge connecting at least two parts of a network; (c) a packet switching network using such a bridge; (d) and a data processing device in the form of a printer, server, computer, facsimile, scanner, VTR, (digital) camcorder, decoder, TV receiver, or digital still camera.

Description

The present invention relates to a method and a device for

  determination of at least one identifier of at least one bridge connecting at least

  a first part of a network to at least a second part of said network.

  The present invention relates both to the transfer of information between two parts of a network which are subnets of different constitution and performance than to the transfer of information between

two subnets of the same kind.

  Part of a network is also called a subnet.

  Communication networks are known which are formed of

  several serial communication buses conforming to the IEEE 1394 standard.

  These buses are organized in a network, that is to say that they are interconnected by equipment that is called "bridges" ("bridges" in

Anglo-Saxon terminology).

  Bridge means any connecting equipment between two or

multiple parts of a network.

  The bridge thus makes it possible to transfer data packets from a first part of the network or first sub-network to a second part of the network or second sub-network by wired, optical, radio or any other link.

other type of bond.

  The bridges connecting serial communication buses to each other are more particularly the subject of standard P1394.1 which is under discussion. In the context of this standard, a bridge is more particularly an item of equipment comprising at least two constituent portions of said bridge, called "portais" in English terminology and making it possible to connect together at least two serial communication buses 1394. A "portai" is a set of ports conforming to the 1394 standard and connected to a bus

1394 serial communication.

  Each serial communication bus of such a network links different peripherals together such as printers, computers,

  servers, scanners, video recorders, decoders (known in English terminology

  Saxon under the term "set top box"), televisions, digital cameras,

  camcorders, digital cameras ...

  These devices are generally called nodes.

  Each device located on a network bus may want to communicate with another network device located on another network bus, the two buses on which these devices are located being separated

by one or more bridges.

  Thus, each of these bridges will therefore have to selectively or not transfer the information exchanged between the two peripherals from one of the buses connected to one of the "ports" of said bridge to another bus arranged on the other side. said bridge and connected to another "portal"

from this same bridge.

  Each bus can be connected to several other buses by

  through several different bridges.

  When a "portal" receives a data packet, it must therefore be able to identify whether the packet it receives is intended for a device present on its

  bus or to one or more of the "portais" present on his bus.

  To do this, the information conveyed on the various buses of the path traversed by the data packet must indicate the destination of the packet and each port must be able to analyze this destination for

  transmit the information to the receiving device.

  In networks conforming to the IEEE-1394 standard, the destination address is coded in a first information field known as the identification of the header of the fixed-length data packet, called the destination field, and l the source address of said data packet is coded in a second information field known as the identification of the fixed length header, called the source field. These two fields are distinct and their

  length depends on the communication protocol.

  In networks conforming to the IEEE-1394 standard, the field

  destination is for example coded on 16 bits and the source field also.

  These 16 bits are separated into 10 bits reserved for coding the identifier of the bus on which the destination device of the data packet is located and 6 bits reserved for coding the identifier of the destination device on this bus. Such data packet transfer networks require centralized equipment (known under the term "prime portal" in English terminology) which, during the initialization of the network, will assign a number to each bus of the network. Then, after this automatic numbering step, each "portal" of each bridge will configure its own routing table according to the different messages it will have seen

pass.

  This routing table is for example represented by a

  succession of bits o each bit corresponds to a network bus.

  Each bit will be set to the binary value 0 or 1, 0 if the bridge must not transfer data intended for a peripheral present on the bus corresponding to this bit in the table and 1 if the bridge must transfer data intended for a peripheral present on the bus corresponding to this bit

in the table.

  These networks are configured to be able to interconnect a maximum number of 1024 buses. Each routing table must therefore comprise 1023 bits and each bridge must therefore comprise two routing tables of 1023 bits since each portal is connected to different buses and must therefore, therefore,

have your own table.

  In such a network, when the data packet arrives in the bridge, it reads the destination field placed in the header of this data packet and reads its routing table to determine if it can transmit the packet to the destination bus, i.e. if the bit corresponding to this bus is

  positioned at "1" in the routing table.

  These data packet transfer networks have several drawbacks, starting with the complexity of the configuration mechanisms, both for the allocation of bus numbers and for the

  management of these numbers in the routing table.

  In addition, these networks require centralized management which must

  determine, during the initialization of the network, the topology of said network, that is to say

  tell how the different buses are interconnected. To do this, it is necessary to establish an exchange protocol between the different buses in order to

  set up this centralized management.

  These networks must assign a number to each bus and this

  number is unique in a given network.

  It should be noted that when two networks are interconnected by a bridge in order to form a single network, each network forming a part of said final network, it must first elect that of the two centralized devices or "prime portals" of the two networks who will become the equipment

  centralized or "prime portal" of the final network.

  Then, given that a number has already been assigned to each bus of each network before their meeting, the numbering of each bus must therefore be corrected to keep the unique numbering of the

  bus and all routing tables will need to be reconfigured.

  Furthermore, these networks generate so-called protocol information traffic which is all the more important as said networks are made up of a large number of elements, which considerably penalizes the capacity of the

  network to convey useful information for the peripherals of said network.

  Data packet transfer methods such as that described in US Pat. No. 5,442,881 are known, making it possible to code the header at the source. The source device or node that wants to send a data packet knows the path that separates it from the destination device to which it wants to transfer data. This path is coded in a field of the header of the data packet which includes all the addresses or identifications of the different nodes of the network encountered by said data packet on its path. When a device on this network, responsible for packet transfer, receives the data packet, it decodes this header and transmits the

  packet to the destination device after changing this header.

  Also known is US Pat. No. 5,613,069 which describes a method for transferring packets in a packet switched network, each packet comprising a header field of variable length to describe the path to be traveled as well as a field of end of length pack

  variable to describe the path traveled.

  However, this system applies to packet switching o each port of a switch is connected to a single other port of another switch while a bridge can be connected to several other bridges via a

same bus.

  Thus, such a solution is not suitable for being implemented in a network of the type presented above, conforming to the IEEE 1394 standard. In these networks, the header of each data packet includes a destination field and a source field, of which only 10 bits are reserved in each of them for coding the identifier of the bus on which

  is the destination or source device.

  Indeed, in a network of the type conforming to the IEEE 1394 standard, in the case where the maximum authorized number of each constitutive portion of a bridge or "portal" on a bus is three, at least two bits are required to code

  the address or identifier of each "portal" in a unique way.

  The destination field of the data packet header can

  therefore contain four different "portals" identifiers.

  Thus the maximum number of bridges separating the source and the

  destination is therefore, in this example, four.

  This is restrictive and we note that the more the number of "portals" authorized on a bus increases, the more it is necessary to have a high number of bits to code the identifier of these portals and therefore the greater the distance

  maximum between the source of a data packet and its destination is low.

  Furthermore, the Applicant has noticed that, in such a network, the specifics of each bus constituting the network are not taken into account. In fact, there are buses with characteristics having different performances, for example buses that can transmit bit rates of 100, 400 or even 800 Mbps / s or more. However, an essential characteristic for packet transfer such that the speed is not taken into account when transferring packets through different parts of networks or subnetworks such as buses, which can cause serious congestion problems for the network, limiting by the same the total flow of the network therefore of the performances of this one. In addition, some buses are linked to a large number of other buses via bridges. These same buses, due to their multiple links with other parts of networks or subnets, may have to transfer

  more information than other buses.

  Congestion problems therefore also arise.

networks.

  The present invention aims to remedy this drawback by proposing a method for determining at least one identifier for at least one bridge connecting at least a first part of a network to at least a second part of said network, characterized in that said method comprises the following steps: - determination of at least one characteristic of said at least one first part of the network to which said bridge is connected, determination of at least one length of at least one identifier associated with said at least one first part of the network as a function of said at least one characteristic, - assignment of at least one identifier having a length which has just been determined to at least one bridge connected to said at least

a first part of the network.

  Correlatively, the invention relates to a device for determining at least one identifier of at least one bridge connecting at least a first part of a network to at least a second part of said network, characterized in that said device comprises: - means for determining at least one characteristic of said at least one first part of the network to which said bridge is connected, means for determining at least one length of at least one identifier associated with said at least one first part of the network according to said at least one characteristic, - means for assigning at least one identifier having a length which is that just determined to at least one bridge connected to said

  at least a first part of the network.

  The Applicant has noticed that by assigning to at least one bridge connected to a part of the network an identifier whose length has been determined as a function of at least one characteristic specific to this part of the

  network, we optimize the management of network resources.

  Thus, the length of an identifier is adjusted to avoid congestion problems and, for example, makes it possible to increase the number of bridges that can be crossed by a data packet and / or to increase the

  number of bridges connected to the same bus.

  This identifier assignment also allows optimum use as regards the throughput performance of each part or subnetwork of the network. The fact of considering at least one characteristic of a part or sub-network of the network in determining the length of the identifier or label of a bridge makes it possible to improve the performance of this part of the network.

  and to guarantee the transmission of information in the network at the best speed.

  This simple local assessment illustrates the simplicity of the step

  assignment of the bridge identifier in the network according to the invention.

  Thanks to the invention, it is not necessary to configure routing tables and there are no problems linked to the interconnection of

  multiple parts or subnets of a network.

  Advantageously, the determination method according to the invention is not centralized, but it is, on the contrary, implemented locally on at least one part or sub-network. The invention therefore makes it possible to avoid management

  complex and an important protocol exchange.

  According to one characteristic, at least one identifier is assigned to said bridge connecting said first and second parts of the network, said bridge

  being an essential part of the network.

  According to one characteristic, said bridge comprising at least two portions each connected to said at least two parts of the network, at least

  an identifier is assigned to each of said at least two portions.

  Thus, the assignment is made to each element of the bridge and therefore makes it possible to differentiate the treatments between each part or sub-network, which

  has the consequence of offering better management of each part or sub-

  network. According to one characteristic, said bridge is connected to at least one bus

serial communication.

  According to another characteristic linked to the preceding one, each

  identifier is unique for a given serial communication bus.

  This simplifies the processing and coding of the header to

source.

  Therefore, the initialization mechanism is local to a bus, which does not require an exchange beyond the bridges for the configuration of the network.

  with regard to the packet transfer method.

  According to a particular characteristic of the invention, the step of determining at least one characteristic of said at least a first

  Part of the network is to determine the possible bit rate of said part.

  Bit rate is an essential criterion when looking at

congestion problems.

  Thus, networks with higher throughput performance than those of other networks will be assigned an identifier length or size.

  different from that of said other networks.

  According to a preferred embodiment, the step of determining the length of the identifier will lead to a longer length of identifier. This allows a greater number of bridges to be able to be linked to said audit.

  sub-network thus increasing the possibilities of exchange between said sub-

  network to other subnets constituting said network.

  According to another characteristic of the invention, the step of determining a characteristic of said at least a first part of the

  network is to determine the number of bridges connected to it.

  This allows in a simple and adaptive manner to be able to implement a packet transfer method using source coding in a flexible manner. This flexible source coding is transparent to the user

  who doesn't have to consider how to interconnect different parts or sub-

  networks of a network, such interconnection being made automatically by

  each part of the network or subnetwork and its associated bridge (s).

  This allows you to assign the size or length of the

  optimally so as to maximize the distance between source and destination.

  According to one characteristic, the step of assigning at least one identifier is carried out for each bridge connected to said at least one

first part of the network.

  So all the bridges are identified and all the paths across

bridges are possible.

  According to one characteristic, the step of assigning at least one identifier is carried out for a predetermined maximum number of bridges connected to said at least one first part of the network. This characteristic makes it possible to limit the number of bridges on a bus, therefore the number of interconnections, and thereby to resolve the

congestion problem.

  According to one characteristic, the predetermined number of bridges is equal to the power of 2 of the number of bits allocated to the identifiers of said bridge

minus one unit.

  This allows optimal use of the capacities of the length of the identifier, and therefore of the number of bridges that can be connected to the bus. According to one characteristic, said data packet comprises at least two information fields known as identification of the path respectively to be traveled and traveled by said data packet, said at least two information fields each having a given length, said method comprising the following steps during the transfer of said data packet across said bridge: - deletion of at least one first item of information from at least one first information field, thereby reducing the length of said first information field by a corresponding length to that of said first information, - addition of at least one second information in at least one second information field, thereby increasing the length of said second information field by a length corresponding to that of said second information. This allows, using source coding, to increase

  the space available to encode the packet path.

  According to one characteristic, the data packet has two opposite ends and said at least two information fields are located

  at the same end of said data packet.

  Thus, the information is advantageously concentrated in the same space, which makes it possible to comply with the IEEE 1394 standard. According to one characteristic, the data packet includes a third information field known as a marker which delimits the first and

  second information fields relative to each other.

  This facilitates processing regarding the reading of the

  head of the package and brings simplicity and efficiency to this treatment.

  Advantageously, the marker makes it possible to determine that a field is about to be completely consumed as a result of the consecutive deletion of information in said field on each crossing of a bridge. The marker is thus used by the last bus to know that the destination device

is on said bus.

  According to one characteristic, the marker has a length at least equal to the number of bits necessary to code an identifier of said bridge

  in one of the information fields.

  This characteristic has the same advantage as that

previously mentioned.

  According to one characteristic, the method comprises, during the transfer of said data packet across said bridge, a step of shifting the first, second and third fields of information between the steps of

  removing and adding information.

  Thus, the marker is moved after each passage across a bridge and its position varies as to its size depending on the distance (expressed in number of bridges crossed) traveled by the packet between the

source and destination.

  According to one characteristic, the total length of the first,

  second and third fields is fixed.

  According to one characteristic, the method comprises, during the transfer of said data packet across said bridge, a step of comparing the length of one of the first and second identification information fields of the packet received from said at least one first part of the network with the length of the same field of the packet transmitted on said at least second

part of the network.

  More particularly, when the length of one of the first and second fields of identification information of the packet received from said at least one first part of the network is different from the length of the same field of packet transmitted on said at least one second part of the network, said method includes a step of modifying the length of the third

field of the packet to be transmitted.

  This ensures a fixed header size and the ability to transfer size bridge identifiers to a fixed size field

different.

  Thus, and advantageously, the coexistence of identifiers of different size in the same network is made feasible in a field

fixed length.

  According to one characteristic, the length of one of the first and second identification information fields of the packet received from said at least one first part of the network is equal to the length of the same field

  of the packet transmitted on said at least a second part.

  Network management is very simple and meets the standard

IEEE 1394.

  According to one characteristic, said first and second information fields contain information relating to said at least one identifier of the bridge or bridges arranged on the path of the data packet.

in the network.

  This allows encoding from the header to the source.

  Routing at source simplifies the implementation of routing in the intermediate bridges placed between the source and the destination

of the package.

  According to one characteristic, said first information field contains information relating to said at least one identifier of the bridge or bridges arranged on the path to be traversed by the data packet in the network. According to a second aspect, the invention relates to a bridge connecting at least two parts of a data packet communication network to each other, characterized in that said bridge comprises a device for determining at least one identifier of at least a bridge as described above. According to a third aspect, the invention relates to a data processing apparatus, characterized in that it comprises a bridge conforming to the

brief statement above.

  The processing apparatus is, for example, a printer.

  The processing device is, for example, a server.

  The processing apparatus is, for example, a computer.

  The processing device is, for example, a fax machine.

  The processing device is, for example, a scanner.

  The processing device is, for example, a video recorder.

  The processing device is, for example, a decoder (known in

  Anglo-Saxon terminology under the term "set top box").

  The processing device is, for example, a television.

  The processing device is, for example, a camcorder.

  The processing device is, for example, a digital camera.

  The processing device is, for example, a device

digital photographic.

  According to a fourth aspect, the invention relates to a data packet communication network comprising at least two parts linked together by at least one bridge, characterized in that said bridge is

in accordance with the above.

  According to a particular characteristic, each of said at least two parts of said network comprises at least one serial communication bus to which said bridge is connected. According to a fifth aspect, the invention relates to a data packet communication network comprising at least two parts linked together by at least one bridge, characterized in that said network

  includes a data processing device as briefly explained below

above.

  The invention further relates to a means of storing information, possibly totally or partially removable, readable by a computer or a processor containing instructions of a computer program, characterized in that it allows the implementation of the method of determination

  at least one identifier for at least one bridge as briefly explained below

  above. The invention further relates to a means of storing information, possibly totally or partially removable, readable by a computer or a processor containing data originating from the implementation of the method for determining at least one identifier of at least such a bridge

that briefly outlined above.

  The invention also relates to an interface making it possible to receive the instructions of a computer program, characterized in that it allows the implementation of the method for determining at least one identifier for at least

  minus a bridge in a network as briefly explained above.

  The advantages and characteristics specific to the device for determining at least one identifier of at least one bridge, to the bridge connecting at least two parts of a network to each other and comprising such a device, to the data processing apparatus comprising such a bridge, to said network comprising such a bridge and to said network comprising such a data processing apparatus, as well as to the information storage means being the same as those set out above concerning the method for determining at least an identifier of at least one bridge according to the invention, they will not be

recalled here.

  Other features and advantages will become apparent during the

  description which will follow given by way of illustrative and nonlimiting example, and

  made with reference to the accompanying drawings in which: - Figure 1 is a schematic view of a serial communication bus network according to the invention; - Figure 2 is a schematic view showing the structure

  an asynchronous data packet as defined in the IEEE 1394- standard; - Figure 3 is a detailed schematic view of an apparatus for

  data processing comprising a bridge according to the invention and referenced 66 in FIG. 1; - Figure 4 is a schematic view showing different registers stored in the RAM memory of the data processing apparatus of Figure 3; - Figure 5 is a schematic view illustrating the transfer of a data packet through the intermediate bridge referenced 66 in Figure 1; - Figure 6 is a schematic view illustrating the transfer of a data packet through the destination bridge referenced 67 in Figure 1; - Figure 7 is a schematic view illustrating the transfer of a data packet through the source bridge referenced 67 in Figure 1; - Figure 8 is a detailed schematic view showing a routing table stored in the RAM memory of the data processing apparatus of Figure 3; FIGS. 9 and 10 represent a schematic view of the algorithms of the methods, on the one hand, for recovering a path descriptor from an index in the routing table and, on the other hand, for recovering an index from a path descriptor; - Figure 11 is a schematic view of the algorithm of the packet transfer method according to the invention; - Figure 12 is a schematic view of a bus network during the broadcast of an address resolution packet on the one hand, and its corresponding response packet on the other hand; - Figure 13 is a schematic view showing the structure of an address resolution data packet; - Figure 14 is a schematic view showing the structure of an asynchronous data packet in response to the packet described in Figure 13; - Figure 15 is a detailed schematic view showing a verification table stored in the RAM memory of Figure 3; FIG. 16 is a schematic view of the algorithm of the method for receiving an address resolution packet at a portal of a bridge according to the invention; - Figure 17 is a schematic view of the algorithm of the method for receiving a response data packet to the address resolution packet at a port of a bridge according to the invention; FIG. 18 is a schematic view of the algorithm of the method for managing the length of the identifiers or routing labels at the level of a bus as a function of the capacity of the bus; FIG. 19 is a schematic view of the algorithm of the method for managing the length of the identifiers or routing labels at the level

  of a bus depending on the number of bridges connected on the bus.

  FIG. 1 represents a schematic view of a serial communication bus network in the context of which the invention applies. A set of serial communication buses 51, 52, 53, 54, 55, 56, 57, 58 and 59, interconnected by several bridges 60, 61, 62, 63, 64, 65, 66 and 67, allow peripherals located on different buses to exchange packets of

asynchronous data.

  Thus, the peripheral 68, connected to the bus 52, can initiate a transaction with the peripheral 69 which, for its part, is connected to the bus 59, by exchange of asynchronous packets. Packet transfer from one bus to another

  is ensured by the packet transfer method according to the invention.

  The structure of an asynchronous packet, widely described in the IEEE 1394-95 standard, is illustrated in Figure 2. Asynchronous packets are among other things used to perform transactions between a source device and a destination device. A transaction is carried out by sending a "Request" type packet from the source to the destination, then a packet of

  "Response" type from destination to source.

  The "destinationlD" field 80 of FIG. 2 ("Destination Identifier" in English terminology), represented on 16 bits, contains

  routing information to reach the destination device.

  This field is called the way to go identification field.

by the data packet.

  The field "source_lD" 81 ("Source Identifier" in English terminology), represented on 16 bits, contains the routing information

  to reach the source device.

  This field is called the path identification field

by the data packet.

  The presence of these two fields 80 and 81 promotes the

  progress of a transaction between the source and the destination.

  It should be noted that the two fields of identifying information of a data packet are not necessarily placed in the header of said packet, as is the case in this example, but can be located at the opposite end of this package, i.e. at the end of

package.

  The field "tl" 82 ('Transaction Label' in English terminology

  Saxon), represented on 6 bits, allows to number a transaction between peripherals. The field "rt" 83 ("Retry Code" in English terminology), represented on 2 bits, makes it possible to identify the attempts to transmit the same

asynchronous packet.

  The "tcode" field 84 ("Transaction Code" in English terminology

  Saxon), represented on 4 bits, identifies a packet type

  asynchronous, such as the type of transaction.

  The "pri" field 85 ("Priority" in English terminology), represented on 4 bits, makes it possible to identify the priority associated with the asynchronous packet. Fields 86, 87, 88, 89 and 90 are for some optional and relate to the interpretation of the data conveyed by the asynchronous packet. The invention relates more particularly to the analysis and processing of fields 80 and 81 of an asynchronous packet during the transfer of a

  packet between a source device and a destination device.

  FIG. 3 represents the schematic structure of a data processing apparatus such as a computer 11 comprising, for example, the bridge 66 represented in FIG. 1. Thus, all the bridges of the network represented in the

  Figure 1 for example have this structure.

  The data processing device could also take the form of a printer, a server, a fax machine, a scanner, a video recorder, a decoder (known in English terminology as term "set top box"), a television set, a camcorder, a camera

  digital camera or digital camera.

  All the bridges in FIG. 1 can for example be integrated into a data processing device of this type or else

constitute the device itself.

  In this example, the bridge constitutes a packet transfer device. This bridge comprises a CPU 12, a permanent storage memory 14 (ROM) which contains the different instructions of the algorithms represented in FIGS. 9, 10, 11, 18 and 19 and a temporary storage memory 16 (RAM). These three elements 12, 14 and 16 communicate by means of respective address and data buses denoted 18, 20, 22, with

  a block denoted 24 and known to those skilled in the art under the name of PCI bridge.

  The computer 11 also includes a screen 13, a keyboard 15, a floppy drive 17, a CD-ROM drive 19 and a network interface

21 (Figure 3).

  The network interface 21 can receive, for example, by means of a local area network (not shown) of the Ethernet type, the instructions of a computer program allowing the implementation of the

* process according to the invention.

  Such instructions may also be contained in the

  floppy drive or CD-ROM drive.

  Block 24 is actually a set of PCI components such as

  the Intel 440LX AGP package ("Intel 440LX AGPset" in English terminology

  Saxon) marketed by the company INTEL. Thus, the block 24 comprises, for example, a component 82443LX which provides the interface with the memory 16 via the memory bus 22 and with the calculation unit CPU 12 via the local bus 18. The component 82443LX is itself connected to a component 82371AB which provides an interface with the ISA bus 20 connected to the memory 14 and to the various peripheral extensions: screen 13, keyboard 15, floppy drive 17, CD-ROM drive 19 and network interface 21. A controller Interrupt IOAPIC Intel 82093AA connected to the CPU 12 calculation unit manages

  interruptions that may occur in the system.

  This block 24 makes it possible in particular to exchange data by means of the standard PCI bus 26 (PCI meaning in English terminology "Peripheral Component Interconnect") with another PCI interface component noted 28. The bus 26 can also connect together other elements, not shown in the figure, themselves provided with a PCI interface and which can

  implement, for example, data processing functions.

  Component 28 is a component called AMCC5933QC and

  is marketed by Applied Micro Circuits Corporation.

  It should be noted that the packet transfer device according to the invention does not necessarily correspond to the bridge itself. It can thus, in fact, represent a subset of it formed, for example, of the different

  elements for implementing the processing functions of the

  head of a data packet, taking into account at least one identifier

  bridge, and asynchronous packet transfer.

  The header processing functions are implemented by the computing unit CPU 12 and the ROM memories 14 and RAM 16. The function for transferring an asynchronous packet after processing the header is implemented work by a logic control block 34 and the

  components 30, 32 by order of the CPU 12.

  The bridge 66 shown in FIG. 3 also includes two sets of components also called blocks 30 and 32 respectively serving as interfaces with the serial communication buses 1394, for example denoted 56 and 58 in FIG. 1. Each block or set of components PHY / LINK 1394 consists for example of a PHY component TSB21LV03A and a LINK component TSB12LV01A sold by the company Texas Instruments and of 1394 connectors, for example sold

  by the company Molex, for example under the reference 53462.

  These physical blocks correspond to at least two portions of the bridge which each form what is called a "portai" in English terminology. The control logic block denoted 34 can communicate respectively with the component blocks 30 and 32 by means of buses denoted

  36 and 38, as well as with the PCI interface component 28 by means of a bus 40.

  Buses 42 and 44 also allow data transfers respectively between the PCI interface component 28 and the control logic block 34, as well as the PHY / LINK 1394 component block referenced 30, on the one hand, and, on the other hand, with the logic control block 34 and the block of

  PHY / LINK 1394 components referenced 32.

  This logic control block 34 makes it possible to transmit isochronous or asynchronous data packets coming from the serial communication bus 56 via the PHY / LINK 1394 component block denoted 30 which is associated with it and intended for the RAM memory 16, under the control of the direct access memory function DMA ("Direct Memory Access" in English terminology) which is in the PCI interface component 28 and which will

  was previously initialized by the CPU 12 calculation unit.

  Conversely, this block 34 also makes it possible to transmit isochronous or asynchronous data packets originating from memory 16 to the other PHY / LINK 1394 block denoted 32, with a view to its transmission on the serial communication bus which is associated with it. This also takes place under the control of the direct access memory function DMA ("Direct Memory Access" in English terminology) which is located in the interface component

  PCI 28 and which will have been previously initialized by the CPU 12 calculation unit.

  The control logic block 34 also makes it possible to trigger a PCI interrupt, for example linked to the reception or the transmission of an asynchronous packet via the interface component 28 in order to inform the calculation unit CPU 12. Similarly, the control logic block 34 is capable of generating a PCI interrupt for other types of events such as the reception or the transmission of any other packet of

data on the 1394 bus.

  In addition, the logic block 34 allows access to the various registers of the component blocks 30 and 32 via the PCI interface component 28. The control logic block 34 is a component of the FPGA (Field Programmable Gate Array) type. Anglo-Saxon terminology) which is by

  example marketed by the company Xilinx.

  Each block of components 30 and 32 are associated with registers represented in FIG. 4, used for implementing the method.

transfer according to the invention.

  In the description, a register whose name is suffixed with "_30"

  or "_32" belongs to the respective blocks 30 and 32 described previously in

figure 4.

  The register 91 "routing_label_30", represented on 8 bits, contains an identifier or routing address which identifies the packets which must

  be transferred from bus 56 to bus 58 in the example of bridge 66.

  The register 92 "routingwidth_30", represented on 8 bits, is associated with the register 91 and indicates the number of significant bits of the register 91.

  The registers 91 and 92 are associated with the component block 30.

  The register 93 "routing_label_32", represented on 8 bits, contains an identifier or routing address which identifies the packets which will have to be transferred from bus 58 to bus 56 in the example of bridge 66. The register 94 "routing_width_32", represented on 8 bits, is associated with register 93 and indicates the number of significant bits of register 93. The registers 93 and 94 are

associated with component block 32.

  Register 97 "max_width", represented for example on 32 bits, contains the maximum value that registers 92 and 94 can take. This register is therefore not associated with a particular "portal". At a given time,

  it contains the same value in each bridge of the network considered.

  In the preferred embodiment, the value of registers 92, 94 and 97 is predetermined and equal to "3" for each register in the mode of

realization of the invention.

  Among all the "portals" connected to the same 1394 bus, the

  P1394.1 standard provides for the determination of a particular "portal" called "alpha-

  portal ". The means of determining the" alpha-portal "are known and in particular described in chapter 4.1 of the draft standard P1394.1 version 0.04, of February 7, 1999. These means allow in particular to identify in a constant and devices on the same bus. By extension, these means also make it possible to assign an identifier in the same way

  constant and unique routing to each "portal" of the same bus.

  A routing identifier thus determined, for example with respect to bus 56 for the bridge 66, is stored in the register 91 and identifies the "port" or block of components 30 of FIG. 3. Likewise, a routing identifier thus determined , for example with respect to bus 58 for bridge 66, is stored in register 93 and identifies the "port" or block of components 32 of the

figure 3.

  The register 95 "routing_table_30" in FIG. 4, represented on 960 bits, represents the routing table associated with the component block or "portai" 30, used during the transfer of packets transmitted from the bus 56, with regard to

concerns deck 66.

  The register 96 "routingtable_32", represented on 960 bits, represents the routing table associated with the block of components 32, used during

  transfer of packets sent from bus 58, with regard to bridge 66.

  The structure of this routing table is described in detail in Figure 8.

  The registers 91, 92, 93, 94, 95, 96 and 97, represented in FIG. 4,

  are located in the RAM 16 of the bridge 66 shown in FIG. 3.

  An asynchronous packet, emitted by a source device located on a bus different from the one on which the destination device is located, is

  says "remote" asynchronous packet, as opposed to a local asynchronous packet.

  In addition, when a "remote" asynchronous packet passes, for example from the peripheral 68 (FIG. 1) to the peripheral 69, via the bridges 61, 62, 64, 66 and 67, different treatments are applied by each of these bridges according to their relative position in relation to the device

  source and destination device.

  Thus, when none of the "ports" of a bridge considered is connected either to the bus of the source device, or to the bus of the destination device, the bridge is said to be an "intermediate" bridge. This is the case of bridge 66 when, for example, the device 68 transmits an asynchronous packet to the

peripheral 69.

  FIG. 5 schematically illustrates the processing carried out by bridge 66 as an "intermediate" bridge on fields 80 and 81 of the asynchronous packet which it transfers from bus 56 to bus 58, according to the

direction indicated by arrow 219.

  Figure 5 illustrates one of the advantages of the invention.

  The register 76 is the equivalent of the register 91 shown in FIG. 4 and has, for example, the value "001" in binary representation on 3 significant bits. In addition, register 77 is the equivalent of register 93 shown in FIG. 4, and has, for example, the value "011" in binary representation out of 3

significant bits.

  We will now focus, with reference to FIGS. 5 and 6, on the transfer of an asynchronous data packet denoted 199 from bus 56 to

peripheral 69 of bus 59.

  The asynchronous data packet 199 transits on the bus 56 and is transferred to the bus 58, by the bridge 66, after processing, in the form of a packet 216. The asynchronous packets 199 and 216 conform to the packet structure represented in the figure 2 and differ from each other only by the

  contents of their respective fields destination 80 and source 81.

  Field 80 of packet 199 is broken down into several fields marked 200, 201, 202 and 203. Field 81 of packet 199 is also

  broken down into several fields marked 204, 205, 206, 207 and 208.

  Fields 201 and 202, both represented on 3 bits, contain the routing identifiers or addresses of the "portals" to be taken into account by the bridges 66 and 67 respectively to transfer the packet

  asynchronous to the destination device 69.

  Fields 208, 207 and 206, each represented on 3 bits, contain the routing identifiers or addresses of the "portals" to be taken into account by the bridges 64, 62 and 61 respectively to transfer a packet

  asynchronous back to source device 68.

  Field 203, represented on 6 bits, contains the information which allows bridge 67 to identify the destination device 69 of the packet

  asynchronous among all devices on bus 59.

  Field 204, represented on 6 bits, contains the information which allows bridge 61 to identify the sending device 68 of the packet

  asynchronous among all devices on bus 52.

  Fields 200 and 205, the whole of which is represented on 5 bits, of which all the bits of fields are positioned at "1", contain the marker delimiting fields 202 and 201, on the one hand, fields 208, 207

and 206, on the other hand.

  Fields 201 and 202 form what is called a first information field within the meaning of the invention and identify the path which is to

  browse through data packet 199.

  Fields 206, 207 and 208 form what is called a second information field within the meaning of the invention and identify the path

  already traversed by the data packet 199.

  It should be noted that the first and second fields in the sense

  of the invention may include fields 203 and 204 respectively.

  Fields 200 and 205 form what is called, in the sense of

  the invention, a third information field or marker.

  In the case of packet 216, field 80 includes fields 209, 210, 211 and 203 and field 81 includes fields 212, 213, 214, 215

and 204.

  The field 211, represented on 3 bits, contains the routing identifier to be taken into account by the bridge 67 to transfer the asynchronous packet to the destination device 69. It corresponds to the field

201 of package 199.

  Fields 215, 214 and 213, each represented on 3 bits, as well as fields 209 and 212, together represented on 3 bits, contain the routing identifiers to be taken into account by bridges 66, 64, 62 and 61 respectively, for forward the asynchronous packet, back, to the source device 68. Fields 213 and 214 correspond respectively to fields 207 and 208 of the packet 199. Fields 209 and 212 correspond

in field 206 of package 199.

  Field 210, represented on 5 bits, all the bits of which are positioned at "1", contains the marker delimiting field 211, on the one hand, fields 209 to 215, on the other hand. It corresponds to fields 205 and 200 of the

packages 199.

  On reception of the packet 199, the bridge 66 reads and analyzes the value of the field 202 which it compares with the content of the register 76. Since the two values, expressed on the same number of significant bits, are identical, the

  packet 199 will be transferred from bus 56 to bus 58 in the form of packet 216.

  It will be noted that between the packet 199 and the packet 216, the bridge 66, implementing the invention, has, on the one hand, deleted from the first field of information within the meaning of the invention a first piece of information constituted by the bits "001" belonging to field 202 and, on the other hand, added to the second information field within the meaning of the invention a second piece of information

  constituted by bits "011" of register 77 identifying the "port" considered.

  In FIG. 5, it should be noted that, on the one hand, the deletion of a first item of information (field 202) from the first item of information reduces the length of the latter and, on the other hand, the addition of second information (field 215) in the second information field increases the

length of the latter.

  This second piece of information is represented by field 215.

  The method according to the invention also proceeds, after the deletion of the first information and before the addition of the second information, to the offset of the first, second and third fields

  of information inside fields 80 and 81.

  When one of the bridge's "portals" is connected to the bus of the destination device, the bridge is called the "destination" bridge. This is the case for example of the bridge 67 of FIG. 1 when the peripheral 69 receives a

  remote asynchronous packet from device 68.

  FIG. 6 schematically illustrates the processing carried out by bridge 67 as a "destination" bridge on fields 80 and 81 of the asynchronous packet which it transfers from bus 58 to bus 59, according to

  the direction indicated by arrow 229.

  The register 78 illustrates, for the bridge 67, the register 91 shown in FIG. 4 whose value, on 3 significant bits, is "011" in binary representation. Furthermore, the register 79 illustrates, for the bridge 67, a register 93 represented in FIG. 4, the value of which, on 3 significant bits, is "000" in binary representation. The asynchronous packet 216 which passes on the bus 58, is transmitted

  on bus 59, via bridge 67 after treatment, in the form of a packet 226.

  Asynchronous packets 216 and 226 conform to the packet structure shown in Figure 2 and differ from each other only in the content of

their respective fields 80 and 81.

  In the case of packet 226, field 80 is broken down into several fields 220 and 221 and field 81 is also broken down into

several fields 223, 224 and 204.

  Field 220, represented on 10 bits, all positioned at "1", is

  representative of an asynchronous packet intended for the local bus.

  The "offset" field marked 223 is added by bridge 67 while field 224 contains the routing identifier or address of the "portal" of bridge 67

  associated with bus 59 and stored in register 79.

  On reception of the packet 216, the bridge 67 reads and analyzes the value of the field 211 which it compares with the content of the register 78. Since the two values, expressed on the same number of significant bits, are identical, the

  packet 216 will be transferred from bus 58 to bus 59 in the form of packet 226.

  It will be noted that in the packet 226, all the bits of the field 80 are positioned at "1" in order to identify the asynchronous packet 226 as a packet

  local asynchronous, capable of being received by one of the devices on bus 59.

  During the transfer of the packet 216 across the bridge 67, the latter implementing the method according to the invention, has deleted from a first information field within the meaning of the invention which is formed from the field 211, and possibly from the field 203, a first piece of information consisting of the bits

"011" from field 211 itself.

  This first information field identifies the path remaining at

browse to package 216.

  The bridge 67 then added in a second information field within the meaning of the invention which is formed of the fields 213, 214 and 215, and possibly of the field 204, a second information constituted by the bits "000" of the register 79 d identification of the "portal" considered. This

  second information is represented by field 224.

  This second information field identifies the path traveled by the packet 216 and it will be the so-called "return" path which will allow it,

  possibly be returned to the source device that issued it.

  The third field of information within the meaning of the invention

  corresponds to the marker noted 210 and previously mentioned.

  The method according to the invention also proceeds, after the deletion of the first information and before the addition of the second information, to the offset of the first, second and third information fields. The field 203, represented on 6 bits, allows the "destination" bridge 67, to identify the destination device 69 of the asynchronous packet among all the devices on the bus 59. The field 203 of the packet 216 has been replaced, during the transfer in the bridge 67, by field 221 in packet 226. Field 221 identifies, for example, device 69 among all the devices in the

  bus 59, so that the packet 226 is received by the peripheral 69.

  The field 204, represented on 6 bits, contains the information which allows the bridge 61 to identify the sending device 68 of the packet

  asynchronous among all devices on bus 52.

  When one of the "portals" of the bridge is connected to the bus of the source device, the bridge is called the source bridge. This is the case for example of the bridge 67 of FIG. 1 when the peripheral 69 transmits an asynchronous "remote" packet bound for the peripheral 68, for example in response

in package 226.

  FIG. 7 schematically illustrates the modifications made by the bridge 67 as a "source" bridge, on the fields 80 and 81 of the asynchronous packet which it transfers from the bus 59 to the bus 58, according to the direction

indicated by arrow 239.

  The asynchronous packet 245 sent on the bus 59 by the peripheral 69 is transferred on the bus 58, by the bridge 67, after processing, in the form of a packet 240. The asynchronous packets 245 and 240 conform to the packet structure shown in Figure 2 and differ from each other only

  by the content of their respective fields 80 and 81.

  In the case of packet 245, the destination field 80 is broken down into several fields 241, 242 and 243 and the source field 81 is

  also broken down into several fields 246 and 244.

  The "offset" field 241 is used by the bridge 67 to find all of the routing identifiers to be taken into account, respectively by the bridges 66, 64, 62 and 61, to transfer the asynchronous packet to the destination device 68 Field 242 contains the identifier of

  routing of bridge 67 associated with bus 59 and stored in register 79.

  Field 246, represented on 10 bits, all positioned at "1", is

  representative of an asynchronous packet sent by the local bus.

  In the case of packet 240, the destination field 80 is broken down into several fields 230, 231, 232, 233 and 243 and the source field

  81 is also broken down into several fields 234, 235, 236 and 238.

  Fields 233, 232 and 231, each represented on 3 bits, as well as fields 230 and 234, together represented on 3 bits, contain the routing identifiers or addresses of the "portals" to be taken into account by the bridges 66, 64 respectively. , 62 and 61, to transfer the package

  asynchronous to the destination device 68.

  Field 236, represented on 3 bits, contains the routing identifier to be taken into account by the bridge 67 to transfer the packet back

  asynchronous to the source device 69.

  Field 235, represented on 5 bits, all the bits of which are positioned at "1", contains the marker delimiting fields 230 to 234, of a

on the other hand, from field 236.

  On reception of the packet 245, the bridge 67 reads and analyzes the value of the field 242 which it compares with the content of the register 79. Since the two values, expressed on the same number of significant bits, are identical, the

  packet 245 will be transferred from bus 59 to bus 58 in the form of packet 240.

  It will be noted that in the packet 240, the routing identifiers 230, 231, 232, 233 and 234 representative of the path to be traveled to the destination device 68 and the field 236 representative of the path traveled from the source device 69 have been initialized by the bridge 67 in the

package 240.

  For this, the bridge uses the value stored in the "offset" field 241 of the packet 245 which it will have previously communicated to the sending peripheral 69, for example, via an asynchronous packet. Thus, if, for example, the packet 245 of FIG. 7 constitutes the response of the peripheral 69 to the received packet 226 in FIG. 6, it will be noted that the value of the fields 223 and 224 of the data packet 226 is identical respectively to the value of

  fields 241 and 242 of packet 245 in Figure 7.

  It will also be noted that in this case, the value of the fields 209, 210, 211 of the packet 216 of FIG. 6 is respectively equal to the value of the fields 234, 235 and 236 of the packet 240 of FIG. 7. Likewise, the value fields 212, 213, 214 and 215 of packet 206 is equal respectively to the

  value of fields 230, 231, 232 and 233 of package 240.

  During the transfer of the packet 245 across the bridge 67, the latter implementing the method according to the invention has removed, from a first information field within the meaning of the invention which is formed from the "offset" fields 241 and 242, and possibly of field 243, a first piece of information constituted by the bits "000" of field 242 itself. This first field of information

  identifies the remaining path to the data packet 245.

  The bridge 67 then added in a second information field within the meaning of the invention which is formed of the field 238, a second information constituted by the bits "011" of the register 78 identifying the "port" considered. This second piece of information is represented by the field

236.

  This second information field identifies the path traveled by the packet 216 from the peripheral 69 and it will be the so-called "return" information path which will allow it, if necessary, to be returned.

  to the source device that issued it.

  The third information field within the meaning of the invention corresponds to part of the field 246 which is transformed in the packet 240

in a field 235 called "marker".

  The method according to the invention also proceeds, after the deletion of the first information and before the addition of the second information, to the offset of the first, second and third information fields. Thus, it is understood that, during the transfer of a packet by a bridge, the identifier of the "portai" by which the packet arrives is removed from the first information field because it has become useless and the identifier of the "portal" whereby the packet leaves the bridge is added in a second field

  information in order to reconstruct the path traveled by the packet.

  The two identifiers having the same length, the total length of the first, second and third information fields (Figure 5)

remains unchanged.

  By reducing the length of the first field and increasing the length of the second field as the packet is transferred by different bridges of the network, it is therefore possible to increase the maximum distance traveled by a packet compared to the prior art in which the length of

  each destination and source field remains fixed over time.

  It should be noted that the third field or marker has a length at least equal to the number of bits necessary to code a

"portal" identifier.

  As previously mentioned, the marker comprises a predetermined sequence of bits which can be, for example, a consecutive sequence

  bits all having the same state "0" or "1".

  Field 244, represented on 6 bits, identifies device 69 among all the devices on bus 59. Field 244 of packet 245 has been replaced by field 238 in packet 240. The value of field 238 allows bridge 67 to identify device 69 among all devices

from bus 59.

  Field 243, represented on 6 bits, contains the information which will allow the destination bridge 61 to identify the destination device 68 of the

  asynchronous packet among all devices on bus 52.

  The use and management of the "offset" field are more

  particularly described with reference to Figures 8, 9 and 10.

  Figure 8 is a detailed schematic view of a routing table illustrated by each register 95, 96 of Figure 4 and stored in the RAM memory of each port of a source or destination bridge. The purpose of this table is to associate with a unique index ("offset" in English terminology) on the local bus, a path to reach a peripheral

remote and vice versa.

  This table is composed of a set of elementary records 250 to 259, each elementary record being associated with an index in the table. Records 250, 251, 252, 253, 254, 255, 256, 257, 258 and 259 are respectively associated with the indexes "0", "1", "2", "3", "4",

"5", "6", "7", '8 "," 9.

  The structure of an elementary record is for example

consisting of the following fields.

  Field 270 "path_descriptor" corresponds to a "Path Descriptor", represented on 16 bits and which contains the routing information

  to reach the remote destination device.

  Field 272 "activ" (short for "activity", English terminology

  Saxon of "activity") represented on 16 bits, contains the information concerning

  management at the local bus level of said path descriptor.

  This field is used in particular to know, at a given moment, how many "Request" type transactions, pending "Response"

are being processed.

  This field can also be used to find out from

  how long the basic record was not consulted.

  To do this, a counter is incremented according to a period predefined by the "portal" and is reset to zero each time the information "descriptor of information path" or the index is used. This field thus allows

  optimize the memory management of the routing table.

  It should be noted that the indexes ("offsets") of the elementary records, not in use and / or not having been used since a

  are preferably reused first.

  Field 271 "local_busbit map", represented on 64 bits, makes it possible to describe which devices on the local bus actually use this path descriptor (each of the 64 bits formed by these two fields, indexed from 0 to 63, corresponds to device of which

  the physical identifier has the value of the index in question.

  As previously mentioned, this field makes it possible to optimize the management of the memory of the table, by avoiding to reuse an index which is

  used, even infrequently, by a large number of devices.

  This field has the main advantage of being able to determine, in the case where an index has been reassigned to another elementary record,

  if the index is still current for a given device on the local bus.

  FIG. 8 describes for example a routing table which can contain up to ten elementary records which are then indexed from 0 to 9. Each elementary record contains three 32-bit words. The maximum size of elementary records having been reached, management of

  these are necessary in order to release them before they can be added.

  It will be noted that the length of fields 270, 271 and 272 is indicative and can be reduced or increased according to the capacities of the network. For example, if you allow a maximum of 32 devices per bus, this including bridges, the length of the 271 "local_busbitmap" field can be reduced to 32 bits and the total number of indexes can be increased to 15

  for the same occupation of the memory.

  This management can obey different policies such as for example that according to which elementary registrations not in progress

  of use and having not been used for a certain period are released.

  Likewise, the number of devices that have used and are still likely to use a given basic record can

  advantageously be taken into account.

  FIG. 9 is a schematic view of the algorithm of the method for recovering a path descriptor from an index in the table of

routing described in figure 8.

  This process is, for example, implemented in bridge 67 of the

  FIG. 7 during the transfer of the packet 245 from bus 59 to bus 58.

  During step 801, the method includes a step of receiving a request to recover a path descriptor from

of a given index.

  During step 802, it is checked that the index in question refers to an elementary record in the routing table. In the positive case, the processing continues with step 803. In the negative case, the method returns information signifying that no path descriptor

  is not valid for said index (step 805).

  During step 803, the method includes a verification step according to which the elementary record corresponds well to the index presented by the peripheral at the origin of the request. It may indeed be that the elementary record corresponding to said index has been deleted from the table, then that this index value has been reused to describe another

  basic recording for another device.

  To do this, a set of 64 bits (indexed from 0 to 63) is used to map the devices using recording

elementary in question.

  Each bit is used to find out whether, for the device whose physical identifier has the index value among the 64 bits, the recording

elementary is valid or not.

  In the case where the information is said to be invalid, the method provides for returning information signifying that no path descriptor is

  valid for said index (step 805).

  In the case where the information is valid, step 803 is followed by

step 804.

* During step 804, the method reads the path descriptor, updates the management information relating to the elementary record, and finally returns the path descriptor

for said index.

  Among the management information relating to the elementary registration, the following two actions can in particular be cited: Firstly, when the request for retrieving a path descriptor from an index comes from a transaction of the "Request" type ", a counter indicating the use of this elementary record is incremented if a transaction of type" Response "is expected. This counter will be decremented during a next request to retrieve an index from

  from a path descriptor resulting from a "Response" type transaction.

  Second, each time the basic recording is used, the counter indicating the time since the last

  use of this record is reset.

  This last counter can for example be incremented on a

  time event generated with a predefined period.

  After having returned the path descriptor or the absence of path descriptor for said index, the method plans to return to step 801 to process any new request for retrieving a path descriptor.

  path from an index in the routing table.

  FIG. 10 is a schematic view of the algorithm of the method for retrieving an index from a path descriptor in the table of

routing described in figure 8.

  This process is for example implemented in bridge 67 of the

  FIG. 6 during the transfer of the packet 206 from bus 58 to bus 59.

  During step 811, the method comprises a step of receiving a request to recover an index from a descriptor of

given path.

  During step 812, the method includes a step of verifying that the path descriptor in question is present in the table

Routing.

  In the positive case, step 812 is followed by step 815, during which the method updates, if necessary, the management information relating to the elementary record, and returns the index corresponding to said audit.

path descriptor.

  With regard to the management information relating to the elementary registration, the following two actions can in particular be cited: First, when the request to retrieve a path descriptor from an index comes from a transaction of the "Response" type ", the counter indicating the use of this elementary record

is decremented.

  Second, the counter indicating the time since the

  last use of this record is reset.

  This last counter can for example be incremented on a

  time event generated with a predefined period.

  In the negative case, the method comprises a step 813 during which it is checked whether at least one index (and therefore a record

  elementary) is free in the routing table.

  In the positive case, during a step 814, an index is allocated and used to store the information path descriptor. The bit among all 64 bits (indexed from 0 to 63) corresponding to the physical identifier of the device at the origin of the request, is set in order to validate this elementary record for the

device in question.

  If the index is not free during a step 816, the method proceeds to the release of one or more indexes (and therefore of record (s))

  elementary (s)) in the routing table.

  The next step 817 consists in checking whether the release step has been able to be carried out successfully. In the positive case, the step 814 previously described is again carried out. In the negative case, during a step 818, the method provides for returning information indicating the absence of index (and therefore elementary registration) for said path descriptor. Then,

  step 811 is performed again.

  FIG. 11 represents an algorithm implementing the method of routing asynchronous packets at the level of a bridge according to the

  preferred embodiment of the invention.

  The instructions or steps of such a process are stored in the

ROM memory of each bridge.

  This algorithm concerns the decision to route said packets as well as the transformation of their headers, according to the result of

  analysis of the content of the headers of received packets.

  In the following description, temporary variables

  stored in the RAM memory of the bridge considered (D_BuslD, S_BuslD, in_RI, out_RI, path_register) have been introduced to facilitate the understanding of

  The algorithm describing the process.

  The method begins with step 100 of FIG. 11 consisting in waiting for the reception of an asynchronous packet. When such a packet has been received and stored in memory, we go to step 101 of analysis of the identifier.

  of the destination bus D_BuslD included in the header of said packet.

  In the following description, D_BuslD represents the information

  of the field "destination_lD" 1 of figure 2, in the same way S_BuslD represents

  information from the "source_lD" field 3).

  If said identifier is equal to 3FF16, it is then either a packet sent on the local bus and intended for this local bus, or a remote packet arrived on its destination bus (as described in FIG. 6). In this case of equality, step 101 is followed by step 102 consisting, since this packet is local to said bus, in rejecting the packet without further processing. Step 102 is

  followed by step 100 of waiting for a new asynchronous packet.

  When in step 101 we find an identifier of the destination bus other than 3FF, 6, this means that the packet is at a level

  intermediate bridge and steps 103 and 104 are executed.

  In the following description, according to the preferred mode of

  embodiment of the invention, the routing information or identifier (or label) of the destination path descriptor is read in the least significant bits of the D_BuslD field, the routing information or identifier (or label) of the descriptor of path traveled, is written in the least significant bits of the field S_BuslD, the bits being shifted from one field to another in an adequate manner: For example, shift to the right of the field D_BuslD, shift to the left of the field S_BuslD, each bit resulting from the shift to the left of the most significant bit of the field S_BuslD being inserted, after shift to the right of the bits of the field

  D_BuslD, instead of the most significant bit of the D_BuslD field.

  Other variants consisting of combining read / write routing information of the path descriptors on the high / low weights of the DBuslD and S_BuslD fields with the appropriate offsets are not

  described in the present description.

  Step 103 consists in determining the identifier or routing label of the destination path descriptor in_RI; to do this, the routing identifier or information is extracted from the D_BuslD field of a length or size (in bits) equal to the content of the "routingwidth_30" 92 register (FIG. 4) associated with the "inbound portal" "in English terminology). In the example of figure 5, the field D_BuslD is worth 1111 011 0012, the value "routing_width_30" being equal to 3, the routing label

inRI is equal to 0012.

  Once the value of the packet's in_RI routing identifier or label is known, step 104 makes it possible to compare it with the content of the “routinglabel_30” register 91 constituting the unique identifier or label per bus assigned to said “portal” on which the package in question has been received. If the two values are different, then step 105 is executed. It consists in rejecting the package

  then go to step 100 of the start of the process presented.

  Otherwise, that is to say when the values in_RI and "routinglabel 30" are equal, step 104 is followed by test 106 in order to analyze the identifier of the source bus S_BuslD included in the header of

package processed.

  If said identifier is equal to 3FF16, then the packet is said to be "remote" (recipient on a remote bus) and is received from its source bus (as for example the packet referenced 245 in FIG. 7); its header will be processed according to steps 110, 111, 112, 113 or 114 and 115 described in more detail below. Otherwise, the processed “remote” packet transits on an intermediate bus between its source bus and its destination bus (such as for example the packet referenced 205 in FIG. 5). Processing of its header follows

  then steps 120 and 121 also described below.

  During step 110, a routing index ("offset" in English terminology) is extracted from the DBuslD field of the packet

  defined in the description of Figures 6 and 7) taking into account the value

  "routing_width_30" 92 mentioned above during the explanation of step 103.

  This index ("offset") consists of the (10 - routing_width_30) most significant bits

  of the D_BuslD field, 10 being the width of said D_BuslD field.

  For example, in the case where the field D_BuslD is worth 0001101 0002 and the value "routingwidth_30" is equal to 3, the index will be equal to

00011012.

  Then, during step 111, said index ("offset") is converted into a path identifier according to the method for retrieving a path descriptor from an index in the routing table as described above.

(Figure 9, steps 801 to 805).

  Test 112 consists in verifying whether such a path identifier was found during the cited process. In the negative case, we execute the step

  1 13 consisting in rejecting the processed package.

  In alternative embodiments of the present invention, more sophisticated error processing methods (not shown in the figures) can be envisaged during step 113. Such methods could consist, for example, of sending a negative acknowledgment to the device originating from the packet for which the path descriptor is obsolete, allowing it to adjust its routing table without waiting

  the expiration of a certain duration ("time-out" in Anglo-Saxon terminology).

  Step 113 is followed by step 100 waiting for a new one.

package to be processed.

  In the positive case of test 112, the path identifier or descriptor, returned by operation 111, is stored in the path_register register during step 114. The path_register register is used for managing the path descriptors ( destination and traveled) and is advantageously composed of two sub-fields, each of these sub-fields corresponding to the information respectively contained in the fields D_BuslD and SBuslD. Then, during step 115, the method performs, on the pathregister register, the replacement of the physical identifier of the peripheral present in the source address field 244 of the packet of FIG. 7 by the corresponding virtual identifier , this by using the appropriate conversion table established during each reset ("bus reset" in English terminology) of the source bus 52 (FIG. 1). This table establishing the correspondence between physical and virtual identifiers is well known to those skilled in the art and is therefore not described here. Step 115 is

  followed by step 130, the description of which is given below.

  Back to step 106, if the identifier is different from 3FF16, then this is followed by step 120 of processing a packet received from an intermediate bus which consists in loading (memorizing) the register path_register from the bus identifiers D_BuslD and S_BuslD extracted respectively from the fields "source_lD" 81 and "destination_lD" 80 of the header

(Figure 2) of the processed package.

  It is recalled here that each of the two identifiers of the bus consists of the 10 most significant bits of the corresponding address field (80 or 81), while the remaining 6 bits of said address fields represent the identifier (either physical or virtual) of the device addressed on the given bus. The loading operation takes into account the management mode of the D_BuslD and S_BuslD fields mentioned above (such as, right shift of the D_BuslD field, left shift of the S_BuslD field, each bit resulting from the left shift of the most significant bit of the S_BuslD field being inserted, after shift to the right of the bits of the D_BuslD field, instead

  of the most significant bit of the D_BuslD field).

  Then, during step 121, the content of the path_register register is transformed in the following way (for a better understanding of this step, the reader is requested to refer to figure 5): We mark the sequence of maximum length composed of at least 2 * max_width 1 ("maxwidth" being the value of register 97 in FIG. 4) bits consecutive to "1" constituting the marker or separator between the field

  identifying the destination path and the field identifying the path traveled.

  In the example of the packet 199 illustrated in FIG. 5, the sequence comprises 5 bits at "1": the sequence "011 0012" describes the destination path, and the sequence "011 010 0112" describes the path traveled. It is noted here that by separating the three fields cited in the manner described above, it is possible to assign (in an erroneous manner) to the marker any adjacent bits belonging to the field of the traveled path and / or to the field of the destination path in the case o said bits are equal to "1"; however, this is not a problem for

  the correct functioning of the described algorithm.

  An offset is made in the pathregister register, according to the management mode adopted, by a number of bits equal to routing_width_30 of the bits of the descriptor field of the destination path (identifier of the path to be traveled). The non-significant bits, following the shift, are positioned at "1", the bits of the marker not being modified. The register "routing_width_30" 92 indicates the length in bits of the identifier or label of

  routing on the input bus of the processed packet.

  Thus, in the example of FIG. 5, the bits of the field 202 have disappeared, the bits of the field 201 have been shifted by a number of bits equal to routing_width_30 (on the right in the field "destination_bus_lD" 91 of FIG. 2 ) and now occupy the field referenced 202, the bits that have become insignificant of the field referenced 201 are set to "1", the bits of the marker, referenced by fields 200 and 205 remaining unchanged. Note that the size or length in bits of the marker is in the previous manipulation

  increased by a number equal to routingwidth_30.

  We perform an offset in the path_register register, depending on the management mode adopted, by a number of bits equal to routing_width_32 of the bits of the path traveled marker (identifier of the path traveled), a number of bits equal to routing_width_32 of the bits of the marker then being written. Recall here that the register "routing_width_32" 94 associated with the output "portal" ("outbound portai" in English terminology) actually indicates the length in bits of the identifier or routing label on the output bus of the processed packet . The value of the bits describing the identifier or routing label for the descriptor of the path traveled (identifier of the path traveled) will be determined during step 150 executed subsequently. In the example of FIG. 5, the information bits of fields 205, 206 and 207, describing the path traveled, have been shifted by a number of bits equal to routingwidth_32 (on the left in the "sourcebusIlD" field 93 of Figure 2 then right in the field "destination_bus_lD" 91 of Figure 2) and then occupy fields 209 and 212 respectively for the first, 213 for the second and 214 for the third. Fields 209 and 212 previously part of the marker now contain information describing the path

  traveled. Field 215 will be assigned during the operation described in step 150.

  During the various phases mentioned above and which take place during step 121, the marker has also been displaced by

  relative to its previous position inside the path_register register.

  If the routingwidth_32 value is greater than the value

  routing_width_30, then the length of the marker is reduced by the difference.

  Similarly, if the routing_width_32 value is less than the routing_width_30 value, then the length of the marker is increased by the difference. Note that following this rule, the length of the marker remains greater than or equal to the value 4 * max_width - 1 - routing_width_30 routing_width_32 (which is always greater than or equal to 2 * max_width - 1) in each bridge crossed, provided

  that this condition is met initially.

  This ensures that the marker remains identifiable by each bridge.

  In the example in FIG. 5, the marker or separating field previously consisting of fields 200 and 205, is found, after crossing the bridge,

  represented by field 210, its length having remained 5 bits.

  In the preferred embodiment of the present invention, the size or length of the identifiers or routing labels is fixed throughout the network. This implies that the registers "routing_width_30" 92, "routing_width_32" 94 and "maxwidth" 97 have the same value in each bridge of the network. It will be noted that for the implementation of this preferred embodiment, it suffices that the marker comprises at least a number of bits "equal to the value" max_width "(instead of 2 * max_width - 1 bits in

  the assumption of a variable length of routing identifiers or labels).

  In an alternative embodiment, the registers "routingwidth_30" 92, "routing_width_32" 94 can have different values for a

same network bridge.

  Note that the description made with reference to Figure 1 and which

  above applies to this variant.

  Step 121 is followed by steps 130 of reading the field composed of the "routing_width_32" of the first field (equivalent of D_BuslD) from the path_register register and by the test 131 in order to determine whether all the bits read

  are equal to "1", that is, if the packet arrived on its destination bus.

  If so, steps 140, 141, 142 and 143 are executed, otherwise we

go to steps 150 and 151.

  For a better understanding of the description of the stages

  at 143 of the processing of a packet arriving on its destination bus 69, the

  reader is asked to refer to figure 6.

  During step 140, the field 216 of the header of the asynchronous packet constituting the virtual identifier of the peripheral or equipment 69 recipient of said packet on the bus 59 is replaced by the identifier

  physical 221 corresponding to it using the appropriate conversion table.

  Step 141 consists in converting the identifier of the path covered contained in the path_register register into an index 233 ("offset") according to the

  appropriate method described above (Figure 10, steps 811 to 818).

  During step 142, the header field identifying the path traveled is initialized with the concatenation of said index 223 ("offset") and the content 224 of the register "routing_label_32" 93 (Figure 4) taking into account the number valid bits of the routing identifier or label, indicated by

"routing_width_32" register 94.

  Then, during step 143, the field of the header 220 identifying the destination bus is initialized with the value 3FF16. This treatment

is followed by step 160.

  During step 150 (when the bits read are not all equal to "1"), the bits identifying the path traveled by the path_register register (number indicated by routing_width_32) are initialized with the identifier or routing label 93 stored in the "routing_label_32" register associated with

  "portal" located on the output bus of the processed packet.

  During step 151, the fields identifying the source bus 212, 213, 214, 215, 209 and the destination bus 210, 211 are respectively initialized with the content of the path_register register. This treatment is

also followed by step 160.

  Step 160 consists in transferring the packet to the bus 58 respectively 59. This step is followed by the step 100 waiting for a

new package to be processed.

  FIG. 12 is a schematic view of a bus network during the broadcasting of an address resolution packet on the one hand, and of its corresponding response packet on the other hand. This network is made up of buses 501 to 505 interconnected by bridges 506 to 511. This so-called address resolution packet is sent by a source device 513 in order to obtain the path descriptor then allowing access to the remote device. by means of asynchronous packets as described in standard 1394-95. This address resolution packet is broadcast throughout the bus network ("broadcast" in

Anglo-Saxon terminology).

  A complementary mechanism can be implemented at each portal of a bridge to prevent the packet from being transmitted more than once on the same bus and thus avoid any infinite loopback in the bus network. This mechanism, known to those skilled in the art and described for example in the book "DATA NETWORKS, second edition, by Bertsekas Gallager, Prentice Hall International Editions, ISBN 0-13-201674-5" in the chapter entitled "Flooding and broacasting ", is based for example on the following principles: the packet being broadcast is uniquely identified (for example using the EUI-64 of the source equipment and a sequence number identifying this packet in a unique way in this same source equipment), when a port broadcasts this packet, it memorizes certain information which will then allow it to know whether a broadcast packet it has received should or should not be broadcast on its other portal, if necessary on each of its other portais, in particular according to a previous reception of this same package. For this purpose, the portals must, among other things, manage a so-called "broadcast" verification table such as that described in FIG. 15. In the case where this packet must be broadcast on a bus, the port in question updates the descriptor of path which will allow the response packet to be routed directly to the equipment at the origin of the address resolution packet. The diffusion of this address resolution packet is described in figure 12 by the arrows

520, 521, 522 and 523.

  When each port on the same bridge is grouped together in a single device such as that described in FIG. 3, a single verification table known as

  common "broadcast" can be used for the portals of a given bridge.

  On a given bus, each portal, having an internal EUI64 table of the various devices connected to the bus, is responsible for verifying, upon receipt of an address resolution packet, whether the device sought is present or not. on the bus. In the positive case, the port of the bridge 506 for example of the bus 501 stops the broadcasting of the address resolution packet and transmits an asynchronous response data packet 530 to the bridge 508 which transfers this response in the form of a packet 531 to the bridge 510, destined for the equipment at the origin of the address resolution packet; to do this, the port retrieves from the address resolution packet the path descriptor updated during the broadcast. The asynchronous response data packet en route to the equipment 513 at the origin of the address resolution packet will construct the path descriptor sought. The same is true for the port of bridge 507 which will send an asynchronous data packet from

answer 533.

  It is up to each portal of the bridges of the bus 504, where the equipment 513 at the origin of the address resolution packet is located, to recognize the various asynchronous response data packets, to filter them and to send no only one, referenced 534 in FIG. 12, towards the equipment 513, in the event that it does not already come from the bus 504 ,. To do this, the portal must memorize that the address resolution request was followed by a response, for example by saving the first response received, and for a certain period, data such as the EUI-64 of the equipment sought and the sequence number identifying the address resolution packet uniquely in this source equipment, and by comparing them with those actually received in the other response packets. Any asynchronous response data packets found to be

duplicates are simply ignored.

  FIG. 13 is a schematic view showing the structure of an address resolution data packet 550. This packet format is preferably based on the format of a global asynchronous stream packet (in English terminology "Global Asynchronous Stream Packet "or in

abbreviated "GASP").

  Fields 551 to 556 called "datalength", "tag", channel "," A16 "," sy "," raclIdHi ", and" headerCRC "have constant values defined by

the standardization committee 1394.

  The value of field 557 "sourceIlD" is used to specify the address

of the packet transmitter port.

  Fields 558 to 560 called "specifiierIDhi", "specifiierID_lo", and "version" have constant values defined by the committee

standardization 1394.

  Fields 561 to 568 constitute the data field part ("data field" in English terminology) of a GASP packet and are used

  as follows in the present invention.

  The path descriptor field 561 ("path_descriptor" in English terminology), represented on 20 bits, contains the routing information produced during the routing of the address resolution packet to the destination equipment sought. The value of this field is therefore representative of the path traveled. The useful size of this field is defined from the value of the fields "max_width" 97, "routing_width_30" 92, and "routing_width_32" 94 (Figure 4) and the processing performed on the way

  traversed as explained in step 121 of FIG. 11.

  For example, when an address resolution packet present on the bus 56, and capable of being transferred by the bridge 66 on the bus 58 of FIG. 1, - and that the field 561, includes for example the fields 200 , 205 to 208 described in FIG. 5, - then the content of field 561 will be replaced by fields 210, 209, 212

  at 215 when transferred via bridge 66.

  The field number sequence 562 ("sequence_number" in English terminology), represented on 12 bits, makes it possible to identify this packet in a unique way in the source equipment at the origin of the request

address resolution.

  The EUI-64 high and low source fields 563 and 564 ("SrcEUI_64_hi" and "Src_EUI_64_lo" in English terminology), each represented on 32 bits, describe the EUI-64 of the equipment at the origin of this packet address resolution. This EUI-64 is useful for uniquely identifying the source equipment making the address resolution request. The EUI-64 high and low equipment sought fields 565 and 566 ("DevEUI_64_hi" and "Dev_EUI 64 1o" in English terminology), each represented on 32 bits, describe the EUI-64 of the equipment sought by the equipment behind this address resolution package. This EUI-64

  uniquely identifies the equipment sought.

  When a device wishes to communicate with a remote device, this device sets, among other things, fields 563 and 564 ("SrcEUI_64_hi" and "Src_EUI_64 1o") with its EUI-64, and the sequence number field 562 with a unique value for this equipment (value incremented for example after each transmission of such a packet). By saving, for a predetermined duration, for example equal to one second, this sequence number for each item of equipment transmitting an address resolution packet, each portal of the network can thus avoid

  re-issue this packet on the adjacent bus (s).

  The field "specific information for the response packet" 567 ("response packet type specific information" in English terminology), represented on 48 bits, contains the information necessary to build the response packet to the address resolution packet. This information is positioned by the sending equipment of the address resolution packet. This field specifies in particular, in the case where the response packet is based for example on an asynchronous primary packet ("asynchronous primary packet" in English terminology) of writing type (described in standard 1394-95), the address of destination in the source equipment at the origin of the address resolution packet, address to which the equipment sought can write data in response to the request. The response packet is for example a packet of type request for writing a data block ("write request for

  data block "in Anglo-Saxon terminology).

  A reserved field 568 ("reserved" in English terminology

  Saxon), represented on 16 bits, as its name suggests, is not used

for the moment.

  The value of field 569 "data_CRC" is calculated based on the value of fields 557 to 568 according to rules predetermined by the committee

standardization 1394.

  FIG. 14 is a schematic view showing the structure of an asynchronous data packet, 580, of response to the address resolution packet, 550, described above. This format of such a package is widely described in the 1394-95 standard, and illustrated in FIG. 2. Only the useful fields

  in the context of the present invention are described below.

  As mentioned earlier, the value of the field

  585 "tCode" can for example be "write request for data block".

  A reserved field 590 ("reserved" in English terminology

  Saxon), represented on 16 bits, as its name suggests, is not used at the moment. The field number sequence 591 ("sequence_number" in English terminology), represented on 12 bits, makes it possible to identify this packet in a unique way in the equipment at the origin of the request for

address resolution.

  The EUI-64 high and low source fields 592 and 593 ("SrcEUI_64_hi" and "Src_EUI_64_10" in English terminology), each represented on 32 bits, describe the EUI-64 of the equipment at the origin of the packet. address resolution. This EUI-64 is useful for identifying

  uniquely the equipment that made the address resolution request.

  Fields 592, 593 ("SrcEUI_64_hi", "Src_EUI_64_10") with field sequence number 591 allow in particular each port on the so-called "source" bus (bus where the equipment at the origin of the resolution request is located address) whether a response has already been sent to the device making the address resolution request. The portals on the so-called "source" bus must therefore manage a so-called verification table.

  "response" such as that described in FIG. 15.

  It will be noted that the detection and processing of the loopback is an improvement made to the invention, which uses methods described in the state of the art. In fact, a processing by default of the loopback is implemented by the invention during the processing associated with field 561: When the entire useful area of field 561 of the address resolution packet is used to describe the path traveled, the process for transferring the packet from one bus to another is stopped. Thus the packet transfer method will consume by inserting routing labels, during each loop, part of the useful area of field 561 of the address resolution packet, until filling all of the

  field which has the effect of stopping the transfer of the packet.

  FIG. 15 is a detailed schematic view representing a verification table 600 stored in the RAM memory of FIG. 3. This type of table can be used by the two types of verification previously described: - diffusion of a resolution resolution packet address on the one hand, generation of one and only one response packet corresponding to an address resolution packet on the bus where the equipment is located

  of this address resolution packet.

  Figure 15 describes for example a verification table containing

  a limited number of elementary records noted 601 to 605.

  The EUI-64 high and low source fields 610 and 611 ("SrcEUI_64_hi" and "Src_EUI_64_1o" in English terminology), each represented on 32 bits, describe the EUI-64 of the equipment at the origin of the packet. address resolution. This EUI-64 is useful for identifying

  uniquely the equipment behind the address resolution packet.

  The field number sequence 612 ("sequence_number" in English terminology), represented on 12 bits, makes it possible to identify this packet in a unique way in the equipment at the origin of the packet of

address resolution.

  Management field 613 ("management" in English terminology

  Saxon), represented on 20 bits, makes it possible to associate information with each

  record the table according to the type of the table.

  In the case of a so-called "broadcast" verification table (used to manage the broadcast of an address resolution packet so that this packet is transmitted on each bus of the network, once and only once), the management field can for example contain information indicating whether an address resolution packet has already either been received by the portal or transmitted

  through this portal (a Boolean value may for example be sufficient).

  In the case of a so-called "response" verification table (used to manage the non-response application to a device at the origin of an address resolution packet), the management field can for example contain a information indicating whether a response packet has already either been received by the portal or transmitted by this portal (a Boolean value may for example be sufficient); in a variant not described in the present invention, a counter could provide additional information on the fact that several responses (therefore path descriptors) exist and therefore that a choice could be made on the path descriptor to be retained according to predefined criteria such as the shortest path for example, this variant then requires defining a communication protocol between the different portals in order to change the path descriptor to be used; in a variant not described in the present invention, it is the alpha portal which centralizes all the responses received at the local bus level where the equipment at the origin of the address resolution packet is located and which decides to retain , according to predefined criteria such as the shortest path for example, a path descriptor, and ultimately sends only one response packet

  to the equipment at the origin of the address resolution packet.

  A variant consists in using as information in the management field, in addition to the indicator for passing an address resolution packet or response packet already transmitted, a value indicating for example the duration in correctly defined time units (" timeout "in English terminology) beyond which this record is no longer

  significant and can therefore be destroyed.

  A variant consists in using only one verification table at a time for the "distribution" and the "responses". In this case the management field can be broken down between two fields, one containing information relating to the broadcast of address resolution packets, the other

  to the response packets to this address resolution packet.

  FIG. 16 is a schematic view of the algorithm of the method for receiving an address resolution packet at a portal of a bridge according to the invention. At the source bus, the address resolution packet sent by the source equipment is described by the standard. This package must be understood by the source portals who will translate it into a package of

  address resolution as described in Figure 13.

  During operation 701, the process in charge, at portal level, of receiving packets receives an address resolution packet. During operation 702, the process reads the EUI64 fields

  source and sequence number described above.

  During operation 703, the process checks whether an elementary record, having the source EUI-64 read in the packet received as high and low source EUI-64 fields, already exists in the verification table 600, described in FIG. 15. In the case where the record does not exist, during operation 704, the process creates one with the values of the source and sequence number EUI-64 fields read from the received packet, for example the record 601 described in FIG. 15, then continues with operation 709. In the case where the record already exists in the verification table, during operation 705, the process verifies that the sequence number read from of the received package is strictly greater than the number of

  current sequence of the recording, for example noted 612 in FIG. 15.

  In the negative case (smaller or equal) during operation 706, the address resolution packet is ignored; for example, it may be an older package and no longer valid. In the positive case, the process updates the sequence number of the record with that read from the received packet, during operation 707, as well as the management information (such as those previously mentioned for example, boolean value indicating if an address resolution packet has already passed on the bus seen by the portal, and / or a counter indicating how many identical address resolution packets have been detected on the bus seen by the port, and / or a value indicating for example the duration in correctly defined time units ("timeout" in English terminology) beyond which this record is no longer significant and can therefore be destroyed), at

during operation 708.

  During operation 709, the process checks whether the port has knowledge of the equipment sought, identified by the fields EUI-64 equipment sought high and low ("Dev_EUI_64_hi" and "Dev_EUI 64 _1o"), described in 565 and 566 in Figure 13. In other words, in the case where the equipment sought is located on the same bus (this bus says "bus destination") as the portal in question, then the latter has its EUI-64 in an internal table (this table is not described in the context of the invention since it is defined within the framework of the current specifications of the 1394 bridge standard). In the positive case, during operation 710, the process performs the creation and / or update operations in the routing table previously described in FIGS. 8 and 9, then initiates the sending of a response packet 580 , as described in FIG. 14, to said address resolution packet; the process notably positions the fields of this packet 580 by using the values of the fields of said address resolution packet as follows: the path descriptor field 561 is used to position the fields 581, 582, 587 and 588, the field " specific information for the response packet "567 is used to position the field with the same name 589, - the sequence number field 562 is used to position the field with the same name 591, - the source EUI-64 fields up and down 563 and 564 are used

  to position the fields with the same names 592 and 593.

  In the negative case, during operation 711, the process checks whether the port has received the address resolution packet from the bus on which it is located (otherwise it means that the packet has been received from (or from a) portal of

  bridge to which these portais belong).

  In the positive case (packet received from the bus), the process managing the port sends, during operation 712, the packet to the portal portal (s) constituting the bridge. In the negative case (packet received from the portai), the process managing the portal, during operation 713, updates the path descriptor of the address resolution packet and sends it on the bus, thus continuing the

  broadcast of the packet through the bus network.

  The path descriptor having a finite size, when this path descriptor of the address resolution packet can no longer be updated; the transmission or broadcasting of said address resolution packet is stopped. This processing makes it possible to control the propagation mechanism of the address resolution packet and by the same allows to detect and resolve

closure problems.

  Following operations 710, 712 and 713, the processing of said address resolution packet is then completed and the process returns to

  its initial state, awaiting a new packet, operation 701.

  FIG. 17 is a schematic view of the algorithm of the method for receiving a response data packet following the transmission of an address resolution packet at a portal portal located on the bus where the equipment at the origin of the address resolution packet is located. There are two types of reception of a response data packet: either it is a response data packet sent by a remote portal signifying the presence of the equipment sought on its bus, or is a response data packet sent by a local portal to the source bus and in this case it is the response packet (one and only one) sent to the equipment at the origin of the packet.

address resolution.

  During operation 751, the process, from the portal of the bus where the equipment at the origin of the address resolution packet is located, waits for a response packet following the transmission of a resolution package

address.

  During operation 752, the process checks whether a response packet to said address resolution packet has actually been received. In the positive case, during operation 753, the process checks whether the type of response packet received is a packet sent by a local port on the bus (response packet (one and only one) sent to the equipment at the origin of the address resolution packet). In the negative case, during operation 754, the process acknowledges the response packet as described in standard 1394-95, the response packet being based on an asynchronous primary packet of request type ("request" in English terminology). -saxonne), it must be acknowledged by a response type packet ("response" in English terminology). In the negative case, the process continues processing by operation 760. During operation 755, the process checks whether a response packet for said address resolution packet has already been received by the portal or detected on the "source" bus or if a negative ack has not already been generated on the source bus. In the negative case, o a priori no response packet is expected, during operation 758, the process ignores the packet and returns to the initial state 751. In the positive case, o indeed a response packet is expected , during operation 756, the process memorizes the reception or the detection of a response packet. Then, during operation 757, in the case where the response packet previously received was not already a response packet (one and only one) sent to the equipment at the origin of the address resolution packet, the process sends the response packet (one and only one) to

  the equipment behind the address resolution packet.

  During operation 760, the process checks whether the predefined maximum waiting time has passed. The waiting time must be correctly chosen, for example so that it is greater than the time of the longest outward journey of an address resolution packet

  added to the travel time of any corresponding response packet.

  In the negative case, the process processes the error case during operation 761. In the positive case, During operation 762, if no operation was detected on the source bus, the process sends to the equipment at the origin of the address resolution packet a response packet indicating that no equipment responding to the source EUI-64 specified in the address resolution packet has been found during the maximum authorized waiting time. The process

returns to the initial state 751.

  FIG. 18 is a schematic view of the algorithm of the method for managing the length of the bridge identifiers or routing labels at the level of a bus as a function of the capacity of the bus. The steps or instructions of this method are stored in a ROM memory of at least one of the bridges connected to the bus. It should be noted that the bridge considered connects two parts of a

  network between them, one of the parts consisting of the bus connected to said bridge.

  During step 901, the method provides for detecting an event indicating a first initialization of a bus to which the bridge is

connected.

  During step 902, the bandwidth capacity is determined for said bus (greater bandwidth common to all the

* peripherals present on this bus).

  It should be noted that the bandwidth or throughput capacity

  binary of the bus is a characteristic of it.

  Then, during step 903, the method provides for checking, for the bus, whether the capacity of said bus in bandwidth is less than the bit rate referenced S400 by the standard 1394-95 (S400 meaning a bit rate of 393.216 Mbit / s). In the negative case, during step 904, for said bus, it is checked whether this capacity of the bus in bandwidth is lower than the speed referenced S800 by the standard 1394-95 (S800 meaning a speed of 786.432 Mbit / s ). According to the value of the bandwidth capacity of said bus, the method provides for fixing, on the one hand, the length in bits of the routing identifier or label at said bus during steps 905, 907 and 909, then , on the other hand, the maximum number of bridges or sections making up

  bridges ("portais") authorized on said bus ("max_bridge" in English terminology

  Saxon), this during steps 906, 908 and 910.

  Note that for a bit length of the identifier or routing label of n bits, only 2 "-1 routing label values are authorized because a particular value called separation (marker or

separator) is reserved.

  During step 911, a constant and unique routing identifier is assigned to the "port" of the bridge connected to said bus. This routing identifier value is advantageously calculated in a similar manner by all the "portais" of a bus under the authority of the "alpha portai" defined above, the role of the latter being more particularly to ensure the consistency of the different information between the different "portals" connected to the bus in question. During step 912, the method provides for checking, for said bus, whether the value of the routing identifier assigned to the bridge port in

  question is less than the maximum number of bridges allowed on said bus.

  In the negative case, during step 914, the bridge is positioned in the disabled state ("disabled" in English terminology) and the algorithm continues with step 915. For example, if the coding of identifiers takes place on 3 bits, one cannot identify more than seven bridges in a field of information of identifications. Thus, if an eighth bridge is connected to the bus, it will not be managed at the bus level (bridge deactivated). In the positive case, during step 913, the different parameters and variables allowing the implementation

  of the routing described in this document are initialized.

  Step 915 consists in waiting for an event of type

  bus initialization ("bus reset" in English terminology).

  In the event that this event occurs, during step 916, the algorithm checks whether the configuration of the bridges at the bus level has changed (for example a bridge has been newly connected or an existing bridge has been disconnected). In the negative case, we return to the previous step 915. In the positive case, during step 917, the implementation of the routing described in this document is suspended so that no more packets can

  enter or exit the bus via the bridge.

  Step 918 consists in waiting for a sufficient predefined duration ("time out" in English terminology) so that any device using this bridge in its path descriptor to communicate with a "remote" device considers this path descriptor as obsolete . Consequently, the device must for example generate a packet again

  address resolution before being able to resume all communication.

Next, step 902 is executed.

  Another variant, not described here, consists, for example, during the time interval between the suspension (step 917) of the implementation of the routing described in this document and the revalidation of this implementation of the routing, to be acknowledged. in a particular way any package wishing

transit via the bridge.

  FIG. 19 is a schematic view of the algorithm of the method for managing the length of the bridge identifiers or routing labels at the level of a bus as a function of the number of bridges and therefore of "portals" connected to the bus. The steps or instructions of this process are stored in a

  ROM memory of at least one of the bridges connected to the bus.

  The algorithm of this method strongly resembles that described above with reference to FIG. 18, the difference mainly relating to the characteristic of the bus used to decide the length of the identifier or routing label to be used. In FIG. 18, this characteristic is the capacity in bandwidth in bit rate of a given bus, the objective being to avoid authorizing too many communications passing over said bus. To this end, a bridge is put in the "deactivated" state so that it can no longer transmit information. We take note that

  in the process of figure 18, one seeks to prevent any congestion.

  In the algorithm of figure 19, the characteristic of the bus which is

  taken into account is the number of bridges or "ports" connected on said bus.

  Depending on the number of bridges on said bus, a certain number of bits is

  necessary in order to be able to identify them all in a unique way.

  This algorithm also takes care not to use bits unnecessarily for this identification. The algorithm also makes it possible to put a bridge in the "deactivated" state in the case where too many bits are necessary for the identification

of said bridge.

  Other variants, not described in this document, can easily be envisaged from other characteristics of a part of the network, for example a bus, will be taken into account in the decision.

  assignment of the length of the routing identifier or label to be used.

  During step 951, an event is detected indicating a

  first initialization of a bus to which the bridge is connected.

  Step 952, determines for said bus the number of bridges or

"portais" present on this bus.

  Then, the method provides for checking, for said bus, if the number of bridges is less than 3 during step 953, otherwise if it is less than 7 during step 954, otherwise if it is less than 15 during step 955. In

  if not, the algorithm continues with step 965.

  Depending on the value of the number of bridges connected to said bus, the length in bits of the identifier or routing label at said bus is fixed during steps 956, 958 and 960, and then on the other hand , the maximum number of bridges or "ports" authorized on said bus ("maxbridge" in English terminology), as well as the minimum number of "ports" for said length in bits of the routing identifier or label (" min_bridge "in

  Anglo-Saxon terminology), this during steps 957, 959 and 961.

  During step 962, a constant and unique routing identifier is assigned to the "portal" of the bridge connected to said bus. This routing identifier value is advantageously calculated in a similar manner by all the "portais" of a bus under the authority of the "alpha portai" defined above, the role of the latter being more particularly to ensure the consistency of the different information between the different "portais" connected to the bus

considered.

  During step 963, the method provides for checking, for said bus, whether the value of the routing identifier assigned to the "portal" of the bridge in

  question is less than the maximum number of bridges allowed on said bus.

  In the negative case, during step 965, the bridge is positioned in the disabled state ("disabled" in English terminology) and the algorithm continues with step 966. In the positive case, at during step 964, the various parameters and variables allowing the implementation of the routing described in the

  this document is initialized.

  Step 966 consists in waiting for a bus initialization type event ("bus reset" in English terminology). In the event that this event occurs, during step 967, the algorithm checks whether the configuration of the bridges at the bus level has changed (for example a bridge has been newly connected or an existing bridge has been disconnected) and if the number of bridges ("portals") is outside the range previously defined by min_bridge and maxbridge. In the negative case, the algorithm returns to the previous step 966. In the positive case, during step 968, the implementation of the routing described in this document is suspended so that no more packets can enter or exit the bus by

through said bridge.

  Step 969 consists in waiting for a sufficient predefined duration ("time out" in English terminology) so that any device using this bridge in its path descriptor to communicate with a "remote" device considers this path descriptor as obsolete . Consequently, the device must for example regenerate a packet of

  address resolution before being able to resume all communication.

Next, step 952 is carried out.

  It should be noted that when a bridge connects two parts of a network, two different lengths of identifiers can be determined respectively for the two consecutive portions ("portais") of the bridge considered according to two characteristics respectively specific to

  each of said two parts of the network.

  Thus, in such a case, the marker which delimits two fields of identification information, respectively of the path to be traveled and traveled by the data packet, sees its size or length vary accordingly, so that the difference in size or length between the two identifiers of the two "portais" does not affect the total length of the field consisting of the marker and the two information fields

  identification which must be fixed.

Claims (73)

  1. Method for determining at least one identifier of at least one bridge (60, 61, 62, 63, 64, 65, 66, 67) connecting at least a first part of a network (1, 10) to at least a second part of said network, characterized in that said method comprises the following steps: determination of at least one characteristic of said at least one first part of network (1, 10) to which said bridge is connected, determination of at least one length of at least one identifier (76, 77, 78, 79) associated with said at least one first part of the network (1, 10) as a function of said at least one characteristic, - assignment of at least one identifier having a length which has just been determined to at least one bridge (76, 77, 78, 79) connected to   said at least a first part of the network (1, 10).   2. Method according to claim 1, characterized in that at least one identifier (76, 77, 78, 79) is assigned to said bridge (60, 61, 62, 63,   64, 65, 66, 67) connecting said first and second parts of the network (1, 10).   3. Method according to claim 2, characterized in that said bridge (60, 61, 62, 63, 64, 65, 66, 67) comprising at least two portions each connected to said at least two parts of the network (1, 10 ), at least one identifier (76, 77, 78, 79) is assigned to each of said at least two portions.   4. Method according to one of claims 1 to 3, characterized in that   that said bridge (60, 61, 62, 63, 64, 65, 66, 67) is connected to at least one bus   serial communication (51, 52, 53, 54, 55, 56, 57, 58, 59).   5. Method according to claims 3 and 4, characterized in that   each identifier (76, 77, 78, 79) is unique for a communication bus   given series (51, 52, 53, 54, 55, 56, 57, 58, 59).   6. Method according to one of claims 1 to 5, characterized in that   that the step of determining (903, 904) at least one characteristic of said at least one first part of the network (1, 10) consists in determining its bit rate.   7. Method according to one of claims 1 to 6, characterized in that   that the step of determining (953, 954) at least one characteristic of said at least one first part of the network (1, 10) consists in determining the   number of bridges (60, 61, 62, 63, 64, 65, 66, 67) connected to it.   8. Method according to one of claims 1 to 7, characterized in that   that the step of assigning at least one identifier (76, 77, 78, 79) is carried out for each bridge (60, 61, 62, 63, 64, 65, 66, 67) connected to said at   minus a first part of the network (1, 10).   9. Method according to claim 7, characterized in that the step of assigning at least one identifier (76, 77, 78, 79) is carried out for a predetermined number of bridges (60, 61, 62, 63, 64, 65, 66, 67) connected to said at   minus a first part of the network (1, 10).   10. Method according to claim 9, characterized in that the predetermined number of bridges is equal to the power of 2 of the number of bits   allocated to the identifiers of said bridge minus one unit.   11. Method according to one of claims 1 to 10, characterized in   that said data packet comprises at least two information fields (80, 81) said to identify the path respectively to be traveled and traveled by said data packet, said at least two information fields each having a given length, said method comprising the following steps during the transfer of said data packet across said bridge (60, 61,62, 63, 64, 65, 66, 67): - deletion of at least one first item of information from at least one first item information field (80), thus reducing the length of said first information field by a length corresponding to that of said first information, - adding at least a second information in at least a second information field (81 ), thereby increasing the length of said second information field by a length corresponding to that of said second information.   12. Method according to claim 11, characterized in that the data packet has two opposite ends and said at least two information fields (80, 81) are located at the same end of said data packet.   13. Method according to claim 11 or 12, characterized in that the data packet comprises a third information field called marker (200, 205, 210, 235) which delimits the first and second fields   of information relative to each other.   14. Method according to claim 13, characterized in that the marker (200, 205, 210, 235) has a length at least equal to the number of bits necessary to code an identifier of said bridge in one of the information fields. 15. Method according to claim 13 or 14, characterized in that the marker (200, 205, 210, 235) comprises a predetermined series of bits. 16. Method according to claim 15, characterized in that the marker (200, 205, 210, 235) comprises a consecutive series of bits having all the same state.   17. Method according to claim 16, characterized in that the   marker (200, 205, 210, 235) has a consecutive sequence of bits at 1.   18. Method according to one of claims 13 to 17, characterized   in that it comprises, during the transfer of said data packet across said bridge, a step of shifting the first, second and third fields   between the steps of removing and adding information.   19. Method according to one of claims 13 to 18, characterized   in that the total length of the first, second and third fields is fixed.   20. Method according to one of claims 11 to 19, characterized   in that it comprises, during the transfer of said data packet across said bridge, a step of comparing the length of one of the first and second identification information fields of the packet received from said at least one first part of the network (1, 10) with the length of the same field   of the packet transmitted on said at least a second part of the network (1, 10).   21. Method according to one of claims 13 to 19, characterized   in that when the length of one of the first and second fields of identification information of the packet received from said at least one first part of the network (1, 10) is different from the length of the same field of the packet transmitted on said at least one second part of the network (1, 10), said method comprises a step of modifying the length of the third field of the packet to be transmitted.   22. The method as claimed in claim 21, characterized in that the length of one of the first and second identification information fields of the packet received from said at least one first part of the network (1, 10) is equal to the length of the same field of the packet transmitted on said at least a second part.   23. Method according to one of claims 11 to 22, characterized   in that said first and second information fields contain information relating to said at least one identifier (76, 77, 78, 79) of the bridge (s) (60, 61, 62, 63, 64, 65, 66, 67) arranged on the way to the package of data in the network (1, 10).   24. The method of claim 23, characterized in that said first information field contains information relating to said at least one identifier (76, 77, 78, 79) of the bridge (s) (60, 61, 62, 63, 64 , 65, 66, 67) arranged on the path to be traversed by the data packet in the network (1, 10).   25. The method as claimed in claim 24, characterized in that said at least one first item of information deleted from said at least one first information field corresponds to said at least one identifier (76, 77, 78,   79) of said bridge (60, 61, 62, 63, 64, 65, 66, 67) considered.   26. The method of claim 25, characterized in that, when the bridge (60, 61, 62, 63, 64, 65, 66, 67) considered comprises at least two portions each connected to said at least two parts of the network (1 , 10) and that at least one identifier (76, 77, 78, 79) is assigned to each of said at least two portions, said at least one first item of information deleted from said at least one first information field corresponds to said at least one identifier (76, 77, 78, 79) of the portion of the bridge which is connected to the part of the network (1, 10) by which the data packet reaches said bridge (60, 61, 62, 63, 64, 65, 66, 67).   27. Method according to one of claims 23 to 26, characterized   in that said second information field contains information relating to said at least one identifier (76, 77, 78, 79) of the bridge (s) (60, 61, 62, 63, 64, 65, 66, 67) arranged on the path traveled by the package of data in the network (1, 10).   28. The method as claimed in claim 27, characterized in that said at least one second piece of information added to said at least one second field of information corresponds to said at least one identifier (76, 77, 78,   79) of said bridge (60, 61, 62, 63, 64, 65, 66, 67) considered.   29. Method according to claim 28, characterized in that, when the bridge (60, 61, 62, 63, 64, 65, 66, 67) considered comprises at least two portions each connected to said at least two parts of the network (1 , 10) and that at least one identifier (76, 77, 78, 79) is assigned to each of said at least two portions, said at least one second piece of information added to said at least one second field of information corresponds to said at least one identifier (76, 77, 78, 79) of the portion of the bridge which is connected to the part of the network (1, 10) by which the data packet leaves said bridge (60, 61, 62, 63, 64, 65, 66, 67).   30. Device for determining at least one identifier (76, 77, 78, 79) of at least one bridge (60, 61, 62, 63, 64, 65, 66, 67) connecting at least a first part of '' a network (1, 10) with at least a second part of said network (1, 10), characterized in that said device comprises: means for determining at least one characteristic of said at least one first part of network ( 1, 10) to which said bridge (60, 61, 62, 63, 64, 65, 66, 67) is connected, means for determining at least one length of at least one identifier (76, 77, 78, 79) associated with said at least one first part of the network (1, 10) as a function of said at least one characteristic, - means for assigning at least one identifier (76, 77, 78, 79) having a length which is that just determined to at least one   bridge connected to said at least a first part of the network (1, 10).   31. Device according to claim 30, characterized in that at least one identifier is assigned to said bridge (60, 61, 62, 63, 64, 65, 66, 67)   connecting said first and second parts of the network (1, 10).   32. Device according to claim 31, characterized in that said bridge (60, 61, 62, 63, 64, 65, 66, 67) comprises at least two connected portions   each to said at least two parts of the network (1, 10).   33. Device according to claim 32, characterized in that at least one identifier (76, 77, 78, 79) is assigned to each of said at least two servings.   34. Device according to claim 32 or 33, characterized in that each portion of the bridge (60, 61, 62, 63, 64, 65, 66, 67) comprises means for deleting at least one first information of at least at least a first information field and means for adding at least a second   information in at least a second information field.   35. Device according to one of claims 32 to 34, characterized   in that each portion of the bridge (60, 61, 62, 63, 64, 65, 66, 67) comprises means for reading said at least one first piece of information from said first information field.   36. Device according to one of claims 30 to 35, characterized   in that said bridge is connected to at least one serial communication bus (51, 52, 53, 54, 55, 56, 57, 58, 59).   37. Device according to claims 33 and 36, characterized in that   that each identifier is unique for a serial communication bus   given (51, 52, 53, 54, 55, 56, 57, 58, 59).   38. Device according to claim 36 or 37, characterized in that the serial communication buses (51, 52, 53, 54, 55, 56, 57, 58, 59) are IEEE 1394 standard compliant.   39. Device according to one of claims 30 to 38, characterized   in that the means for determining at least one characteristic of said at least one first part of the network (1, 10) comprise means   determining its bit rate.   40. Device according to one of claims 30 to 39, characterized   in that the means for determining at least one characteristic of said at least one first part of the network (1, 10) comprise means for determining the number of bridges (60, 61, 62, 63, 64, 65, 66 , 67) connected to this one.   41. Device according to claim 40, characterized in that the predetermined number of bridges (60, 61, 62, 63, 64, 65, 66, 67) is equal to the power of 2 of the number of bits allocated to the identifiers of said bridge less a unit.   42. Device according to one of claims 30 to 41, characterized   in that said data packet comprises at least two information fields (80, 81) said to identify the path respectively to be traveled and traveled by said data packet, said at least two information fields each having a given length said device comprising: means for deleting at least one first item of information from at least one first information field, thereby reducing the length of said first information field (80) by a length corresponding to that of said first information, - means for adding at least one second information to at least one second information field (81), thereby increasing the length of said second information field by a length corresponding to that of said second information.   43. Device according to claim 42, characterized in that the data packet has two opposite ends and said at least two information fields (80, 81) are located at the same end of said packet of data.   44. Device according to claim 42 or 43, characterized in that the data packet includes a third information field called marker (200, 205, 210, 235) which delimits the first and second fields   of information relative to each other.   45. Device according to claim 44, characterized in that the marker (200, 205, 210, 235) has a length at least equal to the number of bits necessary to code an identifier (76, 77, 78, 79) of said bridge in Mon information fields.   46. Device according to claim 44 or 45, characterized in that it comprises means for shifting the first, second and third information fields.   47. Device according to one of claims 44 to 46, characterized   in that the total length of the first, second and third fields is fixed.   48. Device according to one of claims 42 to 47, characterized   in that it comprises means for comparing the length of one of the first and second identification information fields of the packet received from said at least one first part of the network (1, 10) with the length of the same field of the packet transmitted on said at least a second part of the network (1.10).   49. Device according to one of claims 44 to 48, characterized   in that it includes means for modifying the length of the third field of the packet to be transmitted.   50. Device according to claim 48 or 49, characterized in that the length of one of the first and second fields of identification information of the packet received from said at least one first part of the network (1, 10) is equal to the length of the same field of the packet transmitted on   said at least a second part of the network (1, 10).   51. Device according to one of claims 42 to 50, characterized   in that said first and second information fields contain information relating to said at least one identifier (76, 77, 78, 79) of the bridge (s) arranged on the path of the data packet in the network (1,). 52. Device according to claim 51, characterized in that said first information field contains information relating to said at least one identifier (76, 77, 78, 79) of the bridge (s) (60, 61, 62, 63, 64 , 65, 66, 67) arranged on the path to be traversed by the data packet in the network (1, 10).   53. Device according to claim 52, characterized in that said at least one first item of information deleted from said at least one first information field corresponds to said at least one identifier (76, 77, 78,   79) of said bridge (60, 61, 62, 63, 64, 65, 66, 67) considered.   54. Device according to claim 53, characterized in that, when the bridge (60, 61, 62, 63, 64, 65, 66, 67) considered comprises at least two portions each connected to said at least two parts of the network (1 , 10) and that at least one identifier is assigned to each of said at least two portions, said at least one first item of information deleted from said at least one first information field corresponds to said at least one identifier (76, 77, 78, 79 ) of the portion of the bridge (60, 61, 62, 63, 64, 65, 66, 67) which is connected to the part of the network (1, 10) through which the data packet arrives said bridge.   55. Device according to one of claims 42 to 54, characterized   in that said second information field contains information relating to said at least one identifier (76, 77, 78, 79) of the bridge (s) (60, 61, 62, 63, 64, 65, 66, 67) arranged on the path traveled by the package of data in the network (1, 10).   56. Device according to claim 55, characterized in that said at least one second information added to said at least one second information field corresponds to said at least one identifier of said bridge   (60, 61, 62, 63, 64, 65, 66, 67) considered.   57. Device according to claim 56, characterized in that, when the bridge considered (60, 61, 62, 63, 64, 65, 66, 67) comprises at least two portions each connected to said at least two parts of the network (1 , 10) and that at least one identifier is assigned to each of said at least two portions, said at least one second item of information added to said at least one second information field corresponds to said at least one identifier (76, 77, 78, 79 ) of the portion of the bridge (60, 61, 62, 63, 64, 65, 66, 67) which is connected to the part of the network (1,10) by which the data packet leaves said bridge. 58. Bridge (60, 61, 62, 63, 64, 65, 66, 67) connecting at least two parts of a data packet communication network (1, 10) to each other, characterized in that said bridge comprises a device for determining at least one identifier (76, 77, 78, 79) of at least one bridge according to one of claims 30 to 57.   59. Data processing apparatus, characterized in that it   comprises a bridge according to claim 58.   60. Apparatus according to claim 59, characterized in that said device is a printer.   61. Apparatus according to claim 59, characterized in that said device is a server.   62. Apparatus according to claim 59, characterized in that said device is a computer.   63. Apparatus according to claim 59, characterized in that said device is a fax machine.   64. Apparatus according to claim 59, characterized in that said device is a scanner.   65. Apparatus according to claim 59, characterized in that said device is a VCR.   66. Apparatus according to claim 59, characterized in that said device is a decoder.   67. Apparatus according to claim 59, characterized in that said device is a TV.   68. Apparatus according to claim 59, characterized in that said device is a camcorder.   69. Apparatus according to claim 59, characterized in that said   device is a digital camera.   70. Apparatus according to claim 59, characterized in that said   camera is a digital still camera.   71. Network (1, 10) for communicating data packets comprising at least two parts interconnected by at least one bridge (60, 61, 62, 63, 64, 65, 66, 67), characterized in that said bridge conforms to the claim 58.   72. Network (1, 10) according to claim 71, characterized in that each of said at least two parts of said network (1, 10) comprises at least one serial communication bus (51, 52, 53, 5, 55, 56 , 57, 58, 59) to which   is connected said bridge (60, 61, 62, 63, 64, 65, 66, 67).   73. Data packet communication network (1, 10) comprising at least two parts linked together by at least one bridge (60, 61, 62, 63, 64, 65, 66, 67), characterized in that said network (1, 10) includes   a data processing apparatus according to one of claims 59 to 70.