Class-Based Weighted Fair Queuing (CBWFQ) là kĩ thuật hàng đợi ra đời sau WFQ, nó giống với WFQ ở chỗ: Cho phép sử dụng WFQ ngay bên trong một hàng đợi của nó, nhưng khác với WFQ ở chỗ: CBWFQ sử dụng Class để phân loại còn WFQ sử dụng flow.

CBWFQ có thể cấu hình băng thông thực sự cho một hàng đợi.

Hình 1: Tiến trình gởi gói tin của CBWFQ

Từ trái sang phải:

1.CBWFQ phân loại gói tin bằng ACLs, MPLS EXP, Port….

2.Quyết định drop gói tin bằng các kĩ thuật Tail drop hoặc WRED

3.Số hàng đợi tối đa là 64 và chiều dài hàng đợi tối đa là 64, các giá trị này là mặc định ta có thể set tùy theo ý muốn.

4.Bên trong mỗi hàng đợi ta có thể dùng FIFO hoặc WFQ.

Chú ý: WRED là kĩ thuật hàng đợi dùng để chống nghẽn, nó tốt cho một số loại dữ liệu nhưng cũng không tốt cho các dữ liệu như Voice hay Video vì các dữ liệu này cần không bị rớt trong mọi trường hợp.

CBWFQ vượt trội hơn các hàng đợi WFQ ở chỗ: Nó phân loại gói tin theo Class chứ không theo flow, như vậy dễ dàng cho ta thiết kế hơn.

  Định nghĩa và giới hạn băng thông trong cơ chế CBWFQ

            Cisco IOS kiểm tra một chính sách CBWFQ để đảm bảo rằng nó không cấp quá nhiều băng thông. IOS bắt đầu thực hiện việc kiểm tra ngay khi câu lệnh service-policy output được nhập vào. Nếu chính sách policy map định nghĩa quá nhiều băng thông cho cổng đó, lệnh service policy sẽ bị từ chối. IOS định nghĩa băng thông cho phép dựa trên hai lệnh: lệnh bandwidth và lệnh max-reserved-bandwidth (viết tắt là int-bw và max-res). Các phần băng thông còn lại là dành cho các lưu lượng của hệ thống như các hàng đợi của hệ thống (system queue). Nói cách khác, với giá trị max-res bằng 75 (75%) trên một cổng có băng thông là int-bw 256, một policy map có thể cấp đến 192 kbps với các lệnh băng thông của nó.

Hình 2.14: Hàng đợi cân bằng có trọng số dựa lớp - Class-based Weight Fair Queueing.

            Ví dụ dưới đây mô tả một chính sách trong đó có một nhóm lưu lượng được cấp đến 64 kbps băng thông. Lệnh service-policy bị IOS từ chối trên những IOS có băng thông gán bằng 64kbps. Giá trị max-res được gán mặc định bằng 75, vì vậy chỉ có 75% của 64kbps tức là 48 kbps là có sẵn. Chú ý rằng giá trị 48 kbps được đề cập trong thông điệp lỗi.

R3(config-cmap)# policy-map explicit-bw

R3(config-pmap)# class class1

R3(config-pmap-c)# bandwidth 64

R3(config-pmap-c)# int s0/1

R3(config-if)# bandwidth 64

R3(config-if)# service-policy output explicit-bw

I/f Serial0/1 class class1 requested bandwidth 64 (kbps), available only 48 (kbps).

 Các lệnh tham khảo cho CBWFQ

 Lệnh, Chế độ lệnh và chức năng của lệnh:

Bandwidth {bandwidth bandwidth| percent percent}

-          Lệnh này nằm bên trong class;

Gán tỉ lệ phần trăm băng thông cho nhóm.

bandwidth {remaining percent percent}

-         Lệnh bên trong class, gán tỉ lệ phần trăm còn lại cho nhóm.

Queue-limit limit

-         Lệnh này trong cấu hình class. Chỉ ra chiều dài tối đa của hàng đợi CBWFQ.

fair-queue [queue-limit queuevalue]

-          Lệnh này trong cấu hình class, bật WFQ trên class mặc định

