Tóm tắt Luận án Nghiên cứu cải thiện diffserv QoS trong mạng IP

- 1 -

TẬP ĐOÀN BƯU CHÍNH VIỄN THÔNG

VIỆT NAM

HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH

VIỄN THÔNG

NGUYỄN HỒNG SƠN

Nghiên cứu cải thiện DIFFSERV QoS trong

mạng IP

Tóm tắt Luận án TS Kỹ thuật: Kỹ thuật Viễn

thông

Mã số chuyên ngành 62 52 70.05

Người hướng dẫn: PGS.TS Lê Hữu Lập, TS Vũ

Như Lân

Hà Nội, 2010

- 2 -

- 35 -

khiển chấp nhận nối gần giống như môi trường mạng

theo chế độ có kết nối.

A. MỞ ĐẦU

Ngày nay, mạng IP có vai trò thiết yếu trong lĩnh

vực truyền thông. Sự phát triển nhanh chóng của

Internet đã làm cho mạng IP trở thành giao thức

không thể thiếu và ngày càng quan trọng hơn. Trong

khi đó, các nhu cầu về dịch vụ không còn đơn điệu

như trước và trên thực tế các ứng dụng đòi hỏi QoS

xuất hiện ngày càng nhiều. Bối cảnh này đã đặt ra cho

mạng IP nhiều thách thức mới, đòi hỏi mạng IP phải

có các cơ chế QoS hoàn chỉnh để đáp ứng nhu cầu đa

dịch vụ đang gia tăng.

Trong cố gắng đầu tiên tăng cường khả năng QoS

cho mạng IP, tổ chức IETF đã đưa ra cơ chế

Integrated Services (IntServ). Nhưng IntServ sớm tỏ

ra phức tạp, không có tính khả triển (scalability) nên

Differentiated Services (DiffServ) được IETF đề xuất

như là cơ chế thay thế IntServ. Về lý thuyết DiffServ

là kiến trúc QoS quan trọng cho mạng IP, là cơ sở

QoS trong IPv6 và có khả năng phối hợp với MPLS

- 34 -

- 3 -

0,03 trong khi chạy DiffServ không dùng CAC

với cùng điều kiện tải có xác suất mất gói trung

bình khoảng 0,35 (chỉ mô phỏng độc lập tại tầng

mạng, không kết hợp cơ chế hỗ trợ ở tầng giao

vận như cơ chế điều khiển cửa sổ của TCP). Hiệu

suất sử dụng liên kết cũng khá cao, đạt 90% với

xác suất mất gói xấp xỉ 10^-4.

tạo ra cơ chế QoS mạnh. Tuy nhiên, trên thực tế các

triển khai DiffServ vẫn chưa đầy đủ các lớp dịch vụ

như đặc tả, từ đó việc cung cấp QoS trên mạng IP

chưa được phổ biến, phần lớn các phiên truyền thông

hiện nay đều phải chạy với mức best-effort. Thiết nghĩ

cải thiện IP QoS trước hết phải cải thiện DiffServ, vì

vậy cần phải tìm ra nguyên nhân khiến DiffServ có

những yếu kém thực tế và đề ra giải pháp để khắc

phục.

2. Kiến nghị hướng phát triển

Vấn đề thực hiện QoS cho mạng IP là bài toán lớn,

đòi hỏi sự phối hợp giải quyết từ nhiều giải pháp khác

nhau. Hai giải pháp được đề xuất ở đây cần được tiếp

tục nghiên cứu phát triển.

Có nhiều nguyên nhân, ở đây có thể nêu ra hai

nguyên nhân nổi trội. Nguyên nhân thứ nhất thuộc về

phương pháp hiện thực DiffServ hiện nay; theo gợi ý

của IETF, tất cả các hiện thực DiffServ đều dùng thuật

toán quản lý hàng đợi tích cực RED để tạo các lớp

dịch vụ khác biệt, nhưng các nghiên cứu cho thấy

cách dùng RED có khó khăn. Bản thân RED không

phải là cơ chế điều khiển nghẽn chính quy, không hỗ

trợ chia sẻ tài nguyên và đặc biệt rất khó chọn lựa các

tham số hoạt động cho nó mà không ảnh hưởng xấu

đến phẩm chất của mạng. Nguyên nhân thứ hai là

DiffServ của IETF không cung cấp cơ chế end-to-end

QoS và không có phương pháp điều khiển các lớp

QoS giữa các nhà điều hành mạng khác nhau. Thực tế,

ứng dụng của người dùng không có cách gì để yêu cầu

một lớp dịch vụ đặc biệt vì không có điều khiển chấp

nhận kết nối (Connection Admission Control). Thiếu

Đối với giải pháp thực hiện AFij dựa vào CQM

cần nghiên cứu thiết kế module điều khiển thích hợp,

chú trọng thời gian tác động của bộ điều khiển nếu

thực hiện bằng phần cứng theo lý thuyết điều khiển

truyền thống. Nếu thực hiện bằng phần mềm cần đánh

giá độ phức tạp của thuật toán CQM bao hàm thuật

toán token bucket động.

Đối với giải pháp điều khiển chấp nhận kết nối thì

trước hết cần tiếp tục nghiên cứu mở rộng cho trường

hợp liên domain. Kế đến là lý thuyết hóa đăng ký và

giải phóng tài nguyên không tường minh trong mạng

theo chế độ connectionless, từ đó xây dựng mô hình

định lượng hợp lý làm cơ sở áp dụng các thủ tục điều

- 4 -

- 33 -

điều khiển chấp nhận nối sẽ khó ngăn chặn tình trạng

quá tải khiến cho khả năng cung cấp QoS không đảm

bảo.

Kết quả là hàng đợi được duy trì với độ dài ổn

định, bộ đệm không bị tràn. Có thể thay đổi độ dài

ổn định của hàng đợi bằng cách thay đổi giá trị

tham chiếu q_refcủa bộ điều khiển. Muốn sử dụng

hết kích thước bộ đệm chỉ cần điều chỉnh q_ref.

