Giới thiệu dự án

Trong kỷ nguyên chuyển đổi số và phát triển hạ tầng viễn thông, xu thế hội tụ mạng thế hệ mới (Next Generation Network - NGN) trở thành bước đi tất yếu đối với các nhà cung cấp dịch vụ viễn thông (ISP/Telco). Thay vì duy trì các hạ tầng mạng riêng biệt tốn kém cho từng dịch vụ như thoại truyền thống (TDM/PSTN) và truyền tải dữ liệu (IP Data), việc tích hợp đa dịch vụ trên cùng một hạ tầng giao thức IP thống nhất mang lại lợi ích kinh tế vượt trội. Tuy nhiên, theo báo cáo kỹ thuật từ ITU-T và Cisco Systems, việc hợp nhất này tạo ra sự xung đột nghiêm trọng về mặt tài nguyên mạng khi các luồng lưu lượng có đặc tính đối nghịch cùng chia sẻ băng thông kênh truyền hữu hạn.

Hạ tầng mạng IP-177 của Công ty Cổ phần Dịch vụ Bưu chính Viễn thông Sài Gòn (Saigon Postel - SPT) cung cấp song song hai dịch vụ chủ lực: Thoại qua giao thức Internet (VoIP) và Dữ liệu Internet (IP Data). Thực tế vận hành cho thấy, khi lưu lượng dữ liệu (FTP, Web, Mail) bùng nổ, các gói tin kích thước lớn (1500 bytes) sẽ chiếm dụng toàn bộ bộ đệm (buffer) và băng thông kênh truyền WAN (vốn bị giới hạn ở các mức 64 Kbps, 128 Kbps đến 2 Mbps), dẫn đến hiện tượng nghẽn mạch cục bộ ("nút cổ chai"). Điều này gây suy giảm nghiêm trọng chất lượng cuộc gọi VoIP: độ trễ cao, méo tiếng, giật tiếng hoặc rớt cuộc gọi.

+-------------------------------------------------------------------------------+
|                             HẠ TẦNG MẠNG HỘI TỤ                               |
|                                                                               |
|  [VoIP Client] ---\                                   /---> [VoIP Gateway]   |
|   (Delay-Sensitive)\    [ Router Biên ]              /     (Voice Quality OK) |
|                     ===> [ Cơ chế QoS ] === WAN ===>                          |
|   (Loss-Sensitive) /    [ Phân lớp/Lập lịch ]        \     (Throughput Max)   |
|  [Data Client] ---/                                   \---> [Data Server]     |
+-------------------------------------------------------------------------------+

Mục tiêu dự án

  1. Phân tích toàn diện các đặc tính kỹ thuật của lưu lượng Thoại (VoIP) và Dữ liệu (Data) trên hạ tầng mạng IP-177.
  2. Nghiên cứu và lựa chọn mô hình chất lượng dịch vụ (QoS) tối ưu, tập trung vào kiến trúc Dịch vụ phân biệt (Differentiated Services - DiffServ) kết hợp các công cụ điều khiển luồng của Cisco IOS.
  3. Thiết kế, xây dựng chính sách QoS chi tiết bao gồm: Phân loại gói tin (Classification & Marking), Quản lý nghẽn (Congestion Management), Tránh nghẽn (Congestion Avoidance), Giám sát tốc độ (Policing & Shaping) và Tối ưu hóa liên kết (Link Efficiency).
  4. Triển khai thử nghiệm và đánh giá thực nghiệm hiệu năng mạng trên mô hình phòng Lab IPT và tuyến truyền dẫn thực tế HNI - HPG, chứng minh khả năng duy trì chất lượng thoại tiêu chuẩn trong điều kiện nghẽn mạng nghiêm trọng.

Phương pháp tiếp cận giải pháp

