Tecnologia / TWAMP & Service Assurance
Service Assurance

TWAMP, Y.1564 and Y.1731: proving SLA on an open network

Carriers sell service-level agreements, then have to prove they are met. OcNOS builds the measurement in: TWAMP for active IP delay, jitter, and loss; Y.1564 to validate a service at turn-up; and Y.1731 Ethernet OAM for continuous per-service delay and loss. No proprietary probe appliances, no timing black boxes.

One service, three measurements

A customer service crosses two OcNOS provider-edge routers over an MPLS or Segment Routing core. The same routers that forward the traffic also measure it: a Y.1564 test proves the service at turn-up, Y.1731 Ethernet OAM watches per-service frame delay and loss between the maintenance end points, and a TWAMP session measures round-trip delay, jitter, and loss inside the routed VPN.

Topologia di service assurance: un servizio cliente attraversa due router provider edge OcNOS su un core MPLS o Segment Routing, dove un test Y.1564 convalida il servizio alla messa in servizio, Y.1731 Ethernet OAM misura il ritardo e la perdita di frame per servizio tra i maintenance end point, e una sessione TWAMP misura il ritardo di andata e ritorno, il jitter e la perdita all'interno della VPN instradata.
Un servizio, tre misurazioni: un test di attivazione Y.1564 alla messa in servizio, Y.1731 Ethernet OAM per il ritardo e la perdita di frame continui tra i PE, e una sessione TWAMP per il ritardo di andata e ritorno, il jitter e la perdita all'interno della VPN.

Service assurance answers one operator question: is the path actually delivering what the contract promises? On a closed vendor stack that usually means bolting on a separate probe or a dedicated test head. OcNOS answers it from the router itself, using the three standards network operators already write into their SLAs.

01TWAMP: active IP performance measurement

TWAMP, the Two-Way Active Measurement Protocol (IETF RFC 5357), measures the real performance of a live IP path by sending timestamped test packets between two endpoints and reading the results back. A session-sender originates the test traffic and a session-reflector bounces it, so the sender can compute round-trip delay, delay variation, and packet loss on the exact path a service rides. Because it is an open standard, an OcNOS endpoint interoperates with any conformant TWAMP sender or reflector.

OcNOS implements the full protocol on both sides. A router can be the control-client and session-sender that runs the tests, the server and session-reflector that answers them, or both at once, and it also supports one-way measurement where the metric of interest is one direction only.

What makes this useful for carriers is where OcNOS can run the measurement. TWAMP sessions run over plain MPLS transport and, importantly, inside the customer VPN:

  • MPLS L3VPN e EVPN MPLS L3VPN, so the SLA is measured in the same VRF the customer's traffic uses.
  • L3VPN over Segment Routing MPLS e L3VPN su SRv6, for operators who have moved transport to SR.
  • Inter-VPN access interfaces, to measure across service boundaries.

Measuring inside the VPN matters because a path that looks healthy on the underlay can still miss its SLA for one tenant. TWAMP in the service context measures what the customer actually experiences.

02Y.1564: service activation testing

ITU-T Y.1564, the Service Activation Test (SAT), is run once when a service is turned up, to prove it meets its SLA before the customer is told it is live. It replaces the older RFC 2544 methodology for multi-service Ethernet because it tests all of a service's SLA parameters together rather than one at a time.

A Y.1564 test has two stages. The configuration test ramps traffic through the committed information rate (CIR) and excess information rate (EIR) to confirm the policer and shaper behave as provisioned. The performance test then soaks the service at CIR for a sustained period and verifies the four SLA metrics at once:

  • Information rate (throughput at CIR and EIR),
  • Frame Loss Ratio (FLR),
  • Frame Transfer Delay (FTD),
  • Frame Delay Variation (FDV).

OcNOS runs the Y.1564 SAT natively, so a turn-up technician can validate an Ethernet service to its SLA from the OcNOS CLI instead of dispatching a separate test set to each end.

03Y.1731: continuous Ethernet OAM

Where Y.1564 proves a service at birth, ITU-T Y.1731 Ethernet OAM watches it for life. Built on IEEE 802.1ag Connectivity Fault Management, it gives every Ethernet Virtual Connection its own always-on fault detection and performance monitoring. OcNOS implements the full toolkit:

Connectivity

CFM

Connectivity Fault Management with continuity check, loopback, and linktrace across the service, including CFM over layer-2 bridge, provider bridging, VPLS, VPWS, and xConnect.

Delay

Frame delay (DMM/DMR)

Frame delay and inter-frame delay variation measured with Delay Measurement Message and reply, per service.

Loss

Frame loss (LMM/LMR, SLM/SLR)

