FR2828946A1 - Procede de gestion des delais isochrones associes a des ponts heterogenes dans un heterogene de bus numeriques - Google Patents

Procede de gestion des delais isochrones associes a des ponts heterogenes dans un heterogene de bus numeriques Download PDF

Info

Publication number
FR2828946A1
FR2828946A1 FR0111115A FR0111115A FR2828946A1 FR 2828946 A1 FR2828946 A1 FR 2828946A1 FR 0111115 A FR0111115 A FR 0111115A FR 0111115 A FR0111115 A FR 0111115A FR 2828946 A1 FR2828946 A1 FR 2828946A1
Authority
FR
France
Prior art keywords
given
delay
bridge
original
flow
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.)
Withdrawn
Application number
FR0111115A
Other languages
English (en)
Inventor
Stephane Bizet
Laurent Frouin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to FR0111115A priority Critical patent/FR2828946A1/fr
Priority to US10/216,782 priority patent/US7269137B2/en
Priority to DE60201873T priority patent/DE60201873T2/de
Priority to EP02364034A priority patent/EP1289211B1/fr
Priority to JP2002245708A priority patent/JP3647429B2/ja
Publication of FR2828946A1 publication Critical patent/FR2828946A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4604LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462LAN interconnection over a bridge based backbone

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé de gestion des délais isochrones associés à des ponts compris dans un réseau de bus numériques, chaque pont étant associé à un délai isochrone pour chaque direction de traversée de l'une vers l'autre de ses portes. Le réseau de bus numériques est hétérogène, les bus numériques étant interconnectés entre eux : - soit directement, via des ponts homogènes comprenant chacun une première et une seconde portes à chacune desquelles est connecté un des bus numériques; - soit à travers au moins un réseau commuté, via des ponts hétérogènes comprenant chacun une première porte, à laquelle est connecté un des bus numériques, et une seconde porte, à laquelle est connecté le réseau commuté. Lorsque l'on souhaite établir une connexion de flux impliquant la traversée d'un pont hétérogène donné dans une direction de traversée donnée, on détermine un délai isochrone d'origine, associé à la direction de traversée donnée du pont hétérogène donné, en prenant en compte, dans une proportion propre au pont hétérogène donné, un délai introduit par le passage du flux le long d'un chemin de routage à travers le réseau commuté.

Description