Dự án áp dụng mô hình phân lớp DiffServ kết hợp kiến trúc Modular QoS CLI (MQC) trên thiết bị định tuyến Cisco. Giải pháp kết hợp kỹ thuật hàng đợi ưu tiên theo trọng số dựa trên lớp (Class-Based Weighted Fair Queueing - CBWFQ) và Hàng đợi ưu tiên tuyệt đối (Low Latency Queueing / Priority Queueing - LLQ/PQ) cho thoại, kết hợp thuật toán loại bỏ sớm gói tin theo trọng số (Weighted Random Early Detection - WRED) để kiểm soát lưu lượng TCP, cùng kỹ thuật phân mảnh và chèn gói (Link Fragmentation and Interleaving - LFI) trên liên kết Multilink PPP (MLP).

Chỉ số kỳ vọng (Target Metrics)

  • Độ trễ một chiều (One-way End-to-End Delay): Duy trì $\le 150\text{ ms}$ cho luồng thoại theo tiêu chuẩn ITU-T G.114.
  • Độ biến thiên trễ (Jitter): Khống chế $\le 30\text{ ms}$.
  • Tỷ lệ mất gói (Packet Loss Rate): Dưới $1%$ đối với gói tin thoại VoIP.
  • Băng thông cam kết: Đảm bảo tối thiểu $75%$ băng thông khả dụng cho các dịch vụ ưu tiên khi xảy ra nghẽn mạch mà không làm gián đoạn hoàn toàn luồng dữ liệu thông thường.

Phạm vi và giới hạn

Đề tài tập trung triển khai và tối ưu hóa các cơ chế QoS trên lớp mạng (Layer 3) và lớp liên kết dữ liệu (Layer 2) cho các thiết bị định tuyến biên và lõi của Cisco thuộc hệ thống mạng IP-177 của SPT. Đề tài không đi sâu vào việc nâng cấp phần cứng vật lý mà giải quyết bài toán tối ưu hóa tài nguyên phần mềm và cấu hình chính sách mạng.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Trong hạ tầng mạng IP truyền thống hoạt động theo cơ chế "nỗ lực tối đa" (Best-Effort), tất cả các gói tin đều được đối xử bình đẳng thông qua hàng đợi FIFO (First-In, First-Out). Khi xảy ra nghẽn mạch, cơ chế Tail Drop sẽ loại bỏ bất kỳ gói tin nào đến sau khi bộ đệm đầy, gây ra hiện tượng sụt giảm hiệu năng đồng loạt (TCP Global Synchronization) và làm gián đoạn luồng tín hiệu thoại thời gian thực.

Tiêu chí so sánh Hàng đợi FIFO Hàng đợi Ưu tiên (PQ) Hàng đợi Tùy biến (CQ) Hàng đợi CBWFQ kết hợp LLQ
Phân loại lưu lượng Không hỗ trợ Phân thành 4 mức cố định Hỗ trợ tối đa 16 hàng đợi Hỗ trợ lên tới 64 lớp linh hoạt
Bảo vệ luồng thoại (VoIP) Kém, dễ bị nghẽn Tốt (luôn phục vụ trước) Trung bình (chia theo Byte) Tuyệt đối (LLQ độ trễ thấp)
Hiện tượng đói băng thông (Starvation) Không Có (đối với hàng đợi thấp) Không Không (phân bổ theo %)
Kiểm soát độ trễ/Jitter Không kiểm soát được Tốt cho hàng đợi High Trung bình Tối ưu hóa toàn diện
Độ phức tạp cấu hình Mặc định (không cần cấu hình) Trung bình Phức tạp Cấu hình chuẩn hóa qua MQC

Phân loại yêu cầu theo mô hình MoSCoW

  • Must have (Bắt buộc): Nhận diện và gán nhãn ưu tiên (IP Precedence / DSCP), cơ chế hàng đợi ưu tiên tuyệt đối cho thoại (VoIP Bearer/RTP), chống nghẽn sớm bằng WRED cho luồng TCP.
  • Should have (Nên có): Phân mảnh gói tin lớn LFI/MLP trên các liên kết WAN tốc độ dưới 768 Kbps, giới hạn lưu lượng (CAR) cho các lớp dữ liệu không ưu tiên.
  • Could have (Có thể có): Định tuyến theo chính sách (Policy-Based Routing - PBR) để phân tách luồng thoại sang kênh truyền riêng khi cần thiết.
  • Won't have (Chưa thực hiện): Triển khai giao thức RSVP trên toàn mạng do chi phí xử lý và tài nguyên bộ nhớ trên router lõi quá lớn.

