Unicast vs Multicast Unicast Host Router Multicast Host Router

Sorgente multicast IGMP Rete IP multicast Se gli host non sono collegati tramite una rete broadcast (i.e. ethernet), le operazioni di replica possono essere particolarmenti pesanti (tipicamente hw based); se si pensa ad apparati di accesso Internet si possono avere anche decine di migliaia di host Sorgente multicast Rete IP multicast IGMP I Router della rete multicast hanno il compito di gestire il protocollo per la creazione dell’albero di distribuzione e il forwarding dei pacchetti multicast I router di accesso gestiscono le richieste di connessione ai gruppi da parte degli host (IGMP)

Indirizzi multicast Gruppo di indirizzi IP riservato per identificare i gruppi multicast 224.0.0.0–239.255.255.255 Indirizzi di classe D; I bit più alti sono: “1110” Sottogruppo di indirizzi multicast riservati: 224.0.0.0–224.0.0.25: 224.0.0.1 Tutti gli host di una sottorete 224.0.0.2 Tutti i router di una sottorete 224.0.0.5|6 OSPF IANA Reserved Addresses IANA is the responsible Authority for the assignment of reserved class D addresses. Other interesting reserved addresses are: 224.0.0.2 - PIMv1 (ALL-ROUTERS - due to transport in IGMPv1) 224.0.0.5 - OSPF ALL ROUTERS (RFC1583) 224.0.0.6 - OSPF DESIGNATED ROUTERS (RFC1583) 224.0.0.9 - RIP2 Routers 224.0.0.13 - PIMv2 224.0.1.39 - CISCO-RP-ANNOUNCE (Auto-RP) 224.0.1.40 - CISCO-RP-DISCOVERY (Auto-RP) “ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses” is the authoritative source for reserved multicast addresses. Additional Information "Administratively Scoped IP Multicast", June 1997, has a good discussion on scoped addresses. This document is available at: “draft-ietf-mboned-admin-ip-space-03.txt” 4

Mapping tra indirizzi multicast e ethernet 2^5 = 32 ind. Mcast mappati sullo stesso ind. ethernet 224-239 138 1 224 10 1 Ind. mcast 1110 0000 0000 1010 0000 0000 0000 0001 1 5 E 00 A 1 Ind. Ethernet Prefisso 24 bit IEEE dedicato al multicast 23 bit utilizzati per il mapping Riservato usi futuri 5

IGMP Fa parte del protocollo IP 3 messaggi Membership Query Leave Il router designato invia query verso 224.0.0.1 (tutti gli host della rete) con timetolive = 1 (il messaggio non va oltre la rete locale) Su una LAN c’è un solo router “designato” “Query interval” viene scelto considerando le necessità di interazione (tempo di zapping) e di limitazione del traffico di segnalazione Membership Report Inviato dagli host (prima di inviare una risposta gli host aspettano un tempo casuale: se si accorgono che un altro host ha già inviato un report, desistono) Il report può essere “spontaneo”; ciò accade quando l’host si connette ad un gruppo multicast la prima volta Leave IGMP Membership Queries IGMPv1 Membership Queries are sent by the router to the “All-Hosts” (224.0.0.1) multicast address to solicit what multicast groups have active receivers on the local network. IGMP Membership Reports IGMPv1 Membership Reports are sent by hosts wishing to receive traffic for a specific multicast group. Membership Reports are sent (with a TTL of 1) to the multicast address of the group for which the hosts wishes to receive traffic. Hosts either send reports asynchronously (when the wish to first join a group) or in response to Membership Queries. In the latter case, the response is used to maintain the group in an active state so that traffic for the group continues to be forwarded to the network segment. Report Suppression Report suppression is used among group members so that all members do not have to respond to a query. This saves CPU and bandwidth on all systems. The rule in multicast membership is that as long as one member is present, the group must be forwarded onto that segment. Therefore, only one member present is required to keep interest in a given group so report supression is efficient. TTL Since Membership Query and Report packets only have local significance, the TTL of these packets are always set to 1. This is also so they will not be accidentaly forwarded off of the local subnet and cause confusion on other subnets. 9

