Chất lượng dịch vụ IP - Chương 3 pptx

43

Chương 3
MÔ HÌNH ỨNG DỤNG ðẢM BẢO QOS IP

Chương này sẽ giới thiệu hai mô hình ứng dụng ñảm bảo QoS IP: Mô hình tích hợp
dịch vụ IntServ và mô hình phân biệt dịch vụ DiffServ. Các kỹ thuật trình bày trong
chương 3 sẽ ñược thảo luận chi tiết hơn trong từng mô hình.

3.1 MÔ HÌNH TÍCH HỢP DỊCH VỤ INTSERV
3.1.1 Các yêu cầu chức năng chung của IntServ.
Mô hình dịch vụ tích hợp IntServ ñề xuất hai lớp dịch vụ bổ sung cho các dịch vụ
IP truyền thống gồm:
 Dịch vụ bảo ñảm GS cho ứng dụng yêu cầu giới hạn trễ và băng thông.
 Dịch vụ ñiều khiển tải CL cho ứng dụng yêu cầu ñộ tổn thất gói thấp.
Ý tưởng ban ñầu của các dịch vụ tích hợp là ñể hỗ trợ việc dành trước tài nguyên cho
các luồng lưu lượng. Trái ngược với kiến trúc chuyển phát datagram (các gói sẽ ñi qua
các tuyến khác nhau tại mọi thời ñiểm chúng ñược gửi), dịch vụ tích hợp cho phép dành
toàn bộ một tuyến cho luồng dữ liệu. ðiều ñó ñược thực hiện bởi việc thiết lập một tuyến
dành trước tài nguyên trước khi gửi dữ liệu. Thực chất của mô hình này là các bộ ñịnh
tuyến và thiết bị mạng phải dành trước nguồn tài nguyên của nó ñể cung cấp các mức
chất lượng dịch vụ cụ thể cho các gói mang lưu lượng người dùng. ðiều này yêu cầu các
bộ ñịnh tuyến phải có khả năng ñiều khiển các luồng lưu lượng.

Hình 3.1: Mô hình tích hợp dịch vụ Intserv


44

Cả hai lớp dịch vụ ñảm bảo và dịch vụ ñiều khiển tải phải ñược cài ñặt các ñường dẫn
và dự trữ các tài nguyên trước khi truyền dữ liệu của họ. Sự ñiều khiển ñịnh tuyến sẽ
quyết ñịnh cho việc có cấp nguồn cho yêu cầu hay không. Khi bộ ñịnh tuyến nhận ñược
gói, bộ phân lớp sẽ thực hiện sự phân lớp ña trường và ñưa gói vào hàng ñợi ñặc biệt dựa
trên kết quả của sự phân lớp. Cấu hình gói sau ñó sẽ lên lịch trình cho gói ñể ñạt ñược
yêu cầu chất lượng dịch vụ của nó.
Ứng dụng sẽ mô tả lưu lượng và tài nguyên nào mà nó sẽ cần. Sau ñó, mạng sẽ sử
dụng giao thức dành trước tài nguyên (RSVP) ñể dành trước băng thông xác ñịnh trong
mỗi bộ ñịnh tuyến dọc theo ñường ñi. Mỗi bộ ñịnh tuyến sẽ kiểm tra xem ở ñó nó có ñảm
bảo tài nguyên ñược yêu cầu và duy trì tuyến khi ñược yêu cầu bởi yêu cầu dành trước tài
nguyên. Khi tất cả các bước nhảy ñã ñược thiết lập, thiết bị gửi có thể gửi dữ liệu.
Mô hình tích hợp dịch vụ IntServ mô tả các ứng dụng QoS trong mạng IP theo phương
pháp nhận dạng luồng lưu lượng với 5 tham số cơ bản sau:
 Nhận dạng giao thức
 ðịa chỉ IP ñích
 ðịa chỉ cổng ñích
 ðịa chỉ IP nguồn
 ðịa chỉ cổng nguồn
ðể dự trữ tài nguyên cho một luồng lưu lượng, ứng dụng nguồn cần phải cung cấp các
ñặc tính luồng. ðặc tính luồng gồm các ñặc tính lưu lượng và các yêu cầu chất lượng dịch
vụ cho luồng ñó.
 ðặc tính lưu lượng bao gồm tốc ñộ ñỉnh, tốc ñộ trung bình, kích thước bùng nổ và
các tham số của gáo rò.
 Các yêu cầu dịch vụ gồm băng thông tối thiểu và các yêu cầu hiệu năng như trễ,
biến ñộng trễ và tỷ lệ tổn thất gói.
Các dịch vụ tích hợp có thể ñược chia thành hai mặt bằng: mặt bằng ñiều khiển và
mặt bằng dữ liệu.
 Mặt bằng ñiều khiển thiết lập việc dành trước tài nguyên.
 Mặt bằng dữ liệu thực hiện truyền dữ liệu.
ðể yêu cầu một dành trước tài nguyên IntServ, trước tiên ứng dụng phải ñặc tính hoá

ñược luồng lưu lượng của nó và tập hợp lại trong chỉ tiêu luồng lưu lượng. Sau ñó, yêu
cầu thiết lập dự trữ tài nguyên có thể ñược gửi ñến mạng. Nếu có thể cam kết việc dự
phòng, luồng ñó ñược ñưa vào bảng dự phòng tài nguyên. Khi gói tin ñến, khối lượng
nhận dạng luồng sẽ nhận dạng gói tin thuộc về luồng ñặt trước và ñặt chúng vào trong
hàng ñợi phù hợp ñể nhận ñược dịch vụ yêu cầu.


45

Việc lựa chọn ñường dẫn phù hợp cho chặng kế tiếp tại một nút là một nhiệm vụ khó
khăn do các hạn chế trong việc ñịnh tuyến IP truyền thống. ðường dẫn cần ñược lựa chọn
có thể ñã ñáp ứng ñược yêu cầu ñịnh ra. Tuy nhiên, ñịnh tuyến IP thường sử dụng các số
ño như trễ, bước nhảy hay một số loại thông số khác ñể tính toán ñường ñi ngắn nhất. Do
vậy, ñường dẫn ngắn nhất có thể không có ñược khả năng truyền tải, mặc dù ñường dẫn
khác dài hơn lại có ñược khả năng ñó. Vấn ñề ñịnh tuyến có thể trở nên phức tạp hơn bởi
một số ứng dụng có yêu cầu nhiều tham số QoS (ví dụ, cả băng thông và các yêu cầu về
tổn thất gói tin). Tìm kiếm ñường dẫn phù hợp trong nhiều ñiều kiện ràng buộc rất phức
tạp. Chính vì lý do ñó, mô hình ñảm bảo QoS cho IP ñầu tiên này không yêu cầu gắn các
cơ chế ñịnh tuyến ñảm bảo QoS trong kiến trúc InterServ. Kiến trúc này giả sử rằng khối
chức năng ñịnh tuyến của bộ ñịnh tuyến sẽ thực hiện ñịnh tuyến từng bước (hop by hop).
Tài nguyên dành trước trong InterServ cần phải qua tất cả các nút trên ñường dẫn
và thiết lập các dự phòng yêu cầu. Nó cũng phải truyền tải thông tin trong các phác thảo
lưu lượng và các yêu cầu tài nguyên, do vậy mỗi nút cần quyết ñịnh liệu nó có chấp nhận
việc dành trước hay không, nhận dạng luồng như thế nào và lập lịch cho gói tin.
ðiều khiển chấp nhận
Xử lý hai nhiệm vụ cơ bản là: Chấp nhận hay từ chối các yêu cầu dành trước và giám
sát việc sử dụng tài nguyên. Việc dành trước tài nguyên cho một yêu cầu mới không thể
ñược chấp nhận nếu nút không có sẵn tài nguyên yêu cầu. Có hai hướng tiếp cận ñể quyết
ñịnh tài nguyên nào là sẵn sàng: Dựa trên ño ñạc và dựa theo tham số.
 Trong hướng tiếp cận theo tham số, ñiều khiển chấp nhận sẽ tính toán các

