Prima che il cliente esista: che cosa collauda davvero la ITU-T Y.1564

Un capitolato per una rete d’impresa scrive spesso: collaudo secondo la ITU-T Y.1564. Sembra chiudere la questione. Non la chiude quasi mai: la Y.1564 dichiara da sé, nella prima clausola, che cosa misura e quando — prima che il cliente esista. Chi firma quella riga compra la fotografia di un circuito vuoto, scattata il giorno dell’attivazione, non un film del servizio in esercizio.

Che cosa dice la clausola 1, e che cosa non copre

Lo Scope della Raccomandazione, è verbatim: «This Recommendation defines an out-of-service test methodology to assess the proper configuration and performance of an Ethernet service prior to customer notification and delivery.» — fuori servizio, e prima della notifica al cliente e della consegna. È la prima frase del documento: la definizione stessa dell’oggetto. Il collaudo verifica che il circuito sia configurato bene e si comporti bene quel giorno, su traffico generato dallo strumento di prova — non su quello del cliente, che ancora non esiste.

Le due fasi, e il limite che la norma dichiara da sola

Il metodo, alla clausola 8, ha due fasi. Il service configuration test (8.1) verifica che ogni servizio sia configurato come previsto: «Each service MUST be tested individually.» Per ogni gradino di carico fino al CIR, «the IR, FTD, FDV and FLR MUST be measured simultaneously» — tasso d’informazione, ritardo, variazione del ritardo e perdita di trama, tutti insieme. Il limite è nello stesso paragrafo: «As the performance limits are only used for service acceptance when Ethernet traffic is below or equal to the CIR (green traffic), the performance parameters will not be judged against the limits above the CIR.» Sopra il CIR, la Y.1564 osserva ma non giudica.

Il service performance test (8.2) segue, «conducted to validate the quality of the Ethernet services over a medium to long time duration» — su una finestra più lunga.

Quale durata ha comprato il capitolato

La durata, alla clausola 8.2.1, rimanda alla ITU-T M.2110: «The following test periods MUST be supported», e sono tre: Tperiod di 15 minuti, di 2 ore, di 24 ore. Quale delle tre si applichi, però, non è imposto — «The applicable test duration SHOULD therefore be Test15m, Test2h or Test24h» — e la corrispondenza con la topologia è data espressamente come esempio, al permissivo: «For example, an operator MAY test services for 15 minutes if the services are provided over a network already carrying working traffic in a metro application»; due ore «MAY be used for services running over a single operator long-haul network»; ventiquattr’ore «MAY be used for services which are being carried internationally over multiple operator networks». Vincolante resta solo la trasparenza: «All test durations MUST be clearly identified in the test report.» Un capitolato che scrive collaudo secondo Y.1564 senza dire quale Tperiod vuole lascia la scelta al fornitore: quindici minuti restano ammessi anche sul servizio internazionale per cui il testo ne suggerisce ventiquattro. Proprio perché è un esempio e non una regola, la durata deve scriverla il committente.

Il buco che la norma dichiara, non nasconde

Dopo i test su EIR e policing, la Y.1564 prevede una verifica facoltativa sulle raffiche — dimensione garantita (CBS) ed eccedente (EBS) — e la lascia esplicitamente indefinita: «an optional burst size configuration test MAY be executed» […] «A normative methodology is for further study.» È dichiarata, non nascosta. Chi mette in capitolato verifica di CBS ed EBS secondo Y.1564 chiede una prova per cui la raccomandazione non fornisce un metodo — e deve scriverselo da sé.

Il corrigendum che promette una ragione, e ne cambia una riga

Ho scaricato ed estratto entrambi i testi — Y.1564 (02/2016) e Corrigendum 1 (06/2021) — confrontandoli parola per parola. Il Corrigendum si dichiara da solo una ripubblicazione integrale: «This is a complete-text publication. Modifications introduced by this corrigendum are shown in revision marks relative to Recommendation ITU-T Y.1564 (2016).» Il Summary iniziale dà la ragione: «Corrigendum 1 introduces changes related to the withdrawal of IEEE 802.1D.»

