76425396 Tieu Luan Chat Luong DV Tren Mang IP Cuong Thanh

Các phương pháp nâng cao chất lượng dịch vụ trên mạng IP---------------------------------------------------------------------------------------------------------------

Mục lụcMục lục....................................................................................................................................1

Lời nói đầu...............................................................................................................................2

PHẦN I....................................................................................................................................3

MẠNG IP & CÁC THÔNG SỐ ẢNH HƯỞNG ĐẾN CHẤT LƯỢNG DỊCH VỤ..........3

I.1. Phân loại lưu lượng và ứng dụng trên mạng IP............................................................3

I.2. Các thông số đánh giá chất lượng dịch vụ....................................................................5

I.2.1. Trễ................................................................................................................................5

I.2.2. Thông lượng.................................................................................................................5

I.3. Vấn đề cung cấp chất lượng dịch vụ trên mạng IP.......................................................6

PHẦN 2....................................................................................................................................7

CÁC PHƯƠNG PHÁP NÂNG CAO CHẤT LƯỢNG DỊCH VỤ TRÊN MẠNG IP.......7

II.1. Mô hình dịch vụ tích hợp (IntServ)..............................................................................8

II.1.1. Những đặc trưng chính của mô hình IntServ..............................................................8

II.1.2. Giao thức RSVP........................................................................................................10

II.1.2.1. Các đặc trưng của RSVP....................................................................................10

II.1.2.2. Mô hình hoạt động của giao thức RSVP............................................................11

II.1.2.3. Một số vấn đề của giao thức RSVP....................................................................16

II.1.3. Kiểm soát chấp nhận.................................................................................................16

II.1.4. Phân loại gói tin........................................................................................................17

II.1.5. Lập lịch gói tin..........................................................................................................17

II.1.6. Kiến trúc dịch vụ tích hợp........................................................................................18

II.1.6.1. Dịch vụ tải có kiểm soát.....................................................................................20

II.1.6.2. Dịch vụ đảm bảo (Guaranteed Service)..............................................................22

II.1.7. Các vấn đề với mô hình dịch vụ tích hợp.................................................................23

II.2. Mô hình dịch vụ phân biệt...........................................................................................24

II.2.1. Các đặc điểm chính của mô hình DiffServ...............................................................24

II.2.2. Kiến trúc dịch vụ phân biệt.......................................................................................25

II.2.3. Định nghĩa dịch vụ....................................................................................................27

II.2.3.1. Trường DS và các PHB cơ bản..........................................................................27

II.2.3.2. PHB chuyển tiếp nhanh......................................................................................29

II.2.3.3. PHB chuyển tiếp có đảm bảo.............................................................................29

II.2.4. Quản lý động tài nguyên trong mô hình DiffServ...................................................30

II.2.4.1. Tổng quan về Bandwidth Broker.......................................................................30

II.2.4.2. Kiến trúc của một hệ thống BB..........................................................................32

II.2.5. Ưu điểm và hạn chế của dịch vụ Diffserv................................................................33

II.2.5.1. Ưu điểm..............................................................................................................33

II.2.5.2. Hạn chế của Diffserv..........................................................................................33

1


II.3. Multi Switching Label Protocol và Traffic Engineering.........................................34

II.3.1. Giới thiệu..................................................................................................................34

II.3. 2. Kiến trúc MPLS.......................................................................................................35

II.3.2.1. Các thành phần chính trong mô hình..................................................................36

II.3.2.2. Forwarding Equivalent Class.............................................................................36

II.3.2.3. Label Distribute Protocol...................................................................................37

II.3.3. Traffic Engineering với MPLS.................................................................................37

II.3.3.1. Giới thiệu chung.................................................................................................37

II.3.3.2. Mô hình thực hiện..............................................................................................38

II.3.4. Kết luận.....................................................................................................................39

PHẦN 3 ĐÁNH GIÁ, KẾT LUẬN......................................................................................40

III.1. Đánh giá, phân tích các phương pháp:.....................................................................40

III.2. Đề xuất, kiến nghị........................................................................................................41

III.3. Phương án thực hiện các đề xuất và kiến nghị.........................................................41

III.3.1. Mô hình Kết hợp IntServ và DiffServ.....................................................................41

III.3.1.1. Lợi ích của mô hình kết hợp Intserv và Diffserv..............................................41

III.3.1.2. Framework cho Intserv/RSVP over Diffserv....................................................42

III.3.1.3. Thực thi Framework..........................................................................................44

III.3.1.4. Kết luận.............................................................................................................44

III.3.2. Hỗ trợ Diffserv trên MPLS......................................................................................44

III.3.2.1. Lợi ích của kết hợp Diffserv và MPLS.............................................................44

III.3.2.2. Nguyên tắc........................................................................................................45

III.3.2.3. Các hoạt động của LSR Diffserv MPLS...........................................................45

III.3.2.4. Những ưu điểm và tồn tại của hai mô hình E-LSP và L-LSP..........................46

III.3.2.5. Kết luận.............................................................................................................46

Kết luận..................................................................................................................................47

Tài liệu tham khảo................................................................................................................48

2


Lời nói đầu

Ngày nay, các mạng dùng công nghệ IP, đặc biệt là Internet đã trở thành công cụ

quan trọng trong nhiều lĩnh vực. Cùng với các dịch vụ truyền thống (như email, FTP,

WWW,. . .) các dịch vụ mới (truyền tiếng nói, hình ảnh hay đa phương tiện) đòi hỏi tính thời

gian thực cũng ngày càng phát triển. Nhu cầu truyền các dịch vụ thời gian thực trong mạng

IP tăng lên nhanh chóng trong khi mô hình cung cấp dịch vụ truyền thống trong mạng IP

dựa trên việc truyền gói tin với cố gắng tối đa (best – effort) không đáp ứng được những yêu

cầu chặt chẽ về mặt thời gian, độ trễ hay băng thông của các dịch vụ thời gian thực đòi hỏi

phải có giải pháp để giải quyết vấn đề này.

Để đáp ứng được yêu cầu của các ứng dụng thời gian thực, có hai giải pháp cơ bản.

Giải pháp thứ nhất là bổ xung thêm tài nguyên bằng cách nâng cấp cơ sở hạ tầng truyền

thông. Nhưng giải pháp này tốn kém và dù tài nguyên mạng có tăng thì các ứng dụng tiêu

tốn tài nguyên cũng tăng lên và tài nguyên được xem là luôn thiếu so với nhu cầu. Giải pháp

thứ hai hợp lý hơn là bổ sung các cơ chế hỗ trợ chất lượng dịch vụ vào hạ tầng mạng. Do đó

tổ chức Internet Engineering Task Fork (IETF) đã nghiên cứu, phát triển và đưa ra bốn

phương pháp nhằm thực hiện phương án này. Đó là các phương pháp:

- Mô hình dịch vụ tích hợp ( Integrated Services – IntServ)

- Mô hình dịch vụ phân biệt (Differentiated Services – DiffServ)

- Multiprotocol Label Switching

- Traffic Engineering

Trong tiểu luận này, chúng em xin trình bầy về 4 phương pháp hỗ trợ chất lượng

dịch vụ trên. Đánh giá ưu nhược điểm của từng phương pháp và đưa ra các kiến nghị và đề

xuất của riêng mình.

Chúng em xin cám ơn thầy giáo Ngô Hồng Sơn đã cung cấp các kiến thức quý báu

để chúng em hoàn thành tiểu luận này.

3


PHẦN I

MẠNG IP & CÁC THÔNG SỐ ẢNH HƯỞNG ĐẾN CHẤT LƯỢNG

DỊCH VỤ

I.1. Phân loại lưu lượng và ứng dụng trên mạng IPTrên mạng IP có hai loại lưu lượng khác nhau cơ bản là lưu lượng thời gian thực và

lưu lượng dữ liệu (data traffic, lưu lượng không có thuộc tính thời gian thực)

Lưu lượng dữ liệu tạo bởi các ứng dụng như telnet, ftp, www, email,. .. . Đó là các

ứng dụng mềm dẻo (chúng luôn đợi dữ liệu đến). Độ trễ lớn sẽ làm giảm hiệu suất thực hiện

ứng dụng nhưng dữ liệu đi đến đều được sử dụng. Các ứng dụng mềm dẻo có thể tiếp tục

được phân loại căn cứ vào đòi hỏi độ trễ của chúng. Interactive burst traffic

(như telnet, NFS) cần độ trễ nhỏ, interactive bulk traffic (như ftp, www) cần độ trễ trung

bình, asynchronous bulk traffic (email) không bị ảnh hưởng gì bởi độ trễ.

Lưu lượng dữ liệu thường là rời rạc và không đoán trước được. Các liên kết thường

có tuổi thọ ngắn và dùng để truyền một hay nhiều khối dữ liệu. Các ứng dụng gửi dữ liệu đi

với khả năng nhanh nhất có thể được rồi dừng lại. Do đó lưu lượng dữ liệu mang tính bùng

nổ. Lưu lượng thời gian thực tạo bởi các ứng dụng thời gian thực. Các ứng dụng thời gian

thực đểu có đặc tính chỉ chịu độ trễ nhỏ. Khác với các ứng dụng mềm dẻo, chúng rất nhạy

cảm với độ trễ và sự biến thiên độ trễ. Quá trình truyền dữ liệu của ứng dụng thời gian thực

thường đều và kéo dài, luồng dữ liệu có tính điều hoà. Để mô tả luồng dữ liệu thời gian thực,

một phương pháp thường được sử dụng là mô hình giỏ thẻ bài (token bucket model). Một bộ

giỏ thẻ bài được xác định bởi hai tham số : tốc độ thẻ bài r và kích thước giỏ b .

Trong hình 2, r là tốc độ thẻ bài xếp vào giỏ, nếu giỏ đầy các thẻ bài kế tiếp sẽ bị

loại, như vậy giỏ chỉ chứa được tối đa b thẻ bài. Những gói đi đến sẽ được lưu vào hàng đợi.

Để truyền gói đi các thẻ bài được lấy ra khỏi giỏ với một lượng tương đương với kích thước

gói, mỗi khi một gói kích thước p được gửi đi, p thẻ bài sẽ chảy ra khỏi giỏ. Gói chỉ được

gửi đi khi trong giỏ có đủ thẻ bài. Với cơ chế này lưu lượng dữ liệu được kiểm soát (trong

thời gian T, lưu lượng gửi đi không thể vượt quá rt + b)

4

IP applicationsIP traffic

Real – time applicationsReal – time traffic

Elastic applicationsData traffic

Hình 1 . Phân loại ứng dụng và lưu lượng trên mạng IP


I.2. Các thông số đánh giá chất lượng dịch vụ Chất lượng dịch vụ là khả năng của mạng cung cấp dịch vụ tốt hơn cho các lưu

lượng mạng được lựa chọn trên các công nghệ khác nhau như Frame Relay, ATM,. .. Nói

cách khác, đó là đặc tính của mạng cho phép phân biệt các lớp lưu lượng khác nhau và xử lý

chúng một cách phù hợp.

Các thông số quyết định chất lượng dịch vụ là trễ, thông lượng và mất mát

I.2.1. Trễ

Trễ của lưu lượng dịch vụ là đặc tính rất quan trọng của chất lượng dịch vụ. Các khía

cạnh khác nhau của trễ có ảnh hưởng khác nhau đến các dịch vụ.

- Trễ đầu cuối đến đầu cuối (end – to – end)

- Biến thiên trễ (jitter)

Các ứng dụng tương tác thời gian thực (như truyền thông thoại) nhạy cảm với trễ đầu

cuối đến đầu cuối và biến thiên trễ. Độ trễ dài ảnh hưởng đến tính tương tác của quá trình

thông tin .

Các ứng dụng phi tương tác thời gian thực (như quảng bá một chiều) không nhạy

cảm với trễ đầu cuối đến đầu cuối nhưng bị ảnh hưởng bởi biến thiên trễ. Biến thiên trễ

thường được điều chỉnh bằng cách dùng bộ đệm tại đầu thu, tại đó các gói đến được giữ và

phát lại tại thời điểm thích hợp. Thời điểm phát (điểm phát lại) được xác định bởi biến thiên

trễ tối đa. Các ứng dụng có thể điều chỉnh điểm phát lại dựa trên sự thay đổi giá trị biến

thiên trễ gọi là các ứng dụng thích nghi. Các gói đến sau thời điểm phát lại thường không

còn giá trị với ứng dụng.

5

Hình 2 . Nguyên lý hoạt động của mô hình giỏ thẻ bài

Gói dữ liệu đi Gói dữ liệu đến

Hàng đợi độ dài cố định

Giỏ ( kích thước b )

Các thẻ bài đi đến với tốc độ không đổi r


Các ứng dụng không có thuộc tính thời gian thực không nhạy cảm với trễ. Đó là do

các ứng dụng này có thể dùng các phép đo trễ để điều khiển tốc độ lưu lượng (như TCP) hay

lưu trữ dữ liệu cho đến khi được báo nhận (như FTP). Trễ lớn hoặc thay đổi có thể ảnh

hưởng đến chất lượng của những ứng dụng này .

Các thành phần khác nhau của trễ đầu cuối đến đầu cuối là :

- Trễ phát: là thời gian cần thiết để đưa tất cả các bit của gói tin vào đường truyền

- Trễ truyền: là thời gian một bit truyền qua kênh

- Trễ xử lý: là thời gian xử lý một gói trong phần tử mạng

- Trễ hàng đợi: là thời gian gói tin phải đợi trong hàng đợi trước khi nó được truyền đi

Tại đầu cuối, có thể có các trễ khác khi nhận gói tin từ giao diện mạng đến chương

trính và cuối cùng đến người sử dụng .

I.2.2. Thông lượng

Khía cạnh chính của thông lượng là băng thông dành cho ứng dụng. Nó xác định lưu

lượng mà ứng dụng có thể truyền qua mạng. Một khía cạnh quan trọng khác là lỗi (thường

liên quan đến tỷ lệ lỗi được truyền) và mất mát (thường liên quan đến dung lượng bộ đệm)

Với ứng dụng thời gian thực cứng, chúng chỉ có giá trị khi được cung cấp một lượng

dải thông nhất định. Các ứng dụng thích nghi có yêu cầu thấp hơn, hiệu suất của các ứng

dụng này tăng nhanh khi dải thông tăng lên, nhưng chỉ đến một mức độ nhất định, khi dải

thông tiếp tục tăng, hiệu suất ứng dụng không được cải thiện. Đối với các ứng dụng mềm

dẻo, hiệu suất ít phụ thuộc vào dải thông hơn nhưng khi tăng dải thông thì luôn nâng cao

được hiệu suất ứng dụng .

Hình 3 thể hiện sự phụ thuộc hiệu suất của ứng dụng vào dải thông của các loại ứng dụng

Một số ứng dụng có thể giảm tốc độ truyền để thích ứng với dấu hiệu thông lượng

thấp. Các ứng dụng này được gọi là thích ứng tốc độ.

Thông lượng phụ thuộc vào các yếu tố sau :

- Đặc tính đường truyền: băng thông, tỷ lệ lỗi

- Đặc tính nút mạng: dung lượng bộ đệm, năng lực xử lý

6

Hiệu suất

Dải thông

a. Ứng dụng thời gian thực cứng

b. Ứng dụng thích nghi độ trễ

Hiệu suất

Dải thông

c. Ứng dụng mềm dẻo

Hiệu suất

Dải thông

Hình 3 . Sự phụ thuộc của hiệu suất ứng dụng vào dải thông


Một số đặc tính của các phần tử mạng khác nhau như các thiết bị đầu cuối / máy chủ,

chuyển mạch / bộ định tuyến xác định chất lượng dịch vụ cung cấp cho ứng dụng theo các

chỉ tiêu về thông lượng và độ trễ.

I.3. Vấn đề cung cấp chất lượng dịch vụ trên mạng IPCác mạng hiện nay cần hỗ trợ nhiều kiểu lưu lượng trên cùng một liên kết mạng đơn.

Các kiểu lưu lượng khác nhau yêu cầu mạng phải xử lý khác nhau. Lưu lượng chỉ có thể

được phân biệt tại các phần tử mạng tích cực đó là bộ định tuyến (router), chuyển mạch

(switch) và gateway .

Vì vậy, yêu cầu thiết kế mạng bao gồm :

Mạng có thể truyền nhiều loại dịch vụ, có nghĩa là chúng phải quan tâm đến chất

lượng dịch vụ

Khả năng mở rộng, nghĩa là lưu lượng mạng có thể tăng mà không làm ảnh hưởng

đến hoạt động của mạng

Khả năng hỗ trợ các ứng dụng quan trọng, dùng nhiều tài nguyên mạng, các ứng

dụng này đóng vai trò quan trọng trong hoạt động kinh doanh của các doanh nghiệp

Có hai cơ chế cơ bản để cung cấp chất lượng dịch vụ thích hợp dựa trên các tiêu

chuẩn trễ và thông lượng.

Cung cấp đủ dung lượng