tài nguyên khả dụng dựa trên các chỉ tiêu kỹ thuật của yêu cầu dành trước
tài nguyên hiện tại.
 Trong hướng tiếp cận dựa theo ño ñạc, ñiều khiển chấp nhận ño lưu lượng
thực sự trong mạng và sử dụng các phương pháp thống kê ñể quyết ñịnh
xem liệu tài nguyên nào là khả dụng. Hướng tiếp cận này có ưu ñiểm là tối
ưu hoá việc sử dụng mạng, mặc dù nó không thể ñảm bảo chặt chẽ các cam
kết tài nguyên.
Nhận dạng luồng
RSVP Sử dụng 5 trường trong tiêu ñề gói tin IP ñể nhận dạng các gói tin thuộc về các
luồng dành trước tài nguyên trong nút. Các trường này bao gồm: ñịa chỉ IP nguồn, ñịa chỉ
IP ñích, nhận diện giao thức, cổng nguồn và cổng ñích.
Lập lịch gói tin
Là bước cuối cùng trong việc dành trước tài nguyên. Bộ lập lịch gói tin thực hiện việc


46

cấp pháp tài nguyên. Nó quyết ñịnh gói tin nào gửi kế tiếp khi tuyến kết nối ñi là sẵn
sàng. Do ñó nó tác ñộng ñến trễ mà gói tin ñó phải chịu trong bộ ñịnh tuyến và bộ ñịnh
tuyến không trực tiếp loại bỏ gói tin.


47

3.1.2 Giao thức dành trước tài nguyên RSVP
(i) Giới thiệu chung
Giao thức dành trước tài nguyên RSVP là một giao thức thiết lập tài nguyên dự phòng
QoS IP, RSVP hỗ trợ cả IPv4 và IPv6 cũng như ứng dụng cho cả hai phương thức chuyển
phát tin ñơn hướng và ña hướng (Unicast và multicast).
Trong giao thức dành trước tài nguyên RSVP, các nguồn tài nguyên ñược dành trước

theo các hướng ñộc lập. Máy chủ nguồn và máy chủ ñích trao ñổi các bản tin RSVP ñể
thiết lập các trạng thái chuyển tiếp và phân loại gói tại mỗi nút.
RSVP không phải là giao thức ñịnh tuyến mà là giao thức báo hiệu, các bản tin RSVP
ñược chuyển ñi trên cùng ñường dẫn với các gói tin sẽ ñược chuyển và ñược xác ñịnh bởi
bảng ñịnh tuyến trong bộ ñịnh tuyến IP.Các máy chủ sử dụng giao thức RSVP ñể yêu cầu
QoS của mạng cho các luồng lưu lượng thực tế. Các bộ ñịnh tuyến sử dụng RSVP ñể tạo
ra các yêu cầu QoS cho toàn bộ các bộ ñịnh tuyến dọc theo tuyến ñường gói tin chuyển
qua mạng. Giao thức RSVP cũng sử dụng ñể duy trì và làm tươi trạng thái cho luồng ứng
dụng yêu cầu QoS.
Một số ñặc tính cơ bản của giao thức dành trước tài nguyên RSVP ñược liệt kê dưới
ñây:
 RSVP là giao thức báo hiệu ñể dành trước tài nguyên trong ñường dẫn từ
nguồn tới ñích.
 RSVP báo hiệu tới tất cả các thiết bị mạng về yêu cầu QoS của ứng dụng.
 RSVP yêu cầu các ứng dụng khởi tạo yêu cầu.
 RSVP hoạt ñộng liên ñiều hành với các kỹ thuật QoS khác ñể cải thiện ñộ ñảm
bảo cho các tài nguyên dành trước.
Giao thức dành trước tài nguyên RSVP thường ñược sử dụng cho các ứng dụng yêu
cầu ñảm bảo các tham số băng thông và ñộ trễ. Các ứng dụng mạng hiện nay sử dụng
RSVP như là giao thức báo hiệu gồm các ứng dụng cho VoIP và kỹ thuật lưu lượng
MPLS (Multiprotocol Label Switching).
RSVP ñược phát triển ñể chống lại tắc nghẽn mạng bằng cách cho phép các bộ
ñịnh tuyến ñược quyết ñịnh ở mức cao. Tại mức này các bộ ñịnh tuyến có thể ñáp ứng
các yêu cầu của một luồng ứng dụng và dự trữ tài nguyên mong muốn ngay cả khi mặt
bằng chuyển tiếp gói không xử lý ñược. Mô hình báo hiệu RSVP ñược dựa trên xử lý ñặc
biệt kiểu ña phương, mang bản tin báo hiệu tới các nút dọc tuyến ñường qua mạng theo
luồng thực tế, quản lý trạng thái mềm, trao ñổi bản tin, dự phòng tài nguyên và tách báo
hiệu QoS khỏi chức năng ñịnh tuyến.
(ii) Hoạt ñộng của RSVP

48

Một phiên làm việc của giao thức dành trước tài nguyên RSVP thường sử dụng 3 tham
số sau:
 ðịa chỉ ñích
 Nhận dạng giao thức
 ðịa chỉ cổng ñích
Hình 3.2 dưới ñây chỉ ra nguyên lý hoạt ñộng của RSVP. Máy chủ nguồn gửi bản tin
Path tới ñích cho một luồng dữ liệu hay còn gọi là một phiên truyền thông. Bản tin Path
chứa các ñặc tính cho luồng dữ liệu sẽ ñược gửi, bản tin Path ñi qua các bộ ñịnh tuyến
trên ñường dẫn tới ñích. Các bộ ñịnh tuyến trên tuyến ñăng ký nhận dạng luồng và các
ñặc tính luồng vào cơ sở dữ liệu. Bản tin Resv ñược phát ngược từ máy chủ nhận về máy
chủ gửi nhằm xác nhận và chỉnh sửa các thông tin yêu cầu ñã ñược gửi ñi trong bản tin
Path, ñây là các thông tin về dự phòng tài nguyên cho ñường dẫn mà gói tin sẽ ñược
chuyển qua.

Hình 3.2: Nguyên lý hoạt ñộng của RSVP
RSVP giữ trạng thái mềm các tài nguyên trong các bộ ñịnh tuyến. Trạng thái mềm này
ñược cung cấp ñộng theo các thông tin từ các thành viên trong phiên làm việc, tương
thích với sự thay ñổi ñịnh tuyến và các yêu cầu thay ñổi tài nguyên của các luồng lưu
lượng trong phiên. Thời gian làm tươi ñịnh kỳ thông thường là 30s.
(iii) Các kiểu dành trước tài nguyên của RSVP
Trong RFC 2205 [6] ñịnh nghĩa 3 kiểu dự phòng tài nguyên (minh hoạ trên hình
3.3). Hai kiểu ñiều khiển máy gửi ñược ñịnh nghĩa:
 Kiểu lựa chọn hiện
 Kiểu lựa chọn wildcard.
Kiểu lựa chọn tuyến hiện liệt kê toàn bộ các máy gửi, trong khi ñó kiểu wildcard chỉ
liệt kê toàn bộ máy chủ trong phiên.

49


Hình 3.3: Các kiểu dành trước tài nguyên
ðiều khiển chia sẻ lưu lượng thực hiện ñiều khiển các ứng xử tài nguyên dành trước
cho các máy gửi khác nhau trong cùng một phiên. Hai kiểu ñiều khiển chia sẻ lưu lượng
ñược ñịnh nghĩa là:
 Kiểu dành trước tài nguyên riêng biệt.
 Kiểu dành trước tài nguyên chia sẻ.
