1. Introduction (Introduzione)
Il modello di servizio multicast del protocollo Internet (IP) è definito nell'RFC 1112 [RFC1112]. L'RFC 1112 specifica che un datagramma inviato a un indirizzo multicast IP (da 224.0.0.0 a 239.255.255.255) G viene consegnato a ciascun "modulo di protocollo di livello superiore" che ha richiesto la ricezione di datagrammi inviati all'indirizzo G. L'RFC 1112 chiama il servizio di rete identificato da un indirizzo di destinazione multicast G un "gruppo di host". Questo modello supporta sia la comunicazione di gruppo uno-a-molti che molti-a-molti. Questo documento utilizza il termine "Any-Source Multicast" (ASM) per riferirsi al modello di multicast definito nell'RFC 1112. L'RFC 3513 [RFC3513] specifica la forma degli indirizzi multicast IPv6 con semantica ASM.
Gli indirizzi IPv4 nell'intervallo 232/8 (da 232.0.0.0 a 232.255.255.255) sono attualmente designati come indirizzi di destinazione multicast specifici della sorgente (SSM) e sono riservati per l'uso da parte di applicazioni e protocolli specifici della sorgente [IANA-ALLOC].
Per IPv6, il prefisso dell'indirizzo FF3x::/32 è riservato per l'uso multicast specifico della sorgente, dove 'x' è qualsiasi identificatore di ambito valido, da [IPv6-UBM]. Utilizzando la terminologia di [IPv6-UBM], tutti gli indirizzi SSM devono avere P=1, T=1 e plen=0. [IPv6-MALLOC] impone che il campo del prefisso di rete di un indirizzo SSM sia anch'esso impostato a zero, quindi tutti gli indirizzi SSM rientrano nell'intervallo FF3x::/96. Documenti futuri potrebbero consentire un campo prefisso di rete diverso da zero se, ad esempio, viene definita una nuova mappatura da indirizzo IP a indirizzo MAC. Pertanto, l'allocazione degli indirizzi dovrebbe (SHOULD) avvenire all'interno dell'intervallo FF3x::/96, ma un sistema dovrebbe (SHOULD) trattare tutto FF3x::/32 come indirizzi SSM, per consentire la compatibilità con possibili usi futuri del campo prefisso di rete.
Gli indirizzi nell'intervallo da FF3x::4000:0001 a FF3x::7FFF:FFFF sono riservati in [IPv6-MALLOC] per l'allocazione da parte della IANA. Gli indirizzi nell'intervallo da FF3x::8000:0000 a FF3x::FFFF:FFFF sono consentiti per l'allocazione dinamica da parte di un host, come descritto in [IPv6-MALLOC]. Gli indirizzi nell'intervallo da FF3x::0000:0000 a FF3x::3FFF:FFFF sono indirizzi SSM IPv6 non validi. ([IPv6-MALLOC] indica che da FF3x::0000:0001 a FF3x::3FFF:FFFF devono impostare P=0 e T=0, ma per SSM, [IPv6-UBM] impone che P=1 e T=1, da cui la loro designazione come non validi.) Il trattamento di un pacchetto inviato a un tale indirizzo non valido non è definito -- un router o un host PUÒ (MAY) scegliere di scartare tale pacchetto.
La semantica di consegna multicast specifica della sorgente viene fornita per un datagramma inviato a un indirizzo SSM. Cioè, un datagramma con indirizzo IP sorgente S e indirizzo di destinazione SSM G viene consegnato a ciascun "socket" di livello superiore che ha specificamente richiesto la ricezione di datagrammi inviati all'indirizzo G dalla sorgente S, e solo a quei socket. Il servizio di rete identificato da (S,G), per l'indirizzo SSM G e l'indirizzo dell'host sorgente S, viene denominato "canale". A differenza del modello ASM dell'RFC 1112, SSM fornisce supporto a livello di rete solo per la consegna uno-a-molti.
I vantaggi del multicast specifico della sorgente includono:
-
Eliminazione della consegna incrociata del traffico quando due sorgenti utilizzano contemporaneamente lo stesso indirizzo di destinazione specifico della sorgente. L'uso simultaneo di un indirizzo di destinazione SSM da parte di più sorgenti e diverse applicazioni è esplicitamente supportato.
-
Evitare la necessità di coordinamento tra host quando si scelgono indirizzi specifici della sorgente, come conseguenza di quanto sopra.
-
Evitare molti dei protocolli e degli algoritmi del router necessari per fornire il modello di servizio ASM. Ad esempio, gli "alberi condivisi" e i punti di incontro (Rendezvous Points) del protocollo PIM - Sparse Mode (PIM-SM) [PIM-SM] non sono necessari per supportare il modello specifico della sorgente. I meccanismi del router richiesti per supportare SSM sono infatti in gran parte un sottoinsieme di quelli utilizzati per supportare ASM. Ad esempio, il meccanismo dell'albero del percorso più breve del protocollo PIM-SM può essere adattato per fornire la semantica SSM.
Come ASM, l'insieme dei ricevitori è sconosciuto a un mittente SSM. A una sorgente SSM non viene fornita né l'identità dei ricevitori né il loro numero.
SSM è particolarmente adatto per applicazioni in stile diffusione con uno o più mittenti le cui identità sono note prima dell'inizio dell'applicazione. Ad esempio, un'applicazione di diffusione dati che desidera fornire una sorgente dati secondaria nel caso in cui la sorgente primaria fallisca potrebbe implementare ciò utilizzando un canale per ciascuna sorgente e pubblicizzando entrambi ai ricevitori. SSM può essere utilizzato per costruire applicazioni multi-sorgente in cui le identità di tutti i partecipanti non sono note in anticipo, ma la funzionalità di "rendezvous" multi-sorgente non avviene nel livello di rete in questo caso. Proprio come in un'applicazione che utilizza unicast come trasporto sottostante, questa funzionalità può essere implementata dall'applicazione o da una libreria a livello di applicazione.
La scoperta delle risorse multicast nella forma in cui un client invia una query multicast direttamente a un "grouppo di posizione del servizio" a cui i server ascoltano non è direttamente supportata da SSM.
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto nell'RFC 2119 [RFC2119].
Questo documento definisce la semantica degli indirizzi multicast specifici della sorgente e specifica le politiche che ne regolano l'uso. In particolare, definisce un'estensione al servizio di rete Internet che si applica ai datagrammi inviati agli indirizzi SSM e definisce le estensioni dell'host per supportare il servizio di rete. Host, router, applicazioni e protocolli che utilizzano questi indirizzi DEVONO (MUST) conformarsi alle politiche delineate in questo documento. La mancata conformità di un host può impedire a tale host o ad altri host sulla stessa LAN di ricevere traffico inviato a un canale SSM. La mancata conformità di un router può causare la consegna del traffico SSM a parti della rete in cui è indesiderato, gravando inutilmente sulla rete.