Service Provider Archives

Performance Measurement in OcNOS: Y.1731 OAM and Y.1564 Service Acceptance Testing

Carrier Ethernet services require two distinct types of performance measurement: continuous in-service monitoring to detect degradation over time, and one-time acceptance testing to verify the service meets its committed parameters before customer handoff. ITU-T Y.1731 covers the first; Y.1564 covers the second.

This is Part 2 of the IP Infusion performance measurement series. Part 1 covers TWAMP for IP/MPLS networks.

Y.1731: Ethernet OAM for In-Service Monitoring

Y.1731 defines Ethernet Operation, Administration, and Maintenance (OAM) frames that measure performance metrics at Layer 2 — within an Ethernet service domain (MEG) defined between two Maintenance End Points (MEPs). Unlike TWAMP which operates at IP level, Y.1731 measures at the Ethernet frame level, providing accurate performance data for carrier Ethernet services regardless of IP routing changes.

Key Y.1731 Measurement Functions

Function	ITU Code	Measures
One-Way Delay Measurement	1DM	One-way frame delay (requires clock sync)
Two-Way Delay Measurement	DMM/DMR	Round-trip frame delay and delay variation (jitter)
Loss Measurement	LMM/LMR	Frame loss ratio between two MEPs
Synthetic Loss Measurement	SLM/SLR	Loss estimation without traffic disruption

! OcNOS -- Y.1731 MEG and MEP configuration
!
! Step 1: Define Maintenance Entity Group (MEG)
ethernet cfm domain CARRIER-SERVICES level 4
  service SVC-001 evc SVC-001
    continuity-check interval 1s
    continuity-check loss-threshold 3
  !
!
! Step 2: Define Maintenance End Points (MEPs)
interface eth-0-1
  ethernet cfm mep domain CARRIER-SERVICES service SVC-001
    mep-id 1
    direction down                   ! Toward customer
    cos 5                            ! High-priority OAM frames
!
! Step 3: Enable delay measurement toward remote MEP
ethernet cfm delay-measurement domain CARRIER-SERVICES service SVC-001
  mep 1 target-mep 2
  interval 1000                      ! Measure every 1 second
  frames 10                          ! 10 frames per measurement burst
!
! View delay measurement results:
show ethernet cfm delay-measurement domain CARRIER-SERVICES
! Output: avg delay, min/max delay, delay variation (jitter)

! OcNOS -- Y.1731 Frame Loss Measurement
!
ethernet cfm loss-measurement domain CARRIER-SERVICES service SVC-001
  mep 1 target-mep 2
  interval 10000                     ! Measure every 10 seconds
  cos 5
!
show ethernet cfm loss-measurement domain CARRIER-SERVICES
! Output: near-end loss, far-end loss, loss ratio %

Y.1564: Service Acceptance Testing

Y.1564 defines a two-phase test procedure that validates a carrier Ethernet service meets its committed bandwidth, delay, and loss parameters before being handed over to the customer.

Phase 1 (Service Configuration Test) — verifies Committed Information Rate (CIR), Committed Burst Size (CBS), Excess Information Rate (EIR), and traffic policing behavior step by step at 25%, 50%, 75%, and 100% of CIR, then at EIR, then above EIR
Phase 2 (Service Performance Test) — runs traffic at 100% CIR for a configured duration (typically 15 minutes to 24 hours) and measures frame loss ratio, frame transfer delay, and delay variation against SLA thresholds

! OcNOS -- Y.1564 service acceptance test configuration
!
y1564 service-test SVC-001-ACCEPTANCE
  !
  ! Phase 1: CIR step test (25/50/75/100% of 100Mbps CIR)
  phase1
    cir 100000                       ! 100 Mbps CIR
    eir 50000                        ! 50 Mbps EIR
    cbs 12500                        ! Committed burst size (bytes)
    step-duration 60                  ! 60 seconds per step
  !
  ! Phase 2: Performance test at full CIR
  phase2
    duration 900                     ! 15-minute sustained test
    cir 100000
    !
    ! SLA thresholds (test fails if exceeded):
    max-frame-loss-ratio 0.001       ! 0.001% = 1 frame per 100,000
    max-frame-transfer-delay 10      ! 10ms maximum one-way delay
    max-frame-delay-variation 5      ! 5ms maximum jitter
  !
!
! Execute test (Phase 1 then Phase 2 automatically):
y1564 service-test SVC-001-ACCEPTANCE start
!
! Monitor progress:
show y1564 service-test SVC-001-ACCEPTANCE status
!
! View final report:
show y1564 service-test SVC-001-ACCEPTANCE results
! Pass/fail per phase, per metric, with measured values vs. thresholds

IP Infusion Engineering Team

Performance Measurement for Service Providers: TWAMP in OcNOS

