BỘ GIÁO DỤC VÀ ĐÀO TẠO TẬP ĐOÀN BCVT VIỆT NAM
HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG
*********************************************
NGUYỄN HỒNG SƠN
CHUYÊN ĐỀ 1
TỔNG QUAN IP QoS VÀ CƠ CHẾ CUNG CẤP
QoS TRONG MẠNG IP
CHUYÊN ĐỀ CẤP TIẾN SỸ
Giáo viên hướng dẫn: TS. L Ê H ỮU L ẬP
TS. V Ũ NH Ư L ÂN
HÀ NỘI 4-2008
2
MỤC LỤC
3
CHUYÊN ĐỀ 1
TỔNG QUAN IP QoS VÀ CƠ CHẾ CUNG CẤP
QoS TRONG MẠNG IP
1. Khái quát về IP QoS
Những năm gần đây đã bắt đầu khuynh hướng xây dựng các hệ thống truyền thoại
và video dựa vào IP. Khái niệm mạng hội tụ (converged networks) ngày càng
quen thuộc, các công nghệ IP cho phép chuyển các mạng điện thoại chuyển mạch
kênh và ISDN riêng biệt sang một mạng toàn IP, nơi số liệu, thoại và video đều
truyền qua cùng một hạ tầng. Trong một mạng hội tụ, chất lượng dịch vụ QoS
(Quality of Service) là chủ đề hiện thực quan trọng nhất. QoS là một thuật ngữ nối
mạng chỉ ra mức độ đảm bảo chất lượng số liệu được truyền nhận. Trong thực tế,
QoS là cơ chế đảm bảo số liệu âm thanh và hình ảnh truyền qua mạng tốn thời
gian ít nhất mà vẫn đảm bảo tính nguyên vẹn của chúng. Nếu không có QoS thì
các cuộc gọi qua mạng IP sẽ không đảm bảo và không đáp ứng được nguyện vọng
của người dùng.
Chất lượng dịch vụ được đánh giá qua bốn tham số đo lường chính 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).
Thông lượng là tốc độ truyền hiệu quả được đo lường theo bit trên giây (bits per
second hay bps) mà thực tế là số bit trung bình truyền thành công qua mạng trong
một giây. Có sự khác nhau giữa dung lượng tối đa hay tốc độ của đường truyền
với thông lượng. Bất cứ người dùng mạng nào đều nhận thông lượng thấp hơn
băng thông thực tế của liên kết vì họat động truyền còn phải truyền các thông tin
overhead là các bit mở rộng được bổ sung vào mỗi gói để nhận diện và cho nhiều
mục đích điều khiển khác. Về nguyên tắc, tất cả thuê bao đều có một mức thông
lượng tối thiểu luôn được đảm bảo bởi nhà cung cấp dịch vụ.
Tổn thất gói là tham số chỉ ra phần trăm gói đã truyền nhưng không bao giờ đến
đích. Các thiết bị mạng như các bộ chuyển mạch và router, đôi khi phải giữ các
gói trong các hàng đợi hay bộ đệm khi một liên kết bị nghẽn. Nếu liên kết cứ ở
trong tình trạng nghẽn quá lâu, các hàng đợi có thể bị tràn và gói dữ liệu sẽ bị mất.
Các gói bị mất sẽ phải được truyền lại, và lượng thời gian cho việc này sẽ làm tăng
tổng thời gian truyền. Trong một mạng tốt, độ tổn thất gói dưới 1% tính trung bình
trong một tháng.
Độ trễ là khoảng thời gian cần thiết để số liệu di chuyển từ nguồn đến đích. Ngoại
trừ trường hợp có quá giang qua kênh vệ tinh, một cuộc gọi điện thoại thông
thường qua mạng PSTN có khoảng cách 5000 km mất khoảng 25ms. Một cuộc gọi
4
điện thoại qua mạng Internet công cộng có thể mất đến 150ms do phải xử lý tín
hiệu và xếp hàng.
Độ biến động trễ (jitter) là tham số chỉ sự thay đổi độ trễ của các gói trong tuần tự.
Có nhiều nguyên nhân gây ra tham số này, bao gồm sự thay đổi của chiều dài hàng
đợi, sự thay đổi thời gian xử lý để sắp xếp lại trật tự gói và cả sự thay đổi trong
thời gian xử lý đóng hay tách gói trong quá trình truyền.
Ngoài ra, tính khả dụng (availability) cũng là một chỉ tiêu xác định chất lượng
dịch vụ của một mạng. Lý tưởng thì một mạng phải khả dụng trong 100% thời
gian. Ngay cả một mạng có chỉ số này cao 99,8 %, có thời gian bất khả dụng
khoảng một hay nữa giờ một tháng, có lẽ không thể chấp nhận đối với một doanh