max-reserved-bandwidth percent

-         Lệnh này ở chế độ cổng. Định nghĩa tỉ lệ % băng thông có thể dùng để dùng cho CBWFQ, chưa kể đến hàng đợi mặc định.

            Dưới đây là một cấu hình CBWFQ đơn giản dùng hàng đợi WFQ cho class-default. Cấu hình được tạo ra trên R3 dùng các yêu cầu sau:

- Tất cả các gói VoIP sẽ được đặt trên một hàng đợi.

- Tất cả các loại lưu lượng khác sẽ đặt trong hàng đợi khác.

- VoIP sẽ có 50% băng thông.

- WFQ sẽ dùng cho những lưu lượng không phải là VoIP.

Lệnh class map sẽ lựa ra các gói tin UDP/RTP và các cổng RTP.

class-map match-all voip-rtp

match ip rtp 16384 16383

            Kế tiếp, lệnh policy-map dùng lệnh băng thông bandwidth để giữ 64Kbps cho lớp lưu lượng voip-rtp này. Lớp mặc định sẽ nhận một vài phần băng thông còn lại.

policy-map queue-voip

class voip-rtp

bandwidth 64

class class-default

fair-queue

            Lệnh bandwidth 128 cấu hình ở cổng được dùng như mức cơ bản cho giới hạn tổng số băng thông có thể được cấp phát trong chính sách policy map queue-voip. Lệnh load-interval sẽ gán các bộ đếm được cập nhật như thế nào. Ngoài ra, chú ý rằng lệnh policy map được áp dụng cho lưu lượng theo chiều ra, lưu lượng theo chiều vào không được áp dụng chính sách này.

interface Serial0/0

encapsulation frame-relay

load-interval 30

bandwidth 128

service-policy output queue-voip

            Lệnh dưới đây liệt kê các thống kê, phần băng thông dành riêng, kích thước tối đa của hàng đợi (chỉ ra như max threshold) và một lưu ý WFQ được dùng trong hàng đợi lớp mặc định.

R3# show policy-map int s 0/0

Read More →

WFQ là kĩ thuật hàng đợi mặc định trong router Cisco, nó khác với các hàng đợi PQ và FIFO ở các điểm sau:

+ Nó không cho phép cấu hình phân loại, WFQ phân loại gói tin theo flow, một flow bao gồm nhiều gói tin có cùng đích đến và cùng nguồn, cùng port đích và port nguồn. Sẽ không có cấu hình nào rõ rang cho nó.

+ Tính năng lập lịch: WFQ dựa vào flow, do vậy những flow nào có độ ưu tiên cao hơn thì sẽ được phát trước.

+ Mỗi flow là một hàng đợi, vì vậy số hàng đợi trong WFQ có thể lên tới 4096 hàng đợi lớn hơn rất nhiều so với PQ hay FIFO.

Với WFQ ta có tối đa là 4096 hàng đợi trong 1 interface của router, số hàng đợi này cũng chính là số flow chảy vào router. Ví dụ: ta có 5 flow là Voice, 2 kết nối HTTP, 2 kết nối FTP thì khi đó ta sẽ có 5 hàng đợi trong router, như vậy số hàng đợi thay đổi theo số flow, chúng không cố định như trong các kĩ thuật khác

        

Hình 1: Cách lấy gói tin của WFQ

Hoạt động của WFQ như sau:

   

Hình 2: Tiến trình gởi gói tin của WFQ

+Khi gói tin vào interface, nó sẽ được phân loại thành các flow theo 5 thông số:

      - IP source

      - IP destination

      - port source

      - port destination

      - Giao thức lớp 4 nó sử dụng là gì (TCP hay UDP)

WFQ dựa vào các trường như DSCP, ToS để phân loại gói tin và đưa nó vào các hàng đợi khác nhau. Những gói tin có IP precedent hay DSCP cao hơn sẽ có mức ưu tiên cao hơn.

Hai vấn đề quan trọng trong WFQ :