Service providers carry a contractual obligation to deliver specific performance levels — latency, jitter, and packet loss targets defined in SLAs with enterprise and wholesale customers. Meeting these obligations requires more than reactive monitoring: operators need active measurement tools that continuously probe the network and alert when performance degrades, before customers raise a ticket.

TWAMP (Two-Way Active Measurement Protocol, RFC 5357) provides exactly this. It sends test packets between two network nodes and measures round-trip delay, one-way delay (with clock synchronization), jitter, and packet loss — all without dedicated hardware probes.

TWAMP Architecture

TWAMP session flow. Node A (Control Client + Session Sender) establishes a TCP control session to Node B (Server). UDP test packets are sent with timestamps; Node B reflects them with its own timestamps. Node A calculates round-trip delay, jitter, and packet loss from the four timestamps.

TWAMP Configuration in OcNOS

! OcNOS -- TWAMP server (Node B: responds to test sessions)
!
twamp server
  port 862                       ! Standard TWAMP control port
  timer inactivity 900           ! Close idle sessions after 15 min
!
! Optionally restrict to specific senders:
twamp server
  client-list 10.0.0.1           ! Only accept from Node A

! OcNOS -- TWAMP sender (Node A: initiates measurement sessions)
!
twamp sender
  !
  ! Session 1: measure to PE2 (enterprise SLA monitoring)
  session PE2-SLA
    destination 10.0.0.2         ! Node B loopback
    port 862
    dscp 46                      ! EF: measure on high-priority path
    interval 1000                ! Send test packet every 1 second
    packet-size 256              ! Simulate real application traffic
    timeout 5000                 ! 5-second session timeout
  !
  ! Session 2: measure to remote site (bulk data path)
  session REMOTE-BULK
    destination 10.0.0.5
    port 862
    dscp 0                       ! BE: measure best-effort path
    interval 5000                ! Every 5 seconds
    packet-size 1400             ! Large packet for bulk path testing
  !
!
! Start measurement sessions:
twamp sender session PE2-SLA start
twamp sender session REMOTE-BULK start
!
! View results:
show twamp session PE2-SLA
! Output includes: RTT min/avg/max, jitter, packet loss %
!
show twamp session summary
! Overview of all active sessions with current metrics

Integrating TWAMP with SLA Alerting

! OcNOS -- IP SLA tracking: trigger action when delay exceeds threshold
!
ip sla 10
  icmp-echo 10.0.0.2 source-interface lo
  threshold 50            ! Alert if RTT exceeds 50ms
  frequency 30            ! Probe every 30 seconds
!
ip sla schedule 10 start-time now life forever
!
! Track SLA and trigger route change on threshold violation:
track 10 ip sla 10 reachability
  delay down 5 up 10      ! Hold-down timers to prevent flapping
!
! Use track object in routing:
ip route 0.0.0.0/0 10.0.0.2 track 10
! Primary default route only active when SLA target is reachable

IP Infusion Engineering Team

Fanless Cell Site Routers for 5G Backhaul: OcNOS in Remote and Rugged Environments

Not every cell site is located in a climate-controlled equipment room. 5G deployments increasingly push network equipment into outdoor cabinets, street-level enclosures, rooftop installations, and remote tower sites where dust, temperature extremes, and lack of power for active cooling make traditional router hardware unsuitable.

OcNOS supports a range of fanless Cell Site Router (CSR) platforms specifically designed for these environments, delivering full 5G backhaul capabilities — SR-MPLS transport, EVPN services, and IEEE 1588v2 PTP timing — without a single spinning fan.

Why 5G Backhaul Needs Purpose-Built CSR Hardware

A 5G cell site gateway must satisfy requirements that go well beyond basic IP routing:

Timing accuracy — 5G NR (New Radio) requires phase synchronization accurate to ±1.5μs (microseconds). This demands IEEE 1588v2 PTP with hardware timestamping support, not software-only PTP.
Rugged operation — operating temperature range typically −40°C to +70°C for outdoor equipment; fanless passive cooling eliminates the most common point of failure in harsh environments.
SR-MPLS backhaul — 5G transport architectures use SR-MPLS for deterministic path control and fast reroute; the CSR must participate as an IS-IS SR node with full TI-LFA support.
Small form factor — street cabinets and outdoor enclosures have limited rack space; compact 1U or sub-1U platforms are required.

OcNOS Fanless CSR Platforms

Platform	Ports	Cooling	Temp Range	PTP
UfiSpace S9502-16SMT	16×SFP+ + 4×100G	Fanless	0–55°C	✓ HW timestamp
UfiSpace S9502-12SM	4×10G SFP+ + 8×1G SFP	Fanless	0–55°C	✓

OcNOS CSR Configuration for 5G Backhaul