nghiệp lớn. Các nhà cung cấp dịch vụ đặc biệt tin cậy phải đảm bảo chỉ số khả
dụng là 99,9999% hay còn gọi là “sáu số chín” (six nines), chỉ cho phép mất dịch
vụ khoảng 2,6 giây mỗi tháng.
Để các hệ thống truyền thoại và video qua IP làm việc hiệu quả thì thông lượng
phải càng lớn càng tốt trong khi độ trễ, độ tổn thất và độ biến động trễ phải ở mức
tối thiểu. Độ trễ nhỏ giúp cho một hội nghị qua mạng trở nên tự nhiên, ngược lại
nếu độ trễ quá lớn sẽ tạo ra sự ngắt quãng trong các câu hội thoại. Một độ biến
động trễ quá lớn khiến cho các gói đến trong một trật tự sai gây méo dạng âm
thanh và hình ảnh, hiện tượng tương tự sẽ gặp phải khi tổn thất gói lớn hơn 1%.
Chuẩn G.114 của ITU-T khuyến nghị rằng độ trễ không nên lớn hơn 150 ms. Tuy
nhiên, độ trễ đến 200ms cũng có thể chấp nhận được bởi hầu hết người dùng. Còn
jitter thì không nên lớn hơn 20 đến 50 ms. Độ trễ từ đầu cuối đến đầu cuối không
nên vượt quá một trăm mili giây. Tổng thời gian bao gồm trễ lan truyền từ nguồn
đến đích và thời gian xử lý tại các thiết bị, do đó không nên vượt quá 300 mili
giây. Bằng không, người dùng sẽ dễ dàng cảm nhận được sự trễ, đặc biệt là trong
quá trình hội thoại sẽ gây ra khó chịu.
Qui hoạch mạng là công cụ để đảm bảo các tham số nói trên ở trong một giới hạn
cần thiết để cung cấp một mức QoS có thể chấp nhận. Công việc phải tính đến bản
chất tự nhiên của hạ tầng mạng (dung lượng vật lý và các giao thức được dùng tại
lớp 1, lớp 2 và lớp 3 trong mô hình tham chiếu liên kết hệ thống mở OSI) và tri
thức về khi nào các tài nguyên mạng được chia sẻ. Các đặc tính của ứng dụng, của
đầu cuối, kỹ thuật mã hóa và nén…là ngoài phạm vi kiểm soát của nhà cung cấp
dịch vụ mạng, nên chuyên đề này chỉ đề cập đến góc độ ảnh hưởng của mạng.
2. Phương thức căn bản hỗ trợ QoS
Hầu hết các mạng hiện hữu đều được thiết kế cho các ứng dụng số liệu mà không
yêu cầu phẩm chất về thời gian thực (real time). Vì âm thanh và video phải được
tiếp nhận theo thời gian thực nên QoS phải được thiết kế cho mạng này. Có ba
5
khái niệm cơ bản ảnh hưởng truyền số liệu phải được xem xét trong khi thiết kế
mạng IP cho số liệu âm thanh và video, đó là cung ứng mạng (network

provisioning), xếp hàng (queuing) và phân loại (classifying).
Cung vượt cầu (Over provision)
Giải pháp phổ biên nhất cho QoS ngày nay là over-provision băng thông mạng.
Over-provision chỉ đơn giản là xây dựng cho mạng lượng băng thông hay dung
lượng nhiều hơn nhu cầu thực tế cho audio, video và các ứng dụng thường xuyên
chạy trên mạng.
Có hai mức băng thông của Ethernet được triển khai bên trong mạng doanh nghiệp
là 10 Mbps và 100 Mbps, trong khi kết nối T-1 có dung lượng 1,5 Mbps thường
được dùng nối mạng diện rộng cho doanh nghiệp hay liên mạng vào Internet.
Truyền thông đa phương tiện có thể tiêu thụ lượng băng thông đáng kể trên mạng
doanh nghiệp và cung ứng mạng là một phần quan trọng của bất kỳ qui hoạch nào
để thi công mạng đa phương tiện. Giải pháp rẻ tiền và bước đầu tiên được thực
hiện trong bất kỳ môi trường truyền thông đa phương tiện nào là nâng băng thông
mạng bằng cách chuyển sang kiến trúc chuyển mạch. Kế đến là dùng mạng
Ethernet 100 Mbps, bằng cách phân đoạn mạng LAN thành nhiều mạng con sao
cho băng thông khả dụng được chia sẻ bởi số lượng máy trạm nhỏ hơn.
Hình 1- Cung cấp băng thông cho mạng
Một số cuộc gọi IP chất lượng cao có thể được cấu hình để dùng băng thông 768
kbps hay cao hơn. Con số kbps này liên hệ đến lượng dữ liệu thực tế được truyền
bởi mỗi máy trạm. Khi thiết kế mạng có QoS, cũng cần phải xem xét thông tin
overhead của mạng. Một cuộc gọi video dùng xấp xỉ 20% overhead. Do đó, một
cuộc gọi được thực hiện với tốc độ 786 kbps có thể tiêu thụ thực sự đến 920 kbps
trên mạng. Với mức băng thông này, chỉ một cuộc gọi có chất lượng đảm bảo trên
một kết nối T-1 qua mạng WAN này.
T-1
Cable/DSL
ISDN
6
Như là điều luật tiên quyết, băng thông tối đa được yêu cầu cho tất cả các ứng
dụng cộng lại với nhau, bao gồm thoại và video không vượt quá 75% băng thông

khả dụng. Tóm lại, cung cấp cho mạng một lượng bổ sung là cần thiết, tuy nhiên
bản thân cung ứng mạng vẫn chưa đủ đảm bảo một QoS thích hợp.
Xếp hàng (Queuing)
Đệm dữ liệu là yếu tố QoS quan trọng, các bộ đệm truyền trong các thiết bị mạng
có xu hướng bị làm đầy nhanh chóng trong các mạng tốc độ cao. Điều này gây nên
hiện tượng mất gói, khiến cho âm thanh hay video bị cắt xén.
Có thể khắc phục các yếu kém trong việc đệm dữ liệu bằng cách xếp hàng số liệu
âm thanh và video một cách riêng biệt bên trong các thiết bị mạng. Các hàng đợi
riêng biệt cho phép truyền các số liệu khắc khe về thời gian như âm thanh và video
theo phương thức ưu tiên (hình 2). Để làm việc này, số liệu phải được phân loại
thành ra một số ưu tiên nào đó trước khi đưa vào thiết bị truyền. Căn cứ vào sự
phân loại, gói được xếp vào một hàng đợi truyền phù hợp; số liệu âm thanh hay
video được phân loại sao cho chúng được xếp vào một hàng đợi nhạy cảm với trễ
và với tổn thất gói. Điều này có nghĩa là bất kỳ số liệu nào đến một cách đồng thời
với âm thanh hay video có thể bị mất. Tuy nhiên, vì số liệu thông thường không
phải theo thời gian thực nên dữ liệu bị mất sẽ được truyền lại mà không làm ảnh
hưởng luồng dữ liệu bình thường trên mạng. Kỹ thuật hàng đợi cung cấp mức ưu
tiên cao cho số liệu âm thanh và video nhạy cảm với trễ và tổn thất nhằm đảm bảo
cho các gói dữ liệu này được truyền lại một cách kịp thời.
Các thiết bị Hub không hỗ trợ kỹ thuật xếp hàng do đó dẫn đến gia tăng đụng độ
gói, từ đó gây ra trễ và mất gói. Vì vậy các thiết bị Switch hay Router thường
được dùng để thay thế các Hub trong thiết kế mạng có hỗ trợ QoS.
7
Hình 2- Hàng đợi riêng cho các lưu lượng yêu cầu nghiêm ngặt về trễ và mất gói.
Phân loại (classifying)
Kỹ thuật xếp hàng được cho phép bởi một số lược đồ phân loại hay ưu tiên gói.
Một vài lược đồ khác nhau đang được dùng hiện nay bao gồm RSVP (Resource
Reservation Protocol), IP precedence, DiffServ (differentiated services) và MPLS
(Multi-Protocol Label Switching).
RSVP là một giao thức dựa vào luồng (flow-based protocol) đảm bảo chất lượng