Pacchetti IGMPv2 7 15 31 Max. Resp. Time Type Checksum Group Address 0x11 = Membership Query 0x12 = Membership Report (v.1) 0x16 = Membership Report (v.2) 0x17 = Leave Max. Resp. Time tempo max entro cui il router si aspetta una risposta viene usato dagli host come limite max nella scelta random del tempo di risposta (Default = 10 secs) Group Address: Indirizzo del gruppo multicast (0.0.0.0 indica una query di tipo generale…any group) 17

Join asincrona H2 effettua una join asincrona 1.1.1.10 1.1.1.11 1.1.1.12 H2 224.1.1.1 Report H2 H1 H3 1.1.1.1 rtr-a H2 effettua una join asincrona Invia un report senza aver ricevuto una query Riduce la latenza (query cicliche) Rtr-a mantiene attivo il gruppo fino allo scadere di un timer che viene resettato da successivi nuovi report 18

Meccanismo di elezione 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 rtr-b rtr-a Inizialmente tutti i router inviano query Ogni router legge le query inviate dagli altri host Il router con l’IP più basso viene eletto (gli altri non inviano più query) Se scade un time-out (router eletto non ha inviato query) riparte il processo di elezione (meccanismo di recovery) 20

Soppressione delle risposte 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 Il router invia query periodiche Gli host settano un timer tra [0,max resp timer] Se scade il timer invia il report; se invece riceve un report sopprime il timer e non invia alcun report Nella figura, H1 e H3 non inviano report 22

Leave 1.1.1.10 1.1.1.11 1.1.1.12 Leave to 224.0.0.2 224.1.1.1 #1 Report to 224.1.1.1 #3 H2 H2 H1 H3 1.1.1.1 Group Specific Query to 224.1.1.1 #2 rtr-a H2 lascia il gruppo; manda un messaggio Leave relativo al gruppo 224.1.1.1 a tutti i router della rete (224.0.0.2) Il router manda una query specifica verso tutti gli host che sono in ascolto su 224.1.1.1 H3 che è ancora in ascolto manda un report su 224.1.1.1 Il router continua ad inviare traffico sul gruppo 224.1.1.1 24

Leave …continua L’ultimo host attivo sul gruppo manda un Leave Leave to 224.0.0.2 224.1.1.1 #1 1.1.1.11 1.1.1.12 H3 H1 H2 H3 Group Specific Query to 224.1.1.1 #2 rtr-a L’ultimo host attivo sul gruppo manda un Leave Il router invia una query specifica Scade il max-resp-timer Il router cancella il gruppo 26

IGMP v3 Source = 1.1.1.1 Group = 224.1.1.1 Source = 2.2.2.2 H1 vuole ricevere il gruppo da S = 1.1.1.1 ma non da S = 2.2.2.2 R3 può effettuare il prune della sorgente S = 2.2.2.2 R3 IGMPv3: Join 1.1.1.1, 224.1.1.1 Leave 2.2.2.2, 224.1.1.1 H1 37

Flooding del traffico multicast su apparati di livello 2 (e.g. switch) Multicast M PIM Gli apparati di livello 2 tipicamente non sanno come trattare il traffico multicast e si limitano ad effettuare un broadcast verso tutte le interfacce. L2 Multicast Switching For most L2 Switches, Multicast traffic is normally treated like an unknown MAC address or Broadcast frame which causes the frame to be flooded out every port within a VLAN at rates of over 1 Mpps. This is fine for unknowns and broadcasts but as we have seen earlier, IP Multicast hosts may join and be interested in only specific multicast groups. Again, on most L2 Switches, all this traffic is forwarded out all ports resulting in wasted bandwidth on both the segments and on the end stations. One way around this on Catalyst Switches is using the Command Line Interface to program the switch manually to associate a multicast MAC address with say ports 5,6,7 so only ports 5,6,and 7 receive the multicast traffic destined for the multicast group. This works fine but again we know IP Multicast hosts dynamically join and leave groups using IGMP to signal to the Multicast Router. This static way of entering the multicast information is not very scaleable. Dynamic configuration of the Switches’ forwarding tables would be a better idea, and cut down on user administration. 38

