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

Các phương pháp nâng cao chất lượng dịch vụ trên mạng IP 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

Trang 1

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

-

1 Mục lục Mục lục 1

Lời nói đầu 3

PHẦN I 4

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

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

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

I.2.1 Trễ 6

I.2.2 Thông lượng 7

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

PHẦN 2 9

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

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

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

II.1.2 Giao thức RSVP 13

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bảo mật

Trang 2

-

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

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

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

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

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

II.2.5.1 Ưu điểm 43

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

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

II.3.1 Giới thiệu 44

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

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

II.3.2.2 Forwarding Equivalent Class 47

II.3.2.3 Label Distribute Protocol 48

II.3.3 Traffic Engineering với MPLS 48

II.3.3.1 Giới thiệu chung 48

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

II.3.4 Kết luận 51

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

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

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

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

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

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

III.3.1.2 Framework cho Intserv/RSVP over Diffserv 55

III.3.1.3 Thực thi Framework 57

III.3.1.4 Kết luận 57

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

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

III.3.2.2 Nguyên tắc 58

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

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 60

III.3.2.5 Kết luận 60

Bảo mật

Trang 3

-

3

Kết luận 61 Tài liệu tham khảo 62

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:

Bảo mật

Trang 4

-

4

- 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

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 IP

Trê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)

IP applications

IP traffic

Real – time applications

Real – time traffic

Elastic applications

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

Bảo mật

Trang 5

-

5

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)

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

Các thẻ bài đi đến với

tốc độ không đổi r

Bảo mật

Trang 6

-

6

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

Bảo mật

Trang 7

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

Trang 8

-

8

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ý

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 IP

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

Bảo mật

Trang 9

-

9

 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

 Integrated Services – IntServ

 Differentiated Services – DiffServ

 Multiprotocol Label Switching

 Traffic Engineering

Bảo mật

Trang 10

-

10

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

Bảo mật

Trang 11

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

Bảo mật

Trang 12

-

12

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

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

Bảo mật

Trang 13

-

13

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

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

Bảo mật

Trang 14

-

14

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

Trang 15

-

15

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

Bảo mật

Trang 16

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 :

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

Bảo mật

Trang 17

-

17

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

Trang 18

-

18

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

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)

Bảo mật

Trang 19

-

19

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

Bảo mật

Trang 20

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

Trang 21

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

Bảo mật

Trang 22

-

22

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ẻ

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

Bảo mật

Trang 23

-

23

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

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

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ủ

Bảo mật

Trang 24

-

24

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)

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

Bảo mật

Trang 25

-

25

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

Lớp dịch vụ

nguồn

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

Mô tả luồng

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

Filter Spec

Hình 10 Quan hệ giữa thông tin RSVP và việc xử

lý gói trong bộ định tuyến

Bảo mật

Trang 26

-

26

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

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

Lập lịch / xử lý gói Phâ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

Bộ định tuyến

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

Bảo mật

Trang 27

-

27

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

Bảo mật

Trang 28

-

28

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ế

Bảo mật

Trang 29

-

29

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ữ

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ữ

Trang 30

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)

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

Bảo mật

Trang 31

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

Bảo mật

Định dạng
Số trang	63
Dung lượng	605,57 KB