dịch vụ cho mỗi luồng dữ liệu. Mỗi luồng dữ liệu đơn hướng giữa hai ứng dụng
được xem một luồng tách biệt. Trong một hội nghị video thông thường sẽ có bốn
luồng: truyền audio, nhận audio, truyền video và nhận video. Trong thực tế, RSVP
tỏ ra nặng nề và kồng kềnh khi thực hiện. Lý do là mỗi thiết bị dọc theo đường
truyền của luồng bao gồm các server, PC, router, switch…phải có thể báo hiệu các
nhu cầu QoS được đặc tả trong RSVP. Do đó, RSVP rất khó mở rộng ra với các
qui mô mạng rất lớn.
IP precedence và DiffServ dựa trên các cơ cấu tương tự nhau để cung cấp QoS, ở
đó một vài bit bên trong header của gói số liệu sẽ được hiệu chỉnh. Khi đến một
thiết bị mạng có hỗ trợ IP precedence hay DiffServ, các gói với các bit header
được cài đặt thích hợp được xếp vào một hàng đợi ưu tiên tương ứng và được
truyền đi. Với IP precedence và DiffServ, mạng phải được thiết kế sao cho lược đồ
được hiện thực một cách nhất quán trong toàn mạng. Các nhà cung cấp dịch vụ
TX
RX
RX
RX
RX
Data
Data
Data
Audio/Video
Hàng đợi cho các
dịch vụ nhạy cảm
với trễ và mất gói
Thiết bị Router/Switch
8
đang triển khai cung cấp các lớp dịch vụ theo các mức QoS khác nhau tùy vào sự
phân loại của DiffServ.
Các router chuẩn đưa ra các quyết định chuyển gói bằng cách thực hiện nhiệm vụ

phức tạp là dò tìm thông tin định tuyến căn cứ vào địa chỉ IP đích trong mỗi gói.
Mỗi router sẽ thực hiện công việc một cách độc lập bằng cách phân tích header gói
và chuyển gói từ router này đến router kế cho đến khi gói đến được đích sau cùng.
Việc chọn bước chuyển kế tiếp cho một gói căn cứ vào phân tích header của gói
và từ kết quả thực thi một thuật toán định tuyến. Giải pháp này đôi khi không đủ
để hỗ trợ cho các nhu cầu mạng ngày nay, vì các router có thể trở thành các cổ
chai của QoS, ngay cả khi IP precedence và DiffServ được dùng. MPLS định
nghĩa một giải pháp để cải thiện và đơn giản chức năng chuyển gói và để cung cấp
sự đảm bảo QoS. MPSL được thiết kế để mang tốc độ của lớp 2 trong mô hình
OSI lên lớp 3 trong mô hình này. Mỗi gói được gán một nhãn định tuyến căn cứ
vào một vài yếu tố bao gồm ưu tiên của gói và đích sau cùng. Chuyển mạch dựa
vào nhãn là nhanh vì nó cho phép các router đưa ra các quyết định chuyển dựa vào
nội dung của một nhãn đơn giản thay vì phải thực hiện nhiệm vụ dò tìm phức tạp.
MPLS mang lại một số ưu điểm khác cho các mạng dựa vào IP bao gồm đảm bảo
QoS gần như RSVP. Tuy nhiên, chỉ một ít mạng MPLS được triển khai ngày nay
vì các đặc tả vẫn còn thay đổi.
3. Các cơ chế kiểm soát chất lượng mạng phổ biến
Qui họach mạng nhằm thiết kế một mạng để hỗ trợ một hỗn hợp các dịch vụ cho
một số các user nào đó với các QoS có thể chấp nhận theo hợp đồng mức dịch vụ
SLAs (Service Level Agreements). Dịch vụ càng phức tạp và càng nhiều chọn lựa
QoS cho user thì qui họach mạng càng phức tạp.
Hiện nay có 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
-Ưu tiên hóa các dịch vụ và user
3.1. Cung cấp dung lượng vượt yêu cầu
Cung cấp lượng băng thông vượt mức yêu cầu là cơ chế tốn kém nhất, vì hai cơ
chế kia hoạt động theo nguyên lý chỉ dùng một số tối thiểu dung lượng để đáp ứng
cho các hợp đồng (SLAs). Tuy nhiên, có vài yếu tố khiến cho giải pháp này trở