Trattamento del traffico multicast su apparati di livello 2 (e. g Trattamento del traffico multicast su apparati di livello 2 (e.g. switch) Gli apparati di livello 2 (e.g. switches) devono essere “IGMP” aware. I pacchetti IGMP vengono intercettati da hardware specializzato ASICs (IGMP snooping) Lo switch deve esaminare i messaggi IGMP Report e Leave associandogli alle specifiche porte Inoltre deve effettuare il “Proxy” dei messaggi verso il router ( possibilmente filtra i messaggi, join successivo al primo, leave quando ci sono altri host in ascolto sul gruppo) PIM IGMP IGMP 40

Algoritmi di routing multicast Flooding: inoltrno dei pacchetti ricevuti su tutte le interfacce quando il pacchetto è ricevuto per la prima volta Non prevede l’utilizzo di alcun protocollo di instradamento Non utilizza le informazioni sull’attività degli host Richiede di tener traccia di tutti i pacchetti ricevuti Spanning tree Consente di trasmettere il traffico multicast senza incorrere in loop Utilizzo non ottimizzato della rete Reverse Path Forwarding (spiegato in dettaglio in seguito) Shortest path tree

Protocolli multicast Prevedono lo scambio di opportuni messaggi tra i router; tali messaggi forniscono le informazioni necessarie al trattamento dei pacchetti multicast agli algoritmi di instradamento Tipi di protocollo multicast: PIM (Protocol Indipendent Multicast) Indipendent perché utilizza le informazioni di routing fornite da protolli di unicast esterni qualsiasi PIM Dense Mode PIM Sparse Mode I concetti su cui si basa sono: Multicast Distribution Trees Multicast Forwarding

Multicast Distribution Trees Shortest Path o Source Distribution Tree Source Notation: (S, G) S = Source G = Group A B D F Minimizza il numero di hop Viene calcolato per ogni coppia sorgente/destinazione C E Receiver 1 Receiver 2

Multicast Distribution Trees Shared Distribution Tree Sorgente 1 Notation: (*, G) * = All Sources G = Group Sorgente 2 A B D (Shared Root) F Tutti ricevono tutti i gruppi multicast attraverso lo shared root C E Ricevitore 1 Ricevitore 2

Forwarding Multicast Logica inversa rispetto al Routing Unicast Routing Unicast analizza IP_Destinazione Routing Multicast analizza IP_Source e applica il “Reverse Path Forwarding”: IP_source è l’indirizzo da cui proviene la trasmissione multicast IP_destinazione è il gruppo multicast RPF: consente di evitare le duplicazioni scegliendo l’interfaccia da cui ricevere il traffico multicast (su tutte le altre è scartato); l’interfaccia scelta è quella che si userebbe per inviare traffico verso la sorgente (tabella di routing unicast)

RPF RPF Check Fallisce: il traffico è scartato Mcast Dist. Tree Sorgnte mcast 151.10.3.21 S0 S1 S2 Router con comportamento anomalo E0 RPF Check Fallisce: il traffico è scartato Mcast Dist. Tree Pacchetti Mcast

Pacchetto multicast con Check RPF che fallisce Pacchetto multicast con IP sorgente 151.10.3.21 X S0 RPF Check Fails! S1 S2 Multicast Route Table Network Interface 151.10.0.0/16 S1 198.14.32.0/24 S0 204.1.16.0/24 E0 E0 Pacchetto arrivato da una interfaccia sbagliata (verrà scartato)

Check RPF che ha successo Pacchetto multicast con IP sorgente 151.10.3.21 S0 S1 S2 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) E0 Multicast Route Table Network Interface 151.10.0.0/16 S1 198.14.32.0/24 S0 204.1.16.0/24 E0 Il pacchetto arriva dall’interfaccia corretta e viene forwardato su tutte le altre interfacce (distribution tree)

