2. Livello di collegamento (LINK LAYER)

2.1 Introduzione (INTRODUCTION)

Tutti i sistemi Internet, siano essi host o gateway, hanno gli stessi requisiti per i protocolli di livello di collegamento. Questi requisiti sono forniti nel capitolo 3 di "Requisiti per i gateway Internet" [INTRO:2] e vengono integrati da questa sezione.

2.2 Analisi del protocollo (PROTOCOL WALK-THROUGH)

Nessuna (None).

2.3 Problemi specifici (SPECIFIC ISSUES)

2.3.1 Negoziazione del protocollo Trailer (Trailer Protocol Negotiation)

Il protocollo Trailer dell'incapsulamento di livello di collegamento [LINK:1] PUÒ (MAY) essere utilizzato, ma solo se è stato verificato che entrambi i sistemi (host o gateway) che partecipano alla comunicazione di livello di collegamento implementano il trailer. Se il sistema non negozia dinamicamente l'uso del protocollo Trailer su base per indirizzo di destinazione, la configurazione predefinita DEVEREBBE (MUST) disabilitare il protocollo.

DISCUSSION (Discussione):

Il protocollo Trailer è una tecnica di incapsulamento di livello di collegamento che riordina il contenuto dati dei pacchetti inviati sulla rete fisica. In alcuni casi, il trailer migliora la velocità effettiva dei protocolli di livello superiore riducendo la quantità di copia dei dati all'interno del sistema operativo. I protocolli di livello superiore non sono a conoscenza dell'uso del trailer, ma se il protocollo viene utilizzato, sia l'host mittente che quello ricevente devono (MUST) comprendere il protocollo.

Un uso improprio dei trailer causa sintomi molto confusi. Solo i pacchetti con alcune proprietà di dimensione utilizzano l'incapsulamento trailer, e generalmente solo una piccola frazione dei pacchetti scambiati ha tali proprietà. Pertanto, se un sistema che utilizza i trailer scambia pacchetti con un sistema che non li utilizza, alcuni pacchetti scompaiono in un buco nero, mentre altri vengono consegnati con successo.

IMPLEMENTATION (Implementazione):

Su Ethernet, i pacchetti incapsulati con trailer utilizzano un tipo Ethernet diverso [LINK:1], e la negoziazione trailer viene eseguita quando si scopre l'indirizzo di collegamento del sistema di destinazione utilizzando ARP.

Più precisamente, lo scambio ARP viene eseguito nel modo consueto utilizzando il tipo di protocollo IP normale, ma l'host che desidera utilizzare i trailer invia una "risposta ARP trailer (trailer ARP reply)" aggiuntiva, ovvero una risposta ARP che specifica il tipo di protocollo di incapsulamento trailer ma che è altrimenti nel formato di una normale risposta ARP. Se un host configurato per utilizzare i trailer riceve un messaggio di risposta ARP trailer da una macchina remota, può aggiungere tale macchina all'elenco delle macchine che comprendono i trailer, ad esempio marcando la voce corrispondente nella cache ARP.

L'host che desidera ricevere pacchetti incapsulati trailer invia una risposta ARP trailer ogni volta che completa uno scambio di messaggi ARP IP normale. Pertanto, un host che riceve una richiesta ARP per il proprio indirizzo di protocollo IP invia una risposta ARP trailer oltre alla normale risposta ARP IP; l'host che ha inviato una richiesta ARP IP invia una risposta ARP trailer al ricevimento della corrispondente risposta ARP IP. In questo modo, sia l'host richiedente che l'host rispondente dello scambio ARP IP possono richiedere la ricezione dell'incapsulamento trailer.