nên hấp dẫn:
9
-Chi phí cho băng thông trên đường trục đang giảm, vì:
+Cung ứng về cáp đường dài trên mặt đất hiện nay là vượt quá nhu
cầu.
+Với công nghệ DWDM, một khi các thiết bị đầu cuối đã được bán,
thì giá thành cho một bước sóng bổ sung hầu như rất thấp.
-Qui họach mạng đơn giản. Tính toán khi nâng cấp chỉ đơn giản là khi dung
lượng nhiều hơn m% dung lượng khả dụng trong một khoảng thời gian được chỉ
định thì gia tăng dung lượng của tuyến lên n%.
-Việc cung ứng có thể được hoạch định. Dung lượng truy xuất từ các nhánh
hoàn toàn biết được và tổng tôc độ số liệu không thể vượt quá tổng các liên kết
truy xuất. Khi tiếp nhận nhu cầu về các liên kết truy xuất nhanh hơn, có thể đưa ra
quyết định có cần phải nâng cấp dung lượng đường trục hay không.
Đây là giải pháp được dùng hầu hết trong các mạng đường trục IP (ví dụ giữa các
ISP mức 1). Giả sử dung lượng luôn luôn thỏa mãn cho giải pháp này, các gói IP
có thể được nạp vào trong các frame truyền (ví dụ SONET) khi chúng đến, độ trễ
và biến động trễ gây ra bởi độ trễ hàng đợi khác nhau trong quá trình truy xuất
đường trục là nhỏ. Yếu tố lớn nhất ảnh hưởng đến trễ là thời gian lan truyền dọc
theo cáp. Tuy nhiên, trong các mạng truy nhập ngoại vi thường không được lắp đặt
nhiều cáp sợi quang, do đó dung lượng nhìn chung là bị hạn chế. Trong bối cảnh
như vậy, để hỗ trợ QoS cao hơn “Best Effort” thì điều cần thiết là có thể phục vụ
phần lưu lượng nào đó tốt hơn là các phần còn lại bằng cách đăng ký tài nguyên
một cách đặc biệt hay bằng cách xử lý ưu tiên cho chúng.
3.2. Đăng ký trước tài nguyên
3.2.1. ATM (Asynchronous Transfer Mode)
ATM là kỹ thuật đầu tiên được thiết kế để truyền nhiều loại dịch vụ với QoS có
thể dự báo trước. Các đặc tả ATM định nghĩa các lớp dịch vụ (CBR, VBR (rt và
nrt), ABR, UBR) trong đó bất kỳ ứng dụng truyền thông nào đều có thể ánh xạ
vào. Đặc tính của các lớp dịch vụ này có thể được định lượng chính xác, đảm bảo

hỗ trợ QoS. ATM đưa ra các khái niệm mới như chuyển mạch nhanh sử dụng
chiều dài gói cố định, được gọi là cell, khái niệm mạch ảo (Virtual Circuit)/ đường
dẫn ảo (Virtual Path) và tổ chức phân cấp động và định tuyến dùng giao thức
PNNI (Private Network Node Interface).
User (qua ứng dụng hay dịch vụ) phải thông báo các nhu cầu của mình cho mạng
thông qua một tiến trình báo hiệu tiền kết nối. Một khi yêu cầu kết nối đã được
chấp nhận, tất cả các cell thuộc về một cuộc gọi sẽ chạy theo cùng một đường dẫn.
10
Trong chừng mực nào đó vì các nhu cầu cho một giao thức báo hiệu tiền kết nối
giữa user và mạng và sự phức tạp của báo hiệu, quản lý lưu lượng và phân phối tài
nguyên và đặc biệt là ưu thế nổi trội của giao thức IP trong các ứng dụng số liệu
và đa phương tiện dựa vào máy tính cá nhân, mà ATM đã không thành công trong
việc trở thành một giao thức đơn lẻ cho sự hội tụ của các mạng và các ứng dụng.
3.2.2. IP-IntServ
Ngay từ đầu Internet không phân biệt giữa các lớp dịch vụ khác biệt. Giao thức IP
về cơ bản là một giao thức best-effort trong đó không có sự đảm bảo nào khi phân
phối các gói số liệu. Sự xác nhận gói số liệu đã đến được đích là trách nhiệm thuộc
về một giao thức lớp trên (TCP) trong mô hình tham chiếu liên kết các hệ thống
mở OSI.
Nếu có bất kỳ gói số liệu nào không đến được đích ( được xác định bởi sự kiểm tra
chỉ số tuần tự của các gói tại đích), TCP yêu cầu truyền lại gói bị mất, do đó đảm
bảo tất cả các gói sau cùng đều đến được đích. Điều này trông hiệu quả nhưng rất
chậm. Do đó, TCP thường được dùng cho các ứng dụng không nghiêm ngặt về
thời gian.
Các ứng dụng thời gian thực không thể chấp nhận TCP, thời gian cần để theo dõi
các gói bị mất và truyền lại chúng là không thể chấp nhận được trong trường hợp
này. Vì vậy các ứng dụng này dựa vào những gì mà về cơ bản là một phiên bản
giản lược của TCP được gọi là UDP (User Datagram Protocol), UDP chạy nhanh
hơn TCP bởi bỏ qua một số chức năng của nó. Các ứng dụng chạy qua UDP phải
có những chức năng bị bỏ sót này hoặc có thể làm việc mà không cần đến các

