IP Multicast: architettura e protocolli - Taschin Antonio -

Sommario Introduzione al multicast Routing interno Altri protocolli multicast Routing esterno Taschin Antonio

Introduzione al Multicast Cos’è il multicast Storia MBone Il Multicast nell’ISO/OSI Comandi

Cos’è il multicast Tante connessioni separate quante sono le richieste Utilizzare il broadcast La grande maggioranza delle applicazioni più usate su Internet utilizza la tradizionale modalità di comunicazione uno-a-uno detta unicast. Con l’odierna tecnologia, ci si può permettere il costo di stabilire una connessione unicast con chiunque vuole vedere la propria pagina web. Tuttavia, se si vuole inviare audio e video che necessitano di un largo uso di banda, fin quando il multicast non entrò in scena, esistevano due possibilità: o stabilire tante connessioni separate quante sono le richieste, oppure, usare il broadcast. La prima soluzione non era possibile in quanto se diciamo che una singola connessione occupa molta banda figuriamo stabilire decine o centinaia di connessioni contemporaneamente. Il broadcast sembra la soluzione, ma come sappiamo il broadcast funziona solo all’interno di una LAN e se qualche host esterno è interessato? oppure se qualche host della LAN non è interessato?   La tecnica multicast consente di inviare una sola volta lo stesso dato a tutti i possibili riceventi. Il dato viene duplicato solo dove è veramente necessario, quindi nell'ultimo punto di cammino comune tra la sorgente e tutti i destinatari. Quindi definiamo il multicast come un processo che trasmette le informazioni da una sorgente a più destinazioni con un unico flusso di dati, invece di usarne molteplici. La tecnologia multicast, è un processo che trasmette le informazioni da una sorgente a più destinazioni con un unico flusso di dati, invece di usarne molteplici. Taschin Antonio

Inaffidabilità della consegna PRO CONTRO Larghezza di banda Carico del server Carico della rete Inaffidabilità della consegna Duplicazione di pacchetti Congestioni di rete Taschin Antonio

Scenari di applicazione Videoconferenze, video on demand Quotazioni in borsa, distribuzione di listini e cataloghi in tempo reale Training, teledidattica Distribuzione di software Possibilità di sfruttare Internet per trasmissioni di tipo televisivo Possiamo tentare una grossolana classificazione delle applicazioni che traggono vantaggio dall’utilizzo del multicast in: real time e non real time Taschin Antonio

Storia Stanford University primi anni 80 Steve Deering e Vsystem Agosto 1989  RFC1112 Dicembre 1991  “Multicast routing in a Datagram Network” Taschin Antonio

MBone rete virtuale sperimentale di router multicast, costruita sopra la struttura standard di Internet MBone è l'acronimo di Multicast Backbone e rappresenta il più esteso esperimento di trasmissione multicast attuato fino ad ora. MBone è una rete virtuale sperimentale di router multicast, costruita sopra la struttura standard di Internet, in altre parole, è un livello logico posto in cima all’attuale Internet. Un problema che affliggeva i primi sperimentatori del multicast IP era il fatto che non esistevano router di produzione che implementassero algoritmi di routing multicast. Fu così sviluppato un programma, l'mrouted (pronuncia: em-rut-di), che implementava un router multicast su una normale workstation, utilizzando il protocollo di routing DVRMP. Con lo sviluppo dell'mrouted chiunque avesse un server disponibile poteva avere un router multicast e connettersi al circuito di distribuzione del traffico multicast MBone.   Per attraversare, però, dei router normali, è necessario far sembrare i pacchetti multicast dei comuni pacchetti unicast, in modo da “ingannare” i router, che non comprendono il multicast, quindi, MBone fece un grande uso del tunneling IP. Questa tecnica prende il nome di tunneling, e permette di creare connessioni virtuali, senza necessità di creare ulteriori collegamenti fisici oltre quelli già esistenti. MBone è potuta così crescere senza grossi problemi anche su una rete composta in larga parte da router con capacità unicast. Quindi, la struttura che ha assunto MBone è quella di una serie di isole con capacità multicast connesse da tunnel. mrouted  protocollo di routing DVMRP Tunnel Taschin Antonio

Storia di MBone Primi anni 90 Darpa Testbed Network (DARTNet) MIT,SRI, ISI, BBN, varie università 1992 IETF meeting a San Diego Taschin Antonio

Gli indirizzi multicast Insieme di zero o più host identificato da un singolo indirizzo IP di classe D 224.0.0.0 – 239.255.255.255 Taschin Antonio

…riassumendo Indirizzi IP Multicast Classe D — caratterizata dai 4 bit più alti (1110)=(224.0.0.0) Range da 224.0.0.0 a 239.255.255.255 Well known addresses stabiliti dallo IANA Per usi riservati da 224.0.0.0 a 224.0.0.255 224.0.0.1—all systems on subnet 224.0.0.2—all routers on subnet 224.0.0.13 – all PIM routers “http://www.iana.org/assignments/multicast-addresses ” Altri indirizzi utilizzati dinamicamente: Global scope: 224.0.1.0-238.255.255.255 Limited Scope: 239.0.0.0-239.255.255.255 Site-local scope: 239.255.0.0/16 Organization-local scope: 239.192.0.0/16 IANA Internet Assigned Numbers Authority Taschin Antonio