Sử dụng công nghệ quản lý lưu lượng

Khi có đủ dung lượng tài nguyên trong mạng thì không cần một cơ chế đặc biệt nào

để đảm bảo chất lượng dịch vụ. Điều đó bao gồm có đủ :

Đường truyền tốc độ cao

Các bộ xử lý mạnh

Bộ đệm dung lượng lớn

Cơ chế này thích hợp cho môi trường cục bộ có điều khiển như mạng LAN của các

doanh nghiệp nhưng không phù hợp với các mạng lớn như mạng Internet. Trong khi giá

băng thông, bộ nhớ và bộ xử lý đang giảm đi thì giá của các thiết bị đầu cuối và đường

truyền viễn thông tốc độ cao đáp ứng mô hình này vẫn còn khá cao .

Cơ chế cung cấp chất lượng dịch vụ thứ hai là sử dụng công nghệ quản lý lưu lượng.

Ý tưởng ở đây là lưu lượng có thể được phân biệt và cung cấp các mức dịch vụ khác nhau.

Mức độ phân biệt có thể là một tập nhỏ các lớp hay phân biệt đến từng luồng ứng dụng. Phải

có cơ chế điều khiển mức lưu lượng của từng lớp được đưa vào mạng tuỳ theo tài nguyên

sẵn có – điều này có thể được thực hiện tĩnh (bằng cách cung cấp trước) hay động (báo hiệu

việc dự trữ tài nguyên). Phải có các cơ chế chuyển tiếp lưu lượng hiệu quả trên mạng. Hơn

nữa, phần tử mạng phải quản lý việc xử lý và xếp hàng đợi các gói một cách thích hợp đảm

bảo việc cung cấp các dịch vụ khác nhau tuỳ theo từng gói.

7


PHẦN 2

CÁC PHƯƠNG PHÁP NÂNG CAO CHẤT LƯỢNG DỊCH VỤ

TRÊN MẠNG IP

IETF đã đưa bốn phương pháp cung cấp chất lượng dịch vụ trong mạng IP

Integrated Services – IntServ

Differentiated Services – DiffServ

Multiprotocol Label Switching

Traffic Engineering

Intserv cho phép đặt trước một kênh xuyên qua mạng với băng thông đảm bảo. Nó

dự trữ tài nguyên mạng một cách rõ ràng bằng giao thức báo hiệu động và sử dụng kiểm soát

chấp nhận, phân loại gói, lâp lịch thông minh để đạt được chất lượng dịch vụ mong muốn

DiffServ phân loại các gói thành một số nhỏ các kiểu dịch vụ và dùng cơ chế ưu tiên

để cung cấp chất lượng dịch vụ thích hợp cho lưu lượng. Ở đây không sử dụng dự trữ tài

nguyên hay kiểm soát chấp nhận, mặc dù các nút có sử dụng cơ chế hàng đợi thông minh để

phân biệt lưu lượng.

MPLS không phải là mô hình như Intserv và Diffserv, nó là một chuẩn kết hợp công

nghệ chuyển mạch nhanh tầng hai và định tuyến tầng ba cho phép dẫn đường hiệu quả.

MPLS thêm một nhãn ngắn vào gói tin IP và thực hiện chuyển tiếp packet dựa trên nhãn này

để tránh những phức tạp do phải xử lý header của gói tin IP.

Traffic Engineering được sử dụng để đạt được mục tiêu hiệu năng như tối ưu tài

nguyên mạng và sắp đặt lưu lượng vào các đường truyền cụ thể. Bằng cách sử dụng một

công nghệ như MPLS, traffic engineering cho phép giảm tắc nghẽn lưu lượng trên mạng .

Sau đây chúng ta sẽ xem xét các phương pháp này .

II.1. Mô hình dịch vụ tích hợp (IntServ)Integrated Service là mô hình QoS đầu tiên được IETF phát triển vào đầu những năm

1990 và một số phần của mô hình này ngày nay vẫn đang được hoàn thiện. Khi nhóm

Integrated Service bắt đầu, World Wide Web chưa xuất hiện và trao đổi đa phương tiện được

xem là ứng dụng tương lai. Do đó, IntServ là một chuẩn phù hợp nhất với truyền thông

đường dài với băng thông đảm bảo.

Trong IntServ nhiều lớp lưu lượng được các phần tử mạng đảm bảo các loại chất

lượng dịch vụ khác nhau . Ở đây các ứng dụng cần biết trước các đặc tính lưu lượng của

chúng và báo hiệu cho các phần tử mạng trung gian để đặt trước các tài nguyên nhất định

nhằm đáp ứng tính chất lưu lượng của nó. Tuỳ theo sự khả dụng, mạng có thể để dành tài

nguyên và gửi về một báo nhận tích cực hoặc không đáp ứng yêu cầu đó .

8


Ý tưởng chính của IntServ là hỗ trợ đăng ký từng luồng. InteServ cho phép đăng ký

trên toàn tuyến trước khi thực sự gửi dữ liệu.

Trung tâm của Integrated Service là giao thức đăng ký tài nguyên RSVP. Khi một

sender muốn truyền lưu lượng tới một receiver (thông qua unicast hay multicast), sender gửi

một thông điệp PATH tới receiver. Một thông điệp PATH chuyển thông tin tới receiver về

nguồn lưu lượng, đặc điểm của đường đi mạng và cuối cùng nó cài đặt trạng thái cần thiết để

thông điệp RESV có thể tìm đến sender từ receiver. Khi receiver nhận được thông điệp

PATH, nó trả lại một thông điệp RESV dọc theo đường mà thông điệp PATH đã đi qua.

Thông điệp RESV thực sự đặt trước băng thông cần thiết trong router dọc theo đường đi.

Khi sender nhận được thông điệp RESV, nó mới bắt đầu truyền dữ liệu .

II.1.1. Những đặc trưng chính của mô hình IntServ

a) Luồng (flow)

Luồng là một dòng các gói sinh ra từ cùng một hành động của người sử dụng ví dụ

một phiên ứng dụng đơn. Có thể xác định luồng bằng các cơ chế khác nhau .Ví dụ IP V6

dùng địa chỉ nguồn và nhãn luồng còn IP V4 dùng địa chỉ nguồn, địa chỉ đích và cổng đích .

b) Các loại dịch vụ

IntServ định nghĩa các loại dịch vụ có thể cung cấp, dựa trên các yêu cầu về trễ và

mất mát, cụ thể là :

* Dịch vụ đảm bảo : cung cấp sự đảm bảo tuyệt đối về trễ và mất mát gói mà luồng phải

chịu (dùng cho các ứng dụng thời gian thực không thích nghi). Các gói tuân theo sự dự

trữ sẽ không bị mất hay trễ quá giới hạn xác định. Sự đảm bảo chặt chẽ đòi hỏi mức dự

trữ tài nguyên cao

* Dịch vụ tải có kiểm soát : cung cấp dịch vụ tương được với mạng không quá tải (dùng

cho các ứng dụng thích nghi hoạt động tốt trong điều kiện mạng tải nhẹ) . Phần lớn gói

tin sẽ không bị mất hay trễ hàng đợi. Nhưng ở đây không cung cấp mức đảm bảo mang

tính địng lượng cụ thể

* Đặc điểm lưu lượng (Traffic Specification – Tspec)

Lưu lượng luồng được đặc trưng bởi đặc điểm lưu lượng (Tspec). Tspec chứa các

tham số tốc độ thẻ bài r, kích thước giỏ b (giỏ thẻ bài), tốc độ đỉnh p (peak rate), đơn vị

xử lý nhỏ nhất m và kích thước gói tối đa M

- Tốc độ thẻ bài r xác định tốc độ truyền dữ liệu liên tục không đổi, kích thước giỏ b

xác định mức độ mà tốc độ truyền dữ liệu có thể vượt quá tốc độ cho phép trong một

khoảng thời gian ngắn

- Tốc độ đỉnh p là tốc độ tối đa mà nguồn và các điểm đinhj dạng lưu lượng có thể gây

ra bùng nổ lưu lượng trên mạng

9


- Đơn vị xử lý nhỏ nhất m (minimum policed unit), xác định số byte được tính khi

kiểm tra lưu lượng về sự phù hợp với Tspec. Các gói có kích thước m khi kiểm tra

đều được coi là có kích thước bằng m

- Kích thước gói tối đa M là kích thước lớn nhất của gói tuân theo Tspec. M phải nhỏ

hơn hoặc bằng MTU của liên kết vì các gói sử dụng dịch vụ không được phân đoạn.

Luồng sẽ bị loại bỏ (không được sử dụng dịch vụ yêu cầu) nếu kích thước gói tối đa

yêu cầu lớn hơn M .

c) Đặc điểm dịch vụ được yêu cầu

Luồng có độ trễ đảm bảo có thể xác định thêm bằng đặc điểm dịch vụ được yêu cầu

(Requested Service Specification – Rspec) để yêu cầu mức dịch vụ cụ thể. Rspec có các

tham số sau :

- Tốc độ yêu cầu R, xác định tốc độ mong muốn mà lưu lượng được gửi trong luồng,

nó phải lớn hơn r

- Số hạng vi chỉnh S, xác định sự trênh lệch giữa độ trễ mong muốn và độ trễ thu được

khi gửi ở tốc độ R. Nó cho phép mạng điều chỉnh tốc độ được phân bố để đáp ứng

yêu cầu trễ

d) Đặc điểm đường (Path Characterization)

Để giải thích các chất lượng dịch vụ được cung cấp dọc theo một chặng đường cụ

thể, cơ chế dự trữ tài nguyên cũng thông báo một số đặc tính của đường, chúng bao gồm

- Khả năng cung cấp IntServ: chỉ ra xem có nút nào trên đường không có khả năng

cung cấp dịch vụ tích hợp

- Số chặng IntServ: chỉ ra số nút có khả năng cung cấp dịch vụ tích hợp trên đường

- Băng thông đường sẵn có: chỉ ra băng thông tối thiểu

- Độ trễ đường tối thiểu: chỉ ra độ trễ tối thiểu của một gói, bao gồm trễ truyền, trễ xử

lý nhưng không tính đến trễ hàng đợi.

- MTU của đường: chỉ ra kích thước đơn vị truyền cực đại trên đường

- Các tham số trễ: chỉ ra trễ tích luỹ trên đường truyền của một luồng cụ thể, bao gồm

các số hạng phụ thuộc tốc độ và số hạng phụ thuộc tốc độ D.

e) Dự trữ tài nguyên

Phải dự trữ tài nguyên cho các luồng để có thể cung cấp chất lượng dịch vụ theo yêu

cầu. Điều đó có thể thực hiện thông qua giao thức dự trữ tài nguyên động, qua cấu hình bằng

tay hay qua một giao thức quản lý mạng. Mô hình tích hợp dịch vụ không gắn liền với một

cơ chế cụ thể nào. Tất nhiên, nó xác định tổng quát các lưu lượng và đặc tính đường truyền

thông qua mạng. Việc dự trữ tài nguyên được thực hiện bằng giao thức dự trữ tài nguyên

(Resource ReSerVation Protocol – RSVP)

10


II.1.2. Giao thức RSVP

RSVP là giao thức cụ thể được thiết kế cho được thiết kế để cung cấp việc dự trữ tài

nguyên. Nó được thiết kế cho môi trường dịch vụ tích hợp, nhưng ngoài ra nó còn có thể

dùng với các mô hình dịch vụ khác.

II.1.2.1. Các đặc trưng của RSVP

Môi trường quảng bá (multicast): RSVP được thiết kế làm việc tốt trong môi trường

quảng bá bởi vì các ứng dụng yêu cầu dự trữ tài nguyên là hướng quảng bá (multicast –

oriented), ví dụ như ứng dụng hội nghị. Giao thức cung cấp quá trình truyền thông đơn giản

giữa tậpcác bên gửi và tập các bên nhận, với đường truyền thực sự sử dụng các cây truyền

bá.

Hướng bên nhận (receiver – oriented): để có thể mở rộng đáp ứng môi trường quảng

bá lớn, giao thức yêu cầu bên nhận thực hiện việc dự trữ. Bên nhận yêu cầu dự trữ tài

nguyên dựa trên đặc tính lưu lượng của bên gửi và đặc điểm của đường truyền

Sự không đồng nhất của bên nhận: RSVP hỗ trợ các bên nhận không đồng nhất bằng

cách cho phép mỗi bên nhận thực hiên việc dự trữ riêng của mình, có thể khác nhau, thạm

chí nếu lưu lượng nhận từ cùng một nguồn. Các nút trung gian sẽ tập hợp các yêu cầu dự trữ

Trạng thái mềm (soft state): trạng thái dự trữ phải được các bên làm tươi định kỳ,

nếu không chúng sẽ hết hạn. Điều này làm cho giao thức hoạt động tốt và thích ứng với các

điều kiện mạng và các yêu cầu dự trữ thay đổi .Nó cũng hạn chế yêu cầu cần có cơ chế báo

hiệu tin cậy

Không có cơ chế đi kèm để định đường hay lập lịch cho gói tin, RSVP chỉ là một

giao thức báo hiệu. Nó phụ thuộc vào quá trình định đường IP thông thường để tính đường

dự trữ. Tất nhiên, nó muốn bao gồm yêu cầu về tài nguyên trong quá trình tìm đường nhưng

hiện nay chưa có giao thức tìm đường chuẩn nào trong mạng IP xem xét yếu tố chất lượng

dịch vụ. RSVP cũng không quan tâm đến cách các nút mạng thực hiện yêu cầu dự trữ

RSVP truyền tải và duy trì các tham số điều khiển lưu lượng và chính sách quản trị,

nhưng những tham số này lại trong suốt đối với RSVP. RSVP hoạt động trong suốt qua các

bộ định tuyến không hỗ trợ RSVP

II.1.2.2. Mô hình hoạt động của giao thức RSVP

Quá trình đăng ký được thực hiện theo trình tự sau

- Bên gửi gửi đi thông báo PATH tới các bên nhận để thiết lập trạng thái đường đi tại

các bộ định tuyến trên đường đi

- Sau khi nhận được thông báo PATH, bên nhận gửi lại bên gửi thông báo RESV chứa

yêu cầu đăng ký (theo đúng đường mà thông báo PATH đi qua) để thiết lập trạng

thái đăng ký tại các bộ định tuyến trên đường đi

11


a) Thiết lập trạng thái đường đi

Mỗi nút gửi truyền các thông báo RSVP PATH xuôi dòng thưo các lộ trình phát

đơn/quảng bá nhóm được cung cấp bởi các giao thức dẫn đường, theo lộ trình của dòng dữ

liệu. Thông báo PATH lưu “ trạng thái đường đi “ tại mỗi bộ định tuyến trên đường đi.

Trạng thái đường đi bao gồm các thành phần :

- PHOP (Previous Hop) : địa chỉ IP phát đơn của nút trước đó, dùng để dẫn đường cho

thông báo RESV đi theo chiều ngược lại

- Sender Template : mô tả khuôn dạng gói mà nút sẽ gửi đi

- Sender Tspec : xác định các đặc tả lưu lượng của dòng dữ liệu mà nút gửi sẽ tạo ra.

Sender Tspec dùng để ngăn chặn đăng ký thừa

- AdSpec : mang dữ liệu OPWA (One Pass With Advertisement). Thông tin này được

chuyển tới module điều khiển lưu lượng tại mỗi nút, và được trả về giá trị cập nhật

rồi được chuyển tiếp xuống dưới trong thông báo PATH. Các thông tin này được bên

nhận sử dụng để ước lượng khả năng phục vụ của mạng từ đó chọn lựa dịch vụ và

xác định các tham số đăng ký cho phù hợp .

Các thông tin chính bao gồm :

Tổng độ trễ đường đi tối thiểu (không tính trễ hàng đợi). Trong trường hợp dịch

vụ đảm bảo, bên nhận cộng thêm giá trị này vào độ trễ hàng đợi để có độ trễ tổng

cộng

Dải thông tối thiểu trên đường đi : dải thông của liên kết hẹp nhất

Một bit cờ : ban đầu được xoá và được đặt khi gặp một bộ định tuyến không hỗ

trợ RSVP

12

Nút gửi

Nút nhận Nút nhận

Bộ định tuyến


PATH (1)

Ressv (2) Ressv (2)

Hình 4. Qui trình đặt chỗ


PATHMTU : kích thước gói lớn nhất được chấp nhận (giá trị nhỏ nhất trong số

MTU của các liên kết trên đường đi)

Các break bit cho từng dịch vụ : ban đầu được xoá và được đặt khi gặp một bộ

định tuyến không hỗ trợ dịch vụ tương ứng. Ví dụ, có một số bộ định tuyến chỉ

hỗ trợ dịch vụ Tải được Điều khiển nhưng không hỗ trợ dịch vụ Đảm bảo .

Giá trị tổng hợp các số hạng lỗi C và D.

Mỗi nút trên đường đi nhận thông báo PATH và xử lý để tạo lập trạng thái đường đi.