chức năng đó.
Trong trường hợp truyền thoại, các gói truyền lại mất thời gian lâu sẽ không còn
giá trị, vì vậy các gói bị mất bị bỏ qua. Do đó, điện thọai IP chỉ làm việc qua mạng
hoàn toàn tin cậy để bắt đầu với nó, như các mạng dựa vào cáp sợi quang với các
switch và router hiện đại.
Integrated service (IntServ) là thủ tục đầu tiên được đặc tả bởi IETF để hỗ trợ
QoS. IntServ gán một luồng số liệu đặc biệt vào khái niệm được gọi là lớp lưu
lượng (traffic class), lớp lưu lượng định nghĩa một mức dịch vụ nào đó. Ví dụ, có
thể yêu cầu chỉ best-effort hay có thể chấp nhận một giới hạn về độ trễ. Khi một
lớp dịch vụ đã được gán cho một luồng số liệu, một thông điệp PATH (hình 3)
được chuyển đi đến đích để xác định mạng có tài nguyên khả dụng hay không
(dung lượng truyền, không gian bộ đệm…) để hỗ trợ lớp dịch vụ này. Nếu tất cả
các thiết bị dọc theo đường dẫn đều thấy rằng có khả năng cung cấp tài nguyên
theo yêu cầu, máy đích sẽ phát ra thông điệp RESV gửi đến nguồn để thông báo
rằng có thể bắt đầu truyền số liệu. Thủ tục này, được biết đến như là RSVP đã
11
được đề cập ở trên, được lặp lại để xác nhận tài nguyên cần thiết vẫn còn khả
dụng. Nếu tài nguyên yêu cầu không còn khả dụng nữa, máy thu sẽ gửi một thông
điệp báo lỗi RSVP đến máy phát.
Hình 3- Mô hình tham chiếu IntServ với RSVP.
Theo lý thuyết thì việc kiểm tra liên tục này có nghĩa là tài nguyên mạng được
dùng một cách hiệu quả. Khi tài nguyên khả dụng chỉ còn ở một mức tối thiểu, cá
dịch vụ với nhu cầu QoS nghiêm ngặt sẽ không nhận được thông điệp RESV và sẽ
biết rằng QoS không được đảm bảo. Tuy vậy, dẫu cho IntServ có một số khía cạnh
hấp dẫn, nó vẫn có các vấn đề nội tại. Ví dụ, nó không có phương cách để đảm
bảo các tài nguyên cần thiết sẽ khả dụng khi cần đến. Hơn nữa, nó đăng ký tài
nguyên mạng trên căn bản từng luồng số liệu, nếu nhiều luồng từ một điểm tập
trung nào đó, giả sử một server truyền thông trên mạng cục bộ, tất cả đều yêu cầu
cùng một tài nguyên thế nhưng các luồng được phục vụ một cách riêng rẻ. Thông
điệp RESV phải được gửi đi một cách riêng biệt cho mỗi luồng. Nói cách khác,

IntServ không linh động và lãng phí tài nguyên mạng.
3.3. Ưu tiên hóa các dịch vụ và user
3.3.1. IP-DiffServ
Thực chất QoS rất phong phú về ưu tiên. Tại các điểm tập hợp trên mạng như
router, bộ ghép kênh và chuyển mạch, các dòng số liệu với nhu cầu QoS khác
nhau được kết hợp lại để truyền qua hạ tầng mạng chung. Việc hỗ trợ QoS đúng
12
mực có hai yêu cầu chính: một phương tiện để đánh dấu các luồng theo ưu tiên
của nó và cơ chế mạng để nhận dạng và tác động lên chúng.
Với mô hình DiffServ của IETF, một thẻ nhỏ được gắn vào mỗi gói tùy vào lớp
dịch vụ của nó. Các luồng số liệu có cùng nhu cầu tài nguyên có thể được gom lại
trên cơ sở thẻ nhận dạng này khi chúng đến router biên (edge router). Các router
trong mạng lõi (core) sẽ chuyển luồng số liệu đến đích dựa trên các thẻ định dạng
mà không cần kiểm tra chi tiết các header của từng gói. Vì hầu hết quyết định
chuyển được đưa ra đều theo nguyên tắc này nên mạng lõi làm việc rất nhanh. Cơ
chế này còn được gọi là IP-friendly, trong đó nó không yêu cầu một thủ tục báo
hiệu trước nào để truyền số liệu.
Trong quá khứ, qui hoạch QoS hỗ trợ cả IntServ và DiffServ. Hiện nay khuynh
hướng nghiên về dùng DiffServ kèm theo các bổ sung về khả năng đăng ký tài
nguyên của RSVP tại biên. Tại các biên của mạng, tài nguyên có xu thế hạn hẹp
hơn nên không có nhiều luồng số liệu được duy trì.
3.3.2. IP-MPLS
Một giải pháp tương tự để tăng tốc độ truyền số liệu qua mạng là MPLS
(Multiprotocol Label Switching), cũng là một thủ tục được đề xuất bởi IETF đã
được giới thiệu ở phẩn trên. Trong hoạt động IP thông thường, header của gói
được kiểm tra tại các điểm trung chuyển (mutiplexer, router hay switch). Điều này
tốn nhiều thời gian và bổ sung vào tổng thời gia trễ. Giải pháp hiệu quả hơn là
đánh nhãn (label) cho các gói sao cho việc phân tích các gói tại các điểm trung
gian là không còn cần thiết nữa. MPLS thực hiện điều này bằng cách gắn nhãn
thích hợp cho các gói IP tại đầu vào của các router biên trong mạng cho phép

MPLS. (hình)
Lưu lượng của một dạng nào đó có thể được nhóm lại trên một đường chuyển
mạch nhãn đặc biệt, các kỹ thuật của công nghệ lưu lượng được áp dụng vào
đường dẫn này để có một dung lượng nhằm đảm bảo một mức phẩm chất nào đó
cho dịch vụ.
Thủ tục MPLS làm việc như sau: router biên kiểm tra gói đến trên cơ sở địa chỉ
nguồn, địa chỉ đích và mức ưu tiên và quyết định nơi kế tiếp để chuyển gói đến.
Nó cũng gắn một nhãn 32 bit cho gói. Nhãn này còn được gọi là nhãn MPLS
(MPLS label), có chứa thông tin như gói có được xử lý như lưu lượng MPLS hay
được định tuyến như một gói IP thông thường; nó phù hợp với IPv4 hay IPv6; giá
trị time-to-live và bước kế tiếp sẽ đến. Sau đó router biên chuyển gói đến router kế
tiếp.
13
Đến lượt, router kế tiếp cũng kiểm tra nhãn MPLS và quyết định bước kế tiếp cho
gói. Router thứ hai này cũng tạo ra một nhãn thứ hai. Hai nhãn sẽ được trao đổi
trước khi gói được chuyển đi tiếp. Quá trình này sẽ được lặp lại cho đến khi gói
đến được đích. Thủ tục này có hai ưu điểm nổi trội so với định tuyến IP thông
thường, đó là:
-Các router dọc đường đi của gói không cần phân tích toàn bộ header của
gói, chỉ cần kiểm tra một nhãn ngắn gọn. Điều này tiết kiệm nhiều thời gian.
-Việc trao đổi nhãn tạo ra dấu vết đăng ký của các router mà các gói khác
trong cùng một phiên có thể theo. Một khi gói đã thiết lập được một đường dẫn,
các điểm trung gian không cần phải đưa ra quyết định nữa. Điều này giúp tăng tốc
độ truyền lên rất nhiều.
Nhiều nhà cung cấp dịch vụ đã cài đặt các router biên theo MPLS và tung ra các
dịch vụ MPLS. Cable & Wireless đã bắt đầu cung cấp MPLS cho các liên kết vượt
đại dương, nối New York và Washington DC với London, Amsterdam và
Frankurt. Công ty này đưa ra MPLS trên cơ sở mạng quang OC-192 (9,953
Gbit/giây) vào cuối năm 2001.
4. Kiến trúc DiffServ

