SERVICE ASSURANCE

Kiểm thử kích hoạt dịch vụ Ethernet theo Y.1564: khác gì RFC 2544?

18/8/2026 · 17 phút

Thiết bị đo hai đầu phát nhiều class dịch vụ Ethernet qua mạng nhà cung cấp và đo KPI theo SLA
Mục lục bài viết 9 phần

Một đường Ethernet đạt throughput danh nghĩa chưa chứng minh từng class dịch vụ đáp ứng SLA khi chạy đồng thời. ITU-T Y.1564 tổ chức bài đo quanh service configuration và service performance, phù hợp nghiệm thu nhiều service class; RFC 2544 là phương pháp benchmark thiết bị/mạng với các bài throughput, latency, frame loss và back-to-back. Chọn sai phương pháp dễ tạo kết luận đẹp nhưng không trả lời đúng hợp đồng dịch vụ.

ĐỌC NHANH

Bài viết giúp bạn

  • Câu hỏi nghiệm thu cần trả lời
  • Y.1564 và RFC 2544 khác nhau ở đâu?
  • Topology và điều kiện đo
Tùy chỉnh đọc
01

Câu hỏi nghiệm thu cần trả lời

#

Nghiệm thu dịch vụ phải trả lời: traffic trong profile có được chuyển tiếp với throughput, frame loss, latency và delay variation đúng cam kết; traffic vượt profile được policer/shaper xử lý thế nào; và các class có giữ SLA khi hoạt động đồng thời hay không. Chỉ ping hoặc copy file không tạo tải có kiểm soát và không tách được từng service class.

Trước bài đo, chuẩn hóa Service Level Specification: UNI/NNI, VLAN, CoS/DSCP, frame size, CIR, EIR nếu có, burst, availability, one-way hay round-trip delay, measurement interval và ngưỡng. Nếu hợp đồng dùng thuật ngữ khác, lập bảng ánh xạ; không tự coi CIR đồng nghĩa với throughput thực nhận ở mọi frame size.

Y.1564 là khuyến nghị ITU-T cho Ethernet service activation test methodology. RFC 2544 được IETF xuất bản để benchmark thiết bị liên mạng; chính RFC yêu cầu thận trọng với test traffic và môi trường. Hai tài liệu có phần đo gần nhau nhưng intent, trình tự và cách kết hợp service khác nhau.

02

Y.1564 và RFC 2544 khác nhau ở đâu?

#

RFC 2544 tìm throughput bằng cách thay đổi offered load, rồi đo latency tại throughput, frame loss theo load và back-to-back. Nó hữu ích trong lab benchmark khi cần so sánh forwarding behavior dưới điều kiện kiểm soát. Tuy nhiên chạy từng stream/class tuần tự có thể bỏ qua tương tác QoS khi nhiều dịch vụ đồng thời.

Y.1564 bắt đầu bằng service configuration test để kiểm tra từng service theo profile, sau đó service performance test chạy các service đồng thời trong thời lượng xác định. Trọng tâm là nghiệm thu cấu hình và SLA, không phải tuyên bố một thiết bị đạt hiệu năng tối đa phổ quát.

Tiêu chí · Y.1564 · RFC 2544 Intent chính · Service activation/SLA · Benchmarking thiết bị/mạng Đơn vị logic · Nhiều service class/profile · Luồng/bài benchmark Tải đồng thời · Trọng tâm service performance · Không phải trọng tâm gốc CIR/EIR/policer · Kiểm chứng theo profile · Không mô hình hóa hợp đồng mặc định KPI · Throughput/loss/delay/FDV theo service · Throughput/latency/loss/back-to-back Kết luận · Dịch vụ phù hợp SLS trong điều kiện thử · Benchmark trong cấu hình thử

Không nên viết “Y.1564 thay thế hoàn toàn RFC 2544”. Trong lab, RFC 2544 vẫn hữu ích để tìm baseline forwarding; Y.1564 phù hợp hơn khi mục tiêu là activation nhiều class. Có thể dùng cả hai nếu câu hỏi và bằng chứng được tách rõ.

03

Topology và điều kiện đo

#

Topology hai đầu gồm test set tại hai UNI hoặc loopback ở đầu xa. One-way measurement cần hai đầu đồng bộ thời gian đủ tốt; round-trip có thể dùng loopback nhưng không tách được hướng và asymmetry. Ghi rõ L2 loop, L3 routed path, encapsulation, MTU, QoS trust boundary và policing point.