Trong kiểu dành trước tài nguyên riêng biệt, tài nguyên dành ñược tạo ra cho từng
máy gửi. Trong kiểu dành trước tài nguyên chia sẻ, một tài nguyên chung ñược chia sẻ
bởi các máy gửi trong phiên.
Như chỉ ra trên hình 3.3 có 4 khả năng ñược tổ hợp từ các cách thức ñiều khiển chia sẻ
tài nguyên và lựa chọn máy gửi. Tuy nhiên, một kiểu không ñược ñịnh nghĩa và ta còn 3
kiểu dành trước tài nguyên là: Kiểu bộ lọc cố ñịnh FF (Fixed Filter), Kiểu chia sẻ hiện SE
(Shared Explicit) và kiểu bộ lọc Wildcard WF (Wildcard - Filter).
(iv) Các dạng bản tin của RSVP
Khuôn dạng bản tin RSVP có cấu trúc gồm một tiêu ñề chung và các trường chức
năng thể hiện các ñối tượng như chỉ ra trên hình 3.4 (a). Mỗi một ñối tượng ñược cấu trúc
bởi tiêu ñề ñối tượng và nội dung ñối tượng.
Khuôn dạng tiêu ñề chung ñược chỉ ra trên hình 3.4 (b) có tổng ñộ dài là 8 bytes. Nó
gồm 4 bit cho số hiệu phiên bản RSVP, 4 bit cờ, 8 bit sử dụng cho kiểu bản tin RSVP; 16
bit tổng kiểm tra, 8 bit sử dụng cho thời gian sống TTL của gói tin IP, 8 bit dự phòng và
trường hiện thị ñộ dài bản tin gồm 16 bit.



50

Hình 3.4: Khuôn dạng bản tin RSVP và tiêu ñề chung RSVP
Nếu trường tổng kiểm tra ñộ dài chứa toàn bộ giá trị 0, ñiều ñó thể hiện không cần
kiểm tra các dữ liệu truyền ñi. ðộ dài bản tin RSVP bao gồm cả tiêu ñề và các ñối tượng
trong bản tin. RSVP ñịnh nghĩa các kiểu bản tin sắp xếp theo thứ tự kiểu bản tin:
1. Path - Sử dụng ñể yêu cầu tài nguyên dành trước.
2. Resv - Gửi ñáp ứng bản tin ñường ñể thiết lập và duy trì dự trữ tài nguyên.
3. PathTear - Sử dụng ñể xoá dự trữ tài nguyên khỏi mạng theo hướng ñi.
4. ResvTear - Sử dụng ñể xoá bỏ tài nguyên khỏi mạng theo hướng về.
5. PathErr – Thông báo lỗi bản tin Path.
6. ResvErr - Thông báo lỗi bản tin Resv .
7. ResvConf – Là một bản tin tuỳ chọn, gửi ngược lại tới phía gửi của bản tin Resv
ñể xác nhận rằng tài nguyên dự trữ xác ñịnh thực sự ñã ñược cài ñặt.
8. ResvTearConf - Sử dụng ñể xác nhận dự trữ tài nguyên xác ñịnh ñã bị xoá khỏi
mạng.
Khuôn dạng ñối tượng RSVP ñược chỉ ra trên hình 3.5 dưới ñây gồm 32 bit tiêu ñề ñối
tượng và các nội dung ñối tượng có ñộ dài thay ñổỉ. Một ñối tượng ñộ dài có 32 bit ñịnh
nghĩa ñộ dài tối ña cho phép của ñối tượng RSVP là 65,528 byte. Các ñối tượng RSVP
ñược tổ chức thành lớp ñối tượng và kiểu ñối tượng.

Hình 3.5: Khuôn dạng bản tin ñối tượng RSVP
Trường chức năng “Class Num” ñịnh nghĩa lớp ñối tượng và trường chức năng “C
Type” ñịnh nghĩa ñối tượng trong lớp. Các trường chức năng này tổ chức thành một cặp
ñể mô tả các ñối tượng trong RSVP. Các lớp ñối tượng sau ñược ñịnh nghĩa trong RFC
2205.
 NULL - Mô tả trạng thái của phiên.
 SESSION – Mô tả phiên.
 RSVP_HOP - Thể hiện các bước nhảy của bản tin RSVP.
 TIME_VALUE – Mô tả giá trị thời gian chuyển tin.
 STYLE – Mô tả kiểu bản tin.

51

 FLOWSPEC – Mô tả ñặc tính luồng.
 FILTER_SPEC – Mô tả ñặc tính bộ lọc.
 SENDER_TEMPLATE - Mô tả khuôn dạng gói của ñối tượng gửi.
ðối tượng FLOWSPEC chứa các tham số ñiều khiển lưu lượng gồm: tốc ñộ gáo rò
token; kích thước gáo rò token, tốc ñộ ñỉnh , v v.
ðối tượng kiểu bản tin (STYLE) ñược ñặt trong “Class num=8”, lớp này chỉ có một
ñối tượng với C type -1. ðối tượng kiểu ñịnh nghĩa các kiểu dành trước tài nguyên.

Hình 3.6: Khuôn dạng ñối tượng kiểu
XX bit ðiều khiển chia sẻ
00
01
10
11
Dự phòng
Tài nguyên phân biệt
Tài nguyên chia sẻ
Dự phòng
Bảng 3.1: Các bit sử dụng cho ñiều khiển chia sẻ
YYY bit ðiều khiển lựa chọn máy gửi
000
001
010
011-111
Dự phòng
Lựa chọn Wildcard
Lựa chọn hiện

Dự phòng
Bảng 3.2: Các bit sử dụng cho ñiều khiển lựa chọn máy gửi
Hình 3.6 trên ñây chỉ ra khuôn dạng của ñối tượng kiểu. kiểu dành trước tài nguyên
ñược ñịnh nghĩa bởi 5 bit cuối cùng. Trong ñó, 2 bit ñầu ñịnh nghĩa kiểu ñiều khiển chia
sẻ tài nguyên và 3 bit ñiều khiển lựa chọn máy gửi. Ý nghĩa của các bit ñược thể hiện
trong bảng 3.1 và bảng 3.2.


52


Hình 3.7: Cấu trúc bản tin Path và Resv trong RSVP
Bản tin Path mô tả thông tin phiên truyền thông qua ñịa chỉ IP nguồn và ñịa chỉ IP
ñích, cùng với một số ñặc tính của ñường ñi ñược phản ánh trong các ñối tượng
RSVP_HOP và TIME_VALUE. Khuôn dạng của gói tin sẽ ñược chuyển ñi tương thích
với các kiểu lọc ñược mô tả trong ñối tượng SENDER_TEMPLATE, các ñặc tính luồng
của các ứng dụng từ máy gửi ñược mô tả trong ñối tượng SENDER_TSPEC. Cấu trúc
bản tin Path ñược trình bày trên hình 3.7 (a).
Trên hình 3.7 (b) mô tả cấu trúc chung của bản tin Resv, các ñối tượng của bản tin
Resv nhằm xác nhận và sửa ñổi một số yêu cầu của bản tin Path cho phù hợp với hiện
trạng thực tế của mạng.
3.2 MÔ HÌNH PHÂN BIỆT DỊCH VỤ DIFFSERV
3.2.1 Tổng quan về kiến trúc DiffServ.
Kiến trúc mô hình phân biệt dịch vụ DiffServ ñược coi là bước phát triển tiếp theo
của mô hình tích hợp dịch vụ IntServ. Một vấn ñề lớn nhất còn tồn tại của IntServ là các
nguồn tài nguyên cần phải ñược duy trì trạng thái thông tin theo từng luồng. Với các
mạng có số lượng dịch vụ và số lượng thiết bị mạng lớn, vấn ñề này trở nên khó khả thi
ñối với các bộ ñịnh tuyến lõi cần phải xử lý lưu lượng rất lớn trong mạng. Tiếp cận của
mô hình phân biệt dịch vụ DiffServ là không xử lý theo từng luồng lưu lượng riêng biệt
mà ghép chúng vào một số lượng hạn chế các lớp lưu lượng. Trong DiffServ, băng thông