<Desc/Clms Page number 1>
Procédé de gestion des délais isochrones associés à des ponts hétérogènes dans un réseau hétérogène de bus numériques.
Le domaine de l'invention est celui des réseaux de bus numériques. Chaque réseau comprend une pluralité de bus numériques, sur lesquels peuvent être connectés des terminaux. Ceci permet d'interconnecter des terminaux (aussi appelés dispositifs) audio et/ou vidéo, de type analogique et/ou numérique, afin qu'ils échangent des signaux audiovisuels.
Les terminaux appartiennent par exemple à la liste d'équipements suivante (qui n'est pas exhaustive) : récepteurs de télévision (par satellite, par voie hertzienne, par câble, xDSL,...), téléviseurs, magnétoscopes, scanners, caméras numériques, appareils photo numériques, lecteurs DVD, ordinateurs, assistants numériques personnels (PDA), imprimantes, etc.
L'invention s'applique notamment, mais non exclusivement, aux réseaux de bus numériques de type IEEE 1394.
On rappelle que la norme IEEE 1394 est décrite dans les documents de référence suivants :
IEEE Std 1394-1995, Standard for High Performance Serial Bus ;
IEEE Std 1394a-2000, Standard for High Performance Serial Bus (Supplement).
Un troisième document"IEEE P1394.1 Draft 0.17 Standard for High Performance Serial Bus Bridges"décrit comment connecter différents bus de type IEEE 1394.
Plus précisément, l'invention concerne un procédé de gestion des délais isochrones associés à des ponts hétérogènes dans un réseau hétérogène de bus numériques.
On rappelle que, de façon classique, un réseau de bus numériques est homogène.
Les bus numériques sont interconnectés entre eux via des ponts homogènes. Chaque pont homogène comprend une première et une seconde portes, à chacune desquelles est connecté un des bus numériques. Chaque pont permet le transfert de paquets depuis un bus, connecté à sa première porte, vers un autre bus, connecté à sa seconde porte.
A chaque pont est associé un délai isochrone, pour chaque direction de traversée de l'une vers l'autre de ses portes. Ce délai isochrone représente le laps de temps
<Desc/Clms Page number 2>
nécessaire au pont pour passer un paquet isochrone depuis l'une vers l'autre de ses portes.
Le délai isochrone est principalement utilisé pour le transport de paquets isochrones communs (aussi appelés paquets CIP, pour"Common Isochronous Packets") dans le réseau. Un paquet CIP contient une information de temps absolu, indiquant quand le paquet doit être consommé par l'application destinataire. Cette information de temps est calculée par l'initiateur isochrone, pour un paquet transféré sur un bus unique (le terminal d'entrée, "talker", et le terminal destinataire,'1istener", sont connectés au même bus numérique). Lorsque plusieurs ponts séparent le terminal d'entrée, "talker", et le terminal destinataire,'1istener", l'information contenue dans le paquet CIP pourrait ne plus être à jour, du fait de la latence introduite par la traversée des ponts. Afin d'éviter cette situation, chaque pont se trouvant entre le terminal d'entrée et le terminal destinataire augmente l'information temporelle, contenue dans le paquet CIP, avec le délai isochrone propre à ce pont (délai de transfert entre les deux bus interconnectés par ce pont).
Actuellement, et conformément aux normes précitées dans le cas de bus IEEE 1394, chaque pont est associé, pour chaque direction de traversée, à un délai isochrone constant. En d'autres termes, tous les paquets isochrones transférés, à travers le pont, depuis un bus vers un autre bus, sont traités avec le même délai isochrone, quel que soit le flux auquel ils appartiennent.
Dans le cadre de la présente invention, on s'intéresse à un nouveau type de réseau de bus numériques, qualifié d'hétérogène du fait que les bus numériques y sont interconnectés entre eux soit directement, via des ponts homogènes tels que précités, soit à travers au moins un réseau commuté, via des ponts hétérogènes.
Chaque pont hétérogène comprend une première porte, à laquelle est connecté un des bus numériques, et une seconde porte, à laquelle est connecté le réseau commuté. Le réseau commuté comprend une pluralité de noeuds, reliés entre eux par une pluralité de liens. Ces liens sont par exemple du type permettant des transferts de données bidirectionnels, selon la norme IEEE 1355. On rappelle que la norme IEEE 1355 est définie par la référence IEEE Std 1355-1995 Standard for Heterogeneous InterConnect (HIC) (Low Cost Low Latency Scalable Serial Interconnect) (aka ISO/IEC 14575 DIS).
<Desc/Clms Page number 3>
Chaque pont hétérogène joue également le rôle d'un noeud du réseau commuté.
Le réseau hétérogène est par exemple un réseau audiovisuel domestique, comprenant un réseau commuté à haut débit, permettant notamment l'échange en temps réel d'images animées, pour une distribution dans le cadre d'une habitation.
Le fonctionnement d'un tel réseau hétérogène est le suivant : une connexion est établie, via un ou plusieurs ponts et éventuellement via le réseau commuté, entre un premier terminal (ou"listener"en anglais)-connecté à un premier bus numérique-, qui souhaite recevoir des signaux audiovisuels, et un second terminal (ou"talker"en anglais)-connecté à un second bus numérique-, qui peut les lui fournir.
On précise maintenant quelques éléments de la terminologie utilisée dans la suite de la description. Le premier terminal précité est appelé"terminal destinataire", et le second terminal est appelé"terminal d'entrée". Par terminal d'entrée, on entend par exemple une caméra numérique, un appareil photo numérique, un lecteur DVD à sortie numérique, ou tout appareil analogique vu à travers un convertisseur analogique/numérique...
Or, il s'avère que le modèle précité de délai isochrone constant, quel que soit le flux, pour un pont, n'est applicable que pour un pont homogène. Il ne s'applique pas à un pont hétérogène. En d'autres termes, le modèle précité ne peut s'appliquer que si le réseau de bus numériques est homogène, et ne convient donc pas à un réseau de bus numériques hétérogène, auquel on s'intéresse dans le cadre de la présente invention.
En effet, dans le modèle précité, on suppose que le temps de transport sur les bus est constant et le plus souvent négligeable. Ceci est vérifié dans le cas d'un réseau homogène ne comportant que des bus numériques. En revanche, dans le cas d'un réseau hétérogène, le réseau commuté est vu, par n'importe quel terminal connecté à un bus numérique, comme n'importe quel autre bus numérique. Mais, le problème provient du fait que le temps de transfert sur le réseau commuté, contrairement au temps de transfert sur un"vrai"bus, n'est pas constant. En effet, il varie généralement d'un flux à l'autre, puisque le chemin de routage à travers le réseau commuté peut être différent d'un flux à l'autre. Par ailleurs, le temps de transfert sur le réseau commuté n'est généralement pas négligeable.
<Desc/Clms Page number 4>
L'invention a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique.
Plus précisément, l'un des objectifs de la présente invention est de fournir une technique de gestion des délais de transfert de paquets au sein d'un réseau hétérogène constitué de bus numériques d'une part, et d'un réseau commuté d'autre part.
L'invention a également pour objectif de fournir une technique de gestion des délais isochrones au sein d'un tel réseau hétérogène, permettant de respecter les prescriptions de la nonne "IEEE P1394. 1 Draft 0. 17 Standard for High Performance Serial Bus Bridges".
Un autre objectif de l'invention est de fournir une technique de gestion des délais isochrones au sein d'un tel réseau hétérogène, peu consommatrice en termes de ressources, et notamment en termes de ressources mémoire.
Un objectif complémentaire de l'invention est de fournir une technique de gestion des délais isochrones au sein d'un réseau hétérogène de bus numériques, permettant le transfert de paquets isochrones dédiés à des applications audiovisuelles.
Par exemple, l'invention a pour objectif de permettre des échanges isochrones en temps réel, au sein d'un réseau audiovisuel domestique hétérogène, d'images animées.
Encore un objectif de l'invention est de proposer une telle technique de gestion des délais isochrones au sein d'un réseau hétérogène qui soit adaptée à tous les types de flux, quel que soit le chemin de routage emprunté au sein du réseau.
Ces différents objectifs, ainsi que d'autres qui apparaîtront par la suite, sont atteints selon l'invention à l'aide d'un procédé de gestion des délais isochrones associés à des ponts compris dans un réseau de bus numériques, chaque pont étant associé à un délai isochrone pour chaque direction de traversée de l'une vers l'autre de ses portes.
Selon l'invention, ledit réseau de bus numériques est hétérogène, les bus numériques étant interconnectés entre eux : soit directement, via des ponts homogènes comprenant chacun une première et une seconde portes à chacune desquelles est connecté un des bus numériques ; soit à travers au moins un réseau commuté, via des ponts hétérogènes comprenant chacun une première porte, à laquelle est connecté un des bus numériques, et une seconde porte, à laquelle est connecté le réseau commuté, le
<Desc/Clms Page number 5>
réseau commuté comprenant une pluralité de noeuds reliés entre eux par une pluralité de liens, chaque pont hétérogène formant un des noeuds du réseau commuté ; et, lorsque l'on souhaite établir une connexion de flux impliquant la traversée d'un pont hétérogène donné dans une direction de traversée donnée, le procédé comprend l'étape suivante : on détermine un délai isochrone d'origine, associé à la direction de traversée donnée du pont hétérogène donné, en prenant en compte, dans une proportion propre au pont hétérogène donné, m délai introduit par le passage du flux le long d'un chemin de routage à travers le réseau commuté.
Ainsi, l'invention repose sur une approche tout à fait nouvelle et inventive de la gestion des délais isochrones, au sein d'un réseau comprenant des bus numériques. En effet, l'invention repose notamment sur la mise en oeuvre d'un traitement particulier des délais isochrones, au sein de ponts hétérogènes reliant d'une part un bus numérique connecté à sa première porte, et d'autre part un réseau commuté relié à sa seconde porte.
Un tel traitement consiste à calculer, au niveau de chacun des ponts hétérogènes situés sur le chemin de routage d'un flux donné, un délai isochrone tenant compte, d'une part du temps de traversée du pont hétérogène par un paquet du flux, et d'autre part d'une partie du temps de transfert du paquet au sein du réseau commuté le long du chemin de routage. L'invention offre donc une solution avantageuse au problème de la gestion des temps de transfert de paquets de données au sein d'un réseau commuté, de tels temps de transfert n'étant, contrairement aux temps de transport sur un bus numérique, pas négligeables, et variables d'un flux à l'autre.
Selon une première variante avantageuse de l'invention, ladite étape de détermination d'un délai isochrone d'origine comprend elle-même les étapes suivantes : on obtient un chemin de routage dudit flux à travers le réseau commuté, depuis le pont hétérogène donné vers un autre pont hétérogène ; on obtient un délai introduit par le passage du flux le long du chemin de routage ; on détermine une proportion propre au pont hétérogène donné, dans laquelle celui-ci doit tenir compte du délai introduit par le passage du flux le long du chemin de routage ;
<Desc/Clms Page number 6>
on calcule un délai isochrone d'origine, associé à la direction de traversée donnée du pont hétérogène donné, en prenant en compte, dans la proportion propre au pont hétérogène donné, le délai introduit par le passage du flux le long du chemin de routage.
Par exemple, un délai isochrone d'origine calculé, selon l'invention, dans un pont hétérogène d'entrée dans le réseau commuté pourra tenir compte du temps de traversée de ce pont d'entrée et de la moitié du temps de transfert du flux le long de son chemin de routage au travers du réseau commuté. De même, au niveau du pont hétérogène de sortie du réseau commuté, le délai isochrone d'origine pourra tenir compte du temps de traversée de ce pont hétérogène de sortie par un paquet du flux, et de la seconde moitié du temps de transfert des paquets du flux au travers du réseau commuté.
Selon une deuxième variante avantageuse de l'invention, ladite étape de détermination d'un délai isochrone d'origine comprend elle-même l'étape suivante : on choisit un délai isochrone d'origine possédant une valeur prédéterminée.
Un tel choix peut être arbitraire, ou être par exemple fixé a priori par le constructeur des ponts hétérogènes, en fonction de résultats de tests ou de simulations.
Préférentiellement, lesdits bus numériques sont des bus numériques de type IEEE 1394.
De manière préférentielle, ledit réseau commuté est un réseau audiovisuel domestique, ledit réseau hétérogène permettant d'interconnecter une pluralité de terminaux, connectés les uns aux noeuds et les autres aux bus numériques.
Un tel réseau audiovisuel domestique permet par exemple l'échange d'images animées, ou de fichiers son, en temps réel dans le cadre d'une habitation.
Avantageusement, le délai, Dréseau commuté, introduit par le passage du flux le long du chemin de routage est calculé selon la formule suivante : Dréseau commuté = Nnoeuds intermédiaires Dcommutation avec Nnoeuds intermédiairesie nombre de noeuds intermédiaires le long du chemin de routage, et Dcommutation le délai de commutation moyen par noeud.
Ainsi, on prend en compte le délai introduit par la traversée de chacun des noeuds situés sur le chemin de routage du flux, de façon à obtenir une estimation la plus exacte possible du temps de transfert du flux au sein du réseau commuté.
<Desc/Clms Page number 7>
Préférentiellement, ladite proportion propre au pont hétérogène donné est d'environ 50 %.
Cette proportion peut bien sûr prendre n'importe quelle autre valeur comprise entre 0 et 100%, à condition que le délai introduit par le passage du flux le long du chemin de routage soit intégralement pris en compte par l'ensemble des ponts hétérogènes traversés par le flux. Ainsi, on peut envisager qu'un pont hétérogène d'entrée dans le réseau commuté tienne compte de 30 % du délai Dréseau commuté dans le calcul de son délai isochrone d'origine, à condition que le pont hétérogène de sortie du réseau commuté tienne compte de 70 % de ce délai Deseau commuté lors de la détermination de son propre délai isochrone d'origine.
Selon une caractéristique avantageuse de l'invention, le délai isochrone d'origine Disochrone origine est calculé selon la formule suivante :
Figure img00070001

Disochrone origine = (P% X Dréseau commuté) + Dtraversée FIFO origine + Dtraitement pont avec P% la proportion propre au pont hétérogène donné, Dréseau commuté le délai introduit par le passage du flux le long du chemin de routage, Dtraversée FIFO origine le délai de traversée, par le flux, d'une mémoire FIFO d'origine comprise dans le pont hétérogène donné et utilisée pour la direction de traversée donnée, Dtraitement pont le délai de transfert, au sein du pont hétérogène, d'un élément du flux, depuis la mémoire FIFO vers une interface de bus numérique, ou inversement.
Selon un premier mode de réalisation avantageux de l'invention, ladite étape de détermination d'un délai isochrone d'origine est suivie de l'étape suivante : on adapte et on instancie au moins certaines des ressources dudit pont hétérogène donné, pour la direction de traversée donnée, de façon telle que le délai isochrone d'origine, dont la détermination est basée sur les ressources d'origine du pont hétérogène donné, soit modifié en un délai isochrone adapté, dont la détermination est basée sur les ressources adaptées du pont hétérogène donné, ledit délai isochrone adapté devant être sensiblement égal à un délai isochrone de référence prédéterminé (par"sensiblement égal à"on entend préférentiellement "inférieur ou égal à et le plus proche possible de").
On assure ainsi que le délai isochrone de chacun des ponts hétérogènes du réseau de l'invention, dans une direction de traversée donnée, soit sensiblement constant, quel
<Desc/Clms Page number 8>
que soit le flux considéré. Le réseau hétérogène vérifie donc, dans ce premier mode de réalisation de l'invention, les prescriptions de la norme"Standard for High Performance Serial Bus Bridges"mentionnée précédemment.
Selon une caractéristique avantageuse de ce premier mode de réalisation, ladite étape d'adaptation et d'instantiation d'au moins certaines des ressources dudit pont hétérogène donné comprend elle-même les étapes suivantes : on compare le délai isochrone d'origine, calculé préalablement, et le délai isochrone de référence prédéterminé ; si le délai isochrone d'origine est supérieur au délai isochrone de référence, on refuse l'établissement d'une connexion de flux ; si le délai isochrone d'origine est inférieur ou égal au délai isochrone de référence : * on adapte et on instancie au moins certaines des ressources dudit pont hétérogène donné, pour la direction de traversée donnée, de façon telle que le délai isochrone d'origine soit modifié en un délai isochrone adapté sensiblement égal au délai isochrone de référence ; * on accepte l'établissement d'une connexion de flux.
Par"sensiblement égal à", on entend préférentiellement "inférieur ou égal à et le plus proche possible de". Ainsi, si le délai isochrone d'origine est inférieur au délai isochrone de référence, on modifie les ressources internes du pont hétérogène de façon à accroître son délai isochrone jusqu'à une valeur proche de et inférieure ou égale au délai isochrone de référence. On joue ainsi sur les ressources du pont hétérogène pour assurer la conformité du fonctionnement interne du réseau à la nonne IEEE 1394"Standard for High Performance Serial Bus Bridges". Si en revanche, le délai isochrone d'origine est supérieur au délai isochrone de référence, on refuse d'établir une connexion de flux, par souci de respect de la nonne ci-dessus.
Préférentiellement, selon ce premier mode de réalisation, les ressources instanciées du pont hétérogène donné, pour la direction de traversée donnée, comprennent une mémoire FIFO, dite mémoire FIFO d'origine puis, après adaptation et instanciation, mémoire FIFO adaptée. Dans ce cas, on joue sur les caractéristiques des FIFOs (taille, seuil,...).
<Desc/Clms Page number 9>
On joue ainsi sur la taille de la mémoire FIFO du pont hétérogène pour accroître, si nécessaire, le délai isochrone d'origine jusqu'au délai isochrone de référence, ainsi qu'imposé par la norme IEEE 1394"Standard for High Performance Serial Bus Bridges" qui requière que le délai isochrone associé à un pont soit constant.
Selon une autre caractéristique avantageuse de ce premier mode de réalisation, ladite mémoire FIFO d'origine possédant une taille LFIFO origine telle que : LFIFO origine = + X avec une premi ère partie de la mémoire FIFO d'origine, appelée seuil d'origine, et X une seconde partie de la mémoire FIFO d'origine, permettant de contrer la gigue de réseau, ladite mémoire FIFO adaptée possède une taille 4IFO adaptée telle que : LFIFO adaptée ='+ X avec'une premi ère partie de la mémoire FIFO adaptée, telle que : '= + #, avec ladite premi ère partie de la mémoire FIFO d'origine, appelée seuil d'origine, et 8 le plus grand entier tel que : max
Figure img00090001

avec ômax L) ebltfiux X (Disochrone référence - Disochrone origine) où Débit flux est le débit du flux,
Disochrone référence est le délai isochrone de référence,
Disochrone origine est le délai isochrone d'origine et X une seconde partie de la mémoire FIFO adaptée, identique à ladite seconde partie de la mémoire FIFO d'origine, permettant de contrer la gigue de réseau.
On choisit classiquement A = X, de façon que 41FO ongine = 2.
En accroissant le seuil d'origine de la FIFO en un seuil', on augmente ainsi le temps nécessaire à un paquet de données pour traverser la FIFO du pont considéré. On accroît donc le délai isochrone associé à ce pont, le rendant ainsi sensiblement égal au délai isochrone de référence. A nouveau, par"sensiblement égal à", on entend préférentiellement "inférieur ou égal à et le plus proche possible de".
Selon un deuxième mode de réalisation avantageux de l'invention, ladite étape de calcul d'un délai isochrone d'origine est suivie de l'étape suivante : on mémorise le délai isochrone d'origine dans le pont hétérogène donné, pour la direction de traversée donnée, en association avec les caractéristiques du flux
<Desc/Clms Page number 10>
pour lequel l'établissement d'une connexion a nécessité le calcul dudit délai isochrone d'origine.
Une telle mémorisation des délais isochrones calculés, en relation avec le flux auquel ils sont associés, permet leur éventuelle réutilisation ultérieure par le pont hétérogène considéré.
Avantageusement, selon ce deuxième mode de réalisation, dans le cas d'un traitement d'un paquet CIP compris dans un flux, le pont hétérogène donné, pour la direction de traversée donnée, effectue les étapes suivantes : identification du flux dans lequel est compris le paquet CIP ; lecture, dans une mémoire, d'un délai isochrone d'origine préalablement calculé et mémorisé en association avec le flux identifié ; utilisation du délai isochrone d'origine lu pour traiter le paquet CIP.
Il n'est donc pas utile de recalculer le délai isochrone d'origine associé au flux auquel appartient le paquet CIP, ce délai ayant été mémorisé, par exemple en association avec l'identifiant du flux, et pouvant donc avantageusement être réutilisé par le pont hétérogène.
Selon une première variante avantageuse de ce deuxième mode de réalisation, dans le cas d'un traitement d'une requête de lecture du délai isochrone, le pont hétérogène donné, pour la direction de traversée donnée, effectue les étapes suivantes : le pont hétérogène donné tente de lire la requête de lecture et notamment un identifiant de flux éventuellement compris dans la requête ; si la requête de lecture contient un identifiant de flux, et si l'identifiant de flux indique un flux qui est en cours de gestion par le pont hétérogène donné, alors le pont hétérogène donné lit, dans une mémoire, un délai isochrone d'origine préalablement calculé et mémorisé en association avec le flux identifié, puis envoie une réponse contenant le délai isochrone d'origine lu.
Selon une deuxième variante avantageuse de ce deuxième mode de réalisation, dans le cas d'un traitement d'une requête de lecture du délai isochrone, le pont hétérogène donné, pour la direction de traversée donnée, effectue les étapes suivantes : le pont hétérogène donné tente de lire la requête de lecture et notamment un identifiant de flux éventuellement compris dans la requête ;
<Desc/Clms Page number 11>
si la requête de lecture contient un identifiant de flux, et si l'identifiant de flux indique un flux qui n'est pas en cours de gestion par le pont hétérogène donné, ou si la requête de lecture ne contient pas un identifiant de flux, alors le pont hétérogène donné tente d'identifier, au sein de la requête de lecture, des éléments de calcul indispensables au calcul d'un délai isochrone d'origine ; si la requête de lecture contient les éléments de calcul, le pont hétérogène donné calcule un délai isochrone d'origine, le mémorise en association avec le flux identifié, puis envoie une réponse contenant le délai isochrone d'origine calculé.
Un tel calcul du délai isochrone d'origine tient compte, notamment, du délai introduit par le passage du flux le long du chemin de routage, du délai de traversée, par le flux, d'une mémoire FIFO d'origine comprise dans le pont hétérogène donné et utilisée pour la direction de traversée donnée, et du délai de transfert, au sein du pont hétérogène, d'un élément du flux, depuis la mémoire FIFO vers une interface de bus numérique, ou inversement, ainsi que décrit précédemment dans ce document.
Selon une troisième variante avantageuse de ce deuxième mode de réalisation, dans le cas d'un traitement d'une requête de lecture du délai isochrone, le pont hétérogène donné, pour la direction de traversée donnée, effectue les étapes suivantes : le pont hétérogène donné tente de lire la requête de lecture et notamment un identifiant de flux éventuellement compris dans la requête ; si la requête de lecture contient un identifiant de flux, et si l'identifiant de flux indique un flux qui n'est pas en cours de gestion par le pont hétérogène donné, ou si la requête de lecture ne contient pas un identifiant de flux, alors le pont hétérogène donné tente d'identifier, au sein de la requête de lecture, des éléments de calcul indispensables au calcul d'un délai isochrone d'origine ; si la requête de lecture ne contient pas les éléments de calcul, le pont hétérogène donné choisit un délai isochrone d'origine possédant une valeur prédéterminée, le mémorise en association avec le flux identifié, puis envoie une réponse contenant le délai isochrone d'origine choisi.
<Desc/Clms Page number 12>
Un tel délai isochrone d'origine peut alors résulter d'un choix arbitraire, ou être fixé a priori par le constructeur du pont.
Selon une quatrième variante avantageuse de ce deuxième mode de réalisation, dans le cas d'un traitement d'une requête de lecture du délai isochrone, le pont hétérogène donné, pour la direction de traversée donnée, effectue les étapes suivantes : le pont hétérogène donné tente de lire la requête de lecture et notamment un identifiant de flux éventuellement compris dans la requête ; si la requête de lecture contient un identifiant de flux, et si l'identifiant de flux indique un flux qui n'est pas en cours de gestion par le pont hétérogène donné, ou si la requête de lecture ne contient pas un identifiant de flux, alors le pont hétérogène donné tente d'identifier, au sein de la requête de lecture, des éléments de calcul indispensables au calcul d'un délai isochrone d'origine ; si la requête de lecture ne contient pas les éléments de calcul, le pont hétérogène donné envoie une réponse contenant un identifiant d'erreur.
Selon une première caractéristique avantageuse de ce deuxième mode de réalisation, dans le cas d'un traitement d'une requête d'établissement d'une connexion de flux, le pont hétérogène donné, pour la direction de traversée donnée, effectue les étapes suivantes : le pont hétérogène donné tente de lire la requête d'établissement d'une connexion de flux, et notamment un identifiant de flux éventuellement compris dans la requête ; si la requête d'établissement d'une connexion de flux contient un identifiant de flux, si l'identifiant de flux indique un flux pour lequel le pont hétérogène donné a préalablement généré une réponse à une requête de lecture du délai isochrone, et si le délai isochrone d'origine contenu dans la réponse préalablement générée peut être lu, alors le pont hétérogène donné lit le délai isochrone d'origine préalablement calculé et mémorisé en association avec le flux identifié, puis autorise l'établissement d'une connexion avec le délai isochrone d'origine lu.
<Desc/Clms Page number 13>
Selon une deuxième caractéristique avantageuse de ce deuxième mode de réalisation, dans le cas d'un traitement d'une requête d'établissement d'une connexion de flux, le pont hétérogène donné, pour la direction de traversée donnée, effectue les étapes suivantes : le pont hétérogène donné tente de lire la requête d'établissement d'une connexion de flux, et notamment un identifiant de flux éventuellement compris dans la requête ; si la requête d'établissement d'une connexion de flux contient un identifiant de flux, si l'identifiant de flux indique un flux pour lequel le pont hétérogène donné a préalablement généré une réponse à une requête de lecture du déhi isochrone, et si le délai isochrone d'origine contenu dans la réponse préalablement générée ne peut pas être lu, alors le pont hétérogène donné calcule un délai isochrone d'origine, le mémorise en association avec le flux identifié, puis autorise l'établissement d'une connexion avec le délai isochrone d'origine calculé.
Selon une troisième caractéristique avantageuse de ce deuxième mode de réalisation, dans le cas d'un traitement d'une requête d'établissement d'une connexion de flux, le pont hétérogène donné, pour la direction de traversée donnée, effectue les étapes suivantes : le pont hétérogène donné tente de lire la requête d'établissement d'une connexion de flux, et notamment un identifiant de flux éventuellement compris dans la requête ; si la requête d'établissement d'une connexion de flux contient un identifiant de flux, si l'identifiant de flux indique un flux pour lequel le pont hétérogène donné a préalablement généré une réponse à une requête de lecture du délai isochrone, et si le délai isochrone d'origine contenu dans la réponse préalablement générée ne peut pas être lu, alors le pont hétérogène donné refuse l'établissement d'une connexion.
Selon une quatrième caractéristique avantageuse de ce deuxième mode de réalisation, dans le cas d'un traitement d'une requête d'établissement d'une connexion de
<Desc/Clms Page number 14>
flux, le pont hétérogène donné, pour la direction de traversée donnée, effectue les étapes suivantes : le pont hétérogène donné tente de lire la requête d'établissement d'une connexion de flux, et notamment un identifiant de flux éventuellement compris dans la requête ; si la requête d'établissement d'une connexion de flux contient un identifiant de flux, si l'identifiant de flux indique un flux pour lequel le pont hétérogène donné n'a pas préalablement calculé un délai isochrone d'origine, alors le pont hétérogène donné calcule un délai isochrone d'origine, le mémorise en association avec le flux identifié, puis autorise l'établissement d'une connexion avec le délai isochrone d'origine calculé.
L'invention concerne également un pont hétérogène, du type compris dans un réseau hétérogène du type comprenant une pluralité de bus numériques, interconnectés entre eux : soit directement, via des ponts homogènes comprenant chacun une première et une seconde portes à chacune desquelles est connecté un des bus numériques ; soit à travers au moins un réseau commuté, via des ponts hétérogènes comprenant chacun une première porte, à laquelle est connecté un des bus numériques, et une seconde porte, à laquelle est connecté le réseau commuté, le réseau commuté comprenant une pluralité de noeuds reliés entre eux par une pluralité de liens, chaque pont hétérogène formant un des noeuds du réseau commuté ; chaque pont étant associé à un délai isochrone pour chaque direction de traversée de l'une vers l'autre de ses portes.
Selon l'invention, ledit pont hétérogène comprend des moyens de détermination d'un délai isochrone d'origine, de façon que, lorsque ledit pont hétérogène reçoit une requête d'établissement d'une connexion de flux impliquant la traversée dudit pont hétérogène dans une direction de traversée donnée, lesdits moyens de détermination permettent de déterminer un délai isochrone d'origine, associé à la direction de traversée donnée du pont hétérogène donné, en prenant en compte, dans une proportion propre au
<Desc/Clms Page number 15>
pont hétérogène donné, un délai introduit par le passage du flux le long d'un chemin de routage à travers le réseau commuté.
L'invention concerne aussi un programme d'ordinateur, comprenant des séquences d'instructions adaptées à la mise en oeuvre d'un procédé tel que décrit précédemment lorsque ledit programme est exécuté sur un ordinateur.
L'invention concerne encore un produit programme d'ordinateur de gestion des délais isochrones associés à des ponts hétérogènes dans un réseau hétérogène du type comprenant une pluralité de bus numériques, interconnectés entre eux : soit directement, via des ponts homogènes comprenant chacun une première et une seconde portes à chacune desquelles est connecté un des bus numériques ; soit à travers au moins un réseau commuté, via des ponts hétérogènes comprenant chacun une première porte, à laquelle est connecté un des bus numériques, et une seconde porte, à laquelle est connecté le réseau commuté, le réseau commuté comprenant une pluralité de noeuds reliés entre eux par une pluralité de liens, chaque pont hétérogène formant un des noeuds du réseau commuté ; chaque pont étant associé à un délai isochrone pour chaque direction de traversée de l'une vers l'autre de ses portes, ledit produit programme d'ordinateur comprenant des instructions de code de programme enregistré sur un support utilisable dans un ordinateur comprenant : des moyens de programmation lisibles par ordinateur pour effectuer, lorsque l'on souhaite établir une connexion de flux impliquant la traversée d'un pont hétérogène donné dans une direction de traversée donnée, une étape de détermination d'un délai isochrone d'origine, associé à la direction de traversée donnée du pont hétérogène donné, en prenant en compte, dans une proportion propre au pont hétérogène donné, un délai introduit par le passage du flux le long d'un chemin de routage à travers le réseau commuté.
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 présente un synoptique d'un réseau hétérogène selon l'invention ;
<Desc/Clms Page number 16>
la figure 2 illustre un exemple de réalisation d'un pont hétérogène du réseau de la figure 1 ; la figure 3 décrit la structure d'une table de routage mise en oeuvre dans le réseau de la figure 1 ; la figure 4 illustre la taille des mémoires FIFO d'origine d'un pont hétérogène "talker"d'une part, et d'un pont hétérogène"listener"d'autre part, tenant compte d'une estimation de la gigue du réseau, dans un premier mode de réalisation de l'invention ; la figure 5 présente l'algorithme mis en oeuvre dans un premier mode de réalisation de l'invention au cours d'une étape d'instantiation des mémoires
FIFO ; la figure 6 illustre la taille des mémoires FIFO adaptées d'un pont hétérogène "talker"d'une part, et d'un pont hétérogène "listener" d'autre part, après adaptation du délai isochrone à un délai isochrone de référence, dans un premier mode de réalisation de l'invention ; la figure 7 présente, dans un deuxième mode de réalisation de l'invention, un algorithme mis en oeuvre par un pont hétéogène, sur réception d'une requête de lecture de la valeur de délai isochrone de la porte du pont considérée ; les figures 8a et 8b illustrent deux algorithmes pouvant être mis en oeuvre par un pont hétérogène sur réception d'une requête d'établissement de connexion de flux, pour lequel le pont considéré a préalablement généré une réponse à une requête de lecture, dans ce deuxième mode de réalisation de l'invention ; la figure 9 décrit l'algorithme appliqué par un pont hétérogène, selon le deuxième mode de réalisation de l'invention, en cas d'établissement d'une connexion de flux pour lequel le pont hétérogène considéré n'a pas préalablement calculé de délai isochrone d'origine.
Le principe général de l'invention repose sur le calcul d'un délai isochrone d'origine, associé à la direction de traversée d'un pont hétérogène, dans le cadre d'une connexion de flux au sein d'un réseau de bus numériques hétérogène, tenant compte, au moins partiellement, du temps de transfert du flux le long de son chemin de routage au travers d'un réseau commuté.
<Desc/Clms Page number 17>
On présente, en relation avec la figure 1, un premier mode de réalisation d'un réseau hétérogène selon l'invention.
Un tel réseau hétérogène est constitué d'une pluralité de bus de type IEEE 1394 référencés 110,120, 130,140, 150 et 250 interconnectés les uns aux autres et/ou à un réseau commuté 100. Un tel réseau commuté 100 est par exemple un réseau audiovisuel domestique, permettant l'échange en temps réel de fichiers audio et/ou d'images animées.
L'interconnexion du réseau commuté 100 et des bus IEEE 1394 est réalisée par l'intermédiaire de ponts hétérogènes, constitués chacun de deux portes appairées, référencés 201/202,203/204, 205/206,207/208 et 209/211. (Un pont hétérogène constitué de portes référencées X et Y est ainsi référencé X/Y). Chacun de ces ponts hétérogènes présente donc une première porte connectée au réseau commuté 100 et une seconde porte connectée à un bus numérique de type IEEE 1394. Chaque pont hétérogène de la figure 1 est conforme au standard"Standard for High Performance Serial Bus Bridges"mentionné précédemment.
Ainsi, le réseau commuté 100 est vu comme un bus série par tous les noeuds du réseau hétérogène référencés 101, 102,103, 104,105, 106,107, 108,109, 111, 112,113, 114,216/217, 119,121, 115,116, 117 et 118 qui n'appartiennent pas à ce réseau commuté 100.
Le pont référencé 216/217 est un pont homogène du réseau de la figure 1, interconnectant deux bus de type IEEE 1394. Ce pont référencé 216/217 est également conforme au standard"Standard for High Performance Serial Bus Bridges".
Tous les ponts de la figure 1 jouent un rôle de réservation de ressources au cours de l'établissement d'une connexion de flux, comme décrit plus en détails dans le standard "Standard for High Performance Serial Bus Bridges". Ces ponts, sur le chemin de routage allant d'un terminal d'entrée isochrone ou"talker"vers au moins un terminal destinataire ou"listener", interprètent et échangent des messages inter-ponts (par exemple des messages de type"JOIN","LISTEN","LEAVE"et"STREAM STATUS"), ainsi que prévu par la norme IEEE 1394. De tels messages fournissent des informations sur le"talker", le"listener", la bande passante nécessaire au transport de données isochrone, et le statut de l'établissement d'une connexion de flux.
<Desc/Clms Page number 18>
Le réseau commuté 100 est constitué de liens référencés 160,170, 180,190, 200, 210,220, 230 et 240 qui interconnectent, d'une part des noeuds référencés 201/202, 203/204,205/206, 207/208 et 209/211, encore appelés ponts hétérogènes, interconnectant le réseau commuté 100 avec des bus IEEE 1394, et d'autre part des noeuds référencés 212/213 et 214/215, internes au réseau commuté 100.
Le routage de paquets au travers du réseau commuté 100 est réalisé en mettant en oeuvre une métbde de routage par la source (en anglais"source routing"), selon laquelle l'information de routage d'un paquet est calculée par une unité centrale, ou CPU référencée 391 sur la figure 2, qui connaît la topologie du réseau commuté 100. Cet aspect ne sera pas décrit plus en détails dans le cadre de la présente invention.
La figure 2 illustre la structure d'un pont hétérogène référencé 201/202,203/204, 205/206,207/208, 209/211,2121/213 ou 214/215 sur la figure 1.
Un tel pont comprend deux interfaces de communication : une première interface 350 avec le bus IEEE 1394, et une seconde interface 310 avec le réseau commuté. Cette dernière comprend par exemple un composant de type CI 13 fabriqué par 4Links Ltd
Figure img00180001