4.1. Giới thiệu
DiffServ [1], [2] 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 nhau cho khách hàng cũng như cho các dòng lưu
lượng mạng của họ. DiffServ được dự trù là một môi trường để phân biệt dịch vụ
khả thi và cho phép một giải pháp module hóa các mục tiêu QoS cho các nhu cầu
khác nhau của ứng dụng.
Cơ sở của các mạng DiffServ là các router bên trong mạng lõi có khả năng chuyển
các gói của các luồng lưu lượng khác nhau theo cách ứng xử trên từng bước mạng
(per hop behaviors hay PHB) khác nhau. DiffServ đưa ra khái niệm DiffServ Code
Point hay viết tắt là DSCP, dùng 6 bit của trường TOS trong header của gói IP và
do đó có thể chỉ định đến 64 giá trị mã khác nhau [2]. PHB của gói được chỉ ra bởi
mã DSCP. Kiến trúc DiffServ không dùng bất kỳ sự báo hiệu nào giữa các router,
tất cả các quyết định chuyển gói đều dựa theo mã DSCP.
Kiến trúc DiffServ chứa hai thành phần chính. Một là nguyên tắc ứng xử
(behavior) công bằng phổ quát trên đường dẫn chuyển gói 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 [1].
Kiến trúc DiffServ có thể được xem như là bộ tinh chế của mô hình quan hệ ưu
tiên trong đề xuất đánh dấu ưu tiên IPv4 được định nghĩa trong [1], [3]. Kiến trúc
14
này hoàn toàn có thể làm việc với các ứng dụng hiện hữu mà không yêu cầu bất cứ
thay đổi nào đối với API (Application Programming Interface) của chúng.
Chất lượng hay mức đảm bảo theo thống kê của một dịch vụ có thể bị ảnh hưởng
nếu lưu lượng quá cảnh qua một nút mạng hay domain mạng không cho phép
DiffServ [1].
4.2. PHB (per-hop behavior)
Mỗi PHB là một mô tả về thái độ ứng xử trong việc chuyển gói của một DiffServ
node có thể quan sát được từ bên ngoài đối với một BA (Behavior Aggregate) đặc
biệt nào đó [1]. PHB như là định nghĩa các tài nguyên được phân phối cho một
BA. Các tài nguyên có thể được xem xét bao gồm băng thông khả dụng của liên
kết, không gian bộ đệm trên router và chính sách hàng đợi, độ trễ và tổn thất gói.

PHB được hiện thực trong các node bằng công cụ quản lý bộ đệm và cơ chế lập
lịch gói. Định nghĩa PHB không phụ thuộc vào cơ chế cung cấp dịch vụ nhưng về
các đặc tính ứng xử thì có liên quan đến chính sách cung ứng dịch vụ [1].
4.3. DiffServ domain
Kiến trúc Diffserv có cơ sở là một mạng được xây dựng thành một hệ tự quản
hoàn chỉnh (Autonomous System) hay domain. Tất cả lưu lượng phù hợp vào ra
domain đều được quản lý bởi các luật lệ nhất quán và chặt chẽ. Theo [1] lưu lượng
vào mạng tại các router biên (edge router) đều được phân loại và gán vào các
nhóm khác nhau gọi là các Behavior Aggregate (BA). Các gói thuộc về một BA
nào đó sẽ được chuyển đi theo qui tắc đã xác định trước. Như vậy, thực chất là tạo
ra các lớp (class) chứa các luồng (flow), mỗi luồng được tiếp đón với một động
thái tùy theo lớp mà nó thuộc về. Cung cách phục vụ của các diffserv router đối
với các class vì thế cũng được xác định rõ, và được cụ thể hóa thành các PHB
(per-hop-behavior). Các PHB được hiện thực thông qua sự phân phối tài nguyên
khác nhau trong router.
4.3.1. DiffServ Node
Một DiffServ domain bao gồm một tập hợp các DiffServ node có thể cung cấp các
dịch vụ thông thường và có một tập các PHB được hiện thực bên trong mỗi node.
DiffServ domain có hai loại node: node nằm tại biên gọi là edge node của domain
và node nằm bên trong domain gọi core node. Các edge node kết nối DiffServ
domain với domain khác còn các core node chỉ kết nối đến các node trong nội bộ
domain (hình 4)
15
Hình 4- Ví dụ một DiffServ domain.
Tất cả các node của DiffServ domain đều phải có thể áp dụng PHB thích hợp cho
các gói đến, tùy theo mã DSCP. Các edge node được yêu cầu thực hiện chức năng
điều chỉnh lưu lượng khi chức năng này bị hạn chế trong các core node bên trong.
4.3.2. Node ngõ vào và node ngõ ra (Ingress node và Egress node)
Các edge node đóng cả hai vai trò node ngõ vào (ingress node) và node ngõ ra
(egress node), tùy theo hướng của lưu lượng. Một node nguồn đảm bảo rằng dòng