Questo schema utilizza messaggi di risposta ARP trailer aggiuntivi invece di inviare una richiesta ARP per il tipo di protocollo trailer, allo scopo di evitare lo scambio continuo di pacchetti ARP con un host che si comporta in modo contrario a qualsiasi specifica o buon senso (behaving contrary to any specification or common sense) e che risponderebbe a una risposta ARP trailer con un'altra risposta ARP IP. Questo problema viene evitato inviando una risposta ARP trailer solo al ricevimento di una risposta ARP IP in risposta a una richiesta in sospeso; ciò si verifica quando l'indirizzo hardware dell'host è ancora sconosciuto al ricevimento della risposta ARP IP. La risposta ARP trailer può sempre essere inviata insieme alla risposta ARP IP che risponde a una richiesta ARP IP.

2.3.2 Address Resolution Protocol -- ARP (Address Resolution Protocol -- ARP)

2.3.2.1 Validazione della cache ARP (ARP Cache Validation)

L'implementazione dell'Address Resolution Protocol (ARP) [LINK:2] DEVEREBBE (MUST) fornire un meccanismo per cancellare le voci di cache obsolete. Se tale meccanismo comporta un timeout, il valore di timeout DOVREBBE (SHOULD) essere configurabile.

DEVEREBBE (MUST) essere incluso un meccanismo per prevenire l'inondazione ARP (invio ripetuto di richieste ARP a alta velocità per lo stesso indirizzo IP). La velocità massima raccomandata per indirizzo di destinazione è 1 al secondo.

DISCUSSION (Discussione):

La specifica ARP [LINK:2] suggerisce ma non richiede un meccanismo di timeout per invalidare le voci di cache quando un host cambia il proprio indirizzo Ethernet. L'onnipresenza del proxy ARP (vedere sezione 2.4 di [INTRO:2]) aumenta in modo significativo la probabilità che le voci di cache su un host diventino non valide, quindi ora sui host è necessario un meccanismo di invalidazione della cache ARP. Anche senza proxy ARP, un lungo ciclo di timeout della cache è utile per correggere automaticamente eventuali dati ARP errati che potrebbero essere stati memorizzati nella cache.

IMPLEMENTATION (Implementazione):

Sono stati utilizzati quattro meccanismi, a volte in combinazione, per cancellare le voci di cache obsolete.