Le applicazioni in MBone Sessione Trasmissione di dati in MBone Session Announcement Protocol Session Description Protocol Session Initiation Protocol Nel mondo di MBone esistono numerosissime applicazioni, ognuna della quali è stata sviluppata per soddisfare particolari bisogni del programmatore. Le trasmissioni di dati nella rete MBone vengono comunemente chiamate sessioni. Esistono tre protocolli che vengono utilizzati per gestire le sessioni. Il Session Anouncement Protocol è utilizzato per annunciare o cancellare una sessione o comunicare le informazioni riguardanti le proprietà di una sessione Il Session Description Protocol è un protocollo utilizzato da dei programmi che si chiamano Session Directory. Questi programmi sono come il telecomando per una televisione. Infatti, visualizzano e permettono di selezionare tutte le sessioni attive in quel momento su MBone. Tutto questo è fatto tramite il protocollo SDP che viene incapsulato in un pacchetto del protocollo SAP Per finire esiste il Session Initiation Protocol che è un protocollo di livello application utilizzato per favorire il miglior controllo delle sessioni multicast. Taschin Antonio

Session Announcement Protocol (SAP) Per annunciare una sessione multicast e la sua descrizione Sessioni Gloobal Scope  224.2.127.254 224.2.128.0 – 224.2.255.255 Sessioni Administrative Scope  indirizzo più alto Porta 9875 Per poter annunciare una conferenza multicast o qualsiasi sessione multicast, e per poter comunicare qualunque informazione riguardante le proprietà di una sessione multimediale ai possibili partecipanti, è necessario utilizzare un’applicazione che fa uso del protocollo SAP. Un’istanza di questa applicazione, dovrà inviare periodicamente ad un indirizzo multicast ben noto, dei pacchetti che contengono la descrizione della sessione e tutte le informazioni necessarie per prendere parte alla sessione multimediale. Non esiste nessun meccanismo di rendezvous, ne nessun meccanismo di affidabilità, la trasmissione del pacchetto viene affidata al protocollo UDP. Gli annunci, come detto prima, conterranno la descrizione della sessione (si consiglia sia crittata) e inoltre, si consiglia contengano anche un’intestazione per l’autenticazione. I pacchetti SAP vengono inoltrati con la stessa portata della sessione che si sta annunciando, in modo tale da, poter raggiungere tutti i potenziali ricevitori. Esistono varie possibilità: ·        Sessioni Global Scope: utilizzano gli indirizzi multicast tra 224.2.128.0 e 224.2.255.255, gli annunci dovranno essere inviati al 224.2.127.254 (SAP.MCAST.NET). Si ricorda che l’indirizzo 224.2.127.255 è utilizzato dal protocollo SAPv0 che è considerato oramai obsoleto e non deve essere usato. ·         Sessioni Administrative Scope: l’indirizzo multicast utilizzato per annunciare le sessioni è l’indirizzo più alto della zona Administrative Scope. Per esempio, se gli indirizzi vanno dal 239.16.32.0 al 239.16.33.255, allora l’indirizzo a cui mandare i pacchetti multicast con gli annunci è il 239.16.33.255. Tutti gli annunci dovranno essere inviati alla porta 9875 con un TTL di 255.   L’intervallo con cui si ripetono l’invio degli annunci varia a seconda della larghezza di banda utilizzata da questi annunci, della dimensione degli annunci e del numero di annunci che vengono inviati a quell’indirizzo. Taschin Antonio

Cancellazione di una sessione Explicit Timeout Implicit Timeout Explicit Deletion Una sessione può essere cancellata in tre modi:   Explicit Timeout: nella descrizione di una sessione viene specificato l’ora di inizio e la durata. Se l’ora corrente ha già superato l’ora della fine della sessione, non si farà altro che cancellare la sessione dalla cache e ogni annuncio per quella sessione che arriva, verrà ignorato. Implicit Timeout: se non si ricevono annunci di una sessione per tempo uguale a dieci volte l’intervallo di trasmissione oppure un’ora, la sessione verrà cancellata dalla cache. Explicit Deletion: quando si riceve un pacchetto che annuncia la cancellazione di una particolare sessione. Taschin Antonio

Tool di MBone SDR (Session Directory) VIC (Video Conferencing Tool) RAT e VAT (Robust e Visual Audio Tool) WB Taschin Antonio

Livello 2: Multicast Ethernet Indirizzo Ethernet 48bit  6 campi da 2 cifre esadecimali L’indirizzo multicast viene riconosciuto dalla prima cifra esadecimale dell’indirizzo. Pari  unicast Dispari  multicast Esempio: L’indirizzo AB-CD-EF-04-26-45 la cifra AB (171 in notazione decimale) è dispari. La natura di Ethernet è quella di consentire il libero colloquio con qualsiasi macchina collegata e di trasmettere la stessa informazione contemporaneamente a tutte le macchine in ascolto (broadcasting), non è necessariamente la migliore delle tecnologie possibili, ma si è dimostrata la più economica e la più facile da utilizzare. Si denota l’indirizzo Ethernet in forma leggibile agli esseri umani, scrivendolo come una sequenza di sei campi a due cifre esadecimali (4 bit per cifra) separati dal carattere : (due punti). Taschin Antonio

…esempio L’indirizzo AB-CD-EF-04-26-45 la cifra AB (10101011) è dispari. Livello 1: Ogni singolo byte viene trasferito autonomamente dal più significativo Ogni bit del byte viene trasferito dal meno significativo il primo bit che esce dalla scheda di rete è un 1 Questo perché ogni singolo byte viene trasferito autonomamente, inviando per primo il bit meno significativo, cioè quello che si troverebbe più a destra se trascrivessimo il numero esadecimale in notazione binaria. Facciamo un esempio: il numero esadecimale AB visto sopra (171 decimale) diventerebbe 10101011. Fisicamente, l'indirizzo viene trasmesso partendo dal byte più significativo fino ad arrivare al byte meno significativo. Viceversa, i bit di ogni byte vengono trasmessi a partire dal bit meno significavo fino ad arrivare al bit più significativo. Cominciando a trasmettere da destra il primo bit che esce dalla scheda di rete è un 1, ovvero con un livello alto di tensione, e questo dice al ricevente che si tratta di un indirizzo multicast. Se fosse invece uno 0 (il primo byte è pari), sarebbe un indirizzo singolo (unicast). Quindi, per inviare datagram IP multicast è sufficiente mappare gli indirizzi della classe D con indirizzi Ethernet che generino fisicamente (on the wire) un livello alto di tensione all'inizio. mappare gli indirizzi della classe D con indirizzi Ethernet che generino fisicamente un livello alto di tensione all'inizio. Taschin Antonio