2.Áp dụng cơ chế quản lý hàng đợi CQM thực hiện

các lớp dịch vụ AF (AF_ij) cho mạng DiffServ.

Trong đó, cấu hình giá trị tham chiếu qref khác

nhau cho các bộ điều khiển khác nhau để tạo ra

các lớp dịch vụ khác biệt AF_ijtrong mỗi DiffServ

router. Kết quả là tạo ra được các dịch vụ khác

biệt một cách dễ dàng như dự kiến, điều chỉnh

được một cách linh động. Bộ đệm ngõ ra được sử

dụng với một mức ổn định theo cấu hình, không

xảy ra hiện tượng nghẽn. Tài nguyên được sử

dụng hiệu quả vì khi một lớp dịch vụ ở trạng thái

không tải, tài nguyên đang giữ bị thu hồi để cấp

cho lớp dịch vụ khác đang cần.

Từ khảo sát phân tích trên đây, Nghiên cứu sinh

nhận thức rằng DiffServ là cơ chế QoS quan trọng

hàng đầu của mạng IP nên mục đích, đối tượng và

phạm vi nghiên cứu trong luận án như sau:

Mục đích nghiên cứu

Làm sáng tỏ hiện trạng và xu thế của IP QoS.

Tìm nguyên nhân của các hạn chế về thực hiện IP

QoS theo kiến trúc DiffServ hiện nay. Đề xuất giải

pháp nhằm cải thiện DiffServ trên phương diện thực

hiện và cơ chế hoạt động, với hai mục tiêu chủ yếu là :

Đề xuất giải pháp thuận lợi hiệu quả để thực hiện các

lớp dịch vụ con AFij và đề xuất cơ chế điều khiển

chấp nhận kết nối (CAC) cho DiffServ domain.

Đối tượng và phạm vi nghiên cứu

Nghiên cứu kiến trúc DiffServ QoS và DiffServ

domain. Tập trung vào hướng triển khai DiffServ

domain, thực hiện các lớp dịch vụ tại các DiffServ

router và cơ chế đảm bảo end-to-end QoS.

3.Đề xuất giải pháp CAC theo hướng phân tán cho

DiffServ domain, gồm tập tiêu chuẩn quyết định

cục bộ có bổ sung ràng buộc trên số luồng nhằm

khắc phục mâu thuẩn cơ bản giữa đặc tính kết nối

và không kết nối, và cơ chế báo hiệu kết nối

không tường minh phù hợp với tiêu chuẩn quyết

định cục bộ này để cộng tác thực thi thủ tục CAC.

Kết quả là xác suất mất gói thấp, chỉ khoảng dưới

Phương pháp nghiên cứu

Với định hướng nghiên cứu ứng dụng, công việc

thực hiện luận án bước đầu gồm thu thập tài liệu, thực

nghiệm trên các thiết bị và hệ thống. Kế tiếp là khảo

sát các giải pháp thực hiện DiffServ trên thực tế,

- 32 -

- 5 -

nghiên cứu các đề xuất cải tiến điển hình. Trên cơ sở

đó xây dựng các giải pháp mới dùng công cụ toán học

và mô phỏng máy tính để kiểm chứng, đúc kết nguyên

lý áp dụng và tham gia hội thảo.

Kết quả chính của luận án :

+ Đã làm rõ hiện trạng và xu thế cũng như cách

thức thực hiện một hạ tầng QoS cho mạng IP theo

kiến trúc DiffServ. Thiết nghĩ, trong điều kiện công

nghệ chế tạo thiết bị mạng của nước ta còn chưa phát

triển thì việc tìm hiểu để nắm bắt cách thức thực hiện

các giải pháp cụ thể trên thiết bị là bước tiếp cận ban

đầu hợp lý.

Hình 3.25 Đồ thị tương quan giữa xác suất mất gói

và hiệu suất.

Bảng 3.4 Các tham số của nguồn 2 (Expo2)

+ Đã đưa ra giải pháp thực hiện DiffServ mới.

Trong đó, đã thiết kế cơ chế quản lý hàng đợi CQM

dùng token bucket kết hợp với bộ điều khiển. Vận

dụng CQM thực hiện được các lớp dịch vụ trong AF

PHB một cách dễ dàng cùng với khả năng kiểm soát

nghẽn chính qui hơn so với cơ chế dùng thuật toán

RED, cách thực hiện này cũng tạo điều kiện để các

lớp dịch vụ chia sẻ tài nguyên với nhau.

Tham số

Giá trị

Packet size 125 bytes

Burst time

Idle time

Data rate

400 ms

325 ms

64 kbps

C. KẾT LUẬN VÀ KIẾN NGHỊ

1. Kết luận

Luận án “Nghiên cứu cải thiện DiffServ QoS trong

mạng IP” có các kết quả :

+ Đã phát triển phương pháp điều khiển chấp

nhận kết nối cho DiffServ domain. Trong đó, đề xuất

ý tưởng báo hiệu không tường minh, xây dựng tiêu

chuẩn quyết định đặc trưng làm nền tảng. Cơ chế điều

khiển chấp nhận kết nối mới vẫn đảm bảo được tính

khả triển (scalability) vốn có của mạng DiffServ và

1.Đề xuất cơ chế quản lý hàng đợi CQM, trong đó

lấy token bucket kết hợp với bộ điều khiển làm cơ

chế điều khiển cục bộ tại router, điều khiển lưu

lượng đổ vào bộ đệm theo nguyên lý phản hồi.

- 6 -

- 31 -

tạo triển vọng cung cấp end-to-end QoS cho mạng

DiffServ một cách đơn giản.

s

0.5e-6, 0.6e-6, 0.7e-6, 0.8e-6, 0.9e-6, 1e-

6,1.1e-6, 1.2e-6, 1.3e-6, 1.4e-6, 1.5e-6,

1.6e-6, 1.7e-6, 1.8e-7

Luận án gồm 129 trang có bố cục như sau:

Mở đầu : 8 trang

Chương 1- Tổng quan IP QoS : 11 trang