(1) Timeout —— fa scadere periodicamente le voci di cache, anche se vengono utilizzate. Notare che quando una voce di cache viene "aggiornata (refreshed)" (osservando il campo sorgente delle trasmissioni ARP dei sistemi interessati, indipendentemente dall'indirizzo di destinazione), tale timeout dovrebbe essere riavviato. Per il caso proxy ARP, il timeout deve essere dell'ordine di un minuto.

(2) Polling unicast (Unicast Poll) —— sonde attivamente l'host remoto inviando una richiesta ARP point-to-point e elimina la voce se non viene ricevuta alcuna risposta ARP in N sonde consecutive. Allo stesso modo, il timeout deve essere dell'ordine di un minuto e generalmente N è 2.

(3) Consiglio del livello di collegamento (Link-Layer Advice) —— se il driver del livello di collegamento rileva un problema di consegna, cancella la voce di cache ARP corrispondente.

(4) Consiglio del livello superiore (Higher-layer Advice) —— fornisce una chiamata dal livello Internet al livello di collegamento per indicare un problema di consegna. L'effetto di questa chiamata è invalidare la voce di cache corrispondente. Questa chiamata è simile alla chiamata "ADVISE_DELIVPROB()" dal livello di trasporto al livello Internet (vedere sezione 3.4), e in effetti la routine ADVISE_DELIVPROB può a sua volta chiamare la routine di consiglio del livello di collegamento per invalidare la voce di cache ARP.

I metodi (1) e (2) comportano un timeout della cache ARP di circa un minuto o meno. Senza proxy ARP, un timeout così breve può generare un traffico di sovraccarico significativo su Ethernet molto grandi. Pertanto, potrebbe essere necessario configurare l'host per estendere il timeout della cache ARP.

2.3.2.2 Coda dei pacchetti ARP (ARP Packet Queue)

Il livello di collegamento DOVREBBE (SHOULD) salvare (anziché scartare) almeno uno (il più recente) dei pacchetti di ciascun gruppo inviato allo stesso indirizzo IP non risolto e trasmettere il pacchetto salvato una volta risolta l'indirizzo.

DISCUSSION (Discussione):

Il mancato rispetto di questo consiglio comporta la perdita del primo pacchetto di ogni scambio. Sebbene i protocolli di livello superiore possano generalmente far fronte alla perdita di pacchetti tramite ritrasmissione, la perdita di pacchetti influisce sulle prestazioni. Ad esempio, la perdita di una richiesta di apertura TCP esagera la stima del tempo di andata e ritorno iniziale. Le applicazioni basate su UDP (come il sistema dei nomi di dominio) sono più gravemente colpite.

2.3.3 Incapsulamento Ethernet e IEEE 802 (Ethernet and IEEE 802 Encapsulation)

L'incapsulamento IP su Ethernet è descritto in RFC-894 [LINK:3] e RFC-1042 [LINK:4] descrive l'incapsulamento IP sulle reti IEEE 802. RFC-1042 dettaglia e sostituisce la discussione della sezione 3.4 di [INTRO:2].

Ogni host Internet collegato a un cavo Ethernet 10Mbps:

• DEVEREBBE (MUST) essere in grado di inviare e ricevere pacchetti utilizzando l'incapsulamento RFC-894;
• DOVREBBE (SHOULD) essere in grado di ricevere pacchetti RFC-1042, mescolandoli con pacchetti RFC-894; e
• PUÒ (MAY) essere in grado di inviare pacchetti utilizzando l'incapsulamento RFC-1042.

Un host Internet che implementa l'invio di entrambi gli incapsulamenti RFC-894 e RFC-1042 DEVEREBBE (MUST) fornire un interruttore di configurazione per selezionare quale inviare e tale interruttore DEVEREBBE (MUST) avere RFC-894 come predefinito.

Si noti che l'incapsulamento IP standard di RFC-1042 non utilizza il valore di identificatore di protocollo IEEE riservato a IP (K1=6); invece, utilizza un valore (K1=170) che implica un'estensione ("SNAP") in grado di contenere il campo Ether-Type. I sistemi Internet NON DEVONO (MUST NOT) inviare pacchetti 802 che utilizzano K1=6.

La traduzione da indirizzi Internet a indirizzi di livello di collegamento sulle reti Ethernet e IEEE 802 DEVEREBBE (MUST) essere gestita dal protocollo di risoluzione degli indirizzi (ARP).

L'MTU di Ethernet è 1500 e l'MTU di 802.3 è 1492.

DISCUSSION (Discussione):

La specifica IEEE 802.3 prevede il funzionamento su un cavo Ethernet 10Mbps, nel qual caso i frame Ethernet e 802.3 possono essere fisicamente mescolati. Il ricevitore può distinguere i frame Ethernet e 802.3 dal valore del campo di lunghezza 802.3; questo campo di due byte si trova nell'intestazione nella stessa posizione del campo Ether-Type dei frame Ethernet. In particolare, il campo di lunghezza 802.3 deve essere minore o uguale a 1500, mentre tutti i valori Ether-Type validi sono maggiori di 1500.

Un altro problema di compatibilità sorge con la trasmissione di livello di collegamento. Una trasmissione inviata in un formato di frame non viene vista dagli host in grado di ricevere solo l'altro formato di frame.

Le disposizioni di questa sezione mirano, per quanto possibile, a consentire l'interoperabilità diretta sullo stesso cavo tra sistemi che supportano 894 e sistemi che supportano 1042. L'obiettivo è supportare la situazione attuale dominata dai sistemi solo 894, fornendo al contempo una transizione agevole verso un futuro in cui i sistemi 1042 potrebbero diventare comuni.

Si noti che un sistema solo 894 non può interoperare direttamente con un sistema solo 1042. Se questi due tipi di sistemi sono configurati come due reti logiche diverse sullo stesso cavo, possono comunicare solo tramite un gateway IP. Inoltre, a causa del problema della trasmissione di livello di collegamento, è inutile e impossibile per un host a doppio formato rilevare automaticamente quale formato inviare.

2.4 Interfaccia collegamento/Internet (LINK/INTERNET LAYER INTERFACE)

L'interfaccia di ricezione pacchetti tra il livello IP e il livello di collegamento DEVEREBBE (MUST) includere un flag che indica se il pacchetto in arrivo è indirizzato a un indirizzo di trasmissione di livello di collegamento.

DISCUSSION (Discussione):

Sebbene il livello IP in genere non conosca gli indirizzi di livello di collegamento (poiché ciascun diverso mezzo di rete ha in genere un formato di indirizzo diverso), l'indirizzo di trasmissione su un mezzo con capacità di trasmissione è un caso particolare importante. Vedere la sezione 2.4, in particolare la discussione sulle tempeste di trasmissione.

L'interfaccia di invio pacchetti tra IP e il livello di collegamento DEVEREBBE (MUST) includere il campo TOS di 5 bit (vedere sezione 3.2.1.6).

Il livello di collegamento NON DEVE (MUST NOT) segnalare a IP un errore "Destinazione irraggiungibile (Destination Unreachable)" solo perché non esiste alcuna voce di cache ARP per un indirizzo di destinazione.

2.5 Riepilogo dei requisiti del livello di collegamento (LINK LAYER REQUIREMENTS SUMMARY)

Caratteristica (Feature)	Sezione	MUST	SHOULD	MAY	SHOULD NOT	MUST NOT
Incapsulamento Trailer (Trailer encapsulation)	2.3.1			x
Inviare Trailer per impostazione predefinita senza negoziazione (Send Trailers by default without negotiation)	2.3.1					x
ARP	2.3.2
Cancella voci di cache ARP obsolete (Flush out-of-date ARP cache entries)	2.3.2.1	x
Impedisci inondazioni ARP (Prevent ARP floods)	2.3.2.1	x
Timeout cache configurabile (Cache timeout configurable)	2.3.2.1		x
Salva almeno uno (il più recente) pacchetto non risolto (Save at least one (latest) unresolved pkt)	2.3.2.2		x
Incapsulamento Ethernet e IEEE 802 (Ethernet and IEEE 802 Encapsulation)	2.3.3
Host in grado di: (Host able to:)	2.3.3
- Inviare e ricevere incapsulamento RFC-894 (- Send & receive RFC-894 encapsulation)	2.3.3	x
- Ricevere incapsulamento RFC-1042 (- Receive RFC-1042 encapsulation)	2.3.3		x
- Inviare incapsulamento RFC-1042 (- Send RFC-1042 encapsulation)	2.3.3			x
Interruttore di configurazione per selezionare, predefinito RFC-894 (Then config. sw. to select, RFC-894 dflt)	2.3.3	x
Inviare incapsulamento K1=6 (Send K1=6 encapsulation)	2.3.3					x
Usa ARP su reti Ethernet e IEEE 802 (Use ARP on Ethernet and IEEE 802 nets)	2.3.3	x
Interfaccia collegamento/Internet (Link/Internet Layer Interface)	2.4
Il livello collegamento segnala le trasmissioni al livello IP (Link layer report b'casts to IP layer)	2.4	x
Il livello IP passa il TOS al livello collegamento (IP layer pass TOS to link layer)	2.4	x
Voce di cache ARP assente trattata come Dest. Irraggiungibile (No ARP cache entry treated as Dest. Unreach.)	2.4					x

---

Riferimenti (References):

• [LINK:1] Leffler, S., and M. Karels, "Trailer Encapsulations", RFC-893, Univ. of California at Berkeley, April 1984.
• [LINK:2] Plummer, D., "An Ethernet Address Resolution Protocol", RFC-826, November 1982.
• [LINK:3] Hornig, C., "A Standard for the Transmission of IP Datagrams over Ethernet Networks", RFC-894, April 1984.
• [LINK:4] Postel, J., and J. Reynolds, "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC-1042, February 1988.