Multicast su Ethernet (livello 2) RFC1112  01-00-5E-00-00-00 32 Bits 23 Bits 239.255.0.1 nonchè FDDI in accordo con l’RFC1112, un indirizzo IP di un gruppo è mappato con un indirizzo multicast Ethernet uguagliando i 23 bit meno significativi dell'indirizzo multicast Ethernet 01-00-5E-00-00-00 ai 23 bit meno significativi dell'indirizzo IP. 01-00-5e-7f-00-01 24 Bits 24 Bits 48 Bits Taschin Antonio

Indirizzo Multicast Ethernet HEX 01 00 5E - 23 bit - BIN 0000 0001 0000 0000 0101 1110 0xxx xxxx xxxx xxxx xxxx xxxx | | Multicast Bit 0 = Internet Multicast Taschin Antonio

Sovrapposizione di indirizzi 32 Bits 28 Bits 1110 239.255.0.1 5 Bits Lost For example, all of the following IPmc addresses map to the same L2 multicast of 01-00-5e-0a-00-01: 224.10.0.1, 225.10.0.1, 226.10.0.1, 227.10.0.1 228.10.0.1, 229.10.0.1, 230.10.0.1, 231.10.0.1 232.10.0.1, 233.10.0.1, 234.10.0.1, 235.10.0.1 236.10.0.1, 237.10.0.1, 238.10.0.1, 239.10.0.1 224.138.0.1, 225.138.0.1, 226.138.0.1, 227.138.0.1 228.138.0.1, 229.138.0.1, 230.138.0.1, 231.138.0.1 232.138.0.1, 233.138.0.1, 234.138.0.1, 235.138.0.1 236.138.0.1, 237.138.0.1, 238.138.0.1, 239.138.0.1 01-00-5e-7f-00-01 25 Bits 23 Bits 48 Bits Taschin Antonio

Sovrapposizione di indirizzi 32 – Indirizzi IP Multicast 224.1.1.1 224.129.1.1 225.1.1.1 225.129.1.1 . 238.1.1.1 238.129.1.1 239.1.1.1 239.129.1.1 1 - Multicast MAC Address 0x0100.5E01.0101 Taschin Antonio

Sovrapposizione di indirizzi 32 – Indirizzi IP Multicast 224.0.0.x 224.129.0.x 225.0.0.x 225.129.0.x . 238.0.0.x 238.129.0.x 239.0.0.x 239.129.0.x 1 - Multicast MAC Address 0x0100.5E00.00xx Taschin Antonio

Perché Primi anni 90 Steve Deering IEEE  16 consecutivi OUI (Organizational Unique Identifier) Taschin Antonio

Il concetto di Gruppo Insieme di zero o più host identificato da un indirizzo di classe D Associarsi o Abbandonare Non è statico ma dinamico Non è necessario essere membri di un gruppo per inviare dati a quel gruppo Per ricevere i dati però bisogna essere membri del gruppo Un gruppo multicast è analogo ad un alias di email. Taschin Antonio

Internet Group Management Protocol IGMP Internet Group Management Protocol IGMPv1  RFC1112 obsoleto IGMPv2  RFC2236 in uso IGMPv3  bozza Taschin Antonio

Pachetto IGMPv1 Version in questo campo viene specificata la versione dell’IGMP Type esistono due tipi di messaggi IGMP: 1 = Host Membership Query. 2 = Host Membership Report. Unused 0 quando viene spedito Checksum Group Address Taschin Antonio

IGMPv1 Membership Query Membership Report Leave Group 224.0.0.1 ALL-SYSTEMS.MCAST.NET Membership Report Leave Group 224.0.0.2 ALL-ROUTERS.MCAST.NET Taschin Antonio

IGMPv1—Associarsi a un gruppo H3 H1 H2 224.1.1.1 Report Per associarsi a un gruppo un PC manda un pacchetto IGMP report all’indirizzo 224.1.1.1 con TTL 1 Taschin Antonio

IGMPv1 — Membership Queries Membership Query all’indirizzo 224.0.0.1 IGMPv1 Multicast Router Periodicamente il router invia un pacchetto IGMP di Membership Query all’indirizzo 224.0.0.1 per aggiornare la tabella dei gruppi multicast attivi Taschin Antonio

IGMPv1 X Router manda periodicamente la Membership Query 224.1.1.1 Soppresso X #3 224.1.1.1 Report #2 Query a 224.0.0.1 #1 IGMPv1 #1 Router manda periodicamente la Membership Query #2 Solo un membro per gruppo invia il report #3 Gli altri membri non inviano nulla Taschin Antonio

IGMPv1 — Abbandonare un gruppo H3 H3 H1 H2 Query a 224.0.0.1 Query a 224.0.0.1 IGMPv1 Il router invia periodicamente i pacchetti IGMP Il PC lascia il gruppo senza segnalarlo Il router continua ad inviare le query periodiche Il router non riceve nessun report per quel determinato gruppo Il gruppo va in time out Taschin Antonio