Chương 2- Các giải pháp chính cho QoS trong

Mô phỏng được thực hiện đầu tiên với nguồn 1

(Expo1) với tham số s được thay đổi như trong bảng

3.2. Mô phỏng lại được thực hiện tiếp tục với nguồn 2

(Expo2) với tham số được mô tả trong bảng 3.3. Kết

quả mô phỏng được trình bày trên hình 3.25. Trong

trường hợp của nguồn 1, ta thấy rằng hiệu suất sử

dụng liên kết đạt xấp xỉ 90% ứng với xác suất mất gói

rất thấp. Khi hiệu suất đạt xấp xỉ 95% thì xác suất mất

gói cũng chỉ khoảng 8,2.10^-4. Điều này cho thấy việc

sử dụng giải pháp CAC đã cải thiện được chất lượng

dịch vụ qua giảm xác suất mất gói mà vẫn đảm bảo

được hiệu suất sử dụng liên kết ở mức cao.

mạng IP hiện nay

và những hạn chế : 26

trang

Chương 3- Đề xuất các giải pháp nhằm cải thiện

QoS cho mạng

IP theo kiến trúc

DiffServ: 54 trang

3.1 Cơ sở nghiên cứu và các mục tiêu chính : 2

trang

3.2 Giải pháp thực hiện AFij cho mạng

DiffServ : 31 trang

3.3 Giải pháp điều khiển chấp nhận kết nối cho

mạng DiffServ : 20 trang

3.4 Kết luận : 1 trang

So sánh kết quả giữa nguồn 1 và nguồn 2 thấy rằng

sự khác biệt tỉ lệ giữa burst time và idle time cũng ảnh

hưởng đến chất lượng phục vụ, cụ thể là khi tỉ lệ burst

time lớn sẽ dẫn đến xác suất mất gói lớn hơn. Qua kết

quả mô phỏng cũng chứng tỏ rằng tham số s thực sự

đóng vai trò điều khiển nhằm tối ưu giữa hai tham số

xác suất mất gói và hiệu suất sử dụng liên kết cho một

nguồn xác định.

Kết luận và kiến nghị hướng phát triển : 3 trang

Danh mục các công trình của tác giả : 2 trang

Tài liệu tham khảo : 99 tài liệu tham khảo (11

trang)

Luận án có 33 hình và 04 bảng

B. NỘI DUNG

Chương 1 - Tổng quan IP QoS

1.1 Giới thiệu IP QoS

- 30 -

- 7 -

đầu

Ngày nay IP là nền tảng cho mạng hội tụ đa dịch

vụ. Chủ đề QoS trong mạng IP được quan tâm nghiên

cứu dưới tên gọi IP QoS. Có bốn tham số đo lường

chính của IP QoS là thông lượng (throughput), độ trễ

(end-to-end delay), độ biến động trễ (jitter) và độ tổn

thất gói (packet loss).

30

60

90

35.10^-3

65.10^-3

95.10^-3

65.10^-3

95.10^-3

120

12,5.10^-

3

150

180

210

240

270

300

330

360

390

420

15,5.10^-

3

16,9.10^-

18,5.10^-

1.2. Phương thức cơ bản cung ứng QoS trong

mạng IP

3

74,4.10^-

21,5.10^-

3

Ba phương thức cơ bản thường dùng để hỗ trợ QoS

trong mạng IP, đó là cung ứng có dự phòng cho mạng,

xếp hàng và phân loại.

17.4.10^-

24,5.10^-

2

3

25,2.10^-

27,5.10^-

2

3

1.3. Cơ chế kiểm soát chất lượng mạng phổ biến

cho mạng IP

32,8.10^-

1.10^-4

2

Ba nhóm cơ chế chính nhằm đạt được một chất

lượng mạng tốt hơn mức “Best Effort” truyền thống

trên mạng IP, đó là:

35,4.10^-

4,9.10^-4

2

38,7.10^-

36,5.10^-

2

3

- Cung cấp dung lượng vượt yêu cầu

39,4.10^-

10,3.10^-

2

4

- Đăng ký trước tài nguyên: tiêu

40,9.10^-

42,5.10^-

biểu là Intserv

2

3

- Ưu tiên hóa các dịch vụ và người dùng: tiêu biểu

là DiffServ

3.3.6.2 Đánh giá xác suất mất gói và hiệu suất sử

dụng liên kết qua mô phỏng với các nguồn lưu

lượng khác nhau

Chương 2 -Các giải pháp chính cho QoS trong

mạng IP hiện nay và những hạn chế

2.1 Phát triển IP QoS theo cơ chế DiffServ

DiffServ là một tập hợp công nghệ cho phép nhà

cung cấp dịch vụ mạng đưa ra các dịch vụ mạng khác

Bảng 3.3 Các giá trị của s

Tham

Các giá trị

số

- 8 -

- 29 -

nhau cho khách hàng cũng như cho các dòng lưu

lượng mạng của họ. Kiến trúc DiffServ chứa hai thành

phần chính. Một là nguyên tắc ứng xử công bằng phổ

quát trên từng bước gọi là PHB (per hop behaviors) và

thứ hai là chính sách cấu hình các thông số trên đường

dẫn chuyển gói cho từng PHB. Hiện có hai PHB được

định nghĩa là EF (Expedited Forwarding), AF

(Assured Forwarding).

Bảng 3.1 Các tham số của nguồn 1 (Expo1)

Tham số

Giá trị

Packet size 125 bytes

Burst time

Idle time

Data rate

200 ms

64 kbps

Kết quả mô phỏng xác định xác suất mất gói

(packet loss probability) trong trường hợp không có

điều khiển chấp nhận kết nối được mô tả trong hình

3.23 và hình 3.24 mô tả xác suất mất gói khi có thủ

tục CAC tham gia. Cụ thể hơn, bảng 3.2 đưa ra số liệu

so sánh xác suất mất gói giữa hai trường hợp. Từ kết

quả cho thấy, khi có cơ chế điều khiển chấp nhận kết