và các tài nguyên mạng khác ñược chỉ ñịnh trong các lớp lưu lượng. Mặt khác, DiffServ
hướng tới xử lý trong từng vùng dịch vụ phân biệt DS (Differential Service) thay vì xử lý
từ ñầu cuối tới ñầu cuối như trong mô hình tích hợp dịch vụ IntServ.
DiffServ chỉ cung cấp quan hệ ứng xử phân biệt tới các lớp lưu lượng, vì vậy DiffServ
không cung cấp mức QoS cụ thể. ðể ñảm bảo một số mức chất lượng dịch vụ QoS cụ
thể, DiffServ ñược hỗ trợ với ñiều khiển quản lý tại biên vùng DS nhằm phối hợp ñiều
khiển các luồng lưu lượng vào mạng. Chất lượng dịch vụ ñược cung cấp bởi mô hình


53

phân biệt dịch vụ DiffServ theo hướng cung cấp thay vì theo hướng dành trước tài
nguyên.
Thuật ngữ “DiffServ” mô tả tổng thể cách ứng xử của lưu lượng ứng dụng trong mạng
cung cấp dịch vụ, nó ñịnh nghĩa dịch vụ mà người sử dụng mong nhận ñược từ phía nhà
cung cấp dịch vụ. Dịch vụ DiffServ ñược ñịnh nghĩa trong các thoả thuận mức dịch vụ
SLA của người sử dụng với nhà cung cấp dịch vụ DiffServ.
DiffServ ñịnh nghĩa một số tham số mà người sử dụng hiểu rõ cho ứng dụng của họ
trong SLA như: Thoả thuận về ñiều kiện lưu lượng TCA (Traffic Conditioning
Agreement), hồ sơ lưu lượng (các tham số của gáo rò token), các tham số hiệu năng (ñộ
thông qua, ñộ trễ, mức tổn thất gói), cách thức xử lý các gói tin không phù hợp với thoả
thuận, luật ñánh dấu và chia cắt lưu lượng.



Hình 3.8: Mô hình các bước phân biệt dịch vụ DiffServ
Hình 3.8 trên ñây chỉ ra các bước cơ bản liên quan tới vấn ñề cung cấp các dịch vụ
DiffServ. Các gói tin ñến bộ ñịnh tuyến có thể ñã ñược ñánh dấu hoặc chưa ñánh dấu, bộ
ñịnh tuyến xác ñịnh ñiểm mã ñiều khiển dịch vụ DSCP của gói tin và phân loại các gói
tin theo phương pháp phân loại hành vi kết hợp BA. Các gói tin phân loại thành các lớp

BA ñược chuyển tiếp theo hành vi từng bước PHB (Per Hop Behavior) ñược ñịnh nghĩa
trước cho các BA. Mỗi PHB ñược thể hiện bởi giá trị DSCP và xử lý giống nhau ñối với
các gói tin trong cùng lớp BA. Các yêu cầu chung của QoS ñã ñược chỉ ra trong chương 2
của tài liệu này gồm chính sách lưu lượng, chia cắt lưu lượng, loại bỏ gói, hàng ñợi tích
cực và lập lịch gói ñược áp dụng tại bước này của mô hình phân biệt dịch vụ DiffServ.
Kiến trúc DiffServ hướng tới ñảm bảo chất lượng dịch vụ QoS bằng cách kết hợp
trạng thái phân loại lưu lượng theo tính chất lưu lượng ñược phân biệt qua các gói ñánh
dấu. Các gói ñược ñánh dấu và nhận dạng ñể nhận ñược một ứng xử chuyển tiếp ở từng
bước cụ thể trên các nút dọc theo ñường truyền của chúng.


54


Hình 3.9: Xử lý gói trong mô hình DiffServ
Kiến trúc xử lý gói theo DiffServ gồm một số các yếu tố chức năng ñược thực hiện
trong các nút mạng và bổ sung các phép ứng xử chuyển tiếp trên từng luồng cùng với các
chức năng xử lý lưu lượng như: Chức năng phân loại gói, ñánh dấu, ñịnh dạng và hoạch
ñịnh chính sách. Kiến trúc này cho phép mở rộng mạng do thực hiện các chức năng phân
lớp và ñiều khiển phức tạp ở các nút biên mạng
Sự cung cấp dịch vụ và chính sách qui ñịnh lưu lượng ñược tách riêng ra từ các
cách ứng xử chuyển tiếp trong phạm vi nội mạng ñể cho phép thực hiện biến ñổi rộng rãi
các phép ứng xử.
3.2.2 Miền phân biệt dịch vụ DS và ñiểm mã phân biệt dịch vụ DSCP
Một miền DS gồm các bộ ñịnh tuyến hỗ trợ cơ chế phân biệt dịch vụ, còn gọi là các
nút DS hoạt ñộng với một chính sách cung cấp dịch vụ chung và thiết lập các nhóm PHB
ñược thực hiện trên mỗi nút. Một miền DS có biên gồm các nút biên DS và các nút lõi
trong miền. Các nút biên DS phân loại và ñiều khiển lưu lượng ñầu vào ñể ñảm bảo rằng
các gói ñi qua miền ñược ñánh dấu thích hợp ñể lựa chọn một PHB từ một nhóm các
PHB ñược hỗ trợ trong phạm vi miền. Các nút trong miền DS lựa chọn ứng xử chuyển

tiếp cho các gói dựa trên ñiểm mã dịch vụ DSCP của chúng, sắp xếp vào một trong các
PHB theo yêu cầu. Một miền DS thông thường gồm một hay nhiều mạng dưới cùng một
chính sách quản trị. Việc quản trị một miền phải ñảm bảo tin cậy ñể ñảm bảo rằng các
nguồn tài nguyên tương xứng ñược cung cấp và (hoặc) ñược dự trữ ñể hỗ trợ các SLA
yêu cầu.



55

Hình 3.10: Miền phân biệt dịch vụ DS
Một vùng DS là một tập hợp một hay vài miền DS kế tiếp nhau. Các vùng DS có khả
năng hỗ trợ các miền DS dọc theo ñường dẫn nối các miền trong vùng. Các miền DS
trong vùng DS có thể hỗ trợ nội bộ trong các nhóm PHB khác nhau và các ñiểm mã khác
nhau ñể sắp xếp PHB. Tuy nhiên, ñể cho phép các dịch vụ nối ngang qua miền, các miền
DS ngang hàng phải thiết lập mỗi miền một SLA ngang hàng chứa thoả thuận lưu lượng
TCA phù hợp. Một vài miền DS trong một vùng DS có thể kế thừa một chính sách cung
cấp dịch vụ chung và có thể hỗ trợ tập hợp chung các nhóm PHB và các cách sắp xếp
ñiểm mã phân biệt dịch vụ DSCP, vì vậy có thể loại bỏ qui ñịnh lưu lượng giữa các miền
DS ñó.
DiffServ sử dụng trường kiểu dịch vụ ToS trong tiêu ñề IPv4 (mục 1.13) và trường
phân lớp lưu lượng TC (Traffic Class) trong tiêu ñề IPv6 ñể ñánh dấu gói. ðối với các bộ
ñịnh tuyến hoạt ñộng trong miền DS các trường chức năng này ñược thay bằng trường
chức năng dịch vụ phân biệt DS. Trong 8 bit của trường DS, 6 bit ñược sử dụng cho ñiểm
mã dịch vụ phân biệt DSCP và 2 bit dự phòng. Hình 3.11 dưới ñây chỉ ra cấu trúc của
trường DS.

