FR2804812A1 - Procede et dispositif de communication entre un premier et un deuxieme reseau - Google Patents
Procede et dispositif de communication entre un premier et un deuxieme reseau Download PDFInfo
- Publication number
- FR2804812A1 FR2804812A1 FR0001553A FR0001553A FR2804812A1 FR 2804812 A1 FR2804812 A1 FR 2804812A1 FR 0001553 A FR0001553 A FR 0001553A FR 0001553 A FR0001553 A FR 0001553A FR 2804812 A1 FR2804812 A1 FR 2804812A1
- Authority
- FR
- France
- Prior art keywords
- network
- packet
- bus
- transmission
- communication
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/40052—High-speed IEEE 1394 serial bus
- H04L12/40058—Isochronous transmission
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
- H04L12/283—Processing of data at an internetworking point of a home automation network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/40052—High-speed IEEE 1394 serial bus
- H04L12/40117—Interconnection of audio or video/imaging devices
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
- H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/805—QOS or priority aware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/822—Collecting or measuring resource availability data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
- H04L12/2838—Distribution of signals within a home automation network, e.g. involving splitting/multiplexing signals to/from different paths
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Automation & Control Theory (AREA)
- Multimedia (AREA)
- Computing Systems (AREA)
- Small-Scale Networks (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
L'invention concerne un procédé de transmission de paquets de données d'un premier réseau vers un deuxième réseau, l'un des réseaux étant un bus de communication véhiculant des paquets de données de types isochrones et asynchrones, caractérisé en ce que, l'autre réseau étant un réseau à commutation de paquets, ledit procédé comporte, effectuée au niveau d'un dispositif de communication connecté au bus de communication et faisant partie du réseau à commutation de paquets, une étape de réservation de ressources adaptée aux types de paquets de données destinés au deuxième réseau.
Description
La présente invention concerne un réseau de communication comportant au
moins deux bus de communication interconnectés véhiculant
chacun des données de types isochrones et asynchrones.
On connaît des réseaux de communication qui sont formés de
plusieurs bus de communication série conformes à la norme IEEE 1394.
Cette norme concerne des bus de communication série de performances élevées et communiquant, par exemple, des données à des
vitesses comprises entre 100 et 200 Mbps, voire de l'ordre de 400 Mbps.
Ces bus sont organisés en réseau, c'est-à-dire qu'ils sont reliés entre eux par des équipements d'interconnexion que l'on nomme des "ponts"
("bridges" en terminologie anglo-saxonne).
Les ponts reliant des bus de communication série font plus
particulièrement l'objet de la norme P1394.1 qui est en cours d'élaboration.
Cette norme définit un équipement qui assure deux interfaces, à savoir, une interface entre l'équipement lui même et un bus de communication série 1394 et une interface entre cet équipement et un autre bus de
communication série 1394.
La norme P1394.1 prévoit notamment d'étendre les services asynchrones et isochrones déjà définis pour un bus local de communication série à hautes performances à un ou plusieurs autres bus de communication
série à hautes performances par l'intermédiaire d'un ou plusieurs ponts.
Chaque bus de communication série d'un tel réseau relie différents appareils de traitement de données ou périphériques entre eux tels que, par exemple, des imprimantes, serveurs, ordinateurs, scanners, décodeurs (connus en terminologie anglo-saxonne sous le terme de " set-top box "), téléviseurs, magnétoscopes, enceintes acoustiques, caméras numériques,
appareils photographiques numériques, caméscopes...
La mise en réseau de bus de communication série par l'intermédiaire de ponts risque cependant de poser de sérieux problèmes pour ceux désirant les installer et en assurer la gestion, notamment pour les
particuliers qui ne sont généralement pas des administrateurs de réseaux.
En effet, bien que la technologie liée aux bus de communication série conformes à la norme IEEE 1394 semble très prometteuse pour les applications domestiques, I'installation, la gestion et l'utilisation de ponts
semblent au contraire plutôt compliquées pour un particulier.
Si, par exemple, un utilisateur souhaite relier entre eux sous la forme d'un réseau deux bus de communication série, I'un connectant un ordinateur à une imprimante et l'autre reliant entre eux une télévision, un magnétoscope, un caméscope et un décodeur, il va devoir choisir une topologie
pour le réseau.
Le choix de cette topologie repose sur l'analyse des besoins de l'utilisateur, des performances des différents périphériques, de leur localisation
dans l'habitation etc...
L'utilisateur devra ainsi définir une topologie de réseau en regroupant plusieurs appareils de traitement de données ou périphériques entre eux, par exemple, en fonction de leurs relations en termes de données échangées et installer un pont assurant l'interface entre les bus à un endroit plutôt qu'à un autre afin d'éviter les goulets d'étranglement (connus en terminologie anglo-saxonne sous le terme de "bottleneck") et, d'une manière plus générale, pour optimiser les ressources du réseau. Ceci devra également se faire en limitant le nombre de ponts et de câbles pour préserver le coût
global du réseau.
D'autre part la norme 1394.b propose des solutions d'interconnection de périphériques 1394 basées sur de la fibre optique en plastique ou en verre. Ces solutions sont très difficiles à mettre en oeuvre de par la fragilité de la fibre optique et nécessitent donc l'intervention de spécialistes. Ceci signifie donc qu'une telle installation n'est pas facilement modulable à tout instant par l'utilisateur. De plus l'utilisation de la fibre optique
signifie que la distance entre les équipements est réduite.
On connaît d'autre part, d'après le document US 5 940 387, des réseaux de communication dédiés aux applications grand public. Ce genre de réseaux permet, d'une part, de recevoir des applications de natures différentes venant de réseaux extérieurs comme par exemple d'un réseau commuté ou encore de réseaux sans fil de communication par satellite pour véhiculer des
applications liées à la télévision et, d'autre part, de connecter les équipements.
Dans un tel réseau la connexion vers le réseau extérieur est assurée par un adaptateur. L'originalité d'un tel réseau repose sur le fait que chaque terminal de réception, par exemple une télévision, peut recevoir des applications de l'extérieur sans être directement rattaché à un adaptateur réseau. Chaque terminal est relié, d'une part, à un adaptateur de réseau par des liens de type Ethernet et, d'autre part, à un dispositif électronique, connu en terminologie anglosaxonne sous le terme " set-top box ", qui se charge de transmettre au terminal de réception le signal approprié. Dans ce type de réseaux basé sur une passerelle représentée par l'adaptateur réseau, se pose le problème de goulot d'étranglement lorsque plusieurs terminaux doivent accéder au réseau extérieur. La structure du réseau ne permet pas une augmentation de la bande passante de manière illimitée mais, au contraire, cette dernière s'avère de plus en plus restreinte lorsque le nombre de terminaux est de plus en plus élevé. Il semble donc difficile sur un tel réseau de garantir une qualité de services
suffisante pour y véhiculer du trafic isochrone.
Il serait par conséquent intéressant de pouvoir transmettre des données isochrones et asynchrones d'un bus de communication à un autre bus de communication en essayant de remédier à au moins un des problèmes
mentionnés ci-dessus.
La Demanderesse a ainsi prévu de relier entre eux deux bus de communication par un réseau à commutation de paquets qui est apte à transmettre, du premier bus au deuxième bus, des données de types
isochrones et asynchrones véhiculées par ledit premier bus.
En installant un réseau à commutation de paquets de données qui assure l'interface entre deux bus de communication véhiculant des données isochrones et asynchrones, on fixe ainsi la topologie du réseau de communication tout en évitant à l'utilisateur les inconvénients liés au choix de la topologie et donc à l'analyse de ses besoins, aux performances des différents appareils de traitement de données ou périphériques, à leur localisation dans
l'habitation etc...
Par ailleurs, un réseau commuté est d'une gestion relativement facile ce qui présente un avantage pour un utilisateur qui n'est généralement
pas un administrateur de réseau.
En outre, dans un réseau commuté, les temps de propagation étant moins critiques que sur un bus il est possible d'augmenter la longueur des câbles indépendamment du temps de propagation. Ceci permet avantageusement d'éloigner les bus de communication les uns des autres et donc l'utilisateur pourra plus aisément qu'auparavant disposer des périphériques connectés à des bus différents dans des pièces séparées du bâtiment. Selon une caractéristique, le réseau commuté est apte à réserver
des ressources adaptées aux types de paquets de données à transmettre.
D'une manière plus générale, si le réseau de communication comporte plusieurs bus de communication, la présente invention prévoit avantageusement de fédérer tous ces bus par l'intermédiaire d'un seul réseau commuté. Pour assurer la transmission de données isochrones et asynchrones d'un premier bus de communication vers un deuxième bus de communication par l'intermédiaire d'un réseau commuté il faut assurer la transmission, d'une part, du premier bus vers le réseau commuté et, d'autre
part, du réseau commuté vers le deuxième bus.
Ainsi, d'une manière générale, pour assurer une telle transmission la présente invention vise un procédé de transmission de paquets de données d'un premier réseau vers un deuxième réseau, I'un des réseaux étant un bus de communication véhiculant des paquets de données de types isochrones et asynchrones, caractérisé en ce que, I'autre réseau étant un réseau à commutation de paquets, ledit procédé comporte, effectuée au niveau d'un dispositif de communication connecté au bus de communication et faisant partie du réseau à commutation de paquets, une étape de réservation de ressources
adaptée aux types de paquets de données destinés au deuxième réseau.
Selon une autre caractéristique, la réservation de ressources dite en mode connecté a lieu au moins sur le deuxième réseau pour les paquets de
données isochrones.
Ainsi, les paquets ne sont pas bloqués sur le deuxième réseau qui
ne constitue pas un goulot d'étranglement pour les paquets.
Selon un autre aspect, la réservation de ressources concerne
également des ressources internes au dispositif de communication.
Ainsi, lorsqu'un paquet doit être émis, le dispositif possède les ressources nécessaires pour le traiter et, par exemple, le paquet n'est donc pas
écrasé par d'autres paquets.
Selon une autre caractéristique, pour les paquets de données isochrones, la réservation de ressources internes au dispositif de communication est effectuée en fonction des ressources réservées sur le
deuxième réseau.
Ceci contribue à une meilleure gestion des ressources et à un
partage de celles-ci entre le réseau et le dispositif.
Selon une caractéristique particulière, les ressources internes adaptées aux paquets isochrones comprennent au moins une zone mémoire
d'une unité de mémorisation à double port.
Cette zone mémoire permet de faire du contrôle de flux entre les
deux réseaux.
Selon une autre caractéristique, le procédé tel que proposé par l'invention comporte une étape de stockage de paquets de données isochrones
dans les ressources internes réservées.
Grâce à cette caractéristique, le contrôle de flux est plus facile.
Selon une autre caractéristique, le procédé tel que proposé par l'invention comporte une étape de transfert de paquets de données isochrones entre les ressources internes réservées et un moyen d'interfaçage avec l'un des réseaux. Selon une autre caractéristique, la réservation de ressources pour les paquets de données isochrones est effectuée avant une étape de réception
des paquets au niveau du dispositif de communication.
Ainsi les paquets de données ne sont pas perdus ni écrasés au
niveau du dispositif de communication.
Selon une caractéristique propre aux paquets de données asynchrones, la réservation de ressources concerne uniquement des
ressources internes au dispositif de communication.
Selon une caractéristique particulière, les ressources internes adaptées aux paquets asynchrones comprennent au moins une zone mémoire d'un moyen de stockage (RAM) associé à une unité centrale de traitement
(CPU) interne au dispositif de communication.
Selon une autre caractéristique, le procédé tel que proposé par l'invention comporte une étape de stockage de paquets de données
asynchrones dans le moyen de stockage (RAM).
En effet, les paquets asynchrones peuvent être transférés de manière plus discontinue sur le réseau car ils n'ont pas d'exigence de temps de transfert. Par contre, le dispositif de réception doit pouvoir les recevoir lorsqu'ils arrivent à destination et le dispositif d'émission doit pouvoir les stocker avant de
les émettre lorsque le réseau est saturé.
Selon encore une autre caractéristique, le procédé tel que proposé par l'invention comporte une étape de stockage intermédiaire des paquets de données asynchrones dans une unité de mémorisation à double port. Ainsi, le dispositif peut commencer à recevoir des données même si l'unité de traitement dudit dispositif ne peut les traiter immédiatement. Les données sont stockées dans la mémoire double port avant d'être stockées dans
la mémoire associée au moyen de traitement.
Selon une caractéristique particulière, le procédé tel que proposé par l'invention comporte une étape de transfert de paquets asynchrones entre l'unité de mémorisation à double port et le moyen de stockage (RAM) lorsque le
deuxième réseau est un bus de communication.
Selon une autre caractéristique, le procédé comporte, effectuée au niveau d'un dispositif de communication connecté au bus de communication et faisant partie du réseau à commutation de paquets, une opération de
commutation de paquets.
Ceci offre tous les avantages de la commutation de paquets, à savoir la possibilité de véhiculer plusieurs paquets simultanément sur différents
liens du réseau et donc un grand débit de données.
Selon une caractéristique particulière, l'opération de commutation
de paquets consiste à recevoir un paquet venant du premier réseau, c'està-
dire soit du réseau à commutation de paquets soit du bus de communication, à analyser l'en-tête du paquet pour connaître sa destination et à transmettre ledit
paquet vers ladite destination.
Selon une caractéristique particulière, le procédé tel que proposé par l'invention comporte une étape de transfert entre le moyen de stockage (RAM) et l'unité de mémorisation à double port lorsque le deuxième réseau est
le réseau à commutation de paquets.
Selon une caractéristique particulière, la réservation de ressources internes adaptée aux paquets asynchrones est effectuée après une
étape de réception d'un paquet asynchrone.
Ainsi on ne mobilise pas de ressources inutilement dans le noeud.
Selon une caractéristique particulière, la réservation de
ressources internes est effectuée paquet par paquet.
Ainsi la quantité de ressources devant être disponibles n'est pas
trop élevée.
Selon une autre caractéristique, les ressources internes au dispositif de communication sont libérées lorsque le paquet a été transmis sur
le deuxième réseau.
Selon une caractéristique, lorsque le deuxième réseau est le réseau à commutation de paquets, la réservation de ressources pour les
paquets isochrones concerne l'établissement d'une connexion sur ce réseau.
Selon une autre caractéristique, les ressources réservées en mode connecté sur le deuxième réseau sont libérées lorsque la connexion est terminée. Ainsi, on ne bloque pas indéfiniment les ressources internes au
dispositif ni les ressources du réseau commuté.
Selon une caractéristique particulière le procédé est caractérisé en ce qu'il comporte lorsque le premier réseau est le bus de communication: une étape de détermination, au niveau d'un dispositif de communication dit source connecté au bus de communication et faisant partie du réseau à commutation de paquets, pour chaque information qu'il a à transmettre, d'un chemin à faire suivre à ladite information sur ledit réseau commuté, - une étape d'information au cours de laquelle ledit dispositif de communication source diffuse, à destination de tous les autres dispositifs de communication du réseau, une information représentative de la bande passante nécessaire pour effectuer une transmission en mode connecté, et une étape d'attribution de bande passante au cours de laquelle on attribue, d'une part, aux transmissions en mode connecté, la bande passante qui leur est nécessaire et, d'autre part, tout ou partie de la bande passante disponible
à chaque transmission à effectuer en mode non connecté.
Ainsi, tous les dispositifs de communication du réseau sont immédiatement informés de chaque connexion et des ressources du réseau qui
lui sont affectées.
Avant d'effectuer la transmission d'un paquet en mode non connecté, chacun des dispositifs de communication susceptibles de le faire, peut vérifier que chacun des liens, ou segments, du chemin que va suivre ce paquet est disponible pour la transmission de ce paquet. Les engorgements
peuvent ainsi être évités.
La régulation de la charge dédiée au trafic en mode non connecté peut ainsi être effectuée en fonction des fluctuations du trafic en mode connecté (temps réel), ce qui permet d'optimiser en permanence l'utilisation du réseau et
d'éviter les engorgements.
Selon une autre caractéristique, le procédé de transmission de paquets est caractérisé en ce qu'il comporte, pour l'établissement d'une connexion: effectuée par le dispositif de communication source destiné à transmettre de l'information sur ledit chemin, une étape de transmission à destination de chaque dispositif de communication placé sur ledit chemin, appelé "intermédiaire" d'une information représentative de la bande passante nécessaire
pour ladite connexion.
Grâce à ces dispositions, avant d'établir une connexion, on vérifie que le réseau peut supporter la charge potentielle associée à la connexion à établir. En outre, cette vérification est faite par chaque dispositif de communication
placé sur le chemin associé à cette connexion.
Cette prise en compte de la charge estimée revient à effectuer une
estimation de la congestion du réseau.
Selon une autre caractéristique particulière, le procédé de transmission de paquets est caractérisé en ce qu'il comporte, pour chaque transmission d'information, une opération de contrôle de flux effectuée par le
dispositif de communication source du chemin suivi par ladite information.
Grâce à ces dispositions, le procédé selon l'invention implémente un contrôle de flux au niveau des liens, aussi bien pour le trafic connecté que pour le trafic non connecté, sur un réseau à commutation de paquet. Ces dispositions
reviennent à effectuer une détection de la congestion du réseau.
Selon une autre caractéristique le procédé de transmission de paquets est caractérisé en ce qu'il comporte une opération de la transmission
d'information prenant en compte plusieurs niveaux de priorité.
Selon une autre caractéristique, le procédé de transmission de paquets est caractérisé en ce qu'au moins un niveau de priorité est affecté à la
transmission en mode non connecté.
Grâce à ces dispositions, tout le trafic en mode non connecté est transmis avec le même niveau de priorité, ce qui garantit un accès équitable
pour tous les dispositifs de communication du réseau.
Selon une autre caractéristique, le procédé de transmission de paquets selon l'invention est caractérisé en ce que, au cours de l'étape d'attribution de bande passante, la bande passante associée au niveau de priorité correspondant au mode non connecté varie en fonction d'une durée
n'ayant donné lieu à aucune transmission.
Le procédé selon l'invention permet ainsi d'augmenter la bande passante allouée aux transmissions en mode non connecté, lorsque la durée n'ayant donné lieu à aucune transmission augmente, ce qui est signe d'une
absence de congestion du réseau.
Selon un deuxième aspect, I'invention concerne un procédé de transmission de paquets de données de types isochrones et asynchrones entre deux bus de communication interconnectés, caractérisé en ce que lesdits bus sont interconnectés par un réseau à commutation de paquets, ledit procédé comportant une étape de réservation de ressources sur le réseau à commutation de paquets adaptée aux types de paquets provenant d'un premier
bus et destinés au second bus.
Selon une caractéristique, le procédé comporte une étape de réservation de ressources sur le second bus adaptée aux types de paquets
provenant du premier bus et destinés audit second bus.
Selon une autre caractéristique, l'étape de réservation de ressources adaptée aux paquets isochrones sur le réseau à commutation de paquets est plus particulièrement effectuée: - au niveau d'un dispositif de communication dit source connecté au premier bus et faisant partie du réseau à commutation de paquets, - au niveau d'un dispositif de communication dit destinataire connecté au second bus et faisant partie du réseau à commutation de paquets, - sur le réseau à commutation de paquets entre lesdits
dispositifs source et destinataire.
Selon une caractéristique particulière, le procédé comporte: - une étape de détermination, au niveau d'un dispositif de communication dit source connecté au premier bus de communication et faisant partie du réseau à commutation de paquets, pour chaque information qu'il a à transmettre, d'un chemin à faire suivre à ladite information sur ledit réseau commuté, - pour ledit dispositif de communication source qui doit effectuer une transmission en mode connecté, une étape d'information au cours de laquelle ledit dispositif de communication diffuse, à destination de tous les autres dispositifs de communication du réseau, une information représentative de la bande passante nécessaire pour ladite transmission en mode connecté, et - une étape d'attribution de bande passante au cours de laquelle on attribue, d'une part, aux transmissions en mode connecté, la bande passante qui leur est nécessaire et, d'autre part, tout ou partie de la bande
passante disponible à chaque transmission à effectuer en mode non connecté.
Selon une autre caractéristique, le procédé comporte, pour l'établissement d'une connexion: - effectuée par le dispositif de communication source destiné à transmettre de l'information sur ledit chemin, une étape de transmission à destination de chaque dispositif de communication placé sur ledit chemin, appelé "intermédiaire" d'une information représentative de la bande passante nécessaire pour ladite connexion, et - effectuée par chaque dispositif de communication intermédiaire sur ledit chemin, une opération de détermination de disponibilité du lien menant au dispositif de communication suivant sur ledit chemin et, en cas d'indisponibilité, une opération de transmission à destination du dispositif de communication
source, d'une information représentative de l'indisponibilité dudit chemin.
Selon encore d'autres caractéristiques: - le procédé comporte, pour chaque transmission d'information, une étape de contrôle de flux effectuée par chacun des dispositifs de communication intermédiaires du chemin suivi par
ladite information.
- au cours de l'opération d'attribution de bande passante, la bande passante associée au niveau de priorité correspondant au mode non connecté varie en fonction d'une durée n'ayant donné lieu à aucune transmission. La nouvelle structure de réseau de bus de communication mentionnée plus haut est obtenue à partir d'éléments de structure intermédiaires nouveaux qui sont des dispositifs de communication faisant également partie de la présente invention pour laquelle la protection est recherchée. Ainsi, selon un troisième aspect, I'invention concerne un dispositif de communication assurant la transmission de paquets de données d'un premier réseau vers un deuxième réseau, I'un des réseaux étant un bus de communication véhiculant des paquets de données de types isochrones et asynchrones, caractérisé en ce que le dispositif, étant connecté audit bus et faisant partie d'un réseau à commutation de paquets constituant l'autre réseau, comporte des moyens de réservation de ressources adaptée aux types de
paquets de données destinés au deuxième réseau.
Le dispositif de communication selon l'invention est donc configuré pour recevoir les deux types de données véhiculées par un bus de communication et pour les transmettre sur le réseau commuté de manière
adaptée à chaque type de données et inversement.
C'est ainsi que la transmission de données isochrones fait intervenir au préalable des moyens de réservation de ressources dans le deuxième réseau (réseau commuté ou bus), alors que la transmission de données asynchrones ne nécessite pas de réservation de ressources dans le
deuxième réseau.
De telles ressources comprennent notamment la bande passante nécessaire à la transmission ainsi que le numéro de canal virtuel utilisé et, d'une manière générale, l'établissement d'une connexion lorsque le deuxième
réseau est le réseau commuté.
Le dispositif selon l'invention est apte à transmettre sur le réseau commuté des données isochrones et asynchrones provenant, soit du dispositif
lui-même, soit d'autres dispositifs de communication du réseau commuté.
Le dispositif selon l'invention est également apte à transmettre sur
le bus des données isochrones et asynchrones provenant du dispositif lui-
même. Selon un quatrième aspect, I'invention vise un appareil de traitement de données, caractérisé en ce qu'il est adapté à mettre en oeuvre un
procédé tel que décrit dans l'invention.
Selon un autre aspect, I'invention vise un appareil de traitement de
données associé à un dispositif de communication tel que brièvement décrit ci-
dessus.
L'appareil de traitement de données est, par exemple, une imprimante.
L'appareil de traitement de données est, par exemple, un serveur.
L'appareil de traitement de données est, par exemple, un ordinateur.
L'appareil de traitement de données est, par exemple, un télécopieur.
L'appareil de traitement de données est, par exemple, un scanner.
L'appareil de traitement de données est, par exemple, un magnétoscope. L'appareil de traitement de données est, par exemple, un décodeur
(appelé "set top box" en terminologie anglo-saxonne).
L'appareil de traitement de données est, par exemple, un téléviseur.
L'appareil de traitement de données est, par exemple, un caméscope. L'appareil de traitement de données est, par exemple, une caméra numérique. L'appareil de traitement de données est, par exemple, un appareil
photographique numérique.
Selon un autre aspect, I'invention vise également un réseau de communication comportant des dispositifs adaptés à mettre en oeuvre un
procédé selon l'invention.
L'invention concerne en outre un réseau de communication comportant au moins deux bus de communication interconnectés véhiculant chacun des données de types isochrones et asynchrones, caractérisé en ce que ledit réseau comporte un réseau à commutation de paquets comportant au moins un dispositif tel que brièvement exposé ci-dessus et qui est connecté à
l'un des bus constituant un réseau.
Selon une caractéristique, le réseau à commutation de paquets comporte au moins un dispositif tel que brièvement exposé ci-dessus et qui est
connecté à l'autre bus constituant également un réseau.
Selon une autre caractéristique, le réseau à commutation de paquets comporte au moins un appareil de traitement de données conforme au bref exposé qui précède et qui est connecté à l'un des bus constituant un réseau. L'invention vise par ailleurs un moyen de stockage d'informations, éventuellement totalement ou partiellement amovible, lisible par un ordinateur ou un processeur contenant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre du procédé tel que brièvement
exposé ci-dessus.
L'invention vise en outre un moyen de stockage d'informations lisible par un ordinateur ou un processeur contenant des données provenant de
la mise en oeuvre du procédé tel que brièvement exposé ci-dessus. L'invention vise par ailleurs un "produit programme d'ordinateur"
("computer program product" en terminologie anglosaxonne) comportant des séquences d'instructions pour mettre en oeuvre le procédé selon l'invention
conforme à ce qui précède.
Les avantages relatifs au dispositif de communication, à l'appareil de traitement de données, au réseau de communication comportant un dispositif, au réseau de communication comportant un appareil de traitement de données ainsi qu'aux moyens de stockage d'informations et au "produit programme d'ordinateur" étant les mêmes que ceux exposés cidessus
concernant le procédé, ils ne sont pas rappelés ici.
D'autres caractéristiques et avantages apparaîtront au cours de la
description qui va suivre, donnée uniquement à titre d'exemple non limitatif et
faites en référence aux dessins annexés, sur lesquels: - la figure I représente un réseau de communication selon
l'invention mettant en oeuvre l'inter connexion de périphériques de type audio-
vidéo; - la figure 2 représente un réseau de communication selon l'invention mettant en oeuvre l'inter connexion de périphériques bureautiques; - la figure 3a est le schéma d'un dispositif de communication selon l'invention; - la figure 3b est une vue schématique d'un registre de temps de cycle; - la figure 4 est le schéma de l'architecture logicielle mise en oeuvre au sein du dispositif de communication 90 de la figure 3a; - la figure 5 décrit le format des données transférées en mode message ("Message Mode" en terminologie anglosaxonne); - la figure 6 décrit le format des données transférées en mode flux ('Stream Mode" en terminologie anglo-saxonne); - la figure 7 décrit le format des données transférées en mode contrôles ('Control Mode" en terminologie anglo-saxonne); Les figures suivantes concernent le transfert de paquets de type asynchrones: - la figure 8a décrit le format de la table de charge stockée dans la mémoire RAM du dispositif de communication 90 et gérée par le module réseau 122 de la figure 4; - la figure 8b décrit le format d'un paquet asynchrone de type 1394 utilisé pour l'échange de commande de gestion des ponts entre différents module pont 123 du type de celui représenté à la figure 4; - la figure 9a décrit l'organigramme de réception d'un paquet asynchrone en provenance du bus série et qui est mis en oeuvre par le module pont 123; - la figure 9b décrit un organigramme de réception d'un paquet asynchrone en provenance du réseau commuté et qui est mis en oeuvre par le module pont 123; - la figure 9c décrit l'organigramme de réception d'un transfert en mode non connecté en provenance du réseau commuté et qui est mis en oeuvre par le module réseau 122 de la figure 4; - la figure 9d décrit l'organigramme de transfert d'un paquet asynchrone en mode message vers le réseau commuté et qui est mis en oeuvre par le module réseau 122; Les figures suivantes concernent le transfert de paquets de type isochrone: - la figure 10 décrit le format d'un paquet isochrone de type 1394; - la figure 11 décrit le mécanisme d'établissement d'une connexion utilisé pour le transfert de paquet isochrone en mode flux via le réseau commuté; - la figure 12 décrit le format des messages de signalisation échangés entre différents modules réseau 122 du réseau commuté pour l'établissement d'une connexion; - les figures 13 à 16 décrivent les organigrammes mis en oeuvre par le module réseau 122 pour la gestion des connexions; - les figures 17 à 19 décrivent les mécanismes de réservation de ressources associés à la gestion des connexions; - la figure 20 décrit le transit des paquets isochrones entre le réseau commute en mode flux et un bus série de type 1394; Les figures suivantes concernent, d'une manière générale, le transfert de paquets sur le réseau commuté: - la figure 21 décrit la structure des données conservées dans l'unité d'ordonnancement de paquets 109 pour l'émission de paquets en mode contrôle, message et flux; - la figure 22 décrit l'organigramme mis en oeuvre par l'unité d'ordonnancement de paquets 109 pour l'émission de paquets en mode contrôle, message et flux; - la figure 23 décrit l'organigramme de transfert d'un paquet depuis la mémoire 106 de la figure 3a vers l'unité de commutation 108 et qui est mis en oeuvre par le module de contrôle 107; - la figure 24 décrit l'organigramme de transfert d'un paquet depuis l'unité de commutation 108 vers la mémoire 106 et qui est mis en oeuvre par le module de contrôle 107; - la figure 25 décrit l'organigramme de transfert des données en mode message depuis la mémoire 106 vers le moyen de stockage 95, pour traitement ultérieur par le module réseau 122, et qui est mis en oeuvre par l'unité d'ordonnancement de paquets 109; - la figure 26 représente de manière schématique l'unité de
commutation 108.
RESEAU, DISPOSITIF ET MODE DE TRANSFERT
Comme représenté schématiquement sur la figure 1 et désigné par la référence générale notée 10, un réseau de communication selon l'invention comporte plusieurs bus de communication série conformes à la norme IEEE 1394, notés 12, 14, 16, 18 et qui sont tous interconnectés par un réseau à commutation de paquets noté 20, assurant l'interface entre les
différents bus.
Il convient de noter que le réseau commuté 20 est par exemple un
réseau de type conforme à la norme IEEE 1355.
Ce réseau commuté comporte plusieurs noeuds de commutation notés 22, 24, 26, 28 et 30 qui sont considérés comme des dispositifs de communication au sens de la présente invention. Certains sont reliés entre eux par des liens physiques notés 23, 25, 27 et 29 qui sont des liens bidirectionnels rapides. Ces liens physiques sont par exemple des câbles ou bien
pourraient, par exemple, être des liens radio point à point.
Il convient de noter que les noeuds de commutation 22, 26, 28 et sont également des noeuds de communication connectés aux bus de communication série respectifs 14, 12, 18 et 16 et, à ce titre, constituent chacun une interface entre ledit bus de communication série concerné et un autre
noeud du réseau commuté 20.
A titre d'exemple, les noeuds 22, 24, 26, 28 et 30 sont respectivement associés à des appareils de traitement de données également appelés périphériques ou bien peuvent également constituer des appareils de
traitement de données en eux-mêmes.
Ainsi, par exemple, le noeud de commutation 22 peut être associé
à ou être lui-même un écran de télévision haute définition.
Le noeud de commutation 24 peut, par exemple, être associé à ou constituer lui-même un décodeur (connu en terminologie anglo-saxonne sous le
terme de "Set-top box").
Le noeud de commutation 26 peut, par exemple, être associé à ou
constituer lui-même un enregistreur vidéo.
Le noeud de commutation 28 peut, par exemple, être associé à ou
constituer lui-même une unité de stockage DVD.
Enfin, le noeud de commutation 30 peut, par exemple, être associé
à ou constituer lui-même un poste de télévision.
Plusieurs noeuds de communication associés à des appareils de traitement de données ou périphériques ou bien constituant eux-mêmes lesdits appareils de traitements de données sont également connectés à chaque bus
de communication série.
Chaque noeud de communication d'un bus comporte une horloge interne, non représentée sur la figure 1, à partir de laquelle sont générées des impulsions dites d'horloge à une fréquence dite d'horloge, par exemple égale à
24,576 MHz.
Cela me semble être aussi un élément de détail à ce niveau de la
description. Gardons le pour l'instant.
Ainsi, en plus de l'enregistreur 26 connecté au bus 12, une caméra numérique 32, un télécopieur 34, une imprimante 36 et un ordinateur
de type PC noté 38 sont également connectés au bus 12.
En plus de l'écran 22 connecté au bus 14, des hauts parleurs
stéréo 40 et 42 sont également connectés à ce bus.
En plus de l'appareil de télévision 30 connecté au bus 16, une
caméra numérique 44 est également connectée à ce dernier.
Enfin, outre l'unité de stockage DVD 28 connectée au bus 18, un télécopieur 46, un poste de télévision 48 ainsi qu'une radio numérique 50 sont également connectés à ce même bus. Il convient de noter que le réseau ainsi constitué représente typiquement un réseau qui peut être installé par un utilisateur dans son habitation. Le réseau de communication selon l'invention permet à n'importe quel appareil de traitement de données ou périphérique connecté à un premier bus dudit réseau d'échanger des données de type isochrones ou asynchrones avec n'importe quel autre appareil de traitement de données ou périphérique connecté à un deuxième bus dudit réseau, les bus étant séparés l'un de l'autre
par le réseau commuté.
Par ailleurs, le réseau de communication selon l'invention permet aussi à un périphérique connecté à un bus d'échanger des données de type asynchrones et isochrones avec n'importe quel appareil de traitement de
données ou périphérique du réseau commuté.
L'interconnexion des bus de communication au moyen du réseau commuté 20 permet de résoudre le problème du câblage des appareils de traitement de données sur une longue distance, par exemple en disposant chacun des noeuds de commutation du réseau 20 et le bus de communication qui lui est associé, incluant tous les appareils qui y sont connectés, dans une
pièce séparée de l'habitation.
En outre, le fait que tous les bus soient interconnectés par un seul et même réseau commuté simplifie la structure du réseau global et rend la
gestion de celui-ci transparente pour l'utilisateur non spécialiste de réseaux.
L'application illustrée sur la figure 2 vise à connecter entre eux,
des appareils de traitement de données ou périphériques de bureau.
Ainsi, comme représenté sur cette figure, un réseau 52 comprend plusieurs bus de communication série conformes à la norme IEEE 1394 et notés 54, 56, 58 et 60 qui sont interconnectés par un réseau de commutation
de paquets noté 62.
* Le réseau commuté 62 est un réseau par exemple du type
conforme à la norme IEEE 1355.
Ce réseau 62 comporte plusieurs noeuds de commutation notés 64, 66, 68, 70 et 72 dont certains sont reliés entre eux par des liens physiques
notés 53, 55, 57 et 59 qui sont des liens bidirectionnels rapides.
Certains de ces noeuds notés 64, 68, 70 et 72 constituent également des noeuds de communication connectés aux bus respectifs 56, 58,
et 54.
Chacun des nceuds de commutation du réseau 62 peut constituer lui-même ou bien être associé à un appareil de traitement de données
également appelé périphérique.
Ainsi, les noeuds 64, 66, 68, 70 et 72 sont respectivement associés à ou bien constituent en eux-mêmes un ordinateur PC de type serveur, une passerelle, une imprimante, un ordinateur PC de type serveur et
une unité de stockage DVD.
Deux ordinateurs de type PC 61 et 63, une imprimante 65 et un
télécopieur 67 sont connectés au bus 54 en sus de l'unité de stockage DVD 72.
En plus d'un ordinateur de type serveur 64 qui est connecté au bus de communication série 56, deux ordinateurs de type PC notés 74 et 76
sont également connectés à ce bus.
Deux ordinateurs de type PC 76 et 78 ainsi qu'un télécopieur 79
sont connectés au bus de communication série 58 en plus de l'imprimante 68.
Deux hauts parleurs stéréo notés 80 et 82, un télécopieur 84, un ordinateur de type PC 86 et un caméscope 88 sont également connectés au
bus de communication série 60 en sus de l'ordinateur 70.
Ce type de réseau constitué sous la forme d'un réseau dit LAN (connu en terminologie anglo-saxonne sous le terme "Local Area Network")
présente les mêmes avantages que celui décrit en référence à la figure 1.
Comme représenté sur les figures 1 et 2, chacun des réseaux commutés 20 et 62 constituent chacun une interface de communication entre tous les bus de communication série du réseau de communication global et
fédère l'ensemble de ces bus.
Chaque noeud de chaque réseau commuté 20 (figure 1) et 62 (figure 2) comporte une horloge interne, non représentée sur les figures et à partir de laquelle sont générées des impulsions dites d'horloge à une fréquence dite d'horloge, par exemple égale à 24,576 MHz. Chaque horloge interne définit des cycles temporels successifs
ayant chacun une durée T propre à ladite horloge considérée.
La durée T du cycle d'un noeud est déterminée par le nombre niit d'impulsions d'horloge générées par l'horloge interne dudit noeud pendant cette
durée suivant la relation T=ninit/,F.
On compte ainsi par exemple 3072 impulsions d'horloge dans un cycle ou période de référence d'une durée de 125ps pour une fréquence
d'horloge de 24,576 MHz.
La figure 3a représente une vue schématique d'un noeud ou dispositif de communication connecté à un bus de communication série conforme à la norme IEEE 1394 et qui constitue également un noeud de commutation d'un réseau de commutation de paquets de données analogue
aux réseaux précédemment décrits et notés 20 et 62.
Le noeud représenté à la figure 3a est également connecté à un ou plusieurs autres noeuds de commutation du réseau commuté auquel il appartient. Dans les exemples de réalisation représentés sur les figures 1 et 2, chacun des noeuds notés 22, 24, 26, 28, 30 du réseau 20 de la figure 1 ou des noeuds notés 64, 66, 68, 70, 72 du réseau 62 de la figure 2 possède par
exemple un dispositif de communication représenté à la figure 3a et noté 90.
Dans le mode de réalisation représenté sur la figure 3a, on a choisi de représenter un appareil de traitement de données 92 également
appelé périphérique qui est associé au dispositif de communication 90.
Un noeud de communication est constitué d'une part d'un dispositif de communication 90 et d'un appareil de traitement de données 92 associé
audit dispositif.
A titre de variante, I'appareil de traitement de données peut lui-
même constituer ou comporter le dispositif de communication 90.
En ce qui concerne les noeuds 24 et 66 des réseaux commutés respectifs 20 et 62, le bloc 92 correspond dans ce cas à une interface avec un réseau externe non représenté, par exemple, un réseau de type CATV, B- ISDN, SAT pour le noeud 24 (fig. 1) et un réseau de type LAN, B-ISDN pour le
noeud 66 (fig.2).
Le dispositif 90 comporte une unité centrale de traitement CPU 93, un moyen de stockage permanent 94 de type ROM qui contient l'architecture logicielle illustrée à la figure 4 et un moyen de stockage temporaire 95 de type RAM associé à l'unité centrale 93 et dans lequel est chargé cette architecture
logicielle à l'initialisation.
Le moyen de stockage 95 est apte à stocker des paquets de données de différents types: - paquets asynchrones du type conforme à la norme IEEE 1394, - paquets constituant des messages en mode non connecté (asynchrones), du type conforme à la norme IEEE 1355,
- paquets de contrôle du type conforme à la norme IEEE 1355.
Les paquets de type conforme à la norme IEEE1355 ont réellement une existence au niveau du composant 104 qui sera mentionné ultérieurement mais ils ne sont pas stockés sous cette forme dans le moyen de stockage RAM 95. On notera que le moyen de stockage 95 contient les
informations nécessaires pour générer les paquets IEEE 1355.
Le cheminement de tels paquets jusqu'au moyen de stockage 95 provenant soit du bus 1394 soit du réseau commuté constitué de liens 1355
sera détaillé ultérieurement.
Le cheminement de tels paquets, depuis le moyen de stockage 95 jusqu'à leur transmission par le noeud de commutation, soit en direction du bus 1394, soit en direction du réseau commuté constitué de liens 1355 sera détaillé
ultérieurement.
Ces trois éléments 93, 94 et 95 communiquent au moyen de bus d'adresses et de données respectifs notés 96, 97 et 98, avec un bloc noté 99 et
connu de l'homme de l'art sous le nom de contrôleur de bus.
Ce bloc 99 permet notamment d'échanger des données au moyen d'un bus principal 100 avec un moins un composant d'interface de bus 101. Dans le cas o le bus 100 est un bus standard PCI (PCI signifiant en terminologie anglo-saxonne "Peripheral Component Interconnect"), le composant 101 peut être un composant dénommé AMCC 5933QC
commercialisé par la société Applied Micro Circuits Corporation.
Le bus 100 peut également connecter entre eux d'autres éléments, non représentés sur la figure, eux mêmes pourvus d'une interface de bus et pouvant mettre en oeuvre, par exemple, des fonctions de traitement de données. Par exemple dans un cas o le bus 100 est un bus standard PCI, (PCI signifiant en terminologie anglo-saxonne "Peripheral Component Interconnect") le bloc 99 est en fait un ensemble de composants PCI tel que
l'ensemble Intel 440LX AGP ("Intel 440LX AGPset" dans la terminologie anglo-
saxonne) commercialisé par la société INTEL.
Ainsi, le bloc 99 comprend, par exemple, un composant 82443LX qui assure l'interface avec la mémoire 95 via le bus mémoire 98 et avec l'unité centrale de traitement CPU 93 via le bus local 96. Le composant 82443LX est lui-même relié à un composant 82371AB qui fournit une interface avec le bus ISA 97 relié à la mémoire 94. Un contrôleur d'interruption IOAPIC Intel 82093AA connecté à l'unité centrale de traitement CPU 93 gère les
interruptions pouvant survenir dans le système.
Comme représenté sur la figure 3a, le dispositif 90 comporte également une interface bus 102 qui peut être similaire à l'interface bus 101 permettant ainsi à l'appareil de traitement de données ou périphérique 92
d'accéder au dispositif de communication.
Une telle interface est par exemple réalisée sous la forme d'une carte SEDNET PCI commercialisée par la société SEDERTA sous la référence SD-PCI200 et permet d'y connecter n'importe quel appareil de traitement de
données existant conçu pour fonctionner en conformité avec la norme 1394.
Il est bien entendu possible d'utiliser un adaptateur 102 spécifique
à l'appareil de traitement de données que l'on souhaite y connecter.
L'adaptateur 102 comprend essentiellement un composant d'interface similaire au composant d'interface de bus 101. Selon le type d'appareil de traitement de données, le bus principal , ainsi que les composants d'interface de bus 101 et contrôleur de bus 99 peuvent être adaptés en fonction de l'architecture du type de l'appareil. Il en est
de même pour l'ensemble des éléments CPU 93, RAM 95 et ROM 94.
Toutefois, il convient de noter que si l'appareil de traitement de données est un ordinateur de type PC, alors cet adaptateur 102 n'est pas nécessaire. Comme représenté sur la figure 3a, le noeud selon l'invention
comporte également deux moyens d'interfaçage 103 et 104.
Le moyen 103 est destiné à assurer l'interface entre le noeud 90 et le bus de communication série prévu pour fonctionner selon la norme IEEE
1394 auquel est rattaché ledit noeud.
Le moyen d'interfaçage 103 est un ensemble de composants PHY/LINK 1394 qui est par exemple constitué d'un composant PHY TSB21LV03A et d'un composant LINK TSB12LV01A commercialisés par la société Texas Instruments et de connecteurs 1394, par exemple
commercialisés par la société Molex, par exemple sous la référence 53462.
Le moyen d'interfaçage 103 comporte au moins un port externe destiné à être connecté à un appareil de traitement de données ou périphérique
qui est rattaché au bus de communication série 1394.
Le moyen 103 comporte des moyens de comptage du nombre d'impulsions en fonction d'un signal d'horloge généré par un module de contrôle 107 qui sera défini ultérieurement. Ce signal d'horloge est synchronisé avec le "Maître de cycle" du bus de communication série avec lequel il est en relation, par l'intermédiaire des paquets de début de cycle appelés "Cycle Start packet" en terminologie anglo-saxonne. La fréquence du signal d'horloge généré par le module de contrôle107 est égale à 24,576 MHz +/100 ppm. Ce signal est
représenté comme étant l'un des signaux notés ctrl3 sur la figure 3a.
Sur chaque bus de communication série du réseau, I'un des
noeuds est appelé "Maître de cycle" ("Cycle Master" en terminologie anglo-
saxonne) et le noeud "Maître de cycle" du bus "racine" est appelé "Maître de cycle du réseau" ("Net Cycle Master" en terminologie anglo-saxonne). En outre, tous les noeuds "Maîtres de cycle" du réseau présentent une caractéristique qui leur est propre, puisqu'elle dépend de la fréquence de leur horloge interne, à partir de laquelle est définie la durée d'une "période de
référence" ou "cycle".
La durée du cycle notée T est égale à un nombre entier nuit d'impulsions d'horloge commun ou non à tous les bus et qui est multiplié par
l'inverse de la fréquence de l'horloge interne propre au noeud "Maître de cycle".
La durée du cycle T est ainsi par exemple égale à 125 microsecondes. Lorsque deux bus de communication série sont reliés par un pont, le "Maître de cycle" de l'un des bus doit synchroniser ses cycles par rapport aux
cycles générés par le "Maître de cycle" du bus adjacent.
Ainsi, dans le réseau 10 de la figure 1, si l'on considère que le "Maître de cycle" du bus 12 est le noeud 38 et que le "Maître de cycle" du bus 16 est le noeud 44, le "Maître de cycle" 44, qui est relié au bus 12 par le réseau commuté 20 faisant office de pont, synchronise ses cycles par rapport aux
cycles générés par le "Maître de cycle" 38.
Le noeud "Maître de cycle du réseau" sur la figure 1, qui est par exemple le noeud 38 du bus 12, va alors générer sur le bus 12 toutes les 125 microsecondes, un signal appelé "début de cycle" ("cycle start" en terminologie anglo-saxonne"). Ce signal est destiné aux autres noeuds 26, 32, 34 et 36 du bus 12 et les prévient qu'ils peuvent émettre un paquet de données isochrones associé à chaque cycle du bus considéré, à destination de l'un ou de plusieurs des
autres bus qui sont reliés audit bus considéré par le réseau commuté 20.
D'une manière générale, les réseaux de communication formés de bus de communication série permettent la transmission de paquets synchronisée à partir des cycles de bus considérés. Les bus sont par exemple utilisés pour transmettre des paquets de données en temps réel du type audio/vidéo. Les moyens de comptage comme ceux du moyen d'interfaçage 103 cité plus haut se présentent par exemple sous la forme d'un registre tel que
celui représenté à la figure 3b.
Un tel registre appelé "Registre de Temps de Cycle" (connu en terminologie anglo-saxonne sous le terme "Cycle Time Register") comporte plusieurs zones, notamment une première zone représentée sur la partie droite
de la figure 3b et qui est dénommée "cycle-offset".
Dans cette première zone qui comporte 12 bits, est enregistré le nombre d'impulsions d'horloge ninit contenues à l'intérieur d'un cycle propre au bus de communication avec lequel l'ensemble de composants PHY/LINK 1394
103 est en relation.
Conformément à ce qui a été précédemment mentionné, on compte jusqu'à 3071 impulsions d'horloge dans cette première zone. A chaque impulsion de l'horloge considérée, la valeur de cette première zone du registre est incrémentée. Lorsque la valeur 3071 est atteinte et qu'une nouvelle impulsion d'horloge est comptée, la valeur du registre contenue dans cette première zone va passer à 0 et une retenue va alors incrémenter la valeur de la deuxième zone du registre qui est située au centre de la figure 3b et est dénommée "cycle count". Cette deuxième zone totalise le nombre de cycles écoulés, ceci jusqu'à un nombre de 7999, et est enregistrée sur 13 bits. Cette deuxième zone est incrémentée à chaque fois qu'une retenue est générée à
partir de la première zone "cycle-offset".
Toutefois, une incrémentation d'une unité à partir de la valeur 7999 dans cette deuxième zone du registre R va provoquer un retour à 0 de la valeur de cette zone du registre, générant ainsi une retenue qui va incrémenter une troisième zone du registre R, située à gauche sur la figure 3b et dénommée
"second count".
La troisième zone "second count" est enregistrée sur 7 bits. Cette troisième zone compte le nombre de fois o la deuxième zone "cycle count" déborde et ce, jusqu'à une valeur de 127. Une incrémentation d'une unité à partir de la valeur 127 dans cette troisième zone du registre R provoque alors
un retour à 0 de la valeur enregistrée dans cette zone.
Des informations supplémentaires sur ce registre R peuvent être trouvées au paragraphe 8.3.2.3.1 de la norme IEEE 1394-95. On reviendra ultérieurement sur le mécanisme de synchronisation entre les bus du réseau lorsque les mécanismes de communication de données au sein du réseau commuté inclus dans le réseau global de bus selon
l'invention auront été explicités.
Le moyen d'interfaçage 104 mentionné ci-dessus est un composant d'interface 1355 qui comporte trois ports. Il est notamment constitué d'un composant C113 commercialisé par la société 4LINKS ainsi que de trois composants d'interface LUC1141MK commercialisés par la société LUCENT, eux-mêmes reliés à des connecteurs 1355, par exemple commercialisés par la société HARTING. Le composant C113 est lui même réalisé sur la base d'un composant programmable de type FPGA ("Field Prorammable Gate Array" en terminologie anglosaxonne) Spartan XCS30XL, commercialisé par la société
XILINX.
Les initiales FPGA correspondent approximativement en français
à "Matrice de Portes Programmables".
Les trois ports externes du moyen d'interfaçage 104 sont destinés à être connectés à des ports de même type sur un autre noeud de commutation du réseau commuté, permettant ainsi au dispositif 90 de communiquer avec un
autre noeud de ce réseau.
Le dispositif 90 comporte également un moyen de contrôle de flux de données 105 qui permet le transfert des données entre les différents composants d'interface 101, 103 et 104. Ce moyen 105 est réalisé en logique programmable, exécuté par un composant de type FPGA, par exemple de
référence Virtex, commercialisé par la société Xilinx.
Ce moyen 105 met en oeuvre notamment une unité de mémorisation à double port 106 qui permet de stocker des données à
destination de/ou provenant du réseau commuté 1355.
L'unité de mémorisation à double port possède une capacité de stockage inférieure à 2 Mbits et est, par exemple, réalisée sous la forme d'une
mémoire de type DPRAM à accès 32 bits.
Les initiales DPRAM signifient en terminologie anglo-saxonne "Dual Port Random Access Memory" ce qui peut être approximativement traduit
en langue française par "Mémoire volatile à double port".
L'unité de mémorisation 106 comporte une pluralité de zones mémoires qui sont gérées comme des mémoires individuelles de type FIFO, initiales des termes anglais "First-in First-out" signifiant en français "Premier
entré Premier sorti".
Une telle zone mémoire correspond à une mémoire dans laquelle les donnéessont lues dans l'ordre dans lequel elles ont été préalablement écrites. Ces zones mémoires comportent chacune un pointeur de lecture
et un pointeur d'écriture associés.
Chaque zone mémoire étant gérée comme une mémoire de type FIFO, son remplissage et son vidage peuvent s'effectuer en même temps, et de manière indépendante. Ceci permet de désynchroniser les opérations de lecture et d'écriture des données effectuées par une unité de commutation 108 qui sera définie ultérieurement des opérations de lecture et d'écriture des
données effectuées par le module de contrôle 107.
En effet, le taux d'occupation de la zone mémoire considérée est géré de manière circulaire et l'on sait à tout moment si les données contenues dans une zone mémoire ont été lues ou non. Lorsque ces données ont été lues
il est alors possible de venir écrire de nouvelles données à la place de celles-ci.
L'unité de mémorisation à double port constitue en quelque sorte une file d'attente pour les paquets et la fonction de stockage est réalisée de manière indépendante selon le port par lequel les paquets parviennent à l'unité
de mémorisation.
D'une manière générale, toutes les données isochrones ou asynchrones provenant du réseau commuté sont stockées dans l'unité de
mémorisation 106.
Ce stockage est temporaire pour les paquets de données asynchrones (paquets constituant un message transmis en mode non connecté et pour les paquets de contrôle), qui sont amenés à être transférés ensuite dans le moyen de stockage RAM 95 pour un stockage d'une durée plus importante. En revanche, les paquets de données isochrones (paquets de type "stream", c'est-à-dire transmis en mode connecté), sont stockés uniquement dans cette unité de mémorisation 106 avant leur transmission sur le bus de communication auquel est raccordé le noeud de commutation 90 ou
sur le réseau commuté.
Ceci s'explique par le fait que ce type de données doit être transféré aussi rapidement que possible du réseau commuté vers le bus et donc doit être stocké dans un moyen de stockage facilement et rapidement accessible. De même, les paquets de données isochrones issus du bus de communication auquel est raccordé le noeud de commutation 90 et qui sont destinés au réseau commuté sont stockés uniquement dans l'unité de mémorisation 106 et non dans le moyen de stockage 95, pour les mêmes
raisons que celles invoquées précédemment.
Ainsi que représenté sur la figure 3a, le moyen de contrôle de flux de données 105 comporte plusieurs autres éléments dont un module de contrôle 107 (déjà mentionné plus haut) qui assure une fonction de contrôle de l'unité de mémorisation 106, une unité de commutation 108 (déjà mentionnée plus haut) en communication avec le moyen d'interfaçage 104, avec l'unité de mémorisation 106 et avec le module de contrôle 107, ainsi qu'une unité d'ordonnancement des paquets de données 109 qui est relation avec le module
de contrôle 107.
On notera également que le module de contrôle 107 communique avec les moyens d'interfaçage 103 et 104 ainsi qu'avec le composant
d'interface de bus noté 101.
Le module de contrôle 107 a pour fonction de multiplexer les accès en lecture ou en écriture à des registres d'autres modules à partir du bus
principal noté 100.
Le module 107 possède également la maîtrise du composant d'interface de bus 101 pour les opérations de lecture et d'écriture sur le bus principal 100, incluant notamment le transfert en "mode rafale" (connu en
terminologie anglo-saxonne sous le terme de "burst mode").
Le module de contrôle 107 est également chargé du déclenchement des interruptions sur le bus principal 100 en fonction
d'événements de communication particuliers.
Ce module échange des données avec le composant 101 sur un bus additionnel 110 (connu en terminologie anglo-saxonne sous le terme de
"add-on bus") suivant les signaux de contrôle notés ctrl 1.
Comme annoncé ci-dessus, le module 107 est chargé du contrôle de l'unité de mémorisation 106 en ce qui concerne les opérations de lecture et d'écriture en mode FIFO dans le cas particulier o le composant d'interface de bus 101 est un AMCC, par l'intermédiaire d'un bus de données 111 et de
signaux de contrôle ctrl 2.
Le moyen d'interfaçage 103 contient des mémoires de type FIFO qui sont utilisées lors du transfert de paquets de données de type conforme à la norme IEEE 1394. Il comprend deux mémoires FIFO de transmission dite ATF ("Asynchronous Transfer FIFO" en terminologie anglo-saxonne) et ITF ("Isochronous Transfer FIFO" en terminologie anglosaxonne) et une mémoire FIFO de réception dite GRF ("'General Receive FIFO" en terminologie anglosaxonne). Ces mémoires FIFO sont plus largement décrites dans la
documentation associée au composant LINK TSB12LV01A.
Le module de contrôle 107 et le moyen d'interface 103 gèrent le
transfert de données sur un bus 112 suivant des signaux de contrôle ctrl 3.
Par ailleurs, le module de contrôle 107 contrôle l'unité de commutation 108 au moyen de signaux de contrôle ctrl 4 afin de transférer des données de l'unité de commutation vers l'unité de mémorisation 106 par
l'intermédiaire d'un bus de données 113 et inversement.
L'unité de commutation 108 est connectée au moyen d'interface 104 par l'intermédiaire d'un bus de données 114 et de signaux de contrôle
ctrl 5.
L'unité d'ordonnancement des paquets de données 109 notée également SAR (connue en terminologie anglo-saxonne sous le terme de "Segmentation And Reassembling") informe le module de contrôle 107 du ou des prochains paquets de données à transmettre par l'intermédiaire de signaux
de contrôle ctrl 6.
En outre, l'unité d'ordonnancement 109 vérifie la réception des paquets de données et gère l'allocation et la libération de zones mémoires (connues en terminologie anglo-saxonne sous le terme de "buffers") de l'unité
de mémorisation 106.
Les signaux de contrôle ctrl7 échangés entre le moyen d'interfaçage 104 et le module de contrôle 107 comprennent notamment les signaux d'horloges régénérés à partir de la réception des paquets 1355 sur
chacun des trois ports du moyen d'interfaçage 104.
Un quartz à 49,152Mhz (non représenté) est connecté à la fois au moyen 104 pour l'émission des paquets 1355 et au module de contrôle 107 qui génère un signal d'horloge à 24,576 MHz +/- 100 ppm, d'une part, pour l'unité d'ordonnancement des paquets de données 109, afin de cadencer l'émission des paquets 1355 et, d'autre part pour le moyen d'interfaçage 103, afin de
cadencer l'émission des paquets 1394.
La figure 4 représente les fonctions réalisées sous forme logicielle qui sont stockées dans la mémoire ROM notée 94, puis chargées à I'initialisation dans le moyen de stockage RAM 95, et ensuite exécutées par
l'unité centrale de traitement CPU 93.
Comme représenté sur la figure 4, I'architecture logicielle selon l'invention assure plusieurs fonctions identifiées par les modules suivants - un module d'interface de communication 120, - un module d'interface de traitement 121, - un module réseau 122,
- un module pont 123.
Plus particulièrement, le module d'interface de communication 120 correspond à la couche basse du protocole qui pilote à la fois le matériel de communication (connu en terminologie anglo-saxonne sous le terme de "hardware") par l'intermédiaire du composant d'interface de bus 101 et I'interface de bus 102. Le module d'interface 120 a également pour fonction de gérer les
interruptions de bus principal 100.
Les paquets de données isochrones sont transférés entre
l'appareil de traitement de données 92 et les moyens d'interfaçage 103 ou 104.
L'analyse de l'en-tête des paquets asynchrones reçus par le moyen d'interfaçage 103 et stockés dans le moyen de stockage RAM 95 est alors effectuée par le module pont afin de déterminer si un paquet asynchrone est destiné au module de traitement de données 121, au module réseau 122 ou
bien au module pont lui-même.
L'analyse de l'en-tête des paquets asynchrones à émettre depuis le moyen de stockage RAM 95 est alors effectuée par le module pont afin de déterminer si un paquet asynchrone est destiné au moyen d'interfaçage 103, au
module réseau 122 ou bien au module pont lui-même.
Les paquets de données asynchrones sont transférés entre le moyen de stockage RAM 95 et les mémoires FIFO ATF et GRF du moyen
d'interfaçage 103.
Le module d'interface de communication 120 a pour fonction d'accéder en lecture ou en écriture aux différents registres d'état ou de configuration agencés dans les moyens 103, 105 et 107 par l'intermédiaire du composant d'interface de bus 101, permettant notamment au module réseau 122 et au module pont 123 d'effectuer l'initialisation des moyens 103, 105 et 107. La figure 5 décrit le format des données transférées en mode message
("Message Mode" en terminologie anglo-saxonne) sur le réseau commuté.
Le message 300 est composé d'un champ d'en-tête de message 301 ("Message Header" en terminologie anglo-saxonne) et d'un champ de données de
message 302 ("Message Payload" en terminologie anglo-saxonne).
Le champ 302 est représentatif des données à transmettre. Il s'agit
par exemple d'un paquet 1394 de type asynchrone tel que décrit dans la norme.
Le champ 301 est un champ d'en-tête rajouté par le module réseau 122 représentatif du format du champ 302 et décrivant, par exemple, des informations de taille. Afin d'être émis sur le réseau commuté le message 300 est décomposé en une suite de paquets 321 à 326 sous le contrôle de l'unité d'ordonnancement. Les champs d'en-tête de paquet ("Packet Header" en terminologie anglo-saxonne) 303, 306, 309, 312, 315 et 318 contiennent de l'information de routage représentative du chemin à parcourir, de l'identificateur du noeud qui a émis le paquet, du mode de transfert (ici le mode "message"), ainsi que du numéro
de la mémoire FIFO d'émission dans l'unité de mémorisation à double port 106.
Classiquement la valeur de ces champs est identique.
Les champs de données du paquet ("Packet Payload" en terminologie anglosaxonne) 304, 307, 310, 313, 316 et 319 contiennent l'ensemble des données qui constituent le message 300, les paquets étant émis de telle sorte que l'ensemble du message 300 soit émis dans l'ordre depuis la
gauche vers la droite.
Les champs de fin de paquet ("Packet Trailer" en terminologie anglo-
saxonne) 305, 308, 311, 314, 317 et 320 sont explicitement rajoutés par le moyen d'interfaçage 104 après l'émission de chaque paquet. Ces champs sont tous représentatifs d'un marqueur de fin de paquet ("End Of Packet" ou EOP en terminologie anglo-saxonne), tel que décrit dans la norme IEEE1355-95. Les champs 305, 308, 311, 314 et 317 ont tous pour même valeur EOP1, alors que seul le champ 320 qui appartient au dernier paquet du message a pour valeur EOP2. On notera que la taille du champ 319 dépend notamment du nombre de
données restant à émettre dans le message 300.
La figure 6 décrit le format des données transférées en mode flux
("Stream Mode" en terminologie anglo-saxonne) sur le réseau commuté.
Le flux de données partiellement représenté par les champs 352 et 353 est constitué, d'une part, d'un ensemble de champs de données de flux ("Stream Payload" en terminologie anglo-saxonne) représenté par les champs 330 à 334, d'autre part, d'un ensemble de champs d'en-tête de flux ("Stream Header"
en terminologie anglo-saxonne) représenté par les champs 335 à 337.
Les champs 330 à 334 sont représentatifs de données à transmettre et sont chacun constitués par exemple, d'un paquet 1394 de type isochrone. Dans ce cas, tous les champs 330 à 334 ont comme caractéristique d'appartenir au même flux de données isochrones et contiennent donc une même valeur de
numéro de canal.
Afin d'être émis sur le réseau commuté, le flux de données partiellement représenté par les ensembles de champs 352 et 353 est décomposé en une suite de paquets 338 à 341 sous le contrôle de l'unité d'ordonnancement 109. Les champs d'en-tête de paquet ("Packet Header" en terminologie anglo-saxonne) référencés 342, 345 et 349 contiennent de l'information de routage représentative du chemin a parcourir, de l'identificateur du noeud qui a émit le paquet, du mode de transfert (ici le mode flux), ainsi que du numéro de la mémoire FIFO d'émission dans l'unité de mémorisation à double port 106. Classiquement la
valeur de ces champs est identique.
Les champs de données du paquet ("Packet Payload" en terminologie anglosaxonne) référencés 343, 346, 347 et 350 contiennent une partie des données qui constituent le flux, les paquets étant émis de telle sorte que
l'ensemble du flux soit émis dans l'ordre depuis la gauche vers la droite.
Les champs de fin de paquet ("Packet Trailer" en terminologie anglo-
saxonne) référencés 344, 348 et 351 sont explicitement rajoutés par le moyen d'interfaçage 104 après l'émission de chaque paquet. Ces champs sont tous représentatifs d'un marqueur de fin de paquet ("End Of Packet" ou EOP en terminologie anglo-saxonne), tel que décrit dans la norme IEEE- 1355-95 et ont
tous pour même valeur EOP1.
La figure 7 décrit le format des données transférées en mode
contrôle ('Control Mode" en terminologie anglo-saxonne) sur le réseau commuté.
Le champ 360 est représentatif des données à émettre en mode contrôle et constitue l'intégralité d'un message de contrôle, comme par exemple un
message de signalisation mentionné sur la figure 11.
Le message de contrôle est émis sur le réseau commuté sous le contrôle de l'unité d'ordonnancement 109 sous la forme d'un paquet unique. Le champ d'en-tête de paquet ("Packet Header" en terminologie anglo-saxonne) référencé 361 contient de l'information de routage représentative du chemin à parcourir, de l'identificateur du noeud qui a émis le paquet, du mode de transfert (ici le mode contrôle) ainsi que du numéro de la mémoire FIFO
d'émission dans l'unité de mémorisation 106.
Le champ de données du paquet ("Packet Payload" en terminologie
anglo-saxonne) 362 est exactement équivalent au champ 360.
Le champ de fin de paquet ("Packet Trailer" en terminologie anglo-
saxonne) 363 est explicitement rajouté par le moyen d'interfaçage 104 après
l'émission du paquet. Ce champ a invariablement pour valeur EOP1.
TRANSFERT ASYNCHRONE
La figure 8a est une vue schématique de la structure de données d'une table de charge associée au module réseau 122 et stockée dans le
moyen de stockage 95 du dispositif de communication 90.
En figure 8a, on observe des descripteurs de liens 2001 à 2007 disposés côte à côte et des descripteurs de chemins 2011 à 2015 disposés sur
des lignes successives.
Chaque descripteur de chemin est une structure de données pour
la description d'un chemin entre deux noeuds du réseau commuté qui comporte,
en particulier, le champ d'adresse de chacun des deux noeuds, la référence des
liens impliqués dans la description de ce chemin et la référence de chaque
connexion associée à ce chemin.
Le champ d'adresse d'un noeud est associé de manière unique avec un champ d'identification de bus représenté sur 10 bits et dont la valeur correspond à l'identification du bus auquel le dispositif de communication est connecté. La valeur de ce champ adresse de noeud ou identification de bus est utilisée dans les sous-champ d'adressage notés 203 ou 205 des paquets
asynchrones de type 1394 décrits ultérieurement en référence à la figure 8b.
Chaque descripteur de chemin sortant (2011, 2012 ou 2013) comporte en outre l'information de routage utilisée dans chaque en-tête de paquet transféré selon ce chemin. Le champ d'adresse du premier noeud de tous les chemins sortants est identique et correspond au champ d'adresse
associé au dispositif de communication du noeud considéré.
Le sous-ensemble de la table de charge constitué des chemins
sortants est appelé table de routage dans la suite de la description.
Les chemins qui ne partent pas du noeud considéré sont dits "temporaires" et permettent de connaître les charges des liens des chemins sortants. Les chemins temporaires sont créés par le moyen de contrôle de charge qui gère tous les chemins (opérations 2307, 2407 et 2504 sur les
figures 17 à 19).
Dans le mode de réalisation décrit et représenté, les chemins 2011, 2012 et 2013 sont des chemins sortants (en traits gras) et les chemins 2014 et 2015 sont des chemins temporaires (en traits fins). Les chemins 2011, 1012 et 1013 décrivent la table de routage et sont utilisés par le noeud
considéré pour établir des chemins vers n'importe quel noeud destinataire.
Chaque descripteur de lien 2001 à 2007 comporte, en particulier, la référence de chaque chemin qui traverse le lien considéré, identifié par un rectangle, à l'intersection d'une ligne verticale partant du descripteur de lien considéré et d'une ligne horizontale partant du descripteur de chemin considéré. Les liens 2001 à 2004 font partie d'au moins l'un des chemins sortants, et sont représentés en traits gras. Chaque intersection de deux lignes marquée par un point représente une référence en mémoire: - les lignes externes (en haut et/ou à gauche des rectangles) repèrent les références conservées avec chaque lien: ces références concernent chaque chemin qui traverse ledit lien, et - les lignes internes (en bas et/ou à droite des rectangles) repèrent les références conservées avec chaque chemin: ces références concernent
chaque lien traversé par ledit chemin.
La mise à jour de la table de charge effectuée par le module réseau 122 du dispositif, comporte les étapes suivantes: - pour l'établissement d'une connexion: mise à jour de la charge de tous les liens référencés par le chemin (ajout de charge), et * pour chaque lien, mise à jour de la charge de chaque chemin référencé pour ce lien; - pour le retrait d'une connexion: mise à jour de la charge de tous les liens référencés par le chemin (déduction de charge), et À pour chaque lien, mise à jour de la charge de chaque chemin référencé pour ce lien; - pour l'ajout d'un chemin: a soit par le module réseau pour l'initialisation d'une liste prédéterminée de chemins sortants pour le noeud considéré, à la mise sous tension du dispositif de communication, * soit par le module réseau, lorsque le chemin associé à une nouvelle connexion lors de l'ajout de charge n'est pas déjà spécifié (il s'agit alors de chemin temporaire); pour la suppression d'un chemin: par retrait d'un chemin temporaire lorsqu'il n'est plus traversé par aucune connexion, après retrait d'une connexion, soit lorsque la liste de connexions référencée par ce chemin est vide; et - pour la suppression d'un lien 30. par retrait d'un lien lorsqu'il n'est plus traversé par aucun chemin, ou lorsque la liste des
chemins référencés par ledit lien est vide.
Dans la table de charge, à chaque lien est associée une information de charge et à chaque chemin est associée une information représentative du lien le moins disponible. Ainsi, la bande passante disponible
du lien le moins disponible est aussi la bande passante disponible du chemin.
On observe que c'est en utilisant cette information de disponibilité de bande passante de chemin, que le module réseau effectue le choix du chemin en choisissant le chemin le plus disponible. Pour chaque information à transmettre en mode non connecté, la disponibilité de chaque chemin du
réseau est ainsi estimée, en fonction du trafic en mode connecté.
La charge d'un chemin est définie à partir de son lien le moins disponible. Il est caractérisé par la bande passante totale qu'il autorise et la part maximale de la bande passante associée au trafic en mode connecté. Etant donnée la charge effective du trafic en mode connecté, le module réseau définit la part associée au trafic en mode non connecté, comme étant égale à la bande
passante totale à laquelle on a soustrait la part associée au mode connecté.
* Le module réseau alloue à l'ensemble des transmissions en mode non connecté qu'il a à effectuer, tout ou partie de la bande passante (préférentiellement une partie, pour éviter des problèmes de congestion du réseau). Cette part est équitablement répartie entre toutes les transmissions en mode non connecté et se trouve donc dynamiquement mise à jour au début et à la fin de chaque transmission en mode connecté (lorsque la charge du trafic en
mode connecté varie).
L'attribution d'une part est effectuée en définissant un plage de valeurs du nombre de paquets à émettre entre deux valeurs extrêmes (specCPmin 1114 et specCPmax 1115 décrit ultérieurement en référence à la figure 21). Cette opération d'attribution de bande passante est effectuée
avant l'émission de l'information.
En outre, on considère qu'un chemin qui supporte plus d'un nombre prédéterminé de transmissions sortantes en mode non connecté n'est
pas disponible pour une transmission supplémentaire en mode non connecté.
Les événements qui peuvent influencer l'attribution de bande passante à une transmission en mode connecté sont de deux types: - ceux qui concernent le mode connecté, l'établissement ou la fermeture d'une connexion, et qui influent sur la bande passante qui lui est réservée, et, par conséquent, sur le nombre de paquets à émettre en mode non connecté mais aussi sur la taille de ces paquets, et - ceux qui concernent le mode non connecté, le début ou la fin d'une transmission, et qui influent sur le nombre de paquets à émettre en mode
non connecté.
Pour la gestion de la table de charge illustrée à la figure 8a, la charge d'un chemin est déterminée par la charge du lien le moins disponible, en prenant en compte, pour la charge d'un lien, la somme des charges des
chemins qui le traversent.
Les chemins sortants utilisés sont, par exemple, prédéterminés de manière statique étant donné une topologie fixée du réseau commuté. On notera que l'utilisation de moyen de routage permettant de gérer de manière dynamique la liste des chemins sortants pour une topologie variable n'affecte
en rien la mise en oeuvre de l'invention.
On observe ici que chaque noeud du réseau à commutation de paquets contrôle le flux qu'il génère grâce à l'unité d'ordonnancement des paquets 109 et que l'information permettant de contrôler ce flux est établie à partir de la table de charge gérée par le module réseau 122, l'unité d'ordonnancement 109 de chaque noeud conservant cette information sous forme d'un tableau tel que celui illustré à la figure 21 qui sera décrit
ultérieurement. Ce tableau est renseigné par le module réseau 122.
Les niveaux de priorité des messages sont établis par le module
réseau à partir du service requis.
La figure 8b décrit le format d'un paquet asynchrone conforme a la norme 1394, utilisé pour le transfert d'une commande de requête de connexion ("Join Request" en terminologie anglo-saxonne) ou de relâchement de connexion ("Release Request" en terminologie anglo-saxonne). La structure
d'un paquet asynchrone est plus largement décrite dans la norme IEEE 1394-
95. Les paquets asynchrones sont entre autre utilisés pour effectuer des transactions entre un périphérique source et un périphérique destinataire. Une transaction est effectuée en émettant un paquet de type "Requête" de la source vers la destination, puis un paquet de type "Réponse" de la destination vers la source. Le champ "destination_lD" 280 de la figure 8b ("Destination Identifier" en terminologie anglo-saxonne), représenté sur 16 bits, contient
l'information de routage permettant d'atteindre le périphérique destinataire.
Le sous-champ 201 décrit l'identification du bus auquel appartient le périphérique destinataire alors que le sous-champ 202 identifie le périphérique destinataire lui-même parmi les autres périphériques du bus
auquel il appartient.
Le champ "source_lD" 281 ("Source Identifier" en terminologie anglosaxonne), représenté sur 16 bits, contient l'information de routage
permettant d'atteindre le périphérique source.
Le sous-champ 203 décrit l'identification du bus auquel appartient le périphérique source, alors que le sous-champ 204 identifie le périphérique
source lui-même parmi les autres périphériques du bus auquel il appartient.
La présence de ces deux champs 280 et 281 permet le routage
d'une transaction entre la source et la destination.
Le champ "tl" 282 ("Transaction Label" en terminologie anglo-
saxonne), représenté sur 6 bits, permet de numéroter une transaction entre des périphériques. Le champ "rt" 283 ("Retry Code" en terminologie anglo-saxonne), représenté sur 2 bits, permet d'identifier les tentatives d'émission d'un même
paquet asynchrone.
Le champ "tcode" 284 ("Transaction Code" en terminologie anglo-
saxonne), représenté sur 4 bits, permet d'identifier un type de paquet
asynchrone, tel que par exemple le type de la transaction.
Le champ "pri" 285 ("Priority" en terminologie anglo-saxonne), représenté sur 4 bits, permet d'identifier la priorité associée au paquet
asynchrone.
Les champs 286 et 287 permettent d'identifier de manière unique le type de paquet ainsi que les traitements qui lui sont associés. Ils permettent notamment d'identifier les paquets de type "commande" échangés entre ponts et plus particulièrement les commandes d'établissement et de relâchement de connexion. Les champs 289, 290, 291, 292 et 293 sont des champs particuliers aux commandes d'établissement et de relâchement de connexion. Le champ 289 permet d'identifier de manière unique la connexion isochrone
dans l'ensemble du réseau commuté.
Le champ 290 contient l'identification (ou adresse) du noeud dit contrôleur ("Controler" en terminologie anglo-saxonne), par exemple noté 523
sur la figure 11 qui sera décrite ultérieurement.
Le champ 291 contient l'identification (ou adresse) du noeud dit source ("Talker" en terminologie anglo-saxonne), par exemple noté 505 et
repéré par la lettre T sur la figure 11 qui sera décrite ultérieurement.
Le champ 292 contient l'identification (ou adresse) du noeud dit destinataire ('Listener" en terminologie anglo-saxonne), par exemple noté 514
et repéré par la lettre L sur la figure 11 qui sera décrite ultérieurement.
Le champ 293 contient la description des paramètres requis
associés à la connexion envisagée pour le transport du flux isochrone entre le
noeud dit "talker" et le noeud dit "listener".
Les champs standards 288 et 294 sont des champs de détection d'erreur.
Les différents organigrammes présentés dans la description qui va
suivre comportent des étapes correspondant à des instructions qui, lorsqu'elles sont exécutées, permettent mettre en oeuvre tout ou partie du procédé selon
l'invention.
Il convient de noter que plusieurs programmes d'ordinateur notés P1, P2, P3, P4, P5, P6, P7, P8, P9, P10 et Pl1 mémorisés dans le moyen de stockage RAM 95 (figure 3a) sont respectivement basés sur les organigrammes
des figures 9a à 9d, 13 à 19. La figure 9a décrit un organigramme de réception et de traitement des
paquets asynchrones en provenance du bus série connecté au moyen
d'interfaçage 103. Cet organigramme est mis en oeuvre par le module pont 123.
Les paquets 1394 sont préalablement stockés dans la mémoire FIFO de réception GRF associée au moyen d'interfaçage 103. Le paquet est ensuite transféré dans le moyen de stockage RAM 95 par le module d'interface sous le contrôle du module pont 123. Cela décrit l'ensemble des opérations mises en ceuvre au cours de l'étape 150 de l'organigramme. Au cours du test 151 le module pont 123 analyse le champ 201 décrit à la figure 8b pour déterminer si le paquet est destiné au réseau commuté. Dans l'affirmative, I'opération 155 est exécutée et le paquet asynchrone est envoyé au module réseau 122 via l'interface référencée ctrl14
sur la figure 4.
Dans le cas o le test 151 est négatif, le test 152 est exécuté. Au cours du test 152 le module pont détermine en analysant les champs 286 et 287 si le paquet lui est destiné. Dans l'affirmative, l'étape 154 est exécutée et le traitement associé aux champs de données du paquet asynchrone (comme par
exemple les champs 289 à 293 de la figure 8b) est effectué.
Si le test 152 est négatif le paquet asynchrone est transmis au module de traitement de données 121 via l'interface référencée ctrll3 sur la
figure 4 (opération 153).
La figure 9b décrit un organigramme de réception d'un paquet asynchrone en provenance du réseau commuté et mis en ceuvre par le module
pont 123.
Au cours de l'étape 160, le module pont 123 reçoit un paquet asynchrone en provenance du module réseau 122 via l'interface ctrl114 (voir
étape 174 de la figure 9c), puis le test 161 est exécuté.
Au cours du test 161 le module pont 123 analyse le champ 201
représenté à la figure 8b pour déterminer si le paquet est destiné au bus série.
Dans l'affirmative, l'opération 165 est exécutée et le paquet asynchrone, via le module d'interface 120, est transféré dans la mémoire FIFO d'émission ATF
associée au moyen d'interfaçage 103 afin d'être émis sur le bus série.
Dans le cas o le test 161 est négatif, le test 162 est exécuté. Au cours du test 162 le module pont détermine, en analysant les champs 286 et 287, si le paquet lui est destiné. Dans l'affirmative, l'étape 164 est exécutée et le traitement associé aux champs de données du paquet asynchrone (comme
par exemple les champs 289 à 293 de la figure 8b) est effectué.
Si le test 162 est négatif le paquet asynchrone est transmis au module de traitement de données 121 via l'interface référencée ctrl13 sur la figure 4 (opération 163). La figure 9c décrit l'organigramme de réception d'un transfert en mode non connecté en provenance du réseau commuté et mis en oeuvre par le
module réseau 122.
L'étape 170 informe le module réseau 122 du résultat d'un transfert de données en mode non connecté dans le moyen de stockage 95
(voir étape 1268 de la figure 25), puis le test 171 est exécuté.
Au cours du test 171 le module réseau 122 détermine s'il s'agit d'un paquet de type contrôle à partir de l'information d'en-tête de paquet associé au transfert. Si le test est positif, l'étape 177 est exécutée. Il s'agit, par exemple, des traitements associés à la réception d'un message de signalisation comme décrit ultérieurement en référence aux organigrammes des figures 13 à
16 pour la gestion des connexions.
Si le test 171 est négatif, le test 172 est exécuté. Si le test 172 est négatif en fonction du résultat de l'analyse du champ 301 de la figure 5, l'étape
176 est exécutée, sinon le test 173 est exécuté.
L'étape 176 consiste dans un traitement particulier associé à un transfert quelconque de données en mode message qui ne concerne pas
l'exposé de l'invention.
L'étape 173 est exécutée dans le cas o le transfert de données en mode message correspond à un paquet asynchrone. Au cours du test 173, le module réseau 122 détermine si le paquet asynchrone est destiné au bus série en analysant le champ 201 représenté à la figure 8b. Dans la négative, l'étape 175 est exécutée et le traitement associé aux champs de données du paquet asynchrone (comme par exemple les champs 289 à 293 de la figure 8b) est effectué par le module réseau. Dans l'affirmative, le paquet asynchrone est transmis au module pont 123 via l'interface référencée ctrll4 sur la figure 4
(opération 174).
La figure 9d décrit l'organigramme de transfert d'un paquet asynchrone en mode message vers le réseau commuté et mis en oeuvre par le
module réseau 122.
Au cours de l'étape 180, le module réseau 122 reçoit un paquet asynchrone en provenance du module pont 123 via l'interface ctrl14 (voir étape
de la figure 9a), puis le test 181 est exécuté.
Au cours du test 181, le module réseau 122 détermine si le paquet asynchrone est destiné au réseau commuté en analysant le champ 201 représenté sur la figure 8b. Dans l'affirmative, l'étape 183 est exécutée et le paquet est transféré en mode message vers le réseau commuté via le module d'interface 120. Dans la négative, le traitement associé aux champs de données du paquet asynchrone (comme par exemple les champs 289 à 293 de
la figure 8b) est effectué par le module réseau (étape 182).
TRANSFERT ISOCHRONE
La figure 10 décrit le format d'un paquet isochrone utilisé pour le
transfert de données temps réel conformément à la norme IEC - 61883 (IEC -
61883 "Consumer Audio-Video Equipment - Digital Interface - Part 1: General",
February 1998).
Le champ 400 spécifie la longueur du champ de données en
octets qui est composé des champs 406 et 407.
Le champ 401 décrit le format du paquet isochrone et notamment la présence de l'en-tête CIP ("Common Isochronous Packet" en terminologie
anglo-saxonne) si sa valeur est égale à "01" en représentation binaire.
Le champ "channel" 402 spécifie la valeur du numéro de canal
associé au paquet isochrone.
Le champ "tcode" 403 permet d'identifier le paquet comme étant de type isochrone quand sa valeur est égale à "1010" en représentation
binaire.
Le champ "Sy" 404 est un champ disponible pour certaines applications. Le champ "ClPheader" 406 contient des informations
descriptives des données temps réel.
Les champs standards 405 et 408 sont des champs de détection d'erreur.
La figure notée 11 est une vue schématique d'un réseau de communication selon l'invention analogue à ceux représentés sur les figures 1 et 2. Cette figure va permettre d'illustrer la circulation des messages de contrôle
destinés à la gestion du mode connecté.
Le réseau de la figure 11 comporte plusieurs bus de communication série du type conforme à la norme IEEE 1394 notés 540 à 544 et reliés entre eux par l'intermédiaire d'un réseau commuté du type conforme à la norme IEEE1355 et noté 590. Différents appareils de traitements de données ou périphériques de type conforme à la norme IEEE 1394 notés 500 à 516, représentés par des rectangles sur cette figure, sont connectés à chacun des bus. D'autres noeuds sont constitués, d'une part, d'un dispositif de communication 90 et, d'autre part, d'un appareil de traitement de données 92
comme représenté sur la figure 3a.
Il convient de noter que chaque dispositif de communication 90 selon l'invention est représenté sur cette figure par les deux moitiés d'un ovale de manière à faire apparaître, d'une part, l'ensemble des moyens associés à I'interfaçage avec le bus série appelé "accès au bus série" ("Serial Bus Portal" en terminologie anglo-saxonne), représenté par une moitié d'ovale et d'autre part, l'ensemble des moyens associés à l'interfaçage avec le réseau commuté
appelé "accès au bus virtuel" ("Virtual Bus Portal" en terminologie anglo-
saxonne) représenté par l'autre moitié de l'ovale considéré.
Les "accès aux bus série" des différents dispositifs de communication 90 représentés sur la figure 11, sont notés 520 à 524 pour ceux
qui sont effectivement reliés à un bus, et 532 à 534 pour les autres.
Les "accès aux bus virtuels" des différents dispositifs de communication 90 représentés sur la figure 11, sont notés 525 à 529, d'une part, et 530 à 532 d'autre part. Les "accès aux bus virtuels" décrivent l'ensemble du réseau commuté 590 et sont reliés entre eux deux à deux comme indiqué sur la figure 11, par des liens bidirectionnels du type conformes
à la norme IEEE 1355 et notés 550 à 559.
Ainsi, par exemple, "l'accès au bus série" 520 et "l'accès au bus
virtuel" 525 constituent ensemble, un dispositif de communication 90.
"L'accès au bus série" fonctionne sous le contrôle d'organigrammes mis en oeuvre par le module pont 123 alors que "l'accès au bus virtuel" fonctionne sous le contrôle d'organigrammes mis en oeuvre par le
module réseau 122.
Un "accès au bus série" est destiné à communiquer ou bien avec un accès du même type ou bien avec un appareil de type conforme à la norme
IEEE 1394.
Un "accès au bus virtuel" est destiné à communiquer uniquement avec un accès analogue d'un autre dispositif de communication du réseau commuté. La figure 11 va permettre d'illustrer, dans un réseau de communication selon l'invention, la circulation de messages de contrôle destinés à la gestion du mode connecté, notamment en vue de la transmission de données isochrones entre deux périphériques situés respectivement sur des
bus qui sont séparés entre eux par le réseau commuté 590 précité.
Les flèches représentées par des traits pleins illustrent les messages échangés entre les modules réseau des différents "accès aux bus virtuels". On notera que tous les "accès aux bus virtuels" du réseau commuté
590 sont concernés.
Les flèches représentées par des traits en pointillés illustrent les messages de type 1394, bien connus de l'homme de l'art, échangés entre des "accès aux bus série" et des périphériques 1394 appartenant à leurs bus respectifs. On notera que seuls les "accès aux bus série" 521 et 524 sont concernés. Il convient de noter que sur la figure 11 I'un des périphériques 505 connecté sur le bus 541 est repéré par la lettre T (comme "Talker" en terminologie anglo-saxonne) et identifie le périphérique ou noeud qui souhaite émettre un flux de données isochrones, tandis qu'un autre périphérique 514
connecté au bus 544, est noté L (comme "Listener" en terminologie anglo-
saxonne) et identifie le périphérique ou noeud qui va recevoir le flux de données isochrones en question, après sa transmission par l'intermédiaire du réseau
commuté 590.
A l'initiative d'un utilisateur une commande de requête de connexion "Join Request" décrite en référence à la figure 8b est transmise depuis "l'accès au bus série" 523 noté C (comme "Controller" en terminologie anglo-saxonne) appelé périphérique "contrôleur", à destination de "l'accès au
bus série" 524 noté TX.
La commande de requête de connexion est véhiculée sur le
réseau commuté en utilisant un transfert en mode message 560 (non-
connecté). Ainsi, "l'accès au bus série" 523 ("Serial Bus Portal" en terminologie anglo-saxonne) associé au noeud C transmet le message à son accès adjacent ('Adjascent Portal" en terminologie anglo-saxonne), "l'accès au bus virtuel" 528 ('Virtual Bus Portal" en terminologie anglosaxonne). Le message est alors transmis en mode de transfert message (nonconnecté) depuis "l'accès au bus virtuel" 528 jusqu'à "l'accès au bus virtuel" 529 noté D. Enfin, "l'accès au bus virtuel" D transmet la commande de requête de connexion "Join Request" à son accès adjacent 524, noté TX, connecté au bus 544 auquel est aussi connecté le noeud 514, noté L. Finalement, "l'accès au bus" série 524, noté TX, détermine qu'il doit jouer le rôle du noeud source 505, noté T, pour le noeud destinataire 514, noté L, en analysant le contenu de la commande de requête de connexion "Join Request". Ensuite, "l'accès au bus série" TX doit effectuer une réservation de ressources pour un flux de données isochrones sur le bus local considéré 544 en s'adressant (requête 581) à un périphérique 515 appelé IRM connecté à
ce bus.
On notera que les bus 541 et 544 sont considérés respectivement
comme un premier et un second bus au sens de la présente invention.
Le périphérique IRM est un gestionnaire de ressources isochrones (connu en terminologie anglo-saxonne sous le terme "isochronous ressource manager"). La gestion des ressources isochrones sur un bus de communication local est décrit dans la norme IEEE 1394-1395 (IEEE Computer
Society, "Standard for High Performance Serial Bus", IEEE Standard 1394-
1995, IEEE) et complété dans le projet de norme P1394a (IEEE Computer Society, "Draft Standard for High Performance Serial Bus (Supplement)", P
1394a draft 4.0, September 1999).
"L'accès au bus série" du dispositif de communication TX va alors ouvrir un registre de contrôle de connexion d'entrée noté iPCR (connu en terminologie anglo-saxonne sous le terme de "input Plug Control Register")
dans le périphérique destinataire L (requête 582).
On notera que le registre de contrôle de connexion noté PCR est
une notion décrite dans la norme IEC - 61883 (IEC - 61883 "Consumer Audio-
Video Equipment - Digital Interface - Part 1: General", February 1998).
"L'accès au bus série" TX transmet ensuite une requête de
connexion à son "accès adjacent" ("Adjascent Portal" en terminologie anglo-
saxonne), noté D, et qui se trouve être "l'accès au bus virtuel" 529.
"L'accès au bus virtuel" D transmet en mode message 561 la commande de requête de connexion "Join Request" à destination de "l'accès au bus virtuel" 526 noté S. "L'accès au bus virtuel" S sélectionne un chemin jusqu'à "l'accès
au bus virtuel" D a partir de la table de routage prédéterminée.
Comme illustré sur la figure 17, "l'accès au bus virtuel" S procède à une réservation de ressources internes du dispositif de communication auquel il est associé, et notamment dans l'unité de mémorisation à double port 106 de la figure 3a, ceci afin d'allouer une mémoire FIFO associée au canal isochrone des paquets isochrones à transmettre depuis le bus 541 vers le réseau
commuté 590.
"L'accès au bus virtuel" S transmet ensuite sur le réseau commuté
un message d'établissement de connexion (connu en terminologie anglo-
saxonne sous le terme "Set-Up") dont la destination finale est "l'accès au bus virtuel" D. Dans l'exemple représenté sur la figure 11, le chemin sélectionné passe par les noeuds ou dispositifs de communication dit intermédiaires notés 525 et 532 et le message d'établissement de connexion précité est représenté
respectivement par les flèches notées 562 à 564.
Lorsque "l'accès au bus virtuel" D reçoit ce message d'établissement de connexion, il procède à une réservation des ressources internes du dispositif de communication destinataire auquel il est associé, tel que décrit figure 18, et notamment dans l'unité de mémorisation à double port 106 de la figure 3a, afin d'allouer une mémoire FIFO associée au canal isochrone des paquets isochrones à transmettre depuis le réseau commuté 590 vers le bus 544, à destination notamment du noeud 514 noté L. En cas d'acceptation de la connexion, "l'accès au bus virtuel" D transmet par l'intermédiaire du réseau commuté à "l'accès au bus virtuel" S un message de confirmation de connexion ("Connect" message en terminologie
anglo-saxonne), comme indiqué par la flèche notée 565 sur la figure 11.
Dès que "l'accès au bus virtuel" S reçoit ce message, il informe chaque noeud ou dispositif de communication du réseau commuté de l'établissement d'une nouvelle connexion par l'intermédiaire d'un message de mise à jour de la table de charge, 566 à 572, diffusé à tous les noeuds dudit
réseau 527, 528, 531, 529, 532, 525, et 530.
"L'accès au bus virtuel" S transmet la commande de requête de connexion "Join Request" à son "accès adjacent" LX. L'analyse de la commande de requête de connexion "Join Request" permet à "l'accès au bus série" 521, noté LX, de déterminer qu'il joue le rôle du noeud destinataire 514, noté L, pour le noeud source 505, noté T. "L'accès au bus série" LX procède alors à une réservation des ressources isochrones sur le bus local noté 541 en s'adressant (requête 583) auprès d'un périphérique IRM connecté à ce bus et dont la fonction est la même que celle du périphérique 515 de même nom, connecté au bus 544
mentionné ci-dessus.
Cette étape de réservation de ressources est réalisée de la même
manière que celle indiquée précédemment pour l'autre bus.
"L'accès au bus série" LX va ensuite ouvrir (requête 584) un registre de contrôle de connexion de sortie noté oPCR (connu en terminologie anglosaxonne sous le terme de "output Plug Control Register") dans le périphérique source 505, noté T. On termine ainsi de cette façon la phase de signalisation qui
précède le transfert de paquets isochrones via le réseau commuté 590.
La figure 12 représente la structure de messages de contrôle échangés entre les modules 122 des différents noeuds du réseau destinés à la
gestion du mode connecté.
En figure 12, on observe, sur quatre lignes successives, les structures des messages "set-up", "release", de mise à jour de table de charge,
"LinkTabLoad" ou "LinkTabFree" et "connect'.
Le message "set-up" comporte successivement les champs: - 1901, d'identification du type de message ("set-up", "LinkTabLoad", "LinkTabFree", "Connect" ou "Release", - 1902, d'identification de connexion sur le réseau commute,
- 1903, de description de trafic, représentatif du service requis, ce
champ est représentatif des informations contenues dans le champ 293 de la commande d'établissement de connexion représentée figure 10, - 1904, de données propres au dispositif de communication permettant notamment d'identifier les modules pont des noeuds source et destinataire ainsi que des commandes inter-pont de demande d'établissement de connexion transmises par le noeud destinataire, ce qui est décrit dans les champs 289 à 292 de la commande d'établissement de connexion représentée figure 10, - 1905, de nombre de liens qui utilisent le chemin associé à la connexion, - 1906, de rang du lien sur lequel transite le message, sur le chemin associé à la connexion, - 1907, des descripteurs de liens successifs du chemin correspondant à la connexion souhaitée, et
- 1908, de données de protocole.
Le message "release" comporte successivement les champs: - 1901, d'identification du type de message ("set-up", "LinkTabLoac', "LinkTabFree", "Connect' ou "Release", - 1902, d'identification de connexion, - 1909, de cause de la demande de relâchement, - 1905, de nombre de liens qui utilisent le chemin associé à la connexion, - 1906, de rang du lien sur lequel transite le message, sur le chemin associé à la connexion, - 1907, des descripteurs de liens successifs du chemin correspondant à la connexion souhaitée, et
- 1908, de données de protocole.
Un message de mise à jour de table de charge ou comporte successivement les champs: - 1901, d'identification du type de message ("set-up", "LinkTabLoacP', "LinkTabFree", "Connect" ou "Release", - 1902, d'identification de connexion,
- 1903, de description de trafic, représentatif du service requis,
- 1910, d'information relative à l'arbre de recouvrement mis en oeuvre, 1905, de nombre de liens qui utilisent le chemin associé à la connexion, 1906, de rang du lien sur lequel transite le message, sur le chemin associé à la connexion, - 1907, des descripteurs de liens successifs du chemin correspondant à la connexion souhaitée, et
- 1908, de données de protocole.
Le message "connect" comporte successivement les champs: - 1901, d'identification du type de message ("set-up", "LinkTabLoacf', "LinkTabFree", "Connect' ou "Release", - 1902, d'identification de connexion, - 1911, de données de protocole, pouvant être utilisées par le module réseau 122 du noeud source.
- 1908, de données de protocole.
Les figures 13 à 16 décrivent les différents algorithmes mis en oeuvre par le module réseau 122 de chacun des noeuds suivant leur rôle dans l'établissement de la connexion. Sur l'exemple de la figure 11 on peut ainsi identifier les rôles des différents noeuds du réseau commuté 590: Le dispositif de communication du noeud dit source intègre "l'accès au bus virtuel" 526, noté S. - Le dispositif de communication du noeud dit destinataire intègre "l'accès au bus virtuel" 529, noté D. - Les "accès aux bus virtuels" 525 et 532 sont des éléments des dispositifs de communication associés aux noeuds dits intermédiaires. - Les "accès aux bus virtuels" 527, 528, 530 et 531 sont des éléments des dispositifs de communication associés aux
noeuds dits voisins.
La figure 13 représente un algorithme mis en oeuvre par le module
réseau 122 du noeud source, pour une transmission en mode connecté.
En ce qui concerne le module réseau 122, après avoir été dans un état d'initialisation 1300, une commande de requête de connexion "Join Request" est reçue en mode message au cours d'une opération 1301, via le module d'interface 121, en provenance du module réseau du noeud destinataire. Le champ "traffic_descriptor" 293 de cette commande décrite à la figure 8b permet de déterminer pour la connexion envisagée, le service requis, incluant la bande passante et le mode de transmission. Le module réseau 122 du noeud source effectue alors la sélection d'un chemin alloué à la connexion, le calcul des paramètres de transmission en fonction du service requis, puis la mise à jour de la table de charge si un chemin est disponible (figure 17), au
cours d'une opération 1302.
Ensuite, au cours d'un test 1304, le module réseau 122 du noeud source vérifie si la bande passante nécessaire à la connexion envisagée est disponible sur le chemin sélectionné, ou non. Cette procédure de test 1304 est connue sous le nom de " Contrôle d'Admission de Connexion " ou encore "CAC". Lorsque le résultat du test 1304 est négatif, au cours d'une opération
1303, le module réseau émet un message d'erreur de refus de connexion.
Ensuite, les ressources associées à la gestion de la connexion
sont libérées.
Lorsque le résultat du test 1304 est positif, au cours d'une opération 1305, le module réseau émet le message "set-up" à destination du module réseau du noeud destinataire, par l'intermédiaire de chacun des modules réseau des éventuels noeuds intermédiaires. Ce message décrit la
connexion à établir (figure 12).
Ensuite, au cours d'une opération 1306, un compteur d'horloge (en anglais "timer") "cncAckWait" est initialisé à une valeur qui correspond à un délai maximum accordé à l'établissement de la connexion demandée. Le module réseau se met alors dans un état d'attente de la réponse du réseau
quant à l'établissement de la connexion, état 1307.
Dans cet état 1307, trois événements différents peuvent se
produire, au cours d'opérations 1308, 1310 ou 1311.
Lorsque, dans l'état 1307, le message entrant est un message "cncAckWait", provenant du passage à zéro de la valeur du compteur de signaux d'horloge "cncAckWait" initialisé au cours de l'opération 1306, opération 1308, ou lorsque le message entrant est un message "release_back", provenant du noeud destinataire ou de l'un des éventuels noeuds intermédiaires, opération 1310, l'opération 1323 est effectuée, ou le module
réseau émet un message d'erreur de refus de connexion.
A la suite de l'opération 1323, au cours d'une opération 1324, le module réseau du noeud source procède à la mise à jour des tables de charge associées à la connexion qui a été rejetée. Puis, au cours d'une opération
1325, les ressources associées à la gestion de la connexion sont libérées.
Enfin, lorsque, dans l'état 1307, le message entrant est un message de connexion "connect " (figure 12), provenant du noeud destinataire, opération 1311, suite à quoi il notifie le module pont de l'établissement de la connexion et de la réservation des ressources, via l'interface ctrl14 de la figure 4 (opération 1312). Au cours de l'opération 1313, le module réseau diffuse un message
"LinkTabLoad" comportant notamment la description du service requis, la
bande passante utilisée ainsi que la description du chemin correspondant à la
connexion, en termes de liens. Ce message est diffusé à destination de tous les noeuds du réseau, ce qui a pour effet que chaque noeud du réseau met à jour ses tables de charge. La diffusion de ce message est effectuée en suivant un arbre de recouvrement ("Spanning tree" en terminologie anglo-saxonne)
prédéterminé associé au réseau commuté.
Le module réseau du noeud source se met alors dans l'état 1314 au cours duquel il attend une évolution de la connexion ce qui autorise le transfert des paquets isochrones depuis le bus 541 vers le réseau de commutation 590 (figure 11) via l'unité de mémorisation du dispositif de
communication associé à "l'accès au bus virtuel" 526.
Deux messages peuvent alors entrer dans le module réseau, au
cours d'opérations 1315 et 1318.
Lorsque, dans l'état 1314, le message entrant est un message de relâchement provenant d'un autre noeud du réseau "release_back", opération 1315, le module réseau du noeud source émet un message de terminaison de communication "cal/Terminate", "releaseinc'd" via l'interface note ctrl14 sur la figure 4, à destination du module pont (opération 1316), pour l'informer de la
fermeture de la connexion.
Puis, le module réseau 122 émet un message d'alarme "alarm_dcnBack"' (opération 1317) à destination du module pont 123 du noeud source, ce qui a pour effet de déclencher le traitement d'une alarme par ce moyen de traitement puisque la connexion a été interrompue de manière anormale. Le module réseau diffuse ensuite, à destination de tous les autres noeuds du réseau, un message de mise à jour de tables de charges
"LinkTabFree", comportant notamment une description du service requis et du
chemin correspondant à la connexion, en termes de liens (opération 1320).
Le module réseau effectue alors une opération 1321, identique à I'opération 1324, puis une opération 1322 au cours de laquelle les ressources
associées à la gestion de la connexion sont détruites.
Lorsque dans l'état 1314, le module réseau reçoit une commande de libération de connexion "Release Request" en mode message, provenant du module réseau du noeud destinataire (opération 1318), le module réseau émet un message de relâchement "release" (figure 12), opération 1319, puis
effectue les opérations 1320,1321 et 1322.
La figure 14 représente un algorithme mis en oeuvre par le module
réseau 122 d'un noeud intermédiaire, pour une transmission en mode connecté.
En ce qui concerne chaque noeud intermédiaire, après avoir été dans un état d'initialisation 1330, un message entrant "set-up" (figure 12) est reçu au cours d'une opération 1331, de la part d'un noeud source (voir opération 1305 sur la figure 13). Le service requis pour la connexionconsidérée est alors extrait de ce message "set-up". Le module réseau du noeud intermédiaire effectue alors un calcul des paramètres de transmission, à partir du service requis, puis, si la charge est acceptable, une mise à jour de ses
tables de charge, au cours d'une opération 1332, détaillée figure 26.
Ensuite, au cours d'un test 1335, le module réseau du noeud intermédiaire détermine si la bande passante nécessaire à la connexion
envisagée est disponible sur le chemin sélectionné, ou non (voir test 1304).
Lorsque le résultat du test 1335 est négatif, au cours d'une opération 1333, le module réseau du noeud intermédiaire émet un message de relâchement de connexion "release_back" à destination du noeud source (voir opération 1310 sur la figure 13). Puis le module réseau du noeud intermédiaire libère les ressources associées à la gestion de la connexion considérée,
opération 1334.
Lorsque le résultat du test 1335 est positif, au cours d'une opération 1336, le module réseau émet un message d'initialisation "set-up" à destination du module réseau du noeud destinataire, par l'intermédiaire de chacun des modules réseau des éventuels noeuds intermédiaires restant à traverser. Ce message est émis après mise à jour du champ identifiant la
position du noeud dans le chemin, à partir de la description du chemin en
termes de liens (voir figure 12). Ensuite, au cours d'une opération 1337, le compteur d'horloge "cncAckWait' est initialisé à une valeur qui correspond à la durée maximale accordée à l'établissement de la connexion. Le module réseau se met alors dans l'état 1338 d'attente de la réponse du réseau quant à l'établissement de la
connexion.
Dans cet état 1338, cinq événements différents peuvent se
produire, au cours d'opérations 1339,1341,1345,1346 et 1347.
Lorsque le message entrant est un message "cncAckWaitr', provenant du passage à zéro de la valeur du compteur de signaux d'horloge "cncAckWait" initialisé au cours de l'opération 1337 (opération 1339), le module réseau émet un message de relâchement "release" (opération 1340), à destination du noeud destinataire, par l'intermédiaire des éventuels autres noeuds intermédiaires qui le séparent du noeud destinataire, et émet un message de relâchement "release_back", à destination du noeud source, par I'intermédiaire des éventuels autres noeuds intermédiaires qui le séparent du noeud source (opération 1342). Ensuite, au cours d'une opération 1343, le module réseau du noeud intermédiaire considéré procède à la mise à jour des tables de charge associées à la connexion qui a été rejetée. Au cours d'une opération 1344 les ressources associées à la gestion de la connexion sont alors
libérées.
Lorsque le message entrant est un message "release", provenant d'un éventuel autre noeud source ou d'un noeud intermédiaire entre le noeud source et le noeud intermédiaire considéré, (opération 1341), le module réseau
effectue les opérations 1342 à 1344.
Lorsque, dans l'état 1338, le message entrant est un message "LinkTabFree" (opération 1347), ce message est mémorisé et le module réseau
reste dans l'état 1338.
Lorsque, dans l'état 1338, le message entrant est un message de demande de fin de connexion émis par le module de pont 123 du noeud considéré (opération 1346) ce message est mémorisé et le module réseau
reste dans l'état 1338.
* Enfin, lorsque le message entrant est un message "LinkTabLoad',
comportant notamment la description du service requis, ainsi que la description
du chemin en termes de liens, en provenance du noeud source (voir opération 1313 sur la figure 13), opération 1345, le module réseau se met dans un état 1348 au cours duquel il attend une évolution de la connexion et transmet toutes les données destinées à être transmises en mode connecté, sur la connexion
mise en place.
On observe ici que le message "LinkTabLoad" a, vis à vis d'un noeud intermédiaire (et du noeud destinataire), pour fonction de confirmer
l'établissement de la connexion, au cours de l'opération 1345.
Dans l'état 1348, trois événements peuvent se produire, au cours d'opérations
1349, 1350 et 1351.
Lorsque, dans l'état 1348, le message entrant est un message "LinkTabFree", opération 1351, ce message est mémorisé et le module réseau
reste dans l'état 1348.
Lorsque, dans l'état 1348, le message entrant est un message
"release", I'opération 1353 qui sera décrite plus loin est effectuée.
Enfin, lorsque, dans l'état 1348, le message entrant est un message de demande de fin de connexion, émis par exemple par le module de pont 123 du noeud considéré (opération 350) le module réseau émet un message de relâchement "release_back' à destination du noeud source (opération 1352), par l'intermédiaire de chaque éventuel autre noeud
intermédiaire qui sépare le noeud intermédiaire considéré du noeud source.
A la suite de l'une des opérations 1349 ou 1352, le module réseau effectue, au cours d'une opération 1353, l'émission d'un message de relâchement "release" à destination du noeud destinataire, par l'intermédiaire de chaque éventuel autre noeud intermédiaire qui sépare le noeud intermédiaire
considéré du noeud destinataire.
Le module réseau effectue alors une opération 1354 identique à l'opération 1324, puis une opération 1355 au cours de laquelle le compteur d'horloge "cncAckWait" est initialisé à une valeur qui correspond à la durée maximale accordée à la libération de la connexion. Le module réseau se met alors dans l'état 1356 d'attente de la réponse du réseau quant au relâchement
de la connexion.
Dans l'état 1356, deux messages peuvent survenir, au cours
d'opérations 1357 et 1358.
Lorsque le message entrant est un message "LinkTabFree", opération 357, les ressources associées à la gestion de la connexion sont
libérées conformément à l'opération 360.
Lorsque, dans l'état 1356, le message entrant est un message "cncAckWait", provenant du passage à zéro de la valeur du compteur de signaux d'horloge "cncAckWait" initialisé au cours de l'opération 1355 (opération 358) le module réseau émet un message d'alarme "alarm_dcnTO" (opération 359) à destination du module pont du noeud considéré, ce qui a pour effet de déclencher le traitement d'une alarme par ce moyen de traitement
puisque la connexion n'a pas été relâchée de manière normale.
A la suite de l'une des opérations 1357 ou 1359, les ressources associées à la gestion de la connexion sont libérées, conformément à
l'opération 360.
La figure 15 représente un algorithme mis en oeuvre par le module
réseau 122 du nceud destinataire, pour une transmission en mode connecté.
En ce qui concerne le noeud destinataire après avoir été dans un état d'initialisation 1370, un message entrant "setUp_end" est reçu au cours
d'une opération 1371, de la part du noeud source ou d'un noeud intermédiaire.
Le module réseau du noeud destinataire effectue alors l'extraction du service requis (opération 1371), puis le calcul des paramètres de transmission à partir du service requis, et, si la charge est acceptable, la mise à jour de la table de charge, au cours d'une opération 1372 similaire à l'opération 1332, décrite en
référence à la figure 14.
Ensuite, au cours d'un test 1373, le module réseau du noeud destinataire détermine si la bande passante nécessaire à la connexion envisagée est disponible sur le chemin sélectionné, ou non (voir tests 1304 et
1335 sur les figures respectives 13 et 14).
Lorsque le résultat du test 1373 est négatif, au cours d'une opération 1333, le module réseau du noeud destinataire émet, à destination du noeud source et de tous les éventuels noeuds intermédiaires, comme le noeud 22 du réseau de la figure 1, un message de relâchement "release_back", au cours d'une opération 1380. Ensuite, les ressources associées à la gestion de
la connexion sont libérées (opération 1382).
Lorsque le résultat du test 1373 est positif, le module réseau du noeud destinataire émet, à destination du module pont du meme noeud, un message de demande de connexion "connect_ind', au cours d'une opération 1374. Puis, le module réseau se met dans un état 1375 d'attente de la
réponse du module pont.
Dans l'état 1375, trois événements peuvent survenir, au cours
d'opérations 1376, 1377 et 1378.
Lorsque le message entrant est un message de relâchement "release", provenant du noeud source ou de l'un des noeuds intermédiaires, il
est mémorisé au cours de l'opération 1376.
Lorsque, dans l'état 1375, le message entrant est une réponse défavorable "callReq_nack", correspondant à un message "connect_ans" négatif, provenant du module pont (opération 1378) au cours d'une opération 379, le module réseau procède à la mise à jour des tables de charge associées
à la connexion qui a été rejetée.
Les opérations 1380 et 1382 sont alors effectuées.
Enfin, lorsque, dans l'état 1375, le message entrant est un message favorable "callReq_ack", correspondant à un message "connect_ans" positif, en provenance du module pont du noeud destinataire (opération 1377) le
module réseau émet un message "connect", directement vers le noeud source.
L'information de routage représentative du chemin utilisé par le message est déterminée par le module réseau à partir de la table de routage décrite en
référence à la figure 8a.
Ensuite, au cours d'une opération 1383, le compteur d'horloge "cncAckWaif" est initialisé à une valeur qui correspond à un délai maximum accordé à l'établissement de la connexion demandée. Le module réseau se met alors dans l'état d'attente de la réponse du réseau quant à l'établissement de la
connexion, état 1384.
Dans cet état 1384, cinq événements peuvent survenir au cours
d'opérations 1385, 1386, 1387, 1389 et 1390.
Lorsque le message entrant est un message de relâchement "release", provenant du noeud source ou de l'un des noeuds intermédiaires, il
est mémorisé au cours de l'opération 1385.
Lorsque, dans l'état 1384, le message entrant est un message de mise à jour de table de charge "LinkTabFree", provenant du noeud source, il est
mémorisé au cours de l'opération 1389.
Lorsque, dans l'état 1384, le message entrant est un message de demande de fin de connexion provenant du module pont du noeud considéré, il
est mémorisé au cours de l'opération 1386.
Lorsque, dans l'état 1384, le message entrant est un message "cncAckWait", provenant du passage à zéro de la valeur du compteur de signaux d'horloge "cncAckWait" initialisé au cours de l'opération 1383 (opération 1390) le module réseau émet un message de relâchement de connexion "release_back", opération 1391, à destination du ou des noeuds
intermédiaires et du noeud source.
Ensuite, au cours d'une opération 1392, le module réseau du noeud destinataire procède à la mise à jour des tables de charge associées à la connexion qui a été rejetée. Puis, au cours d'une opération 1393, les
ressources associées à la gestion de la connexion sont libérées.
Enfin, lorsque, dans l'état 1384, le message entrant est un
message "LinkTabLoad", message comportant notamment la description du
service requis ainsi que la description du chemin en terme de liens (message
ayant pour fonction de confirmer l'établissement de la connexion), conformément à l'opération 1387, le module réseau du noeud destinataire se
met dans un état 1388 d'attente d'évolution de la connexion.
On observe ici que le message "LinkTabLoacd" a, vis à vis d'un
noeud intermédiaire, pour fonction de confirmer l'établissement de la connexion.
Dans l'état 1388, trois événements peuvent survenir, au cours
d'opérations 1394,1396 et 1397.
Lorsque, dans l'état 1388, le message entrant est un message de mise à jour de table de charge "LinkTabFree", provenant du noeud source, il est
mémorisé au cours de l'opération 1396.
Lorsque, dans l'état 1388, le message entrant est un message de relâchement "release" (opération 1397) le module réseau effectue la notification "callTerminate", correspondant à un message "release_incr', de la rupture de la connexion au module pont du noeud destinataire (opération 1398). Ensuite,
l'opération 1399 qui sera décrite plus loin est effectuée.
Enfin, lorsque, dans l'état 1388, le message entrant est un message de demande de fin de connexion émis par le module pont du noeud, opération 394, le module réseau émet un message de relâchement "releaseback" à destination du noeud source et des noeuds intermédiaires
conformément à l'opération 1395.
A la suite de l'une des opérations 1395 ou 1398, le module réseau effectue une opération 1399 identique à l'opération 1324 sur la figure 13, puis une opération 1400 au cours de laquelle le compteur d'horloge "cncAckWait" est initialisé à une valeur qui correspond à la durée maximale accordée à la libération de la connexion. Le module réseau se met alors dans l'état 1401 d'attente de la réponse du réseau quant au relâchement de la connexion de la
même façon que pour les noeuds intermédiaires.
Dans l'état 1401, deux messages peuvent survenir, au cours
d'opérations 1402 et 1403.
Lorsque le message entrant est un message "LinkTabFree", opération 1402, les ressources associées à la gestion de la connexion sont
libérées, opération 1405.
Lorsque, dans l'état 1401, le message entrant est un message "cncAckWait', provenant du passage à zéro de la valeur du compteur de signaux d'horloge "cncAckWait' initialisé au cours de l'opération 1400 (opération 1403) le module réseau émet un message d'alarme "alarm_dcnTO" (opération 1404), à destination du module pont, ce qui a pour effet de déclencher le traitement d'une alarme par ce moyen de traitement puisque la
connexion n'a pas été relâchée de manière normale.
A la suite de l'une des opérations 1402 ou 1404, les ressources associées à la gestion de la connexion sont libérées conformément à
I'opération 1405.
La figure 16 représente un algorithme mis en oeuvre par le module
réseau 122 d'un noeud voisin, pour une transmission en mode connecté.
En ce qui concerne chaque noeud voisin, après avoir été dans un état d'initialisation 1411, le module réseau du noeud voisin reçoit un message
"LinkTabLoacd', comprenant notamment la description du service requis ainsi
que la description du chemin en termes de liens (opération 1412).
Ensuite, au cours d'une opération 1413, le module réseau du noeud voisin effectue le calcul des paramètres de transmission à partir du service requis, puis, indépendamment de la charge, la mise à jour de la table de
charge.
Ensuite, dans l'état 1414, le module réseau du noeud voisin attend l'évolution de la connexion. Ensuite, au cours d'une opération 1415, il reçoit un message "LinkTabFree" concernant la connexion, message comprenant
notamment la description du service requis ainsi que la description du chemin
en termes de liens.
Ensuite, au cours d'une opération 1416, le module réseau du noeud voisin procède à la mise à jour des tables de charge associées à la connexion qui a été libérée. Puis, au cours d'une opération 1417, les
ressources associées à la gestion de la connexion sont libérées.
On observe ici que le message "LinkTabLoad" a, vis à vis d'un
noeud voisin, pour fonction d'informer sur l'établissement de la connexion.
Ainsi la procédure illustrée ici correspond plutôt à une notification
qu'à un contrôle d'admission.
La figure 17 représente un algorithme mis en oeuvre par "l'accès au bus virtuel" 526 du noeud source de la figure 11 qui permet la détermination de la disponibilité de chemin pour l'établissement d'une connexion, ce qui
correspond, en figure 13, à l'opération 1302 de l'algorithme.
Le module réseau prend en compte la description du service
requis établi par l'application ou le périphérique qui émet le message, au cours
d'une opération 2302.
Ensuite, le module réseau effectue le choix du chemin le plus disponible, au cours de l'opération 2304, à partir de la table de routage décrite en référence à la figure 8a, puis détermine l'identificateur de connexion du
champ 1902 des messages de signalisation représentés figure 12.
Au cours d'un test 2305, le module réseau du noeud source
détermine si un chemin est disponible au cours de l'opération 2304 ou non.
Lorsque le résultat du test 2305 est négatif, le module réseau revendique l'arrêt de la procédure de mise en place de la connexion, au cours d'une opération 2306. Lorsque le résultat du test 2305 est positif, le module réseau effectue le calcul des paramètres de transmission, en particulier de la bande passante, de la taille des paquets transmis, des taux (fréquences d'émission) de paquets et de priorité de la communication correspondant aux champs 1111 à 1113 illustrés en figure 21, en faisant usage de la table de charge, au cours d'une
opération 2303.
Puis, au cours d'une opération 2307, le module réseau: - alloue une mémoire FIFO dite d'émission dans l'unité de mémorisation 106 associée au numéro de canal isochrone des paquets de type isochrone à transmettre depuis le bus 541 (figure 11) en spécifiant les paramètres de transmission précédemment calculés à l'unité d'ordonnancement des paquets 109, - fait varier la taille des paquets en fonction de la modification de la charge des chemins qui interfèrent avec le chemin pour lequel une nouvelle connexion vient d'être établie, ainsi que le taux de paquets sur lesdits chemins, et
- met à jour sa table de charge (figure 8a) pour lesdits chemins.
On notera qu'à partir de ce moment là, le transfert des paquets isochrones depuis le bus série 541 vers le réseau commuté 590, via l'unité de mémorisation 106, est autorisé car l'ensemble des ressources nécessaires à ce
transfert ont été réservées.
Ensuite, au cours d'une opération 2308, le module réseau revendique la poursuite de la mise en place de la connexion L'opération 1302 de l'algorithme de la figure 13 est alors terminée. La figure 18 représente un algorithme mis en oeuvre par "l'accès au bus virtuel" des noeuds intermédiaires 525 et 532, ou du noeud destinataire 529 de la figure 11, qui permet la détermination de la disponibilité de chemin pour l'établissement d'une connexion, ce qui correspond, en figures 14 et 15,
aux opérations 1332 et 1372 des algorithmes considérés.
Le module réseau obtient, d'abord, la description du chemin à
travers les champs 1905, 1906 et 1907 et du service requis associé à la nouvelle connexion, en lisant le champ 1903 du message "set-up" décrit à la figure 12 provenant du noeud source (opération 1305 de la figure 13), au cours
d'une opération 2402.
Puis, le module réseau vérifie la disponibilité du chemin en fonction du service requis, au cours de l'opération 2404, en faisant usage de la
table de charge.
Au cours d'un test 2405, le module réseau du noeud considéré
détermine si le chemin est disponible au cours de l'opération 2404 ou non.
Lorsque le résultat du test 2405 est négatif, le module réseau revendique la procédure de mise en place de la connexion, au cours d'une opération 2406. Lorsque le résultat du test 2405 est positif, le module réseau effectue le calcul des paramètres de transmission, en particulier de la bande passante, de la taille des paquets transmis, des taux (fréquence d'émission) de paquet et de priorité de la communication, en faisant usage de la table de
charge (figure 8a), au cours d'une opération 2403.
Dans le cas du noeud destinataire, le module réseau associé à "l'accès au bus virtuel" 529, alloue une mémoire FIFO dite de réception dans I'unité de mémorisation 106 associée au numéro de canal isochrone des paquets de type isochrone a émettre sur le bus 544 (figure 11). On notera qu'à partir de ce moment là, le transfert des paquets isochrones depuis le réseau commuté 590 vers le bus série 544, via l'unité de mémorisation 106, est autorisé car l'ensemble des ressources nécessaires à ce transfert ont été
réservées.
Puis, au cours d'une opération 2407, le module réseau met à jour sa table de charge, ce qui revient à réserver les ressources nécessaires à la connexion envisagée, puis, au cours d'une opération 2408, il poursuit la mise en place de la connexion. A la fin de l'une des opérations 2406 ou 2408,
l'opération correspondante des algorithmes des figures 14 et 15 est terminée.
La mise à jour de la table de charge s'accompagne d'une mise à jour des paramètres de transmissions associés aux transferts existants représentatifs du trafic sortant pour le noeud considéré, à travers la valeur des champs 1111 à 1113 pour le trafic connecté et 1111, 1113, 1115, 1116 pour le
trafic non connecté.
La figure 19 représente un algorithme mis en oeuvre par "l'accès au bus virtuel" des noeuds voisins 527, 528, 530 et 531 (figure 11) qui permet la détermination de la disponibilité de chemin pour l'établissement d'une
connexion, ce qui correspond, en figure 16, aux opérations 1413.
Le module réseau obtient, d'abord, la description du chemin à
travers les champs 1905, 1906 et 1907 et du service requis (champ 1903) associé à la nouvelle connexion, en lisant le message "LinkTabLoad" (figure 12)
provenant du noeud source (opération 1313), au cours d'une opération 2502.
Ensuite, le module réseau effectue le choix des paramètres de transmission, en particulier de la bande passante, de la taille des paquets transmis, des taux (fréquence d'émission) de paquet et de priorité de la communication, en faisant usage de la table de charge, au cours d'une opération 2503. Puis, au cours d'une opération 2504, le module réseau met à jour sa table de charge. A la fin de l'opération 2504, le fonctionnement de mise
en place de la connexion, par le noeud voisin, est terminé.
On va maintenant décrire en référence à la figure 20, le procédé de transmission selon l'invention pour un paquet de données provenant d'un bus de communication série, par exemple le bus 541 de la figure 11, et destiné
au réseau commuté 590.
Le procédé selon l'invention est mis en oeuvre au niveau du noeud ou dispositif de communication 90 constitué de "l'accès au bus série" 521 et de "l'accès au bus virtuel" 526 selon l'invention, appelé ici noeud ou dispositif
source et qui possède la structure du noeud de la figure 3a.
Dans cet exemple de réalisation, le bus 541 est considéré au sens de l'invention comme un premier réseau véhiculant des paquets de données de types isochrones et asynchrones et le réseau commuté 590 est considéré
comme un deuxième réseau au sens de l'invention.
Le noeud source est apte, selon l'invention, à transmettre des paquets de données isochrones et asynchrones du bus sur le réseau commuté en effectuant une réservation de ressources qui est adaptée aux types des
paquets destinés au réseau commuté.
Selon le type des paquets considérés, le noeud source se
comportera de manière différente comme cela va être expliqué ci-après.
Il convient de noter que le noeud source est également apte, comme tous les noeuds du réseau commuté, à transférer vers un ou plusieurs noeuds du réseau commuté des paquets de données venant d'autres noeuds de
ce réseau.
La figure 20 représente l'algorithme de traitement effectué par le module de contrôle 107 à la réception d'un paquet 1394, en provenance du bus 541 de la figure 11 par l'intermédiaire du moyen d'interfaçage 103 de la figure 3a. Le module de contrôle 107 attend tout d'abord qu'un nouveau paquet du type conforme à la norme IEEE 1394 soit reçu, conformément à
l'étape 200 de l'algorithme de la figure 20.
Au cours de l'étape suivante 201 le module 107 lit l'en-tête du paquet 1394 stocké dans la mémoire FIFO GRF du moyen 103 via l'interface ctrl3 et le bus de données 112. Cela va permettre notamment de déterminer le
type et la taille du paquet reçu.
Au cours d'une étape suivante notée 202, il est prévu de déterminer le type du paquet reçu et, plus particulièrement, d'analyser l'un des champs dénommés "tcode" du paquet de données 1394 afin de vérifier s'il
s'agit d'un paquet de type isochrone.
Le champ "tcode" est noté 284 sur la figure 8b ou 403 sur la figure
10.
S'il s'agit d'un paquet isochrone, alors l'étape 202 est suivie d'une étape 203 et, s'il ne s'agit pas d'un paquet de type isochrone alors l'étape 202
est suivie d'une étape 207.
Au cours de l'étape 203, un test est pratiqué afin de savoir si des
ressources externes au noeud ont été réservées sur le réseau commuté, c'est-
à-dire si une connexion a été prévue pour une transmission en mode connecté.
D'une manière plus précise, le test consiste à rechercher le numéro du canal du
paquet isochrone en vue de déterminer s'il s'agit d'un paquet dit "local", c'est-à-
dire destiné au noeud lui-même.
Si le paquet isochrone est "local", il est alors destiné au module pont 123 de la figure 4 et l'étape 203 est suivie d'une étape 213 qui sera décrite ultérieurement. Au contraire, si un numéro de canal du paquet isochrone a été identifié comme ayant été affecté pour la transmission du paquet sur le réseau, alors le paquet est dit "distant" et, cela signifie que des ressources ont été réservées sur le réseau commuté avant la réception du paquet isochrone ainsi
que des ressources internes au noeud source.
Cette réservation de ressources préalable fait partie d'un mécanisme de détermination d'un chemin disponible sur le réseau commuté et
a été explicité précédemment en référence aux figures 13 à 19.
La réservation de ressources internes en émission, décrite par l'opération 2303 de la figure 17, consiste quant à elle à sélectionner une ou plusieurs zones mémoires de l'unité de mémorisation 106 constituant une mémoire FIFO dite d'émission et à associer cette mémoire FIFO d'émission aux ressources réservées sur le réseau commuté, à savoir, par exemple, le numéro
de canal isochrone.
Ainsi, au cours de l'étape 204 la taille (champ 400 décrit en figure ) du paquet isochrone est stockée (champs 335 à 337 du mode flux décrit en figure 6) dans la mémoire FIFO d'émission préalablement associée au numéro
de canal isochrone.
Au cours de l'étape 205, l'en-tête du paquet isochrone est stocké dans la mémoire FIFO d'émission préalablement associée au numéro de canal isochrone. Dans ce cas, l'étape 205 est suivie d'une étape 206 au cours de laquelle il est prévu de transférer le reste du paquet isochrone depuis la mémoire FIFO GRF du moyen 103 vers l'unité de mémorisation à double port 106 et d'écrire dans la mémoire FIFO d'émission préalablement associée au
numéro de canal isochrone le paquet dans son ensemble.
Suite à l'étape 206, le module de contrôle 107 attend de nouveau
de recevoir le prochain paquet 1394 au cours de l'étape 200.
Si le paquet reçu n'est pas de type isochrone (étape 202), au cours d'uneétape suivante notée 207, il est prévu de déterminer si le paquet
reçu est de type "début de cycle" ("'cycle start", en terminologie anglosaxonne).
Dans l'affirmative, l'étape 208 est exécutée sinon l'étape 213 est exécutée.
L'étape 213 consiste à informer le module pont 123 de la réception d'un paquet 1394 en déclenchant une interruption sur le bus principal
100. Ensuite, l'étape 200 d'attente de paquets est de nouveau exécutée.
Par contre, si un paquet de type "début de cycle" ("cycle start")' a
été reçu, alors l'étape 208 est exécutée.
L'étape 208 consiste à effectuer des opérations de synchronisation. L'étape suivante 209 consiste à vérifier s'il existe une mémoire FIFO dite de réception appartenant à l'unité de mémorisation 106 en attente de transfert d'un paquet isochrone à destination du bus 541 de la figure 11 par
l'intermédiaire du moyen d'interfaçage 103 de la figure 3a.
Cette réservation de ressources internes en réception, décrite par l'opération 2403 de la figure 18, consiste quant à elle à sélectionner une ou plusieurs zones mémoires de l'unité de mémorisation 106 constituant une mémoire FIFO dite de réception et à associer cette mémoire FIFO de réception aux ressources réservées sur le réseau commuté, à savoir, par exemple, le numéro de canal isochrone. Cette réservation de ressources internes en réception s'inscrit dans le cadre plus général de réservation de ressources préalable qui fait partie d'un mécanisme de détermination d'un chemin disponible sur le réseau commuté, explicité précédemment en référence aux
figures 13 à 19.
Dans l'affirmative, la taille isochrone (champs 335 à 337 du mode flux décrit en figure 6) du paquet isochrone à émettre (champs 330 à 334 du
mode flux décrit en figure 6) est lue au cours de l'étape suivante 210.
Ensuite, au cours de l'étape 211 I'en-tête du paquet isochrone est transmis depuis la zone mémoire de l'unité 106 vers la mémoire FIFO ITF du moyen d'interfaçage 103. L'opération d'écriture de l'en-tête peut s'accompagner éventuellement d'une modification du champ "CIP_header" note 406 sur la
figure 10 qui décrit un paquet isochrone.
Enfin, le reste du paquet isochrone est transféré vers la mémoire
FIFO ITF du moyen d'interfaçage 103 au cours de l'étape 212.
Apres exécution de l'étape 212, l'étape 209 est exécutée afin de vérifier qu'il n'existe pas une autre mémoire FIFO en attente de transfert de
paquet dans l'unité de mémorisation 106.
TRANSFERT SUR LE RESEAU COMMUTE
En figure 21, on observe un tableau 1100, comportant trois lignes 1101, 1102 et 1103, chacune des lignes comportant des spécifications de
canals virtuels ("Virtual Channel" en terminologie anglo-saxonne) 1105 à 1110.
Ce tableau est stocké dans l'unité d'ordonnancement des paquets de données
ou module SAR 109.
On rappelle ici que chaque canal virtuel est une entité logique associée à une communication entre deux dispositifs de communication et représentative d'un transfert en mode contrôle, en mode message, ou bien en mode flux. Pour un même transfert, le numéro de canal virtuel est constant et se trouve associé, d'une part, à une mémoire FIFO d'émission dans l'unité de mémorisation 106 du noeud source et, d'autre part, à un mémoire FIFO de
réception dans l'unité de mémorisation 106 du noeud destinataire.
Pratiquement, le numéro de la mémoire FIFO d'émission est déterminé à partir du numéro du canal virtuel. En réception, un numéro de la mémoire FIFO est associé à chaque couple de valeurs décrivant, d'une part, un numéro de canal virtuel et, d'autre part, l'identificateur du noeud émetteur. Le numéro de canal virtuel ainsi que l'identificateur du noeud émetteur sont donc présents dans chaque en-tête de paquet ("Packet Header" en terminologie
anglo-saxonne) tels que décrits a partir des figures 5, 6 et 7.
Dans le tableau de la figure 21, on a choisi de représenter deux
canaux virtuels pour chaque niveau de priorité, pour des raisons de clarté.
Cependant, pour chaque niveau de priorité, le nombre de canaux virtuels peut
varier de zéro à un nombre prédéterminé.
Chacune des spécifications de canaux virtuels comporte: - une information représentative de la taille "specL" 1111 des paquets de données associés au canal considéré; - une information représentative du nombre de paquets à émettre "specCP'" 1112 durant l'intervalle de temps primaire considéré; - une information représentative de la durée "specCT" 1113 de I'intervalle de temps primaire considéré; - une information représentative du niveau de priorité (haut, moyen ou bas) "specprio" 1114 associé au canal; - une information "dyn_CP'" 1117 représentative du nombre de paquets réellement émis sur le canal virtuel, pendant l'intervalle de temps primaire considéré; - une information "dynCT' 1118 représentative du nombre d'intervalles de temps secondaires écoulés pendant l'intervalle de temps primaire considéré; et - une information "VC_state" 1119 représentative de l'état dans lequel se trouve le canal virtuel considéré, "libre", "actif' ou "endormi' (voir figure 12); et - une information "références" 1120 représentative, d'une part, du numéro de la mémoire FIFO dans l'unité de mémorisation 106 dans laquelle sont stockées les données à transmettre, et d'autre part de la valeur du champ d'en-tête de paquet ("Packet Header" en terminologie anglo-saxonne), contenant notamment l'information représentative du chemin à parcourir par le
paquet, ou information de routage.
En outre, les spécifications du niveau de priorité basse comportent: - une information "specCPmin" 1115 représentative de la valeur minimale du nombre de paquets à émettre "specCP" 1112; - une information "specCPmax" 1116 représentative de la valeur maximale du nombre de paquets à émettre "spec_CF" 1112, ceci afin de permettre de diminuer la valeur de "spec_CF" 1112 au cours de l'opération 1218 de l'algorithme de la figure 22 ou de l'augmenter au cours de l'opération 1215 de ce même algorithme, dans la limite de ces bornes "specCpmin" 1115
et "spec_CPmax"1 116.
Enfin, chaque ligne, ou niveau de priorité, est affectée d'une information "prio_state" 1121 représentative de l'état dans lequel se trouve I'ensemble des canaux virtuels du niveau de priorité considéré: lorsqu'au niveau de priorité considéré il ne se trouve aucun canal, le niveau de priorité est "libre", lorsque tous les canaux du niveau de priorité sont dans un état "endorm?, le niveau de priorité est lui-même dans un état "endormi', et dans les
autres cas, le niveau de priorité est "actif'.
La table de spécifications et de priorités 1100 est constituée en plaçant: - en première ligne 1101 (niveau de priorité "haut") tous les canaux virtuels affectés à des transmissions en mode connecté de type "temps réel déterministe" (en terminologie anglo-saxonne "predictive real time"); - en deuxième ligne 1102 (niveau de priorité "moyen") tous les canaux virtuels affectés à des transmissions en mode connecté de type temps réel garanti (connu sous le nom de temps réel garanti, ou, en terminologie anglo-saxonne, "guaranted real time"); - en troisième ligne 1103 (niveau de priorité "bas") tous les canaux virtuels affectés à des transmissions en mode non connecté (connu sous les noms de "asynchrone" et "élastique", ou en terminologie anglo-saxonne "elastic"). Par exemple, les paquets 1394 de type isochrone et véhiculant un trafic de type DV (terme signifiant en terminologie anglosaxonne "Digital Video") seront émis en utilisant des canaux virtuels de niveau de priorité "haut". les paquets 1394 de type isochrone et véhiculant un trafic de type MPEG-2 seront émis en utilisant des canaux virtuels de niveau de priorité "moyen ". Par contre, en général, les paquets 1394 de type asynchrone seront émis en utilisant des canaux virtuels de niveau de priorité "bas". Dans certains cas, par exemple pour l'émission des commandes inter-ponts, les paquets asynchrones peuvent être émis avec la priorité des transferts en mode contrôle, c'est-à-dire de
manière plus prioritaire que les transferts associés au niveau de priorité "haut".
Ainsi, tous les noeuds disposent chacun d'une table de priorité concernant le trafic qu'ils peuvent générer, et chacun s'occupe des messages dont il est la source (principe connu sous le nom de "outgoing trafic" en
terminologie anglo-saxonne, qui signifie "trafic sortant").
On observe ici que les paramètres de transmission sont déterminés par un moyen de contrôle de charge à partir du contenu d'une table de charge. Par conséquent, les paramètres de transmission associés aux canaux virtuels de haute et moyenne priorité 1101 et 1102 sont calculés à partir d'une connaissance, a priori, sur tout le trafic connecté, alors que les paramètres de transmission associés aux canaux virtuels de faible priorité 1103 sont estimés à partir d'une connaissance limitée au trafic non connecté sortant du noeud considéré. L'initialisation de ces registres est effectuée par le module
de contrôle réseau 122 via le module d'interface de communication 120.
La figure 22 représente un algorithme de fonctionnement d'émission des paquets en modes connecté et non connecté. Cet algorithme est mis en oeuvre par l'unité d'ordonnancement des données 109. Le principe du fonctionnement utilisé est que l'ordre d'émission des paquets est basé sur le remplissage d'un intervalle de temps primaire IT-P,
qui comprend lui-même des intervalles de temps secondaires IT-S.
A la suite de l'opération d'initialisation 1201 par remise à zéro de toutes les variables, un test 1202 détermine si un intervalle de temps secondaire s'est écoulé, le début d'un intervalle de temps secondaire étant déterminé à partir d'une horloge temps réel non représentée. Lorsque le résultat du test 1202 est positif, au cours d'une opération 1203, l'unité 109 se place en début de la table de spécifications et de priorités représentée à la
figure 21.
Ensuite, au cours d'une opération 1204, I'information "dynCT" 1118 du canal virtuel considéré est décrémentée. Puis, au cours d'un test 1205, l'unité 109 détermine si la valeur de l'information "dynCT' 1118 du canal virtuel considéré est égale à zéro, ou non. Lorsque le résultat du test 1205 est positif, c'est-à-dire à la fin d'un intervalle de temps primaire, au cours d'un test 1217, I'unité 109 détermine si la valeur de l'information "dyn CPF" 1117 est égale à zéro, ou non. Le test 1217 correspond donc à chaque début d'un
nouvel intervalle de temps primaire IT-P.
Lorsque le résultat du test 1217 est négatif, au cours d'une opération 1218, l'unité 109 gère les priorités de la manière suivante: - pour le trafic déterministe, en priorité haute, les paquets non transmis durant l'intervalle de temps requis, dont le nombre est égal à la valeur "dynCPF" 1117, sont supprimés (perte de paquets) puis, la valeur "dyn_CP"' 1117 est mise à zéro,et - pour le trafic garanti, en priorité moyenne, les paquets non transmis durant l'intervalle de temps sont conservés et la valeur "dyn_CP' 1117 conserve sa valeur, et - pour le trafic élastique, en priorité basse, la bande passante est réduite, par décrémentation de la valeur "specCP" 1112 dans la limite des
bornes autorisées.
A la suite de l'opération 1218 ou lorsque le résultat du test 1217 est positif, une opération 1206 est effectuée. Au cours de l'opération 1206, les spécifications et paramètres de transmission sont mis à jour (voir figure 21): - pour le niveau de priorité "bas", l'information 1111 est mise à jour à la fin de chaque intervalle de temps primaire en fonction d'une part de la charge effective du reseau determinee au cours de l'etape 1215, d'autre part en
fonction des valeurs des champs 1114 et 11 15.
- la valeur de l'information "dyn_CP' 1117 est incrémentée de la valeur de l'information "specCP" 1112, - la valeur de l'information "dynC7" 1118 est incrémentée de la valeur de l'information "specCT" 1113, - la valeur de l'information "VCstate" 1119 passe de l'état
"endormî' à l'état "actif'.
A la suite de l'opération 1206 ou lorsque le résultat du test 1205 est négatif, une opération 1207 consiste, pour l'unité 109, à considérer le canal
virtuel suivant dans la table de spécifications et de priorités.
Ensuite, le test 1208 détermine si la fin de la table de spécifications et de priorités a été dépassée, ou non. Lorsque le résultat du test 1208 est négatif, les opérations 1204 à 1207 sont réitérées. Lorsque le résultat du test 1208 est positif, c'est-à-dire lorsqu'un intervalle de temps secondaire est
achevé, un test 1219 détermine si 'un transfert de type contrôle doit avoir lieu.
Lorsque le test 1219 est positif l'unité 109 demande l'émission du paquet de type contrôle au module 107 (tel que décrit lors de l'opération 1210) au cours
* de l'étape 1220, sinon le test 1209 est exécuté.
Lors de l'étape 1220, l'émission d'un paquet est effectuée.
Le test 1209 détermine si la liste des canaux virtuels de niveau de priorité "haut" possède une information d'état "priostate" 1120 à la valeur "actif' ou non. Lorsque le résultat du test 1209 est positif, au cours d'une opération 1210, en fonction du contenu du champ "références" 1120 correspondant, l'unité 109 demande, au module de contrôle 107, l'émission du paquet depuis l'unité de mémorisation 106 vers l'unité de commutation 108. La suite des opérations mises en oeuvre par le module de contrôle 107 pour l'émission d'un paquet entre l'unité de mémorisation 106 et l'unité de commutation 108 est plus largement décrite en référence à la figure 23. L'unité 109 procède ensuite à la mise à jour de la façon suivante des spécifications du canal virtuel permettant l'émission du paquet considéré: - I'information "dynCPF" 1117 est décrémentée, - si l'information "dyn_CP'" 1117 est égale à zéro, la valeur de l'information "VC_state" 1119 prend la valeur "endormi' et le prochain canal virtuel du même niveau de priorité est considéré et, s'il n'y a aucun autre canal virtuel de même niveau de priorité, le niveau de priorité voit son information "priostate" 1120 prendre la valeur "endormi', En réalité, l'émission du paquet ne se termine que lorsque le prochain noeud intermédiaire a acquitté le contrôle de flux qu'il a opéré sur les données dudit paquet, tel que cela est décrit dans la norme IEEE-1355 et
implémenté par le moyen d'interfaçage 104.
On remarque ainsi que les conflits d'accès aux ressources de transmission (les liens de communications) sont détectés par le protocole de transmission de paquets qui est, par exemple, conforme à la norme IEEE1355 et directement répercuté lors de chaque phase d'émission de paquet 1220, 1210, 1212 et 1214. L'invention permet donc de limiter les effets de ces conflits d'accès pour répartir équitablement l'accès aux ressources entre les différents noeuds du réseau, tout en garantissant une qualité de service spécifiée par le
service requis.
Lorsque le résultat du test 1209 est négatif, un test 1211 détermine si la liste des canaux virtuels de niveau de priorité "moyen" possède une information d'état "priostate" 1120 à la valeur "actif' ou non. Lorsque le résultat du test 1211 est positif, au cours d'une opération 1212, I'unité 109 demande l'émission du paquet au module de contrôle 107 (tel que décrit lors de l'opération 1210) en mode connecté temps réel garanti et procède à la mise à jour de la façon suivante des spécifications du canal virtuel permettant l'émission du paquet considéré: - I'information "dynCP' 1117 est décrémentée, - si l'information "dyn_CP' 1117 est égale à zéro, la valeur de l'information "VC_state" 1119 prend la valeur "endormi' et le prochain canal virtuel du même niveau de priorité est considéré et, s'il n'y a aucun autre canal virtuel de même niveau de priorité, le niveau de priorité voit son information
"priostate" 1120 prendre la valeur "endormi'.
Lorsque le résultat du test 1211 est négatif, un test 1213 détermine si la liste des canaux virtuels de niveau de priorité "bas" possède une information d'état "priostate" 1120 à la valeur "actif' ou non. Lorsque le résultat du test 1213 est positif, au cours d'une opération 1214, I'unité 109 demande l'émission du paquet au module de contrôle 107 (tel que décrit lors de l'opération 1210) en mode non connecté et procède à la mise à jour de la façon suivante des spécifications du canal virtuel permettant l'émission du paquet considéré: - l'information "dynCP' 1117 est décrémentée, - si l'information "dyn_CP' 1117 est égale à zéro, la valeur de l'information "VCstate" 1119 prend la valeur "endormi' et le prochain canal virtuel du même niveau de priorité est considéré et, s'il n'y a aucun autre canal virtuel de même niveau de priorité, le niveau de priorité voit son information
"priostate" 1120 prendre la valeur "endormi'.
Lorsque le résultat du test 1213 est négatif, au cours d'une opération 1215, l'unité centrale 109 procède à l'analyse de la charge effective du réseau. A cet effet, I'unité 109 comptabilise les périodes d'inactivité du module de contrôle 107, pour ajuster le nombre de paquets à émettre par canal
virtuel, pour le trafic de priorité basse (c'est-à-dire en mode non connecté).
En fonction du nombre d'intervalles de temps secondaires non utilisés pour la transmission effective de paquets, la bande passante est accrue, par incrémentation de la valeur "specCP' 1112 dans la limite des bornes autorisées. Puis, les émissions cessent jusqu'à ce que le résultat du test 1202
devienne positif.
L'allocation ou la libération d'un canal virtuel est effectuée par manipulation: - des listes 1101 et 1102, lors de l'exécution des différentes étapes de gestion d'une connexion illustrée en figure 11. - de la liste 1103, lorsque la totalité d'un transfert en mode
message s'achève.
Ainsi, le module réseau 122 tient compte de la charge effective sur
le réseau pour répartir les droits d'accès entre les différents niveaux de priorité.
La figure 23 représente un algorithme de transmission de paquets de données en direction du réseau commuté du type conforme à la norme IEEE 1355. Cet algorithme est mis oeuvre par le module de contrôle 107 sous
le contrôle de l'unité d'ordonnancement (module SAR) 109.
Pour la compréhension de cette description, il sera utile de se
référer, d'une part, à la description faite en référence à la figure 21 représentant
différents registres agencés à l'intérieur de l'unité d'ordonnancement 109 et,
d'autre part, à la description faite en référence à la figure 22, illustrant un
algorithme mis en oeuvre par l'unité d'ordonnancement 109 qui gère la
transmission de paquets de données.
On notera, que pour optimiser les performances globales du système, on peut prévoir plusieurs exemples de tels algorithmes à un instant donné afin de réaliser simultanément des transmissions et des réceptions de
paquets de données.
De retour à la figure 23, lorsque le module de contrôle 107 est sollicité par l'unité d'ordonnancement 109, conformément à l'étape 220 de cet algorithme, ledit module de contrôle doit obtenir des informations de contrôle sur le paquet considéré, incluant notamment l'en-tête de ce paquet, par
l'intermédiaire des signaux de contrôle ctrl 6 représentés sur la figure 3a.
Les informations de contrôle affectées au transfert du paquet de
données considéré sont initialisées à l'étape suivante 221.
L'étape suivante notée 222 consiste à attendre que le bus de données 113 entre l'unité de commutation 108 et l'unité de mémorisation 106 soit disponible et, lorsque celui-ci est disponible, alors l'étape suivante 223 est exécutée. Au cours de celle-ci, l'accès au bus de données 113 est alloué à la transmission du paquet considéré et, au cours d'une étape suivante notée 224, l'en-tête du paquet est écrit dans l'unité de commutation 108 qui sera
brièvement décrite en référence à la figure 26.
Au cours de l'étape suivante notée 225, on vérifie que la
transmission est terminée.
Si la transmission est en effet terminée, alors le paquet dans son ensemble a été transmis et, comme indiqué à l'étape suivante notée 226, le bus
de données 113 est alors libéré.
L'étape 226 est suivie d'une étape 227 au cours de laquelle l'unité d'ordonnancement 109 SAR est informée de la transmission du paquet de données par l'intermédiaire des signaux de contrôle ctrl 5, permettant par là même au prochain paquet d'être transmis par cette unité d'ordonnancement 109. Ceci met fin à la procédure de transmission de paquets de
données.
Afin d'optimiser les performances du mécanisme de transmission de paquets de données, I'unité d'ordonnancement 109 est capable de gérer simultanément de multiples transmissions de paquets de données en fonction
de la disponibilité des ressources de l'unité de commutation 108.
De retour à l'étape 225, lorsque le test pratiqué s'avère négatif, celleci est suivie d'une étape notée 228 au cours de laquelle on vérifie l'état de remplissage des unités de stockage de type "FIFO" de l'unité de commutation 108. Dans le cas o ces unités de stockage ne sont pas remplies, alors l'étape 228 est suivie d'une étape 229 au cours de laquelle des groupes de données constitués de 32 bits chacun et issus de l'unité de mémorisation 106 sont écrits dans les unités de stockage de type "FIFO" de l'unité de commutation 108, que ces données soient de type isochrones ou flux
("stream"), fassent partie d'un message ou soient des données de contrôle.
Le test pratiqué à l'étape 225 est alors ensuite de nouveau exécuté. Lorsqu'une partie d'un paquet de données a été transmise et que l'unité de stockage de type "FIFO" de l'unité de commutation 108 a été remplie (étape 228), alors l'étape suivante notée 230 est exécutée, libérant ainsi l'accès
au bus de données 113.
Au cours de l'étape suivante notée 231, il est prévu d'attendre que I'unité de stockage "FIFO" correspondante de l'unité de commutation 108 soit vide. L'étape suivante, notée 232, met à jour l'état de transmission pour le paquet de données considéré à transmettre par rapport à ce qui a été
transmis au préalable.
L'étape suivante notée 233 consiste à attendre que le bus de données 113 soit disponible et, lorsque celui-ci est disponible, l'étape suivante
notée 234 est alors exécutée.
Au cours de cette étape, un accès au bus de données 113 est affecté à la transmission du paquet de données considéré et l'étape 225 ainsi que les étapes suivantes déjà décrites ci-dessus sont alors de nouveau exécutées. La figure 24 représente un algorithme de réception d'un paquet de
données provenant du réseau commuté du type conforme à la norme 1355.
Cet algorithme est exécuté par le module de contrôle 107 sous le
contrôle de l'unité d'ordonnancement ou module SAR 109.
Le module de contrôle 107 exécute cet algorithme lorsqu'il est informé par l'unité de commutation 108, par l'intermédiaire du signal de contrôle ctrl 4, de la réception d'un nouveau paquet en provenance du réseau commuté
du type conforme à la norme IEEE 1355 (étape 1220).
Afin d'optimiser les performances globales du système, plusieurs algorithmes analogues à celui-ci peuvent se dérouler au même moment afin de
réaliser simultanément la transmission et la réception de paquets de données.
L'étape suivante 1221 consiste à attendre la disponibilité du bus de données 113 entre l'unité de commutation 108 et l'unité de mémorisation 106. Lorsque ce bus de données est disponible, l'étape suivante notée 1222 est exécutée et l'accès au bus est affecté à la réception du paquet de
données considéré.
Au cours de l'étape 1223, l'en-tête du paquet reçu est tout d'abord lu à partir de l'unité de stockage de type FIFO de l'unité de commutation 108, puis est ensuite transmis à l'unité d'ordonnancement 109 au moyen du signal de contrôle ctrl 6, ceci afin de connaître le numéro de la zone mémoire de
l'unité de mémorisation 106 en vue du stockage dudit paquet de données.
Simultanément, l'étape 1260 de l'algorithme représenté à la figure
et qui sera décrit ultérieurement est alors exécutée.
Au cours de l'étape suivante 1224 de l'algorithme de la figure 24, le module de contrôle 107 attend de recevoir de l'unité d'ordonnancement 109, par l'intermédiaire du signal de contrôle ctrl 6, I'identification de la zone mémoire de l'unité de mémorisation 106, comme indiqué à l'étape 1262 de
l'algorithme de la figure 25.
L'identification de la zone mémoire de l'unité de mémorisation 106
reste valable durant toute la réception du paquet de données 1355.
De retour à la figure 24, l'étape 1225 consistant à vérifier la fin de
la réception du paquet de données est exécutée.
Lorsque le résultat du test pratiqué lors de cette étape est positif, ceci signifie que le paquet tout entier a été reçu et il est alors stocké dans l'unité
de mémorisation 106.
Dans le cas o le résultat de ce test est négatif, alors l'étape suivante 1226 est exécutée afin de connaître l'état de remplissage de l'unité de
stockage de type FIFO de l'unité de commutation 108.
Si le test pratiqué au cours de cette étape conduit à un résultat négatif, alors cela signifie que l'unité de stockage de type FIFO n'est pas vide et
l'étape suivante 1227 est exécutée.
Au cours de cette dernière, des groupes de données constitués de 32 bits chacun sont lus à partir de l'unité de stockage de type FIFO de l'unité de commutation 108 et sont écrits dans la zone mémoire de l'unité de mémorisation 106, qu'il s'agisse de données isochrones (mode connecté), d'un message ou de données de contrôle. Ensuite, le test pratiqué à l'étape suivante 1228 est exécuté afin de s'assurer du bon fonctionnement du mécanisme de réception de paquet en
ce qui concerne le débordement de l'unité de mémorisation.
Si le résultat pratiqué au cours de ce test s'avère positif, cela signifie que la zone mémoire correspondante de l'unité de mémorisation 106 a été remplie après la dernière opération d'écriture prévue à l'étape 1227. Au
cours de l'étape suivante 1229, une procédure d'erreur est alors exécutée.
Si le résultat du test pratiqué à l'étape 1228 est négatif, alors
l'étape suivante 1230 est exécutée.
Au cours de l'étape 1230, le seuil de remplissage de la mémoire tampon est testé uniquement pour les zones mémoires destinées à recevoir des données de type "stream" (mode connecté). Une interruption PCI est générée et adressée au module d'interface de communication 120 lorsque la mémoire tampon correspondante est à moitié remplie pour la toute première
fois.
Ensuite, l'étape 1225 déjà décrite ci-dessus est à nouveau exécutée. De retour à l'étape 1226, lorsque le résultat du test qui y est pratiqué s'avère positif, cela signifie qu'une partie du paquet de données a été reçue et que l'unité de stockage de type FIFO de l'unité de commutation 108 est pleine. L'étape suivante notée 1231 consiste à rendre disponible l'accès
au bus de données 113. L'étape suivante 1232 consiste alors à attendre de nouvelles données dans
la ou les unités de stockage correspondantes de type FIFO de
l'unité de commutation 108.
L'étape suivante 1233 met à jour l'état de réception du paquet de données considéré à stocker dans l'unité de mémorisation 106 en fonction de
ce qui a été préalablement reçu.
L'étape suivante 1234 consiste à attendre que le bus de données 113 soit disponible. En cas de disponibilité du bus, l'étape suivante 1235 est exécutée et l'accès au bus de données 113 est alors affecté à la réception du paquet de données considéré. Le test pratiqué à l'étape 1225 déjà décrite ci-dessus est
ensuite de nouveau exécuté.
Lorsqu 'un paquet tout entier a été reçu, le test pratiqué à l'étape 1225 s'avère positif et l'étape suivante 1236 est exécutée libérant ainsi l'accès au bus de données 113. Au cours de l'étape suivante 1237, I'unité d'ordonnancement 109 (module SAR) est informée de la réception du paquet par le signal de contrôle ctrl 6 uniquement pour les zones mémoires destinées à
contenir des données de contrôle ou des messages.
Il est alors mis un terme à la procédure de réception de paquets
conformément à l'étape 1238.
La figure 25 déjà évoquée ci-dessus représente un algorithme de réception de données constituant un message et de données de contrôle en provenance du réseau de commutation du type conforme à la norme IEEE 1355. Cet algorithme est exécuté par l'unité d'ordonnancement 109 ou
module SAR.
Conformément à l'étape 1260, I'unité d'ordonnancement attend qu'un nouvel en-tête de paquet soit lu par le module de contrôle 107 à partir de
l'unité de commutation 108.
Au cours de l'étape suivante notée 1261, l'unité d'ordonnancement 109 attend qu'une zone mémoire de l'unité de mémorisation 106 soit disponible
afin d'y stocker le paquet de données considéré.
L'étape suivante notée 1262 consiste à informer le module de contrôle 107 du bon résultat de l'allocation de zone mémoire dans l'unité de mémorisation 106 en renvoyant l'identification de la zone mémoire
correspondante par l'intermédiaire du signal de contrôle ctrl 6.
Au cours de l'étape suivante 1263, on détermine s'il s'agit d'un
nouvel en-tête de paquet.
Dans le cas o il s'agit d'un nouvel en-tête de paquet, soit qu'il s'agisse du premier paquet d'un message soit d'un paquet de contrôle, alors l'étape suivante notée 1264 est exécutée, sinon l'étape 1265 est exécutée sans
que l'étape 1264 ne soit exécutée au préalable.
Au cours de l'étape 1264, I'unité d'ordonnancement 109 attend qu'une zone mémoire se libère afin de stocker dans le moyen de stockage RAM le message ou le paquet de contrôle et affecte une telle zone mémoire en
vue de ce stockage.
Au cours de l'étape suivante 1265, le transfert de données depuis l'unité de mémorisation 106 jusqu'au moyen de stockage RAM 95, et plus
particulièrement jusqu'à la zone mémoire précédemment affectée, est initialisé.
L'étape suivante 1266 consiste à attendre la fin du transfert avant de libérer la zone mémoire de l'unité de mémorisation 106 précédemment
allouée à l'étape 1261.
Au cours de l'étape suivante 1267, on détermine si un paquet de contrôle ou le dernier paquet d'un message a été reçu et, dans l'affirmative, l'étape suivante 1268 est exécutée, déclenchant par la même une interruption
de type PCI.
Cette interruption vise à informer le module d'interface de communication 120 de la figure 4 de la réception d'un nouveau message ou
d'un paquet de contrôle dans le moyen de stockage RAM 95 de la figure 3a.
L'étape 1268 est ensuite suivie de l'étape 1260 qui a déjà été
décrite ci-dessus.
Dans le cas o le résultat du test pratiqué à l'étape 1267 est
négatif, alors celle-ci est suivie de l'étape 1260 précédemment décrite.
La figure 26 est une vue schématique d'une unité de commutation
108 connue de l'homme de l'art.
Cette unité comporte, par exemple, trois ports externes 1270, 1271 et 1272 comportant chacun une unité de stockage interne et étant chacun reliés à un bus 1274 qui est capable d'échanger des données et des signaux de
contrôle avec le moyen d'interfaçage 104 (figure 3a).
L'unité 108 comporte également trois ports internes 1276, 1277 et 1278 comportant chacun une unité de stockage interne et étant chacun reliés à un bus 1280 qui est capable d'échanger des données et des signaux de contrôle avec l'unité de mémorisation 106 et le module de contrôle 107 (figure 3a). Par ailleurs, l'unité de commutation 108 comporte un organe de routage 1282 qui relie entre eux les différents ports internes et externes dans
les deux sens de transfert.
Claims (84)
1. Procédé de transmission de paquets de données d'un premier réseau vers un deuxième réseau, I'un des réseaux étant un bus de communication véhiculant des paquets de données de types isochrones et asynchrones, caractérisé en ce que, l'autre réseau étant un réseau à commutation de paquets, ledit procédé comporte, effectuée au niveau d'un dispositif de communication connecté au bus de communication et faisant partie du réseau à commutation de paquets, une étape de réservation de ressources
adaptée aux types de paquets de données destinés au deuxième réseau.
2. Procédé selon la revendication 1, caractérisé en ce que la réservation de ressources dite en mode connecté a lieu au moins sur le
deuxième réseau pour les paquets de données isochrones.
3. Procédé selon la revendication 1 ou 2, caractérisé en ce que la réservation de ressources dite en mode connecté, concerne également des
ressources internes au dispositif de communication.
4. Procédé selon la revendication 3, caractérisé en ce que, pour les paquets de données isochrones, la réservation de ressources internes au dispositif de communication est effectuée en fonction des ressources réservées
sur le deuxième réseau.
5. Procédé selon la revendication 3 ou 4, caractérisé en ce que les ressources internes adaptées aux paquets isochrones comprennent au moins
une zone mémoire d'une unité de mémorisation à double port.
6. Procédé selon l'une des revendications 3 à 5, caractérisé en ce
qu'il comporte une étape de stockage de paquets de données isochrones dans
les ressources internes réservées.
7. Procédé selon l'une des revendications 3 à 6, caractérisé en ce
qu'il comporte une étape de transfert de paquets de données isochrones entre les ressources internes réservées et un moyen d'interfaçage avec l'un des réseaux.
8. Procédé selon l'une des revendications 1 à 7, caractérisé en ce
que la réservation de ressources pour les paquets de données isochrones est effectuée avant une étape de réception des paquets au niveau du dispositif de communication.
9. Procédé selon l'une des revendications 1 à 8, caractérisé en ce
que, pour les paquets de données asynchrones, la réservation de ressources dite en mode non connecté concerne uniquement des ressources internes au
dispositif de communication.
10. Procédé selon la revendication 9, caractérisé en ce que les ressources internes adaptées aux paquets asynchrones comprennent au moins une zone mémoire d'un moyen de stockage (RAM) associé à une unité centrale
de traitement (CPU) interne au dispositif de communication.
11. Procédé selon la revendication 10, caractérisé en ce qu'il comporte une étape de stockage de paquets de données asynchrones dans le
moyen de stockage (RAM).
12. Procédé selon l'une des revendications 9 à 11, caractérisé en ce
qu'il comporte une étape de stockage intermédiaire des paquets de données
asynchrones dans une unité de mémorisation à double port.
13. Procédé selon la revendication 12, caractérisé en ce qu'il comporte une étape de transfert de paquets asynchrones entre l'unité de mémorisation à double port et le moyen de stockage (RAM) lorsque le
deuxième réseau est un bus de communication.
14. Procédé selon l'une des revendications 1 à 13, caractérisé en ce
qu'il comporte, effectuée au niveau du dispositif de communication connecté au bus de communication et faisant partie du réseau à commutation de paquets
une opération de commutation de paquets.
15. Procédé selon la revendication 14, caractérisé en ce que l'opération de commutation de paquets consiste à recevoir un paquet venant du premier réseau, à analyser un en-tête du paquet pour connaître sa destination
et à transmettre ledit paquet vers ladite destination.
16. Procédé selon la revendication 12, caractérisé en ce qu'il comporte une étape de transfert entre le moyen de stockage (RAM) et l'unité de mémorisation à double port lorsque le deuxième réseau est le réseau à
commutation de paquets.
17. Procédé selon l'une des revendications 9 à 13, caractérisé en ce
que la réservation de ressources internes adaptée aux paquets asynchrones
est effectuée après une étape de réception d'un paquet asynchrone.
18. Procédé selon l'une des revendications 9 à 13, caractérisé en ce
que la réservation de ressources internes est effectuée paquet par paquet.
19. Procédé selon l'une des revendications 1 à 18, caractérisé en ce
qu'il comporte lorsque le premier réseau est le bus de communication: une étape de détermination, au niveau d'un dispositif de communication dit source connecté au bus de communication et faisant partie du réseau à commutation de paquets, pour chaque information qu'il a à transmettre, d'un chemin à faire suivre à ladite information sur ledit réseau commuté, - une étape d'information au cours de laquelle ledit dispositif de communication source diffuse, à destination de tous les autres dispositifs de communication du réseau, une information représentative de la bande passante nécessaire pour effectuer une transmission en mode connecté, et une étape d'attribution de bande passante au cours de laquelle on attribue, d'une part, aux transmissions en mode connecté, la bande passante qui leur est nécessaire et, d'autre part, tout ou partie de la bande passante disponible
à chaque transmission à effectuer en mode non connecté.
20. Procédé selon la revendication 19, caractérisé en ce qu'il comporte, pour l'établissement d'une connexion: - effectuée par le dispositif de communication source destiné à transmettre de l'information sur ledit chemin, une étape de transmission à destination de chaque dispositif de communication placé sur ledit chemin, appelé "intermédiaire" d'une information représentative de la bande passante nécessaire pour ladite connexion.
21. Procédé selon la revendication 19 ou 20, caractérisé en ce qu'il comporte, pour chaque transmission d'information, une étape de contrôle de flux effectuée par le dispositif de communication source du chemin suivi par ladite information.
22. Procédé selon l'une quelconque des revendications 19 à 21,
caractérisé en ce qu'il comporte une étape de la transmission d'information
prenant en compte plusieurs niveaux de priorité.
23. Procédé selon la revendication 22, caractérisé en ce qu'au moins un niveau de priorité est affecté à la transmission en mode non connecté.
24. Procédé selon la revendication 22 ou 23, caractérisé en ce que, au cours de l'étape d'attribution de bande passante, la bande passante associée au niveau de priorité correspondant au mode non connecté varie en fonction
d'une durée n'ayant donné lieu à aucune transmission.
25. Procédé selon l'une des revendications 1 à 24, caractérisé en ce
que les ressources internes au dispositif de communication sont libérées
lorsque le paquet a été transmis sur le deuxième réseau.
26. Procédé selon l'une des revendications 1 à 25, caractérisé en ce
que, lorsque le deuxième réseau est le réseau à commutation de paquets, la réservation de ressources pour les paquets de données isochrones concerne
l'établissement d'une connexion sur ce réseau.
27. Procédé selon l'une des revendications 1 à 26, caractérisé en ce
que les ressources réservées en mode connecté sur le deuxième réseau sont
libérées lorsque la connexion est terminée.
28. Procédé de transmission de paquets de données de types isochrones et asynchrones entre deux bus de communication interconnectés, caractérisé en ce que lesdits bus sont interconnectés par un réseau à commutation de paquets, ledit procédé comportant une étape de réservation de ressources sur le réseau à commutation de paquets adaptée aux types de
paquets provenant d'un premier bus et destinés au second bus.
29. - Procédé selon la revendication 28, caractérisé en ce qu'il comporte une étape de réservation de ressources sur le second bus adaptée aux types
de paquets provenant du premier bus et destinés audit second bus.
30. Procédé selon la revendication 28, caractérisé en ce l'étape de réservation de ressources adaptée aux paquets isochrones sur le réseau à commutation de paquets est plus particulièrement effectuée: - au niveau d'un dispositif de communication dit source connecté au premier bus et faisant partie du réseau à commutation de paquets, - au niveau d'un dispositif de communication dit destinataire connecté au second bus et faisant partie du réseau à commutation de paquets, - sur le réseau à commutation de paquets entre lesdits dispositifs source et destinataire.
31. Procédé selon l'une des revendications 28 à 30, caractérisé en ce
qu'il comporte: - une étape de détermination, au niveau d'un dispositif de communication dit source connecté au premier bus de communication et faisant partie du réseau à commutation de paquets pour chaque information qu'il a à transmettre, d'un chemin à faire suivre à ladite information sur ledit réseau commuté, - pour ledit dispositif de communication source qui doit effectuer une transmission en mode connecté, une étape d'information au cours de laquelle ledit dispositif de communication source diffuse, à destination de tous les autres dispositifs de communication du réseau, une information représentative de la bande passante nécessaire pour ladite transmission en mode connecté, et - une étape d'attribution de bande passante au cours de laquelle on attribue, d'une part, aux transmissions en mode connecté, la bande passante qui leur est nécessaire et, d'autre part, tout ou partie de la bande passante disponible
à chaque transmission à effectuer en mode non connecté.
32. Procédé selon la revendication 31, caractérisé en ce qu'il comporte, pour l'établissement d'une connexion: - effectuée par le dispositif de communication source destiné à transmettre de l'information sur ledit chemin, une étape de transmission à destination de chaque dispositif de communication placé sur ledit chemin, appelé "intermédiaire" d'une information représentative de la bande passante nécessaire pour ladite connexion, et - effectuée par chaque dispositif de communication intermédiaire sur ledit chemin, une opération de détermination de disponibilité du lien menant au dispositif de communication suivant sur ledit chemin et, en cas d'indisponibilité, une opération de transmission à destination du dispositif de communication
source, d'une information représentative de l'indisponibilité dudit chemin.
33. Procédé selon l'une quelconque la revendication 32, caractérisé en ce qu'il comporte, pour chaque transmission d'information, une étape de contrôle de flux effectuée par chacun des dispositifs de communication intermédiaires du
chemin suivi par ladite information.
34. Procédé selon l'une quelconque des revendications 31 à 33,
caractérisé en ce qu'il comporte une étape de la transmission d'information
prenant en compte plusieurs niveaux de priorité.
35. Procédé selon la revendication 34, caractérisé en ce qu'au moins
un niveau de priorité est affecté à la transmission en mode non connecté.
36. Procédé selon l'une quelconque des revendications 34 ou 35,
caractérisé en ce que, au cours de l'opération d'attribution de bande passante, la bande passante associée au niveau de priorité correspondant au mode non connecté varie en fonction d'une durée n'ayant donné lieu à aucune transmission.
37. Dispositif de communication assurant la transmission de paquets de données d'un premier réseau vers un deuxième réseau, I'un des réseaux étant un bus de communication véhiculant des paquets de données de types isochrones et asynchrones, caractérisé en ce que le dispositif, étant connecté audit bus et faisant partie d'un réseau à commutation de paquets constituant l'autre réseau, comporte des moyens de réservation de ressources adaptée aux
types de paquets de données destinés au deuxième réseau.
38. Dispositif selon la revendication 37, caractérisé en ce que les moyens de réservation de ressources sont disposés au moins sur le deuxième
réseau pour les paquets de données isochrones.
39. Dispositif selon la revendication 37 ou 38, caractérisé en ce que la réservation de ressources concerne également des ressources internes au
dispositif de communication.
40. Dispositif selon la revendication 39, caractérisé en ce que, pour les paquets de données isochrones, les moyens de réservation de ressources internes au dispositif de communication effectuent une réservation de
ressources en fonction des ressources réservées sur le deuxième réseau.
41. Dispositif selon la revendication 39 ou 40, caractérisé en ce que les moyens de réservation de ressources internes adaptée aux paquets isochrones comportent au moins une zone mémoire d'une unité de mémorisation à double port.
42. Dispositif selon l'une des revendications 37 à 41, caractérisé en ce
que, lorsque le deuxième réseau est le réseau à commutation de paquets, la réservation de ressources pour les paquets de données isochrones concerne
l'établissement d'une connexion sur ce réseau.
43. Dispositif selon l'une des revendications 39 à 42, caractérisé en ce
qu'il comporte un moyen de stockage de paquets de données isochrones dans
les ressources internes réservées.
44. Dispositif selon la revendication 39 à 43, caractérisé en ce qu'il comporte des moyens de transfert de paquets de données isochrones entre les
ressources internes réservées et un moyen d'interfaçage avec l'un des réseaux.
45. Dispositif selon l'une des revendications 37 à 44, caractérisé en ce
que la réservation de ressources pour les paquets de données isochrones est effectuée avant une étape de réception des paquets au niveau du dispositif de communication.
46. Dispositif selon l'une des revendications 37 ou 45, caractérisé en
ce que, pour les paquets de données asynchrones, la réservation de ressources concerne uniquement des ressources internes au dispositif de communication.
47. Dispositif selon la revendication 46, caractérisé en ce que les ressources internes adaptées aux paquets asynchrones comprennent au moins une zone mémoire d'un moyen de stockage (RAM) associé à une unité centrale
de traitement (CPU) interne au dispositif de communication.
48. Dispositif selon la revendication 46 ou 47, caractérisé en ce qu'il comporte un moyen de stockage intermédiaire des paquets de données
asynchrones dans une unité de mémorisation à double port.
49. Dispositif selon la revendication 48, caractérisé en ce qu'il comporte un moyen de transfert de paquets asynchrones entre l'unité de mémorisation à double port et le moyen de stockage (RAM) lorsque le
deuxième réseau est un bus de communication.
50. Dispositif selon la revendication 48, caractérisé en ce qu'il comporte un moyen de transfert entre le moyen de stockage (RAM) et l'unité de mémorisation à double port lorsque le deuxième réseau est le réseau à
commutation de paquets.
51. Dispositif selon l'une des revendications 46 à 50, caractérisé en ce
que la réservation de ressources internes adaptée aux paquets asynchrones
est effectuée après une étape de réception d'un paquet asynchrone.
52. Dispositif selon l'une des revendications 46 à 51, caractérisé en ce
que la réservation de ressources internes est effectuée paquet par paquet.
53. Dispositif selon l'une des revendications 37 à 52, caractérisé en ce
qu'il comporte, au niveau d'un dispositif de communication dit source connecté au bus de communication et faisant partie du réseau à commutation de paquets
un moyen de commutation de paquets.
54. Dispositif selon la revendication 53, caractérisé en ce que le moyen de commutation de paquets comprend au moins un moyen de réception des paquets arrivant sur ses ports, un moyen d'analyse de l'en-tête desdits paquets, un moyen de transmission desdits paquets sur le port décodé par ledit
moyen d'analyse.
55. Dispositif selon l'une des revendications 37 à 54, caractérisé en ce
qu'il est adapté à déterminer, pour chaque information qu'il a à transmettre, le chemin à lui faire suivre sur le réseau et un mode de transmission, connecté, ou non, ledit dispositif comportant: - un moyen d'information adapté, pour chaque transmission en mode connecté, à diffuser, à destination de tous les autres dispositifs de communication du réseau, une information représentative de la bande passante nécessaire pour ladite transmission en mode connecté, et - un moyen d'attribution de bande passante, adapté à attribuer, d'une part, aux transmissions en mode connecté, la bande passante qui leur est nécessaire et, d'autre part, tout ou partie de la bande passante disponible à
chaque transmission à effectuer en mode non connecté.
56. Dispositif selon la revendication 55, caractérisé en ce que le moyen d'information est adapté, pour l'établissement d'une connexion, à transmettre, à destination de chaque dispositif de communication placé sur ledit chemin, appelé "intermédiaire", une information représentative de la bande passante nécessaire pour ladite connexion.
57. Dispositif selon l'une quelconque des revendications 55 ou 56,
caractérisé en ce qu'il comporte un moyen de contrôle de flux adapté, pour chaque transmission d'information en mode non connecté, à vérifier la
disponibilité du chemin suivi par ladite information.
58. Dispositif selon l'une quelconque des revendications 55 à 57,
caractérisé en ce qu'il comporte un moyen de transmission d'information
prenant en compte plusieurs niveaux de priorité.
59. Dispositif selon la revendication 58, caractérisé en ce que le moyen de transmission est adapté à ce qu'au moins un niveau de priorité soit
affecté à la transmission en mode non connecté.
60. Dispositif selon l'une quelconque des revendications 58 ou 59,
caractérisé en ce que le moyen d'attribution de bande passante est adapté à ce que la bande passante associée au niveau de priorité correspondant au mode non connecté varie en fonction d'une durée n'ayant donné lieu à aucune
transmission.
61. Dispositif de communication selon la revendication 60, caractérisé en ce que le moyen d'attribution de bande passante est adapté à ce que ladite durée soit la durée séparant la dernière transmission en mode non connecté et la
prochaine transmission en mode connecté.
62. Appareil de traitement de données caractérisé en ce qu'il est associé
à un dispositif selon l'une des revendications 37 à 61.
63. Appareil de traitement de données selon la revendication 62,
caractérisé en ce que ledit appareil est une imprimante.
64. Appareil de traitement de données selon la revendication 62,
caractérisé en ce que ledit appareil est un serveur.
65. Appareil de traitement de données selon la revendication 62,
caractérisé en ce que ledit appareil est un ordinateur.
66. Appareil de traitement de données selon la revendication 62,
caractérisé en ce que ledit appareil est un télécopieur.
67. Appareil de traitement de données selon la revendication 62,
caractérisé en ce que ledit appareil est un scanner.
68. Appareil de traitement de données selon la revendication 62,
caractérisé en ce que ledit appareil est un magnétoscope.
69. Appareil de traitement de données selon la revendication 62,
caractérisé en ce que ledit appareil est un décodeur.
70. Appareil de traitement de données selon la revendication 62,
caractérisé en ce que ledit appareil est un téléviseur.
71. Appareil de traitement de données selon la revendication 62,
caractérisé en ce que ledit appareil est un caméscope.
72. Appareil de traitement de données selon la revendication 62,
caractérisé en ce que ledit appareil est une caméra numérique.
73. Appareil de traitement de données selon la revendication 62,
caractérisé en ce que ledit appareil est un appareil photographique numérique.
74. Réseau de communication comportant au moins deux bus de communication interconnectés véhiculant chacun des paquets de données de types isochrones et asynchrones, caractérisé en ce que ledit réseau comporte un réseau à commutation de paquets qui interconnecte lesdits bus et qui est apte à transmettre du premier bus vers le deuxième bus des paquets données
de types isochrones et asynchrones véhiculés par ledit premier bus.
75. Réseau de communication selon la revendication 74, caractérisé en ce que le réseau à commutation de paquets est apte à réserver des
ressources adaptées aux types de paquets de données à transmettre.
76. Réseau selon la revendication 74 ou 75, caractérisé en ce qu'il comporte plusieurs dispositifs de communication faisant partie du réseau à commutation de paquets, I'un des dispositifs dit source étant connecté au premier bus de communication et: - étant adapté, pour chaque information qu'il a à transmettre, à déterminer un chemin à faire suivre à ladite information sur ledit réseau commuté - comportant un moyen d'information adapté à diffuser, à destination de tous les autres dispositifs de communication du réseau commuté, une information représentative de la bande passante nécessaire pour ladite transmission en mode connecté, et comportant un moyen d'attribution de bande passante adapté à attribuer, d'une part, aux transmissions en mode connecté, la bande passante qui leur est nécessaire et, d'autre part, tout ou partie de la bande passante disponible
à chaque transmission à effectuer en mode non connecté.
77. Réseau selon la revendication 76, caractérisé en ce que, pour l'établissement d'une connexion: - le dispositif de communication source destiné à transmettre de l'information sur ledit chemin, est adapté à transmettre à destination de chaque dispositif de communication placé sur ledit chemin, appelé "intermédiaire", une information représentative de la bande passante nécessaire pour ladite connexion, et - chaque dispositif de communication intermédiaire sur ledit chemin, est adapté à déterminer la disponibilité du lien menant au dispositif de communication suivant sur ledit chemin et, en cas d'indisponibilité, à transmettre à destination du dispositif de communication source, une information représentative de
l'indisponibilité dudit chemin.
78. Réseau selon la revendication 77, caractérisé en ce que chaque dispositif de communication intermédiaire sur le chemin comporte un moyen de contrôle de flux adapté, pour chaque transmission d'information, à vérifier la
disponibilité du chemin suivi par ladite information.
79. Réseau selon l'une quelconque des revendications 76 à 78,
caractérisé en ce que chaque dispositif ayant à transmettre une information comporte un moyen de transmission d'information prenant en compte plusieurs
niveaux de priorité.
80. Réseau selon la revendication 79, caractérisé en ce qu'au moins
un niveau de priorité est affecté à la transmission en mode non connecté.
81. Réseau selon l'une quelconque des revendications 79 ou 80,
caractérisé en ce que le moyen d'attribution de bande passante est adapté à ce que la bande passante associée au niveau de priorité correspondant au mode non connecté varie en fonction d'une durée n'ayant donné lieu à aucune transmission.
82. Réseau de communication comportant au moins deux bus de communication interconnectés véhiculant chacun des données de types isochrones et asynchrones, caractérisé en ce que ledit réseau comporte un réseau à commutation de paquets comportant au moins un dispositif de
communication selon l'une des revendications 37 à 61 qui est connecté à l'un
des bus constituant un réseau.
83. Réseau de communication selon la revendication 82, caractérisé en ce que le réseau à commutation de paquets comporte au moins un dispositif
de communication selon l'une des revendications 37 à 61 qui est connecté à
I'autre bus constituant également un réseau.
84. Réseau de communication selon la revendication 82, caractérisé en ce que le réseau à commutation de paquets comporte au moins un appareil
de traitement de données selon l'une des revendications 62 à 73 qui est
connecté à l'un des bus constituant également un réseau.
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0001553A FR2804812A1 (fr) | 2000-02-08 | 2000-02-08 | Procede et dispositif de communication entre un premier et un deuxieme reseau |
| EP01400316A EP1124357B1 (fr) | 2000-02-08 | 2001-02-08 | Procédé et dispositif de communication entre un premier et un second réseau |
| DE60125611T DE60125611T2 (de) | 2000-02-08 | 2001-02-08 | Verfahren und Vorrichtung zur Kommunikation zwischen einem ersten und einem zweiten Netz |
| US09/778,827 US7123614B2 (en) | 2000-02-08 | 2001-02-08 | Method and device for communicating between a first and a second network |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0001553A FR2804812A1 (fr) | 2000-02-08 | 2000-02-08 | Procede et dispositif de communication entre un premier et un deuxieme reseau |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2804812A1 true FR2804812A1 (fr) | 2001-08-10 |
Family
ID=8846767
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0001553A Pending FR2804812A1 (fr) | 2000-02-08 | 2000-02-08 | Procede et dispositif de communication entre un premier et un deuxieme reseau |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US7123614B2 (fr) |
| EP (1) | EP1124357B1 (fr) |
| DE (1) | DE60125611T2 (fr) |
| FR (1) | FR2804812A1 (fr) |
Families Citing this family (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2816146A1 (fr) * | 2000-10-27 | 2002-05-03 | Canon Kk | Procede et dispositif de gestion d'un reseau de communication |
| US7092378B1 (en) * | 2001-12-10 | 2006-08-15 | At & T Corp. | System for utilizing a genetic algorithm to provide constraint-based routing of packets in a communication network |
| FR2841076A1 (fr) * | 2002-06-13 | 2003-12-19 | Thomson Licensing Sa | Methode et dispositif de transfert de paquets de donnees |
| JP3757917B2 (ja) * | 2002-08-20 | 2006-03-22 | 日本電気株式会社 | パケット転送装置、パケット転送方法解決サーバ、ｄｎｓサーバ、ネットワークシステム及びプログラム |
| GB2392794B (en) * | 2002-09-06 | 2006-03-15 | Canon Europa Nv | Device,apparatus and method for selecting a programme from a plurality of programmes within a network |
| FR2848051B1 (fr) * | 2002-12-03 | 2005-02-25 | Canon Res Ct France Sa | PASSERELLE ET PROCEDE POUR L'INTERCONNEXION DE DEUX RESEAUX, NOTAMMENT UN RESEAU HAVI ET UN RESEAU UPnP |
| FR2850508B1 (fr) | 2003-01-23 | 2005-11-11 | Canon Europa Nv | Procede d'insertion et de traitement d'informations pour le controle par un noeud de la diffusion d'un flux de donnees traversant un reseau de base d'un reseau heterogene, et noeuds correspondants |
| FR2850506B1 (fr) * | 2003-01-24 | 2005-05-20 | Canon Europa Nv | Dispositif d'interface multimedia, procede de traitement d'information, support d'informations et programme d'ordinateur correspondants |
| US7492714B1 (en) * | 2003-02-04 | 2009-02-17 | Pmc-Sierra, Inc. | Method and apparatus for packet grooming and aggregation |
| US20040190553A1 (en) * | 2003-03-26 | 2004-09-30 | Ward Vivian John | Flexible channel system |
| KR100513277B1 (ko) * | 2003-04-16 | 2005-09-09 | 삼성전자주식회사 | 개별적으로 존재하는 네트워크를 연결하는 장치 및 방법 |
| WO2005094075A2 (fr) * | 2004-03-19 | 2005-10-06 | Ucentric Holdings Inc. | Gestion de ressources centralise et support de dispositif support non gere |
| US7522524B2 (en) * | 2004-04-29 | 2009-04-21 | International Business Machines Corporation | Employing one or more multiport systems to facilitate servicing of asynchronous communications events |
| WO2006069197A2 (fr) * | 2004-12-20 | 2006-06-29 | Interactic Holdings, Llc | Interconnexion controlee redimensionnable comprenant des applications optiques et sans fil |
| FR2884943B1 (fr) * | 2005-04-25 | 2007-07-27 | Canon Europa Nv Naamlooze Venn | Procede de gestion de commande au sein d'un reseau de communication, dispositif de controle, produit programme d'ordinateur et moyen de stockage correspondants |
| US8009609B2 (en) * | 2006-06-09 | 2011-08-30 | Alcatel Lucent | Maintaining quality of service for wireless communications |
| US8769267B2 (en) * | 2008-05-30 | 2014-07-01 | The Boeing Company | Geothentication based on new network packet structure |
| US20120320909A1 (en) * | 2011-06-16 | 2012-12-20 | Ziegler Michael L | Sending request messages over designated communications channels |
| US20140161028A1 (en) * | 2012-12-07 | 2014-06-12 | At&T Mobility Ii Llc | Digital mobile radio front end processor |
| US20210280323A1 (en) * | 2020-03-05 | 2021-09-09 | CAREMINDR Corporation | Customizable communication platform with longitudinal alert tags |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0835037A2 (fr) * | 1996-10-04 | 1998-04-08 | Kabushiki Kaisha Toshiba | Node pour la transmission de données et pour la interconnexion de réseaux adapté à un environnement de réseau domestique |
| EP0837579A2 (fr) * | 1996-10-15 | 1998-04-22 | Kabushiki Kaisha Toshiba | Dispositif de commande de transfert de données, dispositif relais et dispositif de contrÔle appropriés pour un réseau domotique |
| FR2780838A1 (fr) * | 1998-07-06 | 2000-01-07 | Canon Kk | Procede et dispositif de communication d'information |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6236655B1 (en) * | 1995-07-19 | 2001-05-22 | Fujitsu Network Communications, Inc. | Port and link identification |
| US6631435B1 (en) * | 1996-02-02 | 2003-10-07 | Sony Corporation | Application programming interface for data transfer and bus management over a bus structure |
| JP4181645B2 (ja) * | 1996-02-29 | 2008-11-19 | 富士通株式会社 | データ処理装置 |
| US6233637B1 (en) * | 1996-03-07 | 2001-05-15 | Sony Corporation | Isochronous data pipe for managing and manipulating a high-speed stream of isochronous data flowing between an application and a bus structure |
| JPH11215143A (ja) * | 1998-01-27 | 1999-08-06 | Canon Inc | データ通信装置及び方法 |
| US6717947B1 (en) * | 1998-12-03 | 2004-04-06 | Lsi Logic Corporation | Method and apparatus for isochronous data transfer with retry capability |
| JP3436174B2 (ja) * | 1999-03-09 | 2003-08-11 | 日本電気株式会社 | 通信方法 |
| US6480923B1 (en) * | 1999-08-19 | 2002-11-12 | International Business Machines Corporation | Information routing for transfer buffers |
| US6363461B1 (en) * | 1999-12-16 | 2002-03-26 | Intel Corportion | Apparatus for memory resource arbitration based on dedicated time slot allocation |
| US6578109B1 (en) * | 2000-06-29 | 2003-06-10 | Sony Corporation | System and method for effectively implementing isochronous processor cache |
| US7463647B2 (en) * | 2001-02-26 | 2008-12-09 | Sony Corporation | Method of and apparatus for providing reserved bandwidth to ethernet devices over switched ethernet including a home network wall plate having a combined IEEE 1394 and ethernet modified hub |
-
2000
- 2000-02-08 FR FR0001553A patent/FR2804812A1/fr active Pending
-
2001
- 2001-02-08 EP EP01400316A patent/EP1124357B1/fr not_active Expired - Lifetime
- 2001-02-08 US US09/778,827 patent/US7123614B2/en not_active Expired - Fee Related
- 2001-02-08 DE DE60125611T patent/DE60125611T2/de not_active Expired - Lifetime
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0835037A2 (fr) * | 1996-10-04 | 1998-04-08 | Kabushiki Kaisha Toshiba | Node pour la transmission de données et pour la interconnexion de réseaux adapté à un environnement de réseau domestique |
| EP0837579A2 (fr) * | 1996-10-15 | 1998-04-22 | Kabushiki Kaisha Toshiba | Dispositif de commande de transfert de données, dispositif relais et dispositif de contrÔle appropriés pour un réseau domotique |
| FR2780838A1 (fr) * | 1998-07-06 | 2000-01-07 | Canon Kk | Procede et dispositif de communication d'information |
Also Published As
| Publication number | Publication date |
|---|---|
| DE60125611T2 (de) | 2007-11-08 |
| EP1124357A1 (fr) | 2001-08-16 |
| US7123614B2 (en) | 2006-10-17 |
| US20010040896A1 (en) | 2001-11-15 |
| EP1124357B1 (fr) | 2007-01-03 |
| DE60125611D1 (de) | 2007-02-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2804812A1 (fr) | Procede et dispositif de communication entre un premier et un deuxieme reseau | |
| EP0403911B1 (fr) | Procédé et dispositif de gestion d'acces au support de transmission d'un réseau de commutation reparti multiservices | |
| JP2528626B2 (ja) | デ―タ通信方法及び装置 | |
| EP2103056B1 (fr) | Procede de reservation et d'allocation dynamique de creneaux temporels dans un reseau avec garantie de service | |
| FR2820921A1 (fr) | Dispositif et procede de transmission dans un commutateur | |
| FR2724277A1 (fr) | Dispositif de mise en forme de trafic et appareil de communication par paquets. | |
| EP1507374A1 (fr) | Procédé et dispositif de gestion de priorité lors de la transmission d'un message. | |
| FR2758681A1 (fr) | Allocation a une pluralite d'elements d'autorisations d'acces a une ressource partagee | |
| FR2925808A1 (fr) | Procede de communication dans un reseau comprenant un reseau primaire et un reseau secondaire | |
| FR2824434A1 (fr) | Procede de diffusion d'un paquet de donnees au sein d'un reseau commute, base sur un calcul optimise de l'arbre de recouvrement | |
| FR2998125A1 (fr) | Procede de transmission de paquets de donnees entre deux modules de communication ainsi que module emetteur et module recepteur | |
| FR2939992A1 (fr) | Procede d'equilibrage de la latence dans un arbre de communication, dispositif, produit programme d'ordinateur et moyen de stockage correspondants | |
| EP0406077A1 (fr) | Système complÀ©mentaire de communication en mode sans-connexion pour réseau temporel asynchrone | |
| FR2790892A1 (fr) | Procede et dispositif de controle de la synchronisation entre deux bus de communication serie d'un reseau | |
| EP2141868B1 (fr) | Contrôle d'admission à un service | |
| FR2848056A1 (fr) | Procedes d'insertion et de traitement d'informations pour la synchronisation d'un noeud destinataire a un flux de donnees traversant un reseau de base d'un reseau heterogene, et noeuds correspondants | |
| FR2816146A1 (fr) | Procede et dispositif de gestion d'un reseau de communication | |
| Moore et al. | Packet sequencing: A Deterministic protocol for QoS in IP networks | |
| FR2827995A1 (fr) | Procede et dispositif de gestion de memoire | |
| EP0270471B1 (fr) | Système de commutation de paquets | |
| FR2831368A1 (fr) | Procede et dispositif de commande des temps de service de cellules multidestination copiees dans le reseau de commutation d'un noeud de commutation asynchrone | |
| FR2831745A1 (fr) | Procede d'etablissement d'une connexion de flux de donnees isochrone impliquant la traversee d'un reseau commute, noeuds d'entree et de sortie correspondants | |
| FR2828357A1 (fr) | Procede de traitement de signaux de telecommande au sein d'un reseau audiovisuel domestique, signal, dispositifs et programme d'ordinateur correspondants | |
| EP1103158B1 (fr) | Procede d'allocation dynamique de debits pour un reseau de communication notamment un reseau du type a hauts debits | |
| FR3001311A1 (fr) | Interface reseau d'un soc comportant un controleur de communication ameliore |