(marque déposée), si le réseau commuté repose sur la norme"IEEE 1355-1995 : Standard for Heterogeneous Interconnect (HIC)".
Le commutateur 320 permet de transférer des données d'un premier vers un second port de l'interface du réseau commuté, de recevoir des données d'un port de l'interface du réseau commuté vers la DPRAM 330, et de transmettre des données de la DPRAM 330 vers au moins un port de l'interface du réseau commuté (dans cet ordre décroissant de priorité). Le fonctionnement d'un tel commutateur 320 est notamment décrit dans la demande de brevet français n 01 02037 par le même déposant, non encore publiée à la date de dépôt de la présente demande. Un tel fonctionnement ne faisant pas l'objet de la présente invention, il ne sera pas décrit plus en détails dans ce document.
La DPRAM 330 est agencée en un ensemble de FIFOs, qui permettent le transfert de données de l'interface IEEE 1394 350 vers l'interface du réseau commuté 310, et vice-versa. La gestion de la DPRAM 330 est assurée par le module de contrôle 360, au moyen des signaux de contrôle ctrl2.
Le module SAR 340 est utilisé pour la segmentation et le ré-assemblage (en anglais"Segmentation And Reassembly") des données en provenance et à destination de
<Desc/Clms Page number 19>
l'interface de réseau 310. Ainsi, les paquets isochrones de type IEEE 1394 peuvent être segmentés en vue de leur transmission sur le réseau commuté 100. Le transfert de paquets asynchrones ne fait pas partie de la présente invention, et en sera donc pas décrit plus en détails.
En outre, le SAR 340 joue le rôle de planificateur pour la transmission de données sur le réseau, afin de respecter les contraintes de temps imposées par les transferts isochrones.
La configuration de tous les modules est effectuée par l'unité centrale ou CPU 391, via l'interface de bus 370. Les échanges de données et de contrôle entre le module Contrôle/Pont 360 et la CPU 391 sont effectués via l'interface de données 304 et les signaux ctrll, l'interface de bus 370 et le bus hôte 380.
Le module de pont 360 comprend une première table de contrôle de flux (aussi appelée table de routage de flux), ainsi que spécifié dans"Standard for High Performance Serial Bus Bridges", pour les communications sur l'interface IEEE 1394 350. Le module de pont 360 maintien également, en correspondance avec cette première table, une deuxième table de contrôle de flux, pour les communications avec le réseau commuté.
Lorsque le noeud local est un"talker"intermédiaire pour le flux considéré, la deuxième table de contrôle de flux contient les informations suivantes : des informations sur le routage permettant d'atteindre le prochain pont sur la route du "listener" ; des informations sur l'ordonnancement mis en oeuvre pour le transport des données sur le réseau commuté ; des informations permettant d'identifier de manière unique la connexion de flux qui est en cours d'établissement entre le noeud local considéré et le prochain pont sur la route du"listener".
Lorsque le noeud local est un"listener"intermédiaire pour le flux considéré, la deuxième table de contrôle de flux contient des informations permettant d'identifier de manière unique la connexion de flux qui est en cours d'établissement entre le noeud local lui-même et le prochain pont sur la route du "ta1ker".
<Desc/Clms Page number 20>
De plus, le module de pont 360 est en charge de la modification des champs des paquets IEEE 1394 en vue de leur transmission sur l'interface IEEE 1394 (350), et notamment des champs relatifs : au débit ; au canal emprunté par les paquets ; aux informations temporelles (CIP Packets) ; - à des indications destinées à l'interfaoe IEEE 1394 (350) relatives à la vitesse de transmission.
On présente désormais, en relation avec la figure 3, une table de routage pour le réseau commuté 100, contenue dans la RAM 392 de la porte 207 du pont 207/208. Des tables similaires sont bien sûr également mémorisées dans les mémoires RAM des autres portes des ponts hétérogènes du réseau de l'invention, mais, par souci de simplification, on s'attachera dans la suite du document à décrire plus particulièrement la table de routage de la porte référencée 207. Une telle table permet d'illustrer la détermination du chemin de routage nécessaire à l'établissement d'une connexion de flux. Les champs qui sont renseignés dans la table de la figure 3 constituent un exemple numérique qui sera repris dans la suite du document.
Lorsque la porte d'un pont reçoit un message inter-pont contenant une requête d'établissement d'une connexion de flux, elle doit vérifier que l'identifiant de bus (virtuel) du terminal d'entrée ou du"talker" (si la porte du pont considérée constitue un "listener"sur le chemin de routage) ou l'identifiant de bus du terminal destinataire ou "listener" (si la porte du pont considérée constitue un"talker"sur le chemin de routage) est encore valide. Dans le cas contraire, la connexion de flux ne peut pas être établie.
Une telle information est contenue dans le plan de routage (en anglais"routing map") défini dans la nonne "IEEE P1394. 1 draft 0.17 Standard for High Performance Serial Bus Bridges". La gestion de ce plan de routage ne fait pas l'objet de la présente invention, et ne sera donc pas décrite dans la présente demande. Pour plus de détails, on pourra se reporter à la norme mentionnée ci-dessus.
La table présentée en figure 3 établit une correspondance entre un identifiant de bus (représenté par une valeur comprise entre 0 et Ox3E), le noeud du réseau commuté transmetteur de données, le chemin de routage au travers du réseau commuté 100 pour
<Desc/Clms Page number 21>
atteindre ce noeud et la bande passante disponible sur ce chemin de routage au travers du réseau commuté.
La méthode de routage au travers du réseau commuté 100 est par exemple une méthode de routage par la source (en anglais"source routing"). La méthode de routage mise en oeuvre au sein du réseau commuté ne fait pas l'objet de la présente invention, et on pourra se référer à la demande de brevet français n 01 02037 mentionnée précédemment pour une description plus détaillée du traitement des en-têtes de routage.
Plusieurs chemins de routage différents peuvent exister entre deux noeuds du réseau commuté 100. Pour choisir un chemin de routage préféré, on peut envisager de prendre en compte certains critères de sélection, comme par exemple la direction du flux au sein du réseau commuté 100 : ainsi, par exemple, on peut choisir deux chemins de routage différents pour atteindre un noeud du réseau, selon que ce noeud est un"talker" ou un"listener".
L'information de bande passante pour un chemin de routage donné au travers du réseau commuté 100, qui est contenue dans la table de la figure 3, permet au noeud qu est en charge du traitement d'une requête d'établissement de connexion de flux, de décider si les ressources courantes du réseau permettent ou non l'établissement de la connexion de flux requise.
L'allocation de bande passante peut, par exemple, être contrôlée par un noeud "leader"du réseau commuté 100, mettant en oeuvre une procédure appelée en anglais "lock compare and swap" (transaction de verrouillage, comparaison et échange") : le noeud souhaitant allouer de la bande passante envoie un message au noeudeader du réseau commuté 100 spécifiant la valeur précédente de la bande passante, et la nouvelle valeur, tenant compte de la réservation de bande passante à effectuer.
Cette procédure garantit que des requêtes d'allocation de bande passante concourantes ne soient pas nuisibles à la table de description de la bande passante du réseau. Le noeud leader n'acceptera la requête d'allocation de bande passante que si la valeur précédente de bande passante spécifiée dans le message reçu correspond à la valeur contenue dans la table de description du noeud leader. Le noeud leader peut ensuite initier un message de réponse destiné à l'émetteur de la requête indiquant le
<Desc/Clms Page number 22>
succès de la transaction et/ou, il peut utiliser un message de diffusion informant tous les noeuds duréseau commuté 100 de la nouvelle bande passante disponible.
Ainsi, la valeur figurant dans les tables distribuées de la figure 3 peut, à un instant donné, ne pas être exactement identique à la valeur contenue dans la table de description du noeud leader. Dans ce cas, le noeud émetteur d'une requête de bande passante utilisera une"vieille valeur", inappropriée, dans le message d'allocation de bande passante, et la requête sera donc rejetée par le noeud leader.
Pour que sa requête soit acceptée, le noeud reqérant une allocation de bande passante doit donc obtenir la nouvelle valeur de bande passante contenue dans la table de description du noeud leader pour ce faire, il peut émettre une requête de lecture de la table de description du noeud leader, ou attende de recevoir un message de diffusion du noeud leader informant tous les noeuds de la nouvelle bande passante disponible sur le réseau commuté 100.
Le choix d'un noeud leader, et son mode de fonctionnement ne font pas l'objet de la présente invention, et en seront donc pas décrits plus en détails dans la présente demande.
Comme indiqué précédemment, l'information de bande passante contenue dans la table de la figure 3, permet à un noeud traitant une requête de connexion de flux de décider si les ressources courantes du réseau permettent ou non l'établissement d'une telle connexion.
Par exemple, selon l'exemple numérique qui sera traité dans la suite du document, lorsque la porte 207 du pont 207/208 essaye d'établir une connexion pour un terminal destinataire connecté au bus 110, elle consulte la table illustrée en figure 3. A l'aide de l'identifiant du bus 110, elle détermine qu'il faut atteindre la porte 202 du pont 201/202, en empruntant un chemin de routage passant par les noeuds 213 et 214 du réseau commuté. Cette information de routage renseigne sur le nombre de noeuds intermédiaires à traverser (2 dans l'exemple décrit) au sein du réseau commuté 100 pour atteindre le pont hétérogène référencé 201/202. Cette information est particulièrement importante pour les calculs qui seront développés dans la suite du document.
Sur le réseau commuté 100, le chemin de routage d'un paquet transitant d'un premier vers un second noeud peut être plus ou moins congestionné, selon les flux de
<Desc/Clms Page number 23>
données qui traversent chaque commutateur 320 de la figure 2. Sur la figure 2, la DPRAM 330 joue le rôle de tampon pour les données, afin de contrer la gigue du réseau, et de garantir que : - il y a toujours assez d'espace libre pour écrire des données dans la FIFO de transmission (Tx FIFO), en mettant en oeuvre une opération d'écriture de flux ; il y a toujours assez de données qui doivent être transmises par ordonnancement dans la FIFO de transmission (Tx FIFO) ; il y a toujours assez d'espace libre dans la FIFO de réception (Rx FIFO) pour le ré-assemblage de données reçues du réseau ; il y a toujours assez de données qui doivent être lues par la FIFO de réception (Rx FIFO), par une opération de lecture de flux.
Ainsi, l'instantiation de la FIFO doit prendre en compte une estimation de la gigue du réseau commuté 100, afin de garantir les conditions listées ci-dessus.
Le réseau commuté 100 est cadencé au moyen d'une horloge à 49, 152MHz. La synchronisation de l'ensemble des noeuds du réseau commuté 100 sur cette horloge ne fait pas l'objet de la présente invention, et ne sera donc pas décrite plus en détails dans ce document. Un intervalle de temps (en anglais"time slot") sur le réseau commuté a une durée de 125 j. 1s, comme pour un bus série de type IEEE 1394. Le transfert d'un paquet sur le réseau est établi en fonction de connexions déjà existantes au sein du réseau. Ainsi, dans le pire des cas, un paquet peut être reçu par le noeud destinataire au début d'un cycle de 125 j. 1s, si aucun des commutateurs intermédiaires du chemin de routage n'était sujet à congestion, alors que le paquet suivant ne sera reçu qu'à la fin du cycle de 125 j. 1s suivant, en raison d"embouteillages"dans certains commutateurs intermédiaires. Par conséquent, la valeur maximale de la gigue du réseau est de 250 j. 1s.
Une estimation plus précise peut être réalisée en analysant le comportement du réseau commuté 100 en présence de flux de données concourant (par simulation, par modélisation du réseau, par test de performance de prototypes), mais une estimation grossière de la gigue à 250 gus est suffisante pour illustrer la présente invention.
Pour une application nécessitant un débit de données de 30 Mbps (par exemple un format vidéo DV), l'estimation de la taille de la FIFO nécessaire pour contrebalancer la gigue du réseau commuté 100 est la suivante :
<Desc/Clms Page number 24>
Figure img00240001