lưu lượng đến phù hợp với bất kỳ đặc tả mức dịch vụ nào giữa nó và domain khác
nối với nó (hình). Tại các edge node, các thành phần xử lý lưu lượng theo kiến
trúc DiffServ được thực hiện như bộ phân loại (classifier), bộ đo lường (meter), bộ
đánh dấu (marker) và bộ chỉnh dạng hay hủy gói (shaper/dropper) (hình 5).
Hình 5- Hai router đóng vai trò là ngõ vào và ngõ ra của một luồng lưu lượng.
CoreCore
Core EdgeEdge Core
Edge
NodeEdge
Node
Node
Domain
Ingress node
Classifier, meter,
marker,
shaper/dopper
Các Core
router
Egress node
Classifier,
meter, marker,
shaper/dropper
Router A Router B
16
4.4. Phân loại và điều chỉnh lưu lượng (Classification và Conditioning)
4.4.1. Các nguyên tắc phân loại và điều chỉnh lưu lượng
DiffServ được kéo dài xuyên qua phạm vi một domain bằng cách kết nối qua một
đặc tả mức dịch vụ SLS (Service Level Specification) giữa mạng nguồn và
DiffServ domain đích. Một đặc tả điều chỉnh lưu lượng TCS (Traffic Conditioning
Specification) là một phần tử thuộc về SLS. Các thông số của TCS và các giá trị

của chúng cùng nhau chỉ ra các qui luật phân loại và đặc tính của lưu lượng.
Dịch vụ khác biệt được phân loại, điều chỉnh và ánh xạ vào một hay nhiều BA
(behavior aggregate) trong DiffServ domain. Các bộ điều chỉnh lưu lượng luôn
nằm tại các node biên để cho các node bên trong không cần thực hiện bất kỳ công
việc điều chỉnh nào.
4.4.2. Phân loại lưu lượng
Bộ phận phân loại xếp các gói theo các mã DSCP. Cơ sở cho phân loại là một bộ
lọc theo DSCP của mỗi gói. Các bộ lọc hình thành theo các nhóm lọc và tạo thành
một bộ phân loại. Tại đầu vào mỗi gói được kiểm tra theo bộ phân loại đầu vào và
ở đầu ra chúng lại được kiểm tra theo bộ phân loại đầu ra trên giao tiếp. Kết quả
phân loại được đưa đến bộ phận đo lường (metter) và gói được xử lý theo cách
phù hợp.
Thứ tự của bộ lọc trong bộ phân loại là cố định và nếu gói phù hợp với một bộ lọc
của nhóm lọc trước thì không cần lọc ở các bộ lọc sau. Mỗi bộ phân loại phải có
thể phân loại tất cả các khả năng [4].
Kiểu phân loại khác là dựa trên giá trị của sự kết hợp của một hay nhiều trường
(field) của header gói IP, như địa chỉ nguồn và đích, port nguồn và đích, danh định
của giao thức và thông tin khác như giao tiếp đầu vào. Mô hình thông tin quản lý
(Managemnet Information Model) bao gồm một định nghĩa một IP Six-Tuple
Classifier [5]
4.4.3. Điều chỉnh lưu lượng
Điều chỉnh lưu lượng bao gồm đo lường (metering), định chế (policing), sửa dạng
(shaping) và đánh dấu lại để đảm bảo rằng luồng lưu lượng vào DiffServ domain
thỏa mãn các luật được đặc tả trong SLS. Các chính sách điều chỉnh lưu lượng
được thỏa thuận giữa các mạng và thay đổi từ đánh dấu lại một cách đơn giản đến
các hoạt động sửa dạng và định chế phức tạp.
17
Các bộ điều chỉnh lưu lượng có thể bao gồm meter, marker, shaper và droper. Các
gói được hướng dẫn đi từ bộ phân loại lưu lượng đến bộ điều chỉnh lưu lượng
(hình 6).

Hình 6- Cấu trúc luận lý của bộ phân loại và điều chỉnh lưu lượng.
Trong hình 6 các gói được dẫn ra khỏi bộ phân loại đến meter hay marker. Bộ đo
lường (meter) đo lường tốc độ mà gói của một BA đi qua nó, được dùng để đo
dòng lưu lượng căn cứ vào profie của lưu lượng. Profile chỉ ra các đặc tính tạm
thời của lưu lượng và là một thành phần tùy chọn của TCS [RFC2475]. Bộ đánh
dấu (marker) bổ sung gói vào một BA thích hợp tùy theo DSCP. DSCP có thể bị
thay đổi bởi marker, gọi là đánh dấu lại. Bộ chỉnh dạng (shaper) sửa dạng dòng
lưu lượng để phù hợp với đặc tính lưu lượng được dùng. Shaper cũng có thể đóng
vai trò của một bộ hủy gói (dropper) bằng cách hủy bỏ các gói để dòng lưu lượng
phù hợp với đặc tính ghi trong profile.
5. Đánh giá hiện trạng về cung cấp QoS cho mạng IP
Lược đồ quan trọng cung cấp QoS cho các ứng dụng trong mạng IP trước đây là
Integrated Servive (IntServ). Ý tưởng chính của lược đồ này là dùng một giao thức
đặc biệt RSVP để đăng ký và quản lý tài nguyên mạng cho mỗi phiên [9]. Các
router phải giữ thông tin trạng thái của tất cả các phiên IntServ đang hoạt động và
dùng thông tin này để lọc dòng lưu lượng [10]. Tuy nhiên, cơ cấu này sớm tỏ ra
nặng nề và phức tạp thậm chí còn phức tạp hơn cả các cơ chế QoS của ATM [6],
[7],[8]. Các tác giả của RSVP đã thừa nhận rằng các mô phỏng đã thực hiện với
các mô hình mạng rất nhỏ và số lượng kết nối giới hạn. Hơn nữa, IntServ đã vi
phạm nguyên tắc của IP đó là phi trạng thái (satelessness). RSVP dùng khái niệm
gọi là trạng thái mềm (soft state), một cho mỗi kết nối, trạng thái mềm phải được
làm tươi định kỳ. Ngoài ra, IntServ cũng đòi hỏi thiết kế lại các giao thức IP chính
để đảm bảo hiệu quả hơn. Khác với ATM, IntServ không thể thay đổi các tuyến
Bộ phân loại
gói (classier)
metter
marker Shaper/dropper
Luồng gói IP
18
nếu đường dẫn ngắn nhất không có dung lượng cho một kết nối mới. Tất cả những

