- 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 -

- 34 -

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
.
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.
Đố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

- 4 -
đ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.
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.
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ế,

- 33 -


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

- 32 -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)
Tham số Giá trị
Packet size

125 bytes

Burst time 400 ms
Idle time 325 ms
Data rate 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ả :
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.


DiffServ một cách đơn giản.
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ạ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
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

- 31 -

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

30 35.10
-3
35.10
-3

60 65.10
-3
65.10
-3

90 95.10
-3
95.10
-3

120 12,5.10
-
3

12,5.10
-
3

150 15,5.10
-
3

15,5.10
-
3

-
3

300 32,8.10
-
2

1.10
-4

330 35,4.10
-
2

4,9.10
-4

360 38,7.10
-
2

36,5.10
-
3

390 39,4.10
-
2

10,3.10

xếp hàng và phân loại.
1.3. Cơ chế kiểm soát chất lượng mạng phổ biến
cho mạng IP
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à:
- Cung cấp dung lượng vượt yêu cầu
- Đăng ký trước tài nguyên: tiêu
biểu là Intserv
- Ưu tiên hóa các dịch vụ và người dùng: tiêu biểu
là DiffServ
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

- 8 -
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).
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

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.
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ị.

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 -

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

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.
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.
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

- 10 -

hin nhiờn v ht sc cp thit nhm t c mt gii
phỏp QoS hon chnh cho mng IP.
2.4 Phỏt trin IP QoS trờn nn MPLS

ù
ù
ù
ợ
ù
ù
ù
ớ
ỡ
mÊ
ữ
ứ
ử
ỗ
ố
ổ
+ì
ì
-
m
Ê+
m
^
sp
m
sp
rSe
r
e
1

thc trờn. Tham s s úng vai trũ l tham s iu
khin trong c ch iu khin chp nhn kt ni v
c xỏc nh tựy vo h s
n
.

- 26 -

dấu, egress router sẽ gửi thông báo không chấp nhận
cho ingress router (hình 3.21) .
Hình 3.21 Thủ tục báo hiệu khi yêu cầu bị từ
chối.
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
Phần này đã áp dụng Chernoff bound cho các

- 11 -

vào thuật toán RED. Phương pháp được đề nghị ở
đây xuất phát từ hai ý tưởng sau:
- Đưa bộ điều khiển vào tham gia quản lý
hàng đợi.
- 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.
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.
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
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 -

ref- 25 -

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.
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. Ở

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

Ingress
router
Core
Router
Egress
router
QoS
request
Request packet
Request packet
Request packet
Accept packet
n+1
n+1 n+1
n+1
Core
Router

- 13 -

hàng đợi hiệu quả và không để xảy ra tình trạng hàng
đợi bị tràn.
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)

( )

đồ 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

- 14 -

độ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ẹ. - 23 -

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


c. Động thái của u
3
(t) d. Động thái của q(t)
Hình 3.19 Động thái của các thành phần trong cơ
cấu.
Từ kết quả trên hình 3.19 dễ dàng nhận thấy, u
2
(t)
và u
3
(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
3
(t) giảm nhanh hơn u
2
(t)
và tiếp cận 0 sớm hơn. Điều này có nghĩa là AF
i3
hủy
gói một cách triệt để trước khi AF
i2
làm công việc
tương tự. Cũng nhận ra rằng tốc độ u
1
(t) của AF

1
y
1
(t)
q
ref1
AF
i1

Controller

b
3
y
3
(t) q
ref3
AF
i3
u
1
(t)
u
2
(t)
u
3
(t)
r
1


1

K
0

1

K
v
1
(t)
v
2
(t)
v
3
(t)
AF
Monitor

- 16 -

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 để

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:

- 21 -

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.
Theo đề nghị 1, chọn q
ref1

có 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.
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. - 17 -( ) ( )
tC)0)t(q(1tq
3
1i
i
u
å
=
·
+×>-=
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()t()0)t((1)t(
y
r
vu
i
i
i
max
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)

Đề 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
1
, b
2
và b
3
. Để bộ đệm không bị tràn, q
ref1
nên cấu
hình như sau:

å
-=
3
1
1
b
q
i
ref
B

(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ụ,

để đá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.
Độ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.
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