Cuối cùng nó tới ứng dụng trên các nút nhận, tuy nhiên nó không quay trở về nút nhận trong

cùng tiến trình với nút gửi .

b) Thiết lập trạng thái đăng ký

Mỗi nút nhận khi nhận được thông báo PATH sẽ sử dụng các tham số (ví dụ, trong

trường hợp Dịch vụ Đảm bảo thì các tham số là : r, b, p, m từ Sender Tspec ,độ trễ đường đi

nhỏ nhất, PATHMTU, Ctot, Dtot, dải thông tối thiểu từ Adspec) để tạo lập thông báo RESV

chứa yêu cầu đăng ký chuyển tới các nút gửi.

Thông báo RESV bao gồm :

Yêu cầu kiểu đăng ký (WF, SE hay FF)

RSVP có một số tuỳ chọn đăng ký, gọi là kiểu đăng ký nhằm phục vụ các loại

ứng dụng khác nhau, sử dụng tối ưu tài nguyên đăng ký. Các kiểu đăng ký được xác

định dựa trên hai yếu tố : có lựa chọn nút gửi hay không và dùng chung đăng ký hay

dùng riêng. Có 3 kiểu đăng ký như sau :

Lựa chọn bên gửi Đăng ký

Phân biệt Dùng chung

Có Fixed – Filter(FF) Shared – Explicit(SE)

Không (không định nghĩa) Wilcard – Filter (WF)

o Wildcard – Filter (WF) : Tạo một đăng ký dùng chung cho các luồng từ tất cả các

nút gửi. Có thể hình dung như là phần tài nguyên được đăng ký tạo thành một

“ống “ dùng chung với “ kích thước “ là yêu cầu tài nguyên lớn nhất từ tất cả các

nút nhận, không phụ thuộc vào số lượng nút gửi sử dụng nó

o Shared – Explicit (SE) : Tạo một đăng ký dùng chung cho các luồng từ một số

nút gửi được lựa chọn

o Fixed – Filter (FF) : Tạo một đăng ký cho luồng dữ liệu từ mỗi nút gửi, không

chia sẻ với luồng dữ liệu của các nút gửi khác trong cùng phiên

Kiểu đăng ký tài nguyên dùng chung (WF, SE) phù hợp với các ứng dụng quảng bá

nhóm trong đó nhiều nguồn dữ liệu không truyền đồng thời. Ví dụ, với các ứng dụng

hội nghị audio, tại mỗi thời điểm chỉ có một số hữu hạn người cùng nói, nghĩa là chỉ

có một số hữu hạn nút gửi đồng thời. Do đó mỗi nút nhận có thể yêu cầu kiểu WF

13


hay SE với dải thông gấp đôi cho mỗi nút gửi. Còn kiểu FF, tạo những đăng ký riêng

biệt cho các luồng từ những nút gửi khác nhau, phù hợp với các ứng dụng video.

Filter Spec (vắng mặt nếu kiểu đăng ký là WF), dùng để nhận dạng nút gửi, khuông dạng

của Filter Spec thường tương tự như khuôn dạng của Sender Template trong thông báo

PATH

Flow Spec : gồm có Tspec và Rspec (Rspec vắng mặt nếu yêu cầu dịch vụ Tải được điều

khiển). Tspec thường bằng Sender Tspec, ngoại trừ tham số M được đặt bằng PATHMTU

lấy từ Adspec

Một số đối tượng tuỳ chọn, như đối tượng RESVCONF chỉ ra rằng nút nhận cần xác

nhận đăng ký, đối tượng policy, chứa thông tin về chính sách quản trị. ..

Thông báo RESV đi chính xác theo chiều ngược lại lộ trình mà dữ liệu đã đi đến. Nó

tạo lập và duy trì một trạng thái đăng ký tại các nút dọc theo lộ trình. Cuối cùng thông báo

RESV đến các nút gửi, do đó các nút này có thể thiết lập các tham số điều khiển lưu lượng

cho phù hợp với chặng đầu tiên. Địa chỉ IP đích của thông báo RESV là địa chỉ phát đơn của

nút gửi trên, lấy từ trạng thái đường đi. Địa chỉ IP nguồn là địa chỉ của nút gửi thông báo

c) Trộn các yêu cầu đăng ký

Thông báo RESV được chuyển tới nút trên mang theo đặc tả luồng lớn nhất trong số

các đặc tả luồng yêu cầu bởi nút dưới. Như thế gọi là các đặc tả luồng được trộn .

Thông thường đặc tả luồng là vector đa chiều, nó có thể chứa cả hai thành phần

Tspec và Rspec, và bản thân mỗi thành phần lại là những vector đa chiều .Do đó có nhiều

trường hợp không thế so sánh hai đặc tả luồng. Chẳng hạn, nếu một cái yêu cầu dải thông

cao hơn và cái kia yêu cầu độ trễ nhỏ hơn. Khi đó thay vì lấy ra cái lớn hơn, thủ tục trộn phải

cho ra đặc tả luồng thứ ba mà các giá trị bằng giá trị nhỏ nhất của cận trên (Least Upper

Bound – LUB) và lớn nhất của cận dưới (Greatest Lower Bound – GLB). Trong trường hợp

trên, đặc tả luồng thứ ba phải có yêu cầu dải thông của đặc tả luồng thứ nhất và độ trễ của

đặc tả luồng thứ hai.

14

H

H

H

H

R RNút gửi

Nút nhận

Nút nhận

Nút nhận

R : bộ định tuyếnH : Hệ thống cuối

Hình 5. Trộn các yêu cầu đặt chỗ


Luật trộn các đặc tả tuỳ thuộc vào kiểu đăng ký của chúng. Các đặc tả luồng chỉ được

trộn khi chúng có cùng kiểu đăng ký và cùng đến một giao diện của bộ định tuyến (trong

trường hợp giao diện này nối vào một mạng LAN, nó có thể nhaanj được nhiều đặc tả luồng

từ nhiều nút nhận). Các đặc tả luồng cũng chỉ được trộn khi chúng thuộc cùng một phiên.

Hình 6 minh hoạ cơ chế trộn các đặc tả luồng với các kiểu FF, SE và WF với giả sử các đặc

tả luồng là các vector một chiều và được so sánh bằng độ đo B.

Mỗi khi trạng thái đăng ký hiện tại thay đổi, bộ định tuyến sẽ tạo ra thông báo RESV

mới và chuyển tiếp lên trên ngay tức thì (không cần đợi đến hết khoảng thời gian làm tươi).

Cơ chế trộn yêu cầu đăng ký là một ưu điểm cơ bản của RSVP, khả năng mở rộng,

với một số lượng lớn người sử dụng tham gia vào một nhóm quảng bá nhóm, lưu lượng trên

mạng tăng lên không nhiều .

d) Duy trì trạng thái đăng ký

RSVP theo cách tiếp cận “ trạng thái mềm “để quản lý trạng thái đăng ký trên các bộ

định tuyến và các trạm đầu cuối .Các trạng thái RSVP được tạo lập và định kỳ làm tươi bởi

các thông báo PATH và RESV. Trạng thái bị xoá nếu sau khoảng thời gian nhất định mà

không được làm tươi. Trạng thái cũng có thể bị xoá bỏ bằng thông báo huỷ bỏ. Sau mỗi

khoảng thời gian làm tươi ( refresh timeout) hoặc sau khi trạng thái thay đổi, tiến trình

RSVP quét trạng thái của nó để tạo và đẩy các thông báo PATH và RESV tới các nút tiếp

theo.

Khi đường đi thay đổi, thông báo PATH tiếp theo sẽ khởi tạo trạng thái đường đi trên

lộ trình mới và các thông báo RESV sau đó sẽ thiết lập trạng thái đăng ký trên đó

RSVP gửi thông báo RSVP dưới dạng các gói IP với độ tin cậy không đảm bảo. Vì

thế cần phải kiểm soát được tình huống các thông báo làm tươi bị mất. Nếu như thời hạn xoá

bỏ trạng thái đăng ký bằng K lần thời hạn làm tươi thì RSVP có thể “ đối phó “ với khả năng

K-1 thông báo làm tươi bị mất mà không làm huỷ bỏ trạng thái đăng ký. Mặt khác, cơ chế

kiểm soát lưu lượng của mạng cần cung cấp cố định một dải thông tối thiểu cho các thông

báo RSVP để tránh mất thông báo do tắc nghẽn.

Trạng thái duy trì bởi RSVP là động, để thay đổi một tập các nút gửi Si hoặc thay đổi

yêu cầu chất lượng dịch vụ, nút chỉ cần gửi đi các thông báo PATH/RESV sửa đổi. Kết quả

là những trạng thái của các nút trên đường đi sẽ được điều chỉnh, trạng thái cũ bị huỷ bỏ.

Khi trạng thái nhận được khác với trạng thái đã lưu trước đó, trạng thái đang lưu sẽ

được cập nhật. Nếu việc cập nhật này làm thay đổi trạng thái được chuyển tiếp trong các

thông báo làm tươi, những thông báo làm tươi sẽ được sản sinh và chuyển tiếp ngay tức thì.

Tuy nhiên ,sự lan truyền này sẽ dừng khi nó tới một điểm trộn mà sau đó không gây ra thay

đổi nào. Điều này làm tối thiểu hoá lưu lượng trên mạng do sự thay đổi trạng thái gây ra và

làm cho RSVP có thể đáp ứng được với nhóm quảng bá nhóm lớn.

15


e) Huỷ bỏ trạng thái

Khi cần huỷ bỏ trạng thái đường đi hoặc trạng thái đăng ký, tiến trình RSVP gửi đi

thông báo huỷ bỏ. Mặc dù trạng thái sẽ bị huỷ bỏ khi hết thời hạn cleanup timeout nhưng

các nút đầu cuối nên gửi các thông báo huỷ bỏ ngay khi ứng dụng kết thúc .

Có hai loại thông báo huỷ bỏ là PATHTEAR và RESVTEAR. Thông báo

PATHTEAR đi xuôi dòng xuống tất cả các nút nhận từ nơi nó được khởi tạo và xoá trạng

thái đường đi cũng như trạng thái đăng ký kèm theo tại các nút trên đường. Thông báo

RESVTEAR được chuyển ngược lên các nút gửi từ nơi nó được khởi tạo và xoá các trạng

thái đăng ký. Có thể hiểu PATHTEAR và RESVTEAR có ý nghĩa ngược lại so với các

thông báo PATH và RESV .

f) Hoạt động qua các bộ định tuyến không hỗ trợ RSVP

RSVP phải hoạt động được khi hai bộ định tuyến RSVP nối với nhau bởi một “đám

mây “ các bộ định tuyến không hỗ trợ RSVP .

RSVP được thiết kế để hoạt động chính xác qua “đám mây “ các bộ định tuyến

không hỗ trợ RSVP. Dĩ nhiên là một đám mây không hỗ trợ RSVP thì không thể thực hiện

đăng ký tài nguyên, nhưng nếu có đủ tài nguyên, nó vẫn có thể đảm bảo độ trễ gói theo yêu

cầu. Các bộ định tuyến RSVP và không RSVP đều chuyển tiếp thông báo PATH tới địa chỉ

đích dùng bảng dẫn đường phát đơn/quảng bá nhóm cục bộ của chúng. Do đó, việc dẫn

đường của thông báo PATH sẽ không bị ảnh hưởng bởi các bộ định tuyến không RSVP trên

đường đi. Khi thông báo PATH đi qua đám mây không RSVP, nó mang theo tới nút có hỗ

trợ RSVP kế tiếp địa chỉ IP của bộ định tuyến RSVP cuối cùng trước đó, trước khi vào đám

mây. Thông báo RESV sẽ được chuyển tiếp đúng đường tới bộ định tuyến RSVP ngay bên

trên đường đi lên nút nguồn

g) Bảo mật

Với khả năng cho phép đăng ký trước tài nguyên, RSVP đã tạo ra các loại hình tấn

công mới như ăn cắp dịch vụ, treo tài nguyên dẫn đến dịch vụ bị từ chối. RSVP ngăn chặn

những tấn công như trên bằng cơ chế xác thực qua từng chặng sử dụng hàm băm mã hoá,

thông qua đối tượng INTEGRITY(tuỳ chọn) trong các thông báo RSVP

16

Nút gửi Nút nhận

“Đám mây “ các bộ định tuyến không hỗ trợ RSVP

R – RSVP R – RSVP

Hình 6 . Hoạt động của RSVP qua các bộ định tuyến không hỗ trợ RSVP


II.1.2.3. Một số vấn đề của giao thức RSVP

Với khả năng bảo mật hạn chế, RSVP chưa thực sự an toàn trước các loại hình phá

hoại như ăn cắp tài nguyên hoặc treo tài nguyên. RSVP sử dụng lược đồ mã hoá MD5 để xác

thực thông báo. Tuy nhiên cơ chế này đòi hỏi một hệ thống phân bố khoá. Và trước khi một

hệ thống phân bố khoá như vậy được sử dụng rộng rãi, việc phân bố khoá phải được thực

hiện thủ công

Các vấn đề về chính sách quản trị và quản lý chính sách cũng chưa được mô tả đầy

đủ. RSVP cung cấp các cơ chế để thực hiện chính sách, nhưng nó chưa định nghĩa một chính

sách nào cụ thể

Cuối cùng là vấn đề mở rộng, khi sử dụng RSVP trên qui mô lớn sẽ nảy sinh các vấn

đề sau : lưu lượng điều khiển trên mạng quá lớn ,các trạng thái đăng ký cũng rất lớn đòi hỏi

tài nguyên rất lớn và phải có cơ chế điều khiển lưu lượng cho nhiều đăng ký

II.1.3. Kiểm soát chấp nhận

Mô hình IntServ dựa vào việc kiểm soát chấp nhận để giới hạn thông tin được nhận

vào mạng, do đó có thể có đủ tài nguyên để cung cấp chẩt lượng dịch vụ cho các luồng đang

tồn tại. Các yêu cầu dự trữ tài nguyên được các nút xử lý để xem xét một yêu cầu mới có thể

được chấp nhận hay không mà không ảnh hưởng đến các luồng đang tồn tại. Module kiểm

soát chấp nhận tại các bộ định tuyến ra quyết định dựa vào các thuật toán đo tải cục bộ của

mình tại thời điểm ra quyết định, phương pháp này được gọi là kiểm soát chấp nhận dựa trên

phép đo (measurement – based admission control). Cách tiếp cận truyền thống được đề nghị

là các router cần ghi nhớ các thông số dịch vụ của các yêu cầu trước đó và tính toán dựa

trên giới hạn xấu nhất của mỗi dịch vụ Cách tiếp cận này an toàn nhưng hiệu quả không cao

do rất hiếm khi các dịch vụ đồng thời đạt đến giới hạn xấu nhất. Cách tiếp cận được đề nghị

gần đây có vẻ giúp sử dụng đường tryền hiệu quả hơn là router đánh giá sự sử dụng đường

truyền thực tế của các luồng packet đang tồn tại và sử dụng thông tin này làm cơ sở cho việc

chấp nhận hay không yêu cầu dịch vụ của luồng mới. Cách tiếp cận này có rủi ro lớn hơn

nhưng làm tăng hiệu quả sử dụng băng thông

II.1.4. Phân loại gói tin

Các gói tin đi đến trước khi được lập lịch sẽ được phân thành lớp nhờ bộ phân lớp

gói Các gói thuộc cùng một lớp sẽ nhận được cùng một cách đối xử như nhau từ bộ lập lịch

gói : chúng cùng được đưa vào một hàng đợi với mức chất lượng dịch vụ nào đó .

Việc phân lớp này dựa vào một số dữ liệu trong gói (ví dụ trong phần đầu của đơn vị

thông tin tầng mạng hay tầng giao vận. Trong IP V4 có thể dùng địa chỉ IP nguồn và đích

cũng như số Port tầng giao vận. Trong IP V6, có thể dùng địa chỉ IP nguồn và nhãn luồng).

Một lớp có thể tương ứng với một phạm vi rộng các luồng, ví dụ tất cả các luồng

video, hoặc chỉ một luồng đơn lẻ.

17


Việc phân lớp chỉ có ý nghĩa cục bộ : một gói có thể thuộc các lớp khác nhau tại các

bộ định tuyến khác nhau dọc theo đường đi. Ví dụ, các bộ định tuyến trên mạng trục

(backbone) có thể gộp nhiều luồng vào một số lớp, còn các bộ định tuyến ở gần đầu cuối,

nơi có rất ít luồng có thể phân mỗi lớp vào một luồng

II.1.5. Lập lịch gói tin

Lập lịch cho gói tin là chức năng nền tảng của hệ thống, là cơ sở để đảm bảo khả

năng cung cấp dịch vụ thời gian thực của phần tử mạng. Lập lịch gói tin dựa trên việc xắp

xếp lại hàng đợi ở đầu ra. Có nhiều cách thực hiện việc này .

Cách đơn giản nhất là sơ đồ ưu tiên trong đó các packet được xắp thứ tự theo mức độ