a.                Đối xử công bằng với tất cả các flow đang tồn tại : Giả sử ta có băng thông là 128 kbps và có 10 hàng đợi đang tồn tại, mỗi hàng đợi sẽ nhận được băng thông là 12.8 kbps. Nều số hàng đợi là 100 thì mỗi hàng đợi sẽ nhận băng thông là 1.28 kbps. Một vấn đề tồn tại ở đây là sự quá công bằng của WFQ, giả sử trong số 10 hàng đợi trên hàng đợi thứ 1 cần băng thông là 5 kbps và hàng đợi thứ 2 cần băng thông là 30 kbps, nhưng vì WFQ chỉ cấp băng thông cho mỗi hàng đợi là 12.8 kbps, như vậy hàng đợi thứ 1 dư băng thông nó sẽ luôn được phục vụ tốt nhất, nghĩa là low delay, low jitter, low loss vì số gói tin trong hàng đợi của nó lúc nào cùng rất ít. Với hàng đợi thứ 2 thiếu băng thông vì vậy delay, jitter và loss của nó sẽ rất lớn.

b.                Cung cấp thêm băng thông cho những flow có mức ưu tiên cao hơn (higher IP precedent hay higher DSCP) : Vẫn với giả sử trên 128 kbps cho 10 flow. Bây giờ giả sử có 5 flow với IP precedent bằng 0, và 5 flow với IP precedent bằng 1, 5 flow IP precedent 1 có mức ưu tiên cao hơn 5 flow IP precedent 0 theo đó tỉ số băng thông phân phối là 2:1, flow IP precedent 1 sẽ nhận băng thông là 17 kbps gấp đôi flow IP precedent 0 là 8.5 kbps, cách tính tỉ số này như sau:

                               ( BW cho IP Precedence 1 / BW cho IP Precedence 0) = (1+1) / (1+0) = 2 / 1        

  + Sau khi được phân loại gói tin sẽ được tính giá trị SN (Sequence number) như sau:

SN = SN (trước đó) + Weight*length

SN : Sequence number

Weight : trọng số của gói tin , Weight=32384 / (IP_Precedence+1)

Length : Chiều dài gói tin

Bảng giá trị của Weight:

Hình 3: Bảng giá trị Weight

Ví dụ: Với gói tin có SN trước đó là 0, chiều dài là 1500 byte và precedent là 0 ta sẽ tính SN như sau:

                              SN = 0 + 1500*32384 = 48576000

-      Sau đó quyết định có drop gói tin hay không dựa vào 2 thông số (còn gọi là Tail drop):

-      Hold-queue: Nếu gói tin là này là gói mà làm vượt mức hold-queue (tổng số gói tin trong tất cả các hàng đơi) thì nó sẽ bị drop.

-      CDT: (Congestion discard threshold) là số gói tin tối đa trong một hàng đợi, giá trị này có thể cấu hình cho phép từ 1 đến 4096.

+ Tiếp theo các gói tin nếu không bị drop sẽ đưa vào hàng đợi và chờ phát đi

+ Khi nằm trong hàng đợi các gói tin sẽ được lập lịch (scheduler logic), quá trình lập lịch dựa vào SN của gói tin, precedent và volume (Số gói tin đang có trong một hàng đợi).

-      Những gói tin có SN càng nhỏ, precedent càng lớn, và volume càng nhỏ sẽ được chọn forward trước.

-      Thứ tự ưu tiên như sau: Đầu tiên là SN, sau đó là precedent, và cuối cùng là volume.

       

Hình 4: Tính toán SN

Ví dụ:

Ta có 4 hàng đợi là flow 1, flow 2, flow 3, flow 4, với kích thức mỗi gói tin là 1500 byte, 1000 byte, 500 byte, 100 byte. Mỗi hàng đợi có 4 gói tin với precedent là 0, giả sử SN trước đó của các gói tin là 0, như vậy ta tính được các giá trị SN như hình sau:

Hình 5: Thứ tự gởi gói tin

Khi đó thứ tự forward gói tin là: 13, 5, 14, 15, 6, 1, 16, 7, 9, 2, 8, 3, 4, 11, 12.

Read More →