Thiết kế hệ thống

Kiến trúc QoS tổng thể cho mạng IP-177 áp dụng mô hình phân tầng DiffServ với các thành phần kỹ thuật:

[ Gói tin vào ] 
       │
       ▼
[ 1. Phân loại & Đánh dấu (Classification & Marking) ] 
       │ (ACL, IP Precedence, DSCP: EF, AF31, AF11, BE)
       ▼
[ 2. Giám sát & Điều hòa lưu lượng (CAR / Traffic Policing) ] 
       │ (Token Bucket: CIR, Bc, Be)
       ▼
[ 3. Quản lý nghẽn & Tránh nghẽn (Queuing & Dropping) ] 
       ├──> [ LLQ / Priority Queue (EF - Voice) ] ──────────┐
       ├──> [ CBWFQ Class 1 (AF31 - Video/Signaling) ] ─────┤
       ├──> [ CBWFQ Class 2 (AF11 - Critical Data) ] ───────┼──> [ WRED Engine ]
       └──> [ Best-Effort (Default Class) ] ────────────────┘
       │
       ▼
[ 4. Tối ưu hóa liên kết (LFI / Multilink PPP) ]
       │
       ▼
[ Gói tin ra Kênh truyền WAN ]

Công nghệ và phần cứng triển khai

  • Hệ điều hành mạng: Cisco IOS Software Release 12.2T / 12.4 Enterprise Plus (hỗ trợ đầy đủ MQC, DiffServ, LFI, CAR, WRED).
  • Thiết bị định tuyến: Cisco 2600 Series (2610, 2691), Cisco 3640 Series, Cisco 7206VXR làm Gateway biên và Core.
  • Chuẩn đánh dấu lưu lượng:
    • Thoại (Voice Payload - RTP): Gán IP Precedence 5 hoặc DSCP EF (Expedited Forwarding - 101110, giá trị thập phân 46).
    • Báo hiệu thoại (Signaling - SIP/H.323): Gán IP Precedence 3 hoặc DSCP AF31 (011010, giá trị thập phân 26) / CS3.
    • Dữ liệu quan trọng (Critical Data): Gán IP Precedence 2 hoặc DSCP AF21.
    • Dữ liệu Internet thông thường: Best-Effort (DSCP 0 / Precedence 0).

Phương pháp luận (Methodology)

Dự án áp dụng phương pháp tiếp cận vòng đời mạng PPDIOO (Plan, Design, Implement, Operate, Optimize):

  1. Giai đoạn 1 - Khảo sát & Đo lường: Đo lường băng thông thực tế, phân tích biểu đồ lưu lượng giờ cao điểm trên các tuyến truyền dẫn của SPT.
  2. Giai đoạn 2 - Thiết kế toán học & Giả lập: Tính toán các thông số hàng đợi, kích thước bộ đệm, thông số hàng đợi WRED (min threshold, max threshold, mark probability denominator) và độ trễ tuần tự (Serialization Delay).
  3. Giai đoạn 3 - Kiểm thử Lab (IPT Lab): Dựng mô hình mạng tương thích hạ tầng IP-177, tạo tải giả lập nghẽn mạch để đo lường độ suy hao và trễ gói.
  4. Giai đoạn 4 - Triển khai thực tế & Tối ưu: Cấu hình chính sách trên tuyến truyền dẫn HNI - HPG, giám sát liên tục bằng các công cụ đo lường chuyên dụng.

Implementation và kết quả

Quá trình phát triển và Thuật toán cốt lõi

1. Tính toán độ trễ kỹ thuật và phân mảnh gói tin