IGMPv2 RFC 2236 group-specific query Leave group message Il router si assicura che non ci sia più nessun interessato al gruppo prima di cessare il forwarding di quel traffico multicast Leave group message Gli host possono inviare questo messaggio per abbandonare il gruppo Taschin Antonio

IGMPv2 Querier election mechanism Query-interval response time Viene selezionato il router con l’indirizzo IP minore. Query-interval response time Viene impostato il massimo tempo nel quale un host può rispondere Compatibilità con IGMPv1 Taschin Antonio

Pacchetto IGMPv2 Type 0x11 Membership Query: ci sono due sottotipi di messaggi: General Query: utilizzato per conoscere quali gruppo hanno dei partecipanti in una particolare rete. Group-Specific Query: utilizzato per conoscere se un particolare gruppo ha dei partecipanti in una particolare rete. 0x12 Membership Report usato per la compatibilità con la versione 1. 0x16 Membership Report per la versione 2. 0x17 Leave Group: Abbandono del gruppo Come l’ICMP, il protocollo IGMP è parte integrante dell’IP. I messaggi IGMP sono incapsulati in datagram IP con un numero di protocollo IP uguale a 2. Tutti i messaggi IGMP descritti in questo paragrafo sono inviati con un TTL uguale a 1

Pacchetto IGMPv2 Max Response Time questo campo è significativo solo nei messaggi di tipo Membership Query e specifica il tempo massimo consentito prima di inviare un report di risposta. Il tempo è misurato in unità da 1/10 di secondo. Negli altri messaggi, questo campo, è settato a zero da coloro che trasmettono e ignorato da chi riceve. Come l’ICMP, il protocollo IGMP è parte integrante dell’IP. I messaggi IGMP sono incapsulati in datagram IP con un numero di protocollo IP uguale a 2. Tutti i messaggi IGMP descritti in questo paragrafo sono inviati con un TTL uguale a 1

IGMPv2—Unirsi a un gruppo 1.1.1.10 1.1.1.11 1.1.1.12 224.1.1.1 Report H1 H2 H3 H1 H3 1.1.1.1 router Il PC che sta per unirsi a un gruppo invia un messaggio IGMP al gruppo di cui vuol far parte Taschin Antonio

IGMPv2—Unirsi a un gruppo 1.1.1.10 1.1.1.11 1.1.1.12 H1 H2 H3 H1 H3 1.1.1.1 router Stato IGMP nel router router>show ip igmp group IGMP Connected Group Membership gruppo Address Interface Uptime Expires Last Reporter 224.1.1.1 Ethernet0 6d17h 00:02:31 1.1.1.11 Taschin Antonio

IGMPv2—Querier Election 1.1.1.10 1.1.1.11 1.1.1.12 H1 H2 H3 Query 1.1.1.2 1.1.1.1 Query IGMP Non-Querier IGMP Querier IGMPv2 router_b router Inizialmente tutti i router inviano una Query Il router con il più basso indirizzo IP viene eletto querier Gli altri router diventano “Non-Queries” Taschin Antonio

IGMPv2—Querier Election Quale router? router>show ip igmp interface e0 Ethernet0 is up, line protocol is up Internet address is 1.1.1.1, subnet mask is 255.255.255.0 IGMP is enabled on interface Current IGMP version is 2 CGMP is disabled on interface IGMP query interval is 60 seconds IGMP querier timeout is 120 seconds IGMP max query response time is 10 seconds Inbound IGMP access group is not set Multicast routing is enabled on interface Multicast TTL threshold is 0 Multicast designated router (DR) is 1.1.1.1 (this system) IGMP querying router is 1.1.1.1 (this system) Multicast groups joined: 224.0.1.40 224.2.127.254 Taschin Antonio

IGMPv2—Mantenere un gruppo 1.1.1.10 1.1.1.11 1.1.1.12 H1 H2 H3 224.1.1.1 Suppressed X 224.1.1.1 Report 1.1.1.1 Query IGMPv2 Il router invia le query periodiche Solo un unico membro per gruppo risponde con un report Gli altri membri sopprimono l’invio del report Taschin Antonio

IGMPv2—Abbandonare un gruppo 1.1.1.10 1.1.1.11 1.1.1.12 H1 H2 H3 1.1.1.1 router router>sh ip igmp group IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 224.1.1.1 Ethernet0 6d17h 00:02:31 1.1.1.11 Stato IGMP nel router Taschin Antonio

IGMPv2—Abbandonare un gruppo 1.1.1.10 1.1.1.11 1.1.1.12 Leave Msg 224.0.0.2 224.1.1.1 #1 Report a 224.1.1.1 #3 H2 H2 H1 H3 1.1.1.1 Group Specific Query to 224.1.1.1 #2 router H2 lascia il gruppo ed invia un Leave message Il router invia il solito Group specific query Uno dei membri rimasti risponde Il gruppo resta attivo Taschin Antonio

IGMPv2—Abbandonare un gruppo 1.1.1.10 1.1.1.11 1.1.1.12 H1 H2 H3 1.1.1.1 router router>sh ip igmp group IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 224.1.1.1 Ethernet0 6d17h 00:01:47 1.1.1.12 Stato IGMP nel router Taschin Antonio

IGMPv2—Abbandonare un gruppo 1.1.1.10 1.1.1.11 1.1.1.12 Leave M 224.0.0.2 224.1.1.1 #1 H3 H1 H2 H3 1.1.1.1 Group Specific Query to 224.1.1.1 #2 router L’ultimo membro rimasto invia un Leave message Il router invia il solito Group specific query Il router non riceve nessun report Il gruppo va in time out Taschin Antonio