Hình 3.11: Cấu trúc của trường phân biệt dịch vụ DS
Các ñiểm mã phân biệt dịch vụ DSCP ñược phân thành 3 khối ñược gọi là các pool.
Bảng 3.3 dưới ñây chỉ ra các khối của DSCP.

Pool ðiểm mã DSCP Ứng dụng
1
2
3
XXXXX0
XXXX11
XXXX01
Tiêu chuẩn
Thử nghiệm/nội bộ
Thử nghiệm/nội bộ
Bảng 3.3: Các khối ñiểm mã dịch vụ phân biệt DSCP
Pool 1 gồm các ñiểm mã DSCP sử dụng cho toàn cầu, pool 2 và pool 3 sử dụng cho
mục ñích thử nghiệm và nội bộ miền DS riêng. Như vậy, số phân lớp dịch vụ của pool 1
có thể lên tới 32 và số lớp dịch vụ tối ña của pool2 và pool 3 là 16. ðể hỗ trợ cho các bộ
ñịnh tuyến truyền thống sử dụng các phân lớp của trường ToS trong IPv4. 8 ñiểm mã


56

DSCP ñược sử dụng nên DSCP có dạng (XXX000). Dịch vụ nỗ lực tối ña có ñiểm mã
phân biệt dịch vụ DSCP là (000000).
3.2.3 Các phương pháp xử lý gói trong DiffServ.
Qui tắc ứng xử theo từng chặng là sự mô tả bề ngoài của ứng xử chuyển tiếp của một
nút DS ñược áp dụng cho một sự tập ứng xử DS cụ thể. Ứng xử chuyển tiếp mục tiêu giới
thiệu trong mục này nhằm sáng tỏ phương pháp xử lý gói trong mô hình DiffServ. ðể tạo
ra các hành vi chuyển tiếp gói ñược ñịnh nghĩa theo quy tắc ứng xử từng chặng PHB, các
cơ cấu kỹ thuật ñảm bảo QoS như AQM và lập lịch gói ñã ñược trình bày trong chương 2
ñược ứng dụng. Một PHB có thể không cần phụ thuộc vào nguyên tắc chung mà có thể
ñược phát triển trên các kỹ thuật riêng của nhà cung cấp thiết bị.
Nhóm làm việc về DiffServ của IETF ñịnh nghĩa hai loại PHB trong RFC 2598 [6],

RFC 3246 và RFC 2597 [6]: Chuyển tiếp nhanh EF (Expedited Forwarding) và Chuyển
tiếp ñảm bảo AF (Assured Forwarding).
(i) Chuyển tiếp nhanh EF PHB
Về cơ bản, EF PHB ñảm bảo tính năng về mặt tốc ñộ hơn là ñộ tin cậy. Nó ñược
yêu cầu ñưa ra các dịch vụ với khả năng tổn hao thấp, trễ thấp, rung pha thấp và ñảm bảo
băng thông. Vì rung pha và trễ gây nên bởi thời gian mà gói sử dụng ở trong bộ nhớ ñệm
và hàng ñợi, một bộ ñịnh tuyến EF phải ñảm bảo rằng lưu lượng EF ñược ñưa ñến những
bộ nhớ ñệm nhỏ. Tốc ñộ ñầu ra của bộ ñịnh tuyến này phải bằng (hoặc cao hơn ñầu vào).
Khi xảy ra hiện tượng quá tải, nút biên miền DS không cho phép lưu lượng dạng này ñi
vào trong miền vì nó sẽ là nguyên nhân gây tắc nghẽn tại các bộ ñịnh tuyến trong miền
DS. Vấn ñề này ñược ñiều chỉnh bởi xác ñịnh mức dịch vụ SLA và xác ñịnh lưu lượng
truyền có ñiều kiện.

Hình 3.12: Xử lý chuyển tiếp nhanh EF PHB
Chuyển tiếp EF PHB khả thi nếu băng thông ñầu ra và kích thước bộ nhớ ñệm ñủ ñể các
luồng lưu lượng ra với tốc ñộ phục vụ µ. Tốc ñộ phục vụ µ luôn lớn hơn tốc ñộ ñầu vào λ


57

tại các bộ ñệm EF. Các luồng không phải là EF ở ñây là các luồng dịch vụ nỗ lực tối ña.
Với kỹ thuật lập lịch ưu tiên như ñã chỉ ra trong chương 3, chuyển tiếp EF ñảm bảo ñược
tính ưu tiên cho các luồng lưu lượng theo yêu cầu.
Một tiếp cận khác của chuyển tiếp EF PHB là sử dụng các biến thể của hàng ñợi WFQ ñể
phân loại các lưu lượng chuyển tiếp EF.
(ii) Chuyển tiếp ñảm bảo AF PHB
ðặc ñiểm của AF PHB là phân phối dữ liệu ñảm bảo với khả năng mất gói thấp.
ðó là ñiều kiện tốt nhất khi sử dụng các giao thức không thực hiện xử lý sửa lỗi hoặc
không có giải pháp truyền lại gói.
AF PHB bao gồm 4 lớp chuyển tiếp và mỗi lớp chuyển tiếp có 3 mức ưu tiên loại bỏ

gói tin, mỗi lớp ñược gán một băng thông và khoảng nhớ ñệm xác ñịnh. Lớp A có thể có
bộ nhớ ñệm lớn hơn nhưng băng thông nhỏ và lớp D có thể có bộ nhớ ñệm nhỏ nhưng
băng thông lớn hơn. Nếu một gói phải bị loại bỏ, bộ ñịnh tuyến có cách nhận biết gói nào
bị loại bỏ ñầu tiên. Ngoài ra, mỗi lớp chuyển tiếp ñược phân bổ một số lượng cực nhỏ
băng thông và bộ nhớ ñệm. Nếu bộ nhớ ñệm ñầy, thì quá trình loại bỏ gói sẽ bắt ñầu theo
trật tự loại bỏ theo mức ưu tiên. Các phân loại AF ñược thể hiện trên hình 3.13 và trên
bảng 3.4.

Hình 3.13: Các phân lớp chuyển tiếp ñảm bảo AF PHB
Lớp PHB Phân lớp Dự ñoán mất gói DSCP
AF4


AF3


AF2


AF41
AF42
AF43
AF31
AF32
AF33
AF21
AF22
AF23
Thấp
Trung bình

Cao
Thấp
Trung bình
Cao
Thấp
Trung bình
Cao
100010
100100
100110
011010
011100
100010
010010
010100
010110


58

AF1


AF11
AF12
AF13
Thấp
Trung bình
Cao
001010