Ma la modifica sostanziale è una sola: alla clausola 2 (References), il riferimento normativo a IEEE 802.1Q passa da «IEEE 802.1Q-2003, IEEE Standards for Local and Metropolitan Area Networks – Virtual Bridged Local Area Networks» a «IEEE 802.1Q-201803, IEEE Standards for Local and Metropolitan Area Networks – Virtual Bridges and Bridged Local Area Networks». Nient’altro, nel corpo normativo, cambia sostanza.

La Bibliografia in fondo al documento — voci marcate dal prefisso b-, lo stesso con cui la clausola 1 rimanda a [b-IETF RFC 2544], assente dai riferimenti normativi di clausola 2 — resta identica in entrambe le edizioni: elenca ancora IEEE 802.1D-2004 (tag [b-IEEE 802.1D], la norma il cui ritiro è la ragione dichiarata del corrigendum) e IEEE 802.1Q-2010 (tag [b-IEEE 802.1Q]) — una terza edizione, quando la clausola 2, poche pagine prima, ne cita già una diversa: la 201803. Non è un errore: per struttura del documento la Bibliografia è materiale di contesto, non vincolante come la clausola 2. Ma un documento conforme alla Y.1564 richiama tre edizioni IEEE in due sezioni con status diverso: solo quella di clausola 2 vincola.

Che cosa resta scoperto dopo la consegna

Siccome la Y.1564 è per definizione fuori servizio, un capitolato che si ferma lì non dice nulla sul servizio in esercizio. Restano tre riferimenti liberi, già normativi dentro la Y.1564: la ITU-T Y.1563 (2009), Ethernet frame transfer and availability performance — in vigore, con Emendamento 1 (2009) e Corrigendum 1 (06/2021, la stessa tornata) — per i parametri d’esercizio; la Y.1731 per le funzioni OAM in servizio; la M.2110 (2002), già citata, per la messa in servizio. Un avviso sulla seconda: l’edizione che la Y.1564 cita, Y.1731 (02/2008), è oggi superseded. L’edizione in vigore è la G.8013/Y.1731 (06/2023), con Corrigendum 1 (01/2024) e Amendment 1 (05/2025): anche il rimando che la Y.1564 offre va riverificato all’origine, non copiato dal 2016.

Cosa scrivere in capitolato

Il Tperiod, scritto per nome — 15 minuti, 2 ore o 24 ore — con la topologia del percorso che lo giustifica.
Il perimetro dei limiti: solo fino al CIR (traffico verde); sopra, la Y.1564 osserva e non giudica.
Se si vuole un test su CBS/EBS, il metodo lo scrive il committente: la norma lo lascia indefinito.
L’edizione: Y.1564 (02/2016) più Corrigendum 1 (06/2021), e quale IEEE 802.1Q vincola — quella di clausola 2, non quella di bibliografia.
Per l’esercizio, un riferimento separato: Y.1563 per i parametri, Y.1731 nell’edizione oggi in vigore per l’OAM — verificate sulla pagina di stato ITU, non copiate dal 2016.

Vedi il servizio · Parlane con un tecnico

Il verbale del collaudo e i riferimenti che richiama — Y.1563, Y.1731, M.2110, le tre edizioni IEEE che attraversano il testo — diventano, con CSIDIA, l’altra società del gruppo, una mappa unica su cui un’AI verifica, prima della firma, quale Tperiod è scritto, se i limiti restano sotto il CIR e se l’edizione richiamata è ancora quella in vigore. Nel perimetro del cliente: on-premise su macchine autonome, oppure cloud dedicato con data center in Italia, sempre con gestione condivisa.

Il vostro capitolato cita la Y.1564 e si ferma lì? Parlatene con un tecnico: la revisione, senza costi, elenca la durata, il limite e l’edizione che di norma restano non scritti.

Quello che non possiamo leggere

La IEEE 802.1Q e la IEEE 802.1D non sono liberamente accessibili: ne citiamo solo numero, anno e titolo, come compaiono nei riferimenti della Y.1564 — non il contenuto, a pagamento nel catalogo IEEE. Non abbiamo verificato se la 802.1Q-201803 sia oggi l’edizione più recente disponibile: sappiamo solo che è quella richiamata dal Corrigendum 1. E non affermiamo un legame causale fra il ritiro della 802.1D e un cambiamento tecnico nella Y.1564: il Summary dichiara la ragione, il testo mostra solo la riga cambiata — non perché quella riga, e non altre, dovesse cambiare.