slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Unicast vs Multicast PowerPoint Presentation
Download Presentation
Unicast vs Multicast

Loading in 2 Seconds...

play fullscreen
1 / 33

Unicast vs Multicast - PowerPoint PPT Presentation


  • 110 Views
  • Uploaded on

Unicast vs Multicast. Unicast. Host. Router. Multicast. Host. Router.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Unicast vs Multicast' - tamika


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Unicast vs Multicast

Unicast

Host

Router

Multicast

Host

Router

slide2

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
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
mapping tra indirizzi multicast e ethernet
Mapping tra indirizzi multicast e ethernet

2^5 = 32 ind. Mcast mappati sullo stesso ind. ethernet

224-239

138

1

224

10

0

1

Ind. mcast

1110

0000

0000

1010

0000

0000

0000

0001

0

1

0

0

5

E

00

A

0

0

0

1

Ind. Ethernet

Prefisso 24 bit IEEE dedicato al multicast

23 bit utilizzati per il mapping

Riservato usi futuri

slide5
IGMP
  • Fa parte del protocollo IP
  • 3 messaggi
    • Membership Query
    • 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
pacchetti igmpv2
Pacchetti IGMPv2

7

15

31

Max. Resp. Time

Type

Checksum

Group Address

Type:

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)

join asincrona

224.1.1.1

H2

H2

Report

Join asincrona

1.1.1.10

1.1.1.11

1.1.1.12

H3

H1

  • 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

1.1.1.1

rtr-a

meccanismo di elezione

Query

Query

Meccanismo di elezione

1.1.1.10

1.1.1.11

1.1.1.12

H2

H3

H1

1.1.1.2

1.1.1.1

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)
soppressione delle risposte

224.1.1.1

224.1.1.1

224.1.1.1

H2

H3

H1

X

X

Suppressed

Report

Suppressed

Query

Soppressione delle risposte

1.1.1.10

1.1.1.11

1.1.1.12

  • 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

1.1.1.1

leave

224.1.1.1

224.1.1.1

H2

H2

Report to

224.1.1.1

Leave to

224.0.0.2

#1

#3

Group Specific

Query to 224.1.1.1

#2

Leave

1.1.1.10

1.1.1.11

1.1.1.12

H3

H1

  • 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

1.1.1.1

rtr-a

leave continua

224.1.1.1

H3

Leave to

224.0.0.2

#1

Group Specific

Query to 224.1.1.1

#2

Leave …continua

1.1.1.11

1.1.1.12

H2

H3

H1

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
igmp v3
IGMP v3

Source = 1.1.1.1

Group = 224.1.1.1

Source = 2.2.2.2

Group = 224.1.1.1

R2

R1

  • 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

flooding del traffico multicast su apparati di livello 2 e g switch

PIM

Multicast M

Flooding del traffico multicast su apparati di livello 2 (e.g. switch)
  • Gli apparati di livello 2 tipicamente non sanno come trattare il traffico multicast e si limitano ad effettuare un broadcast verso tutte le interfacce.
trattamento del traffico multicast su apparati di livello 2 e g switch
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

algoritmi di routing multicast
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
    • Non utilizza le informazioni sull’attività degli host
    • Utilizzo non ottimizzato della rete
  • Reverse Path Forwarding (spiegato in dettaglio in seguito)
  • Shortest path tree
protocolli multicast
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
Multicast Distribution Trees

Shortest Path o Source Distribution Tree

Source

Notation: (S, G)

S = Source

G = Group

A

B

F

D

C

E

Receiver 1

Receiver 2

multicast distribution trees1
Multicast Distribution Trees

Shared Distribution Tree

Sorgente 1

Notation: (*, G)

* = All Sources

G = Group

Sorgente 2

D

(Shared Root)

A

B

F

C

E

Ricevitore 1

Ricevitore 2

forwarding multicast
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)
slide20

RPF

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

slide21

Multicast Route Table

Network Interface

151.10.0.0/16 S1

198.14.32.0/24 S0

204.1.16.0/24 E0

Check RPF che fallisce

Pacchetto multicast con

IP sorgente 151.10.3.21

X

S0

RPF Check Fails!

S1

S2

E0

Pacchetto arrivato da una interfaccia sbagliata (verrà scartato)

slide22

Multicast Route Table

Network Interface

151.10.0.0/16 S1

198.14.32.0/24 S0

204.1.16.0/24 E0

Check RPF che ha successo

Pacchetto multicast con

IP sorgente 151.10.3.21

S0

S1

S2

E0

Il pacchetto arriva dall’interfaccia corretta e viene forwardato su tutte le altre interfacce (distribution tree)

tipi di protocollo multicast
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
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)

pim dm flooding
PIM DM: flooding

S1

S0

Pacchetto multicast

(128.9.160.43, 224.2.127.254)

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
slide26

PIM DM: prune

S1

S0

rtr-a

S3

Prune (S,G)

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

A

  • 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

PIM DM: Grafting

Pacchetti (S,G)

S0

S1

rtr-a

3

PIM Graft-ACK

E0

4

PIM Graft

E0

E0

2

rtr-b

rtr-c

E1

E1

IGMP Join

1

pim sm forwarding
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

Route Intfc

10.1.5.0/24 S0

10.1.2.0/24 E0

128.9.0.0/16 S1

rtr-b

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
pim sm forwarding1
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)
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

RP chiede di costruire il DT join(S,G)

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

R4 invia una join (*,G) verso RP

Il ricevitore chiede di ascoltare il gruppo (*,G) tramite messaggio IGMP;

PIM SM: costruzione del distribution tree(caso in cui il ricevitore si registra per primo su RP)

R1

S

RS

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

RECEIVER

slide31

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

5 RP invia un msg register stop a RS

1. S invia il primo pacchetto mcast

2. RS crea lo stato (*,G) e (S,G) e incapsula il pacchetto mcast in un messaggio unicast PIM register verso RP

8 RP cerca tutte le entry (S,G) e invia un PIM join verso tutte le sorgenti trovate

7 RP riceve un PIM join (*,G) da R4 (RCR ha chiesto il gruppo G)

3. RP non ha uno stato (*,G) e quindi scarta il pacchetto

R1

S

RS

RP

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

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

slide32

PIM SM: pruning del distribution tree

R2 intercetta il messaggio, rimuove l’interfaccia dal DT ma non inoltra il messaggio

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

R1

S

RS

RP

R2

Rec. 2

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
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