001100
001110
Bảng 3.4: Chi tiết các phân lớp chuyển tiếp ñảm bảo AF PHB
(iii) PHB và thoả thuận lớp lưu lượng
Các PHB ñược xác ñịnh theo các giới hạn về tài nguyên của chúng (ví dụ: bộ ñệm,
băng thông) có quan hệ ưu tiên với các PHB khác, hay trong các giới hạn về ñặc ñiểm lưu
lượng tường minh (trễ, tổn thất). Các PHB này có thể ñược dùng như là các khối làm sẵn
ñể cấp phát các tài nguyên và nên ñược ñịnh rõ như một nhóm PHB chắc chắn. Các nhóm
PHB thường chia sẻ áp dụng ràng buộc chung cho mỗi PHB trong phạm vi nhóm, như
chính sách lập lịch gói hay quản lý bộ ñệm. Quan hệ giữa các PHB trong nhóm có thể ở
dưới dạng ưu tiên tuyệt ñối hay tương ñối. Một PHB ñơn là trường hợp ñặc biệt của
nhóm PHB.
PHB ñược thực hiện trong các nút theo một số cơ cấu quản lý bộ ñệm hoặc lập lịch
gói. Các nhóm PHB cần ñược hiểu như sự cấp phát tài nguyên thích hợp giữa các nhóm,
và các cơ cấu tích hợp có thể ñược thực hiện hỗ trợ 2 hay nhiều nhóm. Một ñịnh nghĩa
nhóm PHB nên xác ñịnh rõ khả năng xung ñột với các nhóm PHB trước, mà có thể ngăn
cản sự hoạt ñộng ñồng thời. Một PHB ñược chọn tại một nút nhờ sắp xếp ñiểm mã DS
trong gói nhận ñược. Các PHB tiêu chuẩn có một ñiểm mã ñược chỉ ñịnh. Tuy nhiên, với
các PHB chuẩn toàn bộ không gian các ñiểm mã lớn hơn không gian khả dụng cho các
ñiểm mã ñược ñề nghị, và do ñó loại bỏ sự cung cấp cho những sắp xếp cấu hình nội bộ.
Một bảng sắp xếp ñiểm mã cho PHB có thể bao gồm cả sự sắp xếp 11 và N 1. Tất cả
các ñiểm mã phải ñược sắp xếp theo một số PHB; khi thiếu một vài chính sách cục bộ,
các ñiểm mã không ñược sắp xếp theo PHB chuẩn phù hợp với các chi tiết của PHB ñó
nên ñược sắp xếp theo PHB mặc ñịnh .


59


Hình3.14: Dịch vụ phân biệt với PHB và TCA

Thực hiện, cấu hình, vận hành và quản lý các nhóm PHB ñược hỗ trợ trong
các nút của miền DS nên ñược phân một cách hiệu quả tài nguyên của các nút này
và các liên kết nội vùng giữa các tập ứng xử, phù hợp với chính sách cung cấp
dịch vụ của miền. Các thành phần qui ñịnh lưu lượng có thể tăng mức ñiều khiển
sử dụng các tài nguyên này qua sự ép buộc của các TCA và có thể qua hoạt ñộng
phản hồi từ các nút và các thành phần qui ñịnh lưu lượng trong miền. Mặc dù các
dịch vụ có thể ñược triển khai khi thiếu các chức năng qui ñịnh lưu lượng phức
tạp, các chức năng như là ñịnh chính sách, ñịnh dạng, và ñánh dấu lại ñộng cho
phép triển khai các hệ ño lượng thi hành việc cung cấp các dịch vụ. Cấu hình và
ảnh hưởng giữa các thành phần qui ñịnh lưu lượng và các nút nội vùng nên ñược
quản lý bằng ñiều khiển quản trị của miền và có thể yêu cầu ñiều khiển vận hành
qua các giao thức và một thực thể ñiều khiển.
3.3 IP QOS VÀ CHUYỂN MẠCH NHÃN ðA GIAO THỨC MPLS
Trong một số năm gần ñây, công nghệ chuyển mạch nhãn ña giao thức MPLS ñược
coi là công nghệ hàng ñầu cho mạng lõi. Sự phát triển công nghệ chuyển mạch MPLS là
kết quả của các mô hình ứng dụng công nghệ IP trên nền ATM và FR. Chất lượng dịch
vụ mạng QoS chính là yêu cầu thúc ñẩy MPLS. So sánh với các yêu cầu khác, như quản
lí lưu lượng và hỗ trợ VPN thì QoS không phải là lí do quan trọng nhất ñể triển khai
MPLS. Hầu hết các công việc ñược thực hiện trong MPLS QoS tập trung vào việc hỗ trợ
các dặc tính IP QoS trong mạng. Nói cách khác, mục tiêu là thiết lập ñiểm tương ñồng
của các ñặc tính QoS giữa IP và MPLS chứ không phải là làm cho MPLS QoS tốt hơn IP
QoS.


60

Một lí do nữa ñể khẳng ñịnh MPLS QoS không phải là IP QoS là MPLS không phải là
giao thức xuyên suốt. MPLS không vận hành trong các máy chủ và có thể sẽ tồn tại các
mạng IP không sử dụng MPLS. Mặt khác QoS là ñặc tính thường trực của liên lạc giữa
các LSR cùng cấp. Một cách nhìn khác về vấn ñề này là MPLS không thay ñổi về căn

bản về mô hình dịch vụ IP. Các nhà cung cấp dịch vụ không bán dịch vụ MPLS, họ cung
cấp các dịch vụ IP (hay Frame Relay và các dịch vụ khác), và do ñó nếu họ ñưa ra QoS
thì phải dựa trên IP QoS (hay Frame Relay QoS,…) chứ không phải là MPLS QoS.
ðiều này không có nghĩa là MPLS QoS không có vai trò như IP QoS. Thứ nhất,
MPLS giúp nhà cung cấp ñưa ra dịch vụ IP QoS chất lượng hơn. Thứ hai, hiện nay ñang
xuất hiện một số khả năng QoS mới hỗ trợ qua mạng sử dụng MPLS, tuy không thực sự
xuyên suốt nhưng cũng có thể chứng tỏ rất hữu ích, ví dụ như ñảm bảo băng thông của
LSP.
(i) Mô hình DiffServ và MPLS
Tương tự như DiffServ, MPLS cũng hỗ trợ chất lượng dịch vụ trên cơ sở phân loại các
luồng lưu lượng theo các tiêu chí như ñộ trễ, băng tần. ðầu tiên tại biên của mạng, luồng
lưu lượng của người dùng ñược nhận dạng (băng việc phân tích một số trường trong mào
ñầu của gói) và chuyển các luồng lưu lượng ñó trong các LSP riêng với thuộc tính COS
hay QoS của nó. MPLS có thể hỗ trợ các dịch vụ không ñịnh trước qua LSP bằng việc sử
dụng một trong các kỹ thuật sau:
 Bộ chỉ ñịnh COS có thể ñược truyền trong nhãn gắn liền với từng gói. Bên cạnh
việc chuyển mạch nhãn tại từng nút LSR, mỗi gói có thể ñược chuyển sang kênh
ra dựa vào thuộc tính COS. Mào ñầu ñệm (Shim header) của MPLS có chứa
trường COS.
 Trong trường hợp nhãn không chứa chỉ thị COS hiện tại thì giá trị COS có thể liên
quan ngầm ñịnh với một LSP cụ thể. ðiều ñó ñòi hỏi LDP hay RSVP gán giá trị
COS không danh ñịnh cho LSP ñể các gói ñược xử lý tương xứng.
 Chất lượng dịch vụ QoS có thể ñược cung cấp bởi một LSP ñược thiết lập trên cơ
sở báo hiệu ATM (trong trường hợp MPLS là mạng ATM-LSR).
Khi một bộ ñịnh tuyến MPLS gửi ñi một gói tin ñến chặng kế tiếp của nó, nó gửi một
nhãn ñi kèm. Các LSR tuần tự trong mạng ñó không cần phân tích mào ñầu của gói tin,
nó chỉ ñọc nhãn MPLS ñược ñánh chỉ số trong bảng ñường dẫn ñịnh tuyến duy trì tại
mỗi LSR. Khi các gói tin ñược ñánh dấu bởi các mã ñiểm DiffServ ñến một mạng MPLS,
cần phải có một cách thức chuyển giao thông tin cung cấp bởi các mã ñiểm vào nhãn
MPLS. Việc này cần thực hiện nếu MPLS có khả năng thực hiện các quyết ñịnh ñáp ứng