Tipi di protocollo multicast Differiscono dal modo in cui costruiscono e gestiscono il distribution tree (DT) Dense-mode (si assume un’alta densità di ricevitori) Inizialmente effettua il flooding, i router non interessati chiedono di essere rimossi dal DT (prune) quando un ramo viene tagliato viene più inviato traffico dopo un tempo prestabilito, il ramo tagliato riceve nuovamente traffico e il router deve eventualmente richiedere il prune Sparse-mode (si assume che solo alcune zone saranno interessate alla trasmissione) I router interessati devono fare richiesta esplicita (join) per essere aggiunti al DT Usa lo shared distribution tree ma al superamento di soglie prefissate i router possono comandare la costruzione di un source distribution tree

Pacchetti PIM Join/Prune Sia il DM sia lo SP usano pacchetti di segnalazione per aggiungere o togliere dei rami dal distribution tree; tali pacchetti contengono un elenco di gruppi multicast (multicast group) ciascuno dei quali contiente a sua volta una lista di sorgenti su cui fare Join o Prune Gruppo n JOIN ( Sorgente 1, Sorgente 2,…) ----- (S;G) Gruppo k PRUNE ( *, RP) ---- (*,G) Gruppo m JOIN (*, RP) ---- chiede che la Join venga propagata fino allo shared root/rendevouz point (per default sarebbe propagata fino alla sorgente) 10

PIM DM: flooding S1 S0 rtr-a S3 S0 rtr-b E1 Pacchetto multicast (128.9.160.43, 224.2.127.254) S0 rtr-a S3 “rtr-a” inoltra il traffico (S, G) su tutte le interfacce (tranne quella da cui lo ha ricevuto) S0 rtr-b E1 A questo punto su rtr-a esistono due entry: per (*, G) e (S, G) (*, 224.2.127.254) con interfacce di uscita S1 e S3 (128.9.160.43, 224.2.127.254) con interfacce di uscita S1 e S3 La entry, (*, G) è creata appena si riceve un pacchetto da qualsiasi sorgente per G opprure quando si riceve una richiesta di connessione al gruppo (JOIN IGMP) da un host locale 24

PIM DM: prune Prune (S,G) S1 S0 rtr-a S3 S0 rtr-b E1 Rtr-b non ha ricevitori, quindi invia un messaggio di prune (S,G) A questo punto su rtr-a nella entry (128.9.160.43, 224.2.127.254) l’interfaccia S0 viene messa in stato di prune; ma è solo sospesa per un tempo fissato (e.g 3 min) dopo di che ritorna in stato di forward

PIM DM: Grafting Pacchetti (S,G) S0 S1 rtr-a 3 PIM Graft-ACK E0 4 2 rtr-b rtr-c E1 E1 A IGMP Join 1 A invia una JOIN per il gruppo G. 1 “rtr-b” invia un messaggio PIM Graft per il gruppo (S,G) verso rtr-a 2 “rtr-a” invia un riscontro (PIM Graft-Ack) 3 “rtr-a” inizia a tramettere il traffico per (S,G). 4 36

Tabella di routing unicast PIM SM: Forwarding RP (10.1.5.1) Source Tree Pacchetti Multicast (128.9.160.43, 224.1.1.2) S1 Shared Tree Pacchetti Multicast (128.9.160.1, 224.1.1.1) S0 rtr-a E0 E0 rtr-b Route Intfc 10.1.5.0/24 S0 10.1.2.0/24 E0 128.9.0.0/16 S1 E1 Tabella di routing unicast Nel protocollo Sparse mode il check RPF usa: l’indirizzo del RP, nel caso di shared trees l’indirizzo sorgente nel caso di shortest-path tree 10