Khóa frame size, overhead accounting và line-rate definition. Nếu SLA tính L2 frame còn thiết bị báo L1 hoặc IP payload, con số sẽ lệch có hệ thống. Thử nhiều frame size đại diện, gồm nhỏ, lớn và IMIX nếu hợp đồng cho phép; không dùng một frame size rồi suy rộng.

Ghi trạng thái link, FEC nếu có, error counter, route/QoS policy và tải nền. Bài activation nên có maintenance window hoặc phạm vi tách biệt; test vượt CIR có thể ảnh hưởng khách hàng khác nếu chạy trên production chưa được cô lập.

Minh họa: Topology và điều kiện đo
Minh họa: Topology và điều kiện đo
04

Từ SLA tới traffic profile và KPI

#

Mỗi service class cần định danh L2/L3, CIR, EIR, burst, priority và KPI. Tạo traffic riêng có sequence/timestamp; đánh dấu class đúng trust model. Xác nhận thiết bị đo và DUT thống nhất cách tính loss, latency và frame delay variation (FDV). Với one-way delay, sai số clock có thể lớn hơn ngân sách SLA nếu không kiểm chứng trước.

Trường SLS · Cấu hình bài đo · Bằng chứng CIR · Offered load theo service · Tx/Rx frame, rate ổn định EIR/burst · Tải vượt CIR có kiểm soát · Policer/shaper outcome Frame loss · Sequence number · Lost/duplicate/out-of-order Delay · Timestamp one-way/RTT · Distribution p50/p95/p99/max FDV/jitter · Chuỗi delay · Phân bố, interval rõ ràng Availability · Soak + failure event · Timeline pass/fail CoS isolation · Nhiều class đồng thời · KPI từng class

Không chỉ báo average. Voice/video nhạy với tail delay và jitter; business data có thể ưu tiên loss/throughput. Tiêu chí pass/fail phải lấy từ hợp đồng hoặc test specification được phê duyệt, không tự gán một ngưỡng “chuẩn ngành”.

05

Ma trận bài đo service configuration

#

Với từng service, tăng offered load theo các bước dưới CIR, tại CIR và vượt profile theo phạm vi an toàn. Xác nhận traffic trong profile đạt KPI, traffic vượt profile được xử lý đúng và không làm hỏng class ưu tiên khác. Nếu có CBS/EBS hoặc burst rule, mô hình hóa burst duration và idle period cụ thể.

Bước · Offered load · Mục tiêu · Pass/fail cần chốt Baseline · Không tải/nhỏ · Mapping, connectivity · Đúng VLAN/CoS/path Ramp · Nhiều mức dưới CIR · Không policer sớm · Loss/delay trong SLS CIR · Duy trì tại CIR · Cam kết service · KPI đạt đủ interval Trên CIR · CIR + phần vượt · Kiểm tra EIR/policer · Không ảnh hưởng in-profile Burst · Burst có thời lượng · CBS/EBS behavior · Theo profile đã xác nhận Negative · Sai VLAN/marking · Trust/policy · Không nhập nhầm class

Thứ tự test cần tránh warm-up và state cũ. Xóa counter, chờ queue ổn định và đánh dấu từng step. Nếu service có protection path, lặp configuration test trên cả primary/backup; một đường pass không chứng minh đường còn lại đúng QoS.

06

Service performance và soak test

#

Sau khi từng service pass, chạy đồng thời tất cả service tại CIR hoặc profile được thống nhất. Đây là lúc lộ lỗi scheduler, shared buffer, policer hierarchy và oversubscription. Giữ tải đủ lâu để qua chu kỳ routing, telemetry và traffic nền; thời lượng phải ghi trong biên bản, không chỉ nêu “soak”.

Gây các sự kiện được phép như link failover, route reconvergence hoặc đổi queue profile nếu chúng nằm trong acceptance scope. Đo loss burst, recovery time và KPI từng service trước–trong–sau event. Nếu SLA loại trừ maintenance event, vẫn có thể chạy resilience test riêng và không trộn verdict với activation.

Phân biệt service pass với device capacity. Nếu tổng CIR thấp hơn line rate và test pass, chưa chứng minh thiết bị xử lý line rate ở mọi frame size. Ngược lại, RFC 2544 throughput cao không chứng minh scheduler giữ KPI cho nhiều class đồng thời.

Minh họa: Service performance và soak test
Minh họa: Service performance và soak test
07

Test plan, checklist và bằng chứng

#