nối, xác suất mất gói giảm đi rất nhiều so với trường

hợp chạy DiffServ nguyên bản không CAC.

Công việc phát triển một hệ thống DiffServ liên

quan đến tổ chức và phát triển hai thành phần chính là

bộ điều chỉnh lưu lượng (traffic conditioner) tại router

biên (edge router) và các PHB tại các router, đặc biệt

là các router bên trong (core router).

Mỗi PHB được thể hiện qua hai cơ chế: cơ chế

quản lý hàng đợi và cơ chế lập lịch gói. Trong đó,

nguyên lý quản lý hàng đợi tích cực RED (Random

Early Detection) được dùng để quản lý hàng đợi cho

DiffServ.

Vì RED có thể hủy gói một cách ngẫu nhiên theo

thông số xác suất qua thao tác cấu hình, nên có thể

được dùng để thực hiện động thái AF (Assure

Forwarding behavior) trong DiffServ.

Hình 3.23 Xác suất mất

gói trong trường hợp

không dùng giải pháp

CAC.

Hình 3.24 Xác suất mất

gói trong trường hợp có

dùng cơ chế CAC được

đề nghị.

Theo các nghiên cứu cho thấy để hệ thống dùng

RED ổn định cần phải chọn tham số hoạt động cho

RED theo các tiêu chí nhất định và trong một phạm vi

xác định của các yếu tố khách quan như cự ly truyền.

Bảng 3.2 Bảng so sánh xác suất mất gói giữa hai

trường hợp không dùng CAC và dùng CAC

Thời điểm tính

toán T (s), tính từ

thời điểm ban

Xác suất mất gói

khi không dùng

CAC

Xác suất mất

gói khi dùng

CAC

- 28 -

- 9 -

3.3.5 Hoạt động điều khiển chấp nhận kết nối theo

phương pháp được đề xuất

Điều này không phải lúc nào cũng dễ dàng trên mạng

thực tế, khi mà nhu cầu kết nối cũng như lưu lượng

luôn biến động. Đây cũng là lý do vì sao các triển khai

DiffServ hiện nay vẫn chưa thực hiện một cách đầy đủ

các dịch vụ như trong đặc tả. DiffServ vẫn đang cần

có các giải pháp thực tế hơn để việc triển khai được dễ

dàng và hoạt động bền vững hơn.

Mỗi user với cấp dịch vụ đã thỏa thuận trước với

ISP trong hợp đồng lưu lượng (SLA), dùng thủ tục

báo hiệu gửi yêu cầu tạo kết nối không tường minh

với đối tác. Kết nối không tường minh chỉ được chấp

nhận khi tất cả các router liên quan đều thỏa điều kiện

CAC. Các router sẽ áp dụng tiêu chuẩn quyết định đã

được xây dựng để thực hiện thủ tục CAC cục bộ trên

từng lớp dịch vụ.

2.3 Vấn đề quản lý đăng ký tài nguyên trong mạng

DiffServ

Kiến trúc DiffServ không đảm bảo một QoS từ đầu

cuối đến đầu cuối (end-to-end QoS) vì không có cơ

chế quản lý đăng ký tài nguyên. Trong nỗ lực cải thiện

sự yếu kém này, có nhiều đề xuất bổ sung cơ chế kiểm

soát đăng ký tài nguyên cho DiffServ hay còn gọi là

điều khiển chấp nhận các yêu cầu QoS từ người dùng.

Các giải pháp được đề nghị cho đến nay thể hiện

thành hai nhóm: tập trung và phân tán. Trong đó, giải

pháp tập trung đưa ra khái niệm Bandwidth Broker,

tuy nhiên giải pháp này vấp phải khuyết điểm là tạo ra

một điểm lỗi nhạy cảm cho toàn bộ hệ thống.

3.3.6 Kết quả của giải pháp được đề xuất

Ingress router

Core router

Egress router

Nguồn

Đích

10Mbps

Hình 3.22 Sơ đồ mạng thực hiện mô phỏng.

Sơ đồ mạng mô phỏng như hình 3.22. Chương

trình được viết bằng ngôn ngữ OTcl và C++ được biên

dịch bằng gcc trong NS-2 phiên bản 2.29.

3.3.6.1 Kết quả mô phỏng và so sánh với hệ thống

hiện hữu

Giải pháp RMD, PBAC, GRIP và PCN mang tính

tiêu biểu cho các giải pháp điều khiển chấp nhận phân

tán. Tuy nhiên, các giải pháp này vẫn còn tồn tại các

hạn chế cần phải vượt qua để trở thành hiện thực. Bổ

sung cơ chế điều khiển chấp nhận cho DiffServ là điều

Dùng mô hình nguồn đóng-ngắt (ON-OFF) với

thời gian đóng ngắt tuân theo phân bố mũ như mô tả

trong bảng 3.1.

- 10 -

- 27 -

hiển nhiên và hết sức cấp thiết nhằm đạt được một giải

pháp QoS hoàn chỉnh cho mạng IP.

các router như sau: (các chi tiết được trình bày bên

trong cuốn luận án)

m

2.4 Phát triển IP QoS trên nền MPLS

ì

(

n + 1 £

)

ï

1

MPLS giải quyết vấn đề QoS cho mạng IP bằng

cách thiết lập các đường dẫn tường minh qua mạng.

Các đường dẫn được gọi là LSP (Label Switching

Path) cung cấp một phương tiện để đảm bảo một chất

lượng dịch vụ đặc biệt. Để hỗ trợ DiffServ, có thể linh

hoạt ánh xạ các BA (Behavior Aggregate) vào các

đường dẫn LSP sao cho phù hợp nhất.

× r_m

ï

í

1

e^sp

2 -

(s>0)

ï

æ ^{^}

ö

e^sp× S+ r £ m

ç

÷

è

^mø

ï

î

(3.30)

Trong đó:

n là số luồng được chấp nhận

Chương 3 - Đề xuất các giải pháp nhằm cải thiện

QoS cho mạng IP theo kiến trúc DiffServ

