Request an intervention

Operational notes Testing

Before the customer exists: what ITU-T Y.1564 actually tests

7 min read

Black and white photograph of a running track shot low from ground level, white painted lane markings running in perspective toward the background, grainy surface in the foreground, a pale drainage kerb, a strip of grass on the right
The lanes are measured and painted before anyone runs on them. That is the same condition as Y.1564: out of service, before the customer exists.

An enterprise network specification often carries a line like this: tested to ITU-T Y.1564. It looks like the matter is settled. It settles almost nothing. Y.1564 states, in its own first clause, exactly what it measures and when — before the customer exists. Whoever signs that line is buying a photograph of an empty circuit, taken on activation day, not a film of the service running in production.

What clause 1 says, and what it doesn’t cover

The Recommendation’s Scope reads 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.” Out of service, and before notifying and delivering to the customer. It is the document’s opening sentence: the definition of the object itself. The test confirms the circuit is configured correctly and behaves correctly that day, on traffic generated by the test instrument — not on the customer’s, which does not yet exist.

Two phases, and the limit the standard states on its own

The method, in clause 8, has two phases. The service configuration test (8.1) confirms each service is configured as intended: “Each service MUST be tested individually.” For each load step up to the CIR, “the IR, FTD, FDV and FLR MUST be measured simultaneously” — information rate, delay, delay variation and frame loss, all at once. The limit is in the same paragraph: “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.” Above the CIR, Y.1564 observes but does not judge.

The service performance test (8.2) follows, “conducted to validate the quality of the Ethernet services over a medium to long time duration” — over a longer window.

Which duration did the specification actually buy

Duration, in clause 8.2.1, points to ITU-T M.2110: “The following test periods MUST be supported”, and there are three: Tperiod of 15 minutes, of 2 hours, of 24 hours. Which of the three applies is not imposed — “The applicable test duration SHOULD therefore be Test15m, Test2h or Test24h” — and the mapping to topology is given expressly as an example, in the permissive: “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”; two hours “MAY be used for services running over a single operator long-haul network”; twenty-four hours “MAY be used for services which are being carried internationally over multiple operator networks.” Only transparency binds: “All test durations MUST be clearly identified in the test report.” A specification that writes tested to Y.1564 without stating which Tperiod it wants leaves the choice to the supplier: fifteen minutes stay admissible even on the international service for which the text suggests twenty-four. Precisely because it is an example and not a rule, the buyer must write the duration.

The gap the standard states, rather than hides

After the EIR and traffic-policing tests, Y.1564 provides for an optional test on bursts — committed size (CBS) and excess size (EBS) — and leaves it explicitly undefined: “an optional burst size configuration test MAY be executed” […] “A normative methodology is for further study.” It is stated, not hidden. Anyone who writes CBS/EBS verified to Y.1564 into a specification is asking for a test the recommendation provides no method for — and has to write that method themselves.

The corrigendum that promises a reason, and changes one line

We downloaded and extracted both texts — Y.1564 (02/2016) and Corrigendum 1 (06/2021) — and compared them word for word. The Corrigendum states, of itself, that it is a full republication: “This is a complete-text publication. Modifications introduced by this corrigendum are shown in revision marks relative to Recommendation ITU-T Y.1564 (2016).” Its opening Summary gives the reason: “Corrigendum 1 introduces changes related to the withdrawal of IEEE 802.1D.”

But the one substantive change in the body of the text is exactly that: one line. In clause 2 (References), the normative reference to IEEE 802.1Q moves from “IEEE 802.1Q-2003, IEEE Standards for Local and Metropolitan Area Networks – Virtual Bridged Local Area Networks” to “IEEE 802.1Q-201803, IEEE Standards for Local and Metropolitan Area Networks – Virtual Bridges and Bridged Local Area Networks.” Nothing else, in the normative body, changes substance.

The Bibliography at the back of the document — entries tagged with the b- prefix, the same one clause 1 uses for [b-IETF RFC 2544], absent from the normative references in clause 2 — stays identical across both editions: it still lists IEEE 802.1D-2004 (tag [b-IEEE 802.1D], the very standard whose withdrawal is the corrigendum’s stated reason) and IEEE 802.1Q-2010 (tag [b-IEEE 802.1Q]) — a third edition, when clause 2, a few pages earlier, already cites a different one: 201803. That’s not an error: by the document’s own structure, the Bibliography is contextual material, not binding the way clause 2 is. But a document tested to Y.1564 can cite three different IEEE editions across two sections carrying different status — only the one in clause 2 actually binds.

What stays uncovered after delivery

Because Y.1564 is out of service by definition, a specification that stops there says nothing about the service once it’s running. Three free references remain, already cited as normative inside Y.1564 itself: ITU-T Y.1563 (2009), Ethernet frame transfer and availability performance — in force, with Amendment 1 (2009) and Corrigendum 1 (06/2021, the same round) — for in-service parameters; Y.1731 for in-service OAM functions; M.2110 (2002), already cited for durations, for bringing into service. One warning on the second: the edition Y.1564 itself cites, Y.1731 (02/2008), now shows as superseded on the official ITU page. The edition in force is G.8013/Y.1731 (06/2023), with Corrigendum 1 (01/2024) and Amendment 1 (05/2025) — even the pointer Y.1564 hands you has to be re-checked at the source, not copied from 2016.

What to write into the specification

  1. The Tperiod, named explicitly — 15 minutes, 2 hours or 24 hours — justified by the path’s topology.
  2. The scope of the limits: only up to the CIR (green traffic); above it, Y.1564 observes and does not judge.
  3. If a CBS/EBS test is wanted, the customer has to write the method: the standard leaves it undefined.
  4. The edition: Y.1564 (02/2016) plus Corrigendum 1 (06/2021), and which IEEE 802.1Q binds — the one in clause 2, not the one in the bibliography.
  5. For in-service monitoring, a separate reference: Y.1563 for parameters, Y.1731 in whichever edition is currently in force for OAM — checked on the ITU status page, not copied from 2016.

See the service · Talk to an engineer

The test record and the references it invokes — Y.1563, Y.1731, M.2110, the three IEEE editions running through the text — become, with CSIDIA, the group’s other company, a single map on which an AI checks, before sign-off, which Tperiod is written down, whether the stated limits stay under the CIR, and whether the cited edition is still the one in force. Within the client’s own perimeter: on-premises on autonomous machines, or dedicated cloud with a data centre in Italy, always with shared management.

Does your specification cite Y.1564 and stop there? Talk to an engineer: the review, at no cost, lists the duration, the limit and the edition that usually go unwritten.

What we can’t read

IEEE 802.1Q and IEEE 802.1D aren’t freely accessible: we cite only number, year and title, exactly as they appear in Y.1564’s references — not the content, which sits behind IEEE’s paywalled catalogue. We haven’t checked whether 802.1Q-201803 is itself the latest edition available today: we only know it’s the one Corrigendum 1 cites. And we don’t claim a causal link between the 802.1D withdrawal and a specific technical change in Y.1564: the Summary states the reason, the text shows only the one line that changed — not why that line, and no other, had to change.

Sources