FR 3059504 A1 20180601 FR 1661718 A 20161130 PROCEDE DE FRACTIONNEMENT DE MESSAGES APPLICATIFS DANS UN RESEAU IP La présente invention concerne les réseaux de communications de type IP (« Internet Protocol »), et notamment ceux parmi les réseaux IP qui sont aptes à mettre en oeuvre des protocoles de contrôle de session évolués. Plus particulièrement, la présente invention concerne les moyens mis en oeuvre dans un réseau IP pour transmettre des messages applicatifs de grande longueur. Par « applicatifs », on entend que ces messages obéissent aux normes concernant une certaine application informatique. On rappelle que les réseaux IP permettent la diffusion de données conversationnelles, dans le cadre de services tels que « Voix sur IP » (VolP), « Partage de Contenu », ou « Messagerie Instantanée ». On rappelle également que les protocoles de contrôle de session évolués, tels que le protocole SIP (initiales des mots anglais « Session Initiation Protocol » signifiant « Protocole d'Initiation de Session »), utilisent des messages dits de « signalisation », qui sont des messages permettant à un terminal de demander une connexion avec un autre terminal, ou également des messages signalant qu'une ligne téléphonique est occupée, ou signalant que le téléphone appelé sonne, ou encore signalant que tel téléphone est connecté au réseau et peut être joint de telle ou telle manière. Le protocole SIP a été défini par l'IETF (Internet Engineering Task Force) dans le document RFC 3261. Ce protocole permet l'établissement, la modification et la terminaison de sessions multimédia dans un réseau utilisant le protocole IP. Le protocole SIP a ensuite été étendu notamment dans le document RFC 3265 ; cette extension définit des procédures de notification d'événements. Le protocole SIP est utilisé en particulier dans les infrastructures réseau de type IMS (initiales des mots anglais « IP Multimedia Subsystem » signifiant « Sous-système Multimédia sur IP »). L'IMS a été défini par l'organisme de normalisation 3GPP (« Third Generation Partnership Project ») et TISPAN (« Telecommunications and Internet Converged Services and Protocols for Advanced Networking »). C'est une architecture de réseau introduite par le 3GPP 3059504 2 pour les réseaux mobiles, puis reprise par TISPAN pour les réseaux fixes. Cette architecture permet l'établissement dynamique et le contrôle de sessions multimédia entre deux clients ainsi que la réservation des ressources au niveau du réseau de transport des flux multimédias. Grâce à cette architecture, les 5 opérateurs réseau peuvent commodément mettre en oeuvre une politique de gestion, fournir une Qualité de Service prédéterminée, et calculer les montants à facturer aux clients. L'IMS permet actuellement d'accéder à des services de type téléphonie, visiophonie, Présence et Messagerie Instantanée, dont elle gère aussi l'interaction. 10 Un problème fondamental qui se pose dans les réseaux IP au niveau de la couche réseau (couche 3 du modèle OSI) est que les routeurs ne peuvent transmettre un paquet de données en un seul bloc que si la longueur de ce paquet ne dépasse pas une certaine valeur maximum, appelée « MTU » (initiales des mots anglais « Maximum Transmission Unit » signifiant « Taille Maximum de 15 Transmission »). Dans certains systèmes (notamment ceux conformes à la norme IPv6), le comportement par défaut est de détruire purement et simplement les paquets trop longs. D'autres systèmes possèdent des moyens pour fractionner un paquet trop long au niveau de la couche réseau, de manière à obtenir plusieurs fragments qui sont transmis l'un après l'autre ; un tel 20 fractionnement est appelé « fragmentation ». Or il est bien connu (cf. par exemple les documents RFC 3128, 4459 et 4963 de l'IETF) que le recours à la fragmentation est source de nombreux problèmes, et doit être évité. En effet, il en résulte notamment : - une perte d'efficacité en bande passante (fragments de quelques octets 25 utiles), - un risque de dé-séquencement des fragments, - une difficulté à traverser les NAT (initiales des mots anglais « Network Address Translator » signifiant « Traducteur d'Adresse Réseau ») et les pare-feux (« firewalls » en anglais), qui imposent un réassemblage, 30 - une obligation de retransmettre tous les fragments en cas de perte d'un seul fragment, et - un risque d'attaques lors du réassemblage des fragments (cf. https://en.wikibedia.org/wiki/IP fragmentation attack). 3059504 3 Aussi différentes techniques ont elles vu le jour pour éviter d'avoir à recourir à la fragmentation. L'une de ces techniques consiste à fractionner les paquets de données trop longs dans la couche de transport (couche 4 du modèle OSI) ; les morceaux résultant de ce fractionnement sont appelés « segments » si 5 le protocole de transport est TCP (initiales des mots anglais « Transmission Control Protocol » signifiant « Protocole de Contrôle de Transmission »), ou « chunks » si le protocole de transport est SCTP (initiales des mots anglais « Stream Control Transmission Protocol » signifiant « Protocole de Transmission avec Contrôle de Flux »). Ces morceaux ont une longueur adaptée à la MTU sur 10 le chemin de transmission. On notera à cet égard que les documents RFC 1191, RFC 1181 et RFC 4821 expliquent comment on peut déterminer la MTU dans le cas de protocoles connectés tels que TCP et SCTP. En revanche, lorsqu'une communication utilise un mode de transport non-connecté, tel que le protocole UDP (initiales des mots anglais « User Datagram 15 Protocol » signifiant « Protocole de Datagramme Utilisateur »), on ne sait pas fractionner un paquet de données dans la couche de transport. Cela est fâcheux car le protocole UDP (en particulier) est très souvent utilisé dans les réseaux IP actuels. La présente invention concerne donc, selon un premier aspect, un 20 procédé de fractionnement de messages applicatifs dans un réseau IP (Internet Protocol), comprenant les étapes suivantes : a) un noeud du réseau IP, dit premier noeud, reçoit un message devant être transmis à un autre noeud du réseau IP, dit second noeud, b) ledit premier noeud compare la longueur dudit message avec la taille 25 maximum de transmission MTU (Maximum Transmission Unit) caractérisant le chemin entre ledit premier noeud et ledit second noeud, et, si ladite longueur est supérieure à la MTU, c) le premier noeud fractionne le message en au moins deux segments, et insère chaque segment respectif dans un paquet de données respectif de 30 longueur inférieure ou égale à la MTU, d) le premier noeud transmet lesdits paquets de données au second noeud, et 3059504 4 e) le second noeud assemble lesdits segments de manière à reconstituer ledit message. Ledit procédé est remarquable en ce que, ledit message étant un message applicatif : 5 - lors de ladite étape c), le premier noeud insère dans chacun desdits paquets de données une information dite de positionnement précisant la position relative dans le message du segment inséré dans ce paquet de données, et - lors de ladite étape e), le second noeud reconstitue le message à l'aide desdites informations de positionnement. 10 Ainsi, selon l'invention, lorsqu'un message applicatif est trop long, on le fractionne dans la couche applicative (couche 7 du modèle OSI) ; plus précisément, chaque morceau de message ainsi obtenu, que l'on appellera « segment », est encapsulé dans un paquet de données de longueur compatible avec la MTU. Le fractionnement de messages conformément à l'invention sera 15 appelé « segmentation » ci-après. Grâce à ces dispositions, pour chaque chemin considéré entre deux noeuds selon l'invention, on pourra utiliser au mieux les capacités disponibles, tout en s'assurant qu'aucune partie du message ne sera perdue. Avantageusement, le procédé de fractionnement selon l'invention est en 20 particulier applicable aux communications utilisant un mode de transport non- connecté, tel que le protocole UDP. Selon des caractéristiques particulières, chacun desdits paquets de données comprend l'ensemble des informations obligatoires dans le cadre de l'application informatique régissant ledit message. 25 Grâce à ces dispositions, lesdits paquets de données sont entièrement conformes aux normes régissant ladite application informatique. Selon d'autres caractéristiques particulières, chacun desdits paquets de données comprend : - des informations de routage limitées aux informations nécessaires au 30 routage du paquet de données vers ledit second noeud, et - un champ dédié contenant un identifiant dudit message. Grâce à ces dispositions, on réduit la place occupée par les informations de routage dans lesdits paquets de données, ce qui permet d'augmenter la 3059504 5 longueur desdits segments, et donc de réduire potentiellement le nombre de paquets de données nécessaires pour transmettre l'intégralité du message applicatif. On notera que les messages fractionnés selon la présente invention 5 peuvent être régis par toutes sortes d'applications informatiques. Cette application informatique peut notamment consister en un protocole de l'IETF tel que HTTP (HyperText Transfer Protocol), MGCP (Media Gateway Control Protocol), ou SMTP (Simple Mail Transfer Protocol). Selon des caractéristiques particulières, l'application informatique 10 régissant ledit message est le protocole SIP mentionné ci-dessus. En effet, le procédé de fractionnement selon l'invention est avantageusement applicable aux messages conformes au protocole SIP, qui est un utilisateur historique du protocole de transport UDP, notamment pour les chemins vers les clients utilisateurs. 15 Selon un deuxième aspect, l'invention concerne divers dispositifs. Elle concerne ainsi, premièrement, un noeud d'un réseau IP, dit premier noeud, comprenant des moyens pour, suite à la réception d'un message devant être transmis à un autre noeud du réseau IP, dit second noeud : - comparer la longueur dudit message avec la taille maximum de 20 transmission MTU (Maximum Transmission Unit) caractérisant le chemin entre ledit premier noeud et ledit second noeud, - fractionner le message en au moins deux segments, - insérer chaque segment respectif dans un paquet de données respectif de longueur inférieure ou égale à la MTU, et 25 - transmettre lesdits paquets de données au second noeud. Ledit premier noeud est remarquable en ce que, ledit message étant un message applicatif, ledit premier noeud comprend en outre des moyens pour insérer dans chaque paquet de données une information dite de positionnement précisant la position relative dans le message du segment inséré dans ce paquet de 30 données. Selon des caractéristiques particulières, chacun desdits paquets de données comprend l'ensemble des informations obligatoires dans le cadre de l'application informatique régissant ledit message. 3059504 6 Selon d'autres caractéristiques particulières, chacun desdits paquets de données comprend : - des informations de routage limitées aux informations nécessaires au routage du paquet de données vers ledit second noeud, et 5 - un champ dédié contenant un identifiant dudit message. L'invention concerne aussi, deuxièmement, un noeud d'un réseau IP, dit second noeud, comprenant des moyens pour : - recevoir des paquets de données, et - extraire de chaque paquet de données un segment de message. 10 Ledit second noeud est remarquable en ce que, ledit message étant un message applicatif, le second noeud comprend en outre des moyens pour : - prendre en compte, dans chacun desdits paquets de données, une information dite de positionnement précisant la position relative dans le message du segment extrait de ce paquet de données, et 15 - utiliser lesdites informations de positionnement pour assembler les segments d'un même message. Selon des caractéristiques particulières, ledit premier noeud et ledit second noeud sont actifs au niveau SIP. Selon d'autres caractéristiques particulières, un noeud IP tel que décrit 20 succinctement ci-dessus comprend des moyens pour transmettre à un autre noeud IP la taille maximum de transmission MTU caractérisant le chemin entre ces deux noeuds. Grâce à ces dispositions, on évite un double apprentissage de la même information, à savoir la MTU caractérisant le chemin entre ces deux noeuds. 25 Les avantages offerts par ces noeuds sont essentiellement les mêmes que ceux offerts par les procédés corrélatifs succinctement exposés ci-dessus. On notera qu'il est possible de réaliser ces noeuds dans le contexte d'instructions logicielles et/ou dans le contexte de circuits électroniques. On notera également qu'un noeud de réseau IP peut comprendre à la fois les 30 moyens de « premier noeud » et les moyens de « second noeud » selon l'invention. Selon un troisième aspect, l'invention concerne un système de communication de messages applicatifs dans un réseau IP, comprenant au 3059504 7 moins un premier noeud tel que décrit succinctement ci-dessus et au moins un second noeud tel que décrit succinctement ci-dessus. L'invention vise également un programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par 5 ordinateur et/ou exécutable par un microprocesseur. Ce programme d'ordinateur est remarquable en ce qu'il comprend des instructions pour l'exécution des étapes du procédé de fractionnement succinctement exposé ci-dessus, lorsqu'il est exécuté sur un ordinateur. Les avantages offerts par ce programme d'ordinateur sont 10 essentiellement les mêmes que ceux offerts par ledit procédé. D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-dessous de modes de réalisation particuliers, donnés à titre d'exemples non limitatifs. On va décrire un mode de réalisation de l'invention dans lequel 15 l'application informatique régissant les messages échangés dans une communication est le protocole de contrôle SIP. Dans ce mode de réalisation, le format d'un paquet de données encapsulant un segment de message sera appelé « pseudo-méthode SEGMENT ». On notera que la pseudo-méthode SEGMENT n'est pas à proprement parler une « méthode » au sens du protocole 20 SIP, mais une extension du protocole SIP applicable spécifiquement au procédé de fractionnement selon l'invention. C'est pourquoi on parle de « pseudo »méthode, et c'est pourquoi il est également possible de redéfinir les en-têtes (« headers » en anglais) de paquets de données dans le cadre de cette pseudométhode. 25 La segmentation selon la pseudo-méthode SEGMENT sera mise en oeuvre de préférence sur chaque « hop SIP » du réseau IP considéré. On appelle « hop SIP » le chemin entre deux noeuds de réseau actifs au niveau SIP. Un noeud actif au niveau SIP est caractérisé en ce qu'il génère une requête ou une réponse SIP, ou bien insère/retire un en-tête Via dans le message SIP en cours 30 de traitement, comme le font communément les UAC (User Agent Client), UAS (User Agent Server), serveurs mandataires (« proxy » en anglais) ou B2BUA (Back-to-Back User Agent) du protocole SIP. En particulier, un noeud actif au niveau SIP génère ou décrémente l'en-tête « Max-Forward » dans une requête. 3059504 8 La pseudo-méthode SEGMENT s'applique à tout noeud actif au niveau SIP, quel que soit le contexte d'usage (par exemple, réseau IMS, WebRTC, solutions VolP non normalisées, ou réseaux privés). La valeur de la MTU, notée SIP PATH MTU D, sera déterminée de 5 préférence pour chaque « hop SIP », et mémorisée dans les noeuds actifs pour chaque chemin. En effet, à chaque « hop SIP » un protocole de transport différent (tel que TCP, UDP, ou SCT) peut être utilisé, et c'est donc bien « hop SIP » par « hop SIP » que la MTU doit être déterminée. On va commencer par expliquer comment un noeud SIP actif peut 10 déterminer la valeur de la MTU pour un « hop SIP » dont ce noeud est un point d'extrémité. On notera à cet égard que le document RFC 4821, mentionné ci-dessus, indique (cf. Sections 9 et 10.4) que la détermination de la MTU dans le cas des protocoles de transport non-connectés doit être réalisée au niveau applicatif, et ce, au moyen d'un mécanisme consistant à générer des paquets de 15 test de longueur variable et à observer si ces paquets de test sont reçus ou perdus. Mais les indications du document RFC 4821 sont générales ; on va décrire à présent de manière détaillée comment un tel mécanisme peut être mis en oeuvre pour une communication selon le protocole SIP. La procédure proposée pour l'acquisition du SIP PATH MTU D sur un 20 « hop SIP » donné est fondée sur l'émission d'une requête SIP d'apprentissage, qui pourra être par exemple un message OPTIONS (mais n'importe quelle autre requête peut convenir), dont on fera varier la longueur. De nombreuses variantes existent pour faire varier la longueur d'une requête SIP ; on peut par exemple utiliser un corps de message (body) de longueur variable, ou un en-tête (par 25 exemple, un en-tête « User-Agent ») de longueur variable. Le noeud SIP utilise les automates de transaction normalisés du protocole SIP pour transmettre ou retransmettre les requêtes d'apprentissage. Voici un exemple d'une telle requête : 30 OPTIONS sip:client@NetworkFromOperator.com SIP/2.0 Call-ID: eA6e9NTaAA@10.29.67.130 CSeq: 1 OPTIONS From: ;tag=eA6e9NTbAA 3059504 9 To: Via: SIP/2.0/UDP 10.29.67.130:5060; branch=z9hG4bKf94075096 Max-Forwards: 1 5 Contact: Content-Type: application/probe Content-Length: [testMTU] 10 On notera que la requête OPTIONS ci-dessus comprend un en-tête « Max-Forwards » valorisé à 1, ce qui permet de cibler directement le prochain « hop SIP ». Le noeud SIP ayant émis le message d'apprentissage se met ensuite à 15 l'écoute d'une réponse de la part d'un correspondant. Voici un exemple de réponse : SIP/2.0 200 OK Via: SIP/2.0/UDP 80.12.197.184:5060; 20 branch= z9hG4bKf94075096 Call-ID: eA6e9NTaAA@10.29.67.130 CSeq: 1 OPTIONS From: ; tag=eA6e9NTbAA To: ;tag=rp7e9NTdAA 25 Contact: Content-Length: 0 Dans l'exemple ci-dessus, l'émetteur du message d'apprentissage reçoit une réponse de type SIP 200 OK, mais n'importe quelle réponse SIP (par 30 exemple, « 480 Temporarily unavailable ») peut convenir pour les besoins de la procédure d'apprentissage. 3059504 10 Dans ces conditions : - si une réponse est reçue, c'est que le message d'apprentissage est parvenu à destination ; par conséquent, la taille maximum des messages acceptée sur le chemin vers ce correspondant est au moins égale à celle dudit 5 message d'apprentissage ; - si en revanche aucun message n'est reçu en réponse, c'est que le message d'apprentissage a été perdu, et donc que sa longueur était trop grande. A l'issue de la procédure d'apprentissage, la valeur (ou une estimation de la valeur) de SIP PATH MTU D est ainsi disponible dans l'application 10 informatique SIP. Pour un noeud de réseau servant d'entité de raccordement entre un réseau d'accès et un coeur de réseau (tel qu'un serveur P-CSCF dans un réseau IMS), la procédure de découverte de la MTU entre cette entité de raccordement et un client se déroulera de préférence juste après l'enregistrement initial de ce 15 client, et la mise en oeuvre de cette procédure permettra de stocker la MTU dans le contexte d'enregistrement associé à l'adresse de contact du client. Le SIP PATH MTU D restera ainsi valide tout au long de l'enregistrement du client, et pourra être recalculé lors d'un nouvel enregistrement initial, de façon à s'adapter à une éventuelle modification de ce chemin du réseau. 20 Le stockage du SIP PATH MTU D dans le contexte d'enregistrement de manière permet ensuite au client de mettre en oeuvre l'invention avec tout protocole de transport admissible. Le client pourra par exemple transmettre des messages après avoir basculé d'UDP vers TCP lorsque la longueur de ces messages est supérieure à (SIP PATH MTU D - 200 octets), comme requis 25 par le document RFC 3261 mentionné ci-dessus. Cette information peut être également diffusée à un correspondant du client, qui pourra alors avantageusement la stocker dans son propre contexte d'enregistrement afin de l'exploiter de la même façon. Cette information peut par exemple être communiquée dans un en-tête ou le contenu d'un message, par 30 exemple un message d'apprentissage de la MTU. Voici par exemple comment un noeud actif au niveau SIP peut transmettre la valeur de SIP PATH MTU D à un correspondant en tant que paramètre d'un 3059504 11 en-tête tel que « From » ou « Via », en utilisant un « generic-param » SIP (la notion de « generic-param » est définie dans le document RFC 3261) : From: 5 tag=LC7e9NTgAA;SIP_PATH_MTU_D =5000 Si le noeud actif au niveau SIP est un noeud de coeur de réseau IMS, tel qu'un AS (initiales des mots anglais « Application Server » signifiant « Serveur d'Applications »), un I-CSCF (initiales des mots anglais « Interrogating-Cali 10 Server Control Function » signifiant « Fonction de Commande de Session d'Appel Interrogatrice »), un S-CSCF (initiales des mots anglais « Serving-Cali Server Control Function » signifiant « Fonction de Commande de Session d'Appel Serveuse »), ou un BGCF (initiales des mots anglais « Breakout Gateway Control Function » signifiant « Fonction de Commande de Passerelle 15 de Sortie »), la procédure d'apprentissage sera mise en oeuvre lorsque le « hop SIP » apparaîtra pour la première fois dans une route. Par « première fois », on entend le fait que ce « hop SIP » n'est pas présent dans les tables mémorisées localement. Afin de ne pas risquer une mémorisation sans limite, l'indication de la MTU pour un « hop SIP » non utilisé pendant une durée prédéterminée sera de 20 préférence supprimée. Le procédé de fractionnement selon l'invention, dans le présent mode de réalisation, comprend les étapes suivantes. Selon une première étape, un noeud IP, dit premier noeud, reçoit un message SIP (requête ou réponse), et constate qu'il doit transmettre ce message 25 à un autre noeud IP, dit second noeud. On suppose que ce premier noeud a précédemment découvert la MTU caractérisant le chemin entre le premier noeud et le second noeud (en utilisant, par exemple, la procédure décrite ci-dessus), ou a obtenu précédemment la valeur de la MTU de la part du second noeud (en utilisant, par exemple, la procédure également décrite ci-dessus). 30 Selon une deuxième étape, le premier noeud compare la longueur du message reçu avec cette MTU. On va supposer à présent que la longueur du message est supérieure à la MTU. 3059504 12 Selon une troisième étape, le premier noeud extrait du message SIP reçu l'ensemble des informations SIP obligatoires (telles que spécifiées dans la Table 2 du chapitre 20 du document RFC 3261), ainsi que celles nécessaires au routage du message vers son destinataire ; ces informations comprennent 5 notamment les en-têtes « Via », « From », « To », « Cseq », « Call-ID », « Max- Forwards », « Route », « Record-Route », « Contact », ainsi que la première ligne du message (« Request URI »). Le premier noeud fractionne alors le contenu du message de manière à obtenir plusieurs segments. Chaque segment respectif sera transporté dans un 10 corps de message (« body » en anglais) d'une pseudo-méthode SEGMENT respective de longueur inférieure ou égale à la MTU. En variante dite « optimisée », seules les informations nécessaires au routage de la pseudo-méthode SEGMENT vers le second noeud (par opposition aux informations de routage concernant plusieurs « hop SIP ») sont recopiées 15 dans les en-têtes de la pseudo-méthode SEGMENT ; on fait ainsi l'économie, notamment, des en-têtes Record-Route, Via, From, Call-ID, CSeq, MaxForwards, et Contact. Toutefois, dans le cadre de cette variante, le premier noeud inclut en outre dans la pseudo-méthode SEGMENT un en-tête, dit en-tête d'identification, contenant un identifiant (généré aléatoirement, par exemple) 20 caractéristique du message à transmettre, et que l'on appellera « SIP-PDU-Id » ; cet identifiant SIP-PDU-Id permet donc d'identifier toutes les pseudo-méthodes SEGMENT relatives au même message SIP. Grâce à ces dispositions, on réduit la place occupée par les informations de routage dans les pseudo-méthodes SEGMENT, ce qui permet d'augmenter la longueur desdits segments, et donc de 25 réduire potentiellement le nombre de pseudo-méthodes SEGMENT nécessaires pour transmettre l'intégralité du message. On notera toutefois que ce résultat est obtenu au prix d'un comportement non-standard vis-à-vis des normes SIP. Par ailleurs, quelle que soit la variante, le premier noeud inclut dans chaque pseudo-méthode SEGMENT un en-tête dit de positionnement (que l'on 30 appellera « Segment-Size ») précisant la position relative dans le message à transmettre du segment encapsulé dans cette pseudo-méthode ; cet en-tête de positionnement permettra au second noeud de reconstituer ce message, en particulier si les segments sont dé-séquencés pendant le transport. Ainsi, dans 3059504 13 les exemples fournis ci-dessous, l'en-tête Segment-Size spécifie, dans chaque pseudo-méthode SEGMENT, les numéros d'ordre des octets du message à transmettre encapsulés dans cette pseudo-méthode, ainsi que le nombre total d'octets de ce message. 5 Selon une quatrième étape, le premier noeud transmet au second noeud les pseudo-méthodes SEGMENT ainsi obtenues. Enfin, selon une cinquième étape, le second noeud reconstitue le message grâce à l'information de positionnement contenue dans l'en-tête Segment-Size, ainsi que, dans le cas de la variante optimisée, grâce à 10 l'information contenue dans l'en-tête SIP-PDU-Id (au besoin). Le protocole SIP effectue alors, optionnellement, des contrôles sur le message reconstitué (validité, destination, origine, sémantique, et ainsi de suite), avant de le transmettre vers le « hop SIP » suivant si le message n'a pas atteint sa destination finale. 15 On va illustrer le présent mode de réalisation avec quelques exemples numériques. Supposons, selon un premier exemple, qu'un premier noeud doive transmettre à un second noeud une requête SIP OPTIONS, de longueur totale 1700 octets (à savoir, 200 octets d'en-têtes, et 1500 octets de corps de 20 message), libellée comme suit : OPTIONS sip:client@NetworkFromOperator.com SIP/2.0 Call-ID: eA6e9NTaAA@10.29.67.130 CSeq: 1 OPTIONS 25 Route: From: ;tag=eA6e9NTbAA To: Via: SIP/2.0/UDP 10.29.67.130:5060; branch=z9hG4bKf94075096aaba6a952d7a9a630c70d9b333832 30 Max-Forwards: 1 Contact: Content-Type: application/probe 3059504 14 Content-Length: 1500 5 Si la valeur de la MTU sur le chemin est 1000 octets, il faudra utiliser (au moins) deux pseudo-méthodes SEGMENT. Dans la variante dite « optimisée », la transmission du message comprend alors une première pseudo-méthode, dont les en-têtes occupent (disons) 100 octets et de longueur totale 1000 octets, libellée comme suit : 10 SEGMENT sip:client@NetworkFromOperator.com SIP/2.0 Route: To: sip:client@NetworkFromOperator.com Segment-Size: 1-900 / 1700 15 SIP-PDU-Id: 456@#Th7j8k563ty7K OPTIONS sip:client@NetworkFromOperator.com SIP/2.0Call-ID: eA6e9NTaAA@10.29.67.130 CSeq: 1 OPTIONS 20 From: ;tag=eA6e9NTbAA To: Via: SIP/2.0/UDP 10.29.67.130:5060; branch=z9hG4bKf94075096aaba6a952d7a9a630c70d9b333832 Max-Forwards: 1 25 Contact: Content-Type: application/something Content-Length: 1500 30 où, puisque la MTU vaut 1000 octets : 3059504 15 N1 = 1000 -100 (en-têtes de SEGMENT) - 200 (en-têtes de OPTIONS) = 700 octets. Toujours dans la variante dite « optimisée », la transmission du message comprend en outre une seconde pseudo-méthode, dont les en-têtes occupent 5 (disons) 100 octets et de longueur totale 1000 octets, libellée comme suit : SEGMENT sip:client@NetworkFromOperator.com SIP/2.0 Route: To: sip:client@NetworkFromOperator.com 10 Segment-Size: 901-1700 / 1700 SIP-PDU-Id: 456@#Th7j8k563ty7K 15 où, puisque le contenu de la méthode OPTIONS (c'est-à-dire le corps du message) comprend 1500 octets : N2 = 1500 - N1 = 800 octets. Selon un deuxième exemple, supposons qu'un correspondant souhaite transmettre une réponse SIP 200 OK, de longueur totale 1400 octets (à savoir, 20 200 octets d'en-têtes, et 1200 octets de corps de message), libellée comme suit : SIP/2.0 200 OK Via: SIP/2.0/UDP 80.12.197.184:5060; bra nch=z9hG4bK I M5CA0720430.000 33323c28bbb663570d434d94f66752e3; 25 Call-ID: LC7e9NTfAA@10.29.67.132 CSeq: 1 OPTIONS From: ;tag=LC7e9NTgAA To: ;tag=rp7e9NTdAA Contact: 30 Content-Type: application/ somethingElse Content-Length: 1200 3059504 16 Si la valeur de la MTU sur le chemin est 1000 octets, il faudra utiliser (au 5 moins) deux pseudo-méthodes SEGMENT. Dans la variante dite « optimisée », la transmission du message comprend alors une première pseudo-méthode, dont les en-têtes occupent (disons) 100 octets et de longueur totale 1000 octets, libellée comme suit : 10 SEGMENT 200 OK Via: SIP/2.0/UDP 80.12.197.184:5060; bra nch=z9hG4bK I MSCA0720430.000 33323c28bbb663570d434d94f66752e3; Segment-Size: 1-900 / 1400 SIP-PDU-Id: fsdRET6hrtL45 15 SIP/2.0 200 OK Via: SIP/2.0/UDP 80.12.197.184:5060; bra nch=z9hG4bK I MSCA0720430.000 33323c28bbb663570d434d94f66752e3; Call-ID: LC7e9NTfAA@10.29.67.132 20 CSeq: 1 OPTIONS From: ;tag=LC7e9NTgAA To: ;tag=rp7e9NTdAA Contact: Content-Type: application/somethingElse 25 Content-Length: 1200 où, puisque la MTU vaut 1000 octets : 30 M1 = 1000 -100 (en-têtes de SEGMENT) - 200 (en-têtes de SIP 200 OK) = 700 octets. 3059504 17 Toujours dans la variante dite « optimisée », la transmission du message comprend en outre une seconde pseudo-méthode, dont les en-têtes occupent (disons) 100 octets et de longueur totale 1000 octets, libellée comme suit : 5 SEGMENT 200 OK Via: SI P/2.0/UDP 80.12.197.184:5060; bra nch=z9hG4bK I M5CA0720430.000 33323c28bbb663570d434d94f66752e3; Segment-Size: 901-1400 / 1400 SIP-PDU-Id: fsdRET6hrtL45 10 où, puisque le contenu de la méthode SIP 200 OK (c'est-à-dire le corps du message) comprend 1200 octets : 15 M2 = 1200 - M1 = 500 octets. On notera que la première ligne, ainsi que les en-têtes de routage, des pseudo-méthodes SEGMENT sont différents pour l'encapsulation d'une requête SIP par comparaison avec une réponse SIP, car le routage des requêtes et des réponses selon le protocole SIP n'exploite pas les mêmes informations. 20 En variante, on peut s'abstenir de distinguer les requêtes des réponses dans la pseudo-méthode SEGMENT, auquel cas seuls les en-têtes « SegmentSize » et « SIP-PDU-Id » seront présents. La première ligne (Request-URI) de la pseudo-méthode SEGMENT contient alors l'adresse de contact du prochain noeud SIP. 25 La compatibilité d'un noeud du réseau IP avec la présente invention peut être commodément indiquée dans l'en-tête SIP « Allow » (connu en soi). Aucun mécanisme nouveau de négociation n'est nécessaire à cet effet : si un noeud actif au niveau SIP veut découvrir la compatibilité d'un correspondant avec la pseudo-méthode SEGMENT sur un « hop SIP », il lui suffit d'émettre une 30 méthode OPTIONS avec l'en-tête « Max-Fowards » valorisé à 1 ; si la réponse du correspondant inclut un en-tête SIP « Allow » mentionnant la pseudo-méthode 3059504 18 SEGMENT (en plus des méthodes SIP acceptées par ce noeud), c'est que le correspondant est compatible avec cette pseudo-méthode. De manière générale, la présente invention peut être mise en oeuvre au sein des noeuds d'un réseau IP, au moyen de composants logiciels et/ou 5 matériels. Les composants logiciels pourront être intégrés à un programme d'ordinateur classique de gestion de noeud de réseau. C'est pourquoi, comme indiqué ci-dessus, la présente invention concerne également un système informatique. Ce système informatique comporte de manière classique une unité 10 centrale de traitement commandant par des signaux une mémoire, ainsi qu'une unité d'entrée et une unité de sortie. De plus, ce système informatique peut être utilisé pour exécuter un programme d'ordinateur comportant des instructions pour la mise en oeuvre de l'un quelconque des procédés de fractionnement selon l'invention. 15 En effet, l'invention vise aussi un programme d'ordinateur téléchargeable depuis un réseau de communication comprenant des instructions pour l'exécution des étapes d'un procédé de fractionnement selon l'invention, lorsqu'il est exécuté sur un ordinateur. Ce programme d'ordinateur peut être stocké sur un support lisible par ordinateur et peut être exécutable par un microprocesseur. 20 Ce programme peut utiliser n'importe quel langage de programmation, et se présenter sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations, inamovible, ou 25 partiellement ou totalement amovible, lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comprendre un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de 30 circuit microélectronique, ou un moyen d'enregistrement magnétique, tel qu'un disque dur, ou encore une clé USB (« USB flash drive » en anglais). D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble 3059504 19 électrique ou optique, par radio ou par d'autres moyens. Le programme d'ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. En variante, le support d'informations peut être un circuit intégré dans 5 lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution de l'un quelconque des procédés de fractionnement selon l'invention. REVENDICATIONS1. Procédé de fractionnement de messages applicatifs dans un réseau IP (Internet Protocol), comprenant les étapes suivantes : a) un noeud du réseau IP, dit premier noeud, reçoit un message devant être transmis à un autre noeud du réseau IP, dit second noeud, b) ledit premier noeud compare la longueur dudit message avec la taille maximum de transmission MTU (Maximum Transmission Unit) caractérisant le chemin entre ledit premier noeud et ledit second noeud, et, si ladite longueur est supérieure à la MTU, c) le premier noeud fractionne le message en au moins deux segments, et insère chaque segment respectif dans un paquet de données respectif de longueur inférieure ou égale à la MTU, d) le premier noeud transmet lesdits paquets de données au second noeud, et e) le second noeud assemble lesdits segments de manière à reconstituer ledit message, caractérisé en ce que, ledit message étant un message applicatif : - lors de ladite étape c), le premier noeud insère dans chacun desdits paquets de données (SEGMENT) une information (Segment-Size) dite de positionnement précisant la position relative dans le message du segment inséré dans ce paquet de données, et - lors de ladite étape e), le second noeud reconstitue le message à l'aide desdites informations de positionnement (Segment-Size). 2. Procédé de fractionnement selon la revendication 1, caractérisé en ce que chacun desdits paquets de données comprend l'ensemble des informations obligatoires dans le cadre de l'application informatique régissant ledit message. 3. Procédé de fractionnement selon la revendication 1, caractérisé en ce 30 que chacun desdits paquets de données comprend : - des informations de routage limitées aux informations nécessaires au routage du paquet de données vers ledit second noeud, et - un champ dédié (SIP-PDU-Id) contenant un identifiant dudit message. 3059504 21 4. Procédé de fractionnement selon l'une quelconque des revendications 1 à 3, caractérisé en ce que l'application informatique régissant ledit message est le protocole de contrôle de session SIP (Session Initiation Protocol). 5 5. Noeud d'un réseau IP (Internet Protocol), dit premier noeud, comprenant des moyens pour, suite à la réception d'un message devant être transmis à un autre noeud du réseau IP, dit second noeud : - comparer la longueur dudit message avec la taille maximum de 10 transmission MTU (Maximum Transmission Unit) caractérisant le chemin entre ledit premier noeud et ledit second noeud, - fractionner le message en au moins deux segments, - insérer chaque segment respectif dans un paquet de données respectif de longueur inférieure ou égale à la MTU, et 15 - transmettre lesdits paquets de données au second noeud, caractérisé en ce que, ledit message étant un message applicatif, ledit premier noeud comprend en outre des moyens pour insérer dans chaque paquet de données (SEGMENT) une information (Segment-Size) dite de positionnement précisant la position relative dans le message du segment inséré dans ce paquet 20 de données. 6. Noeud d'un réseau IP selon la revendication 5, caractérisé en ce que chacun desdits paquets de données comprend l'ensemble des informations obligatoires dans le cadre de l'application informatique régissant ledit message. 25 7. Noeud d'un réseau IP selon la revendication 5, caractérisé en ce que chacun desdits paquets de données comprend : - des informations de routage limitées aux informations nécessaires au routage du paquet de données vers ledit second noeud, et - un champ dédié (SIP-PDU-Id) contenant un identifiant dudit message. 8. Noeud d'un réseau IP (Internet Protocol), dit second noeud, comprenant des moyens pour : - recevoir des paquets de données (SEGMENT), et 3059504 22 - extraire de chaque paquet de données un segment de message, caractérisé en ce que, ledit message étant un message applicatif, ledit second noeud comprend en outre des moyens pour : - prendre en compte, dans chacun desdits paquets de données 5 (SEGMENT), une information (Segment-Size) dite de positionnement précisant la position relative dans le message du segment extrait de ce paquet de données, et - utiliser lesdites informations de positionnement (Segment-Size) pour assembler les segments d'un même message. 10 9. Noeud d'un réseau IP selon l'une quelconque des revendications 5 à 8, caractérisé en ce qu'il est actif au niveau SIP (Session Initiation Protocol). 10. Noeud d'un réseau IP selon l'une quelconque des revendications 5 à 15 9, caractérisé en ce qu'il comprend des moyens pour transmettre à un autre noeud IP la taille maximum de transmission MTU (Maximum Transmission Unit) caractérisant le chemin entre ces deux noeuds. 11. Système de communication de messages applicatifs dans un réseau 20 IP (Internet Protocol), comprenant : - au moins un premier noeud selon l'une quelconque des revendications 5 à 7, et - au moins un second noeud selon la revendication 8. 25