µ là dung lượng đầu ra được gán cho lớp tương

ứng tại router

3.1 Cơ sở nghiên cứu và các mục tiêu chính

Dựa vào mô hình toán học và mô phỏng máy tính

để nghiên cứu đề xuất giải pháp thực hiện AFij mà

không dùng RED và đề xuất giải pháp điều khiển chấp

nhận nối cho mạng DiffServ tránh các hạn chế của hai

giải pháp tiêu biểu như RMD, PBAC, GRIP và PCN.

3.2 Giải pháp thực hiện AFij cho mạng DiffServ

3.2.1 Giới thiệu đề xuất

Ŝ là tải hiện hành ước lượng được

r_mlà tốc độ trung bình của nguồn lưu lượng yêu

cầu đăng ký

p là tốc độ đỉnh

s là tham số điều khiển, s qui định giới hạn băng

thông được dùng hay (ŝ + r)_max= n.m

Như đã nói trong mục đích thiết kế ban đầu, mỗi

router sẽ giữ một tham số n để chỉ ra số luồng đã được

chấp nhận, một luồng mới với tốc độ yêu cầu r_mđược

chấp nhận nếu n và r_mthỏa mãn đồng thời hệ bất đẳng

thức trên. Tham số s đóng vai trò là tham số điều

khiển trong cơ chế điều khiển chấp nhận kết nối và

được xác định tùy vào hệ số n.

Theo đặc tả kiến trúc DiffServ thì AF PHB phức

tạp hơn EF PHB, AF PHB có đến bốn lớp con và

trong mỗi lớp con lại được chia ra thành ba mức ưu

tiên, như vậy AF PHB có 12 mức dịch vụ, ở đây tạm

gọi là các AFij trong đó iÎ[0,3] và jÎ[0,2], việc thực

hiện các AFij này vẫn còn hạn chế và phụ thuộc nhiều

- 26 -

- 11 -

dấu, egress router sẽ gửi thông báo không chấp nhận

vào thuật toán RED. Phương pháp được đề nghị ở

đây xuất phát từ hai ý tưởng sau:

cho ingress router (hình 3.21) .

n+1

Ingress

router

Core

Router

Egress

router

-

Đưa bộ điều khiển vào tham gia quản lý

hàng đợi.

n+1

Core

Router

Không đủ

tài nguyên

Request packet

QoS

request

Request packet

-

Dùng thuật toán token-bucket có tốc độ

token linh động để thực hiện chức năng

giám sát và hủy gói.

Marked request packet

Reject packet

Trên cơ sở đó xây dựng nên cơ chế quản lý hàng

đợi mới, đặt tên là cơ chế quản lý hàng đợi có thể điều

khiển được, dịch sang tiếng Anh là CQM (Controllabe

Queue Management). Dùng cơ chế CQM để thay thế

cho cơ chế AQM (Active Queue Management) và do

đó không dùng RED nữa. Phần cơ bản của phương

pháp là cơ cấu gồm token bucket và bộ điều khiển tạo

thành cặp gắn kết cho cơ chế, trong đó token bucket sẽ

chịu trách nhiệm giám sát và hủy gói tùy vào số token

mà nó đang có, còn bộ điều khiển sẽ điều khiển tốc độ

luồng token đổ vào token bucket tùy vào chiều dài

hàng đợi. Việc thay đổi mức tham chiếu của bộ điều

khiển sẽ là điểm then chốt để thực hiện các lớp con

khác nhau của AF PHB.

Clear packet

n-1

Hình 3.21

chối.

Thủ tục báo hiệu khi yêu cầu bị từ

Thủ tục cần sử dụng các gói điều khiển chính như

sau: Request packet, Accept packet, Reject packet,

Release packet, Clear packet, Confirm packet.

3.3.3 Phương pháp ước lượng tải tại DiffServ

router

Trong phương pháp được đề xuất trong luận án này sẽ

áp dụng phương pháp ước lượng tải được công bố bởi

S. Jamin. Mỗi router phải ước lượng tài nguyên bị

chiếm bởi các luồng hiện hành, gọi là ŝ, đây là tham

số đầu vào của tập quyết định trong thủ tục CAC.

3.3.4 Xây dựng tiêu chuẩn quyết định

3.2.2 Thiết kế cơ chế quản lý hàng đợi CQM bằng

token bucket và bộ điều khiển

Phần này đã áp dụng Chernoff bound cho các

phân bố của một tổng các biến ngẫu nhiên độc lập để

phân tích và xây dựng được tiêu chuẩn quyết định cho

Sơ đồ nguyên lý được trình bày trên hình 3.8.

Lượng gói số liệu đi vào hàng đợi trong khoảng thời

gian nào đó tùy vào khả năng tích lủy token của token

- 12 -

- 25 -

bucket trong khoảng thời gian đó. Vì vậy, để quản lý

lưu lượng đi vào hàng đợi thì phải kiểm soát tốc độ

dòng token đổ vào token bucket. Điều chỉnh tốc độ

token hợp lý sẽ quản lý được hàng đợi một cách hiệu

quả và ngăn chặn được tình trạng tắc nghẽn.

r(t)

q_ref

Bộ điều

khiển

b

y(t)

Hình 3.20 Thủ tục báo hiệu kết nối với yêu cầu được

chấp nhận.

C

v(t)

u(t)

Hình 3.20 mô tả hoạt động của thủ tục báo hiệu kết

nối không tường minh trong trường hợp yêu cầu kết

nối được chấp nhận. Khi user gửi yêu cầu đến ingress

router thì router này sẽ phát ra gói yêu cầu để thăm dò

domain, nếu một core router có đủ tài nguyên để chấp

nhận thì nó tiếp tục chuyển yêu cầu này đến router kế

tiếp và tăng tham số n lên một đơn vị, ngược lại nếu

không đáp ứng yêu cầu thì router phải đánh dấu gói

bằng cách dựng một bit cờ và chuyển gói này đi tiếp.

Nếu router nhận được gói bị đánh dấu thì sẽ chuyển