PIM SM: Forwarding Quando un router riceve un pacchetto multicast per il gruppo G lo inoltra su un’altra interfaccia se: ha ricevuto un pacchetto di JOIN PIM per il gruppo G su quella interfaccia da un router adiacente un host su quella interfaccia ha inviato una richiesta IGMP per il gruppo G Al contrario del dense mode, i router PIM-SM assumo che non ci sono ricevitori interessati al gruppo in assneza di JOIN esplicite Al contrario del DM, i router a valle del RP rispetto alla sorgente non si devono preocuppare dell’indirizzo sorgente dei pacchetti multicast perché tutto il traffico passa per i RP (infatti il check RFP è fatto sull’indirizzo IP del RP) I router a valle del RP mantengono lo stato (*,G) I router tra la sorgente e il RP mantengono lo stato (S,G) . 11

PIM SM: costruzione del distribution tree (caso in cui il ricevitore si registra per primo su RP) Il router sorgente invia il primo pacchetto multicast che riceve in un pacchetto unicast di registrazione verso RP (register); Quando RP riceve il primo pacchetto multicast completa il processo di registrazione R1 S RS I router sul percorso S-RP intercettano la join e creano le entry (S,G) mettendo in stato di forward l’interfaccia da cui è arrivata la join RP chiede di costruire il DT join(S,G) RP R4 invia una join (*,G) verso RP R2 I router R3, R2 intercettano le join e creano le entry (*,G) mettendo le interfacce da cui ricevono la join in stato di forward R3 R4 R4 crea l’entry (*,G) e mette in forward l’interfaccia verso RCR Il ricevitore chiede di ascoltare il gruppo (*,G) tramite messaggio IGMP; RECEIVER 12

PIM SM: creazione del distribution tree (caso in cui la sorgente si registra per prima su RP) 4 RP manda un messaggio prune (S,G) verso R1 (che però lo ignora in quanto anch’esso non ha il gruppo G attivo 3. RP non ha uno stato (*,G) e quindi scarta il pacchetto R1 S RS 2. RS crea lo stato (*,G) e (S,G) e incapsula il pacchetto mcast in un messaggio unicast PIM register verso RP RP 1. S invia il primo pacchetto mcast 5 RP invia un msg register stop a RS 7 RP riceve un PIM join (*,G) da R4 (RCR ha chiesto il gruppo G) 6 RS riceve il register stop e non inoltra più i pacchetti mcast ricevuti da S in pacchetti unicast di register (RS non è più nello stato di registering)…cancella lo stato (S,G) In questo momento R1 vede attivo il gruppo (S,G) perché ha ricevuto un prune da RP ma non ha interfacce attive, anche RP ha il gruppo (S,G) ma non interfacce attive (non ci sono ricevitori connessi) R2 8 RP cerca tutte le entry (S,G) e invia un PIM join verso tutte le sorgenti trovate Fino a questo momento RS ha attivato lo stato (S,G) è in stato “registering” e non ha interfacce di forward attive poiché non ha ricevuto nessuna join R3 R2-R3,R4 intercettano la join e creano il distribution tree R4 Receiver

PIM SM: pruning del distribution tree RS RP RCR lascia il gruppo G (leave IGMP); R4 cancella l’interfaccia verso RCR dal ouil del gruppo G. Poiché R4 non ha altre interfacce attive per il gruppo G, invia un messaggio di prune (*,G) verso il RP R2 Rec. 2 R2 intercetta il messaggio, rimuove l’interfaccia dal DT ma non inoltra il messaggio R3 intercetta il messaggio prune e rimuove l’ interfaccia dal DT Poiché non ha altre interfacce attive inoltra il messaggio di prune verso RP R3 R4 R4 ha un solo ricevitore attivo sul gruppo G Receiver

Source Specific Multicast Utilizzato quando le sorgenti sono poche e ben definite (e.g. head end di trasmissioni TV) Prevedono l’utilizzo del protocollo IGMP v3 Permette una notevole semplificazione dei processi dei router