A quel moment, une découverte du MTU d'un chemin est-elle déclenchée ? A
toute ouverture de connexion TCP ?
Un autre point m'interroge : comme on est en mode non connecté, comment
est-on sûr que le chemin prospecté par la procédure sera celui suivi par
tous les datagrammes de la connexion ?
Merci beaucoup pour les avis ou commentaires
Cordialement,
Angelot
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jacques Caron
Salut,
On Thu, 17 Jun 2004 16:04:33 +0200, Angelot wrote:
A quel moment, une découverte du MTU d'un chemin est-elle déclenchée ? A toute ouverture de connexion TCP ?
Oui, mais il y généralement un cache qui permet d'éviter de le faire à chaque fois (il y a d'ailleurs une méthode d'attaque connue sur ce point, mais qui est quasiment inexploitable). Evidemment, ça ne se fait pas si pMTUd a été désactivé (on utilise alors la MSS négociée entre les deux extrémités on ne positionne pas DF).
Un autre point m'interroge : comme on est en mode non connecté, comment est-on sûr que le chemin prospecté par la procédure sera celui suivi par tous les datagrammes de la connexion ?
On n'est pas sûr, on suppose que le chemin reste à peu près stable, et si je ne m'abuse on continue à émettre avec DF et à écouter les ICMP qui pourraient revenir, ce qui fait que le cas où la MTU sur le chemin baisse sera géré. Si la MTU augmente, on n'en profitera pas, tant pis.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On Thu, 17 Jun 2004 16:04:33 +0200, Angelot <OnSePame@KesceKonSePame.fr>
wrote:
A quel moment, une découverte du MTU d'un chemin est-elle déclenchée ? A
toute ouverture de connexion TCP ?
Oui, mais il y généralement un cache qui permet d'éviter de le faire à
chaque fois (il y a d'ailleurs une méthode d'attaque connue sur ce point,
mais qui est quasiment inexploitable). Evidemment, ça ne se fait pas si
pMTUd a été désactivé (on utilise alors la MSS négociée entre les deux
extrémités on ne positionne pas DF).
Un autre point m'interroge : comme on est en mode non connecté, comment
est-on sûr que le chemin prospecté par la procédure sera celui suivi par
tous les datagrammes de la connexion ?
On n'est pas sûr, on suppose que le chemin reste à peu près stable, et si
je ne m'abuse on continue à émettre avec DF et à écouter les ICMP qui
pourraient revenir, ce qui fait que le cas où la MTU sur le chemin baisse
sera géré. Si la MTU augmente, on n'en profitera pas, tant pis.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Thu, 17 Jun 2004 16:04:33 +0200, Angelot wrote:
A quel moment, une découverte du MTU d'un chemin est-elle déclenchée ? A toute ouverture de connexion TCP ?
Oui, mais il y généralement un cache qui permet d'éviter de le faire à chaque fois (il y a d'ailleurs une méthode d'attaque connue sur ce point, mais qui est quasiment inexploitable). Evidemment, ça ne se fait pas si pMTUd a été désactivé (on utilise alors la MSS négociée entre les deux extrémités on ne positionne pas DF).
Un autre point m'interroge : comme on est en mode non connecté, comment est-on sûr que le chemin prospecté par la procédure sera celui suivi par tous les datagrammes de la connexion ?
On n'est pas sûr, on suppose que le chemin reste à peu près stable, et si je ne m'abuse on continue à émettre avec DF et à écouter les ICMP qui pourraient revenir, ce qui fait que le cas où la MTU sur le chemin baisse sera géré. Si la MTU augmente, on n'en profitera pas, tant pis.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Eric Masson
"Angelot" == Angelot writes:
'Lut,
Angelot> A quel moment, une découverte du MTU d'un chemin est-elle Angelot> déclenchée ?
Tu ne déclenches pas la découverte du pmtu. Un routeur sur le chemin t'indique via icmp qu'il ne peut traiter ton paquet pour cause de mtu trop important dans le cas ou le bit DF est actif.
ipv6 définit explicitement la notion de pmtu et de découverte de celui-ci dans la rfc1981.
Angelot> A toute ouverture de connexion TCP ?
Le mtu est lié à ip, pas à tcp.
Angelot> Un autre point m'interroge : comme on est en mode non Angelot> connecté, comment est-on sûr que le chemin prospecté par la Angelot> procédure sera celui suivi par tous les datagrammes de la Angelot> connexion ?
Tu ne peux pas l'être, mis à part si tu fais du source routing, mais sachant que la majorité des routeurs sont paramétrés pour refuser les options de routage par la source de nos jours (drop du paquet ou ignore des options), tu te retrouves dans le cas précédent. Par conséquent, le pmtu peut varier en cours de transmission entre deux points.
Eric Masson
-- Bientôt, Apple ne va plus que fournir les plans sous microfilms coincés sur le proc : le but sera de les en déloger avant d'allumer la machine, sinon ça fond ! Comme à Fort Boyard... -+- SP in Guide du Macounet Pervers :The name is Bond, James Bond -+-
Angelot> A quel moment, une découverte du MTU d'un chemin est-elle
Angelot> déclenchée ?
Tu ne déclenches pas la découverte du pmtu. Un routeur sur le chemin
t'indique via icmp qu'il ne peut traiter ton paquet pour cause de mtu
trop important dans le cas ou le bit DF est actif.
ipv6 définit explicitement la notion de pmtu et de découverte de
celui-ci dans la rfc1981.
Angelot> A toute ouverture de connexion TCP ?
Le mtu est lié à ip, pas à tcp.
Angelot> Un autre point m'interroge : comme on est en mode non
Angelot> connecté, comment est-on sûr que le chemin prospecté par la
Angelot> procédure sera celui suivi par tous les datagrammes de la
Angelot> connexion ?
Tu ne peux pas l'être, mis à part si tu fais du source routing, mais
sachant que la majorité des routeurs sont paramétrés pour refuser les
options de routage par la source de nos jours (drop du paquet ou ignore
des options), tu te retrouves dans le cas précédent. Par conséquent, le
pmtu peut varier en cours de transmission entre deux points.
Eric Masson
--
Bientôt, Apple ne va plus que fournir les plans sous microfilms coincés
sur le proc : le but sera de les en déloger avant d'allumer la machine,
sinon ça fond ! Comme à Fort Boyard...
-+- SP in Guide du Macounet Pervers :The name is Bond, James Bond -+-
Angelot> A quel moment, une découverte du MTU d'un chemin est-elle Angelot> déclenchée ?
Tu ne déclenches pas la découverte du pmtu. Un routeur sur le chemin t'indique via icmp qu'il ne peut traiter ton paquet pour cause de mtu trop important dans le cas ou le bit DF est actif.
ipv6 définit explicitement la notion de pmtu et de découverte de celui-ci dans la rfc1981.
Angelot> A toute ouverture de connexion TCP ?
Le mtu est lié à ip, pas à tcp.
Angelot> Un autre point m'interroge : comme on est en mode non Angelot> connecté, comment est-on sûr que le chemin prospecté par la Angelot> procédure sera celui suivi par tous les datagrammes de la Angelot> connexion ?
Tu ne peux pas l'être, mis à part si tu fais du source routing, mais sachant que la majorité des routeurs sont paramétrés pour refuser les options de routage par la source de nos jours (drop du paquet ou ignore des options), tu te retrouves dans le cas précédent. Par conséquent, le pmtu peut varier en cours de transmission entre deux points.
Eric Masson
-- Bientôt, Apple ne va plus que fournir les plans sous microfilms coincés sur le proc : le but sera de les en déloger avant d'allumer la machine, sinon ça fond ! Comme à Fort Boyard... -+- SP in Guide du Macounet Pervers :The name is Bond, James Bond -+-
Angelot
"Eric Masson" a écrit dans le message de news:
"Angelot" == Angelot writes:
'Lut,
Angelot> A quel moment, une découverte du MTU d'un chemin est-elle Angelot> déclenchée ?
Tu ne déclenches pas la découverte du pmtu. Un routeur sur le chemin t'indique via icmp qu'il ne peut traiter ton paquet pour cause de mtu trop important dans le cas ou le bit DF est actif.
Je continue la phrase que vous interrompez.
...et dans le cas où DF est inactif, le routeur fragmente sans envoyer ICMP.
Ma question était : comment la découverte du MTU est-elle mise en oeuvre pour éviter la fragmentation qui entache les performances du routeur et de la transmission ?
Angelot> A toute ouverture de connexion TCP ?
Le mtu est lié à ip, pas à tcp.
Je suis entièrement d'accord, et ma question concernait le processus de découverte du MTU sur un chemin allant de l'adresse origine à l'adresse de destination.
Angelot> Un autre point m'interroge : comme on est en mode non Angelot> connecté, comment est-on sûr que le chemin prospecté par la Angelot> procédure sera celui suivi par tous les datagrammes de la Angelot> connexion ?
Tu ne peux pas l'être, mis à part si tu fais du source routing, mais sachant que la majorité des routeurs sont paramétrés pour refuser les options de routage par la source de nos jours (drop du paquet ou ignore des options), tu te retrouves dans le cas précédent. Par conséquent, le pmtu peut varier en cours de transmission entre deux points.
Merci pour ce point.
Un détail, lorsqu'une connexion TCP est ouverte en utilisant IP sur ATM par l'ouverture d'une connexion SVC, le routage à la source est utilisé pour créer ce SVC. Le protocole PNNI utilise le routage à la source avec la procédure de retour de manivelle si cela coince (mais nous sommes en ATM avec, par exemple, IP sur ATM).
Cordialement, Angelot
"Eric Masson" <emss@free.fr> a écrit dans le message de news:
86brjimepx.fsf@srvbsdnanssv.interne.kisoft-services.com...
Angelot> A quel moment, une découverte du MTU d'un chemin est-elle
Angelot> déclenchée ?
Tu ne déclenches pas la découverte du pmtu. Un routeur sur le chemin
t'indique via icmp qu'il ne peut traiter ton paquet pour cause de mtu
trop important dans le cas ou le bit DF est actif.
Je continue la phrase que vous interrompez.
...et dans le cas où DF est inactif, le routeur fragmente sans envoyer ICMP.
Ma question était : comment la découverte du MTU est-elle mise en oeuvre
pour éviter la fragmentation qui entache les performances du routeur et de
la transmission ?
Angelot> A toute ouverture de connexion TCP ?
Le mtu est lié à ip, pas à tcp.
Je suis entièrement d'accord, et ma question concernait le processus de
découverte du MTU sur un chemin allant de l'adresse origine à l'adresse de
destination.
Angelot> Un autre point m'interroge : comme on est en mode non
Angelot> connecté, comment est-on sûr que le chemin prospecté par la
Angelot> procédure sera celui suivi par tous les datagrammes de la
Angelot> connexion ?
Tu ne peux pas l'être, mis à part si tu fais du source routing, mais
sachant que la majorité des routeurs sont paramétrés pour refuser les
options de routage par la source de nos jours (drop du paquet ou ignore
des options), tu te retrouves dans le cas précédent. Par conséquent, le
pmtu peut varier en cours de transmission entre deux points.
Merci pour ce point.
Un détail, lorsqu'une connexion TCP est ouverte en utilisant IP sur ATM par
l'ouverture d'une connexion SVC, le routage à la source est utilisé pour
créer ce SVC. Le protocole PNNI utilise le routage à la source avec la
procédure de retour de manivelle si cela coince (mais nous sommes en ATM
avec, par exemple, IP sur ATM).
Angelot> A quel moment, une découverte du MTU d'un chemin est-elle Angelot> déclenchée ?
Tu ne déclenches pas la découverte du pmtu. Un routeur sur le chemin t'indique via icmp qu'il ne peut traiter ton paquet pour cause de mtu trop important dans le cas ou le bit DF est actif.
Je continue la phrase que vous interrompez.
...et dans le cas où DF est inactif, le routeur fragmente sans envoyer ICMP.
Ma question était : comment la découverte du MTU est-elle mise en oeuvre pour éviter la fragmentation qui entache les performances du routeur et de la transmission ?
Angelot> A toute ouverture de connexion TCP ?
Le mtu est lié à ip, pas à tcp.
Je suis entièrement d'accord, et ma question concernait le processus de découverte du MTU sur un chemin allant de l'adresse origine à l'adresse de destination.
Angelot> Un autre point m'interroge : comme on est en mode non Angelot> connecté, comment est-on sûr que le chemin prospecté par la Angelot> procédure sera celui suivi par tous les datagrammes de la Angelot> connexion ?
Tu ne peux pas l'être, mis à part si tu fais du source routing, mais sachant que la majorité des routeurs sont paramétrés pour refuser les options de routage par la source de nos jours (drop du paquet ou ignore des options), tu te retrouves dans le cas précédent. Par conséquent, le pmtu peut varier en cours de transmission entre deux points.
Merci pour ce point.
Un détail, lorsqu'une connexion TCP est ouverte en utilisant IP sur ATM par l'ouverture d'une connexion SVC, le routage à la source est utilisé pour créer ce SVC. Le protocole PNNI utilise le routage à la source avec la procédure de retour de manivelle si cela coince (mais nous sommes en ATM avec, par exemple, IP sur ATM).
Cordialement, Angelot
Angelot
Merci Jacques pour ces remarques,
(on utilise alors la MSS négociée entre les deux extrémités on ne positionne pas DF).
Si pMTUd est désactivité, on peut supposer que MSS est mis à jour grâce à l'indication du distant qui a reçu un datagramme fragmenté.
Cordialement, Angelot
Merci Jacques pour ces remarques,
(on utilise alors la MSS négociée entre les deux
extrémités on ne positionne pas DF).
Si pMTUd est désactivité, on peut supposer que MSS est mis à jour grâce à
l'indication du distant qui a reçu un datagramme fragmenté.
(on utilise alors la MSS négociée entre les deux extrémités on ne positionne pas DF).
Si pMTUd est désactivité, on peut supposer que MSS est mis à jour grâce à l'indication du distant qui a reçu un datagramme fragmenté.
Cordialement, Angelot
Eric Masson
"Angelot" == Angelot writes:
'Lut,
Angelot> Ma question était : comment la découverte du MTU est-elle mise Angelot> en oeuvre pour éviter la fragmentation qui entache les Angelot> performances du routeur et de la transmission ?
Rien actuellement n'existe en termes de standard pour la gestion du pmtu, on peut par contre trouver un draft sur le sujet : http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-01.txt
Cisco propose le papier suivant qui semble assez exhaustif : http://www.cisco.com/warp/public/105/pmtud_ipfrag.html#second
Angelot> Un détail, lorsqu'une connexion TCP est ouverte en utilisant Angelot> IP sur ATM par l'ouverture d'une connexion SVC, le routage à Angelot> la source est utilisé pour créer ce SVC.
Sur ce point, désolé, je ne peux pas répondre, ne connaissant pas ATM, Jacques ?
Eric Masson
-- Il y en a qui ne savent pas déballer leur ordinateur de la boîte d'emballage. Faudrait aussi prévoir une doc là-dessus (parce que celle fournie avec la boîte, il y a plein de mots et pas beaucoup d'images) -+- Jaco in Guide du Linuxien pervers - "[OUI] à fcol.deballage" -+-
Angelot> Ma question était : comment la découverte du MTU est-elle mise
Angelot> en oeuvre pour éviter la fragmentation qui entache les
Angelot> performances du routeur et de la transmission ?
Rien actuellement n'existe en termes de standard pour la gestion du
pmtu, on peut par contre trouver un draft sur le sujet :
http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-01.txt
Cisco propose le papier suivant qui semble assez exhaustif :
http://www.cisco.com/warp/public/105/pmtud_ipfrag.html#second
Angelot> Un détail, lorsqu'une connexion TCP est ouverte en utilisant
Angelot> IP sur ATM par l'ouverture d'une connexion SVC, le routage à
Angelot> la source est utilisé pour créer ce SVC.
Sur ce point, désolé, je ne peux pas répondre, ne connaissant pas ATM,
Jacques ?
Eric Masson
--
Il y en a qui ne savent pas déballer leur ordinateur de la boîte
d'emballage. Faudrait aussi prévoir une doc là-dessus (parce que celle
fournie avec la boîte, il y a plein de mots et pas beaucoup d'images)
-+- Jaco in Guide du Linuxien pervers - "[OUI] à fcol.deballage" -+-
Angelot> Ma question était : comment la découverte du MTU est-elle mise Angelot> en oeuvre pour éviter la fragmentation qui entache les Angelot> performances du routeur et de la transmission ?
Rien actuellement n'existe en termes de standard pour la gestion du pmtu, on peut par contre trouver un draft sur le sujet : http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-01.txt
Cisco propose le papier suivant qui semble assez exhaustif : http://www.cisco.com/warp/public/105/pmtud_ipfrag.html#second
Angelot> Un détail, lorsqu'une connexion TCP est ouverte en utilisant Angelot> IP sur ATM par l'ouverture d'une connexion SVC, le routage à Angelot> la source est utilisé pour créer ce SVC.
Sur ce point, désolé, je ne peux pas répondre, ne connaissant pas ATM, Jacques ?
Eric Masson
-- Il y en a qui ne savent pas déballer leur ordinateur de la boîte d'emballage. Faudrait aussi prévoir une doc là-dessus (parce que celle fournie avec la boîte, il y a plein de mots et pas beaucoup d'images) -+- Jaco in Guide du Linuxien pervers - "[OUI] à fcol.deballage" -+-
Jacques Caron
On Thu, 17 Jun 2004 19:52:07 +0200, Angelot wrote:
(on utilise alors la MSS négociée entre les deux extrémités on ne positionne pas DF).
Si pMTUd est désactivité, on peut supposer que MSS est mis à jour grâce à l'indication du distant qui a reçu un datagramme fragmenté.
Euh, je ne suis pas sûr que ça existe ça?
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
On Thu, 17 Jun 2004 19:52:07 +0200, Angelot <OnSePame@KesceKonSePame.fr>
wrote:
(on utilise alors la MSS négociée entre les deux
extrémités on ne positionne pas DF).
Si pMTUd est désactivité, on peut supposer que MSS est mis à jour grâce à
l'indication du distant qui a reçu un datagramme fragmenté.
Euh, je ne suis pas sûr que ça existe ça?
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Thu, 17 Jun 2004 19:52:07 +0200, Angelot wrote:
(on utilise alors la MSS négociée entre les deux extrémités on ne positionne pas DF).
Si pMTUd est désactivité, on peut supposer que MSS est mis à jour grâce à l'indication du distant qui a reçu un datagramme fragmenté.
Euh, je ne suis pas sûr que ça existe ça?
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Jacques Caron
Salut,
On Thu, 17 Jun 2004 19:28:05 +0200, Angelot wrote:
Ma question était : comment la découverte du MTU est-elle mise en oeuvre pour éviter la fragmentation qui entache les performances du routeur et de la transmission ?
Euh, je ne suis pas sûr que je comprenne la question... pMTUd est un processus inhérent à TCP (même s'il peut être utilisé pour d'autres, à ma connaissance ce n'est pas quelque chose de standard). Si pMTUd est actif, TCP négocie MSS avec la machine de destination, vérifie dans le cache s'il n'a pas une MTU inférieure, puis commence à envoyer des paquets avec la MSS négociée et DF à 1. Si un routeur sur le chemin doit fragmenter, il ne le fait pas, renvoie un ICMP "need to fragment but DF set" à la source, avec la nouvelle MTU. La source change la MSS en conséquence, et recommence, jusqu'à ce que ça arrive à destination.
Donc la MTU découverte est immédiatement utilisée (sauf si les messages ICMP kivonbien sont filtrés, et là, ça ne marche pas du tout).
Tous les détails ici:
http://www.ietf.org/rfc/rfc1191.txt
Un détail, lorsqu'une connexion TCP est ouverte en utilisant IP sur ATM par l'ouverture d'une connexion SVC, le routage à la source est utilisé pour créer ce SVC.
Le routage à la source au niveau ATM, pas au niveau IP. D'ailleurs, je n'ai jamais utilisé de SVC (uniquement des PVC) en ATM, mais je ne suis pas convaincu qu'un routage à la source à la création du SVC soit obligatoire, si?
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On Thu, 17 Jun 2004 19:28:05 +0200, Angelot <OnSePame@KesceKonSePame.fr>
wrote:
Ma question était : comment la découverte du MTU est-elle mise en oeuvre
pour éviter la fragmentation qui entache les performances du routeur et
de la transmission ?
Euh, je ne suis pas sûr que je comprenne la question... pMTUd est un
processus inhérent à TCP (même s'il peut être utilisé pour d'autres, à ma
connaissance ce n'est pas quelque chose de standard). Si pMTUd est actif,
TCP négocie MSS avec la machine de destination, vérifie dans le cache s'il
n'a pas une MTU inférieure, puis commence à envoyer des paquets avec la
MSS négociée et DF à 1. Si un routeur sur le chemin doit fragmenter, il ne
le fait pas, renvoie un ICMP "need to fragment but DF set" à la source,
avec la nouvelle MTU. La source change la MSS en conséquence, et
recommence, jusqu'à ce que ça arrive à destination.
Donc la MTU découverte est immédiatement utilisée (sauf si les messages
ICMP kivonbien sont filtrés, et là, ça ne marche pas du tout).
Tous les détails ici:
http://www.ietf.org/rfc/rfc1191.txt
Un détail, lorsqu'une connexion TCP est ouverte en utilisant IP sur ATM
par l'ouverture d'une connexion SVC, le routage à la source est utilisé
pour
créer ce SVC.
Le routage à la source au niveau ATM, pas au niveau IP. D'ailleurs, je
n'ai jamais utilisé de SVC (uniquement des PVC) en ATM, mais je ne suis
pas convaincu qu'un routage à la source à la création du SVC soit
obligatoire, si?
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Thu, 17 Jun 2004 19:28:05 +0200, Angelot wrote:
Ma question était : comment la découverte du MTU est-elle mise en oeuvre pour éviter la fragmentation qui entache les performances du routeur et de la transmission ?
Euh, je ne suis pas sûr que je comprenne la question... pMTUd est un processus inhérent à TCP (même s'il peut être utilisé pour d'autres, à ma connaissance ce n'est pas quelque chose de standard). Si pMTUd est actif, TCP négocie MSS avec la machine de destination, vérifie dans le cache s'il n'a pas une MTU inférieure, puis commence à envoyer des paquets avec la MSS négociée et DF à 1. Si un routeur sur le chemin doit fragmenter, il ne le fait pas, renvoie un ICMP "need to fragment but DF set" à la source, avec la nouvelle MTU. La source change la MSS en conséquence, et recommence, jusqu'à ce que ça arrive à destination.
Donc la MTU découverte est immédiatement utilisée (sauf si les messages ICMP kivonbien sont filtrés, et là, ça ne marche pas du tout).
Tous les détails ici:
http://www.ietf.org/rfc/rfc1191.txt
Un détail, lorsqu'une connexion TCP est ouverte en utilisant IP sur ATM par l'ouverture d'une connexion SVC, le routage à la source est utilisé pour créer ce SVC.
Le routage à la source au niveau ATM, pas au niveau IP. D'ailleurs, je n'ai jamais utilisé de SVC (uniquement des PVC) en ATM, mais je ne suis pas convaincu qu'un routage à la source à la création du SVC soit obligatoire, si?
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Angelot
Merci Jacques,
Le routage à la source au niveau ATM, pas au niveau IP. D'ailleurs, je n'ai jamais utilisé de SVC (uniquement des PVC) en ATM, mais je ne suis pas convaincu qu'un routage à la source à la création du SVC soit obligatoire, si?
PNNI est en fait assez courant, et s'utilise dans les réseaux publics, bien que P = private. Attention, il existe des PVC à l'interface UNI qui se prolongent en SVC aux interfaces NNI, ça doit s'appeler soft PVC (la durée de SVC est dans ce cas celle du PVC de l'utilisateur). Le routage à la source pour ATM me semblerait nécessaire car il faut négocier à chaque commutateur le contrat de trafic, c'est à dire le triplet capacité de transfert, descripteur de trafic, qualité de service.
Cordialement, Angelot
Merci Jacques,
Le routage à la source au niveau ATM, pas au niveau IP. D'ailleurs, je
n'ai jamais utilisé de SVC (uniquement des PVC) en ATM, mais je ne suis
pas convaincu qu'un routage à la source à la création du SVC soit
obligatoire, si?
PNNI est en fait assez courant, et s'utilise dans les réseaux publics, bien
que P = private. Attention, il existe des PVC à l'interface UNI qui se
prolongent en SVC aux interfaces NNI, ça doit s'appeler soft PVC (la durée
de SVC est dans ce cas celle du PVC de l'utilisateur). Le routage à la
source pour ATM me semblerait nécessaire car il faut négocier à chaque
commutateur le contrat de trafic, c'est à dire le triplet capacité de
transfert, descripteur de trafic, qualité de service.
Le routage à la source au niveau ATM, pas au niveau IP. D'ailleurs, je n'ai jamais utilisé de SVC (uniquement des PVC) en ATM, mais je ne suis pas convaincu qu'un routage à la source à la création du SVC soit obligatoire, si?
PNNI est en fait assez courant, et s'utilise dans les réseaux publics, bien que P = private. Attention, il existe des PVC à l'interface UNI qui se prolongent en SVC aux interfaces NNI, ça doit s'appeler soft PVC (la durée de SVC est dans ce cas celle du PVC de l'utilisateur). Le routage à la source pour ATM me semblerait nécessaire car il faut négocier à chaque commutateur le contrat de trafic, c'est à dire le triplet capacité de transfert, descripteur de trafic, qualité de service.
Cordialement, Angelot
Angelot
Merci Eric,
Rien actuellement n'existe en termes de standard pour la gestion du pmtu, on peut par contre trouver un draft sur le sujet : http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-01.txt
Cisco propose le papier suivant qui semble assez exhaustif : http://www.cisco.com/warp/public/105/pmtud_ipfrag.html#second
De la lecture pour ce week end : d'ailleurs ici, le temps tourne à la pluie, ça permettra finalement d'arroser les jardins de fleurs et de connaissances. Tout cela est bien sec !
Cordialement, Angelot
Merci Eric,
Rien actuellement n'existe en termes de standard pour la gestion du
pmtu, on peut par contre trouver un draft sur le sujet :
http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-01.txt
Cisco propose le papier suivant qui semble assez exhaustif :
http://www.cisco.com/warp/public/105/pmtud_ipfrag.html#second
De la lecture pour ce week end : d'ailleurs ici, le temps tourne à la pluie,
ça permettra finalement d'arroser les jardins de fleurs et de connaissances.
Tout cela est bien sec !
Rien actuellement n'existe en termes de standard pour la gestion du pmtu, on peut par contre trouver un draft sur le sujet : http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-01.txt
Cisco propose le papier suivant qui semble assez exhaustif : http://www.cisco.com/warp/public/105/pmtud_ipfrag.html#second
De la lecture pour ce week end : d'ailleurs ici, le temps tourne à la pluie, ça permettra finalement d'arroser les jardins de fleurs et de connaissances. Tout cela est bien sec !