gói đi tiếp mà không làm công việc nào khác. Ở

egress router khi nhận một gói yêu cầu chưa bị đánh

dấu, nếu có đủ tài nguyên thì sẽ tăng tham số n lên

một đơn vị và gửi thông báo chấp nhận cho ingress

router biết. Ngược lại nếu nhận gói yêu cầu bị đánh

q(t)

Hình 3.8 Mô hình hoạt động của cơ chế quản lý hàng

đợi dùng token bucket và bộ điều khiển.

Tính hợp lý đặt ra ở đây xoay quanh mục tiêu là khi

kích thước hàng đợi còn trống càng nhỏ thì lưu lượng

đổ vào hàng đợi phải càng ít và do đó tốc độ token

cũng phải càng nhỏ. Kịch bản này hoàn toàn phù hợp

với vai trò của một bộ điều khiển. Vì vậy, công việc

điều chỉnh tốc độ token này được giao cho bộ điều

khiển, bộ điều khiển được đặt ở khoảng giữa hàng đợi

và token bucket. Căn cứ vào độ lệch giữa mức tham

chiếu được cấu hình và kích thước của hàng đợi, bộ

điều khiển sẽ phát ra tốc độ token phù hợp để sử dụng

- 24 -

- 13 -

3.3.2 Thiết kế cơ chế báo hiệu cho kết nối không

tường minh

hàng đợi hiệu quả và không để xảy ra tình trạng hàng

đợi bị tràn.

3.3.2.1 Khái niệm kết nối không tường minh

Trên thực tế có trường hợp hai thực thể truyền

thông có thể trao đổi thông tin với nhau nhưng giữa

chúng không có một kết nối rõ ràng nào. Trong trường

hợp này có thể xem hai thực thể truyền thông được

nối với nhau bằng một kết nối không tường minh.

3.3.2.2 Thiết kế cơ chế báo hiệu kết nối không

tường minh cho môi trường DiffServ

Biểu diễn toán học theo mô hình luồng động của

cơ cấu này như sau: (phân tích động học được trình

bày chi tiết trong cuốn luận án)

·

q

(

t

)

= - 1(q(t) > 0)×C + u(t)

y

(

t

)

é

ù

u

