Nous avons vu dans une précédente vidéo l'importance du TUID de l'identification de l'extrémité d'un tunnel. Comment faire pour établir un tunnel et que les deux extrémités connaissent les deux TUID ? Comment le traitement des paquets est-il fait une fois que le tunnel est établi ? Telles sont les questions auxquelles nous allons répondre dans cette vidéo. Si nous regardons comment initialiser un tunnel, le Serving Gateway par exemple va choisir une nouvelle valeur de TUID, qui est unique: 102, va envoyer un message de demande d'établissement d'un tunnel en disant " nouveau tunnel avec le TUID 102". Le P Gateway va à son tour choisir une nouvelle valeur, qui va être localement unique, de TUID. Dans mon exemple 26 538. Il va stocker l'adresse de l'expéditeur, l'adresse du Serving Gateway, et stocker également la valeur de TUID reçue. Et il va faire le lien entre 26 538 et 102. Il envoie, le P Gateway, un message d'acquittement, avec les deux TUID. De cette façon-là le Serving Gateway connaît la correspondance entre son identité de tunnel et l'identité de tunnel allouée par le P Gateway. À la fin de cet échange on a bien un tunnel qui est établi avec d'un côté le 102, comme TUID, et de l'autre côté le 16 538. On peut noter qu'à la fin de l'échange chaque extrémité connaît le TUID alloué par l'entité en vis à vis. Allons un petit peu plus loin pour regarder quel est le traitement à faire dans le Serving Gateway. Eh bien nous allons avoir un traitement relativement simple, à partir du moment où on constitue une table. Ce qui est expliqué dans la suite est valable sur le plan du principe. Je ne prétends pas que l'implémentation concrète dans le Serving Gateway est exactement comme celle-là , mais elle permet de bien comprendre comment on gère les TUID et comment on aboute différents tunnels. Nous allons avoir dans la table du Serving Gateway les valeurs de TUID, les actions à effectuer, éventuellement des précisions sur ces actions et on va indiquer quel est le tunnel de l'entité père. C'est-à -dire pour le Serving Gateway l'entité père est le P Gateway, et on va indiquer quelle est son adresse et quelle est la valeur du TUID. Un petit exemple. Lorsque le Serving Gateway établit le tunnel il indique TUID 102, on va donc créer une entrée dans la table 102, c'est la table du Serving Gateway, et une fois que la P Gateway a bien répondu eh bien on sait, comme on a reçu un paquet du paquet du P Gateway on connaît forcément son adresse, on sait quelle est l'adresse du P Gateway, et on sait que le P Gateway a alloué le TUID 16 538. Si on regarde le tunnel est bien établi. Maintenant on peut avoir un tunnel entre un Serving Gateway et l'eNodeB. Ce tunnel par exemple est établi en utilisant le numéro 103 comme TUID, l'adresse correspondante va être l'adresse de l'eNodeB, eNodeB 2 dans notre exemple, et le TUID a la valeur 65 551. C'est le TUID qui a été choisi par l'eNodeB 2. Les traitements qui vont être remplis. Si on considère que tout paquet arrivant sur le tunnel 103 doit être renvoyé vers le tunnel 102, eh bien l'action ça va être une action de retransmission ou Forwarding, et le détail on va indiquer lorsqu'on Forward du tunnel 102 on va retransmettre vers le tunnel 103, et du tunnel 103 on va retransmettre vers le tunnel 102. Si nous regardons les traitements, eh bien ça veut dire qu'un paquet qui arrive par exemple de l'eNobeB 2 va contenir le TUID 103. Le Serving Gateway regarde 103, il voit, il faut que je retransmette le paquet. Je le retransmets vers le tunnel 102, et ce tunnel 102 à quoi correspond-il ? Il correspond au packet et au tunnel 16 538 pour ce packet gateway. Donc tout paquet que je reçois avec le TUID 103 je le renvoie vers le packet gateway avec le TUID 16 538. Les principes du tunnel et l'utilisation de cette table, nous les avons vus pour les paquets descendants, ils sont aussi valables pour les paquets montants, et ils sont valables de façon générale. Plusieurs exercices vont vous permettre de bien assimiler cette notion de TUID.