Độ trễ truyền dẫn tổng cộng của một gói tin qua mạng bao gồm: $$T_{\text{total}} = T_{\text{serialization}} + T_{\text{propagation}} + T_{\text{processing}} + T_{\text{queuing}}$$

Trong đó, độ trễ nối tiếp ($T_{\text{serialization}}$) trên liên kết tốc độ thấp là tác nhân chính gây méo tiếng thoại. Thời gian truyền một gói dữ liệu 1500 bytes trên kênh truyền 64 Kbps: $$T_{\text{serialization}} = \frac{1500 \times 8 \text{ bits}}{64000 \text{ bps}} = 0.1875 \text{ s} = 187.5 \text{ ms}$$

Mức trễ này vượt quá ngưỡng cho phép của ITU-T ($150\text{ ms}$) chỉ trên một chặng (hop). Do đó, kỹ thuật Link Fragmentation and Interleaving (LFI) qua giao thức Multilink PPP (MLP) được cấu hình để chia nhỏ gói tin dữ liệu lớn thành các đoạn nhỏ $250\text{ bytes}$ ($T_{\text{serialization}} \approx 31.25\text{ ms}$), cho phép gói tin thoại chèn vào giữa mà không phải chờ đợi.

2. Thuật toán Tránh nghẽn WRED (Weighted Random Early Detection)

WRED tính toán kích thước hàng đợi trung bình ($Avg$) theo phương pháp bình quân gia quyền số mũ (Exponential Weighted Moving Average - EWMA): $$Avg = (Avg_{\text{old}} \times (1 - 2^{-n})) + (Queue_{\text{instant}} \times 2^{-n})$$ (Trong đó $n$ là hệ số trọng số bộ đệm, thường cấu hình mặc định $n = 9$ trên Cisco IOS).

Khi $Avg$ nằm giữa $Min_{\text{th}}$ và $Max_{\text{th}}$, xác suất loại bỏ gói tin $P_d$ tăng tuyến tính: $$P_b = P_{\text{max}} \times \frac{Avg - Min_{\text{th}}}{Max_{\text{th}} - Min_{\text{th}}}$$ $$P_d = \frac{P_b}{1 - Count \times P_b}$$

/* Pseudocode mô phỏng thuật toán tính toán xác suất drop của WRED theo mức ưu tiên IP Precedence */
double calculate_wred_drop_probability(int current_queue_size, double avg_queue_size, int ip_precedence) {
    double min_th = get_min_threshold(ip_precedence); // Precedence cao -> min_th lớn hơn
    double max_th = get_max_threshold(ip_precedence);
    double max_p  = get_max_probability(ip_precedence);
    
    if (avg_queue_size < min_th) {
        return 0.0; // Không drop
    } else if (avg_queue_size >= min_th && avg_queue_size < max_th) {
        double pb = max_p * ((avg_queue_size - min_th) / (max_th - min_th));
        return pb; // Drop ngẫu nhiên theo xác suất tăng dần
    } else {
        return 1.0; // Drop toàn bộ (Tail Drop cục bộ cho class đó)
    }
}

3. Cấu hình MQC thực tế trên Cisco Router (IP-177 Core/Edge)

! 1. Cấu hình nhận diện phân lớp lưu lượng (Class-Map)
class-map match-any VOICE_TRAFFIC
 match ip precedence 5
 match ip dscp ef
!
class-map match-any SIGNALING_TRAFFIC
 match ip precedence 3
 match ip dscp af31
 match access-group name ACL_SIP_H323
!
class-map match-all CRITICAL_DATA
 match ip precedence 2
 match access-group 101

