@irs 

Architecture Intégrée de Réseaux et Services

LIAISON SATELLITE

Architecture intégrée de réseaux et de services

Mesures de trafic RC INRIA

Sous-projets

 
 

Contact: 
    Rafael Rizo
    Walid Dabbous
1. ARCHITECTURE DU RESEAU INTEGRANT DES LIENS SATELLITES

Figure1 : Architecture général du réseau intégrant la liaison satellite

      L'architecture du réseau dans le cadre du projet @IRS est constitué par  une station montante située à l'INRIA Sophia Antipolis 
et des récepteurs situés dans les différents sites des différentes partenaires du projet. Dans cette configuration le réseau satellite est
un réseau à diffusion (multipoint) qui interconnecte des routers dans l'environnement FreeBSD. 

       En général le réseau intégrant des liens satellites contient des "stations montantes" (voir Figure1) qui partagent la bande passante 
satellite soit de façon statique, SCPC, soit par TDMA. Dans le premier cas, la modification de la bande passante disponible à l'une des 
stations (par préallocation de bande au moment  de l'installation de la station)  nécessite l'intervention du centre de contrôle. Le canal 
d'émission reste cependant disponible à tout moment à la station montante (pas de TDMA). Dans le deuxième cas, plusieurs stations 
partagent la bande passante montante par TDMA. Ceci permet une granulerité plus fine pour l'allocation des ressources : un canal de 
C Mbps pourra alors être partagé parmi plusieurs stations montantes. 

   En général la station montante (INRIA) dispose donc d'un canal de capacité C Mbps connue à l'avance. Dans les deux cas (allocation 
statique ou TDMA), le service skyplex disponible au niveau du satellite permet de multiplexer numériquement les flux montants des 
différentes stations et de transmettre un flux DVB standard, donc démodulable par les set-top box du marché. 

L'encapsulation "Unidirectional Links Routing  "  [UDLR] permet  d'intégrer les stations montantes et les récepteurs ainsi que la liaison 
satellite unidirectionnelle dans l'Internet de façon transparente. La liaison satellite est alors considérée comme une liaison "classique" 
de l'Internet. 
 

2.  La Qualité de Service sur les Réseaux Satellites :

       La liaison satellite a des caractéristiques particulières. Le délai de propagation aller-retour est de l'ordre de 0.5 seconde. La bande 
passante est onéreuse et assez limitée, mais permet le support d'un service de diffusion à un grand nombre de récepteurs.

      Les applications envisagées dans le cadre du projet @IRS (DIS, audio et vidéo conférence, ...) générant des flux avec des besoins 
de qualité de service différents. Le support de ces flux sur la même liaison satellite nécessite un mécanisme de partage de la bande 
passante permettant de fournir un service adéquat à chacun des flots applicatifs. 

      Deux solutions pour la gestion de la qualité de service sont proposées : Une solution serait de gérer la qualité de service au niveau IP 
(avec des files WFQ ou CBQ et mécanismes de contrôle de congestion RED ou WRED par exemple). La liaison satellite sera considérée 
comme une liaison HDLC au-dessus de laquelle les paquets IP seront transmis sans avoir un contrôle de l'émission sur le canal au niveau 
liaison. En d'autres termes, un paquet IP transmis à la couche liaison sera transmis sur le canal en entier avant de pouvoir transmettre un 
autre paquet venant éventuellement d'un autre flux. 

      Une autre solution serait de mettre en ouvre un mécanisme d'allocation du canal satellite au niveau liaison. Ceci revient à découper 
la bande passante disponible en "sous-canaux ". Un flux IP avec qualité de service spécifique serait alors orienté vers le sous-canal 
correspondant. 

Ces deux approches sont étudiées dans le cadre du projet @IRS en prenant en considération les difficultés liées : 

  • à l'asymétrie des liaisons bidirectionnelles utilisant le réseau satellite, 
  • à la prise en compte du réseau satellite dans les mécanismes de routage, 

    • à l'optimisation des fonctions de diffusion en utilisant les propriétés intrinsèques des réseaux satellites. 
Le schéma ci-dessous présente les flux transitant sur ce réseau : 
     

   
     
3. Description du mécanisme d'encapsulation IP sur DVB 
     

Figure 2. : Mécanisme d'encapsulation IP sur DVB 
     
      Le standard  DVB  fournit un moyen pour la transmission de "flux de transport"  MPEG-2 (Transport Stream) au-dessus
d'une variété de support de transmission (dont les liaisons satellites). Plusieurs profils de spécification de diffusion de données 
sur DVB ont été définis afin de supporter des applications différentes. L'un de ces profils, le profil pour l'encapsulation multi-protocole 
"MultiProtocol Encapsulation" ou MPE permet le support de la transmission de datagrammes au-dessus du DVB. La transmission 
est effectuée en encapsulant les datagrammes dans des sections DSM-CC compatible avec le format de section privée MPEG-2. Celui
assure la compatibilité avec les décodeurs DVB satellite (ou câble) existants. L'encapsulation MPE (voir figure2.) ajoute au paquet IP 
une entête de 12 octets et une enqueue de 4 octets . Le paquet encapsulé sera ensuite segmenté et transmis dans des cellules MPEG-2 
de 188 octets dont une entête MPEG-2 de 4 octets. L'entête MPEG-2 contient en particulier le champ PID (program identificator) de 
13 bits qui permet de définir 8192 "sous-canaux". 
     
4.   Le routage multipoint  

     Etant les liens satellites  intrinsèquement des liens de support d 'un service de diffusion à un grand nombre de récepteurs, les liaisons
satellites nous permettent de transmettre en multipoint à moindre coût. La transmission multipoint est un mécanisme requis par un grand 
nombre d'applications multimédia. Afin que ce mécanisme soit efficace, il nécessite un support du réseau, ainsi qu'un contrôle de transmission 
approprié dans les systèmes finaux. L'étude des solutions pour le routage multicast (IGMP, PIM) et la liaison satellite sera réalisée en  
étroite collaboration avec le sous-projet routage multipoint . 

    L'encapsulation "UDLR"  permet  d'intégrer les stations montantes et les récepteurs ainsi que la liaison satellite unidirectionnelle 
dans l'Internet de façon transparente.  La liaison satellite est alors considérée comme une liaison "classique" de l'Internet et il est considéré 
à niveau IP  comment un réseau local. À ce niveau les noeuds et les routeurs  échangent des informations d'appartenance au groupe : IGMP 
(Internet Group Management Protocol). Ce protocole est supporté par des messages spécifiques ICPMv6  et les mécanismes du protocole 
MLD décrits dans [MLD] 

 Le principe général du protocole IGMP est le suivant : 
 

- Le router envoie périodiquement [Query Interval] (125s) : 
une requête (QUERY) à tous les hôtes du LAN : "à quel(s) groupe(s) voulez vous vous abonner ?" et attend les réponses. 
- Le(s) hôte(s) renvoie(nt) un "IGMP report" avec un délai aléatoire entre [0..Max Réponse Time] avec l'information de 
l'adresse du ou des groupes qui l'intéressent. 
- Si  le router ne reçoit aucune réponse pour un groupe donné il  arrête l'émission des paquets multicast de ce groupe.
Le groupe est réputé sans abonné local. 
 
 Quand l'hôte reçoit la sollicitation (query) :
 
- Il fixe un délai aléatoire avant de répondre [0..Max Response Time] 
- quand un hôte a répondu (Report), les autres reçoivent le message et n'ont donc plus besoin de répondre 
- Le router  simplement nécessite  savoir si au moins un membre du groupe est présent. 
- Le router  arme une temporisation sur les abonnements aux groupes multicast avant de solliciter à nouveau tous les hôtes 
 
 Un router est élu entre tous les routers 
- c'est le Dominant Router (DR) ou  " Designated Router " 
- il est seul à émettre les IGMP Queries 


Dans un future proche le nombre des récepteurs satellite seront très nombreux. Avec le mécanisme d'encapsulation " UDLR " 
les réponses aux requêtes multipoint seront tunnelées vers la station émettrice par défaut avec la possibilité d'avoir le problème 
de " feed-back implosion " pour raison du délai de transmission sur la liaison satellite . 

La solution proposée est basée sur l'élection des horloges exponentielles [ERNST]. Le principe repose en l'élection 
des délais  aléatoires utilisant une fonction de distribution exponentielle. Le travaille d'optimisation des différents paramètres 
(fonction exponentielle, temps maxime de réponse) permettra d'avoir un nombre de réponses limité avec  un délai maximum l
imité pour un nombre des récepteurs R. 

5 .Plate-forme d' experimentation 
 

- L'équipement d'émission :

   L'équipement d'émission  est composé essentiellement  pour:

  • un router freBSD 2.2.8 - souche Ipv6 KAME  et l'équipe d'émission (up-link)située à l'Inria 

    • Sophia et pointée sur le satellite Eutelsat Hotbird 5 13 degrés. 
  • Bande passante actuelle  512 Kbps et nous utilisons la technique TDMA (Time Division Multiple Access)  

    • pour l'accès.e control d'acces


- La station de réception est composée des éléments suivants: 

  • Antenne TVRO: Parabole 80cm pour télé numérique avec LNB universel (longitude <100m) 
  • Décodeur DVB : carte comatlas CAS2033A :
    • SCPC/MCPC demodulateur (2-30 MSymb)
    • Réception IP sur  DVB/MPEG 2 transport stream
    • Multiprotocol Encapsulation compatible
    • Débit trafic IP traffic  5 Mbps
    • ISA Bus
    • Connecteur  antenne Type F (classique) 
    La carte CAS2033A ne fait pas de filtrage hardware, il est donc conseillé d'utiliser un CPU assez rapide et un peu de 
    mémoire RAM (on a un très bon fonctionnement avec un Pentium Pro 200Mhz et 64Mb de RAM) .  INRIA supporte autres 
    cartes DVB :  Broadlogic et HDS - Cyberstream 040 model (Harmonic data systems)vous trouverez plus d'information 
    sur les drivers UDLR dans la page Web d'Emmanuel Duros.
  • PC:  Operating system: FreeBSD Release 2.2.8 Pile Kame (release 8/9/99). 
  •  Connectivité Internet, ATM ou ISDN terrestre pour la voie de retour "udlr".



     
    Abréviations
    AF        Assured Forwarding
    AH        Authentication Header
    ATM     Asynchronous Transfer Mode 
    DVB Direct Video Broadcasting
    tEF      Expedited Forwarding
    GRE      Generic Routing Encapsulation 
    IETF Internet Engineering Task Force
    IP Internet Protocol
    IPng Internet Protocol next generation
    IPv6 Internet Protocol version 6
    IPv4 Internet Protocol version 4
    ISP Internet Service Provider
    LAN Local Area Network
    MAC      Medium Access Control
    MARS Multicast Address Resolution Server
    MPEG II     Moving Pictures Experts Group Layer 2
    MPE      Multi-Protocol Encapsulation
    MTU      Maximum Transmit Unit
    PID      Program IDentifier 
    PVC Permanent Virtual Circuit
    QoS Quality of Service
    RFC Request For Comments
    RM Reliable Multicast
    UDLR      Uni-Directional Link Routing 
    VC Virtual Circuit
    WAN Wide Area Network


     
    Références


    [RFC 1483]  : "Multiprotocol Encapsulation over ATM Adaptation Layer 5"

    [RFC 2491]  : "IPv6 over Non-Broadcast Multiple Access (NBMA) Networks".

    [RFC 2492]  : "IPv6 over ATM Networks".

    [RFC 2022]  : "Support for multicast over UNI 3.0/3.1 based ATM networks"

    [RFC791]    :  "Internet Protocol".

    [RFC 1812]       : "Requirements for IP version 4 Routers".

    [RFC 2474]        "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 headers"

    [RFC 2475]     : "An Architecture for Differentiated Services"

    [RFC 2598]     : "An Expedited Forwarding PHB"

    [RFC 2597]     : "Assured Forwarding PHB Group"

    [UDLR]      : "A Link Layer Tunneling Mechanism for Unidirectional Links "   W. Dabbous, Y. Zhang, E. Duros, N. Fujii.

    [RM]    Antoine Clerget, Walid Dabbous, "Organizing Data Transmission for Reliable Multicast over Satellite Links", in 
    the Proceedings of the 5th Conference on Computer Communications, Africom CCDC'98, Internet and Global Networking. 

    [DVB]   :Digital Video Broadcast (DVB). ETSI EN 301 192 V1.1.1 

    [MPEG-2]  :MPEG-2. ISO IEC 13818.

    [FEC]  :L. Vicisano, L. Rizzo, and J. Crowcroft, "Tcp-like congestion control for layered multicast data transfer"  in 
    Proceedings of IEEE Infocom '98, March 1998

    [GRE] :'Generic Routing Encapsulation (GRE)',rfc 2784 D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina. Draft IETF.

    [RML]         :S. McCanne and V. Jacobson, "Receiver-driven layered multicast", in Proceedings  ACM Sigcomm '96, 
    (Stanfowrd, CA), August 1996.

    [FEC2]           :L. Vicisano, L. Rizzo, and J. Crowcroft, "Tcp-like congestion control for layered multicast data transfer", 
    in Proceedings of IEEE Infocom '98, March 1998.
     

    [MLD]         :Steve Deering, Bill Fenner, Brian Haberman, "Multicast Listener Discovery for Ipv6" draft-ietf-ipngwg-mld-02.txt
      , 06/08/1999. 

    [ERNST]          Jorg Nonnenmacher, Ernst Biersack  " Scalable Feedback for Satellite Broadcast " ACM/IEEE MobiCom '97 


     
     
     
     

Derniére modification:  14 septembre  2000
Editeur en chef :Rafael Rizo

WebMaster : WebMaster