điều đó chứng tỏ các hệ thống IntServ qui mô lớn là không thể khả thi.
Ngày nay, xu thế hỗ trợ các ứng dụng thời gian thực trong các mạng IP là dùng
lược đồ DiffServ [11]. Các nhu cầu về QoS được chuyển sang một khái niệm mới
gọi là cấp dịch vụ GoS (Grade of Service). Ý tưởng ở đây là cung cấp các loại
dịch vụ khác nhau cho từng loại lưu lượng khác nhau, đó là cung cấp một dịch vụ
tốt hơn cho các ứng dụng nhạy cảm với trễ. Hơn nữa, các lược đồ khác nhau để
tương tác với các phiên TCP bằng quản lý bộ đệm hay lập lịch được tạo ra để giảm
khả năng tắc nghẽn và chia sẻ tài nguyên công bằng hơn. Tuy nhiên, DiffServ
không thành công trong việc cung cấp end-to-end QoS vì chưa có phương pháp
để kiểm soát GoS giữa các mạng khác nhau. Ngoài ra, phương thức cho các ứng
dụng của user yêu cầu một GoS nào đó vẫn chưa rõ ràng vì không có điều khiển
chấp nhận kết nối, CAC (connection admission control). Một giải pháp được theo
đuổi trong thời gian gần đây là dùng khái niệm gọi là Bandwidth Broker để kiểm
soát một vài mức CAC. Tuy nhiên, vào lúc này chưa thể khẳng định một hệ thống
như vậy là đủ linh hoạt và chịu lỗi được hay không.
Với các đặc tính như hiện nay, DiffServ không đủ khả năng giải quyết bài toán
chia sẻ tài nguyên giữa các luồng TCP đang hoạt động. Tài nguyên vẫn bị chia sẻ
không công bằng bên trong mỗi tập hợp lưu lượng và cũng xuất hiện vấn đề mới
liên quan đến chia sẻ tài nguyên giữa các tập hợp lưu lượng khác nhau [12]. Để
khắc phục các vấn đề tồn tại của DiffServ, các cơ chế lập lịch và quản lý bộ đệm
đã được phát triển với hy vọng sẽ giải quyết được các bài toán khó nêu trên. Các
cơ chế này được xây dựng trên cơ sở tin tưởng rằng động thái của cơ chế điều
khiển luồng TCP sẽ trở nên tích cực hơn nếu bỏ đi nguyên lý quản lý hàng FIFO
truyền thống (First In First Out) hay tail-drop. Tuy nhiên, điều khó khăn là nhiều
lược đồ quản lý bộ đệm không khả thi trong môi trường hệ thống thực, ví dụ RED
(random early detection)[13]. Gần như rất khó chọn được các tham số RED mà
chất lượng mạng không bị ảnh hướng xấu [14],[15].
DiffServ đang rất cần một hệ thống điều khiển nghẽn hoàn hảo hơn với các cơ chế
lập lịch, quản lý bộ đệm, phản hồi nghẽn và cả điều chỉnh đầu cuối.
19

Tài liệu tham khảo
[1]. S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, ”An
architecture for Differentiated Services,” RFC2475, Network Working
Group, Dec. 1998; also in Proc. SIGCOMM’00, 2000.
[2]. K. Nichols,S. Blake, F. Baker, D. Black, “Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers,” RFC2474,
Network Working Group, Dec 1998.
[3]. Jon Postel, “Internet Protocol”, RFC 791, Information Sciences Institute,
University of Southern California,Sep 1981
[4]. Fine M., McCloghrie K., Seligson J., Chan K., Hahn S., Smith A.,
Reichmeyer F., “Differentiated Services Quality of Service Policy
Information Base”, Internet Draft, draft-ietf-diffserv-pib-01.txt, July 14,
2000
[5]. Baker F., Chan K., Smith A., “Management Information Base for the
DiffServ Architecture”, Internet Draft, draft-ietf-diffserv-mib-04.txt, July
2000
[6]. Laurent Mathy, Christoper Edwards, and David Hutchison., “The Internet:
[7]. A global telecommunications solution? ”, IEEE Network, 14(4):46–57,
2000.
[8]. Ray Hunt., “A review of quality of service mechanisms in IP-based
networks_ integrated and differentiated services, multi-layer switching,
MPLS and traffic engineering”, Computer Communications, 25(1):100–
108, 2002.
[9]. Xipeng Xiao and Lionel M. Ni., “Internet and QoS: A big picture”, IEEE
Network, 13(2):8–18, 1999.
[10]. Lixia Zhang, Stephen Deering, Deborah Estrin, Scott Shenker, and Daniel
[11]. Zappala., “RSVP: A new resource reservation protocol”, IEEE Network,
7(5):8–18, 1993.
[12]. Paul P. White., “RSVP and integrated services in the Internet: A tutorial”,
IEEE Communications Magazine, 35(5):100–106, 1997.

[13]. V.P. Kumar, T.V. Lakshman, and D. Stiliadis., “Beyond best effort: Router
[14]. architectures for the differentiated services of tomorrow’s Internet”, IEEE
Communications Magazine, 36(5):152–164, May 1998.
[15]. Ikjun Yeom and Narashima Reddy., “Modeling TCP behavior in a
differentiated services network”, IEEE/ACM Transactions on Networking,
9(1):31–46, 2001.
[16]. Sally Floyd and Van Jacobson., “Random early detection gateways for
congestion
[17]. Avoidance”, IEEE/ACM Transactions on Networking, 1(4):397–413, 1993.
[18]. Mikkel Christiansen, Kevin Jeffay, David Ott, and F. Donelson Smith.,
“Tuning RED for Web traffic”, IEEE/ACM Transactions on Networking,
9(3):249–264, June 2001.
20
[19]. Archan Misra, Teunis Ott, and John Baras., “Effect of exponential
averaging on the variability of a RED queue”, In Proceedings of IEEE ICC
2001, 2001.
[20]. S. Shenker, C. Partridge, and Guerin R., “Specification of guaranteed
quality of service”, RFC 2212, Internet Engineering Task Force, September
1997.
21