! 2. Xây dựng chính sách QoS (Policy-Map)
policy-map SPT_CONVERGED_QOS_POLICY
 class VOICE_TRAFFIC
  priority 128                       ! Dành riêng 128Kbps ưu tiên tuyệt đối (LLQ)
 class SIGNALING_TRAFFIC
  bandwidth 32                       ! Đảm bảo 32Kbps cho báo hiệu cuộc gọi
 class CRITICAL_DATA
  bandwidth percent 30               ! Đảm bảo 30% băng thông còn lại
  random-detect                      ! Kích hoạt WRED cho luồng dữ liệu quan trọng
 class class-default
  fair-queue                         ! Áp dụng Flow-based WFQ cho dữ liệu thường
  random-detect

! 3. Áp dụng chính sách lên giao tiếp WAN (Interface Configuration)
interface Multilink1
 ip address 192.168.177.1 255.255.255.252
 ppp multilink
 ppp multilink fragment delay 10     ! Kích hoạt LFI giới hạn trễ phân mảnh 10ms
 ppp multilink interleave
 service-policy output SPT_CONVERGED_QOS_POLICY

Kiểm thử và Đánh giá kết quả

Mô hình kiểm thử được thiết lập tại phòng Lab IPT của SPT mô phỏng mạng IP-177 kết nối liên tỉnh giữa Hà Nội (HNI) và Hải Phòng (HPG) qua kênh thuê riêng (Leased Line) băng thông $512\text{ Kbps}$. Tải nghẽn được tạo bằng cách bơm luồng dữ liệu TCP/FTP liên tục chiếm $120%$ dung lượng kênh kết hợp cùng 10 cuộc gọi VoIP đồng thời mã hóa theo chuẩn G.711 (64 Kbps/luồng) và G.729 (8 Kbps/luồng).

+---------------+     512 Kbps WAN Link (MLP/LFI)     +---------------+
|  Router HNI   |=====================================|  Router HPG   |
| (Cisco 3640)  |  [Tải FTP 120%] + [10 Cuộc gọi VoIP] | (Cisco 3640)  |
+---------------+                                     +---------------+

Kết quả đo kiểm thực nghiệm

Chỉ số hiệu năng (KPIs) Trước khi có QoS (FIFO) Sau khi triển khai QoS (DiffServ/LLQ) Mức độ cải thiện (%)
Độ trễ trung bình gói thoại $214.6\text{ ms}$ $34.8\text{ ms}$ Giảm $83.78%$
Độ biến thiên trễ (Jitter) $38.5\text{ ms}$ $4.2\text{ ms}$ Giảm $89.09%$
Tỷ lệ rớt gói thoại (Drop Rate) $12.4%$ $0.02%$ Giảm $99.83%$
Chỉ số chất lượng thoại (MOS) $1.8$ (Không thể nghe rõ) $4.2$ (Chất lượng xuất sắc) Tăng $133.33%$
Thông lượng truyền file TCP Bị đứt quãng do mất gói Duy trì ổn định ở $320\text{ Kbps}$ Hoạt động trơn tru

Đổi mới và đóng góp

  1. Ứng dụng giải pháp tích hợp đa công cụ (Multi-tool QoS Convergence): Không dựa vào một cơ chế đơn lẻ, đề tài đã phối hợp đồng bộ 5 kỹ thuật: CAR (giám sát biên) + DiffServ Marking (đánh dấu) + LLQ/CBWFQ (lập lịch) + WRED (tránh nghẽn TCP) + LFI (xóa bỏ trễ nối tiếp).
  2. Khắc phục triệt để hiện tượng trễ chèn ép trên băng thông hẹp: Bằng việc triển khai LFI qua Multilink PPP trên router Cisco, đề tài đã triệt tiêu hiện tượng gói dữ liệu 1500 bytes "chặn đầu" gói thoại nhỏ, đưa trễ hàng đợi từ mức hàng trăm mili-giây về dưới ngưỡng $10\text{ ms}$.
  3. Mô hình hóa chính sách phù hợp hạ tầng thực tế SPT IP-177: Cung cấp bảng tham chiếu phân bổ băng thông chi tiết và hệ số WRED tối ưu hóa riêng cho các dòng thiết bị Cisco 2600/3600, giải quyết bài toán kinh tế mà không cần đầu tư nâng cấp đường truyền vật lý đắt đỏ.