IGMPv2—Abbandonare un gruppo 1.1.1.10 1.1.1.11 1.1.1.12 H1 H2 H3 1.1.1.1 router router>sh ip igmp group IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter Stato IGMP nel router Taschin Antonio

Comandi ip multicast-routing clear ip igmp group clear ip sdr ip igmp access-group ip igmp helper-address ip igmp join-group ip igmp query-interval ip igmp query-max-response-time ip igmp query-timeout ip igmp static-group ip igmp version ip multicast cache-headers ip multicast rate-limit ip multicast ttl-threshold ip sdr cache-timeout ip sdr listen mrinfo mstat mtrace show ip igmp groups show ip igmp interface show ip sdr Taschin Antonio

In dettaglio ip multicast-routing Default: Disabled Command Mode: Global Cisco IOS Release 10.0. ip multicast ttl-threshold <ttl> Default: 0 Command Mode: Interface Cisco IOS Release 11.0. Taschin Antonio

In dettaglio ip multicast rate-limit {in | out} [video | whiteboard] [group-list access-list] [source-list access-list] kbps Default: NC Command Mode: Interface Cisco IOS Release 11.0. ip igmp access-group <access-list-number> <version> Default: tutti i gruppi sono permessi Cisco IOS Release 10.0. Taschin Antonio

In dettaglio ip igmp join-group <group-address> ip igmp query-interval <seconds> ip igmp query-max-response-time <seconds> ip igmp query-timeout <seconds> ip igmp static-group <group-address> Taschin Antonio

In dettaglio ip sdr cache-timeout <minuti> ip sdr listen mrinfo mstat mtrace Taschin Antonio

In dettaglio clear ip igmp group [group-name | group-address | type number] clear ip sdr [group-address | "session-name"] show ip igmp groups [group-name | group-address | type number] show ip igmp interface [type number] show ip sdr [group | "session-name" | detail] Taschin Antonio

Routing Interno Principi di routing interno Protocolli di routing Comandi Taschin Antonio

Inoltro e instradamento Inoltro (forwarding) consiste nel prendere il pacchetto, esaminarne l’indirizzo di destinazione, consultare la tabella di inoltro e inviare il pacchetto nella direzione stabilita e memorizzata nella tabella Instradamento (routing) è il processo di costruzione della tabella di inoltro È necessario badare bene alla differenza, spesso trascurata, tra inoltro e instradamento. L’inoltro consiste nel prendere il pacchetto, esaminarne l’indirizzo di destinazione, consultare la tabella di inoltro e inviare il pacchetto nella direzione stabilita e memorizzata nella tabella. Attualmente, per inoltrare un pacchetto multicast viene utilizzato il Reverse Path Forwarding (RPF) un algoritmo dove il router, prima controlla se il pacchetto è stato ricevuto dall’interfaccia dove inoltra il traffico unicast, dopo di che, in caso positivo, inoltrerà il datagram nell’interfaccia destinata al traffico multicast; nel caso negativo il pacchetto verrà ignorato. L’instradamento (o routing) è il processo di costruzione della tabella di inoltro, ed è un argomento complesso che tratta essenzialmente problemi di teoria dei grafi. Il problema fondamentale dell’instradamento consiste nel trovare il percorso di costo minimo tra due nodi qualsiasi, dove il costo del percorso è la somma dei costi dei vari archi che compongono il percorso. Se si rappresenta una LAN come un grafo che può contenere dei cicli, allora è necessario un algoritmo che crea un albero di copertura (spanning tree). Uno spanning tree è un sottografo che si estende su tutti i nodi del grafo d’origine ma elimina quegli archi che creano dei cicli. Ecco che i protocolli di routing utilizzano al loro interno degli algoritmi che sono in grado di creare degli spanning tree per poi poter calcolare il percorso di costo minimo. Taschin Antonio

Principi di routing interno Alberi di distribuzione Basati sulla sorgente (S,G) Condivisi (*,G) Il multicast routing utilizza “Reverse path forwarding” per costruire l’albero di distribuzione e arricurarsi che I pacchetti vengano inoltrati nella interfaccia corretta. Viene utilizzato un algoritmo unicast È utilizzato per determinare il miglior percorso unicast dal ricevente alla sorgente. L'instradamento (routing) di datagram multicast è più complesso rispetto all'instradamento dei datagram unicast. Infatti, i gruppi (ovvero gli host che hanno aderito ad un gruppo) non hanno residenza fissa, ma possono, al limite, trovarsi in tutto il mondo. Inoltre, la dinamicità dei gruppi costringe i router multicast ad adattarsi di continuo alla comparsa e scomparsa di gruppi sulle varie reti locali. Taschin Antonio

Algoritmi di routing Flooding Spanning Tree Reverse Path Broadcasting Truncated Reverse Path Broadcasting Reverse Path Multicasting Taschin Antonio

Reverse Path Forwarding (RPF) Multicast Forwarding Reverse Path Forwarding (RPF) Come viene utilizzato RPF per costruire un albero di distribuozione? Gli alberi di distribuzione per il multicast vengono costruiti hop-by-hop, determinando il miglior hop successivo seguendo il percorso verso la sorgente con un algoritmo unicast. Dopo aver determinato l’hop successivo un Join o un Graft viene emesso nell’interfaccia RPF. Così viene costruito l’albero: dal ricevitore alla sorgente. Come funziona? Se il pacchetto arriva dall’interfaccia specificata da routing unicast per la sorgente allora il check RPF ha successo. Altrimenti fallisce. Taschin Antonio