LFIFO adaptée = A+X = 2*A = 2* débit* gigue = 2*30. 106*250. 10-6 = 1875 bytes 470 Quadlets
Comme décrit par la suite en relation avec la figure 4, A représente une première partie de la mémoire FIFO d'origine, appelée seuil d'origine, et X représente une seconde partie de la mémoire FIFO d'origine, permettant de contrer la gigue du réseau.
Dans un mode de réalisation préféré de l'invention, on choisit X == A.
La figure 4 illustre la taille des FIFOs de deux noeuds hétérogènes jouant respectivement le rôle d'émetteur ("talker") et de récepteur ("listener") d'un flux de données, après estimation de la gigue du réseau commuté. Ces FIFOs sont instanciées dans la DPRAM 330 et gérées par le module Contrôle/Pont 360 de la figure 2. Les données sont placées dans la FIFO 401 par le module de pont 360, en vue d'un transfert sur le réseau commuté 100, en mettant en oeuvre une opération d'écriture 400. Ces données doivent être segmentées et ordonnancées par le module SAR 340, au cours d'une opération de segmentation et d'ordonnancement 405.
Le chemin de routage de bout en bout 406 peut traverser un ou plusieurs noeuds intermédiaires du réseau commuté 100. La gigue du réseau introduit des variations du délai nécessaire à la transmission de paquets de bout en bout, et les FIFOs 401 et 402 de la figure 4 ont pour rôle de contrer cette gigue. La taille L et le seuil A des FIFOs sont déterminés par l'unité centrale 391, après estimation de la gigue du réseau, ainsi que décrit précédemment.
On présente désormais, en relation avec les figures 5 et 6, un premier mode de réalisation de l'invention, dans lequel on modifie les ressources des ponts hétérogènes du réseau, de façon que le délai introduit lors du transfert d'un paquet au travers du pont soit constant, et sensiblement égal ("inférieur ou égal à et le plus proche possible de") à un délai de référence, ainsi qu'imposé par la norme IEEE 1394 définie dans"Standard for High Performance Sériai Bus Bridges".
La figure 5 présente un algorithme mis en oeuvre par un pont hétérogène du réseau commuté 100, sur réception d'une requête d'établissement de connexion de flux.
Cet algorithme est stocké dans la ROM du pont hétérogène. Il est chargé dans la RAM lors de la mise sous tension et l'unité centrale (CPU) 391 va exécuter les instructions correspondantes.
<Desc/Clms Page number 25>
Au cours d'une étape référencée SO, l'un des ponts hétérogènes référencés 201/202,203/204, 205/206,207/208 ou 209/211 reçoit et interprète une requête d'établissement de connexion de flux.
Au cours d'une étape référencée SI, on calcule la taille de la mémoire FIFO d'origine (à savoir la taille de la mémoire Tx FIFO pour un pont hétérogène jouant le rôle de"talker", et la taille de la mémoire Rx FIFO pour un pont hétérogène jouant le rôle de"listener"), selon la méthode décrite précédemment.
Au cours d'une étape référencée S2, on calcule ensuite le délai introduit par le passage du flux le long du chemin de routage : Dréseau commuté = Nnoeudsintermédiaires x Dcommutation, Où Nnceudsintermédiaires est le nombre de noeuds intermédiaires le long du chemin de routage, Et où Dcommutation est le délai de commutation moyen par noeud.
Si l'on considère que le pont hétérogène"talker"et le pont hétérogène"listener" doivent chacun tenir compte du délai réseau commuté dans une proportion de 50 %, on a alors, pour l'un de ces deux ponts :
Dréseau commuté ! pont = Dréseau commuté/2
Au cours d'une étape référencée S3, on calcule le délai isochrone d'origine, dû à la configuration du réseau :
Figure img00250001