ưu tiên. Các packet có mức ưu tiên cao nhất sẽ được gửi đi đầu tiên. Nhưng sơ đồ này có thể

dẫn đến các packet có mức ưu tiên thấp được gửi đi quá chậm hoặc thậm chí không được gửi

đi nếu có nhiều packet có mức ưu tiên cao.

Một sơ đồ lập lịch gói khác là cơ chế phục vụ quay vòng (round – robin) hoặc một số

sơ đồ cải biến từ sơ đồ này (tiêu biểu là Weighted Fair Queuing). Nó cho phép các lớp

packet khác nhau chia sẻ một đường truyền chung.

Ngoài ra còn nhiều sơ đồ phức tạp cho phép quản lý hàng đợi tuỳ thuộc vào một số

mục tiêu dịch vụ đối với một số luồng riêng biệt .

II.1.6. Kiến trúc dịch vụ tích hợp

Thông thường trong mạng IP có một số cách tuỳ chọn để cài đặt một chức năng trong

mạng. Với dịch vụ tích hợp cần phải trao đổi thông tin giữa các hệ cuối với các phần tử

mạng (bộ định tuyến hay mạng con). Sự lựa chọn lô gíc cho trường hợp này là sử dụng

giao thức RSVP, nhưng đó không phải là khả năng duy nhất. Có thể dùng một số giao thức

thiết lập khác tương đương về mặt chức năng cũng như thủ tục quản lý để thực hiện việc đó.

Giao thức thường được sử dụng trong dịch vụ tích hợp là RSVP nhưng RSVP và mô hình

IntServ độc lập với nhau .

18

Acct

Auth

Policy

Dữ liệu

RSVP RSVP

Chức năng kiểm soát chính sách

Xử lý đối tượng kiểm soát QoS

Xử lý đối ượng định danh

Xử lý đối tượng kế toán

Chức năng đường dữ liệu Kiểm soát QoS

Hình 7 . Kiến trúc của mô hình dich vụ tích hợp

Bộ định tuyến hoặc mạng con Máy chủ


Hình 7 trình bày một phần của kiến trúc hệ thống dịch vụ tích hợp. Trong đó RSVP

là giao thức duy nhất mang yêu cầu của chức năng chất lượng dịch vụ. Nó được gửi đến các

khối chức năng thực sự cung cấp chất lượng dịch vụ trong bộ định tuyến / mạng con. RSVP

truyền tải các đối tượng nhưng các đối tượng này lại trong suốt đối với RSVP. Hình 10 minh

hoạ mối quan hệ giữa các khối chức năng. Ví dụ chức năng kiểm soát thu nhận sẽkhông chỉ

dùng đối tượng chính sách của RSVP chuyển mà còn dùng các đối tượng dùng để gọi chức

năng chất lượng dịch vụ và thậm chí cả đối tượng định danh và kế toán

Một điểm cần lưu ý là việc yêu cầu và cung cấp chất lượng dịch vụ là khác nhau, hơn

nữa giao thức RSVP không cung cấp chất lượng dịch vụ mà cung cấp dịch vụ truyền thông.

Do đó việc cung cấp dịch vụ tích hợp (và cả dịch vụ DiffServ) là độc lập với RSVP.

Hình 7 mô tả các đối tượng dữ liệu trong tin báo PATH. Như trình bày ở trên trong

RSVP, tin báo PATH được truyền từ bên gửi đến bên nhận và chứa thông tin về lưu lượng

xuất phát từ bên gửi.

Dòng lưu lượng mô tả trong Tspec của bên gửi. Tspec không thay đổi các đặc trưng

của dòng lưu lượng trong quá trình gửi mà chỉ báo hiệu chúng đến tất cả các nút trung gian

trong mạng và đích. Adspec được sinh ra bởi máy chủ gửi hoặc bộ định tuyến đầu tiên trên

đường, nó chứa các tham số tổng quát đặc trưng cho đường đó, xác định bởi việc tính toán

trên từng chặng, cũng như các tham số đặc trưng cho chất lượng dịch vụ cụ thể được phần tử

mạng hỗ trợ. Ví dụ về các tham số tổng quát : kích thước MTU của đường truyền, băng

thông, trễ tối thiểu trên đường. ..

Hình 8 cho thấy bộ mô tả luồng (flow description) trong RSVP. Mô tả luồng bao

gồm hai phần : flow spec và filter spec. Mô tả luồng được gửi trong thông báo RESV, truyền

từ bên nhận đến bên gửi .

Filter spec chỉ làm nhiệm vụ phân biệt các gói một cách logic. Căn cứ vào nhãn của

luồng (trong IP v6) hay địa chỉ đích, cổng đích (trong gói IP v4), việc lựa chọn dòng con

thích hợp với dịch vụ trên được thực hiện.

Flow spec chứa ba phần : kiểu dịch vụ được yêu cầu, các tham số dịch vụ (Rspec) và

các tham số luồng yêu cầu dịch vụ (Tspec).

19

AdSpec TSpec

Hình 8 . Các đối tượng trong tin báo PATH

Lớp dịch vụ

RSpec TSpec Địa chỉ nguồn

FlowSpec Filter Spec

Hình 9 . Các đối tượng trong tin báo RESV

Mô tả luồng


Hình 9 mô tả chi tiết hơn về chức năng đường dữ liệu kiểm soát chất lượng. Thông

tin từ giao thức RSVP được đưa vào các khối chức năng khác nhau trong bộ định tuyến, tại

đó chúng được xử lý để đưa ra quyết định cung cấp chất lượng dịch vụ tương ứng. Bộ phân

loại gói xác định cách xử lý các gói. Bộ lập lịch gói áp dụng các cơ chế xác định với các gói

để cung cấp chất lượng dịch vụ được yêu cầu. Chức năng kiểm soát chính sách và kiểm soát

chấp nhận xác định một luồng cụ thể có được phép yêu cầu một dịch vụ nhất định tại thời

điểm đó hay không (chính sách) và có đủ tài nguyên trong phần tử mạng để hỗ trợ dịch vụ

được yêu cầu (chấp nhận). Kết quả của các hoạt động đó ảnh hưởng đến quyết định của bộ

phân loại gói. Hơn nữa, các thông tin của RSVP cũng ảnh hưởng tới các giải thuật chọn

đường của phần tử mạng (chọn đường có xem xét đến chất lượng dịch vụ).

Sau đây chúng ta xẽ xét hai dịch vụ cụ thể của mô hình IntServ .

II.1.6.1. Dịch vụ tải có kiểm soát

Dịch vụ tải có kiểm soát được áp dụng cho một lớp ứng dụng có đặc tính thời gian

thực nhưng có thể thích nghi với điều kiện mạng không quá tải. Dịch vụ tải có kiểm soát cố

gắng tạo ra điều kiện mạng “không tải “ cho các ứng dụng đó nhưng không cung cấp đảm

bảo dịch vụ. Các dịch vụ này có thể là audio hoặc video

Dịch vụ tải có kiểm soát quan tâm đến hai tham số chất lượng dịch vụ : trễ và mất

gói. Mục tiêu của dịch vụ này là tỷ lệ mất gói và độ trễ trên mạng đạt tối thiểu và xấp xỉ

dịch vụ thông thường khi mạng không quá tải .

20

RSVP

Chọn đường

Kiểm soát chấp nhận

Kiểm soát chính sách

Phân loại gói tin

Lập lịch gói tin

Đối tượng chính sách

TSpec RSpec

TSpec

FilterSpec

Hình 10. Quan hệ giữa thông tin RSVP và việc xử lý gói trong bộ định tuyến


Kiến trúc dịch vụ.

Hình 11 mô tả một phần tử mạng cung cấp dịch vụ tải có kiểm soát, trong đó phần

quan trọng nhất là chức năng xử lý gói. Tại đây, tất cả các luồng gói đều đi qua bộ phân loại

gói trong bộ định tuyến. Nó xác định gói nào thích hợp với dịch vụ này gói nào không. Ở

đầu ra của bộ phân loại gói là thùng thẻ bài. Cơ chế thùng thẻ bài được dùng để xác định gói

nào nhận dịch vụ tải có kiểm soát. Trong thiết kế hình 11 có hai hàng đợi. Hàng đợi trên

được ưu tiên và các các gói tuân theo cơ chế thùng thẻ bài của luồng được đưa vào hàng đợi

ưu tiên cao hơn này. Hàng đợi thấp hơn được dùng chung cho các gói không tuân theo cơ

chế thùng thẻ bài và các gói chỉ nhận được dịch vụ cố gắng tối đa. Hàng đợi ở dưới lại có thể

phân thành hai hàng đợi nhỏ hơn.

Ở đây, có một số vấn đề cần xem xét. Trước hết là cách xử lý lưu lượng không tuân

theo yêu cầu dịch vụ. RFC 2211 đề nghị đối xử với chúng như với lưu lượng cố gắng tối đa.

Do đó trên hình 6, ta thấy phần vượt quá được đưa vào hàng đợi cố gắng tối đa. Tất nhiên

lưu lượng vượt quá không được ảnh hưởng nhiều đến dịch vụ cố gắng tối đa bình thường, ví

dụ nó không được gây ra sự suy giảm chất lượng dịch vụ đáng kết với dịch vụ thông thường.

Vấn đề là khi có nhiều lưu lượng tải được kiểm soát không tuân thủ, chúng có thể làm dịch

vụ thông thường bị dừng lại do bị mất nhiều gói trong hàng đợi. Do đó cần có cơ chế xử lý

lưu lượng vượt quá từ dịch vụ tải có kiểm soát. Một số giải pháp được đề nghị như dùng một

mức hàng đợi ưu tiên khác cho phần lưu lượng này hay dùng cơ chế hàng đợi WFQ hay

CBQ để đảm bảo lưu lượng cố gắng tối đa không bị ảnh hưởng bởi lưu lượng vượt quá .

Vấn đề thứ hai là phân bổ tài nguyên trong hàng đợi ưu tiên cao (lưu lượng tải có

kiểm soát), có nghĩa là cách các luồng tải có kiểm soát chia sẻ hàng đợi này và cách kiểm

soát chấp nhận với các luồng này .

Cơ chế thực hiện dịch vụ tải có kiểm soát

Để gọi dịch vụ tải có kiểm soát cho một luồng, ứng dụng dùng giao thức

SENDER_TSPEC với yêu cầu dịch vụ tải có kiểm soát trong tin báo PATH . RSVP cũng

21

Lập lịch / xử lý góiPhân loại gói

Thùng thẻ bài

Chức năng đường dữ liệu kiểm soát chất lượng


Hình 11 . Dịch vụ tải có kiểm soát


gửi ADSPEC trong tin báo PATH, chứa thông báo rằng dịch vụ này có được cài đặt trên mỗi

chặng của đường hay không, kích thước MTU tối thiểu và các tham số đặc trưng của đường

đi của các gói trong luồng. Các nút trung gian có thể sửa đổi ADSPEC nhưng không thể sửa

đổi SENDER_TSPEC. Khi bên nhận thấy tin báo PATH cho dịch vụ tải có kiểm soát, chúng

chỉ báo dịch vụ có được hỗ trợ hay không bằng cách đặt “ bit gãy “ (break – bit). Bit này

báo cho mọi người biết rằng có ít nhất một nút trên đường không hỗ trợ dịch vụ này.

Một điểm chú ý quan trọng là không có định nghĩa mang tính định lượng chính xác

của dịch vụ tải có kiểm soát. Mỗi phần tử mạng cần quyết định một cách độc lập xem nó có

thể cung cấp dịch vụ này dựa trên mức tải hiện tại của nó cũng như mức độ rủi ro có thể có

(do cung cấp quá mức tổng của Tspec của các luồng tải có kiểm soát).

Khi luồng đã được chấp nhận, chức năng đường dữ liệu bắt đầu làm việc. Chức năng

này quan tâm đến việc xử lý và lập lịch gói. Ở đây chúng ta cần xem xét một khía cạnh trong

đáp ứng của thùng thẻ bài : giả sử luồng đạt đến số gói mà thùng thẻ bài cho phép và sau đó

gửi với tốc độ thẻ ghi trong Tspec. Nếu nút chọn phục vụ luồng với tốc độ thẻ đó thì sẽ có

đống (backlog) “ cố định “ các gói tại hàng đợi của nút đó. Vì vậy RFC 2211 khuyến nghị

nên có cơ chế để cho phép dọn dẹp backlog đó để làm giảm thời gian xắp xếp hàng đợi cho

luồng. Một cách tương tự, như chúng ta đã biết, lưu lượng gửi qua nhiều nút không duy trì

được hình dạng và đặc tính ban đầu của nó, nếu một nut đặt kích thước bộ đệm tối đa bằng

kích thước chùm chỉ ra trong Tspec thì sẽ có mất mát gói (không cần thiết) do lưu lượng

không được định dạng lại tại mỗi nút trong mạng. RFC cũng khuyến nghị dùng sơ đồ phân

bổ bộ đệm mềm dẻo để có thể cung cấp thêm bộ đệm cho các chùm .

Nút xác định sự tương thích của luồng bằng cơ chế thùng thẻ bài (được tham số hoá

trong Tspec). Việc xử lý các gói không tương thích không quá chặt chẽ, nhưng không được

làm giảm dịch vụ cung cấp cho các luồng tải có kiểm soát khác và dịch vụ cố gắng tối đa.

Tất nhiên, một tuỳ chọn trong việc xử lý luồng với lưu lượng không tương thích là làm giảm

dịch vụ của cả luồng (chứ không chỉ cho các gói không tương thích). Một khả năng khác là

định dạng lại luồng để các gói không tương thích đợi đến khi chúng tương thích hoặc đến

một thời hạn xác định nào đó. Một cách xử lý khác là đưa chúng vào hàng đợi cùng với lưu

lượng cố gắng tối đa (hoặc sau lưu lượng đó). Điều đó làm các gói trong luồng bị chuyển

không theo thứ tự và gây trễ cho các giao thức tầng cao hơn

II.1.6.2. Dịch vụ đảm bảo (Guaranteed Service)

Mục tiêu của dịch vụ này là cung cấp là cung cấp độ trễ có giới hạn và đảm bảo việc

truyền tất cả các gói đã được xác định cho ứng dụng cần đến nó. Phần này xem xét các tham

số của dịch vụ đảm bảo, cách sử dụng và cơ chế cung cấp dịch vụ. Phần cơ bản của dịch vụ

đảm bảo là tham số từ tất cả các phần tử mạng trong đường cụ thể phải có khả năng tổ hợp

với nhau một cách đơn giản để dự đoán (giới hạn) chất lượng dịch vụ mà các gói trong luồng

sẽ trải qua

Do quá trình dự trữ là một chiều nên đối với truyền thông hai chiều, phải có hai dự trữ .

22


Mô hình dịch vụ

Vì dịch vụ đảm bảo là định lượng – nó có giới hạn trễ xác định – nên nó cần dựa trên

cả hai mô hình : đáp ứng của nguồn và cách phần tử mạng xử lý luồng. Mục đích của các mô

hình này là giới hạn trễ hàng đợi. Một thành phần khác của trễ đầu cuối đến đầu cuối là trễ

truyền, được kiểm soát bằng các giải thuật định đường dùng khi thiết lập luồng. Các mô hình

được mô tả dưới đây.

Bên trái là mô hình thùng thẻ bài, dùng cho bên nguồn. Có nghĩa là dòng bên nguồn

luôn phải nằm trong giới hạn do thùng thẻ bài qui định. Bên phải là mô hình của một liên kết

trong bộ định tuyến. Nó chỉ ra tài nguyên (bộ đệm và băng thông) mà bộ định tuyến phải

phân bổ cho luồng được đảm bảo. Mô hình được sử dụng là “ mô hình dòng chất lỏng “

(fluid model). Nguồn sinh ra dòng chất lỏng với tốc độ r (là tốc độ thẻ bài được tạo ra)

nhưng đôi khi nó có thể tạo ra luồng có tốc độ nhanh hơn r. Phần vượt quá sẽ được giữ lại ở

nguồn và đưa ra với tốc độ r. Nếu nguồn không phát trong một thời gian, thẻ bài được giữ

đến giới hạn b, bất kỳ luồng nào đến sẽ được truyền ngay lập tức khi còn thẻ bài. Tốc độ

truyền sẽ là p .

Khi dòng dữ liệu đến phần tử mạng, nó được phục vụ với tốc độ R và dùng bộ đệm

kích thước B. Cần có bộ đệm vì tốc độ truyền p có thể lớn hơn nhiều so với R

Kết quả lý thuyết cho thấy trễ của luồng ở mạng có giới hạn b/R (với điều kiện

r<=R) , đó là cơ sở của dịch vụ đảm bảo. Nếu nguồn tạo luồng lớn hơn hay bằng b thì bộ

đêm tại phần tử mạng sữ có b đơn vị luồng và trễ tối đa sẽ là b/R

Phần tử mạng thực tế sẽ không cài đặt mô hình dòng chất lỏng một cách lý tưởng, do