các yêu cầu dịch vụ khác biệt nhờ ñó các gói tin ñược ñánh dấu với MPLS trong mạng,
các tiêu ñề IP không ñược kiểm tra khi các gói tin ñược gán nhãn MPLS. Do vậy các gói
tin không thể phân biệt dựa trên các DSCP của chúng do DSCP là một phần của tiêu ñề
IP. Có hai phương pháp ñặt thông tin DSCP vào tiêu ñề IP.


61

 Phương pháp thứ nhất sử dụng 3 bit trường EXP của tiêu ñề MPLS. Theo cách ñó,
có tối ña 8 lớp BA và một giá trị EXP ñược ánh xạ ñến một mô tả PHB hoàn
chỉnh: trình tự huỷ và xếp hàng.
 Phương pháp thứ hai, nếu có hơn 8 lớp dịch vụ, RFC 2309 ñề xuất một kiểu LSP
khác. Do ñó, DSCP ñược ánh xạ vào một cặp <Label, EXP>. Nhãn này trao ñổi
thông tin riêng về hàng ñợi và lập lịch L-LSP. ở trên ñoạn giữa của LSP, sự phân
loại BA ñược dựa trên EXP hay các trường nhãn của tiêu ñề MPLS chứ không
phải DSCP ñược lưu trong tiêu ñề IP. Do ñó, hành vi cho mỗi chặng của gói tin
cũng là duy nhất.
MPLS kết hợp với Diffserv trong mạng lõi ñem lại lợi ích cho cả các thành phần của
MPLS và Diffserv. MPLS cung cấp các dịch vụ phân biệt Diffserv với ñặc tính khôi phục
và bảo vệ ñường dẫn, trong khi Diffserv hoạt ñộng như một kiến trúc phân lớp dịch vụ
cho MPLS. MPLS với Diffserv có thể ñưa ra các thiết kế mạng mềm dẻo ñể cung cấp các
xử lý khác nhau cho các lớp dịch vụ CoS trong ñường dẫn lưu lượng. Kiểu ghép hai mức
ñược sắp xếp nhờ vào giao thức RSVP, RSVP thiết lập và duy trì một số lượng ñường
dẫn LSP MPLS và trên các ñường dẫn ñó ñược phân lớp dịch vụ theo kiến trúc Diffserv.
ðể ñảm bảo các chức năng của Diffserv qua mạng MPLS, Các ñiểm mã dịch vụ DSCP
ñược chuyển tới các LSR nhằm chỉ ra các xử lý tương thích với QoS yêu cầu.
(i) Mô hình IntServ và MPLS
MPLS tái sử dụng các giao thức của IP, RSVP cũng là một trong các giao thức ñược
tái sử dụng và ñược cải thiện. RSVP nguyên thuỷ [RFC 2205] ñược thiết kết cho các ứng
dụng thời gian thực qua mạng Internet. ðã có rất nhiều các ứng dụng mở rộng của RSVP

ñể hỗ trợ thêm các ñặc tính như tính bảo mật và khả năng mềm dẻo; hỗ trợ các giao diện
tới các thiết bị trong miền Diffserv; hỗ trợ kỹ thuật lưu lượng trong các ứng dụng mới
như MPLS và GMPLS (RSVP-TE).

Hình 3.15: Thực hiện phân bổ nhãn qua RSVP-TE
Các ñặc tính của RSVP-TE [RFC 3209] là sự mở rộng phần lõi của RSVP ñể thiết
lập các tuyến ñường hiện dựa trên ñịnh tuyến ràng buộc các LSP trong mạng MPLS sử


62

dụng RSVP làm giao thức báo hiệu. Dự trữ tài nguyên là một thành phần rất quan trọng
của xử lý lưu lượng. ðây là một trong số các lý do ñể nhóm làm việc MPLS chọn RSVP
hơn là việc xây dựng mới hoàn toàn một giao thức báo hiệu khác ñể hỗ trợ các yêu cầu
xử lý lưu lượng. RSVP mở rộng thành giao thức báo hiệu ñể hỗ trợ việc tạo LSPs có thể
ñược ñịnh tuyến tự ñộng tránh khỏi lỗi mạng và tắc nghẽn. RSVP ñơn giản hoá việc vận
hành mạng bằng quá trình xử lý lưu lượng một cách tự ñộng. RSVP-TE sử dụng các bộ
ñịnh tuyến chuyển mạch ñể thiết lập, duy trì các ñường ống LSP và ñể phục vụ tài
nguyên cho các LSP ñó.
RSVP-TE yêu cầu thiết bị có khả năng mang một ñối tượng “mờ” (opaque object),
nghĩa là các ñối tượng này không bị xử lý bởi các thiết bị khác khi truyền trong mạng.
RSVP mang các ñối tượng trong các bản tin của nó như là các ñoạn mờ của thông tin
(hình 3.15). Những ñoạn mờ này ñược mang tới các module ñiều khiển thích hợp trong
bộ ñịnh tuyến. Phương thức thiết lập báo hiệu dựa trên cơ sở này khuyến khích sự phát
triển của các ñối tượng RSVP mới. Các ñối tượng này có thể ñược dùng ñể tạo ra và duy
trì các trạng thái ñược phân phối cho các thông tin khác ngoài vấn ñề dự trữ tài nguyên
ñơn thuần.Tập hợp các mở rộng có thể nhanh chóng và dễ dàng ñược phát triển qua việc
cải thiện RSVP nhằm hỗ trợ các yêu cầu xử lý lưu lượng mang tính tức thời trong vấn ñề
ñịnh tuyến chính xác và giảm ñộ phức tạp trong quá trình phân phối nhãn.

Hình 3.16: Cấu trúc bản tin RSVP-TE
Các khuyến nghị mới ñể mở rộng RSVP ñược yêu cầu tương thích hoàn toàn với
RSVP truyền thống. RSVP-TE có thể dễ dàng phân biệt báo hiệu thiết lập ñường LSP của
MPLS với RSVP truyền thống bằng cách kiểm tra các ñối tượng chứa trong các bản tin.
Như vậy hệ thống báo hiệu hợp nhất mang mọi ñối tượng cần thiết ñể thiết lập LSP một
cách mềm dẻo.
Các ñặc ñiểm cơ bản của RSVP-TE hỗ trợ trong MPLS ñược tóm tắt dưới ñây:


63

Các kiểu LSP ñược cung cấp
Giao thức RSVP cung cấp các ñường dẫn chuyển mạch ñịnh tuyến hiện ER-LSP theo
cả hai kiểu chặt và lỏng, chức năng này lợi dụng chính hai kiểu ñịnh tuyến trong MPLS
(ñịnh tuyến hiện và ñịnh tuyến từng bước). ðối với phương pháp lỏng trong các ñường
dẫn ER-LSP, phương pháp ñịnh tuyến từng bước ñược sử dụng ñể xác ñịnh nơi bản tin
gửi ñến. Vì thế RSVP cũng cung cấp ñịnh tuyến từng bước dựa trên yêu cầu ñường
xuống.
Các tham số QoS
Ban ñầu RSVP ñược thiết kế ñể cung cấp các dịch vụ tích hợp, nó không có khả
năng phân biệt dịch vụ trong các mạng mang. Vì thế RSVP không có khả năng báo hiệu
các dịch vụ phân biệt. ðể tương thích với các dịch vụ phân biệt RSVP truyền và ñiều
khiển khéo léo các tham số ñiều khiển QoS như là dữ liệu "mờ", gửi các dữ liệu này tới
module ñiều khiển lưu lượng thích hợp ñể thực hiện dự trữ tài nguyên cho các lớp dịch
vụ phân biệt.
Kiến trúc báo hiệu trong mạng
RSVP-TE ñược thiết kế dựa trên cây multicast IP, thực hiện thống nhất dự trữ tài
nguyên hướng tới thiết bị gửi. Trong phạm vi MPLS, chỉ có kết nối ñơn phương ñược
xem xét, nên nó bỏ ñi một số kiểu dự trữ và kiến trúc gốc thiết bị gửi. Trong suốt thời
gian báo hiệu, các yêu cầu các lớp dịch vụ và QoS thường ñược khởi tạo từ thiết bị

