5. Per-Hop Behavior Standardization Guidelines (Linee guida per la standardizzazione dei comportamenti per-hop)

Le caratteristiche comportamentali (behavioral characteristics) dei PHB dovrebbero essere standardizzate, non gli algoritmi o meccanismi specifici utilizzati per implementarli. Un nodo può avere un insieme (possibilmente grande) di parametri che possono essere utilizzati per controllare come i pacchetti vengono schedulati sulle interfacce di uscita (ad esempio, N code separate con priorità configurabili, lunghezze di coda, pesi round-robin, algoritmi di scarto, pesi e soglie di priorità di scarto). Per illustrare la differenza tra PHB e meccanismi, sottolineiamo che un PHB conforme al selettore di classe può essere implementato da diversi meccanismi, da soli o in combinazione, incluso l'accodamento prioritario rigoroso, WFQ, WRR o varianti [HPFQA, RPS, DRR], o CBQ [CBQ].

I PHB possono essere specificati individualmente o in gruppo (group). Un gruppo PHB è tipicamente composto da un insieme di due o più PHB che possono essere specificati e implementati in modo significativo solo simultaneamente, a causa di un vincolo comune (common constraint) applicabile a ciascun PHB nel gruppo, come il servizio di coda o la politica di gestione della coda. Una specifica di gruppo PHB dovrebbe (SHOULD) descrivere le condizioni in cui un pacchetto può essere ri-marcato per selezionare un altro PHB all'interno del gruppo. È raccomandato (RECOMMENDED) che le implementazioni PHB non introducano il riordino dei pacchetti all'interno di un microflusso (microflow). Le specifiche di gruppo PHB devono (MUST) identificare le implicazioni di riordino dei pacchetti (packet re-ordering implications) che possono verificarsi per ogni singolo PHB, e quelle che possono verificarsi se pacchetti diversi all'interno di un microflusso sono marcati per PHB diversi all'interno del gruppo.

Solo i comportamenti per-hop che non sono descritti dagli standard PHB esistenti e che sono stati implementati, deployati e dimostrati utili dovrebbero (SHOULD) essere standardizzati. Dato che l'esperienza corrente con i servizi differenziati è piuttosto limitata, sarebbe prematuro assumere specifiche precise per questi comportamenti per-hop.

Ogni PHB standardizzato deve (MUST) avere un codepoint raccomandato (RECOMMENDED) associato ad esso, assegnato dallo spazio di 32 codepoint (vedere Sezione 6). Lo spazio dei codepoint è intenzionalmente sparso (intentionally sparse) nello spazio definito ('xxx000'), poiché questa specifica lascia spazio nello spazio dei codepoint per l'evoluzione.

I fornitori di apparecchiature di rete sono liberi di fornire i parametri e le funzionalità che ritengono utili o commerciabili. Se un particolare PHB standardizzato è implementato in un nodo, il fornitore può (MAY) utilizzare qualsiasi algoritmo che soddisfi la definizione del PHB secondo lo standard. Le capacità di un nodo e la sua particolare configurazione determinano i vari modi in cui può gestire i pacchetti.

I fornitori di servizi non devono utilizzare gli stessi meccanismi o configurazioni di nodo per consentire la differenziazione del servizio nella loro rete, e sono liberi di configurare i parametri del nodo in modo appropriato ai loro obiettivi di fornitura del servizio e ingegneria del traffico. Nel tempo, possono evolvere particolari comportamenti per-hop comuni (cioè quelli particolarmente utili per implementare servizi end-to-end) e questi possono (MAY) essere associati a particolari codepoint PHB EXP/LU del campo DS per l'uso attraverso i confini di dominio (vedere Sezione 6). Questi PHB sono candidati per la standardizzazione futura.

È raccomandato (RECOMMENDED) che i PHB standardizzati siano specificati secondo le linee guida presentate in [ARCH].