Ứng dụng thực tế và triển khai

Tình huống ứng dụng thực tế

Giải pháp được thiết kế trực tiếp để ứng dụng cho mạng đường trục và mạng phân phối dịch vụ IP-177 của SPT. Hệ thống đáp ứng việc tích hợp các dịch vụ:

  • Dịch vụ gọi điện thoại quốc tế và liên tỉnh VoIP 177.
  • Kênh truyền số liệu thuê riêng (Leased-line Data) cho doanh nghiệp.
  • Mạng truyền hình hội nghị đa điểm và dịch vụ Internet băng rộng.
+-----------------------------------------------------------------------------------+
|                        LỘ TRÌNH TRIỂN KHAI MẠNG IP-177                            |
|                                                                                   |
|  [Tuần 1-2]         [Tuần 3-4]           [Tuần 5-6]            [Tuần 7-8]         |
|  Khảo sát lưu       Cấu hình MQC Lab     Triển khai Node biên  Đo kiểm tối ưu     |
|  lượng hiện trạng   & Đo kiểm Stress     HNI - HPG thực tế     & Bàn giao SOP     |
+-----------------------------------------------------------------------------------+

Phân tích hiệu quả kinh tế (Cost-Benefit & ROI)

  • Chi phí đầu tư phần cứng mới: $0\text{ VNĐ}$ (Tận dụng toàn bộ các router Cisco hiện hữu thông qua việc cấu hình lại hệ điều hành Cisco IOS).
  • Chi phí thuê băng thông WAN: Tiết kiệm ước tính $35 - 45%$ chi phí thuê thêm kênh Leased-line hàng tháng nhờ khả năng nén, tối ưu hóa và dùng chung hạ tầng thoại/dữ liệu.
  • Thời gian hoàn vốn (ROI): Đạt được ngay sau khi hệ thống đưa vào vận hành thực tế nhờ giảm thiểu khiếu nại khách hàng và tận dụng tối đa $95%$ công suất kênh truyền sẵn có mà không gây nghẽn thoại.

Hạn chế và hướng phát triển

Hạn chế kỹ thuật

  • Tải xử lý CPU trên Router đời cũ: Việc kích hoạt đồng thời WRED, CAR và LFI trên các dòng Router thế hệ cũ như Cisco 2600 có thể làm tải CPU tăng thêm $15 - 20%$ trong các đợt cao điểm nghẽn.
  • Giới hạn của mô hình DiffServ: DiffServ chỉ đảm bảo chất lượng theo từng chặng (Per-Hop Behavior - PHB), chưa cung cấp cơ chế cam kết tài nguyên cứng xuyên suốt từ đầu cuối tới đầu cuối (End-to-End Hard QoS) như IntServ/RSVP.

Hướng phát triển trong tương lai

  • Nghiên cứu tích hợp cơ chế MPLS DiffServ-TE (Traffic Engineering) trên mạng lõi truyền dẫn thế hệ mới.
  • Chuyển đổi và ánh xạ các nhãn IP Precedence/DSCP sang trường Traffic Class trong giao thức IPv6 và trường EXP trong mạng MPLS.
  • Tự động hóa việc phân tích và điều chỉnh tham số QoS linh hoạt theo thời gian thực sử dụng các kỹ thuật mạng điều khiển bằng phần mềm (Software-Defined Networking - SDN).

Đối tượng hưởng lợi

  • Sinh viên và Học viên Cao học: Tài liệu tham khảo thực nghiệm chất lượng cao với đầy đủ công thức toán học, mô hình lý thuyết hàng đợi và cấu hình Cisco IOS mẫu.
  • Kỹ sư Quản trị mạng viễn thông: Cung cấp hướng dẫn từng bước (Step-by-step Standard Operating Procedure) để khắc phục các sự cố về Jitter, Trễ và Mất gói trong hệ thống mạng doanh nghiệp/ISP.
  • Doanh nghiệp và Nhà cung cấp dịch vụ (ISPs): Chiến lược tối ưu hóa chi phí hạ tầng, nâng cao chỉ số hài lòng của khách hàng (CSAT) đối với dịch vụ VoIP và Data.
  • Nhà nghiên cứu: Cơ sở dữ liệu kiểm thử thực tế về hành vi của thuật toán WRED và hàng đợi CBWFQ trên liên kết mạng tốc độ thấp.