! OcNOS CSR -- 5G backhaul: SR-MPLS + PTP configuration
!
! IS-IS SR for backhaul transport
router isis BACKHAUL
  net 49.0002.0000.0000.0050.00
  is-type level-2-only
  segment-routing mpls
  fast-reroute per-prefix level-2 ti-lfa
  address-family ipv4 unicast
    segment-routing mpls
  exit-address-family
!
interface lo
  ip address 10.5.0.50/32
  ip router isis BACKHAUL
  isis segment-routing prefix-sid index 50
!
interface eth-0-1
  no shutdown
  ip address 192.168.50.1/30
  ip router isis BACKHAUL
  isis network point-to-point
  isis metric 10
!
! IEEE 1588v2 PTP for 5G timing (ITU-T G.8275.1 profile)
ptp
  clock-type boundary
  domain 24
  profile g8275.1
  priority1 128
  !
  port eth-0-1
    unicast-negotiation enable
  !
!
! SyncE for frequency sync layer
interface eth-0-1
  synchronous-ethernet enable
  esmc send
!
! Verify timing state:
show ptp clock
show ptp port dataset eth-0-1

IP Infusion Engineering Team

Nanosecond Clock Accuracy for 4G/5G Networks: PTP and SyncE with OcNOS

Timing and synchronization are non-negotiable requirements for successful 4G and 5G network deployments. Unlike 4G LTE which required only frequency synchronization, 5G NR requires phase synchronization accurate to ±1.5 microseconds (1,500 nanoseconds) at the antenna port. Delivering this accuracy across a multi-hop packet-switched transport network requires a coordinated approach combining two complementary technologies: IEEE 1588v2 PTP and SyncE.

Why 5G Requires Nanosecond Accuracy

5G NR base stations (gNBs) use Time Division Duplex (TDD) for most frequency bands. In TDD, both uplink and downlink transmissions share the same frequency spectrum, separated in time. If adjacent cell sites are not synchronised to a common time reference, their TDD uplink/downlink transitions occur at different times — causing interference at cell boundaries that degrades network capacity and user experience.

The ITU-T G.8271 standard specifies that the maximum time error (TE) at the air interface must be within ±1.5μs for most 5G NR configurations, and as tight as ±130ns for some advanced 5G features. This is stricter than 4G LTE which required only ±1.5μs frequency accuracy.

The Two-Layer Timing Architecture

Technology	What it Distributes	Standard	OcNOS Support
SyncE	Frequency (clock rate)	ITU-T G.8261/G.8262	✓ All SP platforms
IEEE 1588v2 PTP	Phase and time-of-day	ITU-T G.8265/G.8275	✓ Hardware timestamping

SyncE distributes a highly accurate frequency reference over the Ethernet physical layer — essentially making the Ethernet clock as accurate as a GPS-referenced source. IEEE 1588v2 PTP then distributes phase (the precise time of day) over the packet network, using hardware timestamping to compensate for packet delay variation.

OcNOS PTP Configuration for 5G Transport

! OcNOS -- ITU-T G.8275.1 telecom PTP profile for 5G fronthaul
! (Full-timing support: all network elements are PTP-aware)
!
ptp
  clock-type boundary                ! BC: receives from upstream, distributes downstream
  domain 24                          ! G.8275.1 default domain
  profile g8275.1                    ! ITU-T telecom profile
  priority1 128
  priority2 128
  clock-class 135                    ! Boundary clock class
  !
  ! Uplink port: receives PTP from aggregation (slave mode)
  port eth-0-1
    role slave                       ! Synchronize to upstream grandmaster
    unicast-negotiation enable
    delay-mechanism end-to-end
  !
  ! Downlink ports: distribute PTP to gNBs (master mode)
  port eth-0-2
    role master
    unicast-negotiation enable
    delay-mechanism end-to-end
  !
  port eth-0-3
    role master
    unicast-negotiation enable
  !
!
! SyncE for frequency layer
interface eth-0-1
  synchronous-ethernet enable
  esmc send                          ! Distribute ESMC quality level downstream
!
interface eth-0-2
  synchronous-ethernet enable
  esmc send
!
! Verify timing chain:
show ptp clock
! Check: clockClass, offsetFromMaster (should be <500ns for good lock)

show ptp time-status
! Check: grandmasterIdentity, stepsRemoved, offsetFromMaster

show synchronous-ethernet clock-source
! Check: QL level (should be QL-PRC or QL-SSU-A for 5G timing)

Timing Budget: How Many Hops Are Possible

ITU-T G.8271.1 specifies maximum time error budgets per network element. With OcNOS hardware-assisted PTP timestamping, each boundary clock introduces approximately 20–30ns of residual time error. This allows a timing chain of 10+ hops from grandmaster to gNB while remaining within the ±1.5μs budget.

IP Infusion Engineering Team