Để bảo đảm các luồng lưu lượng của các ứng dụng khác được cư xử đúng mực và bảo đảm theo SLA giữa khách hàng với nhà cung cấp dịch vụ thì nhà cung cấp dịch vụ phải quan tâm đến các yêu cầu tối thiểu của các ứng dụng đó về băng thông, độ trễ, jitter và tỷ lệ mất gói khi chúng được thực thi trên mạng, đặc biệt là các ứng dụng thời gian thực như Voice, Video…
2.1. Lưu lượng thoại (Voice Traffic)
Một gói tin thoại bao gồm các thành phần như: Voice payload, tiêu đề giao thức truyền thời gian thực RTP, tiêu đề giao thức UDP, tiêu đề IP, và tiêu đề giao thức tầng 2 của mô hình TCP/IP.
Trong mỗi trường thoại IP của Cisco, có hai kiểu mã hóa được sử dụng phổ biên là G.711 và G.729. Bảng 6-2 dưới đây là các tùy chọn cách mã hóa payload của thoại tương ứng với băng thông và số lượng gói tin được truyền qua trong một giây. Bảng phụ lục 2: Bảng tùy chọn cách mã hóa payload và băng thông yêu cầu tương ứng.
79 Mã hóa Tốc độ lấy mẫu Voice Payload Số gói tin/giây
Tổng băng thông cho một cuộc gọi
G.711 20 ms 160 bytes 50 pps 80 kbps
G.711 30 ms 240 bytes 33 pps 74 kbps
G.729 20 ms 20 bytes 50 pps 24 kbps
G.729 30 ms 30 bytes 33 pps 19 kbps
Bảng phụ lục 3: Bảng yêu cầu các tham số QoS để bảo đảm lưu lượng Voice
Độ trễ Nhỏ hơn hoặc bằng 150 ms
Jitter Nhỏ hơn hoặc bằng 30 ms
Tỷ lệ mất gói Nhỏ hơn 1%
Các ứng dụng thoại không chấp nhận độ trễ và vấn đề tắc nghẽn trên mạng. Để hạn chế độ trễ, jitter, và mất gói, lưu lượng thoại phải luôn luôn được đưa vào hàng đợi ưu tiên, có thể sử dụng hàng đợi LLQ bất kỳ lúc nào có thể được.
2.2. Lưu lượng Video
Nếu các gói tin Video bị mất hoặc bị trễ hoặc jitter quá nhiều thì video có thể bị mất hình hoặc giật video. Vì vậy các tham số như độ trễ, jitter, tỷ lệ mất gói phải đặc biệt quan tâm, đặc biệt là băng thông.
Bảng phụ lục 4: Bảng yêu cầu các tham số QoS để bảo đảm lưu lượng Video
Độ trễ Nhỏ hơn hoặc bằng 150 ms
Jitter Nhỏ hơn hoặc bằng 30 ms
Tỷ lệ mất gói Nhỏ hơn 1 %
Băng thông giao động (Bandwidth Fluctuation) 20 %
Các ứng dụng thoại không chấp nhận độ trễ và vấn đề tắc nghẽn trên mạng. Để hạn chế độ trễ, jitter, và mất gói, lưu lượng thoại phải luôn luôn được đưa vào hàng đợi ưu tiên, có thể sử dụng hàng đợi LLQ bất kỳ lúc nào có thể được.
2.3. Lưu lượng dữ liệu
Các ứng dụng dữ liệu có thể tách ra không quá 4 hoặc 5 lớp lưu lượng khác nhau, mỗi lớp bao gồm các ứng dụng dữ liệu yêu cầu QoS như nhau. Các lớp này bao gồm:
80 Các ứng dụng quan trọng (Mission – critical applications). Các ứng dụng này được xác định như là các ứng dụng lõi trong việc kinh doanh dựa trên chức năng thực tế và tính hiệu quả. Các ứng dụng này cần rất nhiều băng thông bởi vì chúng sử dụng giao thức TCP, và chúng không nhạy cảm với độ trễ, jitter, và mất gói. Các ứng dụng này có thể giới hạn trong 3 lớp hoặc thấp hơn, sẽ nhận được tối thiểu (least) 50% băng thông còn lại sau khi hàng đợi LLQ được phục vụ ưu tiên lưu lượng.
Các ứng dụng giao dịch (Transactional applications). Các ứng dụng này là các ứng dụng Client/Server hỗ trợ chính trong việc kinh doanh. Như các ứng dụng hoạch định tài nguyên doanh nghiệp ERP (Enterprise Resource Planning) ví dụ như SAP hoặc Oracle. Các ứng dụng này nhạy cảm với độ trễ và mất gói. Các ứng dụng này có thể giới hạn trong 3 lớp hoặc thấp hơn, sẽ nhận được tối thiểu (least) 20% băng thông còn lại sau khi hàng đợi LLQ được phục vụ ưu tiên lưu lượng.
Các ứng dụng nỗ lực tối đa (Best Effort Applications). Hầu hết các ứng dụng ở dụng lớp này. Bao gồm các ứng dụng như: E-mail, HTTP, và FTP. Các ứng dụng này sẽ nhận được tối thiểu (least) 25% băng thông còn lại sau khi hàng đợi LLQ được phục vụ ưu tiên lưu lượng.
Các ứng dụng khác thấp hơn các ứng dụng nỗ lực tối đa. Các ứng dụng loại này có thể bao gồm các ứng dụng tương tự như chương trình chia sẻ file ngang hàng Kazaa (peer-to-peer file-sharing program Kazaa). Các ứng dụng này có thể nhận không quá 5% băng thông còn lại sau khi hàng đợi LLQ được phục vụ ưu tiên lưu lượng.
Sau khi chúng ta đã phân ranh giới của các ứng dụng trong mạng và xác định các lớp cần thiết để cung cấp các mức dịch vụ yêu cầu, một điều quan trọng tiếp theo là nhóm các ứng dụng với các yêu cầu phổ biến vào cùng lớp. Ví dụ, chúng ta không thể nhóm một ứng dụng FTP (lưu lượng bùng nổ và cần nhiều băng thông) và một ứng dụng giao dịch (nhạy cảm với độ trễ, mất gói và thời gian của phiên giao dịch) vào cùng nhóm.
81 Voice Video Mission-Critical/ Transactional Data Bulk Data/ Best-Effort Data Băng thông yêu cầu
(Bandwidth Requirements ) Thấp đến vừa (Low to Moderate) Vừa (Moderate)
Thấp đến vừa Vừa đến cao
Nhạy cảm với mất gói (Drop Sensitivity)
Cao Cao Thấp đến cao Thấp
Nhạy cảm với độ trễ (Delay Sensitivity)
Cao Cao Thấp đến vừa Thấp
Nhạy cảm với Jitter (Jitter Sensitivity)
High High Thấp đến vừa Thấp
Bình thường hoặc bùng nổ (Smooth or Bursty) Bình thường (Smooth) Bùng nổ (Bursty) Cả 2 Cả 2
Ôn hòa hoặc tham lam Ôn hòa
(Benign)
Tham lam (Greedy)
Cả 2 Cả 2