5. Linee guida per la standardizzazione dei comportamenti per hop (Per-Hop Behavior Standardization Guidelines)
Le caratteristiche comportamentali di un PHB devono essere standardizzate, e non i particolari algoritmi o i meccanismi utilizzati per implementarli. Un nodo può avere un insieme (possibilmente grande) di parametri che possono essere utilizzati per controllare come i pacchetti vengono pianificati su un'interfaccia di output (ad esempio, N code separate con priorità impostabili, lunghezze di coda, pesi round-robin, algoritmo di scarto, pesi e soglie di preferenza di scarto, ecc.). Per illustrare la distinzione tra un PHB e un meccanismo, sottolineiamo che i PHB conformi al selettore di classe potrebbero essere implementati da diversi meccanismi, inclusi: accodamento a priorità rigorosa, WFQ, WRR o varianti [HPFQA, RPS, DRR], o CBQ [CBQ], isolatamente o in combinazione.
I PHB possono essere specificati individualmente o come gruppo (un singolo PHB è un caso speciale di un gruppo PHB). Un gruppo PHB di solito consiste in un insieme di due o più PHB che possono essere specificati e implementati in modo significativo solo simultaneamente, a causa di un vincolo comune applicabile a ciascun PHB all'interno del gruppo, come una politica di servizio di coda o di gestione della coda. Una specifica di gruppo PHB dovrebbe (SHOULD) descrivere le condizioni in cui un pacchetto potrebbe essere ricontrassegnato per selezionare un altro PHB all'interno del gruppo. È raccomandato (RECOMMENDED) che le implementazioni PHB non introducano alcun riordinamento di pacchetti all'interno di un microflusso. Le specifiche di gruppo PHB devono (MUST) identificare eventuali possibili implicazioni di riordinamento dei pacchetti che possono verificarsi per ciascun PHB individuale, e che possono verificarsi se pacchetti diversi all'interno di un microflusso sono contrassegnati per PHB diversi all'interno del gruppo.
Solo quei comportamenti per hop che non sono descritti da uno standard PHB esistente, che sono stati implementati, distribuiti e si sono dimostrati utili, dovrebbero (SHOULD) essere standardizzati. Poiché l'esperienza attuale con i servizi differenziati è piuttosto limitata, è prematuro ipotizzare la specifica esatta di questi comportamenti per hop.
Ogni PHB standardizzato deve (MUST) avere un codepoint raccomandato (RECOMMENDED) associato, allocato da uno spazio di 32 codepoint (vedi Sez. 6). Questa specifica ha lasciato spazio nello spazio dei codepoint per consentire l'evoluzione, quindi lo spazio definito (xxx000) è intenzionalmente sparso.
I fornitori di apparecchiature di rete sono liberi di offrire qualsiasi parametro e capacità ritenuti utili o commerciabili. Quando un particolare PHB standardizzato è implementato in un nodo, un fornitore può (MAY) utilizzare qualsiasi algoritmo che soddisfi la definizione del PHB secondo lo standard. Le capacità del nodo e la sua particolare configurazione determinano i diversi modi in cui i pacchetti possono essere trattati.
I fornitori di servizi non sono tenuti a utilizzare gli stessi meccanismi o configurazioni di nodo per abilitare la differenziazione del servizio all'interno delle loro reti e sono liberi di configurare i parametri del nodo in qualsiasi modo appropriato per le loro offerte di servizio e gli obiettivi di ingegneria del traffico. Nel tempo, è probabile che evolvano certi 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 nel campo DS, consentendo l'uso oltre i confini del dominio (vedi Sez. 6). Questi PHB sono candidati per la standardizzazione futura.
È raccomandato (RECOMMENDED) che i PHB standardizzati siano specificati in conformità con le linee guida stabilite in [ARCH].