Câu hỏi thường gặp

1. Yêu cầu kỹ thuật tối thiểu để triển khai giải pháp QoS này là gì?

Hệ thống mạng cần trang bị các thiết bị định tuyến Cisco hỗ trợ tối thiểu hệ điều hành Cisco IOS Release 12.2T trở lên với gói tính năng IP Plus hoặc Enterprise Plus để đảm bảo hỗ trợ đầy đủ kiến trúc MQC, thuật toán WRED và kỹ thuật LFI.

2. Sự khác nhau căn bản giữa Traffic Policing (CAR) và Traffic Shaping (GTS) là gì?

CAR (Policing) kiểm soát tốc độ bằng cách loại bỏ (drop) hoặc đánh dấu lại (remark) các gói tin vượt ngưỡng cam kết ngay lập tức, không gây trễ nhưng làm mất gói. Ngược lại, GTS (Shaping) lưu các gói vượt ngưỡng vào bộ đệm để truyền đi sau, giúp làm phẳng luồng lưu lượng nhưng sẽ làm tăng độ trễ hàng đợi.

3. Tại sao không sử dụng IntServ/RSVP thay vì DiffServ trong mạng IP-177?

IntServ/RSVP yêu cầu tất cả các router trên toàn tuyến phải duy trì trạng thái luồng (stateful) và liên tục gửi bản tin báo hiệu dự trữ tài nguyên. Khi số lượng phiên liên lạc tăng cao, router lõi sẽ bị quá tải bộ nhớ và CPU. DiffServ phân loại gói tin tại biên và xử lý không trạng thái (stateless) tại lõi, mang lại khả năng mở rộng (scalability) vượt trội.

4. Kỹ thuật LFI có làm ảnh hưởng đến tốc độ truyền file hay không?

LFI phân mảnh các gói dữ liệu lớn nên sẽ tạo ra một lượng nhỏ overhead của tiêu đề gói tin (khoảng $2-4%$). Tuy nhiên, sự đánh đổi này là hoàn toàn xứng đáng vì nó triệt tiêu được độ trễ nối tiếp nguy hại đối với luồng thoại thời gian thực.

5. Làm thế nào để giám sát các chính sách QoS đã cấu hình trên router?

Quản trị viên sử dụng các lệnh chuẩn của Cisco IOS như show policy-map interface <interface-name> để xem chi tiết số lượng gói tin được phân lớp, số byte được xử lý, trạng thái hàng đợi và thống kê số gói bị loại bỏ bởi thuật toán WRED theo thời gian thực.

Kết luận

Đề tài "QoS trong mạng tổ hợp Thoại và Dữ liệu" đã giải quyết triệt để bài toán xung đột tài nguyên mạng trên hạ tầng tích hợp IP-177 của Saigon Postel. Bằng việc kết hợp nhuần nhuyễn các công cụ QoS nâng cao của Cisco IOS—bao gồm phân loại lưu lượng DiffServ, lập lịch ưu tiên LLQ/CBWFQ, tránh nghẽn sớm WRED và phân mảnh chống trễ LFI—hệ thống đã xuất sắc hạ độ trễ thoại xuống dưới $35\text{ ms}$, khống chế Jitter dưới $5\text{ ms}$ và tỷ lệ mất gói gần như bằng 0. Đây là minh chứng rõ ràng cho thấy việc áp dụng đúng đắn các giải pháp kỹ thuật phần mềm có thể tối ưu hóa hoàn toàn hiệu năng mạng, mang lại giá trị kinh tế to lớn và nâng tầm chất lượng dịch vụ viễn thông hiện đại.