FR2780837A1 - Procede et dispositif de communication d'information - Google Patents

Procede et dispositif de communication d'information Download PDF

Info

Publication number
FR2780837A1
FR2780837A1 FR9808627A FR9808627A FR2780837A1 FR 2780837 A1 FR2780837 A1 FR 2780837A1 FR 9808627 A FR9808627 A FR 9808627A FR 9808627 A FR9808627 A FR 9808627A FR 2780837 A1 FR2780837 A1 FR 2780837A1
Authority
FR
France
Prior art keywords
transmission
communication device
communication
information
path
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.)
Granted
Application number
FR9808627A
Other languages
English (en)
Other versions
FR2780837B1 (fr
Inventor
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 FR9808627A priority Critical patent/FR2780837B1/fr
Priority to US09/345,969 priority patent/US6891797B1/en
Publication of FR2780837A1 publication Critical patent/FR2780837A1/fr
Application granted granted Critical
Publication of FR2780837B1 publication Critical patent/FR2780837B1/fr
Priority to US10/921,901 priority patent/US7602708B2/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/822—Collecting or measuring resource availability data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L12/5602—Bandwidth control in ATM Networks, e.g. leaky bucket
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/805—QOS or priority aware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5619—Network Node Interface, e.g. tandem connections, transit switching
    • H04L2012/562—Routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5629—Admission control
    • H04L2012/5631—Resource management and allocation
    • H04L2012/5632—Bandwidth allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5638—Services, e.g. multimedia, GOS, QOS
    • H04L2012/5645—Connectionless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5638—Services, e.g. multimedia, GOS, QOS
    • H04L2012/5646—Cell characteristics, e.g. loss, delay, jitter, sequence integrity
    • H04L2012/5651—Priority, marking, classes

Landscapes

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

Abstract

Le procédé de communication concerne un réseau comportant des dispositifs de communication, adaptés, chacun, à déterminer, pour chaque information à transmettre, le chemin à lui faire suivre sur le réseau, et un mode de transmission, connecté ou non. Il comporte : - pour chaque dispositif de communication qui doit effectuer une transmission en mode connecté, une opération de diffusion à destination de tous les autres dispositifs de communication du réseau, d'une information représentative de la bande passante nécessaire pour ladite transmission en mode connecté, et - une opération d'attribution de bande passante (1221), au cours de laquelle on attribue, d'une part, aux transmissions en mode connecté, la bande passante qui leur est nécessaire et, d'autre part, toute ou partie de la bande passante disponible à chaque transmission à effectuer en mode non connecté.

Description

La présente invention concerne un procédé et un dispositif de
communication d'information.
Elle s'applique, en particulier, à un réseau à commutation asynchrone de paquets, permettant notamment d'interconnecter un petit nombre d'équipements multimédia, tout en leur fournissant différentes qualités de service
pour échanger des données.
Le comportement d'un trafic de données généré par un équipement multimédia (ou application) peut s'inscrire dans deux classes de service principales, elles mêmes divisées, chacune, en deux sous-classes. Ainsi le trafic peut être soit élastique (il s'adapte facilement aux changements de conditions de transmission), soit temps réel. S'il est élastique, il peut soit être de nature interactive, et donc sensible au délai de transfert, soit correspondre à un transfert massif d'un gros volume de données et donc sensible à la bande passante. S'il s'agit d'un trafic temps réel, soit il est acceptable de perdre certains paquets d'information pour privilégier le délai de transmission, le trafic est alors appelé "déterministe", soit il est préférable de disposer d'un débit moyen mais sans perte
de données, le trafic est alors appelé "garanti".
Le trafic élastique correspond au trafic de type datagramme. Ce trafic est dit élastique car il est capable de s'adapter aux conditions de transmission sans pour autant perdre de son utilité. Un transfert de fichier pourra aussi bien s'exécuter via un chemin supportant un débit de 64 kilobit par seconde que via un chemin supportant un débit de 2 Mégabit par seconde. Pour le trafic élastique, une première classe de base concerne le trafic généré par les applications interactives ou transactionnelles (comme une application de type client-serveur), et une seconde classe identifie les données véhiculées par bloc
(comme le transfert de fichiers).
Les équipements générateurs d'un trafic temps réel requièrent un service déterministe ou garanti. Pour le trafic déterministe, qui privilégie le respect d'une contrainte élevée en ce qui concerne le délai de transmission, l'application qualifie la bande passante dont elle suppose avoir besoin, ainsi que le délai maximal de transmission qu'elle peut accepter. Le réseau privilégie ce type de trafic mais se débarrasse des données pour lesquelles le délai ne peut être respecté. Il s'agit par exemple de transmission vidéo (en cas de problèmes de transmission, une image statique apparaît), ou de systèmes audio de qualité moyenne. Le service dit garanti se différencie du service déterministe par le fait que le réseau ne se débarrasse pas volontairement des données issues d'un trafic garanti mais que celui ci peut être affecté d'un délai de transmission variable en fonction du trafic déterministe plus prioritaire ou au trafic garanti concurrent. Il s'agit, par exemple, du trafic vidéo haute définition (utilisant des techniques de compression). Dans ce cas, le réseau réserve la bande passante à l'application qui requiert un service garanti, mais pour gérer les problèmes de gigue (en anglais "jitter") sur les données à la réception, I'application doit posséder des capacités de stockage temporaires des données (de l'ordre de la seconde de
trafic), afin de rétablir le comportement original du trafic.
La garantie de la qualité de service exigée par des applications concurrentes et de natures différentes passe par la résolution de problèmes tels que la gestion des ressources et le contrôle de trafic. Les procédés à mettre en oeuvre doivent permettre au réseau de fonctionner de façon optimale tout en fournissant une qualité de service acceptable aux différentes applications. Ce problème a fait l'objet de nombreuses études pour les réseaux à commutation de
circuits et pour les réseaux à commutation de paquets.
Dans les réseaux à commutations de circuits, la solution connue consiste à allouer à chaque connexion une bande passante constante (canal) pendant toute sa durée. Au préalable, une procédure d'acceptation d'appel permet au réseau de savoir s'il peut supporter l'appel. Dans le cas o aucun canal n'est disponible, I'appel est rejeté. Dans les réseaux à commutation de paquets o le trafic est, par définition, imprévisible, la nature variable des débits offre l'opportunité d'un partage statistique des ressources du réseau. Cette optimisation des ressources augmente, malheureusement, les risques de congestion. Ces réseaux peuvent être vus comme une succession de files d'attente à capacité limitée dont il convient de contrôler le remplissage afin d'éviter leur saturation, synonyme de
perte de paquets.
Il est connu de contrôler le trafic par un mécanisme dit "de fenêtrage": lorsqu'un état de saturation est détecté, le récepteur demande explicitement à la source de réduire son flux. On parle alors de régulation et de
contrôle de flux.
Aucune de ces approches n'est suffisante, la première parce qu'elle conduit à un gaspillage inévitable des ressources du réseau en allouant à la source une bande passante correspondant à son débit maximal et la seconde parce que le rapport du temps de propagation sur le temps de transmission
augmente de manière considérable lorsque les liaisons sont à très haut débit.
Dans les systèmes de contrôle de flux par rétroaction, entre l'instant d'émission de la notification de congestion et l'instant de sa réception par le noeud source, le trafic déjà en transit dans le réseau peut être considéré comme définitivement perdu en raison de la congestion, à moins de disposer de mémoires de grande
capacité pour conserver tous les paquets en transit pendant l'état de congestion.
Par conséquent, pour la commutation rapide de paquets, les méthodes de contrôle purement réactives sont insuffisantes dans un environnement haut débit. La commutation nécessite des mécanismes élaborés dans les équipements de commutation (noeuds intermédiaires du réseau) incluant des méthodes préventives et des méthodes réactives. La technologie ATM ("Asynchronous Transfert Mode" ou mode de transfert asynchrone), propose des techniques de gestion de la qualité de service, et de contrôle de congestion basées sur des mécanismes élaborés implémentés au sein des équipements de commutation. Des exemples de tels mécanismes sont décrits dans les brevets US 5,291,481 et US 5,313,454 qui illustrent aussi la complexité et le coût potentiel
d'implémentation de telles méthodes.
Ces méthodes ne sont donc pas adaptées à des réseaux comprenant un nombre plus restreint d'équipements à interconnecter o le coût des moyens de communication ne doit pas être trop élevé par rapport au coût des
équipements à interconnecter.
Des tentatives d'utilisation de commutateurs ATM embarqués ont été faites, telles que celle décrite dans la thèse "Architecture distribuée temps réel fondée sur ATM" de Jean-François Guilaud (INPG). Cette thèse mentionne l'utilisation de la signalisation ATM classique afin de permettre la gestion des connexions, ce qui représente une implémentation complexe. Cependant, la mise en oeuvre complète des mécanismes de gestion des connexions doit prévoir d'éviter la congestion, qui, afin de simplifier l'utilisation du commutateur, reposent sur une gestion locale des informations de charge et sur l'utilisation des files
d'attente en sortie pour chaque commutateur.
Le contrôle de flux strict, à la source, tel qu'il est décrit dans la thèse, prévoit l'utilisation d'un mode connecté uniquement, et vérifie le non dépassement du transfert de données par rapport à ce qui a été prévu lors de l'établissement de la connexion correspondante. Cela peut donc engendrer une mauvaise utilisation des ressources réseau ainsi qu'un manque de flexibilité du
système.
Par ailleurs, il n'est envisagé aucun moyen simple pour réagir au problème de congestion si ce n'est en se reposant sur les solutions décrites précédemment, propre a l'utilisation de l'ATM, mais qui demeurent des solutions complexes. De plus, I'utilisation d'une dimension de paquet fixe, conformément à l'ATM, engendre une perte fixe du débit utile par lien du réseau disponible. En revanche, une taille de paquet variable en fonction de la charge du réseau permet d'optimiser le débit utile. Les techniques de contrôle de la taille des paquets ont
déjà été testées sur des architectures réseau de type bus ou anneau.
La commutation asynchrone de paquets, telle que decrite dans la norme IEEE-P1355, est basée sur une technologie de commutation (matrice de commutation non bloquante permettant plusieurs chemins simultanés) à faible coût de réalisation en ce qui concerne le commutateur. En effet, le commutateur en question n'utilise qu'un minimum de ressources pour effectuer la commutation d'un paquet à partir d'un port d'entrée vers un port de sortie. Le transfert d'un paquet au travers du commutateur a lieu dès que le commutateur a connaissance des informations de commutation du dit paquet (en-tête de paquet) sans attendre la complète réception de toutes les données du paquet. Il n'y a donc aucune
gestion de file d'attente ou de priorité dans les noeuds intermédiaires du chemin.
Par ailleurs, afin de régler les problèmes de contention d'accès à un port d'entrée (respectivement vers un port de sortie) du commutateur, lorsque plusieurs paquets sont à priori destinés à transiter via ce port d'entrée (respectivement de sortie), un mécanisme de contrôle de flux au niveau du lien est implémenté, n'autorisant une source à transmettre des données sur la ligne de transmission que lorsqu'elle a obtenu l'autorisation de la part de la destination, c'est-à-dire lorsqu'un groupe de données précédemment émises par la source ont
été acquittées par la destination.
Cependant, la commutation asynchrone de paquets, telle que connue dans l'état de la technique, si elle laisse envisager des coûts d'implémentation attractifs, ne prévoit pas de garantir différentes qualités de
service pour les trafics concurrents au sein d'un même réseau.
Les technologies de type bus série proposent une alternative à l'utilisation de la commutation de paquets pour interconnecter des périphériques à moindre coût. En effet, les mécanismes mis en oeuvre pour partager les ressources se trouvent simplifiés du fait de l'unicité de la ressources principales, en l'occurrence le médium de communication. Cette simplicité implique aussi l'inconvénient d'une bande passante limitée: la bande passante moyenne
disponible par terminal diminue en fonction du nombre de terminaux connectés.
Certaines technologies bus série, telles que celle normalisée par l'IEEE, référence P1394, définie pour l'interconnexion d'équipements multimédia, supportent le transfert des données selon principalement deux classes de service en mettant en oeuvre une architecture logique de type bus. Des mécanismes sont donc nécessaires pour arbitrer l'accès au bus et organiser le transfert des données. Cette technologie de bus série prévoit un mécanisme de réservation de ressources. Il permet, d'une part, la transmission de données dite isochrone, comprenant une phase de réservation, et, d'autre part, la transmission de
données dite asynchrone, sans phase de réservation.
Le document US-A-4,914,650 décrit une méthode pour organiser la transmission de données en provenance de files d'attente différentes et pour y insérer un trafic ultra prioritaire (de type signalisation) en provenance d'une troisième file d'attente, ainsi que des mécanismes pour réagir au problème de congestion dans les files d'attente associées à chaque type de données. Il ne propose pas de solution pour limiter les pertes d'information dues à des
problèmes de congestion et donc pour garantir différentes qualités de service.
Le document US-A-5,621,898 illustre un mécanisme pour organiser la transmission des données sur un bus conforme aux spécifications IEEEP1394. Il décrit ainsi le séquencement des transmissions de paquets, associé à différentes files d'attente ainsi que les mécanismes de contrôle d'accès au bus permettant de prendre en compte la bande passante disponible
pour la transmission de paquets supplémentaires.
L'invention vise à permettre, sur un réseau à commutation de paquets, le séquencement des transmissions de paquets à la source, selon différentes priorités, en fonction, d'une part, de la charge estimée du réseau (en maintenant à jour une table de charge pour tout le trafic connecté) et, d'autre part,
en fonction de la charge effective du réseau (contrôle de flux au niveau des liens).
Dans son application à un réseau commuté, la présente invention vise: - à garantir un accès équitable aux ressources du réseau comprenant plusieurs équipements multimédias; - à organiser le transfert de paquets afin que certains de ces paquets traversent le réseau avec un temps de latence inférieur à une valeur maximale garantie; - à garantir, pour un groupe de paquets formant un flux, une valeur de bande passante déterminée; - à privilégier la transmission de certains paquets dont le contenu décrit de l'information dite "de contrôle", - à optimiser l'utilisation de la bande passante effective du réseau, - à détecter et à circonvenir les congestions du réseau, et - à affranchir les commutateurs des dispositifs de communication intermédiaires de tout traitement concemrnant l'organisation du séquencement des paquets. A cet effet, la présente invention vise un procédé de communication sur un réseau comportant des dispositifs de communication, chaque dispositif de communication étant adapté à déterminer, pour chaque information qu'il a à transmettre, le chemin à lui faire suivre sur le réseau et un mode de transmission, connecté ou non, caractérisé en ce qu'il comporte: - pour chaque dispositif de communication qui doit effectuer une transmission en mode connecté, une opération d'information au cours de laquelle ledit dispositif de communication diffuse, à destination de tous les autres dispositifs de communication du réseau, une information représentative de la bande passante nécessaire pour ladite transmission en mode connecté, et - une opération d'attribution de bande passante, au cours de laquelle on attribue, d'une part, aux transmissions en mode connecté, la bande passante qui leur est nécessaire et, d'autre part, toute ou partie de la bande
passante disponible à chaque transmission à effectuer en mode non connecté.
Ainsi, tous les dispositifs de communication du réseau sont immédiatement informés de chaque connexion et des ressources du réseau qui
lui sont affectées.
Avant d'effectuer la transmission d'un paquet en mode non connecté, chacun des dispositifs de communication susceptibles de le faire, peut vérifier que chacun des liens, ou segments, du chemin que va suivre ce paquet est disponible pour la transmission de ce paquet. Les engorgements
peuvent ainsi être évités.
La régulation de la charge dédiée au trafic en mode non connecté peut ainsi être effectuée en fonction des fluctuations du trafic en mode connecté (temps réel), ce qui permet d'optimiser en permanence l'utilisation du réseau et
d'éviter les engorgements.
Selon des caractéristiques particulières, le procédé de communication tel que succinctement exposé ci-dessus comporte, pour un établissement de connexion: - effectuée par le dispositif de communication source destiné à transmettre de l'information sur ledit chemin, une opération de transmission, à destination de chaque dispositif de communication placé sur ledit chemin, appelé "intermédiaire", d'une information représentative de la bande passante nécessaire pour ladite connexion, et - effectuée par chaque dispositif de communication intermédiaire sur ledit chemin, une opération de détermination de disponibilité du lien menant au dispositif de communication suivant sur ledit chemin et, en cas d'indisponibilité, une opération de transmission à destination du dispositif de communication
source d'une information représentative de l'indisponibilité dudit chemin.
Grâce à ces dispositions, avant d'établir une connexion, on vérifie que le réseau peut supporter la charge potentielle associée à la connexion à établir. En outre, cette vérification est faite par chaque dispositif de communication
placé sur le chemin associé à cette connexion.
Cette prise en compte de la charge estimée revient à effectuer une
estimation de la congestion du réseau.
Selon d'autres caractéristiques particulières, le procédé de communication tel que succinctement exposé ci-dessus comporte, pour chaque transmission d'information, une opération de contrôle de flux effectuée conformément à la norme IEEE 1355, par chacun des dispositifs de communication intermédiaires du chemin suivi par ladite information. Grâce à ces dispositions, le procédé selon l'invention implémente un contrôle de flux au niveau des liens, aussi bien pour le trafic connecté que pour le trafic non connecté, sur un réseau à commutation de paquet. Ces dispositions
reviennent à effectuer un détection de la congestion du réseau.
Selon d'autres caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte: - pour chaque dispositif de communication du réseau, à la suite de chaque opération d'information, une opération de détermination de la bande passante disponible sur chaque lien, en prenant en compte lesdites informations, et - pour chaque dispositif de communication dit "source" qui doit effectuer une transmission en mode non connecté à destination d'un dispositif de communication destinataire: - une opération de détermination de disponibilité de chemin pour une transmission en mode non connecté, au cours de laquelle on détermine si au moins une chemin allant dudit dispositif de communication source audit dispositif de communication destinataire est au moins partiellement disponible pour ladite transmission, a et, dans l'affirmative, une opération de transmission sur
ledit chemin, en mode non connecté.
Grâce à ces dispositions, plusieurs chemins peuvent être utilisés par les transmissions en mode non connecté, en fonction de la charge du reseau. Selon d'autres caractéristiques particulières, le procédé de communication tel que succinctement exposé ci-dessus comporte une opération de la transmission d'information prenant en compte plusieurs niveaux de priorité, et un niveau de priorité est affecté à la transmission en mode non connecté. Grâce à ces dispositions, tout le trafic en mode non connecté est transmis avec le même niveau de priorité, ce qui garantit un accès équitable
pour tous les dispositifs de communication du réseau.
Selon d'autres caractéristiques particulières, au cours de l'opération d'attribution de bande passante, la bande passante associée au niveau de priorité correspondant au mode non connecté varie en fonction d'une
durée n'ayant donné lieu à aucune transmission.
Le procédé de l'invention permet ainsi d'augmenter la bande passante allouée aux transmissions en mode non connecté, lorsque la durée n'ayant donné lieu à aucune transmission augmente, ce qui est signe d'une
absence de congestion du réseau.
Selon d'autres caractéristiques particulières, au cours de l'opération d'attribution de bande passante, la bande passante associée au niveau de priorité correspondant au mode non connecté varie en fonction d'un nombre de
paquets non transmis pendant une durée prédéterminée.
Le procédé de l'invention permet ainsi de réduire la bande passante allouée aux transmissions en mode non connecté, lorsque le nombre de paquets non transmis augmente, ce qui est signe d'une congestion du réseau. Selon d'autres caractéristiques particulières, à chaque niveau de priorité est associé une liste de canaux virtuels, successivement mis en oeuvre,
lesdits canaux virtuels sont associés au trafic sortant.
Grâce à ces dispositions, le séquencement des émissions est effectué sur le trafic sortant et il n'y a donc pas de gestion de ce trafic par les dispositifs de communication intermédiaires, ce qui simplifie le fonctionnement
du réseau et le rend plus efficace.
Selon d'autres caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte une opération de détermination de paramètres de transmission, au cours de laquelle on détermine: - une dimension de paquets transmis sur ledit réseau, ladite opération prenant en compte la charge sur ledit réseau, - un nombre de paquets à émettre sur ledit réseau, ladite opération prenant en compte la charge sur ledit réseau, et/ou - une durée disponible pour émettre les paquets restant à émettre
sur ledit réseau, ladite opération prenant en compte la charge sur ledit réseau.
Ainsi, la bande passante peut être répartie au mieux (c'est-à-dire
efficacement et équitablement).
Selon des caractéristiques particulières, I'opération de détermination de paramètres de transmission a lieu pour chaque dispositif de
communication, canal virtuel par canal virtuel.
Ainsi, les paramètres de transmission peuvent dépendre du
chemin utilisé.
Selon des caractéristiques particulières, ladite opération de détermination de paramètres de transmission est effectuée lors de l'opération d'information. Grâce à ces dispositions, la mise à jour des paramètres peut avoir lieu de manière dynamique et immédiate et le réseau peut donc être réactif aux
variations des contraintes de charge.
Selon d'autres caractéristiques particulières, pour le trafic garanti, l'information non transmise durant un intervalle de temps prédéterminé, est
conservée pour être transmise durant l'intervalle de temps suivant.
Grâce à ces dispositions, des risques de congestion sont évités.
Selon un deuxième aspect, la présente invention vise un dispositif de communication sur un réseau comportant des dispositifs de communication, chaque dispositif de communication étant adapté à déterminer, pour chaque information qu'il a à transmettre, un chemin à lui faire suivre et un mode de transmission, connecté ou non, caractérisé en ce qu'il comporte: - un moyen d'information adapté, pour chaque transmission en mode connecté, à diffuser, à destination de tous les autres dispositifs de communication du réseau, une information représentative de la bande passante nécessaire pour ladite transmission en mode connecté, et - un moyen d'attribution de bande passante, adapté à attribuer, d'une part, aux transmissions en mode connecté, la bande passante qui lui est nécessaire et, d'autre part, tout ou partie de la bande passante disponible à
chaque transmission à effectuer en mode non connecté.
L'invention vise aussi un ordinateur, une caméra, un télécopieur, un appareil photographique, un téléviseur, une imprimante, un scanner et un lecteur audio/vidéo, caractérisés en ce qu'ils comportent un dispositif tel que
succinctement exposé ci-dessus.
L'invention vise aussi - un moyen de stockage d'informations lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique caractérisé en ce qu'il permet la mise en oeuvre du procédé de l'invention telle que succinctement exposée ci-dessus, et - un moyen de stockage d'informations amovible, partiellement ou totalement, et lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique caractérisé en ce qu'il permet la mise
en oeuvre du procédé de l'invention telle que succinctement exposée cidessus.
Les caractéristiques préférentielles ou particulières, et les avantages de ce dispositif, de cet ordinateur, de cette caméra, de ce télécopieur, de cet appareil photographique, de ce téléviseur, de cette imprimante, de ce scanner, de ce lecteur audio/vidéo et de ces moyens de stockage d'information étant identiques à ceux du procédé tel que
succinctement exposé ci-dessus, ces avantages ne sont pas rappelés ici.
D'autres avantages et caractéristiques de l'invention ressortiront
de la description qui va suivre, faite en regard des dessins annexés dans
lesquels: - la figure 1 représente un réseau de noeuds interconnectés, la figure 2 représente un dispositif (ou "moyen") de communication selon la présente invention, - la figure 3 représente des échanges de messages intervenant entre un noeud source et un noeud destinataire pour véhiculer d'une part un trafic connecté et, d'autre part, un trafic non connecté, la figure 4 représente un organigramme mis en oeuvre par le moyen de communication du noeud dit "source" pour une transmission en mode connecté, - la figure 5 représente un organigramme mis en oeuvre par un moyen de communication d'un noeud dit "intermédiaire" pour une transmission en mode connecté, - la figure 6 représente un organigramme mis en oeuvre par un moyen de communication d'un noeud dit "destinataire" pour une transmission en mode connecté, - la figure 7 représente un organigramme mis en oeuvre par un moyen de communication d'un noeud dit "voisin" pour une transmission en mode connecté, - la figure 8 représente un réseau sur lequel circulent des messages de contrôle destinés à la gestion du mode connecté, - la figure 9 représente la structure de messages de contrôle destinés à la gestion du mode connecté, - la figure 10 représente la structure de données d'une table de charge en mémoire d'un moyen de communication, - la figure 11 représente la structure de données d'une table de spécifications et de priorités contenant des canaux virtuels réservés à la transmission en mode connecté, en mémoire d'un moyen de communication, - la figure 12 représente un organigramme d'émission en modes connecté et non connecté d'un moyen de communication tel qu'illustré en figure 2, - la figure 13 représente un organigramme de détermination, par le noeud source, de disponibilité de chemin pour l'établissement d'une connexion, incorporé dans l'organigramme de la figure 4, - la figure 14 représente un organigramme de détermination, par un noeud intermédiaire ou le noeud destinataire, de disponibilité de chemin pour l'établissement d'une connexion, incorporé dans l'organigramme de la figure 5 ou 6,et - la figure 15 représente un organigramme de détermination, par un noeud voisin, de disponibilité de chemin pour l'établissement d'une
connexion, incorporé dans l'organigramme de la figure 7.
Dans toute la présente demande les termes "dispositifs de communication " et "moyen de communication" ont la même signification et
désignent les mêmes combinaisons de moyens objets de la présente invention.
Le mode préféré de réalisation gère trois classes de service spécifiques, déterministe (en mode connecté), garantie (en mode connecté) et
élastique (en mode non connecté), sur un réseau à commutation de paquet.
En figure 1, on observe cinq équipements multimédias 101 à 105 d'un réseau à commutation de paquet 100, reliés entre eux par six liens 106 à 111. Chaque équipement multimédia comporte un moyen de communication 112 et un moyen de traitement de données 113. Le moyen de communication 112 permet au moyen de traitement 113 d'ouvrir une connexion dédiée à un trafic connecté (trafic temps réel déterministe ou garanti) puis de générer ce
trafic, ou bien de générer directement un trafic non connecté (trafic élastique).
Lorsque l'équipement multimédia 101 envoie un paquet de données àl'équipement multimédia 105, par l'intermédiaire des liens 108 et , l'équipement 101 est un noeud "source", I'équipement 105 est un noeud "destinataire", l'équipement 102, par lequel transitent les données, est un noeud "intermédiaire", tandis que les noeuds 103 et 104 sont des noeuds "voisins",
aucune des données transmises ne transitant par l'un d'entre eux.
Le mode de réalisation décrit et représenté concerne un réseau local composé de plusieurs noeuds interconnectés par des liens bidirectionnels rapides. Chaque noeud incorpore un commutateur non bloquant possédant une
matrice de commutation à réception et émission simultanées (en anglais "cut-
through crossbar") et possède un certain nombre de ports externes auxquels peuvent être raccordés des liens. Dans un tel réseau, la route ou le chemin suivi par un paquet est une succession de liens, chacun des liens étant défini
par les deux noeuds qu'il rejoint.
La communication sur un tel réseau est dite "commutée". Un exemple d'un tel réseau est donné par un système utilisant des composants
selon la norme IEEE 1355.
En figure 2, on observe un schéma bloc d'un moyen de communication 112 du réseau, comportant un composant commutateur/routeur 209 couplé à une unité centrale 206 (décomposée en deux entités 206A et 206 B). Le composant commutateur/routeur 209, constitué d'un composant de la marque SGS-THOMSON (marque déposée), référencé ST C104, comporte des ports physiques reliés à un connecteur 230, et deux ports internes dont l'un est dédié au contrôle, reliés à l'unité centrale 206 par
l'intermédiaire de différents composants décrits ci-dessous.
On observe ici que le composant commutateur/routeur susmentionné 209 ST C104 possède, en fait, trente-deux ports physiques en plus de deux ports de contrôle, seulement un port de contrôle et quelques ports physiques étant représentés en figure 2. Des composants d'interface 213 et 216 sont reliés aux deux ports internes du composant commutateur/routeur 209 et sont, chacun, basés sur un composant référencé ST C1I01 et fabriqué sous la
marque SGS-THOMSON.
Le composant commutateur/routeur 209 et les composants d'interface 213 et 216 effectuent un codage conforme à la norme IEEE 1355. Le
composant commutateur/routeur 209 est à architecture de type non bloquante.
Des émetteur/récepteurs, non représentés, plus connus sous leur dénomination technique de langue anglaise "transceiver ", convertissent des signaux TTL, sur les ports physiques du composant commutateur/routeur 209
en signaux différentiels sur le connecteur 230.
Les émetteurs/récepteurs sont, par exemple, des composants de
la marque AT&T (marque déposée) référencés 1141 MK.
Le connecteur 230 est destiné à être relié à plusieurs connecteurs identiques incorporés à d'autres moyens de communication du réseau. Ils sont
de la marque déposée HARTING et de référence 2721-121-8000.
Les composants d'interface 213 et 216 sont reliés, par une liaison parallèle, à une interface PCI 208, elle-même reliée à un bus PCI 231. L'interface 208 est, par exemple, composée d'un circuit AMCC (marque déposée) S5933. Le bus PCI 231 est, en outre, relié:
- à un composant d'interface 232, identique au composant 208, lui-
même relié au moyen de traitement 113 (figure 1); - à une interface de contrôle 203, par exemple constituée d'un composant 82439 HX de marque INTEL , lui même relié à un bus local d'unité centrale 206, comportant un microprocesseur 206A et une mémoire cache statique 206B, et à une mémoire dynamique 204 (constituée des deux entités 204A et 204 B); et - à un composant d'interface 205, par exemple de référence 823715B de marque INTEL , ce composant étant relié à un bus ISA qui relie un contrôleur ISA de périphériques 233, à une mémoire flash de système d'exploitation BIOS 234, à une horloge temps-réel 235 et à une extension de
mémoire flash 236.
L'architecture et les composants du moyen de communication 112 sont bien connus de l'homme du métier des systèmes informatiques et ils ne
sont pas plus détaillés ici.
Pour une meilleure compréhension de la constitution du mode de réalisation décrit et représenté, le lecteur est invité à consulter les notes
d'utilisation des composants, notes fournies par leurs constructeurs respectifs.
L'unité centrale de traitement CPU 206 est composée d'un microcontrôleur 206A de la marque déposée INTEL et de référence PENTIUM (marque déposée) avec 32 Mo de mémoire vive dynamique DRAM 204 à titre
de mémoire de travail, 256 Ko de mémoire statique cache 206B.
On observe ici que l'expression "segment de mémoire" utilisée ci-
dessous désigne, dans chacune des mémoires, aussi bien une zone mémoire de faible capacité (ne conservant que quelques données binaires), qu'une zone
mémoire de grande capacité (permettant de stocker un programme entier).
La mémoire vive 204A conserve des données, des variables et des résultats intermédiaires de traitement utilisés par les programmes stockés en mémoire 204B, dans des segments de mémoire portant, dans la suite de la
description, les mêmes noms que les données dont ils conservent les valeurs.
En cours de fonctionnement, la mémoire flash 204B contient le BIOS et les logiciels de contrôle (qui opèrent avec le système d'exploitation
temps-réel CHORUS (marque déposée)) qui sont décrits en figure 3 à 7.
La mémoire vive 204 comporte notamment: - un segment de mémoire "user_data" dans lequel sont conservées les informations utilisateur à transmettre, dont, en particulier, le service requis (comportant la bande passante nécessaire), - un segment de mémoire " add_data " dans lequel sont conservées des informations additionnelles à transmettre, informations qui définissent, notamment, dans son intégralité, le chemin à suivre par les données utilisateur sur le réseau de communication (figure 9), et - un segment de mémoire "Tables" dans lequel sont conservées une table de charge de chemins et une table de charge de liens comportant des informations décrivant tous les chemins dont le noeud considéré est la source
et tous les liens faisant partie de ces chemins (figures 10 et 11).
La zone d'extension de mémoire 236 est adaptée à conserver: - le programme de fonctionnement de l'unité centrale de traitement 206, dans un segment de mémoire "program1 ", et - un identificateur représentatif du moyen de communication 112,
identificateur qui est unique sur le réseau de communication.
A l'initialisation du moyen de communication, le programme stocké dans la mémoire d'extension 236 est au moins partiellement copié et organisé
dans la zone mémoire d'exécution 204B.
La zone d'extension de mémoire 236 constitue un moyen de stockage d'informations lisibles par un ordinateur ou un microprocesseur, conservant des instructions d'un programme informatique caractérisé en ce qu'il permet la mise en oeuvre du procédé de l'invention. Selon une variante, la zone d'extension de mémoire 236 est amovible, partiellement ou totalement, et comporte, par exemple, une bande magnétique, une mémoire flash, une disquette ou un compact disque à mémoire figée ("CD-ROM" en anglais). Dans le mode de réalisation décrit et représenté, le moyen de traitement utilise le moyen de communication conforme à l'invention. Le moyen de traitement demande l'établissement d'une connexion au moyen de communication en lui faisant part du service requis ("application requirement" en anglais). Ces paramètres dits de "service requis" sont, d'une part, transmis dans certains messages de signalisation et, d'autre part, utilisés pour calculer les paramètres de transmission ("trafic parameters" en anglais). Le service requis est l'étalon utilisé pour la mise à jour des tables de charges dans les différents noeuds du réseau car il ne dépend pas de l'état respectif des tables
de charges.
Les organigrammes objets des figures 4 à 7 n'illustrent que
partiellement le fonctionnement des dispositifs de communication.
L'unité centrale de traitement 206 est adaptée à mettre en oeuvre
les organigrammes décrits en figures 4 à 7.
En figure 3, on observe, symbolisés par des flèches descendantes placées dans une colonne centrale, des messages transmis sur le réseau, entre un noeud source, à gauche, et un noeud destinataire, à droite. Les flèches orientées de la gauche vers la droite correspondent à des messages transmis depuis le noeud source des données utilisateur à destination du noeud destinataire de ces données et les flèches orientées de la droite vers la gauche correspondent à des messages transmis depuis le noeud destinataire des
données utilisateur vers le noeud source de ces données.
Dans la colonne de gauche, sont représentés les messages échangés entre le moyen de traitement du noeud source (à gauche) et le
moyen de communication du noeud source (à droite de la colonne de gauche).
Dans la colonne de droite, sont représentés les messages échangés entre le moyen de traitement du noeud destinataire (à droite) et le moyen de
communication du noeud destinataire (à gauche de la colonne de droite).
Les six flèches 251 à 256 de la colonne centrale correspondent à un mode de communication connecté conforme à la présente invention, les flèches 257 et 258 correspondent à une transmission en mode non connecté avec synchronisation des deux moyens de traitement et la flèche 259 correspond à une communication en mode non connecté sans synchronisation
des deux moyens de traitement.
Dans la colonne centrale, les flèches 254, 257, 258 et 259 correspondent à des transferts de données sur le réseau, les autres flèches
correspondant à des messages organisant ces transferts.
En mode connecté, c'est-à-dire dans le cas du trafic connecté, le moyen de traitement du noeud source informe le moyen de communication du noeud source de l'ouverture d'une connexion en lui envoyant un message de requête de connexion ("connectreq") En conséquence, le moyen de communication du noeud source lance la phase d'initialisation ("set-up" en anglais). Cette phase comporte notamment l'émission d'un message d'initialisation 251 (message "set-up") par le moyen de communication du noeud source et à destination du moyen de communication du noeud destinataire (par l'intermédiaire, le cas échéant, du
moyen de communication de chaque noeud intermédiaire).
A réception du message de "set-up", le moyen de communication du noeud destinataire informe le moyen de traitement du noeud destinataire qu'il a reçu une demande d'ouverture de connexion, par l'intermédiaire d'un
message de demande d'ouverture de connexion "connect_incd'.
Si la demande est acceptée, le moyen de communication du noeud destinataire est informé par le moyen de traitement du noeud destinataire, par l'intermédiaire d'un message "connect_ans" (identifié en figure 6 par le nom "callRequest_ack" pour acceptation de requête d'appel ou de "callRequestnack", pour rejet de requête d'appel, selon le résultat de la demande d'ouverture de connexion, opérations 377 et 378 respectivement. Dans le premier cas, un message de connexion 252 ("connect") est émis par le moyen de communication du noeud destinataire vers le moyen de communication du
noeud source.
Le moyen de traitement du noeud source est alors informé du bon déroulement de l'ouverture de la connexion par un message de confirmation de connexion "connect_cfr", de la part du moyen de communication du noeud source. Le moyen de communication de chaque noeud du réseau est alors informé de l'établissement d'une nouvelle connexion par l'intermédiaire d'un message 253 de mise à jour de table de charge "LinkTabLoad" diffusé par le moyen de communication du noeud source. Ce message est aussi utilisé pour confirmer auprès des noeuds intermédiaires et du noeud destinataire le bon
déroulement de la phase d'établissement de la connexion.
Le transfert de données composant le trafic connecté associé à la connexion, du noeud source vers le noeud destinataire, peut alors avoir lieu. A cet effet, le moyen de traitement du noeud source et le moyen de communication du noeud source échangent des messages de demande d'émission d'un message de données "sendlsoDatareq" et de confirmation
d'émission du message de données "sendisoData_cfr'.
Le transfert des messages de données 254 est alors effectué après segmentation du flot de données en paquets de taille prédéfinie. Le moyen de communication du noeud destinataire reçoit les paquets de données qu'il confie au moyen de traitement du noeud destinataire, par l'intermédiaire du message de réception d'un message de données "sendlsoData_ind"), après
avoir restructuré le flot de données.
Lorsque les données à transmettre ont été transmises, le moyen de traitement du noeud source peut décider de la fermeture d'une connexion en transmettant un message de demande de fermeture de connexion
"releasereq" au moyen de communication du noeud source.
Le moyen de communication du noeud source émet alors: - un message de confirmation de relâchement "releasecfr" à destination du moyen de traitement du noeud source, - un message de relâchement "release" 255 à destination des éventuels noeuds intermédiaires et du noeud destinataire, et - un message 256 de mise à jour de table de charge "LinkTabFree"
à tous les noeuds du réseau.
Le message 256 est utilisé pour confirmer auprès des noeuds intermédiaires, des noeuds voisins et du noeud destinataire le bon déroulement de la phase de libération de la connexion. Au niveau du noeud destinataire, le moyen de communication informe le moyen de traitement de la fermeture de la connexion par l'intermédiaire d'un message de notification de fermeture de
connexion "releaseind".
Le transfert de données pour le trafic élastique, en mode non connecté avec synchronisation des moyens de traitement, se fait sans ouverture préalable d'un connexion, par la transmission du message d'émission de message "sendSyncData_req" par le moyen de traitement du noeud source vers le moyen de communication du noeud source. Ce moyen de communication effectue le transfert 257 des données après segmentation du flot de données en paquets de taille prédéfinie. Au niveau du noeud destinataire, la réception des données est effectuée par le moyen de communication, qui informe le moyen de traitement, et transmet le flot de données restructuré, par l'usage du message de réception de message "sendSyncData_ind". En réponse, le moyen de traitement du noeud destinataire émet, à destination du moyen de communication du noeud destinataire, un message de bonne réception "sendSyncData_ans", qui contient la réponse du moyen de traitement du noeud destinataire et provoque le transfert d'un message 258 entre le moyen de communication du noeud destinataire et le moyen de communication du noeud source. A réception de ce message 258, le moyen de communication du noeud source émet à destination du moyen de traitement du noeud source un message de confirmation de transmission "sendSyncData_cfr'. Le transfert de données pour le trafic élastique, en mode non connecté sans synchronisation des moyens de traitement, se fait sans ouverture préalable d'un connexion, par la transmission du message d'émission de message "sendAsyncData_req" par le moyen de traitement du noeud source vers le moyen de communication du noeud source. Ce moyen de communication effectue le transfert 259 des données après segmentation du flot de données en paquets de taille prédéfinie et émet à destination du moyen de traitement du noeud source un message de confirmation de transmission "sendAsyncData_cf?'. Au niveau du noeud destinataire, la réception des données est effectuée par le moyen de communication, qui informe le moyen de traitement et transmet le flot de données restructuré, par l'usage du
message de réception de message "sendAsyncData_ind".
Les figures 4 à 7 illustrent les procédures de gestion des
connexions selon l'invention.
En ce qui concerne le moyen de communication du noeud source, après avoir été dans un état d'initialisation 300 (figure 4), un message entrant "connectreq" est reçu au cours d'une opération 301, de la part du moyen de traitement du noeud source. Ce message comporte le service requis, dont la bande passante, et le mode de transmission. Le moyen de communication du noeud source effectue alors la sélection d'un chemin alloué à la connexion, le calcul des paramètres de transmission en fonction du service requis puis la mise à jour de la table de charge si un chemin est disponible (figure 13), au
cours d'une opération 302.
Ensuite, au cours d'un test 304, le moyen de communication du noeud source détermine si la bande passante nécessaire à la connexion envisagée est disponible sur le chemin sélectionné, ou non. Cette procédure de test 304 est connue sous le nom de " Contrôle d'Admission de Connexion "ou encore "CAC". Lorsque le résultat du test 304 est négatif, au cours d'une opération 303, le moyen de communication émet un message de refus d'ouverture (message "connect_cfr' négatif) de communication à destination du moyen de traitement du noeud source. Ce message de refus "connect_cf?' négatif a pour effet d'avertir l'application logicielle qui avait requis la
transmission de l'impossibilité d'effectuer cette transmission en mode connecté.
Ensuite, les ressources associées à la gestion de la connexion
sont libérées.
Lorsque le résultat du test 304 est positif, au cours d'une opération 305, le moyen de communication émet le message 251 "set-up" (figure 3) à destination du moyen de communication du noeud destinataire, par l'intermédiaire de chacun des dispositifs de communication des éventuels noeuds intermédiaires. Ce message 251 décrit la connexion à établir (voir figure 9). Ensuite, au cours d'une opération 306, un compteur d'horloge (en anglais "timer") "cncAckWait" est initialisé à une valeur qui correspond à un délai maximum accordé à l'établissement de la connexion demandée. Le moyen de communication se met alors dans un état d'attente de la réponse du
réseau quant à l'établissement de la connexion, état 307.
Dans cet état 307, trois événements différents peuvent se
produire, au cours d'opérations 308, 310 ou 311.
Lorsque, dans l'état 307, le message entrant est un message "cncAckWait", provenant du passage à zéro de la valeur du compteur de signaux d'horloge "cncAckWait" initialisé au cours de l'opération 306, opération 308, ou lorsque le message entrant est un message "release_back", provenant du noeud destinataire ou de l'un des éventuels noeuds intermédiaires, opération 310, I'opération 323 est effectuée, au cours de laquelle le moyen de traitement du noeud source est informé du rejet de la demande de connexion. A cet effet, le moyen de communication du noeud source émet un message "openCall_nack", correspondant à un message "connect_cfi" négatif, notifiant le
rejet de la connexion, à destination du moyen de traitement du noeud source.
A la suite de l'opération 323, au cours d'une opération 324, le moyen de communication du noeud source procède à la mise à jour des tables de charge associées à la connexion qui a été rejetée. Puis, au cours d'une opération 325, les ressources associées à la gestion de la connexion sont
libérées.
Enfin, lorsque, dans l'état 307, le message entrant est un message de connexion 252 "connecté, provenant du noeud destinataire, opération 311, le moyen de communication du noeud source effectue l'émission d'un message d'acquittement d'ouverture de connexion "openCallack", correspondant à un message "connect_cf?' positif, à destination du moyen de traitement du noeud source, opération 312, puis, au cours d'une opération 313,
diffuse un message 253 "LinkTabLoad" comportant notamment la description
du service requis, la bande passante utilisée ainsi que la description du chemin
correspondant à la connexion, en termes de liens. Ce message est diffusé à destination de tous les noeuds du réseau, ce qui a pour effet que chaque noeud du réseau met à jour ses tables de charge. La diffusion de ce message est effectuée en suivant un arbre de recouvrement du réseau, déterminé selon des
techniques connues (voir figure 8).
Le moyen de communication du noeud source se met alors dans I'état 314 au cours duquel il attend une évolution de la connexion et transmet toutes les données destinées à être transmises en mode connecté, sur la
connexion mise en place.
Deux messages peuvent alors entrer dans le moyen de
communication, au cours d'opérations 315 et 318.
Lorsque, dans l'état 314, le message entrant est un message de relâchement provenant d'un autre noeud du réseau "release_back", opération 315, le moyen de communication du noeud source émet un message de terminaison de communication "caliTerminate", "releaseind" figure 3, à destination du moyen de traitement du noeud source, opération 316, ce qui a
pour effet d'informer le moyen de traitement de la fermeture de la connexion.
Puis, le moyen de communication émet un message d'alarme "alarm_dcnBack", opération 317, à destination du moyen de traitement du noeud source, ce qui a pour effet de déclencher le traitement d'une alarme par ce moyen de traitement puisque la connexion a été interrompue de manière anormale. Puis, le moyen de communication diffuse à destination de tous les autres noeuds du réseau, un message de mise à jour de tables de charges
"LinkTabFree", comportant notamment une description du service requis et du
chemin correspondant à la connexion, en termes de liens, opération 320.
Le moyen de communication effectue alors une opération 321, identique à l'opération 324, puis une opération 322 au cours de laquelle les ressources associées à la gestion de la connexion sont détruites. Lorsque le message reçu, dans l'état 314, est un message de demande de fin de connexion (message "releasereq" provenant du moyen de traitement du noeud source et message "release_cf?", en réponse), opération 318, le moyen de communication émet un message de relâchement 255
"release", opération 319, puis effectue les opérations 320, 321 et 322.
En ce qui concerne chaque noeud intermédiaire (figure 5), après avoir été dans un état d'initialisation 300, un message entrant 251 "set-up" est reçu au cours d'une opération 331, de la part du noeud source (voir opération 305). Le service requis pour la connexion considérée est alors extrait de ce message 251 "set-up". Le moyen de communication du noeud intermédiaire effectue alors un calcul des paramètres de transmission, à partir du service requis, puis, si la charge est acceptable, une mise à jour de ses tables de
charge, au cours d'une opération 332, détaillée figure 14.
Ensuite, au cours d'un test 335, le moyen de communication du noeud intermédiaire détermine si la bande passante nécessaire à la connexion
envisagée est disponible sur le chemin sélectionné, ou non (voir test 304).
Lorsque le résultat du test 335 est négatif, au cours d'une opération 333, le moyen de communication du noeud intermédiaire émet un message de relâchement de connexion "release_back" à destination du noeud source (voir opération 310). Puis le moyen de communication du noeud intermédiaire libère les ressources associées à la gestion de la connexion
considérée, opération 334.
Lorsque le résultat du test 335 est positif, au cours d'une opération 336, le moyen de communication émet un message d'initialisation "set-up" 251 à destination du moyen de communication du noeud destinataire et de chacun des moyens de communication des éventuels noeuds intermédiaires. Ce message est émis après mise à jour du champ identifiant la position du noeud
dans le chemin, à partir de la description du chemin en termes de liens (voir
figure 9).
Ensuite, au cours d'une opération 337, le compteur d'horloge "cncAckWait" est initialisé à une valeur qui correspond à la durée maximale accordée à l'établissement de la connexion. Le moyen de communication se met alors dans l'état 338 d'attente de la réponse du réseau quant à
l'établissement de la connexion.
Dans cet état 338, cinq événements différents peuvent se
produire, au cours d'opérations 339, 341, 345, 346 et 347.
Lorsque le message entrant est un message "cncAckWait", provenant du passage à zéro de la valeur du compteur de signaux d'horloge "cncAckWait' initialisé au cours de l'opération 337, opération 339, le moyen de communication émet un message de relâchement "release", opération 340, à destination du noeud destinataire et des éventuels noeuds intermédiaires qui le séparent du noeud destinataire, et émet un message de relâchement "release_back", à destination du noeud source et des éventuels noeuds intermédiaires qui le séparent du noeud source, opération 342. Ensuite, au cours d'une opération 343, le moyen de communication du noeud intermédiaire considéré procède à la mise à jour des tables de charge associées à la connexion qui a été rejetée. Puis, au cours d'une opération 344, les ressources
associées à la gestion de la connexion sont libérées.
Lorsque le message entrant est un message "release" 255, provenant du noeud source ou d'un noeud intermédiaire entre le noeud source et le noeud intermédiaire considéré, opération 341, le moyen de communication
effectue les opérations 342 à 344.
Lorsque, dans l'état 338, le message entrant est un message 256 "LinkTabFree", opération 347, ce message est mémorisé et le moyen de
communication reste dans l'état 338.
* Lorsque, dans l'état 338, le message entrant est un message de demande de fin de connexion émis par un moyen de contrôle de noeud, dont la fonction est de prendre en compte les différents problèmes du réseau, opération 346, ce message est mémorisé et le moyen de communication reste
dans l'état 338.
Enfin, lorsque le message entrant est un message 253
"LinkTabLoacd"', comportant notamment la description du service requis, ainsi
que la description du chemin en termes de liens, en provenance du noeud
source (voir opération 313), opération 345, le moyen de communication se met dans un état 348 au cours duquel il attend une évolution de la connexion et transmet toutes les données destinées à être transmises en mode connecté,
sur la connexion mise en place.
On observe ici que le message 253 "LinkTabLoad" a, vis à vis d'un noeud intermédiaire (et du noeud destinataire), pour fonction de confirmer
l'établissement de la connexion, au cours de l'opération 345.
Dans l'état 348, trois événements peuvent se produire, au cours
d'opérations 349, 350 et 351.
Lorsque, dans l'état 348, le message entrant est un message 256 "LinkTabFree", opération 351, ce message est mémorisé et le moyen de
communication reste dans l'état 348.
Lorsque, dans l'état 348, le message entrant est un message 255
"release", I'opération 353 décrite plus loin est effectuée.
Enfin, lorsque, dans l'état 348, le message entrant est un message de demande de fin de connexion, émis par un moyen de contrôle de noeud, opération 350, le moyen de communication émet un message de
relâchement "release_back" à destination du noeud source, opération 352.
A la suite de l'une des opérations 349 ou 352, le moyen de communicationeffectue, au cours d'une opération 353, l'émission d'un message de relâchement "release" à destination du noeud destinataire et de chaque éventuel noeud intermédiaire qui sépare le noeud intermédiaire considéré et le
noeud destinataire.
Le moyen de communication effectue alors une opération 354 identique à l'opération 324, puis une opération 355 au cours de laquelle le compteur d'horloge "cncAckWait" est initialisé à une valeur qui correspond à la durée maximale accordée à la libération de la connexion. Le moyen de communication se met alors dans l'état 356 d'attente de la réponse du réseau
quant au relâchement de la connexion.
Dans l'état 356, deux messages peuvent survenir, au cours
d'opérations 357 et 358.
Lorsque le message entrant est un message 256 "LinkTabFree", opération 357, les ressources associées à la gestion de la connexion sont
libérées, opération 360.
Lorsque, dans l'état 356, le message entrant est un message "cncAckWait", provenant du passage à zéro de la valeur du compteur de signaux d'horloge "cncAckWair' initialisé au cours de l'opération 355, opération 358, le moyen de communication émet un message d'alarme "alarm_dcnTO", opération 359, à destination d'un moyen de contrôle de noeud, ce qui a pour effet de déclencher le traitement d'une alarme par ce moyen de traitement
puisque la connexion n'a pas été relâchée de manière normale.
A la suite de l'une des opérations 357 ou 359, les ressources
associées à la gestion de la connexion sont libérées, opération 360.
En ce qui concerne le noeud destinataire, (figure 6), après avoir été dans un état d'initialisation 370, un message entrant "setUp_end" est reçu au cours d'une opération 371, de la part du noeud source ou d'un noeud intermédiaire. Le moyen de communication du noeud destinataire effectue alors I'extraction du service requis, opération 371, puis le calcul des paramètres de transmission à partir du service requis, et, si la charge est acceptable, la mise à jour de la table de charge, au cours d'une opération 372 similaire à l'opération
332, décrite figure 14.
Ensuite, au cours d'un test 373, le moyen de communication du noeud destinataire détermine si la bande passante nécessaire à la connexion envisagée est disponible sur le chemin sélectionné, ou non (voir tests 304 et 335). Lorsque le résultat du test 373 est négatif, au cours d'une opération 333, le moyen de communication du noeud destinataire émet, à destination du noeud source et de tous les éventuels noeuds intermédiaires, un
message de relâchement "release_back", au cours d'une opération 380.
Ensuite, les ressources associées à la gestion de la connexion sont libérées,
opération 382.
Lorsque le résultat du test 373 est positif, le moyen de communication du noeud destinataire émet, à destination du moyen de traitement du noeud destinataire un message de demande de connexion
"connectincd', au cours d'une opération 374.
Puis, le moyen de communication se met dans un état 375
d'attente de la réponse du moyen de traitement du noeud destinataire.
Dans l'état 375, trois événements peuvent survenir, au cours d'opérations 376, 377 et 378. Lorsque le message entrant est un message de relâchement "release", provenant du noeud source ou de l'un des noeuds
intermédiaires, il est mémorisé au cours de l'opération 376.
Lorsque, dans l'état 375, le message entrant est une réponse défavorable "callReq_nack", correspondant à un message "connect_ans" négatif (figure 3), provenant du moyen de traitement du noeud destinataire, opération 378, au cours d'une opération 379, le moyen de communication du noeud destinataire procède à la mise à jour des tables de charge associées à la
connexion qui a été rejetée. Puis les opérations 380 et 382 sont effectuées.
Enfin, lorsque, dans l'état 375, le message entrant est un message favorable "callReqack", correspondant à un message "connect_ans" positif (figure 3), en provenance du moyen de traitement du noeud destinataire, opération 377, le moyen de communication émet un message 252 "connect', directement vers le noeud source, par mise en oeuvre du moyen de routage, au cours d'une opération 381. Ensuite, au cours d'une opération 383, le compteur d'horloge "cncAckWait' est initialisé à une valeur qui correspond à un délai maximum accordé à l'établissement de la connexion demandée. Le moyen de communication se met alors dans l'état d'attente de la réponse du réseau quant
à l'établissement de la connexion, état 384.
Dans cet état 384, cinq événements peuvent survenir au cours d'opérations 385, 386, 387, 389 et 390. Lorsque le message entrant est un message de relâchement "release", provenant du noeud source ou de l'un des noeuds intermédiaires, il
est mémorisé au cours de l'opération 385.
Lorsque, dans l'état 384, le message entrant est un message de mise à jour de table de charge 256 "LinkTabFree", provenant du noeud source,
il est mémorisé au cours de l'opération 389.
Lorsque, dans l'état 384, le message entrant est un message de demande de fin de connexion provenant du moyen de traitement ou d'un
moyen de contrôle de noeud, il est mémorisé au cours de l'opération 386.
Lorsque, dans l'état 384, le message entrant est un message "cncAckWait', provenant du passage à zéro de la valeur du compteur de signaux d'horloge "cncAckWait' initialisé au cours de l'opération 383, opération 390, le moyen de communication émet un message de relâchement de connexion "releaseback", opération 391, à destination des noeuds
intermédiaires et du noeud source.
Ensuite, au cours d'une opération 392, le moyen de communication du noeud destinataire procède à la mise à jour des tables de charge associées à la connexion qui a été rejetée. Puis, au cours d'une opération 393, les ressources associées à la gestion de la connexion sont
libérées.
Enfin, lorsque, dans l'état 384, le message entrant est un
message 253 "LinkTabLoacd"', message comportant notamment la description
du service requis ainsi que la description du chemin en terme de liens
(message ayant pour fonction de confirmer l'établissement de la connexion), opération 387, le moyen de communication du noeud destinataire se met dans
un état 388 d'attente d'évolution de la connexion.
On observe ici que le message 253 "LinkTabLoacd"' a, vis à vis d'un noeud intermédiaire, pour fonction de confirmer l'établissement de la connexion. Dans l'état 388, trois événements peuvent survenir, au cours
d'opérations 394, 396 et 397.
Lorsque, dans l'état 388, le message entrant est un message de mise à jour de table de charge 256 "LinkTabFree", provenant du noeud source,
il est mémorisé au cours de l'opération 396.
Lorsque, dans l'état 388, le message entrant est un message de relâchement 255 "release", opération 397, le moyen de communication effectue la notification "carlTerminate", correspondant à un message "release_ind' (figure 3), de la rupture de la connexion au moyen de traitement du noeud destinataire, opération 398. Ensuite, I'opération 399 décrite plus loin est effectuée. Enfin, lorsque, dans l'état 388, le message entrant est un message de demande de fin de connexion émis par un moyen de contrôle de noeud, opération 394, le moyen de communication émet un message de relâchement "releaseback" à destination du noeud source et des noeuds
intermédiaires, opération 395.
A la suite de l'une des opérations 395 ou 398, le moyen de communication effectue une opération 399 identique à l'opération 324, puis une opération 400 au cours de laquelle le compteur d'horloge "cncAckWait' est initialisé à une valeur qui correspond à la durée maximale accordée à la libération de la connexion. Le moyen de communication se met alors dans l'état 401 d'attente de la réponse du réseau quant au relâchement de la connexion
de la même façon que pour les noeuds intermédiaires.
Dans l'état 401, deux messages peuvent survenir, au cours
d'opérations 402 et 403.
Lorsque le message entrant est un message 256 "LinkTabFree", opération 402, les ressources associées à la gestion de la connexion sont
libérées, opération 405.
Lorsque, dans l'état 401, le message entrant est un message "cncAckWait", provenant du passage à zéro de la valeur du compteur de signaux d'horloge "cncAckWait" initialisé au cours de l'opération 400, opération 403, le moyen de communication émet un message d'alarme "alarm_dcnTO", opération 404, à destination du moyen de contrôle de noeud, ce qui a pour effet de déclencher le traitement d'une alarme par ce moyen de traitement puisque la
connexion n'a pas été relâchée de manière normale.
A la suite de l'une des opérations 402 ou 404, les ressources
associées à la gestion de la connexion sont libérées, opération 405.
En ce qui concerne chaque noeud voisin (figure 7), après avoir été dans un état d'initialisation 411, le moyen de communication du noeud voisin
reçoit un message 253 "LinkTabLoad", comprenant notamment la description
du service requis ainsi que la description du chemin en termes de liens,
opération 412. Ensuite, au cours d'une opération 413, le moyen de communication du noeud voisin effectue le calcul des paramètres de transmission à partir du service requis, puis, indépendamment de la charge, la
mise à jour de la table de charge.
Ensuite, dans l'état 414, le moyen de communication du noeud voisin attend l'évolution de la connexion. Ensuite, au cours d'une opération 415, il reçoit un message 256 "LinkTabFree" concernant la connexion, message
comprenant notamment la description du service requis ainsi que la description
du chemin en termes de liens.
Ensuite, au cours d'une opération 416, le moyen de communication du noeud voisin procède à la mise à jour des tables de charge associées à la connexion qui a été libérée. Puis, au cours d'une opération 417,
les ressources associées à la gestion de la connexion sont libérées.
On observe ici que le message 253 "LinkTabLoad" a, vis à vis
d'un noeud voisin, pour fonction d'informer sur l'établissement de la connexion.
Ainsi la procédure (figure 7) correspond plutôt à une notification
qu'à un contrôle d'admission.
En figure 8 sont représentés, dans un réseau à commutation de paquets 800: - un noeud source 801, - un noeud destinataire 802, - deux noeuds intermédiaires 803 et 804, - cinq noeuds voisins 805 à 809, et
- les liens entre ces noeuds.
Le long de ces liens sont représentés des messages transitant
successivement sur le réseau ainsi constitué, sous forme de flèches.
On observe que le message 251 "set-up" circule: - du noeud source 801 au noeud intermédiaire 803, puis - du noeud intermédiaire 803 au noeud intermédiaire 804, puis
- du noeud intermédiaire 804 au noeud destinataire 802.
En revanche, le message 252 "connect" retourne directement du noeud destinataire 802 au noeud source 801, sans intervention des noeuds intermédiaires 803 ou 804. Ce message 252 peut, en fait, passer par n'importe quel chemin entre le noeud destinataire et le noeud source, par exemple par un
chemin passant par le noeud voisin 808.
Enfin, les messages de mise à jour de table de charge 253 "LinkTabLoacd"' et 256 "LinkTabFree" sont diffusés à tous les noeuds du réseau,
en suivant un arbre de recouvrement.
Préférentiellement, toutes les extrémités, ou "feuilles" de l'arbre de recouvrement se trouvent sur le chemin de la connexion. Ainsi, lorsqu'il y a une panne dans le réseau, les noeuds du chemin, noeuds intermédiaires ou noeud destinataire, qui, comme on l'a vu dans les organigrammes des figures 5 et 6, attendent le message "LinkTabLoad" 253, respectivement dans les états 345 et 387, peuvent détecter la panne lorsque l'un des noeuds voisins ne transmet pas
ce message.
En figure 9, on observe, sur quatre lignes successives, les structures des messages 251 "set-up", 255 "release", de mise à jour de table de
charge, 253 "LinkTabLoad" ou 256 "LinkTabFree" et 252 "connect'.
Le message 251 "set-up" comporte successivement les champs: - 901, d'identificationdu type de message ("set-up", "LinkTabLoad", "LinkTabFree", "Connect" ou "Release", voir figure 3), - 902, d'identification de connexion,
- 903, de description de trafic, représentatif du service requis,
- 904, de données propres au moyen de communication permettant notamment d'identifier les moyens de traitement des noeuds source et destinataire, 905, de nombre de liens qui utilisent le chemin associé à la connexion, 906, de rang du lien sur lequel transite le message, sur le chemin associé à la connexion, - 907, des descripteurs de liens successifs du chemin correspondant à la connexion souhaitée, et
- 908, de données de protocole.
Le message 255 "release" comporte successivement les champs: - 901, d'identification du type de message ("set-up", "LinkTabLoad", "LinkTabFree", "Connect' ou "Release", voir figure 3), - 902, d'identification de connexion, - 909, de cause de la demande de relâchement, - 905, de nombre de liens qui utilisent le chemin associé à la connexion, - 906, de rang du lien sur lequel transite le message, sur le chemin associé à la connexion, - 907, des descripteurs de liens successifs du chemin correspondant à la connexion souhaitée, et
- 908, de données de protocole.
Un message de mise à jour de table de charge 253 ou 256 comporte successivement les champs: - 901, d'identification du type de message ("set-up", "LinkTabLoad", "LinkTabFree", "Connect" ou "Release", voir figure 3), - 902, d'identification de connexion,
- 903, de description de trafic, représentatif du service requis,
- 910, d'information relative à l'arbre de recouvrement mis en oeuvre, 905, de nombre de liens qui utilisent le chemin associé à la connexion, 906, de rang du lien sur lequel transite le message, sur le chemin associé à la connexion, - 907, des descripteurs de liens successifs du chemin correspondant à la connexion souhaitée, et
- 908, de données de protocole.
Le message 252 "connect' comporte successivement les champs: - 901, d'identification du type de message ("set-up", "LinkTabLoad", "LinkTabFree", "Connect" ou "Release", voir figure 3), - 902, d'identification de connexion, - 911, de données de protocole, pouvant être utilisées par le
moyen de traitement du noeud source.
- 908, de données de protocole.
En figure 10, on observe des descripteurs de liens 1001 à 1007 disposés côte à côte et des descripteurs de chemins 1011 à 1015 disposés sur
des lignes successives.
Chaque descripteur de chemin est une structure de données pour
la description d'un chemin qui comporte, en particulier la référence des liens
impliqués dans la description de ce chemin et la référence de chaque
connexion associée à ce chemin. Chaque descripteur de chemin sortant (101 1, 1012 ou 1013) concerne un chemin créé par le moyen de routage du moyen de communication. Les chemins qui ne partent pas du noeud considéré sont dits "temporaires" et permettent de connaître les charges des liens des chemins sortants. Les chemins temporaires sont créés par le moyen de contrôle de charge qui gère tous les chemins (opérations 1307, 1407 et 1504, figures 13 à ). Dans le mode de réalisation décrit et représenté, les chemins 1011, 1012 et 1013 sont des chemins sortants (en traits gras) et les chemins 1014 et 1015 sont des chemins temporaires (en traits fins). Les chemins 1011, 1012 et 1013 décrivent la table de routage et sont utilisés par le noeud
considéré pour établir des chemins vers n'importe quel noeud destinataire.
Chaque descripteur de lien 1001 à 1007 comporte, en particulier, la référence de chaque chemin qui traverse le lien considéré, identifié par un rectangle, à l'intersection d'une ligne verticale partant du descripteur de lien considéré et d'une ligne horizontale partant du descripteur de chemin considéré. Les liens 1001 à 1004 font partie d'au moins l'un des chemins sortants, et sont représentés en traits gras. Chaque intersection de deux lignes marquée par un point représente une référence en mémoire: - les lignes externes (en haut et/ou à gauche des rectangles) repèrent les références conservées avec chaque lien: ces références concernent chaque chemin qui traverse ledit lien, et - les lignes internes (en bas et/ou à droite des rectangles) repèrent les références conservées avec chaque chemin: ces références concernent
chaque lien traversé par ledit chemin.
La mise à jour de la table de charge effectuée par le moyen de contrôle de charge, comporte les étapes suivantes: - pour l'établissement d'une connexion: * mise à jour de la charge de tous les liens référencés par le chemin (ajout de charge), et pour chaque lien, mise à jour de la charge de chaque chemin référencé pour ce lien -pour le retrait d'une connexion: À mise à jour de la charge de tous les liens référencés par le chemin (déduction de charge), et À pour chaque lien, mise à jour de la charge de chaque chemin référencé pour ce lien - pour l'ajout d'un chemin: ò soit par le moyen de routage, lors de l'établissement de la table de routage du noeud considéré (il s'agit alors d'un chemin sortant), ou lors de la mise à jour de la table de routage, soit par le moyen de contrôle de charge, lorsque le chemin associé à une nouvelle connexion lors de l'ajout de charge n'est pas déjà spécifié (il s'agit alors de chemin temporaire); pour la suppression d'un chemin: par retrait d'un chemin temporaire lorsqu'il n'est plus traversé par aucune connexion, après retrait d'une connexion, soit lorsque la liste de connexions référencée par ce chemin est vide, - pour la transformation d'un chemin sortant en chemin temporaire lorsqu'il ne fait plus partie de la table de routage (à la suite d'une opération de mise à jour de la table de routage); et - pour la suppression d'un lien: par retrait d'un lien lorsqu'il n'est plus traversé par aucun chemin, ou lorsque la liste des chemins référencés par
ledit lien est vide.
Dans la table de charge, à chaque lien est associée une information de charge et à chaque chemin est associée une information représentative du lien le moins disponible. Ainsi, la bande passante disponible
du lien le moins disponible est aussi la bande passante disponible du chemin.
On observe que c'est en utilisant cette information de disponibilité de bande passante de chemin, que le moyen de communication effectue le choix du chemin en choisissant le chemin le plus disponible. Pour chaque information à transmettre en mode non connecté, la disponibilité de chaque chemin du réseau est ainsi estimée, en fonction du trafic en mode connecté. La charge d'un chemin est définie à partir de son lien le moins disponible. Il est caractérisé par la bande passante totale qu'il autorise et la part maximale de la bande passante associée au trafic en mode connecté. Etant donnée la charge effective du trafic en mode connecté, chaque moyen de communication définit la part associée au trafic en mode non connecté, comme égale à la bande passante totale à laquelle on a soustrait la part associée au
mode connecté.
Le moyen de communication alloue à l'ensemble des transmissions en mode non connecté qu'il a à effectuer, tout ou partie de la bande passante (préférentiellement une partie, pour éviter des problèmes de congestion du réseau). Cette part est équitablement répartie entre toutes les transmissions en mode non connecté et se trouve donc dynamiquement mise à jour au début et à la fin de chaque transmission en mode connecté (lorsque la
charge du trafic en mode connecté varie).
L'attribution d'une part est effectuée en définissant un plage de valeurs du nombre de paquets à émettre entre deux valeurs extrêmes (specCPmin 1114 et specCPmax 1115 (figure 11). Cette opération d'attribution de bande passante est effectuée avant l'émission de l'information
257 ou 259 (figure 3).
En outre, on considère qu'un chemin qui supporte plus d'un nombre prédéterminé de transmission sortante en mode non connecté n'est
pas disponible pour une transmission en mode non connecté supplémentaire.
Les événements qui peuvent influencer l'attribution de bande passante à une transmission en mode connecté sont de deux types: - ceux qui concernent le mode connecté, I'établissement ou la fermeture d'une connexion, et qui influent sur la bande passante qui lui est réservée, et, par conséquent, sur le nombre de paquets à émettre en mode non connecté mais aussi sur la taille de ces paquets, et - ceux qui concernent le mode non connecté, le début ou la fin d'une transmission, et qui influent sur le nombre de paquets à émettre en mode non connecté. Pour la gestion de la table de charge illustrée en figure 10, la charge d'un chemin est déterminée par la charge du lien le moins disponible, en prenant en compte, pour la charge d'un lien, la somme des charges des
chemins qui le traversent.
Les chemins sortants utilisés sont établis par un moyen de
routage de type connu.
On observe ici que chaque noeud du réseau contrôle le flux qu'il génère et que l'information permettant de contrôler ces flux est établie à partir de la table de charge qui est partagée entre les différents noeuds, chaque noeud conservant cette information sous forme d'un tableau tel que celui illustré
en figure 11.
Les niveaux de priorité des messages sont établis par le moyen
de traitement à partir du service requis.
En figure 11, on observe un tableau 1100, comportant trois lignes 1101, 1102 et 1103, chacune des lignes comportant des spécifications de
canaux virtuels 1105 à 1110.
On rappelle ici que chaque canal virtuel est une entité logique associée à une communication entre deux applications mises en oeuvre par
deux moyens de traitements associés à deux moyens de communication.
Dans le tableau de la figure 11, on a choisi de représenter deux
canaux virtuels pour chaque niveau de priorité, pour des raisons de clarté.
Cependant, pour chaque niveau de priorité, le nombre de canaux virtuels peut
varier entre zéro à un nombre prédéterminé.
Chacune de ces spécifications comporte: - une information représentative de la taille "specL" 1111 des paquets associés au canal; - une information représentative du nombre de paquets à émettre "spec_CF"' 1112 durant l'intervalle de temps primaire considéré; - une information représentative de la durée "spec CT" 1113 de l'intervalle de temps primaire considéré; une information représentative du niveau de priorité (haut, moyen ou bas) "specprio" 1114 associé au canal; - une information "dynCP' 1117 représentative du nombre de paquets réellement émis sur le canal virtuel, pendant l'intervalle de temps primaire considéré; - une information "dyn_CT' 1118 représentative du nombre d'intervalles de temps secondaires écoulés pendant l'intervalle de temps primaire considéré; et - une information "VC_state" 1119 représentative de l'état dans lequel se trouve le canal virtuel, "libre", "actif' ou "endormi' (voir figure 12); et - une information "références" 1120 représentative des positions
(ou références), en mémoire, des données utilisateur à transmettre.
En outre, les spécifications du niveau de priorité basse comportent: - une information "specCPmin" 1115 représentative de la valeur minimale du nombre de paquets à émettre "spec_CF" 1112 - une information "spec_CPmax" 1116 représentative de la valeur maximale du nombre de paquets à émettre "spec_CF" 1112, ceci afin de permettre de diminuer la valeur de "spec_ CP' 1112 au cours de l'opération 1221 ou de l'augmenter au cours de l'opération 1215, dans la limite de ces bornes specCPmin 1115 et
specCPmax 1116.
Enfin, chaque ligne, ou niveau de priorité, est affectée d'une information "prio_state" 1120 représentative de l'état dans lequel se trouve I'ensemble des canaux virtuels du niveau de priorité considéré: lorsqu'au niveau de priorité considéré ne se trouve aucun canal, le niveau de priorité est "libre", lorsque tous les canaux du niveau de priorité sont dans un état "endormi', le niveau de priorité est lui-même dans un état "endormi', et dans les
autres cas, le niveau de priorité est "actif'.
La table de spécifications et de priorités 1100 est constituée en plaçant: - en première ligne 1101 (niveau de priorité "haut") tous les canaux virtuels affectés à des transmissions en mode connecté, ou "temps réel déterministe" (en anglais "predictive real time"); - en deuxième ligne 1102 (niveau de priorité "moyen") tous les canaux virtuels affectés à des transmissions en mode connecté temps réel garanti (connu sous le nom de temps réel garanti, ou, en anglais, "guaranted real time"); - en troisième ligne 1103 (niveau de priorité "haut") tous les canaux virtuels affectés à des transmissions en mode non connecté (connu
sous les noms de "asynchrone" et "élastique", ou, en anglais "elastic").
Ainsi, tous les noeuds disposent d'une table de priorité concernant le trafic qu'il peut générer, et chacun s'occupe des messages dont il est la source (principe connu sous le nom de "outgoing trafic" en anglais, qui signifie
"trafic sortant").
On observe ici que les paramètres de transmission sont déterminés par le moyen de contrôle de charge à partir du contenu de la table de charge. Par conséquent, les paramètres de transmission associés aux canaux virtuels de haute et moyenne priorité 1101 et 1102 sont calculés à partir d'une connaissance, a priori, sur tout le trafic connecté alors que les paramètres de transmission associés aux canaux virtuels de faible priorité 1103 sont estimés à partir d'une connaissance limitée au trafic non-connecté sortant
du noeud considéré.
La figure 12 représente un organigramme de fonctionnement d'émission en modes connecté et non connecté d'un moyen de communication tel qu'illustré en figure 2. Cet organigramme est mis en oeuvre par l'unité
centrale 206 (figure 2).
Le principe du fonctionnement utilisé est que l'ordre d'émission des paquets est basé sur le remplissage d'un intervalle de temps primaire ITP,
comprenant des intervalles de temps secondaires IT-S.
A la suite de l'opération d'initialisation 1201 par remise à zéro de toutes les variables, un test 1202 détermine si un intervalle de temps secondaire s'est écoulé, le début d'un intervalle de temps secondaire étant déterminé à partir de l'horloge temps réel 235. Lorsque le résultat du test 1202 est positif, au cours d'une opération 1203, l'unité centrale 206 se place en début
de la table de spécifications et de priorités (figure 11).
Ensuite, au cours d'une opération 1204, I'information "dynCT"' 1118 du canal virtuel considéré est décrémentée. Puis, au cours d'un test 1205, l'unité centrale 206 détermine si la valeur de l'information "dynCT"' 1118 du canal virtuel considéré est égale à zéro, ou non. Lorsque le résultat du test 1205 est positif, c'est-à-dire à la fin d'un intervalle de temps primaire, au cours d'un test 1220, I'unité centrale 206 détermine si la valeur de l'information "dynCP" 1117 est égale à zéro, ou non. Le test 1220 correspond donc à
chaque début d'un nouvel intervalle de temps primaire.
Lorsque le résultat du test 1220 est négatif, au cours d'une opération 1221, l'unité centrale 206 gère les priorités de la manière suivante: -pour le trafic déterministe, priorité haute, les paquets non transmis durant l'intervalle de temps requis, dont le nombre est égale à la valeur de valeur "dynCP" 1117, sont supprimés (perte de paquets) puis, la valeur "dynCPF" 1117 est mise à zéro, et - pour le trafic garanti, priorité moyenne, les paquets non transmis durant l'intervalle de temps sont conservés et "dynCPF" 1117 conserve sa valeur, et - pour le trafic élastique, priorité basse, la bande passante est réduite, par décrémentation de la valeur "specCPF" 1112 dans la limite des
bornes autorisées.
A la suite de l'opération 1221 ou lorsque le résultat du test 1220
est positif, une opération 1206 est effectuée.
Au cours de l'opération 1206, les spécifications et paramètres de transmission sont mis à jour (voir figure 11): - les informations 1111 à 1113 et 1115 à 1116 sont mises à jour à la fin de chaque intervalle de temps primaire, en fonction des changements d'état de la table de charge déterminé par le moyen de contrôle de charge, - la valeur de l'information "dyn_CP"' 1117 est incrémentée de la valeur de l'information "specCPF" 1112, - la valeur de l'information "dynCT"' 1118 est incrémentée de la valeur de l'information "specCT" 1113, - la valeur de l'information "VCstate" 1119 passe de l'état
"endormi' à l'état "actif'.
A la suite de l'opération 1206 ou lorsque le résultat du test 1205 est négatif, une opération 1207 consiste, pour l'unité centrale 206, à considérer
le canal virtuel suivant dans la table de spécifications et de priorités.
Ensuite, le test 1208 détermine si la fin de la table de spécifications et de priorités a été dépassée, ou non. Lorsque le résultat du test 1208 est négatif, les opérations 1204 à 1207 sont réitérées. Lorsque le résultat du test 1208 est positif, c'est-à-dire lorsqu'un intervalle de temps secondaire est achevé, un test 1209 détermine si la liste des canaux virtuels de niveau de priorité "haut" possède une information d'état "priostate" 1120 à la valeur "actif' ou non. Lorsque le résultat du test 1209 est positif, au cours d'une opération 1210, I'unité centrale 206 procède à l'émission du paquet dont le remplissage est effectué à partir du champ référence 1120, qui indique la position mémoire des prochaines données à émettre, en mode connecté temps réel déterministe et procède à la mise à jour des spécifications du canal virtuel permettant l'émission du paquet considéré: - l'information "dyn_CF" 1117 est décrémentée, - si l'information "dyn_CP' 1117 est égale à zéro, la valeur de l'information "VC_state" 1119 prend la valeur "endormi' et le prochain canal virtuel du même niveau de priorité est considéré et, s'il n'y a aucun autre canal virtuel de même niveau de priorité, le niveau de priorité voit son information
"priostate" 1120 prendre la valeur "endormi'.
L'émission du paquet ne se termine que lorsque le prochain noeud intermédiaire a acquitté le contrôle de flux qu'il a opéré sur les données dudit paquet, tel que cela est décrit dans la norme IEEE-1355 et implémenté par les
composants ST-C101 213 ou 216 et ST-C104 209.
On remarque ainsi que les conflits d'accès aux ressources de transmission (les liens de communications) sont détectés par le protocole de
transmission de paquets, par exemple conforme à la norme IEEE-1355.
L'invention permet donc de limiter les effets de ces conflits d'accès pour équitablement répartir l'accès aux ressources entre les différents noeuds du réseau, tout en garantissant une qualité de service spécifiée par le service requis. Lorsque le résultat du test 1209 est négatif, un test 1211 détermine si la liste des canaux virtuels de niveau de priorité "moyen" possède une information d'état "priostate" 1120 à la valeur "actif' ou non. Lorsque le résultat du test 1211 est positif, au cours d'une opération 1212, l'unité centrale 206 procède à l'émission d'un paquet en mode connecté temps réel garanti et procède à la mise à jour des spécifications du canal virtuel permettant l'émission du paquet considéré: - I'information "dynCP'F" 1117 est décrémentée, - si l'information "dyn_CFP' 1117 est égale à zéro, la valeur de l'information "VCstate" 1119 prend la valeur "endormi' et le prochain canal virtuel du même niveau de priorité est considéré et, s'il n'y a aucun autre canal virtuel de même niveau de priorité, le niveau de priorité voit son information
"priostate" 1 1 20 prendre la valeur "endormi'.
Lorsque le résultat du test 1211 est négatif, un test 1213 détermine si la liste des canaux virtuels de niveau de priorité "bas" possède une information d'état "prio_ state" 1120 à la valeur "actif' ou non. Lorsque le résultat du test 1213 est positif, au cours d'une opération 1214, I'unité centrale 206 procède à l'émission d'un paquet en mode non connecté et procède à la mise à jour des spécifications du canal virtuel permettant l'émission du paquet considére: - l'information "dynrCP" 1117 est décrémentée, - si l'information "dyn_CP'" 1117 est égale à zéro, la valeur de lI'information "VO_state" 1119 prend la valeur "endormi' et le prochain canal virtuel du même niveau de priorité est considéré et, s'il n'y a aucun autre canal virtuel de même niveau de priorité, le niveau de priorité voit son information
"priostate" 1120 prendre la valeur "endormi'.
Lorsque le résultat du test 1213 est négatif, au cours d'une opération 1215, l'unité centrale procède à l'analyse de la charge effective du réseau. A cet effet, l'unité centrale 206 comptabilise les périodes d'inactivité du moyen de communication, pour ajuster le nombre de paquets à émettre par canal virtuel, pour le trafic de priorité basse (c'est-à-dire en mode non connecté). En fonction du nombre d'intervalles de temps secondaires non utilisés pour la transmission effective de paquets, la bande passante est accrue, par incrémentation de la valeur "specCP" 1112 dans la limite des bornes autorisées. Puis, le moyen de communication cesse ses émissions jusqu'à ce
que le résultat du test 1202 devienne positif.
L'allocation ou la libération d'un canal virtuel est effectuée par manipulation: - des listes 1101 et 1102, lors de l'exécution des différentes
étapes de gestion d'une connexion illustrée en figure 4.
- de la liste 1103, lors de la réception d'un message "SendSyncDatareq" ou "SendAsyncData_cf?', par le moyen de communication, émis par le moyen de traitement, jusqu'à transmission
complète du message.
Ainsi, le moyen de contrôle de charge tient compte de la charge effective sur le réseau pour répartir les droits d'accès entre les différents
niveaux de priorité.
La figure 13 représente un organigramme de détermination, par le noeud source, de disponibilité de chemin pour l'établissement d'une connexion,
ce qui correspond, en figure 4, à l'opération 302.
Le moyen de communication prend en compte la description du
service requis établi par l'application ou le périphérique qui émet le message,
au cours d'une opération 1302.
Puis, le moyen de communication effectue le choix du canal virtuel et du chemin le plus disponible, au cours de l'opération 1304, en faisant usage
de la table de routage.
Au cours d'un test 1305, le moyen de communication du noeud source détermine si un chemin a été choisi au cours de l'opération 1304 ou non. Lorsque le résultat du test 1305 est négatif, le moyen de communication revendique l'arrêt de la procédure de mise en place de la connexion, au cours d'une opération 1306. Lorsque le résultat du test 1305 est positif, le moyen de communication effectue le calcul des paramètres de transmission, en particulier de la bande passante, de la taille des paquets transmis, des taux (fréquences d'émission) de paquets et de priorité de la communication correspondant au champ 1111 à 1113 illustrés en figure 11, en
faisant usage de la table de charge, au cours d'une opération 1303.
Puis, au cours d'une opération 1307, le moyen de communication: - alloue un canal virtuel en spécifiant les paramètres de transmission précédemment calculés, et - fait varier la taille des paquets avec la charge du chemin ainsi que le taux de paquets sur ledit chemin, et - met à jour sa table de charge par l'intermédiaire du moyen de
contrôle de charge.
Ensuite, au cours d'une opération 1308, il revendique la poursuite de la mise en place de la connexion
L'opération 302 est alors terminée.
La figure 14 représente un organigramme de détermination, par un noeud intermédiaire ou le noeud destinataire, de disponibilité de chemin pour l'établissement d'une connexion, ce qui correspond, en figures 5 et 6, aux
opérations 332 et 372.
Le moyen de communication obtient, d'abord, la description du
chemin et du service requis associés à la nouvelle connexion, en lisant le message 251 "set-up" provenant du noeud source (opération 305), au cours
d'une opération 1402.
Puis, le moyen de communication vérifie la disponibilité du chemin en fonction du service requis, au cours de l'opération 1404, en faisant usage de
la table de routage.
Au cours d'un test 1405, le moyen de communication du noeud considéré détermine si le chemin est disponible au cours de l'opération 1404 ou non. Lorsque le résultat du test 1405 est négatif, le moyen de communication revendique la procédure de mise en place de la connexion, au cours d'une opération 1406. Lorsque le résultat du test 1405 est positif, le moyen de communication effectue le calcul des paramètres de transmission, en particulier de la bande passante, de la taille des paquets transmis, des taux (fréquence d'émission) de paquet et de priorité de la communication, en faisant
usage de la table de charge, au cours d'une opération 1403.
Puis, au cours d'une opération 1407, le moyen de communication met à jour sa table de charge par l'intermédiaire du moyen de contrôle de charge, ce qui revient à réserver les ressources nécessaires à la connexion envisagée, puis, au cours d'une opération 1408, il poursuit la mise en place de la connexion. A la fin de l'une des opérations 1406 ou 1408, l'opération 334 est terminée. La mise à jour de la table de charge s'accompagne d'une mise à jour des paramètres de transmissions associés aux canaux virtuels existants représentatifs du trafic sortant pour le noeud considéré, à travers la valeur des champs 1111 à 1113 pour le trafic connecté et 1111, 1113, 1115, 1116 pour le
trafic non connecté.
La figure 15 représente un organigramme de détermination, par un noeud voisin, de disponibilité de chemin pour l'établissement d'une connexion, ce qui correspond, en figure 7, aux opérations 413.
Le moyen de communication obtient, d'abord, la description du
chemin et du service requis associés à la nouvelle connexion, en lisant le message 253 "LinkTabLoad" provenant du noeud source (opération 313), au
cours d'une opération 1502.
Ensuite, le moyen de communication effectue le choix des paramètres de transmission, en particulier de la bande passante, de la taille des paquets transmis, des taux de paquet et de priorité de la communication, en faisant usage de la table de charge, au cours d'une opération 1503. Puis, au cours d'une opération 1504, le moyen de communication met à jour sa table de charge. A la fin de l'opération 1504, le fonctionnement de mise en place de la
connexion, par le noeud voisin, est terminé.

Claims (63)

REVENDICATIONS
1. Procédé de communication sur un réseau (800) comportant des dispositifs de communication (801 à 809), chaque dispositif de communication étant adapté à déterminer, pour chaque information qu'il a à transmettre, le chemin à lui faire suivre sur le réseau, et un mode de transmission, connecté ou non, caractérisé en ce qu'il comporte: - pour chaque dispositif de communication qui doit effectuer une transmission en mode connecté, une opération d'information (313) au cours de laquelle ledit dispositif de communication diffuse, à destination de tous les autres dispositifs de communication du réseau, une information (253) représentative de la bande passante nécessaire pour ladite transmission en mode connecté, et - une opération d'attribution de bande passante (1221), au cours de laquelle on attribue, d'une part, aux transmissions en mode connecté, la bande passante qui leur est nécessaire et, d'autre part, tout ou partie de la bande
passante disponible à chaque transmission à effectuer en mode non connecté.
2. Procédé de communication selon la revendication 1, caractérisé en ce qu'il comporte, pour un établissement de connexion: - effectuée par le dispositif de communication source (801) destiné à transmettre de l'information sur ledit chemin, une opération de transmission (305), à destination de chaque dispositif de communication placé sur ledit chemin, appelé "intermédiaire" (803, 804), d'une information (251) représentative de la bande passante nécessaire pour ladite connexion, et - effectuée par chaque dispositif de communication intermédiaire sur ledit chemin, une opération de détermination de disponibilité (1402, 1404) du lien menant au dispositif de communication suivant sur ledit chemin et, en cas d'indisponibilité, une opération de transmission (333) à destination du dispositif de communication source, d'une information représentative de l'indisponibilité dudit
chemin.
3. Procédé de communication selon l'une quelconque des
revendications 1 ou 2, caractérisé en ce qu'il comporte, pour chaque transmission
d'information, une opération de contrôle de flux effectuée par chacun des dispositifs de communication intermédiaires du chemin suivi par ladite information. 4. Procédé de communication selon la revendication 3, caractérisé en ce que l'opération de contrôle de flux effectuée par chaque dispositif de
communication intermédiaire est effectuée conformément à la norme IEEE 1355.
5. Procédé de communication selon l'une quelconque des
revendications 1 à 4, caractérisé en ce qu'il comporte:
- pour chaque dispositif de communication du réseau, à la suite de chaque opération d'information, une opération de détermination de la bande passante (1303, 1403, 1503) disponible sur chaque lien, en prenant en compte esdites informations, et - pour chaque dispositif de communication dit "source" qui doit effectuer une transmission en mode non connecté à destination d'un dispositif de communication destinataire: * une opération de détermination de disponibilité de chemin pour une transmission en mode non connecté, au cours de laquelle on détermine si au moins une chemin allant dudit dispositif de communication source audit dispositif de communication destinataire est au moins partiellement disponible pour ladite transmission, et, dans l'affirmative, une opération de transmission sur
ledit chemin, en mode non connecté.
6. Procédé de communication selon l'une quelconque des
revendications 1 à 5, caractérisé en ce qu'il comporte une opération de la
transmission d'information (254, 257, 259) prenant en compte plusieurs niveaux
de priorité.
7. Procédé de communication selon la revendication 6, caractérisé en ce qu'un niveau de priorité est affecté à la transmissioh en mode non connecté. 8. Procédé de communication selon l'une quelconque des
revendications 6 ou 7, caractérisé en ce que, au cours de l'opération
d'attribution de bande passante (1221), la bande passante associée au niveau de priorité correspondant au mode non connecté varie en fonction d'une durée
n'ayant donné lieu à aucune transmission.
9. Procédé de communication selon la revendication 8, caractérisé en ce que ladite durée est la durée séparant la dernière transmission en mode
non connecté et la prochaine transmission en mode connecté.
10. Procédé de communication selon l'une quelconque des
revendications 6 à 9, caractérisé en ce que, au cours de l'opération d'attribution
de bande passante (1221), la bande passante associée au niveau de priorité correspondant au mode non connecté varie en fonction d'un nombre de
paquets non transmis pendant une durée prédéterminée.
11. Procédé de communication selon l'une quelconque des
revendications 6 à 10, caractérisé en ce que le trafic temps réel déterministe est
transmis avec un niveau de priorité supérieur à celui du trafic temps réel garanti.
12. Procédé de communication selon l'une quelconque des
revendications 6 à 11, caractérisé en ce que chaque niveau de priorité est
associé à une liste de canaux virtuels (1105 à 1110), successivement mis en oeuvre. 13. Procédé de communication selon la revendication 12,
caractérisé en ce que lesdits canaux virtuels sont associés au trafic sortant.
14. Procédé de communication selon l'une quelconque des
revendications 12 ou 13, caractérisé en ce qu'il comporte une opération de
détermination de paramètres de transmission (1221), au cours de laquelle on détermine une dimension de paquets transmis sur ledit réseau, ladite opération
prenant en compte la charge sur ledit réseau.
15. Procédé de communication selon l'une quelconque des
revendications 12 à 14, caractérisé en ce qu'il comporte une opération de
détermination de paramètres de transmission (1221), au cours de laquelle on détermine un nombre de paquets à émettre sur ledit réseau, ladite opération
prenant en compte la charge sur ledit réseau.
16. Procédé de communication selon l'une quelconque des
revendications 12 à 15, caractérisé en ce qu'il comporte une opération de
détermination de paramètres de transmission (1221), au cours de laquelle on détermine une durée disponible pour émettre les paquets restant à émettre sur
ledit réseau, ladite opération prenant en compte la charge sur ledit réseau.
17. Procédé de communication selon l'une quelconque des
revendications 14 à 16, caractérisé en ce que l'opération de détermination de
paramètres de transmission (1221) a lieu, pour chaque dispositif de
communication, lors de l'étape d'information.
18. Procédé de communication selon l'une quelconque des
revendications 14 à 17, caractérisé en ce que l'opération de détermination de
paramètre de transmission (1221) a lieu, pour chaque dispositif de
communication, canal virtuel par canal virtuel.
19. Procédé de communication selon l'une quelconque des
revendications 14 à 18, caractérisé en ce que ladite opération de détermination
de paramètres de transmission (1221) est effectuée lors de l'opération
d'information (313).
20. Procédé de communication selon l'une quelconque des
revendications 6 à 19, caractérisé en ce qu'il comporte une opération de
transmission d'information de contrôle, au cours de laquelle chaque information
de contrôle est transmise avec le plus haut niveau de priorité.
21. Procédé de communication selon l'une quelconque des
revendications 6 à 20, caractérisé en ce que, pour au moins un niveau de
priorité, l'information non transmise durant un intervalle de temps prédéterminé,
est éliminée avant transmission.
22. Procédé de communication selon l'une quelconque des
revendications 6 à 21, caractérisé en ce que, pour au moins un niveau de
priorité, l'information non transmise durant un intervalle de temps prédéterminé,
est conservée pour être transmise durant l'intervalle de temps suivant.
23. Procédé de communication selon l'une quelconque des
revendications 1 à 22, caractérisé en ce que le trafic temps réel, déterministe ou
garanti, est transmis en mode connecté.
24. Procédé de communication selon l'une quelconque des
revendications 1 à 23, caractérisé en ce que le trafic élastique est transmis en
mode non connecté.
25. Procédé de communication selon l'une quelconque des
revendications 1 à 24, caractérisé en ce qu'il comporte, pour chaque dispositif
de communication placé sur le chemin destiné à être suivi par une transmission en mode connecté, une opération de vérification (1404), au cours de laquelle, on vérifie que la bande passante nécessaire à ladite transmission est disponible
sur ledit chemin.
26. Procédé de communication selon l'une quelconque des
revendications 1 à 25, caractérisé en ce que, pour le trafic déterministe,
l'information non transmise durant un intervalle de temps prédéterminé, est
éliminée avant transmission.
27. Procédé de communication selon l'une quelconque des
revendications 1 à 26, caractérisé en ce que, pour le trafic garanti, l'information
non transmise durant un intervalle de temps prédéterminé, est conservée pour
être transmise durant l'intervalle de temps suivant.
28. Procédé selon l'une quelconque des revendications 1 à 27,
caractérisé en ce que chaque dispositif de communication effectue chaque
transmission d'information par commutation de paquet.
29. Procédé de communication selon l'une quelconque des
revendications 1 à 28, caractérisé en ce qu'il comporte, pour l'établissement d'une
connexion: A/ effectuées par un dispositif de communication source d'information à transmettre en mode connecté: - une opération de détermination de besoin de bande passante pour la transmission de ladite information en mode connecté, - une opération de détermination d'un éventuel chemin disponible pour ladite transmission, en fonction d'informations conservées dans une table de charge de chaque lien du réseau, et - lorsqu'un chemin disponible est déterminé: ò une opération d'émission d'une information représentative dudit besoin de bande passante à destination du dispositif de communication suivant sur ledit chemin, et À une opération de mise à jour de ladite table de charge des liens du réseau, - une opération de diffusion à destination d'au moins tous les dispositifs de communication en dehors du chemin, d'une information représentative dudit besoin de bande passante, B/ effectuées par chaque dispositif de communication intermédiaire sur ledit chemin: - une opération de détermination de disponibilité dudit chemin, pour ladite communication, en fonction d'informations conservées dans une table de charge de chaque lien du réseau, et - lorsque le chemin est disponible:
15. une opération d'émission d'une information représentative dudit besoin de bande passante, au dispositif de communication suivant sur le chemin, et a une opération de mise à jour d'une table de charge des liens du réseau, C/ effectuée par chaque dispositif de communication en dehors dudit chemin: - une opération de mise à jour d'une table de charge des liens du réseau. 30. Procédé de communication selon l'une quelconque des
revendications 1 à 29, entre des dispositifs de communication susceptibles, de
déterminer, chacun, pour chaque information qu'il a à transmettre, un chemin à lui faire suivre, caractérisé en ce qu'il comporte: - effectuée par chaque dispositif de communication dit "source", qui a besoin d'une connexion associée à un chemin, pour effectuer une transmission d'information à destination d'un dispositif de communication destinataire, une opération de demande de connexion, au cours de laquelle, le dispositif de communication source émet, à destination de chaque dispositif de communication dudit chemin, une demande d'établissement de connexion, lorsque l'établissement de ladite connexion est possible, effectuée par au moins le dispositif de communication destinataire, une opération d'émission à destination du dispositif de communication source d'une acceptation de connexion, - effectuée par le dispositif de communication source, une opération de diffusion, à tous les dispositifs de communication du réseau, d'une information représentative de l'établissement de la connexion, - effectuée par chaque dispositif de communication dudit chemin, à réception de ladite information représentative d'établissement de connexion, une opération de confirmation d'établissement de ladite connexion, et - effectuée par chaque dispositif de communication en dehors dudit chemin, à réception de ladite information représentative d'établissement de connexion, une opération de mise en mémoire d'une information
représentative de ladite connexion.
31. Dispositif de communication sur un réseau comportant des dispositifs de communication, chaque dispositif de communication étant adapté à déterminer, pour chaque information qu'il a à transmettre, un chemin à lui faire suivre sur le réseau et un mode de transmission, connecté, ou non, caractérisé en ce qu'il comporte: - un moyen d'information adapté, pour chaque transmission en mode connecté, à diffuser, à destination de tous les autres dispositifs de communication du réseau, une information représentative de la bande passante nécessaire pour ladite transmission en mode connecté, et - un moyen d'attribution de bande passante, adapté à attribuer, d'une part, aux transmissions en mode connecté, la bande passante qui leur est nécessaire et, d'autre part, tout ou partie de la bande passante disponible à
chaque transmission à effectuer en mode non connecté.
32. Dispositif de communication selon la revendication 31, caractérisé en ce que: - le moyen d'information est adapté, pour un établissement de connexion, à transmettre, à destination de chaque dispositif de communication placé sur ledit chemin, appelé "intermédiaire", une information représentative de la bande passante nécessaire pour ladite connexion, et - il comporte un moyen de détermination de disponibilité en mode connecté, adapté, lorsque ledit dispositif de communication est un dispositif de communication intermédiaire sur un chemin destiné à être associé à une connexion, à déterminer la disponibilité du lien menant au dispositif de communication suivant sur ledit chemin et, en cas d'indisponibilité, à faire transmettre, à un moyen de transmission, à destination du dispositif de communication source, une information représentative de l'indisponibilité dudit
1 5 chemin.
33. Dispositif de communication selon l'une quelconque des
revendications 31 ou 32, caractérisé en ce qu'il comporte, un moyen de contrôle
de flux adapté, pour chaque transmission d'information en mode non connecté pour laquelle ledit dispositif est incorporé dans un dispositif de communication
intermédiaire, à vérifier la disponibilité du chemin suivi par ladite information.
34. Dispositif de communication selon la revendication 33, caractérisé en ce qu'il est adapté à mettre en oeuvre des procédures de
communication conformes à la norme IEEE 1355.
35. Dispositif de communication selon l'une quelconque des
revendications 31 à 34, caractérisé en ce qu'il comporte un moyen de
détermination de bande passante disponible adapté: - à déterminer la bande passante disponible sur chaque lien d'un chemin associé à une connexion, à réception de chaque information représentative de bande passante en provenance d'un autre dispositif de communication, en prenant en compte ladite information, et - lorsque ledit dispositif de communication doit effectuer une transmission en mode non connecté à destination d'un dispositif de communication destinataire, à déterminer la disponibilité au moins partielle d'au moins un chemin allant dudit dispositif de communication source audit dispositif
de communication destinataire pour une transmission en mode non connecté.
36. Dispositif de communication selon l'une quelconque des
revendications 31 à 35, caractérisé en ce qu'il comporte un moyen de
transmission d'information prenant en compte plusieurs niveaux de priorité.
37. Dispositif de communication selon la revendication 36, caractérisé en ce que le moyen de transmission est adapté à ce qu'un niveau
de priorité soit affecté à la transmission en mode non connecté.
38. Dispositif de communication selon l'une quelconque des
revendications 36 ou 37, caractérisé en ce que le moyen d'attribution de bande
passante est adapté à ce que la bande passante associée au niveau de priorité correspondant au mode non connecté varie en fonction d'une durée n'ayant
donné lieu à aucune transmission.
39. Dispositif de communication selon la revendication 38, caractérisé en ce que le moyen d'attribution de bande passante est adapté à ce que ladite durée soit la durée séparant la dernière transmission en mode non
connecté et la prochaine transmission en mode connecté.
40. Dispositif de communication selon l'une quelconque des
revendications 36 à 39, caractérisé en ce que le moyen d'attribution de bande
passante est adapté à ce que la bande passante associée au niveau de priorité correspondant au mode non connecté varie en fonction d'un nombre de
paquets non transmis pendant une durée prédéterminée.
41. Dispositif de communication selon l'une quelconque des
revendications 36 à 40, caractérisé en ce que le moyen de transmission
d'information est adapté à ce que le trafic temps réel déterministe soit transmis
avec un niveau de priorité supérieur à celui du trafic temps réel garanti.
42. Dispositif de communication selon l'une quelconque des
revendications 36 à 41, caractérisé en ce que le moyen de transmission
d'information est adapté à ce que chaque niveau de priorité soit associé à une
liste de canaux virtuels, successivement mis en oeuvre.
43. Dispositif de communication selon la revendication 42, caractérisé en ce que le moyen de transmission d'information est adapté à ce
que lesdits canaux virtuels soient associés au trafic sortant.
44. Dispositif de communication selon l'une quelconque des
revendications 42 ou 43, caractérisé en ce qu'il comporte un moyen de
détermination de paramètres de transmission adapté à déterminer une dimension de paquets transmis sur ledit réseau, en prenant en compte la
charge sur ledit réseau.
45. Dispositif de communication selon l'une quelconque des
revendications 42 à 44, caractérisé en ce qu'il comporte un moyen de
détermination de paramètres de transmission adapté à déterminer un nombre de paquets à émettre sur ledit réseau, en prenant en compte la charge sur ledit réseau. 46. Dispositif de communication selon l'une quelconque des
revendications 42 à 45, caractérisé en ce qu'il comporte un moyen de
détermination de paramètres de transmission adapté à déterminer une durée disponible pour émettre les paquets restant à émettre sur ledit réseau, en
prenant en compte la charge sur ledit réseau.
47. Dispositif de communication selon l'une quelconque des
revendications 44 à 46, caractérisé en ce que le moyen de détermination de
paramètres de transmission est adapté à déterminer lesdits paramètres, canal
virtuel par canal virtuel.
48. Dispositif de communication selon l'une quelconque des
revendications 36 à 47, caractérisé en ce que le moyen de transmission est
adapté à transmettre chaque information de contrôle avec le plus haut niveau
de priorité.
49. Dispositif de communication selon l'une quelconque des
revendications 36 à 48, caractérisé en ce que le moyen de transmission est
adapté à ce que, pour au moins un niveau de priorité, l'information non transmise durant un intervalle de temps prédéterminé, est éliminée avant transmission. 50. Dispositif de communication selon l'une quelconque des
revendications 36 à 49, caractérisé en ce que le moyen de transmission est
adapté à ce que, pour au moins un niveau de priorité, I'information non transmise durant un intervalle de temps prédéterminé, est conservée pour être
transmise durant l'intervalle de temps suivant.
51. Dispositif de communication selon l'une quelconque des
revendications 31 à 50, caractérisé en ce qu'il est adapté à ce que le trafic
temps réel, déterministe ou garanti, soit transmis en mode connecté.
52. Dispositif de communication selon l'une quelconque des
revendications 31 à 51, caractérisé en ce qu'il est adapté à ce que le trafic
élastique soit transmis en mode non connecté.
53. Dispositif de communication selon l'une quelconque des
revendications 31 à 52, caractérisé en ce que chaque dispositif de
communication placé sur le chemin destiné à être suivi par une transmission en mode connecté, comporte un moyen de vérification adapté à vérifier que la bande passante nécessaire à ladite transmission est disponible sur ledit
chemin.
54. Dispositif de communication selon l'une quelconque des
revendications 31 à 53, caractérisé en ce qu'il comporte un moyen de
transmission adapté à éliminer l'information non transmise durant un intervalle
de temps prédéterminé, pour le trafic déterministe.
55. Dispositif de communication selon l'une quelconque des
revendications 31 à 54, caractérisé en ce qu'il comporte un moyen de
transmission adapté à conserver pour une transmission ultérieure l'information
non transmise durant un intervalle de temps prédéterminé, pour le trafic garanti.
56. Dispositif selon l'une quelconque des revendications 31 à 55,
caractérisé en ce que chaque dispositif de communication est adapté à mettre en oeuvre un protocole de transmission d'information par commutation de
paquet.
57. Dispositif de communication selon l'une quelconque des
revendications 31 à 56, caractérisé en ce qu'il comporte:
- un moyen de détermination de temps libre dans ladite période de base après séquencement de toutes les transmissions, adapté à organiser toutes les autres transmissions, et - un moyen de régulation adapté à réguler la bande passante
disponible pour les transmissions en mode non connecté.
58. Dispositif de communication selon l'une quelconque des
revendications 56 ou 57, caractérisé en ce que ledit moyen de régulation est
adapté: - à diminuer la bande passante allouée aux transmissions en mode non connecté, lorsque le temps libre est négatif, et - à augmenter la bande passante allouée aux transmissions en
mode non connecté, lorsque le temps libre est positif.
59. Dispositif de communication selon l'une quelconque des
revendications 31 à 58, caractérisé en ce que:
- il comporte une mémoire adaptée à conserver une table de charge contenant des informations relatives à la charge de chaque lien du réseau, et - il est adapté, pour l'établissement d'une connexion: pour la transmission d'information en mode connecté: - à déterminer un besoin de bande passante pour la transmission de ladite information en mode connecté, - à déterminer un éventuel chemin disponible pour ladite transmission, en fonction d'informations conservées dans ladite table de charge, et lorsqu'un chemin disponible est déterminé, - à faire émettre, au moyen de transmission, une information représentative dudit besoin de bande passante, à destination du dispositif de communication suivant sur ledit chemin, - à mettre à jour ladite table de charge, - à faire diffuser, par le moyen de transmission, à destination d'au moins tous les dispositifs de communication en dehors du chemin, une
information représentative dudit besoin de bande passante.
60. Dispositif de communication selon l'une quelconque des
revendications 31 à 59, sur un réseau comportant des dispositifs de
communication susceptibles, chacun, de déterminer le chemin à faire suivre à chaque information qu'il a à émettre, caractérisé en ce qu'il est adapté, lorsqu'il a besoin d'une connexion associée à un chemin, pour effectuer une transmission d'information à destination d'un dispositif de communication destinataire: - à faire émettre, par le moyen de transmission, à destination de chaque dispositif de communication dudit chemin, un message de demande d'établissement de connexion, et - à réception d'un message d'acceptation de connexion en provenance du dispositif de communication destinataire, à faire diffuser, par ledit moyen de transmission, à tous les dispositifs de communication du réseau,
un message d'information d'établissement de la connexion.
61. Ordinateur, caractérisé en ce qu'il comporte un dispositif de
communication selon l'une quelconque des revendications 31 à 60.
62. Caméra, caractérisée en ce qu'elle comporte un dispositif de
communication selon l'une quelconque des revendications 31 à 60.
63. Télécopieur, caractérisé en ce qu'il comporte un dispositif de
communication selon l'une quelconque des revendications 31 à 60
64. Appareil photographique, caractérisé en ce qu'il comporte un
dispositif de communication selon l'une quelconque des revendications 31 à 60.
65. Téléviseur, caractérisé en ce qu'il comporte un dispositif de
communication selon l'une quelconque des revendications 31 à 60.
66. Imprimante, caractérisée en ce qu'elle comporte un dispositif
de communication selon l'une quelconque des revendications 31 à 60.
67. Scanner, caractérisé en ce qu'il comporte un dispositif de
communication selon l'une quelconque des revendications 31 à 60.
68. Lecteur audio/vidéo, caractérisé en ce qu'il comporte un
dispositif de communication selon l'une quelconque des revendications 31 à 60.
FR9808627A 1998-07-06 1998-07-06 Procede et dispositif de communication d'information Expired - Fee Related FR2780837B1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
FR9808627A FR2780837B1 (fr) 1998-07-06 1998-07-06 Procede et dispositif de communication d'information
US09/345,969 US6891797B1 (en) 1998-07-06 1999-07-01 Method and device for communicating information
US10/921,901 US7602708B2 (en) 1998-07-06 2004-08-20 Method and device for communicating information

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR9808627A FR2780837B1 (fr) 1998-07-06 1998-07-06 Procede et dispositif de communication d'information

Publications (2)

Publication Number Publication Date
FR2780837A1 true FR2780837A1 (fr) 2000-01-07
FR2780837B1 FR2780837B1 (fr) 2002-12-20

Family

ID=9528309

Family Applications (1)

Application Number Title Priority Date Filing Date
FR9808627A Expired - Fee Related FR2780837B1 (fr) 1998-07-06 1998-07-06 Procede et dispositif de communication d'information

Country Status (1)

Country Link
FR (1) FR2780837B1 (fr)

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
BENNER A F: "FIBRE CHANNEL: GIGABIT COMMUNICATIONS AND I/O FOR COMPUTER NETWORKS", 1996, MCGRAW-HILL, NEW YORK (US), XP002098797 *
BUDRIKIS Z L ET AL: "A GENERIC FLOW CONTROL PROTOCOL FOR B-ISDN", ONE WORLD THROUGH COMMUNICATIONS, FLORENCE, MAY 4 - 8, 1992, vol. 2, no. CONF. 11, 3 August 1992 (1992-08-03), INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS, pages 895 - 904, XP000300226 *
COOK B M: "IEEE 1355 data-strobe links: ATM speed at RS232 cost", MICROPROCESSORS AND MICROSYSTEMS, vol. 21, no. 7-8, 30 March 1998 (1998-03-30), pages 421-428, XP004123975 *
PLATT R: "WHY ISOETHERNET WILL CHANGE THE VOICE AND VIDEO WORLDS", IEEE COMMUNICATIONS MAGAZINE, vol. 34, no. 4, 1 April 1996 (1996-04-01), pages 55 - 59, XP000586071 *
WU H T ET AL: "INTEGRATION OF SYNCHRONOUS AND ASYNCHRONOUS TRAFFIC ON THE METARING ARCHITECTURE AND ITS ANALYSIS", DISCOVERING A NEW WORLD OF COMMUNICATIONS, vol. 1, 14 June 1992 (1992-06-14) - 18 June 1992 (1992-06-18), CHICAGO (US), pages 147 - 153, XP000326867 *

Also Published As

Publication number Publication date
FR2780837B1 (fr) 2002-12-20

Similar Documents

Publication Publication Date Title
EP2103056B1 (fr) Procede de reservation et d'allocation dynamique de creneaux temporels dans un reseau avec garantie de service
JP2528626B2 (ja) デ―タ通信方法及び装置
EP0858193B1 (fr) Procédé et dispositif d'allocation de ressources dans un réseau numerique de transmission par paquets
CA2030685C (fr) Procede de gestion des flux dans un reseau numerique de telecommunication a integration de services, a large bande, et reseau pour la mise en oeuvre de ce procede
FR2850816A1 (fr) Dispositif et procede de commande de vitesse d'acheminement du trafic dans un reseau de telecommunications utilisant un compartiment fuyant a plusieurs seuils
JPH0514410A (ja) トラヒツク制御方法
JPH07170271A (ja) 統合ネットワークにおけるマルチメディア・ストリームの柔軟な参入許可制御方法
FR2858895A1 (fr) Procede et dispositif de gestion de priorite lors de la transmission d'un message
EP1884875A1 (fr) Système de gestion de messages transmis dans un réseau d'interconnexions sur puce
US6891797B1 (en) Method and device for communicating information
FR2804812A1 (fr) Procede et dispositif de communication entre un premier et un deuxieme reseau
EP0886455B1 (fr) Procédé de gestion de largeurs de bandes allouées dans les réseaux locaux à accès partagés, protocole et filtre de mise en oeuvre
FR2725811A1 (fr) Appareil et procede pour systeme de reservation de memoire tampon
FR2671251A1 (fr) Protocole d'acces multiple a un canal de telecommunications a partir de terminaux auxiliaires par messages d'information numerisee et systeme correspondant.
FR2780838A1 (fr) Procede et dispositif de communication d'information
FR2780837A1 (fr) Procede et dispositif de communication d'information
FR2780836A1 (fr) Procede et dispositif de communication d'information
EP2141868B1 (fr) Contrôle d'admission à un service
FR2780839A1 (fr) Procede et dispositif de communication d'information
EP0961446B1 (fr) Contrôle de congestion dans un noeud ATM
Borgonovo et al. Circuit service in deflection networks
WO2014135793A1 (fr) Procédé d'allocation de ressources pour la mise en œuvre de réseaux virtuels dans un réseau de télécommunication
Pan et al. Processing overhead studies in resource reservation protocols
US20120201129A1 (en) Stateless admission control
Moore et al. Packet sequencing: A Deterministic protocol for QoS in IP networks

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20140331