(

t

(

= 1 v

(

t

)

> 0

)

× r

ê

(

t

)

+

ú

û

T

ë

(3.1)

3.2.3 Áp dụng cơ chế quản lý hàng đợi CQM gồm

token bucket-controller để thực hiện các AFij

trong mạng IP DiffServ

Về cơ bản thì thủ tục báo hiệu là giữa ingress

router và egress router nhằm hỏi DiffServ domain có

cho một kết nối không tường minh hay không.

Trong chế độ họat động không kết nối, core router

chấp nhận một luồng mới nhưng tải thực sự của luồng

này có thể được định tuyến qua router khác và router

lại có thể tiếp tục cho phép nhiều luồng mới vì tải thực

tế qua nó vẫn còn trong hạn định. Điều này dẫn đến

tình trạng quá tải trong domain. Giải pháp được

nghiên cứu sinh đưa ra là bổ sung một ràng buộc (hay

luật) vào tập tiêu chuẩn quyết định CAC dựa trên số

luồng hiện hành được router cho phép. Để tạo điều

kiện thực hiện ràng buộc bổ sung này, các DiffServ

router phải theo dõi số lượng luồng đã chấp nhận, gọi

là n.

3.2.3.1 Nguyên lý và kiến trúc thực hiện AFij tại

các DiffServ router dùng token bucket_controller

Mục tiêu chính ở đây là thực hiện các lớp PHB phụ

(subclass) hay AFij trong mỗi lớp AF. Theo kiến trúc

DiffServ thì mỗi lớp AF có ba lớp phụ ứng với ba

mức bị chọn để hủy khác nhau. Vì việc thực hiện các

AFij là giống nhau trong các lớp AF nên ở đây chỉ

trình bày phương pháp thực hiện trong một lớp AF. Sơ

đồ nguyên lý được mô tả trên hình 3.13.

Mỗi AFij được thực hiện bằng cơ chế quản lý hàng

đợi có điều khiển CQM gồm một token bucket hai

trạng thái (có tích hợp trạng thái luôn đầy) và một bộ

điều khiển. Như vậy trong mỗi lớp AF sẽ có ba bộ

token bucket-controller. Hệ thống này được thiết kế để

có hai chế độ hoạt động tách biệt gọi là chế độ hoạt

Egress

router

Ingress

router

Core

Router

Core

Router

n+1

Request packet

n+1

QoS

request

Request packet

Accept packet

Request packet

- 14 -

- 23 -

động tự do và chế độ hoạt động có ràng buộc. Chế độ

hoạt động tự do ứng với các khóa K chuyển đến vị trí

0 để kết nối với token bucket luôn đầy CTB (constant

token bucket). Token bucket luôn đầy luôn có đầy đủ

token để chuyển gói số liệu đi. Vì vậy trong chế độ

hoạt động tự do, các gói IP từ tất cả các lớp phụ AFij

đều được chuyển đi mà không bị bất kỳ hạn chế nào.

Chế độ hoạt động này nhắm đến thỏa mãn các nhu cầu

của lưu lượng AF đã được định chế tại các router biên

(theo hợp đồng lưu lượng) trong điều kiện mức độ tải

tại router còn nhẹ.

nhưng chiều dài hàng đợi gia tăng và đạt ổn định tại

một mức xác định xấp xỉ 280. Điều này chứng tỏ đã

đảm bảo điều khiển nghẽn cho hàng đợi đầu ra.

3.3 Giải pháp điều khiển chấp nhận kết nối cho

mạng DiffServ

3.3.1 Giới thiệu đề xuất

Vì các mạng DiffServ hoạt động theo chế độ không

tạo kết nối (connectionless), do đó các router có thể

mắc lỗi khi chấp nhận quá nhiều luồng mới nếu nó chỉ

dựa vào đo lường trên tải hiện hành để thực hiện chức

năng đăng ký. Chưa có một giải pháp nào chú ý đến

vấn đề này và đây cũng là lý do tại sao RMD, PBAC,

GRIP và PCN vấp phải các hạn chế. Trong phần này

sẽ đề xuất một giải pháp điều khiển chấp nhận kết nối

có thể tránh được các hạn chế của các giải pháp khác

nhờ tập trung khắc phục vấn đề nêu trên. Cụ thể là sẽ

bổ sung ràng buộc vào tiêu chuẩn quyết định trong

CAC để hạn chế sự cho phép quá mức số luồng.

Giải pháp được đề nghị gồm có hai phần chính:

- Cơ chế báo hiệu cho kết nối không tường minh.

- Tiêu chuẩn quyết định cho các DiffServ router

thực hiện CAC.

Phương pháp điều khiển chấp nhận kết nối ở đây

được phát triển để hoạt động cho từng PHB riêng biệt

nhằm tương thích với môi trường DiffServ.

- 22 -

- 15 -

Controller

Constant

Token

r₁(t)

Bucket

b₁

y₁(t)

q_ref1

1

0

K

u₁(t)

AF_i1

v₁(t)

a. Động thái của u₁(t)

b. Động thái của u₂(t)

Controller

r₂(t)

Constant

Token

Bucket

b₂

q_ref2

y₂(t)

1

0

K

u₂(t)

C

AF_i2

v₂(t)

Out

q(t)

c. Động thái của u₃(t)

d. Động thái của q(t)

Controller

r₃(t)

Constant

Token

Bucket

B

Hình 3.19 Động thái của các thành phần trong cơ

cấu.

b₃

q_ref3

y₃(t)

AF

Monitor

Từ kết quả trên hình 3.19 dễ dàng nhận thấy, u₂(t)

và u₃(t) giảm nhanh xuống 0 tương ứng với tất cả các

gói đến bị hủy hay đánh dấu, như hình 3.19b và 3.19c.

Trong đó, nếu để ý sẽ thấy u₃(t) giảm nhanh hơn u₂(t)

và tiếp cận 0 sớm hơn. Điều này có nghĩa là AF_i3hủy

gói một cách triệt để trước khi AF_i2làm công việc

tương tự. Cũng nhận ra rằng tốc độ u₁(t) của AF_i1

giảm nhưng vẫn lớn hơn 350 vì đây là lớp có ưu tiên

cao nhất (xem hình 3.19a).

K

1

0

u₃(t)

AF_i3

v₃(t)

Hình 3.13 Sơ đồ nguyên lý thực hiện AFij trong một

lớp AF.

Khi hệ thống rơi vào tình trạng có nguy cơ bị

nghẽn, thành phần được gọi là bộ giám sát AF (AF

monitor) sẽ chuyển khóa K sang vị trí 1 để nối vào

token bucket bên trái, tương ứng với token bucket

chuyển sang làm việc ở trạng thái thông thường của

nó. Lúc này, hệ thống sẽ vào chế độ hoạt động có ràng

Kế tiếp, động thái của hàng đợi đầu ra được thể

hiện trên hình 3.19d cho thấy mặc dù lượng tải lớn

- 16 -

- 21 -

buộc. Trong chế độ ràng buộc, lưu lượng của các lớp

phụ AFij chịu sự quản lý của token bucket trong sự

cộng tác với bộ điều khiển. Bộ điều khiển sẽ lấy thông

tin về chiều dài hiện hành của hàng đợi qua cơ cấu

phản hồi, từ đó phát ra một tốc độ token hợp lý sao

cho không để hàng đợi bị nghẽn. Token bucket sẽ hủy

hay đánh dấu các gói IP đến nếu không có đủ token để

chuyển chúng vào hàng đợi chung ở đầu ra. Mức hủy

gói của mỗi token bucket thực sự là cụ thể hóa mức độ

bị chọn để hủy (drop precedence) của AFij và mức

hủy này là khác nhau giữa các AFij.

Hình 3.18- Cải thiện hiệu quả sử dụng khi nâng mức

tham chiếu q_ref.

3.2.4.2 Kết quả mô phỏng và đánh giá phương

pháp thực hiện AFij được đề xuất

Để minh chứng cho tính khả thi của giải pháp thực

hiện AFij được đề xuất, hệ thống đã được mô phỏng

trên máy tính dùng phần mềm Matlab. Mục đích của

mô phỏng gồm: kiểm chứng sự khác biệt giữa các

AFij trong hệ thống, khảo sát tính ổn định của hệ

thống và khả năng điều khiển nghẽn. Quá trình khảo

sát tập trung vào biểu hiện của tốc độ lưu lượng đầu ra

của token bucket hay các u_i(t), biểu hiện động thái của

hàng đợi cổ chai (hàng đợi chia sẻ) ở đầu ra.

Trong kịch bản mô phỏng ở đây giả sử hàng đợi

(bộ đệm) đầu ra có kích thước 500 gói; tất cả các

token bucket đều có thể chứa đến 50 token; tốc độ của

liên kết đầu ra là C = 150 gói/giây.

Trong hệ thống này, kích thước hàng đợi tham

chiếu q_ref(thông số được cấu hình) được dùng như

tham số then chốt để tạo nên các mức hủy gói khác

nhau. Giá trị tham chiếu này càng lớn thì mức hủy gói

càng nhỏ. Do đó, sẽ cấu hình (gán) q_ref1>q_ref2>q_ref3

nếu như AF_i1, AF_i2và AF_i3lần lượt là dịch vụ vàng

(Gold service), dịch vụ bạc (Silver service) và dịch vụ

đồng (Bronze service). Các giá trị của q_reftùy thuộc

vào mức độ khác biệt muốn tạo ra giữa các lớp phụ

AFij của nhà cung cấp dịch vụ.

Theo đề nghị 1, chọn q_ref1= B- (b₁+b₂+b₃) = 500 –

150 = 350, q_ref2= 250 và q_ref3= 200.

Thực hiện chỉnh định theo phương pháp Ziegler-

Nichols thứ hai và xác định được tham số điều khiển

K_p» 3.14, K_I= 0.7

3.2.3.4 Mô hình động học của cơ cấu thực hiện các

AFij

Động học của hệ thống theo mô hình luồng động

được biểu diễn như sau:

- 20 -

- 17 -

3

·

b=20.

q

(

t

)

=

- 1(q(t) > 0) ×C

+

(

t

)

å

u_i

i=1

é

ù

ú

û

(

T

t

)

y

i

u_i⁽^{= 1}⁽v_i⁽

_êr_i

t

)