Pacchetto multicast dall’indirizzo Multicast Forwarding Pacchetto multicast dall’indirizzo 151.10.3.21 S0 S1 S2 E0 Multicast Forwarding: RPF Check Succeeds Ex: Router can only accept multicast data from Source 151.10.3.21 on interface S1 ... multicast data is forwarded out all outgoing on the distribution tree because it arrive on the incoming interface specified in the RPF check (S1) Unicast Route Table Network Interface 151.10.0.0/16 S1 198.14.32.0/24 S0 204.1.16.0/24 E0 Il pacchetto è arrivato dall’interfaccia corretta. Ora viene forwardato in tutte le altre interfaccie. Taschin Antonio

Albero di distribuzione basato sulla sorgente Notazione: (S, G) o (1.1.1.1 , 224.2.2.2) e (1.1.2.1 , 224.2.2.2) S = Sorgente G = Gruppo Indirizzo Sorgente 1.1.1.1 Gruppo 224.2.2.2 Indirizzo Sorgente 1.1.2.1 A B D F C E Receiver 1 Receiver 2 Taschin Antonio

Albero di distribuzione condiviso Indirizzo Sorgente 1.1.1.1 Indirizzo Gruppo 224.2.2.2 Notazione: (*, G) or (* , 224.2.2.2) * = Tute le sorgenti G = gruppo Indirizzo Sorgente 1.1.2.1 A B D (Shared Root) F C E Receiver 1 Receiver 2 Taschin Antonio

Protocolli di routing Dense-mode Sparse-mode Metodo Flood and prune Crea uno stato in ogni router per ogni sorgente Supportano solo SPT o SDT Sparse-mode Metodo del join espicito Supportano sia I SDT che I Shared-DT Taschin Antonio

Albero basato sulla sorgente Protocolli di routing Albero basato sulla sorgente Albero Condiviso Distance Vector Multicast Routing Protocol Multicast Open Shortest Path First Protocol Independent Multicast – Dense Mode Core Based Tree Protocol Independent Multicast - Sparse Mode Taschin Antonio

DVMRP DVMRP Utilizza il RIP e TRPB Utilizza il metodo Flood and Prune Molto utilizzato nelle reti accademiche Costruisce un albero per ogni sorgente Largamente utilizzato in MBone Taschin Antonio

I problemi del DVMRP DVMRP non può scalare alle dimesioni di Internet Distance vector-based routing protocol Update tabella di routing Un update ogni 60 secondi Dimensioni Molte informazioni memorizzate nella tabella di routing Stabilità Converge lentamente, count-to-infinity, etc. Non supporta gli albero condivisi Taschin Antonio

Come funziona il DVMRP Taschin Antonio

Come funziona il DVMRP Taschin Antonio

MOSPF - RFC 1584 Multicast Extension to OSPF Estensione all’OSPF unicast OSPF: I router utilizzano del pacchetti aprticolari per capire le condiziojni della rete MOSPF: Include le informazioni multicast negli annunci OSPF. Ogni router ha un’immagine dell’intera topologia della rete Utilizza l’algoritmo di Dijkstra algorithm per calcolare SPT. Taschin Antonio

MOSPF Non fa flood di traffico multicast Protocollo dipendente — lavora solo nelle reti in cui c’è l’OSPF. Problemi: L’algoritmo di Dijkstra viene eseguito per ogni coppia (S,G). Non supporta gli alberi condivisi Non è appropriato per: Grandi reti con un grande numero di sernder e receiver. Taschin Antonio

Il metodo Flood and Prune Protocolli Dense Mode Il metodo Flood and Prune 1. Inizialmente viene fatto un fllod 2. Prune dove non c’e’ il gruppo 3. Prune i non SPT 4. Reflooding periodico Sorgente No Receivers A B D F RPF Fails (Normal) Utilizzo del SPT C E Receiver 1 Receiver 2 Taschin Antonio

PIM Dense Mode Protocollo Independente Supporta la maggior parte dei protocolli unicast: static, RIP, IGRP, EIGRP, IS-IS, BGP, e OSPF Utilizza reverse path forwarding Adatto per... Piccole reti densamente popolate dal multicast Taschin Antonio

PIM Dense Mode Vantaggi: Problemi... Facile da configurare—due comandi Meccanismo di flood and prune molto semplice Facile da capire e facile debug Problemi... Non adatto per WAN Non supporta gli alberi condivisi Taschin Antonio

Esempio PIM Dense Mode Sorgente Link Data Control A B G C D F H E I Receiver 1 Receiver 2 Taschin Antonio 25

Esempio PIM Dense Mode Sorgente Inizialmente viene effetuato un flood dei dati A B G D F H E I Receiver 1 Receiver 2 Taschin Antonio 26

Esempio PIM Dense Mode Sorgente Prune dei non Non-RPF D F I B C A E G H Prune Receiver 1 Receiver 2 Taschin Antonio 27

Esempio PIM Dense Mode Sorgente C e D devono decidire chi forwarderà il flusso D F I B C A E G H Asserts Receiver 1 Receiver 2 Taschin Antonio 28

Esempio PIM Dense Mode Sorgente Prune di I Prune di E ignorato D F I B C A E G H Prune Join Override Prune Receiver 1 Receiver 2 Taschin Antonio 29

Esempio PIM Dense Mode Source Un nuovo Receiver, I invia un Graft D F B C A E G H Graft Receiver 1 Receiver 2 Receiver 3 Taschin Antonio 30

Esempio PIM Dense Mode Source D F I B C A E G H Receiver 1 Receiver 2 Taschin Antonio 31

