1. Introduzione
Il modello di servizio di multicast del protocollo Internet (Internet Protocol, IP) è definito nella RFC 1112 [RFC1112]. La RFC 1112 stabilisce che i datagrammi inviati a un indirizzo di multicast IP (224.0.0.0 - 239.255.255.255) G vengono recapitati a ciascun "modulo di protocollo di livello superiore" che ha richiesto la ricezione di datagrammi inviati all'indirizzo G. La RFC 1112 chiama il servizio di rete identificato dall'indirizzo di destinazione G un "gruppo di host" (host group). Questo modello supporta sia la comunicazione di gruppo uno-a-molti che molti-a-molti. Il presente documento utilizza il termine "multicast con sorgente arbitraria" (Any-Source Multicast, ASM) per riferirsi al modello di multicast definito nella RFC 1112. La RFC 3513 [RFC3513] specifica la forma degli indirizzi di multicast IPv6 con semantica ASM.
L'intervallo di indirizzi IPv4 232/8 (232.0.0.0 - 232.255.255.255) è attualmente designato come indirizzo di destinazione per il multicast specifico della sorgente (Source-Specific Multicast, SSM) ed è riservato all'uso di applicazioni e protocolli specifici della sorgente [IANA-ALLOC].
Per IPv6, secondo le convenzioni di [IPv6-UBM], il prefisso di indirizzo FF3x::/32 è riservato per il multicast specifico della sorgente, dove 'x' è un identificatore di scope (scope identifier) valido qualsiasi. Utilizzando la terminologia di [IPv6-UBM], tutti gli indirizzi SSM devono avere P=1, T=1 e plen=0. [IPv6-MALLOC] richiede inoltre che il campo del prefisso di rete degli indirizzi SSM sia impostato a zero, pertanto tutti gli indirizzi SSM rientrano nell'intervallo FF3x::/96. Documenti futuri potrebbero consentire campi del prefisso di rete non nulli, ad esempio se viene definita una nuova mappatura da indirizzo IP a indirizzo MAC. Pertanto, l'allocazione degli indirizzi deve essere effettuata nell'intervallo FF3x::/96, ma i sistemi DEVONO (MUST) trattare l'intero FF3x::/32 come indirizzi SSM, per rimanere compatibili con un uso futuro eventuale del campo del prefisso di rete.
Gli indirizzi nell'intervallo FF3x::4000:0001 - FF3x::7FFF:FFFF sono riservati da [IPv6-MALLOC] per l'allocazione IANA. Gli indirizzi nell'intervallo FF3x::8000:0000 - FF3x::FFFF:FFFF sono consentiti per l'allocazione dinamica da parte degli host, come descritto in [IPv6-MALLOC]. Gli indirizzi nell'intervallo FF3x::0000:0000 - FF3x::3FFF:FFFF sono indirizzi SSM IPv6 non validi. ([IPv6-MALLOC] indica che FF3x::0000:0001 - FF3x::3FFF:FFFF devono avere P=0 e T=0, ma per SSM [IPv6-UBM] richiede P=1 e T=1, pertanto questi indirizzi sono specificati come non validi.) La gestione dei pacchetti inviati a tali indirizzi non validi non è definita -- il router o l'host possono scegliere di scartare tali pacchetti.
Per i datagrammi inviati a un indirizzo SSM, viene fornita la semantica di consegna del multicast specifico della sorgente. Cioè, un datagramma il cui indirizzo IP sorgente è S e il cui indirizzo di destinazione SSM è G verrà recapitato solo ai "socket" (socket) di livello superiore che hanno esplicitamente richiesto la ricezione di datagrammi inviati dalla sorgente S all'indirizzo G, e solo a tali socket. Rispetto al modello ASM della RFC 1112, l'SSM fornisce a livello di rete solo il supporto per la consegna uno-a-molti.
I vantaggi del multicast specifico della sorgente sono i seguenti:
-
Eliminazione della consegna incrociata del traffico quando due sorgenti utilizzano simultaneamente lo stesso indirizzo di destinazione specifico della sorgente. L'uso simultaneo di un medesimo indirizzo di destinazione SSM da parte di più sorgenti e diverse applicazioni è esplicitamente supportato.
-
Eliminazione, grazie alla caratteristica sopra, della necessità di coordinamento tra gli host nella scelta di un indirizzo sorgente specifico.
-
Eliminazione di molti protocolli e algoritmi di routing necessari per fornire il modello di servizio ASM. Ad esempio, l'"albero condiviso" (shared tree) e i punti di rendezvous (Rendezvous Points) del protocollo PIM - Sparse Mode (PIM-SM) [PIM-SM] non sono richiesti per supportare il modello specifico della sorgente. I meccanismi di router necessari per supportare SSM sono in larga misura un sottoinsieme di quelli necessari per supportare ASM. Ad esempio, il meccanismo dello shortest-path tree del protocollo PIM-SM può essere adattato per fornire la semantica SSM.
Come per ASM, l'insieme dei ricevitori non è noto al mittente SSM. Il mittente SSM non ottiene né l'identità né il numero dei ricevitori.
L'SSM è particolarmente adatto per applicazioni di tipo diffusione (dissemination-style) in cui vi è uno o più mittenti e l'identità del mittente è nota prima dell'avvio dell'applicazione. Ad esempio, un'applicazione di distribuzione dati che desideri fornire una sorgente dati di backup in caso di guasto della sorgente dati principale può utilizzare un canale per sorgente e informare i ricevitori di entrambi i canali. L'SSM può anche essere utilizzato per costruire applicazioni multi-sorgente in cui l'identità di tutti i partecipanti non è nota in anticipo, ma in questo caso la funzione di "rendezvous" (rendezvous) multi-sorgente non si verifica a livello di rete. Come nelle applicazioni che utilizzano l'unicast (unicast) come trasporto sottostante, questa funzione può essere implementata dall'applicazione stessa o da una libreria di livello applicativo.
L'individuazione delle risorse multicast, in cui un client invia direttamente una query multicast al "gruppo di localizzazione del servizio" (service location group) su cui un server è in ascolto, non è supportata direttamente da SSM.
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" del presente documento DEVONO (MUST) essere interpretate come descritto nella RFC 2119 [RFC2119].
Il presente documento definisce la semantica degli indirizzi di multicast specifico della sorgente e specifica la politica che ne governa l'utilizzo. In particolare, definisce l'estensione del servizio di rete Internet applicabile ai datagrammi inviati a indirizzi SSM e definisce le estensioni host necessarie per supportare tale servizio di rete. Gli host, i router, le applicazioni e i protocolli che utilizzano questi indirizzi DEVONO (MUST) conformarsi alla politica esposta nel presente documento. Un host che non si conforma può impedire a tale host o ad altri host sullo stesso LAN di ricevere il traffico inviato su un canale SSM. Un router che non si conforma può causare il recapito del traffico SSM a parti della rete che non lo richiedono, imponendo così un carico non necessario alla rete.