Pha A review SLS và mapping. Pha B xác minh topology, clock, frame size và overhead. Pha C chạy service configuration từng class. Pha D chạy service performance đồng thời. Pha E thực hiện failure/soak nếu trong scope. Cuối cùng đối soát raw counters và ký verdict theo từng KPI.

Bằng chứng nên có test specification phiên bản, sơ đồ, serial/model/firmware, clock status, cấu hình service, traffic profile, raw result và exception. Screenshot tổng quan không đủ nếu không truy lại được từng stream và interval.

  • Xác nhận UNI/NNI, VLAN, CoS/DSCP và trust boundary.
  • Ghi CIR/EIR, burst, frame size, overhead và interval.
  • Hiệu chuẩn clock/loopback; xác định one-way hay round-trip.
  • Chụp baseline link/error/QoS counter và traffic nền.
  • Chạy từng service dưới CIR, tại CIR và vượt profile an toàn.
  • Kiểm tra negative marking/VLAN để bắt mapping sai.
  • Chạy mọi service đồng thời trong thời lượng thống nhất.
  • Ghi Tx/Rx, loss, duplicate, reorder, delay và FDV từng class.
  • Nếu có, gây failover rồi đo recovery và loss burst.
  • Xuất cấu hình, raw result, timeline và biên bản pass/fail.
08

Đọc kết quả và giới hạn kết luận

#

Loss xuất hiện trước CIR có thể do mapping sai, overhead mismatch, policer cấu hình thấp, lỗi vật lý hoặc cross-traffic. Delay tăng mạnh nhưng loss thấp có thể chỉ ra queue/buffer. Một class ưu tiên pass khi chạy riêng nhưng fail khi đồng thời thường chỉ ra scheduler, shared resource hoặc tổng CIR không phù hợp.

Kết quả chỉ đúng với route, topology, protection state, frame size, profile và thời lượng đã thử. Loopback round-trip không chứng minh one-way asymmetry. Activation pass không thay thế giám sát dài hạn; production cần baseline và SLA telemetry liên tục.

Không công bố thiết bị “đạt Y.1564” như chứng nhận chung nếu chỉ chạy một profile tự định nghĩa. Y.1564 là phương pháp; verdict phải gắn với SLS, điều kiện đo và bằng chứng cụ thể.

09

Khái niệm cần nhớ

#
  • Service Activation Test: Bài đo trước khi bàn giao/kích hoạt dịch vụ.
  • CIR: Committed Information Rate, mức tốc độ cam kết theo profile.
  • EIR: Excess Information Rate, phần vượt cam kết theo thỏa thuận.
  • FDV: Frame Delay Variation, biến thiên trễ frame.
  • SLS: Service Level Specification, đặc tả mức dịch vụ đo được.
  • UNI/NNI: Giao diện khách hàng–mạng và mạng–mạng.
  • Back-to-back: Bài RFC 2544 đo số frame burst có thể xử lý không mất.
THUẬT NGỮ NHANH

Khái niệm cần nhớ

Baseline
Dải giá trị bình thường được thu đủ lâu để làm mốc so sánh và đặt ngưỡng.
SLA
Cam kết chất lượng dịch vụ gắn với KPI, phạm vi, thời gian và cách đo cụ thể.
Active test
Phép đo dùng traffic tổng hợp được tạo có chủ đích giữa các điểm kiểm tra.
TÀI LIỆU ĐỐI CHIẾUTài liệu tham khảo3 nguồn

Nội dung được biên soạn độc lập, theo hướng vendor-neutral và đối chiếu các tài liệu gốc dưới đây. Tính năng sản phẩm cần được kiểm tra lại theo phiên bản đang sử dụng.

Nguyên tắc biên tập

NetVali ưu tiên nguồn tiêu chuẩn và tài liệu chính thức; phân biệt khuyến nghị triển khai với yêu cầu của tiêu chuẩn; không công bố thông số sản phẩm chưa gắn với phiên bản và điều kiện đo.

Thông số và khả năng sản phẩm có thể thay đổi theo phiên bản. Hãy đối chiếu tài liệu chính thức trước khi xây dựng cấu hình hoặc tiêu chí nghiệm thu.
BẮT ĐẦU TỪ BÀI TOÁN

Cần chuyển kiến thức thành test plan?

Chia sẻ mục tiêu, topology và ràng buộc kỹ thuật. NetVali sẽ cùng bạn xác định bài đo phù hợp.

Trao đổi yêu cầu kỹ thuật