PIM Sparse Mode (RFC 2362) Supporta sia gli alberi condivisi che basati sulla sorgente Utilizza un Rendezvous Point (RP) Le sorgenti si registrano nell’RP e inviano il loro traffico attravero l’RP Richiesta esplicita di ottenere il flusso multicast Indipendente dai protocolli unicast Ha posto le basi per il routing esterno (inter-domain) Adatto per… Per tutti I tipi di rete Ottimale per gruppi che hanno receiver su WAN differenti Taschin Antonio

Protocolli Sparse Mode Meccanismo di Join Esplicito 1. Nessuno riceve il traffico di un gruppo senza un esplicito join 2. Utilizzo del Rendezvous 3. Nessun flood periodico Sorgente 1 Rendezvous Point (Shared Root) Non Viewers A B D F Utilizza gli alberi condivisi per default. Ma può switchare se necessario ai SPT. C E Receiver 1 Taschin Antonio Non Viewer

Esempio PIM Sparse Mode Link Data Control A B RP D C E Taschin Antonio

Esempio PIM Sparse Mode Receiver 1 manda un Joins per il gruppo G C crea lo stato (*, G), E manda il join al RP A B RP D Join C E Receiver 1 Taschin Antonio

Esempio PIM Sparse Mode RP crea lo stato (*, G) A B RP D C E Receiver 1 Taschin Antonio

Esempio PIM Sparse Mode Sorgente 1 invia il flusso e A lo registra via unicast su RP Sorgente 1 Register A B RP D C E Receiver 1 Taschin Antonio

Esempio PIM Sparse Mode Rp manda un join a B per ottenere il flusso nativo Sorgente 1 Join Join A B RP D C E Receiver 1 Taschin Antonio

Esempio PIM Sparse Mode Source 1 Register-Stop A B RP D C E Receiver 1 Taschin Antonio

Esempio PIM Sparse Mode C invia un Join per il gruppo (S, G) per unirsi al Shortest Path Tree (SPT) Source 1 A B RP D (S, G) Join C E Receiver 1 Taschin Antonio

Esempio PIM Sparse Mode C invia un msg di Prune fino al RP RP invia un msg di prune fino alla sorgente Source 1 (S, G) Prune A B RP D (S, G) RP Prune C E Receiver 1 Taschin Antonio

Esempio PIM Sparse Mode Nuovo receiver Source 1 A B RP D (*, G) Join C E Receiver 1 Receiver 2 Taschin Antonio

Esempio PIM Sparse Mode C inserisce E nella OIF Source 1 A B RP D C E Receiver 1 Receiver 2 Taschin Antonio

Esempio PIM Sparse Mode Source 2 inizia a spedire D invia il messagio di Register RP inoltra I dati del msg Source 1 Register Source 2 A B RP D C E Receiver 1 Receiver 2 Taschin Antonio

Esempio PIM Sparse Mode Source 1 RP invia un Join a D Register Join Source 2 A B RP D C E Receiver 1 Receiver 2 Taschin Antonio

Esempio PIM Sparse Mode Source 1 RP invia Register-Stop Register-Stop Source 2 A B RP D C E Receiver 1 Receiver 2 Taschin Antonio

Esempio PIM Sparse Mode Source 1 Sia l’albero condiviso che l’albero basato sulla sorgente sono in uso Source 2 A B RP D C E Receiver 1 Receiver 2 Taschin Antonio

Comandi clear ip dvmrp route clear ip mroute clear ip pim auto-rp ip dvmrp accept-filter ip dvmrp auto-summary ip dvmrp default-information ip dvmrp metric ip dvmrp metric-offset ip dvmrp output-report-delay ip dvmrp reject-non-pruners ip dvmrp routehog-notification ip dvmrp route-limit ip dvmrp summary-address ip dvmrp unicast-routing ip mroute ip mroute-cache ip pim ip pim accept-rp ip pim message-interval ip pim minimum-vc-rate ip pim multipoint-signalling ip pim nbma-mode ip pim neighbor-filter ip pim query-interval ip pim rp-address ip pim rp-announce-filter ip pim send-rp-announce ip pim send-rp-discovery ip pim spt-threshold ip pim vc-count Taschin Antonio

Comandi show ip dvmrp route show ip mcache show ip mpacket show ip mroute show ip pim interface show ip pim neighbor show ip pim rp show ip pim vc show ip rpf show ip sdr Taschin Antonio

In dettaglio ip pim {dense-mode | sparse-mode | sparse-dense-mode} ip pim accept-rp {address | auto-rp} [group-access-list-number] ip pim message-interval seconds Taschin Antonio

In dettaglio ip pim query-interval seconds default 30 ip pim rp-address ip-address [group-access-list-number] [override] ip dvmrp unicast-routing Taschin Antonio

In dettaglio ip mroute source mask [protocol as-number] {rpf-address | type number} [distance] Es: ip mroute 0.0.0.0 255.255.255.255 tunnel0 ip mroute 171.69.0.0 255.255.0.0 171.68.10.13 Taschin Antonio

Admin-Scoping Esempio di una semplice scoped zone: 239.255.0.0/16 = Site-Local Scope Zone 239.192.0.0/10 = Org.-Local Scope Zone 224.0.1.0 - 238.255.255.255 = Global scope (Internet) zone Taschin Antonio

Admin-Scoping Centro Stella Internet Economia Ingegneria AS Border Internet RP Locale S0 Border A S0 S1 T1 T1 S0 S0 Border B Border C RP Locale RP Locale Economia Ingegneria Taschin Antonio

Admin-Scoping Centro Stella Internet Router di frontiera RP Locale S0 Router di frontiera Border A Router di frontiera periferici Router di frontiera periferici S0 S1 T1 T1 S0 S0 Border B Border C RP Locale RP Locale Economia Ingegneria Taschin Antonio