nhận.Với các ñường dẫn chuyển mạch ñịnh tuyến hiện ER - LSP, nhà quản lý mạng
thường xuyên cấu hình và khởi tạo các yêu cầu và chính sách từ thiết bị gửi hơn là từ
thiết bị nhận hoặc cả hai.
Chỉ thị lỗi
Do thiếu các cơ chế hỗ trợ vận chuyển tin cậy, RSVP không thể nhanh chóng thông tin
cho ñiểm kết cuối rằng kết nối giữa chúng bị lỗi, RSVP có một bản tin ngắt ñường nhưng
nó lại không ñược gửi một cách tin cậy. Chính vì vậy, ñiểm cuối không thể bắt ñầu tái
ñịnh tuyến cho ñến khi kết thúc khoảng thời gian xoá bỏ trạng thái mềm.
Khả năng tái ñịnh tuyến
Kiểu dự trữ tài nguyên RSVP SE ñược sử dụng thiết lập ñồng thời 2 ñường cho một
phiên ñể ñịnh tuyến thích nghi luân phiên xuyên qua mạng bằng cơ chế nối trước khi cắt.
Trong kiểu này, một phiên có thể thiết lập một ñường khác cho LSP, sử dụng một nhận
dạng ñường khác với ñường ban ñầu. Thiết bị gửi gửi một bản tin Path sử dụng ñối tượng
phiên ban ñầu và LSP ID mới và ñối tượng tuyến hiện ñể chỉ thị tuyến mới. Sau ñó trên
các liên kết mà không chiếm giữ chung, bản tin Path mới ñược ñối xử như là thiết lập
LSP mới thông thường. Trên các liên kết ñược duy trì, ñối tượng phiên chia sẻ và kiểu SE
cho phép LSP ñược thiết lập chia sẻ tài nguyên với LSP cũ. Mỗi lần thiết bị gửi nhận


64

một bản tin Resv cho LSP mới, nó có thể truyền lưu lượng vào ñó và huỷ bỏ LSP cũ. ðặc
ñiểm này có thể ñược sử dụng trong việc tối ưu lại lưu lượng, không sử dụng cho cân
bằng tải. Khi sử dụng ñặc tính này, chú ý rằng chỉ có một ER - LSPs mang lưu lượng và
tất cả ñường thứ hai khác ñều trống rỗng.
Quyền giành trước ñường
RSVP sử dụng các ñộ ưu tiên thiết lập và chiếm giữ ñường dể xác ñịnh ñường mới có
thể chiếm trước ñường ñang tồn tại. Cơ chế vận chuyển của RSVP, trên IP có thể gây ra
các vấn ñề khác nữa ñối với việc hỗ trợ ñặc ñiểm này. Bởi vì quyền giành trước thường
xuyên ñược yêu cầu khi mạng ñang chạy trong khi thiếu tài nguyên, bản tin báo hiệu

RSVP có thể bị mất trong trường hợp này.
Tối ưu lại ñường
Khả năng tái ñịnh tuyến trong RSVP có thể ñược sử dụng ñể tối ưu ñường.
Khôi phục lỗi
Các mở rộng của RSVP mang lại ñặc ñiểm tái ñịnh tuyến ñể ñiều khiển khôi phục lỗi.
Nhưng trong trường hợp này, nối trước khi cắt không ñược sử dụng. RSVP ñưa ra một
lựa chọn tái ñịnh tuyến nhanh cục bộ ñể ñiều khiển tình huống lỗi. Tái ñịnh tuyến nhanh
liên quan ñến tính toán ñường vòng trước tại mỗi nút dọc theo ñường. Tiếp cận này ñòi
hỏi rất nhiều các giải pháp mở rộng tính toán. Số lượng lớn cả hai ñường phải ñược tính
trước, ñể ñảm bảo rằng chúng không nối với nhau và ñược duy trì ñể sử dụng trong ñiều
kiện lỗi.
Tách vòng lặp
ðể ñiều khiển tách vòng lặp, ñối tượng ghi thông tin tuyến ñược sử dụng, nó cũng có
thể cung cấp thông tin tuyến của LSP xác ñịnh cho mục ñích chẩn ñoán tuyến.
Vấn ñề khả năng gia tăng kế thừa
ðể giải quyết vấn ñề này, các mở rộng gần ñây nhất cho phép kết hợp bản tin làm tươi
ñể giảm bớt số lượng bản tin này, khi số lượng lớn LSP tồn tại. ðể giảm quá trình nạp
các bản tin làm tươi trong một nút, nhận dạng bản tin ñược ñưa ra, mục ñích ñể cho các
nút nhận nhanh chóng nhận ra trạng thái thay ñổi. Tuy nhiên sử dụng nhận dạng nút (ID
node) cần phải quản lý chắc chắn số lượng ID và bản tin ñể tránh nhiều lỗi có thể. Các
mở rộng mới nhất cấm hoàn toàn các bản tin làm tươi. LSR phải sử dụng giao thức mới
ñể phát hiện mất các kế cận.
Hệ thống báo hiệu linh ñộng
Thiết kế trạng thái mềm rất linh ñộng, RSVP có thể linh ñộng ñối với các node khi xử lý
các tình huống tắc nghẽn nhưng không nhanh chóng trong việc khôi phục LSP.




65

Tóm tắt chương 3
Chương 3 tập trung vào hai mô hình ñảm bảo chất lượng dịch vụ IP: mô hình tích
hợp dịch vụ IntServ và mô hình phân biệt dịch vụ DiffServ. Các ñặc ñiểm của hai mô hình
ñược trình bày chi tiết nhằm giúp người ñọc nắm bắt rõ các khía cạnh ứng dụng của hai
mô hình trong mạng IP thực tế. Một số vấn ñề ñược trình bày trong chương 1 và chương
2 ñược tổng kết và ứng dụng trong chương 3 tạo ra một cách nhìn nhận xuyên suốt về
khía cạnh ñảm bảo chất lượng IP. Một số ñặc tính cơ bản của mô hình ứng dụng QoS IP
ñược thực hiện trong MPLS ñược giới thiệu là những thông tin khởi ñầu cho một tài liệu
tiếp theo.

66



BÀI TẬP
Bài 1: Xác ñịnh màu gói tin trong srTCM

Hình1- BT1: Lưu ñồ nguyên lý ñánh dấu

Hình2- BT1: Lưu ñồ nguyên lý srTCM
Giả thiết:
 Phương thức hoạt ñộng mù màu
 CIR = 1000 byte/s
 CBS = 50 token
 EBS = 400 token
 Tại thời ñiểm t, Tc=10 token, Te=70 token.
 Tại thời ñiểm t, một gói có kích thước 5 byte ñến.


67

Yêu cầu
 Căn cứ theo nguyên lý trên hình1-BT1

 Xác ñịnh màu của gói tin
 Tính Te và Tc sau khi xử lý gói.

Bài 2: Xác ñịnh trạng thái gáo rò sau một khoảng thời gian

Hình 1-BT2:ðánh dấu 3 màu tốc ñộ ñơn
Giả thiết:
 Phương thức hoạt ñộng mù màu
 CIR = 100 byte/s
 CBS = 50 token
 EBS = 400 token
 Tại thời ñiểm t, Tc=10 token, Te=50 token.
 Thời gian cập nhật token t’ = t + (1/100)
 Sau 2 giây, không có gói ñến
Yêu cầu
 Căn cứ theo nguyên lý trên hình1-BT1
 Xác ñịnh trạng thái Te và Tc sau 2 giây.

Bài 3: Xác ñịnh thứ tự ưu tiên trong WFQ