Disochrone origine = Dréseau commuté/pont'Dtraverése FIFO origine + Dtraitement pont Avec Draverése FIFO origine =A/Débitflux, où A représente une première partie de la FIFO, appelée seuil d'origine de la FIFO.
Dans le cas d'un pont hétérogène "listener", le délai traitement pont correspond à la somme du délai subi par les paquets isochrones lorsqu'ils sont transférés de la Rx FIFO du noeud hétérogène "listener" vers l'interface IEEE 1394 350 de ce même pont et du temps de traitement réalisé par le module de pont 360. Dans le cas d'un pont hétérogène "talker", le délai Dtraitement pont correspond à la somme du retard subi par les paquets isochrones lorsqu'il sont transférés de l'interface IEEE 1394 350 vers la Tx FIFO du pont hétérogène"talker", et du temps de traitement effectué par le module de pont 360 de ce pont hétérogène.
<Desc/Clms Page number 26>
Au cours d'une étape référencée S4, on compare le délai isochrone d'origine D1sochrone origme au délai isochrone de référence prédéterminé, indiqué dans la ROM de configuration, appelée CONFIG ROM, de la porte du pont hétérogène considéré, comme spécifié dans la norme"Standard for High Performance Serial Bus Bridges". Si le délai isochrone d'origine est supérieur au délai isochrone de référence, l'établissement de la connexion de flux est refusé (S5).
En revanche, si le délai isochrone d'origine est inférieur ou égal au délai isochrone de référence, on détermine le nouveau seuil A'de la FIFO au cours d'une étape référencée S6 : S=+Ö, où A est le seuil d'origine de la FIFO, et où â est le plus grand entier tel que 8 < 8max, avec : Ömax = Débitflux x (Disochrone référence - Disochrone origine)
Au cours d'une étape référencée S7, on détermine alors la taille 4IFO adaptée de la mémoire FIFO :
LFIFO adaptée = A'+ X
Or, la taille LFIFO origine de la mémoire FIFO d'origine est donnée par :
LFIFO origine = à + X, avec, classiquement, A = X.
Donc, LFIFO adaptée = A'+ LFIFO origine/2.
Au cours d'une étape référencée S8, la FIFO est instantiée. L'unité centrale 391 donne au module Pont/Contrôle 360 les paramètres relatifs au flux considéré, qui ont été listés et calculés précédemment.
Au cours d'une étape référencée S9, la requête d'établissement de connexion de flux est acceptée par la porte du pont concernée, et la procédure d'établissement de connexion de flux peut continuer, comme spécifié dans la nonne "Standard for High Performance Serial Bus Bridges".
La figure 6 illustre la taille des FIFOS, Rx FIFO et Tx FIFO, des ponts hétérogènes"talker"et"listener", après adaptation de la valeur du délai isochrone du pont, dans une direction de traversée donnée, au délai isochrone de référence, pour une connexion de flux donnée, selon un chemin de routage déterminé au sein du réseau commuté 100.
<Desc/Clms Page number 27>
On considère une connexion de flux du terminal référencé 114 au terminal référencé 102 de la figure 1, pour une application à 30Mbps. On considère le chemin de routage allant de la porte 207 du pont hétérogène 207/208 à la porte 202 du pont 201/202, selon un chemin de routage passant par les portes 213 et 214 des ponts hétérogènes 212/213 et 214/215.
Si l'on applique l'algorithme de la figure 5 à la porte 207, qui traite la connexion de flux décrite ci-dessus, le calcul de la taille de la FIFO d'origine nécessaire pour contrer la gigue du réseau commuté 100, réalisé au cours de l'étape référencée SI, donne LFIFO origine = 470 Quadlets, ainsi que calculé précédemment.
Le temps de latence moyen d'un commutateur peut être évalué grâce aux modèles de réseau et de commutateur, par simulation, et/ou en effectuant des tests de performance de prototypes. Par exemple, une telle valeur peut être égale à 30 ils. Le chemin de routage allant du pont hétérogène 207/208 au pont hétérogène 201/202 passe par deux noeuds intermédiaires, ainsi que décrit précédemment, donc le temps de latence dû au réseau commuté 100 est égal à 60 ils.
Ce délai est partagé entre le pont hétérogène 207/208 et le pont hétérogène 201/202. En considérant que ces deux ponts prennent en compte une proportion identique du temps de latence du réseau (à savoir 50%), on peut donc considérer que le temps de latence du réseau qui doit être pris en compte par la porte 207 est égal à 30 ils.
La porte 207 du pont 207/208 calcule cette valeur pour la porte 208, qui constitue une porte"listener"sur le chemin de routage liant le terminal référencé 114 au terminal référencé 102.
On notera que la nonne "IEEE P1394. 1 Draft 0.17 Standard for High Performance Serial Bus Bridges"précise que l'ajout de délai isochrone dans le champ isochronous delay du message LISTEN doit être effectué par les portes"listener"sur le chemin de routage allant du terminal"talker"114 au terminal"listener"102.
Le délai isochrone d'origine, pour la connexion de flux décrite ci-dessus, et en considérant un délai de transfert, au sein du pont hétérogène, Dtraitement pont, égal à 125 ils par exemple (tenant compte du temps de récupération des données dans la DPRAM, du temps de modification des en-têtes de paquets, du temps de transfert vers l'interface de
<Desc/Clms Page number 28>
bus, et du temps de synchronisation avec l'horloge de bus locale IEEE 1394), est inc égal à : D, isochrone origine = 30 ils + (470 Quadlets/2)/30 Mbps + 125 ils = 406 ils, ce qui correspond approximativement à 3,25 cycles de 125 ils.
Si le délai isochrone de référence fixé dans la ROM de configuration de la porte 208 du pont 207/208 est égal à 5, la comparaison de l'étape référencée S4 de la figure 5 conduit à une réponse négative, et on peut donc calculer le nouveau seuil A'de la FIFO de la manière suivante :
A'= ( (5* 125 ils) - 30 Ils-125 ils) * 30Mbps 440 Quadlets.
Le délai isochrone de référence spécifié dans la ROM de configuration de la porte du pont hétérogène est fixé par le constructeur, et peut être déterminé en réalisant une simulation, à partir de modèles, ou en effectuant des tests de performance de prototypes du constructeur.
Ainsi, la nouvelle taille de FIFO, appelée LFIFO adaptée, de la porte 207 du pont 207/208 est égale à :
Figure img00280001