Admin-Scoping Centro Stella Internet Economia Ingegneria AS Border Internet Interface Serial0 . . . ip multicast ttl-threshold 16 ip multicast boundary 10 access-list 10 deny 239.255.0.0 0.0.255.255 access-list 10 permit any RP Locale S0 Border A S0 S1 T1 T1 S0 S0 Border B Border C RP Locale RP Locale Economia Ingegneria Taschin Antonio

Admin-Scoping Centro Stella To Internet Economia Ingegneria AS Border To Internet RP Locale S0 Border A Interface Serial0 . . . ip multicast ttl-threshold 16 ip multicast boundary 10 Interface Serial1 access-list 10 deny 239.255.0.0 0.0.255.255 access-list 10 permit any S0 S1 T1 T1 S0 S0 Border B Border C RP Locale RP Locale Economia Ingegneria Taschin Antonio

Admin-Scoping Centro Stella To Internet Economia Ingegneria AS Border interface Loopback0 ip address 192.168.10.2 255.255.255.255 ip pim send-rp-discovery scope 15 ip pim send-rp-announce Loopback0 scope 15 gruppo 20 access-list 20 permit 239.255.0.0 0.0.255.255 To Internet RP Locale S0 Border A S0 S1 T1 T1 S0 S0 Border B Border C RP Locale RP Locale Economia Ingegneria Taschin Antonio

Admin-Scoping Centro Stella To Internet Economia Ingegneria AS Border To Internet RP Locale S0 interface Loopback0 ip address 192.168.10.1 255.255.255.255 ip pim send-rp-discovery scope 15 ip pim send-rp-announce Loopback0 scope 15 gruppo 20 access-list 20 permit 239.255.0.0 0.0.255.255 Border A S0 S1 T1 T1 S0 S0 Border B Border C RP Locale RP Locale Economia Ingegneria Taschin Antonio

Admin-Scoping Centro Stella Internet Economia Ingegneria AS Border Internet RP Locale S0 interface Loopback0 ip address 192.168.10.3 255.255.255.255 ip pim send-rp-discovery scope 15 ip pim send-rp-announce Loopback0 scope 15 gruppo 20 access-list 20 permit 239.255.0.0 0.0.255.255 Border A S0 S1 T1 T1 S0 S0 Border B Border C RP Locale RP Locale Economia Ingegneria Taschin Antonio

Admin-Scoping Centro Stella Internet Economia Ingegneria AS Border Internet Interface Serial0 . . . ip multicast ttl-threshold 128 ip multicast boundary 10 access-list 10 deny 239.0.0.0 0.0.0.255 access-list 10 permit any RP Locale S0 Border A S0 S1 T1 T1 S0 S0 Border B Border C RP Locale RP Locale Economia Ingegneria Taschin Antonio

MSDP Concepts Works with PIM-SM only RP’s knows about all sources in a domain Sources cause a “PIM Register” to the RP Can tell RP’s in other domains of its sources Via MSDP SA (Source Active) messages RP’s know about receivers in a domain Receivers cause a “(*, G) Join” to the RP RP can join the source tree in the peer domain Via normal PIM (S, G) joins Only necessary if there are receivers for the gruppo Taschin Antonio

MSDP Design Points MSDP peers talk via TCP connections UDP encapsulation option Source Active (SA) messages Peer-RPF forwarded to prevent loops RPF check on AS-PATH back to the peer RP If successful, flood SA message to other peers Stub sites accept all SA messages Since they have only one exit (e.g., default peer) MSDP speaker may cache SA messages Reduces join latency Taschin Antonio

MSDP Example r s Domain E Domain C Domain B Domain D Domain A MSDP Peers Source Active Messages SA RP SA r Join (*, 224.2.2.2) Domain C SA RP Domain B SA SA RP SA Message 192.1.1.1, 224.2.2.2 RP SA Message 192.1.1.1, 224.2.2.2 Domain D RP s 192.1.1.1, 224.2.2.2 Domain A Taschin Antonio

MSDP Example r s Domain E Domain C Domain B Domain D Domain A MSDP Peers RP Join (S, 224.2.2.2) r Domain C RP Domain B RP RP Domain D RP s Domain A Taschin Antonio

MSDP Example r s Domain E Domain C Domain B Domain D Domain A MSDP Peers Multicast Traffic RP r Domain C RP Domain B RP RP Domain D RP s Domain A Taschin Antonio

Implementazione Cisco MSDP draft-ietf-msdp-spec-02.txt Multiple peer support Peer with BGP, MBGP, or static peers SA caching (off by default) Sending and receiving SA-requests Sending and receiving SA-responses Taschin Antonio

Cisco MSDP Implementation SA input and output filtering SA-request input filtering Default peer support So a tail site can MSDP with a backbone provider without requiring the two to BGP peer Triggered join support when creating an (S,G) learned by MSDP Mesh gruppos Reduces RPF-flooding of SA messages between fully meshed MSDP peers Taschin Antonio

MSDP Configuration Configure peers Configure default peer SA caching ip msdp peer <ip-address> [connect-source <i/f>] Configure default peer ip msdp default-peer <ip-address> [prefix-list acl] SA caching ip msdp cache-sa-state [list <acl>] Mesh gruppos ip msdp mesh-gruppo <name> <ip-address> Taschin Antonio

MSDP Configuration (Cont.) Filtering Can filter SA in/out, gruppos, with acls or route-maps TTL Scoping ip msdp ttl-threshold <ip-address> <ttl> For more configuration commands see: ftp://ftpeng.cisco.com/ipmulticast/ msdp-commands Taschin Antonio

Architettura per l’allocazione degli indirizzi Taschin Antonio

FINE ataschin@unive.it ataschin@dsi.unive.it Taschin Antonio