đó sẽ có thêm các trễ khác trong quá trình cài đặt : C và D. Do đó độ trễ toàn bộ sẽ là :

Trễ = b/R + C/R + D (1)

Giới hạn trễ của dịch vụ được tính trên đường bằng phương trình (1)

23

X

Hình 12 . Mô hình dịch vụ đảm bảo

R

Mô hình thùng thẻ bài Mô hình đệm dòng chất lỏng

r thẻ bài /s

B

p

b


II.1.7. Các vấn đề với mô hình dịch vụ tích hợp

Mô hình IntServ đề xuất một mô hình mới về cơ bản cho mạng IP. Nó khác với mô

hình truyền thống và đưa ra các dịch vụ mới như dịch vụ đảm bảo và dịch vụ tải có kiểm

soát. Nó đòi hỏi việc dự trữ tài nguyên một cách rõ ràng, kiểm soát thu nhận, phân loại và

lập lịch gói tin. Nó chỉ ra cách xác định các yêu cầu về lưu lượng và chất lượng dịch vụ .

Tuy nhiên, mô hình này còn có một số vấn đề cần xem xét khi áp dụng cho các mạng

trục (backbone) lớn. Đó là các vấn đề :

Số lượng các luồng đơn trong mạng trục có thể rất lớn, duy trì trạng thái của chúng đòi

hỏi nhiều dung lượng dự trữ .

Số lượng tin báo điều khiển cho việc dự trữ tài nguyên cho một lượng lớn các luồng sẽ rất

lớn và đòi hỏi nhiều năng lực xử lý

Việc phân loại gói dựa trên header của gói có thể tốn kém trên đường truyền tốc độ cao

Vấn đề an ninh cần được giải quyết để đảm bảo rằng các nguồn không có quyền không

đựơc thực hiện việc dự trữ giả mạo

Vấn đề chính sách cần giải quyết để xác định các bên có quyền thực hiện dự trữ

Từ các vấn đề trên, người ta rút ra kết luận IntServ là mô hình thích hợp cho mạng

nhỏ, trong đó chỉ có ít luồng và vấn đề an toàn và chính sách có thể quản lý một cách dễ

dàng. Cũng có thể triển khai các IntServ trong các mạng lớn (chẳng hạn mạng của các nhà

cung cấp dịch vụ) với một số hạn chế các luồng. Ngoài phạm vi đó, các mạng trục lớn cần

những cớ chế khả dụng hơn để phân biệt lưu lượng và cung cấp các dịch vụ khác nhau cho

chúng. DiffServ là một cơ chế như vậy .

24


II.2. Mô hình dịch vụ phân biệt Yêu cầu đặt ra với các nhà cung cấp dịch vụ mạng là cần có các cơ chế khả dụng và

thực tế để cung cấp các mức dịch vụ khác nhau cho khách hàng xuất phát từ những mối quan

tâm mang tính thương mại. Ngoài ra, các doanh nghiệp sẽ không đưa các số liệu quan trọng

của họ lên mạng nếu không có các cơ chế đảm bảo dịch vụ. Sự phát triển của các ứng dụng

như thoại trên IP (VOIP) và mạng riêng ảo (VPN) gắn liền với khả năng của hạ tầng mạng

trong việc cung cấp các loại dịch vụ phân biệt cho các ứng dụng như vậy.

II.2.1. Các đặc điểm chính của mô hình DiffServ

Do những vấn đề tồn tại của mô hình IntServ như đã trình bày ở trên, mô hình

DiffServ đã được nghiên cứu nhằm cung cấp một cơ chế đơn giản khả dụng hơn cho việc

phân biệt các dịch vụ. Những đặc điểm chính của mô hình này như sau:

Mức độ phân biệt thô hơn

Các bộ định tuyến trục chính chuyển một số lượng lớn các luồng đơn. Việc duy trì trạng

thái dự trữ cho từng luồng là rất khó khăn vì kích thước mạng tăng rất nhanh. Vì vậy,

trong mô hình DiffServ, lưu lượng không được phân biệt theo luồng, thay vào đó, có một

số nhỏ các lớp đã được định nghĩa trước, cung cấp các dịch vụ khác dựa trên độ trễ và

mất mát thông tin.

Không phân loại gói trong mạng

RSVP chỉ ra rằng, mỗi bộ định tuyến đều thực hiện chức năng phân loại gói nhằm cung

cấp các mức dịch vụ khác nhau, do đó cần kiểm tra nhiều trường trong phần đầu gói (ví

dụ với IP v4, cần kiểm tra địa chỉ IP nguồn và đích, địch danh giao thức, cổng nguồn và

đích). Thao tác này rất tốn kém, vì vậy trong mô hình DiffServ việc phân loại được thực

hiện ở biên của mạng, nơi có ít gói phải xử lý hơn. Các bộ định tuyến ở biên phân loại và

đánh dấu các gói tin một cách tương ứng. Các bộ định tuyến ở bên trong chỉ xử lý các

gói theo dấu của chúng. Như vậy, các bộ định tuyến bên trong không làm việc với từng

luồng đơn mà chỉ làm việc với các lớp tập hợp. Điều này làm cho giải pháp khả dụng

hơn .

Các mô hình cung cấp khác nhau

RSVP điều khiển việc dự trữ tài nguyên động. Điều này có thể tạo ra nhiều gói tin kiểm

soát và đòi hỏi kiểm soát thu nhận động ở mỗi bộ định tuyến. Mô hình DiffServ đưa việc

kiểm soát thu nhận ra biên của mạng. Hơn nữa, nó không yêu cầu việc dự trữ động. Thay

vào đó, nó sử dụng việc cung cấp tĩnh, dài hạn để thoả thuận dịch vụ với người sử dụng

mạng, mà lưu lượng của họ có thể được kiểm soát ở điểm vào mạng. Cũng có thể dùng

công nghệ kiểm soát lưu lượng để định đường các gói từ các nguồn nhất định theo các

đường xác định trước để tránh các điểm tắc nghẽn trong mạng (mà gói có thể đi qua nếu

dùng các giao thức định đường không quan tâm đến chất lượng dịch vụ thông thường)

25


Không có đảm bảo dịch vụ tuyệt đối

Dịch vụ trễ có đảm bảo trong mô hình IntServ cung cấp giới hạn chặt chẽ về độ trễ tối đa

mà các gói có thể trải qua. Nó thực hiện được điều đó nhờ dự trữ tài nguyên trên đường

truyền. Trái lại, DiffServ không cung cấp sự đảm bảo chặt chẽ trừ phi có một luồng tĩnh

được cung cấp đặc biệt cho luồng cụ thề. Trong mô hình này, bộ định tuyến bên trong

không phân biệt các luồng đơn mà làm việc với tập hợp luồng, do đó nó không thể đối

xử một cách ưu tiên đối với một luồng cụ thể.

Mục tiêu của DiffServ là theo dõi lưu lượng đi vào mạng ở nút vào và kiểm tra tính

tương thích với một số profile dịch vụ định trước. Dựa trên đó, các gói có thể được đánh dấu

là “trong“ (thoả mãn) hay “ngoài“ (không thoả mãn) các profile của chúng. Bên trong mạng,

bộ định tuyến sẽ ưu tiên loại bỏ các gói được gán nhãn “ngoài”.

Bên cạnh ưu tiên loại bỏ, có các thông tin trong phần đầu gói cho biết kiểu dịch vụ

mong muốn của gói. Ví dụ, dịch vụ hạng nhất (premium service) là tương đương với CBR.

Tương tự dịch vụ đảm bảo có đáp ứng chùm và được cung cấp dung lượng mong muốn.

II.2.2. Kiến trúc dịch vụ phân biệt

Ý tưởng của dịch vụ phân biệt khá đơn giản: một luồng một chiều đi vào mạng qua

bộ định tuyến biên đầu vào, ở đó nó được định dạng và gửi đi bằng đáp ứng theo chặng (Per

Hop Behaviour – PHB), theo đó dịch vụ tương ứng được cung cấp cho luồng. Tại các bộ

định tuyến tiếp theo, PHB được áp dụng cho luồng cho đến khi nó đến bộ định tuyến biên

đầu ra, ở đó luồng có thể được định dạng lại trước khi gửi đến máy chủ hoặc một miền dịch

vụ phân biệt khác .

Một vùng dịch vụ phân biệt là một mạng DiffServ. Lối vào của vùng này được gọi

là nút vào (ingress node), lối ra được gọi là nút ra (egress node), các nút này còn được gọi là

nút biên. Một miền DS bao gồm một hoặc nhiều vùng DiffServ, mỗi vùng gồm nhiều nút

trong (interior) và ít nhất hai nút biên (border) mà lưu lượng đi vào và đi ra khỏi vùng. Một

nút biên là một router hay một máy tính thực hiện phân loại packet đến để chuyển tiếp trong

miền DS. Các packet có thể được phân loại tại máy tính gửi hay tại nút biên của mạng DS.

Cấu trúc của một nút cung cấp dịch vụ phân biệt có thể khác nhau căn cứ vào vị trí

của nó ở trong mạng (ở biên mạng hay ở trong mạng) và dựa vào sự lựa chọn của người

quản trị mạng khi cài đặt thoả thuần mức dịch vụ và chính sách .

26

Phân loại gói Đo

Đánh dấu gói

Đinh dạng hoặc loại bỏ gói

Cơ chế PHB

Định dạng lưu lượng

Nút DS

Hình 13 . Cấu trúc nút dịch vụ phân biệt


Nút ở biên có nói chung có nhiều chức năng hơn nút bên trong và có thể mở rộng các

dịch vụ như đánh dấu, định dạng gói cho các máy chủ hay miền không có khả năng tự cung

cấp các dịch vụ đó. Nút bên trong có thể giả thiết rằng lưu lượng đã đi qua các nút biên hỗ

trợ dịch vụ phân biệt và do vậy đã được đánh dấu và điều chỉnh chính xác. Các chức năng

này có thể được bỏ qua ở các nút bên trong .

Thoả thuận mức dịch vụ (Service Level Agreement – SLA) là một khái niệm quan

trọng trong dịch vụ phân biệt. SLA xác định một miền dịch vụ phân biệt xử lý các gói. SLA

thường chứa thoả thuận điều kiện lưu lượng (Traffic Conditioning Agreement – TCA), trong

đó mô tả sự phân lớp của luồng, cách đánh dấu và bỏ dấu đối với các gói trong luồng, các

tham số thùng thẻ bài và thoả thuận về cách xử lý các gói ngoài profile (nghĩa là không đáp

ứng một số đặc tính đã thoả thuận). Chức năng này được thực hiện trong một số thiết bị

logic như trong hình 13 .

Profile lưu lượng xác định một số tính chất của luồng với mức dịch vụ nhất định. Đó

là các đặc tính hay thiết bị cho phép bộ định tuyến xác định một cách rõ ràng một gói là

trong hay ngoài profile. Hơn nữa trên cơ sở của SLA/TCA hay trên cơ sở của chính sách

miền, các gói ngoài profile có thể được đối xử khác với các gói trong profile.

Thiết bị đầu tiên chúng ta xem xét trong cấu trúc nút là thiết bị phân loại gói (packet

classifier). Thiết bị này dùng để chọn các luồng nhận mức dịch vụ nhất định. Có hai loại

thiết bị phân loại gói : một kiểu dựa trên việc chỉ sử dụng trường DS trong phần đầu gói tin

IP. Kiểu này gọi là thiết bị phân loại tập hợp đáp ứng (behaviour aggregate – BA). Ưu điểm

của kiểu phân loại này là tính đơn giản và chỉ có một số hữu hạn các trạng thái cần được bộ

định tuyến duy trì. Kiểu thiết bị khác gọi là thiết bị phân loại nhiều trường (multi – field –

MF) và nó có thể dùng nhiều nhiều trường trong phần đầu gói để xác định xem gói có thuộc

luồng hay không. Ưu điểm của kiều phân loại này là các gói thuộc về các luồng cùng đến

một giao diện nhưng có SLA khác nhau được xác định và phân biệt. Nhược điểm của kiểu

phân loại này là thông tin trạng thái có thể rất lớn .

Trên hình 13, một số thiết bị logic tập hợp với nhau tạo nên bộ điều chỉnh lưu lượng

(traffic conditioner). Bộ điều chỉnh lưu lượng hữu ích nhất khi sử dụng tại các bộ định tuyến

biên đầu vào hay đầu ra của mạng dịch vụ phân biệt. Tất nhiên chúng có thể có ở nguồn

thông tin hoặc ở bộ định tuyên bên trong mạng. Trong một nút hay một giao diện cụ thể, một

số (hay tất cả) chức năng mô tả trê hình có thể không tồn tại.

Thiết bị logic tiếp theo là thiết bị đo (meter), dùng để theo dõi luồng xác định bởi

thiết bị phân loại gói. Nó có chứa cơ chế logic như thùng thẻ bài và có khả năng xác định

xem gói tin trong hay ngoài profile. Tuỳ theo SLA và chính sách của mạng, thông tin từ thiết

bị đo có thể được thiết bịđánh dấu và định dạng / loại bỏ gói sử dụng .

Thiết bị đánh dấu gói (packet marker) cho phép các gói được xử lý theo SLA/TCA.

Các vấn đề được nêu ra trong SLA như luồng nào nhận dịch vụ nào, cách xử lý các gói

ngoài profile được bộ định tuyến biên thực hiện bằng cách đánh dấu trường DS với các giá

trị cụ thể. Các giá trị của trường này và ý nghĩa của chúng đã được trình bày ở phần trên.

27


Thiết bị định dạng (shaper) đảm bảo luồng tuân thủ chính xác các tham số đã cho

trong profile lưu lượng nhất định. Nó có thể làm một số gói bị trễ. Nếu dòng gói thực sự rất

khác so với profile lưu lượng, nó có thể gây ra loại bỏ gói vì thiết bị địng dạng không có bộ

đệm vô hạn (hoặc rất lớn)

Thiết bị loại bỏ (dropper) loại bỏ các gói khỏi luồng để đảm bảo sự tương thích với

profile lưu lượng. SLA/TCA hay chính sách miền xác định thiết bị loại bỏ áp dụng cho tất cả

hay chỉ một phần của luồng (chẳng hạn các gói ngoài profile) hay tất cả các luồng. Thiết bị

này có thể dùng thông tin từ thiết bị phân loại, đo và đánh dấu để ra quyết định loại bỏ gói.

II.2.3. Định nghĩa dịch vụ

Có một số định nghĩa khác nhau cho mạng dịch vụ phân biệt. Ta sẽ xem xét các

PHB cơ bản, được thiết kế để tương thích với việc sử dụng trường IP Precedence (trước kia

là một phần của trường TOS). Ta cũng mô tả PHB chuyển tiếp nhanh

(Expedited Forwaring – EF) và PHB chuyển tiếp có đảm bảo (Assured Forwarding–AF)

II.2.3.1. Trường DS và các PHB cơ bản

Byte DS là định nghĩa lại của byte TOS trong phần đầu IP v4 và lớp octet lưu lượng

trong phần đầu IP v6. Byte này được chia thành hai trường : một mã (codepoint) DS 6 bit và

một trường (hiện không dùng) 2 bit. Mối quan hệ giữa mã và PHB cài đặt trong nút và mạng

là cấu hình được. Để duy trì sự tương thích ngược với trường IP Precedence (3 bit) hiện

đang sử dụng, một tập mã được định nghĩa, gọi là mã chọn lớp (Class Selector), được ánh xạ

với tập chuẩn các đáp ứng tối thiểu tương thích với các đáp ứng IP Precedence đang sử

dụng.

Cấu trúc trường DS :

PHB cơ bản được các nút dịch vụ phân biệt hỗ trợ gọi là PHB mặc định và là đáp

ứng truyền cố gắng tối đa bình thường của IP. PHB này chịu sự hạn chế tài nguyên của nhà

quản trị mạng và các gói được truyền khi nút mạng không phải phục vụ các lớp dịch vụ

khác. Mã chọn PHB mặc định là ‘000000’ (nhị phân). Các mã khác có thể ánh xạ đến PHB

này và các mã chưa định nghĩa có thể chọn PHB này là cách xử lý mặc định chung. PHB

mặc định tương thích với cách các gói tin có cùng giá trị trường TOS được xử lý hiện nay.

28

2 3

DSCP

0 1 7 5 6 4

CU


Bảng 1 : Bảng ánh xạ giữa DSCP và PHB

Có 8 mã chọn lớp, trong đó có một mã chọn đáp ứng mặc định. Các PHB do 7 mã

còn lại chọn phải thoả mãn các yêu cầu sau : các mã chọn lớp phải có trật tự theo giá trị của

chúng. Qui luật chung cho các PHB chọn lớp là dưới điều kiện tải tương đương, PHB gắn

với mã giá trị cao hơn phải có đáp ứng tốt hơn so với PHB gắn với mã giá trị thấp hơn. Để

thoả mãn yêu cầu tối thiểu, phải có ít nhất hai đáp ứng phân biệt rõ ràng .Một đáp ứng phải