Frame loss measured with Loss Measurement and with Synthetic Loss Measurement, which injects synthetic frames to measure loss even on services with no real traffic.

EVPN

OAM over EVPN

Delay and loss measurement over EVPN MPLS and EVPN VxLAN ELINE and ELAN services, including single-homed and active/active multi-homed attachment.

Resilienza

OAM over protected rings

CFM integrated with G.8032 ring protection (ERPS over CFM) and G.8031 linear protection (ELPS with CFM), so OAM keeps working across a protection switch.

Standards

Open and interoperable

Standards-based 802.1ag and Y.1731, so OcNOS OAM interoperates with existing Carrier Ethernet equipment in a multi-vendor metro.

04How the three fit together

The three standards are not alternatives. They are the assurance lifecycle of a service, and OcNOS runs all of them on the same router:

Turn-up

Y.1564

Prove the new service meets throughput, loss, delay, and jitter before it goes live.

In service, layer 2

Y.1731

Continuously monitor per-service Ethernet delay and loss, and detect connectivity faults, for the life of the EVC.

In service, layer 3

TWAMP

Actively measure round-trip delay, jitter, and loss inside the routed VPN, across MPLS and SR transport.

Together they let an operator sell a hard SLA and back it with measurement at both the Ethernet and IP layers, on open hardware, without a rack of proprietary probes.

What you get with OcNOS service assurance

Built-in TWAMP, Y.1564, and Y.1731 turn every OcNOS router into its own SLA measurement point. That means faster service turn-up, per-tenant visibility inside the VPN, and SLA evidence you can show a customer, all from the same platform that forwards the traffic and all over standards that interoperate in a multi-vendor network.

Metro Ethernet Service Provider Networks PTP & SyncE Segment Routing MPLS EVPN OcNOS-SP
FAQ

Domande frequenti

What is TWAMP?
TWAMP, the Two-Way Active Measurement Protocol defined in IETF RFC 5357, measures round-trip delay, delay variation (jitter), and packet loss between two IP endpoints. One endpoint acts as a session-sender and the other as a session-reflector, exchanging timestamped test packets so an operator can measure the real performance of a live IP path without proprietary probes.
What is the difference between TWAMP, Y.1564 and Y.1731?
They cover different layers and phases of service assurance. Y.1564 is a service activation test run once at turn-up to prove a new service meets its SLA. Y.1731 is continuous Ethernet-layer OAM that monitors frame delay and frame loss per service. TWAMP is active IP-layer measurement of round-trip delay, jitter, and loss across a routed or MPLS path. OcNOS supports all three, so one platform covers turn-up validation and ongoing monitoring at both the Ethernet and IP layers.
Does OcNOS support both TWAMP client and server?
Yes. OcNOS implements the TWAMP session-sender and control-client roles as well as the server and session-reflector roles, plus one-way measurement. That means an OcNOS router can originate SLA tests, reflect tests originated elsewhere, or both, and interoperate with third-party TWAMP endpoints because the protocol is standards-based.
What is a Y.1564 service activation test?
A Y.1564 Service Activation Test (SAT) validates that a newly provisioned service meets its contracted SLA before it is handed to the customer. It runs a configuration test that ramps the committed and excess information rates, then a performance test that soaks the service and verifies throughput, frame loss ratio, frame transfer delay, and frame delay variation against the SLA thresholds.
How does OcNOS measure frame delay and frame loss with Y.1731?
OcNOS uses ITU-T Y.1731 Ethernet OAM with 802.1ag Connectivity Fault Management. Frame delay and delay variation are measured with Delay Measurement Messages and replies (DMM/DMR), and frame loss is measured with Loss Measurement (LMM/LMR) and Synthetic Loss Measurement (SLM/SLR). These run over EVPN, VPLS, VPWS, provider bridging, G.8032 rings, and G.8031 linear protection.
Over which transports can OcNOS run TWAMP?
OcNOS runs TWAMP over MPLS transport and inside customer VPNs, including MPLS L3VPN, EVPN MPLS L3VPN, L3VPN over Segment Routing MPLS, and L3VPN over SRv6, as well as inter-VPN access interfaces. This lets an operator measure SLA inside the exact service context a customer is paying for.

Building a metro or service-provider network that has to prove its SLA?

Talk to an engineer →
Datasheet e schede soluzione

Approfondite. Portatelo con voi.

A short, technical download that goes further than this page: the full OcNOS-SP datasheet.

Datasheet

Datasheet OcNOS-SP

Specifica completa di OcNOS-SP: il set di funzionalità access, cell site e aggregazione, gli SKU software, le piattaforme hardware supportate e la guida all'ordine della soluzione.

Ottieni il datasheet