If you are about to accept a leased line from a carrier, you will almost certainly run into two names: RFC 2544 and Y.1564. Both measure Ethernet performance, but they answer different questions. Pick the wrong one and you can sign off on a circuit whose SLA was never really verified. Our team has watched this happen more than once, and in our experience the root cause is almost always the method, not the equipment.
The short version: RFC 2544 tests the device, Y.1564 tests the service
RFC 2544 is a benchmarking methodology for network devices and point-to-point links. It is usually run in a lab, where you control the traffic and the environment. Y.1564 is an ITU-T standard built for a different job. It checks an entire Ethernet service end to end against its SLA, looking at bandwidth, delay, jitter and frame loss for each service individually.
The rule of thumb we give new engineers is simple. Use RFC 2544 to qualify the hardware, and use Y.1564 to accept the carrier’s circuit. Most acceptance disputes start when someone blurs those two roles together.
What each methodology actually measures
RFC 2544, published in 1999, focuses on four core metrics: throughput, latency, frame loss rate, and back-to-back burst capacity. Put plainly, it asks how fast your device can forward traffic before it starts dropping frames. Everything runs on a single traffic flow, which keeps the setup clean but also limits what it can tell you about a real service.
Y.1564 is more involved, and it has two phases. The first is the service configuration test. Here the CIR (Committed Information Rate) is stepped through roughly 25, 50, 75 and 100 percent to see whether each step holds. The second is the service performance test. Several services run in parallel, each with its own CIR, EIR and CoS marking, for long enough to expose faults that only show up under steady load.
The core difference lies in how the test runs. RFC 2544 runs one flow after another. Y.1564 checks several services at the same time, which mirrors how carriers actually sell the service to customers. If your circuit carries voice, data and management traffic on one port, a single-flow test will never reproduce that mix.
Setting up the test topology in a lab
For RFC 2544, the most common setup is a two-port loopback, or two test endpoints placed on either side of the device under test (DUT). The standard frame sizes are 64, 128, 256, 512, 1024, 1280 and 1518 bytes. The 64-byte case is the harshest on the packet processor, because the packet rate climbs very high and the device has less time to handle each frame.
Y.1564 allows more flexible frame sizing, and it is usually measured at both ends of the circuit so both directions are covered. The profile below is illustrative only, since the syntax changes from vendor to vendor:
service 1
cir 100 Mbps
eir 50 Mbps
cos 5
frame-size 512
service 2
cir 200 Mbps
eir 0 Mbps
cos 3
frame-size 1518CoS is the detail people skip most often. When two services share a port and their CoS markings are wrong, you cannot tell whether a fault comes from the device itself or from the priority queueing. We have spent hours untangling that exact confusion on a live lab bench, so label your CoS values before you start the run.
Walkthrough: running an RFC 2544 throughput test
RFC 2544 finds throughput with a binary search. The test box starts at a chosen rate. If frames are lost, it drops the rate; if nothing is lost, it raises it. It keeps narrowing until it finds the highest rate with zero loss for each frame size. That gives you the exact limit without guesswork, which is why vendors and engineers still rely on it for hardware qualification.
The RFC recommends that each trial run for at least 60 seconds and be repeated several times for stable results. When you record the outcome, keep the rate, frame size, frames sent and received, and the measured latency. Drop any one of these and the report becomes close to useless to whoever reads it later.
Walkthrough: running a Y.1564 service configuration test
In a Y.1564 run, you step through each CIR level. At every step the test set measures frame loss, delay and jitter, and it checks whether traffic is being marked correctly. The 25 percent step mostly confirms the service is up at all. The 100 percent step tells you whether the service holds its commitment under full load, and that is the step where marginal circuits usually fail.
After the CIR phase comes the EIR check, which covers bandwidth above the commitment. Here the test confirms that the bandwidth profile trims traffic at the right level rather than letting it through or clipping too early. Pass or fail is judged against the SLA on four measures: frame loss ratio, frame delay, frame delay variation, and service availability.
Choosing the right method at a glance
The table below summarises when each method fits. Read it as a guide to the use case, not as a ranking, because each standard does a different job well.
| Criterion | RFC 2544 | Y.1564 |
|---|---|---|
| Primary purpose | Device or benchmark qualification | Service acceptance against SLA |
| Scope | Single flow, one device or link | Several services with CIR/EIR and CoS |
| Output | Throughput, latency, loss, burst | Pass/fail per service against SLA |
| Typical user | Lab, vendor, engineer | Carrier turn-up, enterprise acceptance |
| Duration | Shorter per trial, many runs | Longer, including a sustained performance phase |
How results should be reported
Report RFC 2544 results separately for each frame size, and report Y.1564 results separately for each service. Resist the urge to merge them into one table. A reader who sees a single blended number will not know which service or frame size it belongs to, and that ambiguity is where disputes are born.
Every report should state the test duration, the test set model, the firmware or software version of the device, and the topology diagram. This is not bureaucratic padding. On the same switch, a firmware change can shift results considerably. If a result depends on the version, write that into the report instead of generalising it across releases.
Keep measured values and SLA thresholds clearly apart, and state the pass or fail verdict in plain words. The person buying the service, often not an engineer, needs to see the conclusion at a glance without decoding a wall of numbers.
Common mistakes engineers make
The most frequent mistake is using RFC 2544 to sign off an SLA that only Y.1564 can properly cover. RFC 2544 does not verify per-service CIR and EIR, so a circuit can pass RFC 2544 cleanly and still break the contract the moment real services share the line.
The second mistake is running one short test and treating the result as stable. A few dozen seconds may never expose a fault that recurs on a timer or under bursty load. The third is mixing frame-size results from different topologies into one table, which can make the numbers look better than they really are. The last, already mentioned, is ignoring CoS when several services share a port.
Choosing a method for your project
If you are evaluating a new switch or router in the lab, RFC 2544 is the right tool. If you are accepting a leased Ethernet circuit from a carrier, use Y.1564 and treat RFC 2544 as an optional preliminary check. Running both is often the safest path for a high-value link, because each catches a different class of problem.
For ongoing validation of traffic profiles after the circuit is live, automated load validation with synthetic traffic fits better than one-off tests. Our write-up on automation covers how to build that kind of recurring check into day-to-day operations so that drift gets caught early.
If you want to go deeper on the carrier side, the The MONA team publishes practical material on Ethernet service acceptance that is worth a read alongside the standards themselves.
Frequently asked questions
Can Y.1564 completely replace RFC 2544?
Not entirely. Y.1564 focuses on the service and the SLA, while RFC 2544 remains useful when you need to benchmark a device at its hardware limits. The two complement each other more than they replace each other, and most mature teams keep both in their toolkit.
Do I need specialised test hardware for both?
For RFC 2544, most common test sets are sufficient. For Y.1564, you usually need equipment that can generate several services with their own CIR, EIR and CoS, which means a more specialised test set. Exact support depends on the vendor and software version, so check the supplier documentation before you buy.
How long does a full Y.1564 test take?
It depends on the number of services and the length of the performance phase. Many teams finish the configuration phase in a few minutes per service, while the performance phase can run from several tens of minutes to a few hours before the data stabilises.
Which standard do carriers in Vietnam usually ask for?
Carriers typically ask for Y.1564 when accepting leased Ethernet services, since it ties directly to the SLA. RFC 2544 often appears as a check before the circuit goes into production. Confirm the exact requirement with your carrier before you plan the test, because contract wording varies.