ưu tiên cho các gói mang mã DS ‘ 11x000’ so với các gói nhận PHB mặc định để tương

thích với các lớp IP Precedence ‘111’và ‘110’ đang dùng cho lưu lượng định đường. PHB

chọn lớp cung cấp cơ sở cho một tập các PHB chuẩn được các dịch vụ phân biệt cung cấp .

64 mã dự trữ được chia thành 3 phần.

- ‘xxxxx0’ : dùng cho các PHB chuẩn, có 32 mã có thể gán cho các PHB chuẩn

- ‘xxxx11’ : dùng cho các PHB thực nghiệm hay cục bộ, chúng được định nghã và chỉ

dùng trong một trường DS đơn

- ‘xxxx01’ : dùng cho các PHB thực nghiệm hay cục bộ, 16 mã này trong tương lai có

thể được dùng cho tập chuẩn nếu 32 mã không đủ

II.2.3.2. PHB chuyển tiếp nhanh

Mục tiêu của PHB EF là xây dựng kiểu dich vụ “đường thuê riêng ảo “. Các đặc

trưng dịch vụ này là : tỷ lệ mất gói nhỏ, trễ và biến thiên trễ thấp và thông lượng đảm bảo.

Định nghĩa của EF tập trung vào các cơ chế trong đường truyền với giả thiết rằng lưu lượng

đã được xử lý tại các nút biên của miền DS và có chức năng kiểm soát chấp nhận ở bên

trong miền.

Ý tưởng chính của EF là đối với luồng tập hợp EF, tốc độ ra được giữ ở một tốc độ

đã cho (cấu hình được) hoặc cao hơn, không quan tâm đến tải trên nút tại bất kỳ thời điểm

nào và cũng không quan tâm đến đặc trưng của bất kỳ dòng lưu lượng khác mà nút nhình

29

Codepoint

000000

001000

001111

111000

111001

111101

PHB

PHB_number PHB_semantic

PHB_1

PHB_2

PHB_3

Best - Effort

EF

AF


thấy. Lý do của yêu cầu chặt chẽ này là để cung cấp dịch vụ với những đặc điểm kể trên,

hàng đợi phải luôn giữ ở mức thấp. Các rõ ràng để đạt được điều đó là giữ tốc độ vào thấp

hơn tốc độ ra. Để thực hiện điều đó, tốc độ ra phải cố định hoặc ít nhất là không dưới một

ngưỡng đã cho.

Có một số cơ chế cài đặt PHB EF, bao gồm hàng đợi ưu tiên đơn giản, lập lịch theo

vòng tròn (round robin) có trọng số. .. . Mặc dù các cơ chế này có thể thực hiện chức năng

cơ bản của EF, chúng không có cùng đặc tính. Một số tính chất của dịch vụ như biến thiên

trễ có thể khác nhau rất nhiều trong các cài đặt khác nhau của cùng dịch vụ .

II.2.3.3. PHB chuyển tiếp có đảm bảo

Mục tiêu của định nghĩa dịch vụ này là cho phép mạng cung cấp các mức đảm bảo

truyền khác nhau và có thể các mức trễ và biến thiên trễ khác nhau. Tất nhiên, hai tính chất

sau không phải là mối quan tâm chính của AF. Không có mục tiêu cụ thể về trễ và biến thiên

cho AF, mặc dù trong điều kiện nào đó (ví dụ như phụ thuộc vào việc phân bổ tài nguyên và

cơ chế cài đặt PHB này), luồng được gán PHB AF cao hơn có thể đạt được các đặc tính về

trễ và biến thiên tốt hơn.

Mã được gán cho nhóm PHB AF cho trong bảng sau :

Bảng 2 Byte mã DS cho AF

Yêu cầu của PHB AF được phát biểu bằng những điều kiện về đáp ứng truyền, phân

bổ và sắp xếp lại tài nguyên. Có 4 lớp AF và 3 mức ưu tiên loại bỏ trong mỗi lớp. 6 bit của

byte DS được chia thành hai trường : trường thứ nhất (3 bit) là số lớp AF (giá trị thập phân

2, 3, 4 hoặc 5) và trường thứ hai (3 bit) là mức ưu tiên loại bỏ (giá trị thập phân 0, 2 hoặc 4).

Thứ tự của byte DS (giá trị số lớp AF) chỉ ra trật tự của dịch vụ. Nếu mã (x) < mã (y) thì lớp

(y) có lượng tài nguyên (bộ đệm và băng thông) được cấp ít nhất bằng lớp (x). Tương tự, thứ

tự của trường ưu tiên loại bỏ chỉ ra trật tự của tỷ lệ loại bỏ. Cuối cùng, trong cùng một lớp

AF, nút không được phép sắp xếp lại các gói của luồng bẩt kể mức ưu tiên loại bỏ .

Trong dịch vụ này, các nút cài đặt cả 4 lớp AF và các lớp này không được kết hợp

với nhau : có nghĩa là cac gói thuộc các lớp khác nhau phải được truyền độc lập với nhau.

Đối với 3 mức ưu tiên loại bỏ, phải có ít nhất hai mức tỷ lệ loại bỏ phân biệt. Nếu mạng chỉ

cung cấp hai mức, hai giá trị ưu tiên loại bỏ cao hơn sẽ được ánh xạ vào tỷ lệ loại bỏ cao

hơn và giá trị thấp nhất sẽ được ánh xạ vào tỷ lệ loại bỏ thấp hơn.

30

AF1 AF2 AF3 AF4

Ưu tiên loại bỏ thấp 010000 011000 100000 101000

Ưu tiên loại bỏ trung bình 010010 011010 100010 101010

Ưu tiên loại bỏ cao 010100 011100 100100 101100


Cuối cùng, có thể dùng điều chỉnh lưu lượng để giới hạn lưu lượng AF đi vào mạng.

Các gói có thể bị loại bỏ do hành động điều chỉnh lưu lượng nhưng chúng có thể nâng cấp

hoặc giảm cấp trong mức ưu tiên loại thậm bỏ, chí gán vào lớp AF

II.2.4. Quản lý động tài nguyên trong mô hình DiffServ

Có hai phương pháp quản lý tài nguyên là quản lý tài nguyên động và quản lý tài

nguyên tĩnh, tài nguyên có thể được cung cấp động theo nhiều phương pháp. Trong mô hình

dịch vụ tích hợp, việc cung cấp động động tài nguyên chủ yếu nhờ giao thức RSVP. Trong

mô hình dịch vụ phân biệt, ở phần trên ta đã xem xét mô hình DiffServ với sự cung cấp tĩnh

tài nguyên. Việc cung cấp tĩnh tài nguyên có ưu điểm là không tạo ra nhiều các gói tin báo

điều khiển cho việc dữ trữ tài nguyên như trong cung cấp động và không đòi hỏi việc kiểm

soát thu nhận động, như thế mô hình sẽ đơn giản hơn. Tuy nhiên, việc cung cấp tĩnh tài

nguyên cũng có một số hạn chế, đó là tính kém linh hoạt và đặc biệt là không sử dụng tối ưu

tài nguyên. Chính vì thế, gần đây, để quản lý tài nguyên động trong mô hình DiffServ người

ta sử dụng một phần tử mới là Bandwidth Broker.

II.2.4.1. Tổng quan về Bandwidth Broker

Mục tiêu cuối cùng của hỗ trợ QoS cho mạng là cung cấp các dịch vụ phân phối dữ

liệu với chất lượng khác nhau cho các user và các ứng dụng khác nhau. Tuy nhiên từ quan

điểm định tuyến, hỗ trợ QoS gồm ba phần cơ bản :

Định nghĩa các lớp

Xác định lượng tài nguyên cho mỗi lớp

Phân loại các gói vào các lớp tương ứng

Nỗ lực DiffServ giải quyết vấn đề thứ nhất và vấn đề thứ ba, nó xác định các lớp lưu

lượng cũng như cung cấp một cơ chế phân lớp gói đơn giản mà không cần biết các gói thuộc

luồng nào hay thuộc vào ứng dụng nào. Bandwidth Broker giải quyết vấn đề thứ hai bằng

cách theo dõi sự cấp phát tài nguyên hiện tại cho các lưu lượng được đánh dấu và xem xét

các yêu cầu mới dựa trên các chính sách và sự cấp phát hiện tại.

Ở bên trong vùng DS, BB kiểm tra yêu cầu về QoS từ các user và các ứng dụng riêng

biệt và phân phối tài nguyên trong vùng tuỳ thuộc vào các chính sách sử dụng tài nguyên của

vùng. Ở bên ngoài, một BB sẽ chịu trách nhiệm thiết lập và duy trì thoả thuận dịch vụ song

phương với BB của các miền lân cận để đảm bảo xử lý các lưu lượng dữ liệu đi qua biên của

vùng .

Cơ chế hoạt động của Bandwidth Broker : yêu cầu cấp phát tài nguyên cho một

luồng cụ thể được gửi tới BB. Yêu cầu bao gồm loại dịch vụ, tốc độ, burst tối đa và thời

gian yêu cầu dịch vụ, yêu cầu này có thể do một user hay một BB của vùng khác đưa ra.

Đầu tiên BB sẽ tiến hành chứng thực yêu cầu, sau đó kiểm tra xem tài nguyên chưa được

phân phối có đủ đáp ứng yêu cầu không. Nếu một yêu cầu qua cả hai kiểm tra này, băng

31


thông khả dụng sẽ giảm đi một lượng bằng băng thông yêu cầu và đặc tính luồng (flow

specification) được lưu lại.

BB cấu hình các router lá thích hợp với thông tin về luồng được cấp dịch vụ tại thời

điểm dịch vụ bắt đầu. Sự cấu hình này là “ trạng thái mềm “ (soft state), được BB làm tươi

định kỳ .

BB là một phần của kiến trúc DiffServ, nó đóng vai trò quan trọng trong việc quản lý

tài nguyên dịch vụ khác biệt .Hai khía cạnh quan trọng là :

- Quản lý tài nguyên trong vùng

- Quản lý tài nguyên giữa các vùng

a) Quản lý tài nguyên trong vùng

Quản lý tài nguyên trong một vùng giải quyết vấn đề cấp phát tài nguyên trong một

mạng hay một vùng (domain) .

Trong một mạng gốc, SLA được thoả thuận với khách hàng và yêu cầu cấp phát băng

thông được đáp ứng hay từ chối dựa trên vào lượng tài nguyên khả dụng. Ngoài ra, thông tin

về DSCP được thiết lập, được chuyển cho các router lá và thông tin về thiết lập lớp được

chuyển tới egress router căn cứ vào yêu cầu .

Trong mạng chuyển tiếp, quản lý tài nguyên được yêu cầu chủ yếu để hỗ trợ luồng

thông tin đi qua miền. Khi một BB nhận được thông tin quản lý tài nguyên giữa các miền,

thông tin bao gồm : thông tin về luồng tập hợp đi vào vùng tại một điểm vào cụ thể và DSCP

được yêu cầu cho luồng . Luồng tập hợp hiện tại được update profile thông tin luồng ra vào.

BB theo dõi lưu lượng DS đi vào và rời khỏi vùng qua biên của nó, đảm bảo rằng thoả thuận

song phương với các miền lân cận được đảm bảo

b) Quản lý tài nguyên giữa các vùng

Quản lý tài nguyên giữa các vùng đề cập đến việc cung cấp và phân phối tài nguyên

tại biên mạng giữa hai vùng. Một SLA song phương xác định số lượng và loại luồng, mà

mỗi bên đồng ý gửi và/hoặc nhận, phải được thiết lập trên biên giữa hai miền

Thông điệp báo hiệu được gửi giữa các BB của các vùng lân cận để yêu cầu BB lân

cận tài nguyên cần thiết trong mạng lân cận và để truyền đạt thông tin về tài nguyên được

yêu cầu trên đường nối các vùng.

Trong một mạng gốc, một BB quản lý tài nguyên trên đường nối mạng gốc với mạng

chuyển tiếp kề với nó. Trong mạng chuyển tiếp, BB theo dõi lưu lượng DS đến và đi khỏi

vùng qua biên vùng, đảm bảo rằng thoả thuận song phương với vùng lân cận được giữ vững.

BB thông tin với router biên đi vào và đi ra để cấu hình bộ điều khiển lưu lượng

trong router dựa trên các thoả thuận.

32


II.2.4.2. Kiến trúc của một hệ thống BB

Một BB bao gồm 4 thành phần như sau

Bandwidth Broker Database

Bandwidth Broker Server

Bandwidth Broker Command Line Interfaces

o Service Level Agreement Client.

o Bandwidth Allocation request Client.

Bandwidth Broker router configuration client

Trong đó :

BB SLA Client dùng để theo dõi các user, tài nguyên và topology của vùng. BB SLA

Client chứa dữ liệu SLA, dữ liệu cấp phát tài nguyên và dữ liệu topology của vùng .

BB Server xử lý tất cả tin tức truyền thông giữa các thành phần của BB, tiến hành

chứng thực và cấu hình thiết bị

Bandwidth Broker Command Line Interfaces cung cấp chức năng yêu cầu và thay

đổi dịch vụ user

BB Router Configuration Client cấu hình các router lá trong miền để xử lý dữ liệu từ

một user riêng biệt

Hình dưới đây minh hoạ mô hình dịch vụ phân biệt sử dụng Bandwidth Broker, trong đó

BB là phần tử đóng vai trò quản lý tài nguyên trong dịch vụ phân biệt

33

BB Database

BB SLA Client

BB BARClient

BB RouterClient

BB Server

Hình 14 . Kiến trúc hệ thống Bandwidth Broker

Hình 15 . Mô hình dịch vụ phân biệt xử dụng BB


II.2.5. Ưu điểm và hạn chế của dịch vụ Diffserv

II.2.5.1. Ưu điểm

Tính dễ mở rộng (scalability)

Đây là ưu điểm quan trọng nhất của Diffserv. Trên mạng trục có thể có rất nhiều

luồng lưu lượng, bất kỳ giao thức nào yêu cầu duy trì trạng thái từng luồng hay tính toán

phức tạp đều dẫn đến khó khăn trong việc mở rộng dịch vụ. Diffserv thực hiện gộp nhiều

luồng và do đó có thể xử lý một số lượng luồng lớn. Thêm nữa, Diffserv đưa những công

việc phức tạp (phân loại, qui định lưu lượng) ra các bộ định tuyến biên nên các PHB trong

Diffserv đơn giản, cho phép hoạt động với tốc độ cao.

Dễ quản trị

Trong một DS framework, các vùng DS khác nhau có thể cài đặt các PHB tuỳ ý

miễn là thoả mãn SLA . Do đó các nhà cung cấp dịch vụ có thể tự do lựa chọn cài đặt, vì

vậy họ có thể chọn cách cung cấp Diffserv với những thay đổi tối thiểu trong cơ sở hạ tầng

của họ.

II.2.5.2. Hạn chế của Diffserv

Trong kiến trúc Diffserv có hai hạn chế cơ bản.

Diffserv cung cấp chất lượng dịch vụ cho luồng lưu lượng trên cơ sở từng chặng, thường

không đảm bảo chất lượng dịch vụ từ đầu cuối đến đầu cuối

Diffserv không có khả năng xử lý lỗi đường truyền. Chẳng hạn, khi một đường truyền

mang lưu lượng EF trong miền Diffserv hỏng, nhà cung cấp dịch vụ không có cách nào

để gửi nhanh lưu lượng qua một đường truyền khác và đảm bảo mất gói là tối thiểu.

Hơn nữa sử dụng cơ chế chọn đường ngắn nhất, một số đường trong miền Diffserv có

thể bị tắc nghẽn trong khi các đường khác lại không được sử dụng.

Có thể thấy Diffserv chỉ thích hợp với mạng trục, nơi có nhiều luồng đi qua, để kết hợp

các luồng giảm bớt tải cho thiết bị. Nhưng ngay cả trên mạng trục, cũng cần có những cơ

chế hỗ trợ Diffserv trong việc chọn đường để nâng cao hiệu quả sử dụng dịch vụ . MPLS với

khả năng traffic engineering có thể đáp ứng yêu cầu này .

34


II.3. Multi Switching Label Protocol và Traffic Engineering

II.3.1. Giới thiệu

Trong mạng IP truyền thống, gói dữ liệu được chuyển tiếp độc lập tại mỗi router căn

cứ vào header của gói và bảng thông tin định tuyến. Thuật toán chuyển tiếp dựa trên so khớp

dài nhất, nghĩa là prefix so khớp càng dài càng được ưu tiên. Tuy nhiên thuật toán này khá

chậm. Đồng thời chọn đường theo qui tắc đường dẫn ngắn nhất cũng giới hạn khả năng quản

lý tài nguyên mạng .

MPLS là một công nghệ mới cố gắng giải quyết những vấn đề về định tuyến trong

mạng IP truyền thống . Với MPLS, một nhãn có chiều dài ngắn và cố định được gán cho mỗi