LFIFO adaptée = A'+ X, et, dans le cas où 4IFO origine = A + X = 2A, on a :
LFIFO adaptée = #1 + LFIFO origine/2 = 440 + 235 = 675 Quadlets
La même procédure peut être mise en oeuvre pour la porte 202 du pont hétérogène 201/202, qui est la porte de pont "listener" suivante sur le chemin de routage du terminal"talker"114 au terminal"listener"102, lorsque la porte 207 transfère un message LISTEN pour l'établissement d'une connexion de flux. La porte 202 du pont hétérogène 201/202 va donc intégrer, dans le calcul de sa taille de mémoire FIFO adaptée, la partie du délai isochrone subi par les paquets lors de leur transfert au sein du réseau commuté 100 qui n'a pas été prise en compte par la porte 207 du pont hétérogène 207/208 lors de son propre calcul de taille de FIFO adaptée.
Ainsi, comme indiqué sur la figure 6, on a, pour la porte 202 :
LFIFO adaptée = A"+ X, où X est la seconde partie de la mémoire FIFO d'origine de la porte 202.
On notera que A"et A'peuvent être de valeurs égales ou non : en effet, le délai de transfert, au sein du pont hétérogène, traitement pont peut varier en fonction de la direction de traversée du pont.
<Desc/Clms Page number 29>
On présente désormais, en relation avec les figures 7 à 9, un deuxième mode de réalisation de l'invention, qui, contrairement au premier mode de réalisation décrit cidessus, n'est pas conforme à la norme"Standard fbr High-Speed Sériai Bus Bridges", mais présente l'avantage d'être moins consommateur en termes de mémoire.
La différence principale entre ce deuxième mode de réalisation de l'invention et le premier mode de réalisation décrit précédemment est que l'objectif de ce deuxième mode de réalisation n'est pas d'appliquer un délai isochrone constant pour tout flux traversant un pont. Au contraire, le délai isochrone subi par des paquets isochrones traversant un pont hétérogène est désormais dépendant du flux auquel ils appartiennent, une telle dépendance étant principalement liée au chemin de routage qu'ils empruntent au sein du réseau commuté 100 (à savoir au nombre de noeuds intermdiaires situés le long de ce chemin de routage), ainsi qu'à la gigue du réseau (dans le cas d'un calcul affiné et non le choix d'une valeur arbitraire pour le délai isochrone) et au débit du flux.
Les situations nécessitant la connaissance de la valeur de délai isochrone associée à un flux donné, pour une direction de traversée donnée d'un pont, sont les suivantes : un établissement de connexion de flux (notamment dans un message LISTEN tel que décrit précédemment) ; un traitement de paquet CIP (tel que décrit en introduction de ce document) ; une requête de lecture de la ROM de configuration de bus contenant le champ de délai isochrone, ainsi que décrit dans la norme "Standard for High Performance serial Bus Bridges".
On considère tout d'abord le cas d'un traitement de paquet CIP, décrit dans la norme "Standard for High Performance serial Bus Bridges". Comme dans le cadre d'une procédure d'établissement de connexion de flux, on applique un délai isochrone par flux : la porte"listener"du pont hétérogène considéré ajoute notamment son propre délai isochrone dans le champ syt de l'en-tête CIP.
Le flux traité étant clairement identifié, on peut utiliser un délai isochrone adapté au flux traité, et il n'existe alors aucune ambiguïté quant à la valeur de délai isochrone à ajouter, cette dernière ayant été calculée au cours de l'établissement de connexion de
<Desc/Clms Page number 30>
flux, et mémorisée en association avec l'identifiant du flux. Connaissant l'identifiant du flux, on peut donc retrouver la valeur de délai isochrone calculée précédemment.
On considère désormais, en relation avec la figure 7, le cas d'une requête de lecture du délai isochrone. Lorsque une requête de lecture de délai isochrone est reçue (S200) par le CPU (391) gérant la ROM de configuration d'une porte, celui-ci doit décider de la réponse à envoyer à l'émetteur de la requête.
Dans le premier mode de réalisation de l'invention, conforme à la norme "Standard for High Performance serial Bus Bridges", il n'y avait aucune ambiguïté possible pour les portes des ponts hétérogènes, puisque tous les paquets isochrones subissaient le même délai isochrone : une porte répondait donc à une requête de lecture de délai isochrone en indiquant le délai isochrone commun à tous les flux pour une direction de traversée donnée de cette porte.
Dans ce deuxième mode de réalisation de l'invention, en revanche, le délai isochrone étant dépendant du flux, la porte du pont hétérogène doit mettre en oeuvre un traitement spécifique sur réception d'une requête de lecture du délai isochrone, ainsi qu'illustré par l'algorithme de la figure 7.
Cet algorithme est stocké dans la ROM du pont hétérogène. Il est chargé dans la RAM lors de la mise sous tension et l'unité centrale (CPU) 391 va exécuter les instructions correspondantes.
Au cours d'une étape référencée S201, le pont hétérogène considéré détermine si un identifiant de flux est contenu dans la requête de lecture.
Dans l'affirmative, il vérifie (S202) alors si l'identifiant de flux correspond à un flux en cours. Si oui, le pont hétérogène va lire (S203) en mémoire le délai isochrone d'origine préalablement calculé pour ce flux, et mémorisé en association avec le flux identifié. Il émet alors une réponse S204 contenant le délai isochrone d'origine lu à destination de l'émetteur de la requête de lecture.
Ainsi, si la requête de lecture constitue un message interprétable par la porte du pont hétérogène, et si ce message contient, dans l'un quelconque de ses champs, un identifiant de flux, et si cet identifiant de flux pointe sur un flux qui est en cours de gestion par le pont hétérogène considéré, alors, il n'y a aucune ambiguïté, et la porte du
<Desc/Clms Page number 31>
pont considéré peut émettre une réponse S204 contenant la valeur de délai isochrone caractéristique du flux considéré.
Si, en revanche, une réponse négative est apportée à la réponse S202 (à savoir le flux identifié n'est pas en cours de gestion par le pont hétérogène considéré), l'étape suivante S205 de l'algorithme de la figure 7 consiste à déterminer si des éléments indispensables au calcul d'un délai isochrone d'origine figurent dans la requête de lecture.
De même, si au cours de l'étape référencée S201, on détermine que la requête de lecture ne contient pas d'identifiant de flux, on passe à l'étape référencée S205 visant à identifier la présence, au sein de la requête de lecture, d'éléments de calcul indispensables au calcul d'un délai isochrone d'origine.
Si la requête de lecture de délai isochrone contient de tels éléments indispensables au calcul d'un délai isochrone d'origine, le pont hétérogène calcule (S206) un délai isochrone d'origine, puis passe à l'étape référencée S208 de mémorisation du délai isochrone calculé en association avec le flux considéré.
Si, en revanche, la requête de lecture ne contient pas de tels éléments de calcul, le pont hétérogène fixe arbitrairement (S207) une valeur de délai isochrone d'origine, et mémorise (S208) le délai isochrone fixé arbitrairement, en association avec le flux considéré. La valeur arbitraire choisie par défaut est par exemple celle contenue dans la mémoire CONFIG ROM.
Au cours d'une étape référencée S209, le pont hétérogène considéré émet ensuite une réponse contenant le délai isochrone mémorisé, à destination de l'émetteur de la requête de lecture.
Ainsi, si la requête de lecture de délai isochrone constitue un message interprétable par la porte du pont hétérogène, et si ce message contient, dans l'un quelconque de ses champs, suffisamment d'éléments pour évaluer un délai isochrone sur le réseau, la porte du pont sollicitée réalise une telle évaluation S206, selon la méthode de calcul décrite en relation avec le premier mode de réalisation de l'invention, sans cependant instancier des moyens de transfert (seuil et taille de la FIFO notamment).
Les termes"suffisamment d'éléments"signifient ici que l'on connaît au moins l'identifiant du "listener" dans le cas où la porte du pont sollicitée (la porte 208 dans
<Desc/Clms Page number 32>
l'exemple traité précédemment) est appairée avec la porte "talker" (la porte 207 dans l'exemple décrit précédemment) au sein du réseau commuté 100. Dans le cas où la porte sollicitée (la porte 202 dans l'exemple traité précédemment) constitue la porte"listener" du flux au sein du réseau commuté, ces termes signifient qu'on connaît au moins l'identifiant du"talker".
Si l'on ne connaît pas ces éléments, on peut choisir une valeur arbitraire S207.
Une telle valeur peut par exemple être choisie par le constructeur du pont, à partir de simulations du réseau, de modèles, et/ou de tests de performance de prototypes.
Afin de permettre sa réutilisation ultérieure, la valeur de délai isochrone, calculée ou fixée arbitrairement, est de préférence mémorisée en relation avec des caractéristiques du flux correspondant.
La porte sollicitée peut ensuite émettre une réponse S209 contenant la valeur de délai isochrone calculée ou fixée arbitrairement. La porte émettant une telle réponse mémorise le délai isochrone d'origine indiqué dans sa réponse à la requête de lecture, et tente de l'appliquer aux prochaines procédures d'établissement de connexion de flux impliquant un"listener"et/ou un"talker"présentant l'identifiant spécifié dans la requête de lecture d'origine, et empruntant le même chemin de routage.
Si la requête de lecture ne contient aucun élément permettant de déterminer à quelles fins l'émetteur de la requête souhaite connaître la valeur de délai isochrone de la porte sollicitée, cette dernière peut renvoyer un message d'erreur dans sa réponse à la requête, afin de ne pas fournir à l'émetteur de la requête une valeur de délai isochrone arbitraire, qui pourrait compromettre le fonctionnement futur du réseau de l'invention.
Il est important de noter que, si la topologie du réseau commuté change de manière dynamique (ce qui signifie que les noeuds du réseau commuté présentent des caractéristiques dites de"hot-plugging" ("connexion à chaud"), il est recommandé que le contrôleur cherchant à établir une connexion de flux, au cours de sa procédure d'établissement d'une connexion de flux, requière une confirmation de la valeur de délai isochrone, lorsque cette dernière a été requise au moyen d'une requête de lecture adressée à la ROM de configuration de la porte du pont considéré.
Par contrôleur, on entend un noeud utilisant des messages interpont pour établir ou clore un chemin pour un flux de données entre un"talker"et un"listener".
<Desc/Clms Page number 33>
On considère enfin le cas de l'établissement d'une connexion de flux. On rappelle que, selon le standard"Standard for High Performance serial Bus Bridges", au cours d'un établissement de connexion de flux pour un flux isochrone, le contrôleur qui requiert la connexion émet un message de type JOIN à destination du bus terminal auquel est connecté le"listener". Ce message est intercepté par la porte terminale (c'est- à-dire la porte du pont connecté au bus terminal sur le chemin de routage vers le listener), qui l'analyse, effectue les traitements nécessaires, le modifie, et l'envoie vers l'initiateur du flux, à savoir le"talker".
Toutes les portes situées sur le chemin de routage menant au"talker"interceptent le message et effectuent les traitements nécessaires. A partir du message JOIN, la porte terminale sur le chemin de routage vers le"talker"génère un message LISTEN, afin d'établir une connexion complète entre le"talker"et le"listener". Les portes'listener" situées sur le chemin de routage du"talker"au"listener"doivent augmenter la valeur contenue dans le champ isochronous delay du message LISTEN (ainsi que décrit en relation avec le premier mode de réalisation de l'invention) de la valeur du délai subi par les paquets isochrones lors de la traversée du pont.
On notera que selon le standard"Standard for High Performance serial Bus Bridges", la procédure d'établissement d'une connexion de flux utilise des messages inter-ponts contenant un identifiant du flux concerné. Pour traiter une telle situation, il n'est pas nécessaire d'avoir un délai isochrone commun à tous les flux : on peut appliquer un délai isochrone distinct pour chaque flux traversant le pont.
On décrit désormais en relation avec les figures 8 à 9, les différents algorithmes pouvant être mis en oeuvre par un pont hétérogène sur réception d'une requête d'établissement de connexion de flux, selon le deuxième mode de réalisation de l'invention.
Ces algorithmes sont stockés dans la ROM du pont hétérogène. Ils sont chargés dans la RAM lors de la mise sous tension et l'unité centrale (CPU) 391 va exécuter les instructions correspondantes.
Lorsque la porte d'un pont hétérogène reçoit (S300) une requête d'établissement de connexion pour un identifiant de flux pour lequel elle a déjà précédemment généré une réponse à une requête de lecture, ainsi que décrit en relation avec la figure 7, elle
<Desc/Clms Page number 34>
met en oeuvre l'un des algorithmes des figures 8a et 8b, pour accepter ou refuser l'établissement de la connexion de flux demandé. L'un de ces algorithmes doit être mis en oeuvre à chaque requête de connexion de flux impliquant l'un des éléments mémorisés au cours de l'étape référencée S208 de la figure 7.
Au cours d'une étape référencée S301, commune aux figures 8a et 8b, le pont hétérogène détermine s'il existe, dans la requête d'établissement de connexion de flux reçue, des éléments permettant d'obtenir une valeur de délai isochrone qui aurait été préalablement insérée dans une réponse à une requête de écture pour ce flux. Ainsi, si la requête d'établissement de connexion de flux contient un identifiant de flux préalablement géré par le pont hétérogène, et pour lequel ce dernier a généré une réponse à une requête de lecture contenant une valeur de délai isochrone (calculée ou choisie arbitrairement par exemple), le pont hétérogène peut extraire de sa mémoire la valeur de délai isochrone mémorisée préalablement en association avec l'identifiant de flux.
Une telle valeur de délai isochrone mémorisée et lue en mémoire par le pont hétérogène peut alors être utilisée lors de l'établissement S302 de la connexion de flux par ce dernier.
Si en revanche, la requête d'établissement de connexion de flux S300 est relative à un flux pour lequel le pont hétérogène a préalablement généré une réponse à une requête de lecture du délai isochrone, mais que ce délai ne peut pas être lu, par manque d'éléments dans la requête d'établissement de connexion de flux (réponse "non" à l'étape référencée S301 des figures 8a et 8b), le pont hétérogène peut mettre en oeuvre l'une ou l'autre des étapes référencées S303a et S303b des figures 8a et 8b respectivement.
Ainsi, selon une première variante de réalisation, le pont hétérogène peut décider, au cours d'une étape référencée S303a, de calculer un délai isochrone d'origine pour le flux considéré, s'il dispose de suffisamment d'éléments pour le faire, et selon la technique de calcul déjà décrite précédemment dans ce document. Il accepte ensuite l'établissement de la connexion de flux avec la valeur du délai isochrone d'origine qu'il vient de calculer.
Par exemple, le pont hétérogène accepte l'établissement de la connexion de flux, indique la nouvelle valeur de délai isochrone calculée dans une message LISTEN, et se
<Desc/Clms Page number 35>
met en attente d'une demande de confirmation de la valeur du délai isochrone par l'émetteur de la requête d'établissement de connexion de flux. On notera que, selon la norme"Standard for High Performance Serial Bus Bridges", le contrôleur à l'origine de l'établissement de la connexion de flux reçoit un message STREAM STATUS, contenant le délai isochrone subi par les paquets sur l'ensemble du chemin de routage du terminal d'entrée"talker"au terminal destinataire"listener". Cette valeur de délai isochrone peut être comparée à la valeur de délai isochrone attendue, et en cas de différence entre ces deux valeurs, le contrôleur peut requérir une confirmation de la valeur de délai isochrone de chacun des ponts hétérogènes du réseau, et prendre ensuite la décision de maintenir ou de mettre fin à la connexion de flux établie.
Selon une deuxième variante de réalisation, en l'absence de valeur de délai isochrone connue, le pont hétérogène peut aussi décider de refuser l'établissement de la connexion de flux, au cours d'une étape référencée S303b sur la figure 8b.
Par exemple, en cas de modification de la topologie du réseau après la génération par le pont hétérogène d'une réponse de lecture de délai isochrone, la valeur de délai isochrone préalablement envoyée dans la réponse peut âre rendue obsolète, ce qui peut donc amener le pont à décider de refuser l'établissement de la connexion de flux, comme décrit précédemment en relation avec l'étape référencée S5 de la figure 5, et d'effacer la valeur de délai isochrone qui avait été mémorisée au cours de l'étape référencée S208 de la figure 7. La prochaine requête de lecture de délai isochrone, ou le prochain établissement de connexion de flux pour le flux considéré permettra d'établir une nouvelle valeur de délai isochrone, plus adaptée à la nouvelle configuration du réseau commuté 100.
On décrit désormais en relation avec la figure 9 le traitement mis en oeuvre dans un pont hétérogène sur réception d'une requête d'établissement de connexion de flux pour un flux non préalablement traité par le pont.
Au cours d'une étape référencée SI 00, le pont hétérogène reçoit une requête d'établissement de connexion de flux.
Figure img00350001
Au cours d'une étape référencée SI 0 1, le pont hétérogène considéré calcule alors la taille de la FIFO d'origine, comme décrit précédemment en relation avec la figure 5. Le pont hétérogène calcule alors (S 102) le temps de latence du réseau, puis calcule et
<Desc/Clms Page number 36>
mémorise (S 103) le délai isochrone d'origine pour le flux considéré. II instancie ensuite (S104) la FIFO, et accepte (S 105) l'établissement de la connexion de flux, avec le délai isochrone d'origine calculé et mémorisé.
Ainsi, le délai isochrone d'origine calculé et utilisé dans le cadre de l'algorithme de la figure 9 est optimisé par rapport au chemin de routage du flux au travers du réseau commuté 100.

Claims (36)

  1. REVENDICATIONS 1. Procédé de gestion des délais isochrones associés à des ponts compris dans un réseau de bus numériques, chaque pont étant associé à un délai isochrone pour chaque direction de traversée de l'une vers l'autre de ses portes, caractérisé en ce que ledit réseau de bus numériques est hétérogène, les bus numériques étant interconnectés entre eux : soit directement, via des ponts homogènes comprenant chacun une première et une seconde portes à chacune desquelles est connecté un des bus numériques ; soit à travers au moins un réseau commuté, via des ponts hétérogènes comprenant chacun une première porte, à laquelle est connecté un des bus numériques, et une seconde porte, à laquelle est connecté le réseau commuté, le réseau commuté comprenant une pluralité de noeuds reliés entre eux par une pluralité de liens, chaque pont hétérogène formant un des noeuds du réseau commuté ; et en ce que, lorsque l'on souhaite établir une connexion de flux impliquant la traversée d'un pont hétérogène donné dans une direction de traversée donnée, le procédé comprend l'étape suivante : on détermine un délai isochrone d'origine, associé à la direction de traversée donnée du pont hétérogène donné, en prenant en compte, dans une proportion propre au pont hétérogène donné, un délai introduit par le passage du flux le long d'un chemin de routage à travers le réseau commuté.
  2. 2. Procédé selon la revendication 1, caractérisé en ce que ladite étape de détermination d'un délai isochrone d'origine comprend elle-même les étapes suivantes : on obtient un chemin de routage dudit flux à travers le réseau commuté, depuis le pont hétérogène donné vers un autre pont hétérogène ; on obtient un délai introduit par le passage du flux le long du chemin de routage ; on détermine une proportion propre au pont hétérogène donné, dans laquelle celui-ci doit tenir compte du délai introduit par le passage du flux le long du chemin de routage ; on calcule un délai isochrone d'origine, associé à la direction de traversée donnée du pont hétérogène donné, en prenant en compte, dans la proportion propre au
    <Desc/Clms Page number 38>
    pont hétérogène donné, le délai introduit par le passage du flux le long du chemin de routage.
  3. 3. Procédé selon la revendication 1, caractérisé en ce que ladite étape de détermination d'un délai isochrone d'origine comprend elle-même l'étape suivante : on choisit un délai isochrone d'origine possédant une valeur prédéterminée.
  4. 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que lesdits bus numériques sont des bus numériques de type IEEE 1394.
  5. 5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ledit réseau commuté est un réseau audiovisuel domestique, ledit réseau hétérogène permettant d'interconnecter une pluralité de terminaux, connectés les uns aux noeuds et les autres aux bus numériques.
  6. 6. Procédé selon l'une quelconque des revendications 2 à 5, caractérisé en ce que le délai, Dréseau commuté, introduit par le passage du flux le long du chemin de routage est calculé selon la formule suivante :
    Figure img00380001
    Dréseau commuté = Nnoeuds intermédiairesX Dcommutation avec Noeuds intermédiairesle nombre de noeuds intermédiaires le long du chemin de routage, et Dcommutation le délai de commutation moyen par noeud.
  7. 7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ladite proportion propre au pont hétérogène donné est d'environ 50 %.
  8. 8. Procédé selon l'une quelconque des revendications 2 à 7, caractérisé en ce que le délai isochrone d'origine Disochrone origine est calculé selon la formule suivante :
    Figure img00380002
    Disochrone origine = (P% X Dréseau commuté) + Dtraversée FIFO origine + Dtraitement pont avec P% la proportion propre au pont hétérogène donné, Dréseau commuté le délai introduit par le passage du flux le long du chemin de routage, Dtraversée FIFO origine le délai de traversée, par le flux, d'une mémoire FIFO d'origine comprise dans le pont hétérogène donné et utilisée pour la direction de traversée donnée, Dtraitement pont le délai de transfert, au sein du pont hétérogène, d'un élément du flux, depuis la mémoire FIFO vers une interface de bus numérique, ou inversement.
  9. 9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que ladite étape de détermination d'un délai isochrone d'origine est suivie de l'étape suivante :
    <Desc/Clms Page number 39>
    on adapte et on instancie au moins certaines des ressources dudit pont hétérogène donné, pour la direction de traversée donnée, de façon telle que le délai isochrone d'origine, dont ! a détermination est basée sur les ressources d'origine du pont hétérogène donné, soit modifié en un délai isochrone adapté, dont la détermination est basée sur les ressources adaptées du pont hétérogène donné, ledit délai isochrone adapté devant être sensiblement égal à un délai isochrone de référence prédéterminé.
  10. 10. Procédé selon la revendication 9, caractérisé en ce que ladite étape d'adaptation et d'instanciation d'au moins certaines des ressources dudit pont hétérogène donné comprend elle-même les étapes suivantes : on compare le délai isochrone d'origine, calculé préalablement, et le délai isochrone de référence prédéterminé ; si le délai isochrone d'origine est supérieur au délai isochrone de référence, on refuse l'établissement d'une connexion de flux ; si le délai isochrone d'origine est inférieur ou égal au délai isochrone de référence : * on adapte et on instancie au moins certaines des ressources dudit pont hétérogène donné, pour la direction de traversée donnée, de façon telle que le délai isochrone d'origine soit modifié en un délai isochrone adapté sensiblement égal au délai isochrone de référence ; * on accepte l'établissement d'une connexion de flux.
  11. 11. Procédé selon l'une quelconque des revendications 9 et 10, caractérisé en ce que les ressources instanciées du pont hétérogène donné, pour la direction de traversée donnée, comprennent une mémoire FIFO, dite mémoire FIFO d'origine puis, après adaptation et instanciation, mémoire FIFO adaptée.
  12. 12. Procédé selon la revendication 11, ladite mémoire FIFO d'origine possédant une taille 4IFO origine telle que : LFIFO origine = + X avec une premi ère partie de la mémoire FIFO d'origine, appelée seuil d'origine, et X une seconde partie de la mémoire FIFO d'origine, permettant de contrer la gigue de réseau,
    <Desc/Clms Page number 40>
    Disochrone origine est le délai isochrone d'origine et X une seconde partie de la mémoire FIFO adaptée, identique à ladite seconde partie de la mémoire FIFO d'origine, permettant de contrer la gigue de réseau.
    Disochrone référence est le délai isochrone de référence,
    caractérisé en ce que ladite mémoire FIFO adaptée possède une taille LFIFO adaptée telle que : LFIFO adaptée = 1 + X avec'une premi ère partie de la mémoire FIFO adaptée, telle que : 1 = + , avec ladite premi ère partie de la mémoire FIFO d'origine, appelée seuil d'origine, et 0 le plus grand entier tel que : S 8 max avec 6 maux = Débit flux X (Disochrone référence - Disochrone origine) où Débit flux est le débit du flux,
  13. 13. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que ladite étape de calcul d'un délai isochrone d'origine est suivie de l'étape suivante : on mémorise le délai isochrone d'origine dans le pont hétérogène donné, pour la direction de traversée donnée, en association avec le flux pour lequel l'établissement d'une connexion a nécessité le calcul dudit délai isochrone d'origine.
  14. 14. Procédé selon la revendication 13, caractérisé en ce que, dans le cas d'un traitement d'un paquet CIP compris dans un flux, le pont hétérogène donné, pour la direction de traversée donnée, effectue les étapes suivantes : identification du flux dans lequel est compris le paquet CIP ; lecture, dans une mémoire, d'un délai isochrone d'origine préalablement calculé et mémorisé en association avec le flux identifié ; - utilisation du délai isochrone d'origine lu pour traiter le paquet CIP.
  15. 15. Procédé selon la revendication 13, caractérisé en ce que, dans le cas d'un traitement d'une requête de lecture du délai isochrone, le pont hétérogène donné, pour la direction de traversée donnée, effectue les étapes suivantes : le pont hétérogène donné tente de lire la requête de lecture et notamment un identifiant de flux éventuellement compris dans la requête ;
    <Desc/Clms Page number 41>
    si la requête de lecture contient un identifiant de flux, et si l'identifiant de flux indique un flux qui est en cours de gestion par le pont hétérogène donné, alors le pont hétérogène donné lit, dans une mémoire, un délai isochrone d'origine préalablement calculé et mémorisé en association avec le flux identifié, puis envoie une réponse contenant le délai isochrone d'origine lu.
  16. 16. Procédé selon la revendication 13, caractérisé en ce que, dans le cas d'un traitement d'une requête de lecture du délai isochrone, le pont hétérogène donné, pour la direction de traversée donnée, effectue les étapes suivantes : le pont hétérogène donné tente de lire la requête de lecture et notamment un identifiant de flux éventuellement compris dans la requête ; si la requête de lecture contient un identifiant de flux, et si l'identifiant de flux indique un flux qui n'est pas en cours de gestion par le pont hétérogène donné, ou si la requête de lecture ne contient pas un identifiant de flux, alors le pont hétérogène donné tente d'identifier, au sein de la requête de lecture, des éléments de calcul indispensables au calcul d'un délai isochrone d'origine ; si la requête de lecture contient les éléments de calcul, le pont hétérogène donné calcule un délai isochrone d'origine, le mémorise en association avec le flux identifié, puis envoie une réponse contenant le délai isochrone d'origine calculé.
  17. 17. Procédé selon la revendication 13, caractérisé en ce que, dans le cas d'un traitement d'une requête de lecture du délai isochrone, le pont hétérogène donné, pour la direction de traversée donnée, effectue les étapes suivantes : le pont hétérogène donné tente de lire la requête de lecture et notamment un identifiant de flux éventuellement compris dans la requête ; si la requête de lecture contient un identifiant de flux, et si l'identifiant de flux indique un flux qui n'est pas en cours de gestion par le pont hétérogène donné, ou si la requête de lecture ne contient pas un identifiant de flux, alors le pont hétérogène donné tente d'identifier, au sein de la requête de lecture, des éléments de calcul indispensables au calcul d'un délai isochrone d'origine ;
    <Desc/Clms Page number 42>
    si la requête de lecture ne contient pas les éléments de calcul, le pont hétérogène donné choisit un délai isochrone d'origine possédant une valeur prédéterminée, le mémorise en association avec le flux identifié, puis envoie une réponse contenant le délai isochrone d'origine choisi.
  18. 18. Procédé selon la revendication 13, caractérisé en ce que, dans le cas d'un traitement d'une requête de lecture du délai isochrone, le pont hétérogène donné, pour la direction de traversée donnée, effectue les étapes suivantes : le pont hétérogène donné tente de lire la requête de lecture et notamment un identifiant de flux éventuellement compris dans la requête ; si la requête de lecture contient un identifiant de flux, et si l'identifiant de flux indique un flux qui n'est pas en cours de gestion par le pont hétérogène donné, ou si la requête de lecture ne contient pas un identifiant de flux, alors le pont hétérogène donné tente d'identifier, au sein de la requête de lecture, des éléments de calcul indispensables au calcul d'un délai isochrone d'origine ; si la requête de lecture ne contient pas les éléments de calcul, le pont hétérogène donné envoie une réponse contenant un identifiant d'erreur.
  19. 19. Procédé selon la revendication 13, caractérisé en ce que, dans le cas d'un traitement d'une requête d'établissement d'une connexion de flux, le pont hétérogène donné, pour la direction de traversée donnée, effectue les étapes suivantes : le pont hétérogène donné tente de lire la requête d'établissement d'une connexion de flux, et notamment un identifiant de flux éventuellement compris dans la requête ; si la requête d'établissement d'une connexion de flux contient un identifiant de flux, si l'identifiant de flux indique un flux pour lequel le pont hétérogène donné a préalablement généré une réponse à une requête de lecture du délai isochrone, et si le délai isochrone d'origine contenu dans la réponse préalablement générée peut être lu, alors le pont hétérogène donné lit le délai isochrone d'origine préalablement calculé et mémorisé en association avec le flux identifié, puis autorise l'établissement d'une connexion avec le délai isochrone d'origine lu.
    <Desc/Clms Page number 43>
  20. 20. Procédé selon la revendication 13, caractérisé en ce que, dans le cas d'un traitement d'une requête d'établissement d'une connexion de flux, le pont hétérogène donné, pour la direction de traversée donnée, effectue les étapes suivantes : le pont hétérogène donné tente de lire la requête d'établissement d'une connexion de flux, et notamment un identifiant de flux éventuellement compris dans la requête ; si la requête d'établissement d'une connexion de flux contient un identifiant de flux, si l'identifiant de flux indique un flux pour lequel le pont hétérogène donné a préalablement généré une réponse à une requête de lecture du délai isochrone, et si le délai isochrone d'origine contenu dans la réponse préalablement générée ne peut pas être lu, alors le pont hétérogène donné calcule un délai isochrone d'origine, le mémorise en association avec le flux identifié, puis autorise l'établissement d'une connexion avec le délai isochrone d'origine calculé.
  21. 21. Procédé selon la revendication 13, caractérisé en ce que, dans le cas d'un traitement d'une requête d'établissement d'une connexion de flux, le pont hétérogène donné, pour la direction de traversée donnée, effectue les étapes suivantes : le pont hétérogène donné tente de lire la requête d'établissement d'une connexion de flux, et notamment un identifiant de flux éventuellement compris dans la requête ; si la requête d'établissement d'une connexion de flux contient un identifiant de flux, si l'identifiant de flux indique un flux pour lequel le pont hétérogène donné a préalablement généré une réponse à une requête de lecture du délai isochrone, et si le délai isochrone d'origine contenu dans la réponse préalablement générée ne peut pas être lu, alors le pont hétérogène donné refuse l'établissement d'une connexion.
  22. 22. Procédé selon la revendication 13, caractérisé en ce que, dans le cas d'un traitement d'une requête d'établissement d'une connexion de flux, le pont hétérogène donné, pour la direction de traversée donnée, effectue les étapes suivantes :
    <Desc/Clms Page number 44>
    le pont hétérogène donné tente de lire la requête d'établissement d'une connexion de flux, et notamment un identifiant de flux éventuellement compris dans la requête ; si la requête d'établissement d'une connexion de flux contient un identifiant de flux, si l'identifiant de flux indique un flux pour lequel le pont hétérogène donné n'a pas préalablement calculé un délai isochrone d'origine, alors le pont hétérogène donné calcule un délai isochrone d'origine, le mémorise en association avec le flux identifié, puis autorise l'établissement d'une connexion avec le délai isochrone d'origine calculé.
  23. 23. Pont hétérogène, du type compris dans un réseau hétérogène du type comprenant une pluralité de bus numériques, interconnectés entre eux : soit directement, via des ponts homogènes comprenant chacun une première et une seconde portes à chacune desquelles est connecté un des bus numériques ; soit à travers au moins un réseau commuté, via des ponts hétérogènes comprenant chacun une première porte, à laquelle est connecté un des bus numériques, et une seconde porte, à laquelle est connecté le réseau commuté, le réseau commuté comprenant une pluralité de noeuds reliés entre eux par une pluralité de liens, chaque pont hétérogène formant un des noeuds du réseau commuté ; chaque pont étant associé à un délai isochrone pour chaque direction de traversée de l'une vers l'autre de ses portes, caractérisé en ce que ledit pont hétérogène comprend des moyens de détermination d'un délai isochrone d'origine, de façon que, lorsque ledit pont hétérogène reçoit une requête d'établissement d'une connexion de flux impliquant la traversée dudit pont hétérogène dans une direction de traversée donnée, lesdits moyens de détermination permettent de déterminer un délai isochrone d'origine, associé à la direction de traversée donnée du pont hétérogène donné, en prenant en compte, dans une proportion propre au pont hétérogène donné, un délai introduit par le passage du flux le long d'un chemin de routage à travers le réseau commuté.
  24. 24. Pont hétérogène selon la revendication 23, caractérisé en ce que lesdits moyens de détermination d'un délai isochrone d'origine comprennent :
    <Desc/Clms Page number 45>
    des moyens d'obtention d'un chemin de routage dudit flux à travers le réseau commuté, depuis le pont hétérogène donné vers un autre pont hétérogène ; des moyens d'obtention d'un délai introduit par le passage du flux le long du chemin de routage ; des moyens de détermination d'une proportion propre au pont hétérogène donné, dans laquelle celui-ci doit tenir compte du délai introduit par le passage du flux le long du chemin de routage ; des moyens de calcul d'un délai isochrone d'origine, associé à la direction de traversée donnée du pont hétérogène donné, en prenant en compte, dans la proportion propre au pont hétérogène donné, le délai introduit par le passage du flux le long du chemin de routage.
  25. 25. Pont hétérogène selon la revendication 23, caractérisé en ce que lesdits moyens de détermination d'un délai isochrone d'origine comprennent : des moyens permettant de choisir un délai isochrone d'origine possédant une valeur prédéterminée.
  26. 26. Pont hétérogène selon l'une quelconque des revendications 23 à 25, caractérisé en ce que lesdits bus numériques sont des bus numériques de type IEEE 1394.
  27. 27. Pont hétérogène selon l'une quelconque des revendications 23 à 26, caractérisé en ce que ledit réseau commuté est un réseau audiovisuel domestique, ledit réseau hétérogène permettant d'interconnecter une pluralité de terminaux, connectés les uns aux noeuds et les autres aux bus numériques.
  28. 28. Pont hétérogène selon l'une quelconque des revendications 2 à 5, caractérisé en ce que le délai, Dréseau commuté, introduit par le passage du flux le long du chemin de routage est calculé selon la formule suivante : Dréseau commuté = Noeuds intermédiaires Dcommutation avec Nnoeuds intermédiairesie nombre de noeuds intermédiaires lelong du chemin de routage, et Dcommutation le délai de commutation moyen par noeud.
  29. 29. Pont hétérogène selon l'une quelconque des revendications 23 à 28, caractérisé en ce que ladite proportion propre au pont hétérogène donné est d'environ 50 %.
    <Desc/Clms Page number 46>
  30. 30. Pont hétérogène selon l'une quelconque des revendications 23 à 29, caractérisé en ce que le délai isochrone d'origine isochrone origine est calculé selon la formule suivante
    Figure img00460001
    Disochrone origine = (P% X Dréseau commute)'traversée FIFO origine'traitement pont avec P% la proportion propre au pont hétérogène donné, Dréseau commuté le délai introduit par le passage du flux le long du chemin de routage, Dtraversée FIFO origine le délai de traversée, par le flux, d'une mémoire FIFO d'origine comprise dans le pont hétérogène donné et utilisée pour la direction de traversée donnée, Dtraitement pont le délai de transfert, au sein du pont hétérogène, d'un élément du flux, depuis la mémoire FIFO vers une interface de bus numérique, ou inversement.
  31. 31. Pont hétérogène selon l'une quelconque des revendications 23 à 30, caractérisé en ce que, outre lesdits moyens de détermination d'un délai isochrone d'origine, ledit pont hétérogène comprend : des moyens d'adaptation et d'instanciation d'au moins certaines des ressources dudit pont hétérogène donné, pour la direction de traversée donnée, de façon telle que le délai isochrone d'origine, dont la détermination est basée sur les ressources d'origine du pont hétérogène donné, soit modifié en un délai isochrone adapté, dont h détermination est basée sur les ressources adaptées du pont hétérogène donné, ledit délai isochrone adapté devant être sensiblement égal à un délai isochrone de référence prédéterminé.
  32. 32. Pont hétérogène selon la revendication 31, caractérisé en ce que les ressources instanciées du pont hétérogène donné, pour la direction de traversée donnée, comprennent une mémoire FIFO, dite mémoire FIFO d'origine puis, après adaptation et instanciation, mémoire FIFO adaptée.
  33. 33. Pont hétérogène selon la revendication 32, ladite mémoire FIFO d'origine possédant une taille LFIFO origine telle que : LFIFO origine = + X avec une premi ère partie de la mémoire FIFO d'origine, appelée seuil d'origine, et X une seconde partie de la mémoire FIFO d'origine, permettant de contrer la gigue de réseau, caractérisé en ce que ladite mémoire FIFO adaptée possède une taille LFIFO adaptée telle que : LFIFO adaptée = + X
    <Desc/Clms Page number 47>
    Disochrone origine est le délai isochrone d'origine et X une seconde partie de la mémoire FIFO adaptée, identique à ladite seconde partie de la mémoire FIFO d'origine, permettant de contrer la gigue de réseau.
    avec'une premi ère partie de la mémoire FIFO adaptée, telle que :'= + 8, avec ladite premi ère partie de la mémoire FIFO d'origine, appelée seuil d'origine, et ≈le plus grand entier tel que : 8 8 max avec fimax = Débitnux X (Disochrone référence - Disochrone origine) où Débit flux est le débit du flux, D, isochrone référence est le délai isochrone de référence,
  34. 34. Pont hétérogène selon l'une quelconque des revendications 23 à 30, caractérisé en ce que, outre lesdits moyens de calcul d'un délai isochrone d'origine, ledit pont hétérogène comprend : des moyens de mémorisation du délai isochrone d'origine, pour la direction de traversée donnée, en association avec le flux pour lequel l'établissement d'une connexion a nécessité le calcul dudit délai isochrone d'origine.
  35. 35. Programme d'ordinateur, caractérisé en ce que ledit programme comprend des séquences d'instructions adaptées à la mise en oeuvre d'un procédé selon l'une quelconque des revendications 1 à 22 lorsque ledit programme est exécuté sur un ordinateur.
  36. 36. Produit programme d'ordinateur de gestion des délais isochrones associés à des ponts hétérogènes dans un réseau hétérogène du type comprenant une pluralité de bus numériques, interconnectés entre eux : soit directement, via des ponts homogènes comprenant chacun une première et une seconde portes à chacune desquelles est connecté un des bus numériques ; soit à travers au moins un réseau commuté, via des ponts hétérogènes comprenant chacun une première porte, à laquelle est connecté un des bus numériques, et une seconde porte, à laquelle est connecté le réseau commuté, le réseau commuté comprenant une pluralité de noeuds reliés entre eux par une pluralité de liens, chaque pont hétérogène formant un des noeuds du réseau commuté ;
    <Desc/Clms Page number 48>
    chaque pont étant associé à un délai isochrone pour chaque direction de traversée de l'une vers l'autre de ses portes, ledit produit programme d'ordinateur comprenant des instructions de code de programme enregistré sur un support utilisable dans un ordinateur comprenant : des moyens de programmation lisibles par ordinateur pour effectuer, lorsque l'on souhaite établir une connexion de flux impliquant la traversée d'un pont hétérogène donné dans une direction de traversée donnée, une étape de détermination d'un délai isochrone d'origine, associé à la direction de traversée donnée du pont hétérogène donné, en prenant en compte, dans une proportion propre au pont hétérogène donné, un délai introduit par le passage du flux le long d'un chemin de routage à travers le réseau commuté.
FR0111115A 2001-08-24 2001-08-24 Procede de gestion des delais isochrones associes a des ponts heterogenes dans un heterogene de bus numeriques Withdrawn FR2828946A1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
FR0111115A FR2828946A1 (fr) 2001-08-24 2001-08-24 Procede de gestion des delais isochrones associes a des ponts heterogenes dans un heterogene de bus numeriques
US10/216,782 US7269137B2 (en) 2001-08-24 2002-08-13 Method for setting up an isochronous data stream connection, with the application of a predetermined, total isochronous delay on one or more routing paths
DE60201873T DE60201873T2 (de) 2001-08-24 2002-08-22 Verfahren zum Aufbau eines isochronen Datenstroms durch die Verwendung einer vorbestimmten isochronen Verzögerung an einen oder mehreren Pfaden
EP02364034A EP1289211B1 (fr) 2001-08-24 2002-08-22 Méthode pour établir un flux de données isochrone, en appliquant un délai total isochrone prédéterminé à un ou plusieurs chemins de routage
JP2002245708A JP3647429B2 (ja) 2001-08-24 2002-08-26 アイソクロナスデータストリーム接続の確立装置及び方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0111115A FR2828946A1 (fr) 2001-08-24 2001-08-24 Procede de gestion des delais isochrones associes a des ponts heterogenes dans un heterogene de bus numeriques

Publications (1)

Publication Number Publication Date
FR2828946A1 true FR2828946A1 (fr) 2003-02-28

Family

ID=8866737

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0111115A Withdrawn FR2828946A1 (fr) 2001-08-24 2001-08-24 Procede de gestion des delais isochrones associes a des ponts heterogenes dans un heterogene de bus numeriques

Country Status (1)

Country Link
FR (1) FR2828946A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
EP1087581A2 (fr) * 1999-09-24 2001-03-28 Nec Corporation Méthode et dispositif pour le transfert de paquets isochrones et support d'information lisible par ordinateur enregistré en utilisant la méthode descrite précédemment
WO2001042877A2 (fr) * 1999-11-29 2001-06-14 Sony Electronics, Inc. Procede et systeme destines a ameliorer la largeur de bande dans un pont de bus

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
EP1087581A2 (fr) * 1999-09-24 2001-03-28 Nec Corporation Méthode et dispositif pour le transfert de paquets isochrones et support d'information lisible par ordinateur enregistré en utilisant la méthode descrite précédemment
WO2001042877A2 (fr) * 1999-11-29 2001-06-14 Sony Electronics, Inc. Procede et systeme destines a ameliorer la largeur de bande dans un pont de bus

Similar Documents

Publication Publication Date Title
EP1835411B1 (fr) Systeme sur puce a controle semi-distribue
US20180262359A1 (en) System and method for a managed network with quality-of-service management
EP2052503B1 (fr) Procede d&#39;optimisation du transfert d&#39;informations dans un reseau de telecommunication
JP2001034576A (ja) メディア処理システム及び方法
US11968281B2 (en) Distributed machine-learning resource sharing and request routing
US9894124B2 (en) Rapid startup with dynamic reservation capabilities for network communication systems
FR2804812A1 (fr) Procede et dispositif de communication entre un premier et un deuxieme reseau
FR2913156A1 (fr) Procede d&#39;allocation de ressources de transmission d&#39;un contenu de donnees, produit programme d&#39;ordinateur, moyen de stockage et dispositif correspondants
EP1289211A1 (fr) Méthode pour établir un flux de données isochrone, en appliquant un délai total isochrone prédéterminé à un ou plusieurs chemins de routage
FR2865334A1 (fr) Procede et systeme de transmission de messages dans un reseau d&#39;interconnexions.
EP0874533B1 (fr) Procédé d&#39;ordonnancement de paquets à pertes équitables
Caraguay et al. SDN/NFV Architecture for IoT Networks.
FR2828946A1 (fr) Procede de gestion des delais isochrones associes a des ponts heterogenes dans un heterogene de bus numeriques
Montessoro et al. Advanced research issues for tomorrow's multimedia networks
FR2831745A1 (fr) Procede d&#39;etablissement d&#39;une connexion de flux de donnees isochrone impliquant la traversee d&#39;un reseau commute, noeuds d&#39;entree et de sortie correspondants
FR2848056A1 (fr) Procedes d&#39;insertion et de traitement d&#39;informations pour la synchronisation d&#39;un noeud destinataire a un flux de donnees traversant un reseau de base d&#39;un reseau heterogene, et noeuds correspondants
FR2857809A1 (fr) Procede de selection et d&#39;etablissement d&#39;une connexion de flux de donnees via un equipement intermediaire, programme d&#39;ordinateur et equipement intermediaire correspondants.
WO2024067148A1 (fr) Procédé, appareil et système d&#39;exécution de service d&#39;interconnexion périphérique, dispositif électronique, et support
EP2014026B1 (fr) Procede de transmission d&#39;une pluralite de champs identificateurs dans un reseau a commutation de paquets
FR2842682A1 (fr) Procede d&#39;etablissement d&#39;une connexion de flux de donnees isochrone, avec application d&#39;un delai isochrone total predetermine sur un ou plusieurs chemins de routage
EP2553888B1 (fr) Procédé et système de transmission de flux multimédia
EP4142251A1 (fr) Procede de traitement d&#39;une requete d&#39;interet dans un reseau ndn
EP0612173B1 (fr) Réservation de débit dans un réseau à transfert temporel asynchrone
FR2827995A1 (fr) Procede et dispositif de gestion de memoire
FR2665040A1 (fr) Procede et dispositif de pontage entre reseaux locaux.

Legal Events

Date Code Title Description
ST Notification of lapse