t

)

> 0

)

×

(

t

)

+

ê

ú

ë

(3.7)

Trong đó, T là khoảng thời gian truyền liên tục và

C là băng thông của liên kết đầu ra. Giá trị C này sẽ

được gán cố định cho một lớp AF nào đó theo đặc tả

của kiến trúc DiffServ.

Tuy nhiên, chúng ta có thể cải thiện được tình trạng

này một cách dễ dàng nếu như ép q_refthêm một lượng

thích hợp. Lúc này tham số q_refcó thể đóng vai trò

như một tham số chỉnh định. Tham số này có thể lấy

giá trị lớn hơn giá trị chiều dài thực tế của hàng đợi

sao cho cơ cấu sử dụng hết bộ đệm đầu ra. Ví dụ trong

trường hợp b = 20, có thể cấu hình q_ref= 530 và đạt

được mức sử dụng như trên hình 3.18, nâng mức sử

dụng ổn định từ 310 lên xấp xỉ 360.

Từ (3.7) ta thấy rằng u_i(t) » 1(v_i(t)>0)r_i(t) nếu T có

giá trị đáng kể và với bất kỳ thang thời gian xem xét

nào ta luôn có:

[

(t)

]

u_i^(t)max ^{= 1(}v_i^{(t) > 0) ×}r_i^{(t) +}

y

i

(3.8)

với T lấy giá trị đơn vị của thang thời gian xem xét.

Xem u_i(t)=u_i(t)_maxlà trường hợp xấu nhất vì là ứng

với trường hợp hàng đợi chia sẻ bị làm đầy với tốc độ

lớn nhất. Để có tính tổng quát, ở đây sẽ đánh giá hệ

thống theo trường hợp xấu nhất này.

Qua kết quả mô phỏng trên cho thấy hệ thống

hoàn toàn khả thi và hoạt động ổn định. Cơ chế không

những đảm bảo về điều khiển nghẽn trên hàng đợi cổ

chai mà còn giúp cải thiện hiệu suất sử dụng.

Do đó, động học của hàng đợi cổ chai là

3

·

q

(

t

)

=

- 1(q(t) > 0)C

+

[

+

(t)

]

¹⁽v_i^{(t) > 0) ×}r_i^(t)

y

å

i

i=1

(3.9)

(các phân tích chi tiết được trình bày trong cuốn luận

án)

3.2.3.5 Điều kiện áp dụng CQM vào thực hiện AFij

và hệ quả

- 18 -

- 19 -

Đề nghị 1: Giả sử hàng đợi có kích thước B gói và

kích thước thùng chứa của các token bucket lần lượt là

b₁, b₂và b₃. Để bộ đệm không bị tràn, q_ref1nên cấu

đích và kịch bản mô phỏng như sau: mô phỏng hoạt

động của cơ chế quản lý hàng đợi có điều khiển gồm

một bộ token bucket-controller và một hàng đợi cổ

chai. Qua đó xác định động thái của hàng đợi cổ chai

để đánh giá tính ổn định của cơ chế và khả năng điều

khiển nghẽn cũng như cải thiện hiệu quả sử dụng tài

nguyên.

hình như sau:

3

=

1

B

-

q

å

b

i

ref

1

(3.13)

Đề nghị 1 có mục đích đơn giản là tạo ra một

khoảng không gian dự phòng trên hàng đợi cho trường

hợp có lượng gói nhập quá mức do số token thừa.

Đề nghị 2: Trong chế độ hoạt động có ràng buộc, để

đạt được khả năng chia sẻ tài nguyên giữa các dịch vụ,

cần giám sát thường xuyên và điều chỉnh các q_refcủa

các AF_ijtheo lưu đồ giải thuật được trình bày chi tiết

trong cuốn luận án.

Động thái của chiều dài hàng đợi q(t) được trình

bày trên hình 3.16, hình cho thấy số lượng gói trong

hàng đợi thoạt đầu tăng nhanh lên đến mức tối đa, sau

đó giảm xuống và ổn định ở mức xấp xỉ 360.

Để kiểm tra tác động của kích thước thùng

(bucket) của token bucket đến cơ chế như thế nào,

giảm giá trị b xuống còn 20, lúc này kết quả mô phỏng

cho thấy hàng đợi q(t) ổn định ở mức xấp xỉ 310 như

trên hình 3.17. Như vậy, b càng nhỏ thì dung lượng

hàng đợi được dùng càng giảm. Trong khi đó, thường

thì y(t) nhỏ hơn b trong quá trình token bucket hoạt

động nên sẽ không tận dụng hết hàng đợi.

3.2.4 Kết quả của giải pháp được đề xuất

3.2.4.1 Kết quả mô phỏng và đánh giá khả năng

của cơ chế quản lý hàng đợi CQM dùng token

bucket và bộ điều khiển

Để phục vụ cho việc mô phỏng đánh giá cơ chế

quản lý hàng đợi CQM (hình 3.8), ở đây chọn loại bộ

điều khiển thông dụng PI có sẵn trong phần mềm

MATLAB Simulink. Giả sử hàng đợi có kích thước

500 gói, token bucket có b =50 gói, tốc độ truyền của

liên kết đầu ra C=150 gói/giây. Sử dụng phương pháp

chỉnh định Ziegler-Nichols xác định được các hệ số

K_p» 3,14 và K_I= 0,7 để tiến hành mô phỏng. Mục

Hình 3.16 Động thái của

q(t) tương ứng với b=50.

Hình 3.17 Động thái

của q(t) tương ứng với