packet và quá trình chuyển gói trong mạng dựa trên nhãn này. Việc phân tích toàn bộ

header của gói dữ liệu được thực hiện chỉ một lần tại nút vào của mạng MPLS, nhờ vậy tiến

trình định tuyến đơn giản hơn và nhanh hơn.

Các dịch vụ trong mạng IP truyền thống có đặc trưng không thể dự đoán trước. Điểm

mạnh của MPLS là cung cấp khả năng Traffic Engineering. Ví dụ như việc sử dụng các

tuyến đường rõ ràng dẫn đến khả năng quản lý tài nguyên mạng và hỗ trợ các dịch vụ mới.

Sau đây, chúng ta sẽ xem xét kiến trúc của MPLS và Traffic engineering với MPLS

II.3. 2. Kiến trúc MPLS

Ý tưởng của MPLS là khi một packet đến một ingress LSR (Label Switching

Router). LSR xác định FEC (Forwarding Equivalent Class) của packet và gán nhãn cho

packet tương ứng với FEC đó dựa vào ánh xạ trong Incoming Label Map (LIM). LIM có thể

được đặt tại mỗi nút bằng tay hoặc bằng giao thức báo hiệu như LDP, CR – LDP và RSVP –

TE (được IETF định nghĩa). Các LSR tiếp theo trong đường đi của packet ra quyết định

chuyển tiếp dựa trên nhãn của packet và thực hiện hành động tương ứng với nhãn (được qui

định trong LIM) .Nút cuối cùng trong miền MPLS, egress LSR sẽ bỏ nhãn để router kế tiếp

nhận được packet giống như khi packet đi vào miền MPLS đó .

Sơ đồ chuyển tiếp gói MPLS như sau :

35


II.3.2.1. Các thành phần chính trong mô hình

Nhãn

Nhãn được sử dụng trong MPLS có chiều dài ngắn và cố định. Một nhãn chỉ có ý

nghĩa cục bộ và nó đại diện cho một FEC mà packet được gán vào. Một packet có thể có

nhiều nhãn và chúng được tổ chức thành stack (Last In First Out).

Label Switching Router (LSR)

LSR là một nút có khả năng chuyển tiếp packet tự nhiên của tầng mạng và cũng cho

phép các giao thức điều khiển MPLS. Có thể phân LSR thành LSR ngược hướng và LSR

xuôi hướng .LSR chuyển packet theo hướng của luồng dữ liệu là LSR xuôi hướng còn LSR

nhận packet là LSR ngược hướng.

Label Switching Path (LSP)

LSP của một packet là một dãy các router < R1 ;. .. ; Rn > với R1 là LSP ingress và

Rn là LSP egress. LSP ingress gán nhãn vào packet ở mức m nào đó, các router giữa nút vào

và nút ra chuyển packet dựa vào nhãn này, nút ra chuyển tiếp packet sử dụng nhãn ở mức m

– k với k > 0 hoặc sử dụng một số thủ tục chuyển tiếp khác.

Next Hop Label Forwarding Entry (NHLFE)

NHLFE được sử dụng khi một packet đã gán nhãn được chuyển tiếp về phía trước

NHLFE chứa thông tin về chặng tiếp theo của packet và hoạt động được thực hiện trên

36

Tạo nhãn

Đổi nhãn

Đổi nhãn

LSR

Đổi nhãn

Đổi nhãn

Bỏ nhãn

Bản đồ nhãn

Bản đồ nhãn

Bản đồ nhãn

Bản đồ nhãn

Nút biên

Nút biên

Mạng không phải MPLS

Mạng MPLS

Mạng không phải MPLS

Luồng không được gán nhãn Luồng được gán nhãn lộ trình 1Luồng gán nhãn lộ trình 2

Hình 16 . Cơ chế chuyển tiếp gói MPLS


chồng nhãn của packet. Một nhãn có thể được thay thế bằng một nhãn mới hay có thể bị bỏ

đi. Mỗi nhãn của một packet vào có thể được liên kết một NHLFE. Để chia lưu lượng ra

thành các đường khác nhau có thể có vài NHLFE cho một label .

Incoming Label Map (ILM)

ILM mô tả ánh xạ giữa nhãn của một packet vào và một tập NHLFE. LSR chuyển

tiếp packet được xác định bởi NHLFE. Có thể so sánh ILM với bảng định tuyến của router

IP truyền thống.

Label Mapping

Kết hợp nhãn là khả năng của LSR chuyển tiếp các packet có nguồn hoặc nhãn khác

nhau tới một FEC với một nhãn. Thông tin mà các packet có khi chúng tới từ các interface

khác nhau với nhãn khác nhau, sẽ bị mất trong thủ tục kết hợp nhãn .

II.3.2.2. Forwarding Equivalent Class

Thông tin từ một số giao thức dẫn đường truyền thống (như OSPF) được giữ lại

trong định tuyến tầng mạng để biết cần chuyển tiếp packet như thể nào và để chia không

gian chuyển tiếp thành thành các FEC. FEC bao gồm các packet được chuyển tiếp trên cùng

đường dẫn và được đối xử như nhau. Nhãn của một packet ánh xạ packet tới một FEC.

Packet được gán vào FEC chỉ một lần

Forwarding granularity đề cập đến mức độ tập hợp được sử dụng trong quyết định

chuyển tiếp. MPLS hỗ trợ nhiều kiểu forwarding granularity. Các packet có thể được gán

vào cùng FEC dựa trên nút ra, địa chỉ IP đích hoặc luồng ứng dụng. Phân loại dựa vào nút ra

là mức thô nhất của granularity và phù hợp với mạng lớn. Trong khi đó phân loại căn cứ vào

luồng ứng dụng là mức tinh vi nhất nhưng nó khả năng mở rộng không cao .

II.3.2.3. Label Distribute Protocol

Label Distribute Protocol được sử dụng trong tiến trình thiết lập đường dẫn, với

LDP, một LSR thông báo cho LSR khác về ánh xạ label/FEC mà nó đã thực hiện. Quyết

định gán một label tới một FEC được thực hiện bởi LSR xuôi hướng. LSR này có thể thực

hiện kết nối nhãn theo hai cách. Cách thứ nhất, LSR ngược hướng yêu cầu LSR lân cận kết

gán một nhãn tới một FEC. Các thứ hai, LSR xuôi hướng gán trực tiếp mà không cần yêu

cầu .Label Distribute Protocol cũng được sử dụng để trao đổi thông tin về khả năng MPLS

giữa hai Label Distribute peer. MPLS cho phép nhiều Label Distribute Protocol. Ba Label

Distribute Protocol là LDP, CR – LDP và RSVP – TE đã được chuẩn hoá .

37


II.3.3. Traffic Engineering với MPLS

II.3.3.1. Giới thiệu chung

Traffic Engineering được sử dụng để đạt được mục tiêu hiệu năng như tối ưu tài

nguyên mạng và xắp đặt lưu lượng vào các đường truyền cụ thể. Điều này có nghĩa là tính

toán đường đi từ nguồn đến đích dựa vào một tập ràng buộc và chuyển tiếp lưu lượng dọc

theo đường đi này. Chuyển tiếp lưu lượng theo một đường như vậy là điều không thể đối với

IP, bởi vì quyết định chuyển tiếp IP được đưa ra độc lập tại mỗi chặng và chỉ dựa trên địa

chỉ đích IP của packet

MPLS có thể dễ dàng chuyển tiếp lưu lượng trên một đường đi tuỳ ý. Khả năng dẫn

đường rõ ràng của MPLS cho phép người khởi tạo LSP tính toán đường đi, thiết lập trạng

thái chuyển tiếp MPLS dọc theo đường đi và ánh xạ các packet tới những LSP này. Khi một

packet được ánh xạ vào một LSP, việc chuyển tiếp được thực hiện dựa trên nhãn và không

hop trung gian nào thực hiện bất cứ quyết định chuyển tiếp độc lập dựa trên địa chỉ đích IP

của packet. MPLS – TE đưa ra khái niệm LSP priorities. Mục đích của priorities là đánh dấu

một số LSP báo hiệu rằng chúng quan trọng hơn các LSP khác và cho phép chúng lấy tài

nguyên từ những LSP ít quan trọng hơn. Làm như vậy sẽ đảm bảo rằng :

- Khi không có các LSP quan trọng, tài nguyên có thể được dành cho các LSP ít quan trọng

hơn.

- Một LSP quan trọng luôn thiết lập dọc theo đường đi tối ưu nhất (ngắn nhất)

- Khi một LSP cần định tuyến lại, các LSP quan trọng có cơ hội tìm thấy một đường đi lớn

hơn .

Mục tiêu của traffic engineering là tìm ra một đường đi trong mạng thoả mãn một tập

các ràng buộc. Do đó, những ràng buộc này cần được đưa vào tính toán khi tính toán các

đường đi khả thi tới đích. Các ràng buộc đó có thể là băng thông yêu cầu cho một LSP cụ

thể, số lượng hop mà lưu lượng được phép đi qua, mức ưu tiên của LSP so với các LSP

khác. v. v. .

Việc tính toán một đường dẫn thoả mãn những điều kiện ràng buộc này có thể được

thực hiện tại nút vào sử dụng một thuật toán tính đường (ví dụ như CSPF).

Cuối cùng khi đường đi đã được tính toán thành công, trạng thái chuyển tiếp MPLS

được thiết lập dọc theo đường đi bằng cách sử dụng RSVP – TE như một giao thức phân bố

nhãn. Khi đường đi được thiết lập, tài nguyên khả dụng được update tại mỗi nút và các nút

khác được thông tin về sự thay đổi này

38


II.3.3.2. Mô hình thực hiện

Để thực hiện traffic engineering, nguời ta đưa ra hai phương pháp là Overlay Model

và Peer Model .

a) Mô hình Overlay

Mạng backbone thường sử dụng công nghệ ATM và sử dụng nó theo cách thông

thường để xây dựng mạch qua đó lựa chọn đường đi qua một mạng. Thay vì cho phép mỗi

router quyết định đường đi xuyên qua mạng, điều hành viên có thể xây dựng đường đi hay

các mạch đi qua vài router mà không để những router này đưa ra bất kì quyết định nào về

dẫn đường, điều này có nghĩa là bảng định tuyến được xây dựng bằng tay. Đối với mạng IP,

MPLS có thể thực hiện nhiệm vụ này.

Chức năng tích cực của một mạng như vậy là lưu lượng có thể được chuyển một

cách rõ ràng, cho phép lưu lượng đi qua một số đường truyền tốc độ thấp, giải phóng dung

lượng trên các đường truyền khác nhằm nâng cao hiệu năng truyền lưu lượng. Việc này có

thể được thực hiện bằng cách nhập vào bằng tay một số tuyến hoặc bằng cách thiết lập tự

động một mạng “ full mesh “ (mạng mà mọi lối vào /ra đều có đường đi trực tiếp đến mọi lối

vào khác). Mặc dù mô hình Overlay có nhiều thuận lợi và đang được sử dụng rộng rãi hiện

nay nhưng nó có vấn đề về mở rộng khi thiết lập mạng full mesh. Đó là vấn đề “ N – square

“ mà đối với mỗi LER được thêm vào mạng, phải thêm vào một đường đi từ LER này tới

mỗi LER khác trong mạng. Như vậy sẽ có N – 1 đường đi mới cho mỗi LER mới. Khi mạng

tăng lên, số lượng đường đi tăng lên rất lớn, thêm vào sự phức tạp và chi phí thông điệp

đáng kể. Đặc biệt là khi một đường truyền hỏng, phải thực hiện một số lượng lớn hoạt động

update.

b) Mô hình peer

Trong mô hình này điều khiển lưu lượng cân bằng có thể đạt được bằng cách thay

đổi weight của đường truyền trong giao thức dẫn đường OSPF. Với phương pháp này, mỗi

đường truyền được cho một giá trị phản ánh mức độ sử dụng của đường truyền đó. Nếu là

một đường truyền chậm, đắt như đường truyền vệ tinh hay đường hay bị tắc nghẽn, đường

truyền này có thể được cho một giá trị weight cao, để báo cho router chọn đường truyền

khác. Theo cách này, các weight được tính toán và thiết lập chỉ một lần , có thể giúp mạng

cân bằng với ít hoặc không có đường truyền tắc nghẽn và lưu lượng overhead ít hơn so với

mô hình Overlay .

II.3.4. Kết luận

Được thiết kế để cho phép IP over ATM nhưng MPLS có những kết quả tích cực nếu

được cài đặt trên mạng IP thông thường. MPLS là một giải pháp đa năng cho nhiều vấn đề

của mạng hiện nay: tốc độ, scalibility, quản lý chất lượng dịch vụ và traffic engineering.

Bằng cách gắn một header đặc biệt vào một packet, các router trong mạng sẽ không cần mở

39


packet, trích ra địa chỉ IP và dựa vào đó để quyết đường đi. MPLS chỉ đơn giản mở header

đặc biệt và căn cứ vào header này, gửi packet đến đường kế tiếp xác định.

Bằng cách sử dụng một công nghệ như MPLS, traffic engineering cho phép giảm tắc

nghẽn lưu lượng trên mạng. Với traffic engineering, có thể đưa một số lưu lượng vào một

đường và một số lưu lượng vào đường khác, chẳng hạn như trên một đường truyền vệ tinh

và trên một đường truyền khác rẻ hơn. MPLS header sẽ báo cho router đường gửi packet

thay vì lựu chọn packet gần nhất

40


PHẦN 3ĐÁNH GIÁ, KẾT LUẬN

III.1. Đánh giá, phân tích các phương pháp:

Cả bốn phương pháp cung cấp chất lượng dịch vụ cho mạng IP là Intserv, Diffserv,

MPLS và Traffic engineering đều có những ưu và nhược điểm riêng.

(1) Mô hình dịch vụ tích hợp (Intserv)

Ưu điểm:

o Có khả năng cung cấp chất lượng dịch vụ end-to-end.

o Cho phép đặp trước một kênh xuyên qua mạng với băng thông đảm bảo

Nhược điểm:

o Khả năng mở rộng kém, chỉ thích hợp với mạng nhỏ.

(2)Mô hình dịch vụ phân biệt (Diffserv)

Ưu điểm:

o Dễ mở rộng: Đây là ưu điểm quan trọng nhất của Diffserv. Trên mạng trục

có thể có rất nhiều luồng lưu lượng, bất kỳ giao thức nào yêu cầu duy trì

trạng thái từng luồng hay tính toán phức tạp đều dẫn đến khó khăn trong việc

mở rộng dịch vụ. Diffserv thực hiện gộp nhiều luồng và do đó có thể xử lý

một số lượng luồng lớn. Thêm nữa, Diffserv đưa những công việc phức tạp

(phân loại, qui định lưu lượng) ra các bộ định tuyến biên nên các PHB trong

Diffserv đơn giản, cho phép hoạt động với tốc độ cao

o Dễ quản trị: Trong một DS framework, các vùng DS khác nhau có thể cài

đặt các PHB tuỳ ý miễn là thoả mãn SLA . Do đó các nhà cung cấp dịch vụ

có thể tự do lựa chọn cài đặt, vì vậy họ có thể chọn cách cung cấp Diffserv

với những thay đổi tối thiểu trong cơ sở hạ tầng của họ.

Nhược điểm:

o Diffserv cung cấp chất lượng dịch vụ cho luồng lưu lượng trên cơ sở từng

chặng, thường không đảm bảo chất lượng dịch vụ từ đầu cuối đến đầu cuối.

o Diffserv không có khả năng xử lý lỗi đường truyền.

o Chỉ thích hợp với mạng đường trục

(3)MPLS & Traffic engineering

Ưu điểm:

o Kết hợp khả năng chuyển mạch nhanh của tầng 2 và định tuyến ở tầng 3, có

khả năng Traffic engineering, giúp tránh tắc nghẽn trong mạng

o Tối ưu hóa tài nguyên mạng, sắp đặt lưu lượng vào các đường truyền cụ thể

41


Nhược điểm: Không đưa ra kiến trúc QoS mới, không có khả năng phân biệt dịch

vụ trong mỗi luồng.

III.2. Đề xuất, kiến nghị

Các phương pháp trên đều nhằm mục đích tăng hiệu năng mạng nhưng chúng được

thực hiện theo những cách khác nhau, tách biệt với nhau. Tuy nhiên, mỗi một phương pháp

có một số ưu và nhược điểm riêng. Để cải thiện hơn nữa chất lượng dịch vụ trên mạng IP,

chúng em đề xuất 2 mô hình kết hợp để tăng cường khả năng cung cấp chất lượng dịch vụ

là:

- Mô hình Kết hợp Intserv với Diffserv

- Mô hình Kết hợp Diffserv với MPLS

III.3. Phương án thực hiện các đề xuất và kiến nghị

III.3.1. Mô hình Kết hợp IntServ và DiffServ

III.3.1.1. Lợi ích của mô hình kết hợp Intserv và Diffserv

Cả Intserv và Diffserv đều có những ưu điểm và nhược điểm riêng, RFC 2998 đã

đưa ra Frame work cho hỗ trợ dịch vụ Intserv trên mạng Diffserv.

Lợi ích của việc kết hợp này khá rõ ràng, Diffserv với việc điều khiển luồng theo tập

hợp có khả năng mở rộng cao sẽ bù đắp cho khả năng mở rộng không cao của Intserv.

Ngược lại, RSVP trong Intserv cũng giúp Diffserv cung cấp dịch vụ có tính định lượng trên

mạng, cái mà một mình Diffserv không đáp ứng được.

Trong Diffserv, điều khiển thâm nhập được thực hiện theo một cách tương

đối tĩnh bằng cách cung cấp các tham số policing tại các phần tử mạng. Với việc sử

dụng RSVP, Diffserv có khả năng điều khiển thâm nhập dựa trên tài nguyên nhờ vậy có

thể sử dụng tài nguyên mạng tối ưu.

Sử dụng RSVP, Diffserv có thể thực áp dụng điều khiển thâm nhập dựa trên

chính sách đối với từng user, từng ứng dụng chứ không phải đối với toàn bộ mạng chứa

user hay ứng dụng đó, nhờ vậy tăng hiệu quả sử dụng tài nguyên mạng

Trong một mạng Diffserv, DSCP có thể được đánh dấu tại host hoặc router

nhưng cả hai cơ chế này đều tồn tại những nhược điểm riêng.

Đối với đánh dấu tại host đó là khó khăn trong việc quản lý thông tin về cách hiểu

(interpretation) DSCP của mạng.

Còn với đánh dấu tại router, nếu là đánh dấu tĩnh (cấu hình bằng tay hay bằng script

tự động) thì sẽ gặp khó khăn trong quản lý thông tin phân loại do tiêu chuẩn phân loại

thường xuyên thay đổi. Việc đánh dấu tại router có thể được thực hiện bằng cách cho phép

42


hệ điều hành của host báo hiệu tiêu chuẩn phân loại tới router (động). RSVP rất thích hợp

cho nhiệm vụ báo hiệu.

Các phần tử mạng Intserv thực hiện qui định (conditioning) lưu lượng theo

từng luồng. Việc quy định trước lưu lượng theo cách này trước khi chúng đi vào mạng

Diffserv sẽ làm tăng khả năng cung cấp dịch vụ định lượng sử dụng điều khiển lưu

lượng gộp của Diffserv

Từ những lợi ích này, Intserv và Diffserv có thể được sử dụng bổ xung cho nhau.

Intserv được sử dụng tại mạng truy nhập (access) cho phép các host yêu cầu và dự trữ tài

nguyên từng luồng nhờ RSVP và Diffserv được sử dụng trong mạng trục sẽ tránh vấn đề mở

rộng RSVP

III.3.1.2. Framework cho Intserv/RSVP over Diffserv

a) Mạng tham chiếu cho Framework Intserv/RSVP over Diffserv như sau :

Như được thể hiện trên hình vẽ, Framework bao gồm những phần tử sau :

- Sender và Receiver là những host có khả năng RSVP, nó có thể khởi tạo một tiến

trình RSVP dựa trên yêu cầu ứng dụng chạy trên host đó

- Edge và Boder router là các thiết bị cạnh mà chức năng của nó phụ thuộc vào sự thực

thi cụ thể của Framework .

- Miền non – Diffserv là một miền có khả năng Intserv chứa các host và những phần tử

mạng khác có khả năng Intserv và cũng có thể chứa cả những phần tử mạng khác nữa

- Miền Diffserv có thể hoặc không chứa các router biết về RSVP

b) Ánh xạ dịch vụ

Ánh xạ dịch vụ phụ thuộc vào sự lựu chọn PHB phù hợp, điều khiển thâm nhập và

điều khiển chính sách trên yêu cầu Intserv dựa trên tài nguyên khả dụng và chính sách trong

Intserv

43

Hình 17 : Mạng tham chiếu cho Intserv/RSVP over Diffserv framework


Ánh xạ dịch vụ bao gồm :

- Lựa chọn một PHB hay một tập PHB cho dịch vụ được yêu cầu

- Thực hiện policing phù hợp tại cạnh của miền Diffserv

- Xuất các tham số Intserv khỏi miền Diffserv

- Thực hiện điều khiển truy nhập trên yêu cầu Intserv mã đã tính cả tài nguyên trong

miền Diffserv

Có một bảng ánh xạ mặc định nổi tiếng :

Trong cách ánh xạ này dịch vụ đảm bảo được ánh xạ tới EF PHB, trong khi dịch vụ

tải được điều khiển tuỳ thuộc vào nó có khả năng chịu trễ hay không mà được ánh xạ vào

các mức ưu tiên AF PHB khác nhau .

Các router có khả năng xử lý cả packet Diffserv và RSVP sẽ thực hiện ánh xạ dịch

vụ ở trên và các router này cũng có thể sử dụng ánh xạ dịch vụ khác (override). Những

router này thường được đặt ở cạnh của vùng Diffserv

c) Quản lý tài nguyên trong mạng Diffserv

Có nhiều cách khác nhau quản lý tài nguyên trên mạng Diffserv khác nhau để thoả

mãn yêu cầu của các luồng Intserv từ điểm cuối đến điểm cuối, bao gồm :

- Tài nguyên được cung cấp tĩnh

- Tài nguyên được cung cấp động bằng RSVP

- Tài nguyên được cung cấp động bằng các phương tiện khác như Bandwidth

Broker, .vv.

III.3.1.3. Thực thi Framework

Thực thi cụ thể Framework phụ thuộc vào sự quản lý tài nguyên Diffserv và khả

năng RSVP của miền mạng Diffserv. Như vừa đề, quản lý tài nguyên mạng Diffserv có thể

là động hoặc tĩnh. Miền mạng Diffserv được xem là “ hiểu “ (aware) nếu nó có các router

RSVP tiêu chuẩn trong domain của nó, ít nhất là trên biên của domain. Những router nào là

router hiểu RSVP tuỳ thuộc người quản trị.

44

Intserv service Diffserv PHB

Controlled Load

Guaranted service

HAF

L AF

EF PHB

Bảng 3 : Bảng ánh xạ dịch vụ mặc định


Trong trường hợp tài nguyên được cung cấp tĩnh, chủ của miền Diffserv thoả thuận

một SLA tĩnh với khách hàng của nó, tức là miền Intserv, do đó, chủ của Diffserv sẽ thực

hiện một số hành động phù hợp với SLA đã được thoả thuận để thực hiện cam kết dịch vụ.

Trong trường hợp tài nguyên được cung cấp động, SLA được thoả thuận dựa trên các

các yêu cầu được gộp từ nhiều khách hàng, do đó , nó yêu cầu các cơ chế phức tạp hơn

nhiều trong Diffserv để có thể thực hiện điều khiển truy nhập và phân chia tài nguyên chính

xác . Những cớ chế này đang được nghiên cứu.

Cơ chế kiểm soát thâm nhập và phân chia tài nguyên trong vùng Diffserv rất được

ưu thích là Bandwidth Broker.

III.3.1.4. Kết luận

Intserv over Diffserv là phương pháp cung cấp chất lượng dịch vụ đang rất được

quan tâm hiện nay. Intserv với khả năng cung cấp chất lượng dịch vụ end-to-end, diffserv

với khả năng mở rộng cao có thể kết hợp với nhau trong một mạng để bổ xung cho nhau

cung cấp dịch vụ end-to-end có khả năng mở rộng

III.3.2. Hỗ trợ Diffserv trên MPLS

III.3.2.1. Lợi ích của kết hợp Diffserv và MPLS

Diffserv cung cấp chất lượng dịch vụ cạnh tới cạnh dễ mở rộng, trong khi đó MPLS

thực hiện traffic engineering để phân phối tải lưu lượng trên các đường truyền khả dụng và

dẫn đường nhanh đối với những tuyến qua nút hoặc liên kết hỏng. Thêm nữa MPLS có thể

được sử dụng trên nhiều công nghệ tầng liên kết (link) khác nhau. Kết hợp Diffserv và

MPLS trên mạng backbone là một phương án đang được quan tâm hiện nay với QoS dễ mở

rộng và khả năng traffic engineering, sử dụng công nghệ chuyển mạch nhanh .

III.3.2.2. Nguyên tắc

Khi một packet Diffserv đi vào mạng MPLS, LSR ở lối vào kiểm tra trường ToS của

gói dữ liệu để lấy các thông tin Diffserv. Lưu lượng vào được ánh xạ tới LSP thích hợp. Khi

packet ra khỏi mạng MPLS đi vào mạng Diffserv lưu lượng MPLS được ánh xạ tới các PHB

thích hợp. MPLS có thể ánh xạ lưu lượng Diffserv vào lưu lượng MPLS theo hai cách. Cách

thứ nhất nhiều BA có thể được ánh xạ vào một LSP, cách thứ hai là mỗi BA được ánh xạ tới

một LSP. Khi nhiều BA được ánh xạ tới một LSP thì trường Exp trong MPLS được sử dụng

để xác định PHB. Phương pháp này được gọi là EXP-Inference-PSC LSP

(E-LSP). Ở phương pháp thứ hai mỗi BA được ánh xạ tới một LSP, phương pháp này được

gọi là Label-Only-Inference-PSC LSP (L-LSP).

Bảng sau cho thấy sự khác nhau giữa E-LSP và L-LSP

E-LSP L-LSP

45


PHB được xác định từ trường EXP PHB được xác định từ nhãn và trường EXP

Không yêu cầu báo hiệu PHB hoặc nhóm PHB scheduling được

báo hiệu khi thiết lập LSP (LDP, RSVP....)

Ánh xạ EXP-> PHB được cấu hình Ánh xạ label->PHB được báo hiệu

Ánh xạ EXP->PHB là ánh xạ nổi tiếng

Yêu cầu Shim header

E-LSp không thể thực hiện trên ATM

link

Shim header hoặc header tầng link có thể

được sử dụng, do đó phù hợp với ATM

link

Có thể đến từ 1 đến 8 PHP mỗi LSP Mỗi PHB một LSP

Hỗ trợ 8 BA Hỗ trợ nhiều hơn 8 BA

Với E-LSP : trường EXP được sử dụng để xác định BA. Nhãn có thể được sử dụng

để ra quyết định chuyển tiếp và trường EXP có thể được sử dụng để xác định cách đối xử

với packet.

Với L-LSP : một LSP riêng biệt được thiết lập cho mỗi cặp < FEC, BA >. Trong

trường hợp này, LSR có thể có thể xác định đường dẫn cũng như là cách đối xử với packet

từ nhãn của packet. Trường EXP mã hoá mức ưu tiên bỏ của packet.

III.3.2.3. Các hoạt động của LSR Diffserv MPLS

Xác định PHB đến :

- Đối với E-LSP, ánh xạ EXP-to-PHB có thể được cấu hình trước hoặc được báo

hiệu rõ ràng trong quá trình thiết lập E-LSP. LSR xác định PHB được áp dụng cho packet

đến bằng cách kiểm tra trường EXP trong ánh xạ EXP-to-PHB

- Đối với L-LSP : ánh xạ EXP-to-PHB là một chức năng của PSC (PHB scheduling

Class) được mang trên L-LSP và được thiết lập trong quá trình thiết lập L-LSP. Do đó, PSC

(tức là queue và scheduling) là đã biết đối với LSR dựa trên trường nhãn. LSR sau đó xác

định mức ưu tiên bỏ, do đó xác định PHB, được áp dụng đối với packet đến bằng cách kiểm

tra trường EXP trong ánh xạ EXP-to_PHB

Xác định PHB ra với qui định lưu lượng tuỳ chọn :

Một LSR Diffserv có thể thực hiện đánh dấu, khống chế (police) và định dạng

(shapping) trên luồng lưu lượng đến, thay đổi PHB ra cho những packet không thoả mãn

trong luồng lưu lượng đến. Do đó, PHB đến và ra có thể khác nhau.

Chuyển tiếp nhãn

Mỗi LSR Diffserv phải biết “ Diffserv context “ cho nhãn, nó bao gồm loại LSP, các

PHB được hỗ trợ, ánh xạ EXP-to-PHB cho một nhãn đến và ánh xạ PHB-to-EXP cho nhãn

ra.

Mã hoá thông tin Diffserv vào tầng Encapsulation

46


LSR xác định giá trị EXP được ghi vào packet ra bằng cách tìm PHB trong bảng ánh

xạ PHB-to-EXP.

- E-LSP xác định của một packet chỉ dựa vào trường EXP và do đó chỉ có thể hỗ trợ

8 PHB mỗi E-LSP. Trường EXP mang queuing, scheduling và mức ưu tiên bỏ cho LSR.

Báo hiệu PHB có thể được sử dụng để báo hiệu rõ ràng các PHB được hỗ trợ trong lúc thiết

lập LSP nhưng không bắt buộc.

- L-LSP xác định PHB của packet từ cả nhãn và trường EXP. Trường nhãn xác định

PSC (queuing và scheduling) trong khi trường EXP xác định PHB ( ưu tiên bỏ). L-LSP có

thể hỗ trợ một số lượng lớn tuỳ ý PHB.

III.3.2.4. Những ưu điểm và tồn tại của hai mô hình E-LSP và L-LSP

Với những mạng hỗ trợ ít hơn 8 mức phân loại Diffserv, E-LSP rất hữu dụng. Nó kết

hợp khả năng traffic engineering của MPLS và QoS được cung cấp bởi DSCP. Nhưng 3 bit

EXP chỉ cho phép biểu diễn 8 BA cho một FEC nên với những mạng hỗ trợ hơn 8 BA, E-

LSP không còn hiệu quả.

L-LSP được sử dụng để hỗ trợ một số lượng tuỳ ý cặp < FEC, BA >, khắc phục được

hạn chế của E-LSP. Nhưng nó cũng có hạn chế, đó là khả năng mở rộng. Với một LSP cho

một BA, số lượng nhãn một LSR phải duy trì có thể trở thành vấn đề khi số lượng PHB tăng

quá lớn .

III.3.2.5. Kết luận

Diffserv over MPLS là phương pháp cung cấp chất lượng dịch vụ đang rất được

quan tâm hiện nay. MPLS với khả năng traffic engineering và sử dụng công nghệ chuyển

mạch nhanh có thể kết hợp với Diffserv để cung cấp chất lượng dịch vụ trên mạng backbone

47


Kết luận

Xu hướng phát triển của các mạng truyền số liệu trong những năm qua đã cho thấy

sự quan tâm ngày càng tăng đến vấn đề chất lượng dịch vụ và đáp ứng yêu cầu chặt chẽ của

các ứng dụng thời gian thực. Đó cũng là một trong những hướng phát triển chính của công

nghệ mạng và truyền số liệu.

Trong tiểu luận này, chúng em đã trình bày các cơ chế cung cấp chất lượng dịch vụ

cho các ứng dụng yêu cầu thời gian thực trên mạng IP (Phần I, II). Đó là mô hình dịch vụ

tích hợp (Intserv), mô hình dịch vụ phân biệt (DiffServ), công nghệ MultiProtocol Label

Switching (MPLS) và cơ chế Traffic Engineering, trong đó mỗi giải pháp đều có ưu nhược

điểm riêng. Dịch vụ tích hợp, kết hợp với giao thức RSVP cho phép đảm bảo chất lượng

dịch vụ từ đầu cuối đến đầu cuối với các tiêu chuẩn định lượng cụ thể nhưng phức tạp đòi

hỏi nhiều tài nguyên và khả năng xử lý của mạng do đó chỉ thích hợp với các mạng có qui

mô vừa và nhỏ. Dịch vụ phân biệt cho phép xử lý lưu lượng theo các nhóm có độ ưu tiên

khác nhau, nó thích hợp với các mạng trục lớn hơn. MPLS kết hợp khả năng chuyển mạch

nhanh ở tầng hai với khả năng định tuyến gói tin IP ở tầng ba cùng với với ứng dụng

Traffic Engineering cho phép cân bằng tải là thích hợp cho cung cấp chất lượng dịch vụ

trong các mạng trục lớn. Các phương pháp trên có thể kết hợp với nhau , tận dụng ưu điểm

của nhau để cung cấp chất lượng dịch vụ trong một mạng.

Phần III của tiểu luận, chúng em đã đánh giá và phân tích ưu nhược điểm của các cơ

chế cung cấp chất lượng dịch vụ. Từ đó đề xuất ra phương án kết hợp 2 mô hình để nâng cao

chất lượng dịch vụ.

48


Tài liệu tham khảo

[1]. “ An Architecture for Differentiated Services” RFC 2475 December 1998

[2]. “ Integrated Services in the Internet Architecture: an Overview”

RFC 1633 June 1994

[2]. “ The Use of RSVP with IETF Integrated Services “ RFC 2210 September 1997

[4] .” Multiprotocol Label Switching Architecture “ RFC 3031 January 2001

49

Documents

76425396 Tieu Luan Chat Luong DV Tren Mang IP Cuong Thanh