Đề tài: Tổng quan, kỹ thuật đảm bảo chất lượng dịch vụ QoS IP và mô hình ứng dụng đảm bảo QoS IP
MỤC LỤC
LỜI NÓI ĐẦU
CHƯƠNG 1. TỔNG QUAN VỀ CHẤT LƯỢNG DỊCH VỤ QOS
1.1. CHẤT LƯỢNG DỊCH VỤ QoS VÀ CÁC THAM SỐ QoS
1.1.1. Các vấn đề chung của chất lượng dịch vụ QoS
1.1.2. Cấp độ dịch vụ GoS (Grade of Service)
1.1.3. Kiểu dịch vụ ToS và lớp dịch vụ CoS
1.1.4. Các tham số chất lượng dịch vụ
1.2 CÁC YÊU CẦU CHẤT LƯỢNG DỊCH VỤ
1.3. CÁC VẤN ĐỀ ĐỂ ĐẢM BẢO QoS
1.3.1 Cung cấp QoS
1.3.2 Điều khiển QoS
1.3.3 Quản lý QoS
CHƯƠNG 2. KỸ THUẬT ĐẢM BẢO CHẤT LƯỢNG DỊCH VỤ IP
2.1. GIỚI THIỆU TỔNG QUAN VỀ QOS IP
2.1.1 Lịch sử phát triển các mô hình QoS cho mạng IP
2.1.2. Các tham số chất lượng dịch vụ IP
2.1.3. Một số tham số cơ bản ảnh hưởng tới QoS IP thực tế
2.2. CÁC YÊU CẦU CHỨC NĂNG CHUNG CỦA IP QOS
2.3. CÁC KỸ THUẬT ĐẢM BẢO CHẤT LƯỢNG DỊCH VỤ IP
2.3.1. Kỹ thuật đo lưu lượng và màu hoá lưu lượng
2.3.2. Kỹ thuật quản lý hàng đợi tích cực
2.3.3. Kỹ thuật lập lịch cho gói tin
2.3.4. Kỹ thuật chia cắt lưu lượng
CHƯƠNG 3. MÔ HÌNH ỨNG DỤNG ĐẢM BẢO QoS IP
3.1. MÔ HÌNH TÍCH HỢP DỊCH VỤ INTSERV
3.1.1. Các yêu cầu chức năng chung của IntServ
3.1.2 . Giao thức dành trước tài nguyên RSVP
3.2. MÔ HÌNH PHÂN BIỆT DỊCH VỤ DIFFSERV
3.2.1. Tổng quan về kiến trúc DiffServ
3.2.2. Miền phân biệt dịch vụ DS và điểm mã phân biệt dịch vụ DSCP
3.2.3. Các phương pháp xử lý gói trong DiffServ
3.3. IP QoS VÀ CHUYỂN MẠCH NHÃN ĐA GIAO THỨC MPLS
KẾT LUẬN
TÀI LIỆU THAM KHẢO
61 trang |
Chia sẻ: lvcdongnoi | Lượt xem: 3641 | Lượt tải: 1
Bạn đang xem trước 20 trang tài liệu Tổng quan, kỹ thuật đảm bảo chất lượng dịch vụ QoS IP và mô hình ứng dụng đảm bảo QoS IP, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
trong bộ định tuyến được trình bày trong mục này gồm có: Hàng đợi FIFO; Hàng đợi ưu tiên PQ; hàng đợi công bằng FQ; hàng đợi quay vòng trọng số WRR; hàng đợi công bằng trọng số WFQ và hàng đợi dựa theo lớp công bằng trọng số CBQ.
(i) Hàng đợi FIFO
Hàng đợi vào trước – ra trước FIFO là kỹ thuật hàng đợi ngầm định, các gói tin đến được đưa vào trong một hàng đợi đơn và được gửi ra đầu ra theo đúng thứ tự. FIFO là kiểu hàng đợi đơn giản nhất không cần sử dụng thuật toán điều khiển. FIFO đối xử với tất cả các gói theo cùng một cách, vì vậy nó rất thích hợp với mạng nỗ lực tối đa. Mặt khác FIFO không thể cung cấp các dịch vụ phân biệt và tất cả các luồng lưu lượng đều bị suy giảm chất lượng khi có tắc nghẽn xảy ra.
(ii) Hàng đợi ưu tiên PQ
Hàng đợi FIFO đặt tất cả các gói tin vào trong một hàng đợi đơn bất kể lớp lưu lượng nào. Một cách đơn giản để tạo ra sự phân biệt lớp lưu lượng là sử dụng hàng đợi ưu tiên PQ. Trong PQ, N hàng đợi được tạo ra như trong hình 2.19 với các mức ưu tiên từ 1 tới N. Thứ tự lập lịch được xác định bởi thứ tự ưu tiên và không phụ thuộc vào vị trí của gói tin. Các gói trong hàng đợi thứ j được xử lý khi không còn gói nào trong hàng đợi có thứ tự cao hơn (Các hàng đợi từ 1 tới (j-1)).
Hình 2.19: Hàng đợi ưu tiên PQ
Giống như FIFO, hàng đợi ưu tiên có ưu điểm là rất đơn giản: nó cung cấp phương tiện đơn giản nhất để phân biệt lớp lưu lượng. Nhược điểm của hàng đợi ưu tiên là PQ luôn hướng tới xử lý mức ưu tiên cao, nên các hàng đợi có mức ưu tiên thấp có thể không có cơ hội để gửi gói đi.
(iii) Hàng đợi công bằng FQ
Hàng đợi công bằng còn được gọi là hàng đợi dựa trên luồng lưu lượng, trong FQ các gói tin đến được phân loại thành N hàng đợi. Mỗi một hàng đợi nhận 1/N băng thông đầu ra. Bộ lập lịch kiểm tra các hàng đợi theo chu kỳ và bỏ qua các hàng đợi rỗng. Mỗi khi bộ lập lịch tới một hàng đợi, một gói tin được truyền ra khỏi hàng đợi.
Hàng đợi công bằng rất đơn giản, nó không yêu cầu một kỹ thuật chỉ định băng thông phức tạp nào. Nếu một hàng đợi mới được thêm vào N hàng đợi có trước đó, bộ lập lịch tự động đặt lại băng thông theo thực tế bằng 1/(N+1). Đơn giản chính là ưu điểm của hàng đợi công bằng.
Hình 2.20: Hàng đợi công bằng FQ
Hàng đợi công bằng có hai nhược điểm chính. Đầu tiên, khi băng thông đầu ra được chia thành N hàng đợi 1/N, nếu các lớp lưu lượng đầu vào có yêu cầu băng thông khác nhau, thì FQ không thể phân bố lại được băng thông của đầu ra để đáp ứng yêu cầu đầu vào. Thứ hai, khi kích thước gói không được quan tâm trong FQ, kích thước các gói sẽ ảnh hưởng đến phân bố băng thông thực tế, thậm chí bộ lập lịch vẫn hoạt động đúng trên cơ sở công bằng, các hàng đợi có gói kích thước lớn sẽ chiếm nhiều băng thông hơn các hàng đợi khác.
(iv) Hàng đợi quay vòng theo trọng số (WRR)
Hàng đợi quay vòng theo trọng số WRR được đưa ra nhằm giải quyết hai nhược điểm của hàng đợi công bằng FQ. WRR chia băng thông cổng đầu ra với các lớp lưu lượng đầu vào phù hợp với băng thông yêu cầu. Nguyên lý hoạt động của WRR được chỉ ra trên hình 2.21. Các luồng lưu lượng đầu vào được nhóm thành m lớp tương ứng với trọng số được xác định bởi băng thông yêu cầu. Tổng các trọng số của các lớp bằng 100%.
(ct 2.4)
Trong đó: m là số lớp lưu lượng, Wi là % trọng số của lớp i.
Với mỗi một lớp, các luồng lưu lượng riêng được lập lịch theo nguyên tắc hàng đợi công bằng FQ. Đặt số lượng các hàng đợi FQ trong lớp i là Ni, tổng số hàng đợi FQ trong lược đồ WRR được tính theo công thức 2.5 sau đây :
(ct 2.5)
Như chỉ ra trên hình 2.21, hàng đợi quay vòng theo trọng số WRR gồm hai lớp lập lịch quay vòng.
Bộ lập lịch quay vòng chỉ tới các lớp trong khoảng từ lớp 1 đến lớp m, đây được coi là lớp lập lịch thứ nhất.
Khi bộ lập lịch dừng lại tại một lớp, bộ lập lịch quay vòng thứ hai sẽ quay vòng trong các hàng đợi FQ.
Băng thông cổng đầu ra tính theo % được gán vào lớp i, trọng số của lớp i (Wi) thể hiện lượng thời gian tiêu tốn của bộ lập lịch cho lớp i. Ví dụ, Wi=20% có nghĩa là bộ lập lịch sẽ tiêu tốn 20% chu kỳ thời gian quay vòng cho lớp i. Với các hàng đợi FQ trong lớp i, thời gian cho các hàng đợi là công bằng, vì vậy lượng thời gian cho một hàng đợi trong Ni hàng đợi là (1/Ni). Trọng số cho mỗi một hàng đợi FQ được tính như sau:
Wij = Wi x (1/Ni) (ct 2.6)
Trong đó : Wij là trọng số của hàng đợi thứ j trong lớp i; Wi là trọng số lớp i.
Hình 2.21: Hàng đợi quay vòng theo trọng số WRR
Theo công thức 2.6 ta có thể viết lại thành Wi = Wij x Ni hay:
(ct 2.7)
Trọng số của lớp i sẽ được tính bằng tổng các yêu cầu lưu lượng trong lớp i. WRR sử dụng Wi thay cho 1/m như trong trường hợp FQ, tạo ra m lớp lưu lượng khác nhau tại các cổng đầu ra. Đây chính là cải thiện của WRR so với FQ nhằm tránh nhược điểm đầu của FQ.
(iv) Hàng đợi công bằng trọng số (WFQ) và Hàng đợi công bằng trọng số phân lớp CB-WFQ.
Mặc dù WRR đã chỉ ra được cách khắc phục nhược điểm thứ nhất của hàng đợi công bằng FQm nhưng WRR chưa giải quyết được ảnh hưởng của kích thước gói tin đối với băng thông chia sẻ. Tiếp cận hàng đợi công bằng trọng số WFQ cũng nhằm cải thiện nhược điểm thứ hai của hàng đợi FQ. Giống như hàng đợi FQ, lưu lượng đầu vào được nhóm m hàng đợi. Tuy nhiên, băng thông cổng đầu ra được phân bổ tới m hàng đợi theo trọng số được xác định bởi các yêu cầu băng thông của lớp lưu lượng thay vì chia đều.
Hàng đợi công bằng trọng số phân lớp CB-WFQ tương tự như hàng đợi quay vòng theo trọng số WRR, sự khác biệt cơ bản của CB-WFQ so với WRR là cách sử dụng cơ chế công bằng theo trọng số tại các lớp i thay vì sử dụng cơ chế hàng đợi công bằng. Tiếp cận này theo hướng mềm hoá hơn nữa đối với các yêu cầu băng thông không đồng nhất.
2.3.4 Kỹ thuật chia cắt lưu lượng
Kỹ thuật chia cắt lưu lượng gồm hai kiểu: Chia cắt lưu lượng thuần và chia cắt lưu lượng kiểu gáo rò.
(i) Chia cắt lưu lượng thuần
Hình 2.22 dưới đây chỉ ra nguyên lý chia cắt lưu lượng thuần. Các gói tin đến được đưa vào bộ đệm (gáo rò) có độ sâu d, sau đó được gửi ra liên kết đầu ra tại tốc độ hằng số, tốc độ hằng số này được gọi là tốc độ rò r.
Hình 2.22: Chia cắt lưu lượng thuần
Chia cắt lưu lượng thuần không cho phép bùng nổ băng thông trên các liên kết đầu ra. Thông thường, tốc độ rò r luôn nhỏ hơn tốc độ liên kết C (r<C). Tuy nhiên, với chia cắt lưu lượng thuần, tốc độ rò r được đặt tại tốc độ lớn nhất của tốc độ đầu ra vì không cho phép bùng nổ lưu lượng. Nếu kích thước gói bùng nổ quá độ sâu của gáo rò d thì các gói sẽ bị loại bỏ.
(ii) Chia cắt lưu lượng kiểu gáo rò
Hình 2.23 chỉ ra nguyên lý chia cắt lưu lượng gáo rò, gáo rò token được sử dụng trong mô hình này tương tự như gáo rò C sử dụng trong srTCM và trTCM. Các token được đưa vào gáo rò với tốc độ bằng hằng số, được gọi là tốc độ token r. Tốc độ token tương tự với tốc độ thông tin cam kết CIR. Độ sâu của gáo rò d thể hiện kích thước bùng nổ cam kết CBS. Nếu gáo rò đầy, không một token nào có thể được đưa vào gáo.
Mỗi một token cho phép bộ đệm lưu lượng đầu vào gửi ra một byte dữ liệu. Khi không còn gói nào trong bộ đệm gửi ra, đáy của gáo rò đóng lại và không một token nào được lấy ra. Khi vẫn có các gói tin trong bộ đệm, các token được rút ra theo tốc độ liên kết đầu ra (C) và các gói được chuyển tới đầu ra. Nếu gáo rò xả hết các token, các gói trong bộ đệm phải đợi cho đến khi các token được đưa vào gáo rò.
Hình 2.23: Chia cắt lưu lượng bùng nổ kiểu gáo rò
Kết quả của hoạt động này là các gói được chuyển tới liên kết đầu ra tại tốc độ liên kết C. Kích thước bùng nổ được giới hạn bởi độ sâu của gáo d .Khi các token được đưa vào trong gáo rò tại tốc độ r, thì tốc độ trung bình dài hạn của các gói tại đầu ra sẽ là r. Vì vậy, kỹ thuật chia cắt lưu lượng gáo rò hoạt động giống hệt gáo rò C trong srTCM và trTCM, ngoại trừ gáo rò token được áp dụng tại đầu ra trong khi gáo rò C được áp dụng tại đầu vào.
Tóm tắt chương 2:
Chương 2 tập trung vào các giải pháp kỹ thuật nhằm đảm bảo chất lượng dịch vụ IP. Từ các đặc điểm cơ bản của chất lượng dịch vụ IP, các yêu cầu QoS IP đã được thể hiện qua mô hình bộ định tuyến dưới khía cạnh khối chức năng cơ bản. Các giải pháp kỹ thuật như phân lớp dịch vụ, chính sách loại bỏ gói, lập lịch và chia cắt lưu lượng được trình bày dựa trên mô hình chức năng bộ định tuyến IP.
CHƯƠNG 3
MÔ HÌNH ỨNG DỤNG ĐẢM BẢO QoS IP
Chương này sẽ giới thiệu hai mô hình ứng dụng đảm bảo QoS IP: Mô hình tích hợp dịch vụ IntServ và mô hình phân biệt dịch vụ DiffServ. Các kỹ thuật trình bày trong chương 3 sẽ được thảo luận chi tiết hơn trong từng mô hình.
MÔ HÌNH TÍCH HỢP DỊCH VỤ INTSERV
3.1.1 Các yêu cầu chức năng chung của IntServ.
Mô hình dịch vụ tích hợp IntServ đề xuất hai lớp dịch vụ bổ sung cho các dịch vụ IP truyền thống gồm:
Dịch vụ bảo đảm GS cho ứng dụng yêu cầu giới hạn trễ và băng thông.
Dịch vụ điều khiển tải CL cho ứng dụng yêu cầu độ tổn thất gói thấp.
Ý tưởng ban đầu của các dịch vụ tích hợp là để hỗ trợ việc dành trước tài nguyên cho các luồng lưu lượng. Trái ngược với kiến trúc chuyển phát datagram (các gói sẽ đi qua các tuyến khác nhau tại mọi thời điểm chúng được gửi), dịch vụ tích hợp cho phép dành toàn bộ một tuyến cho luồng dữ liệu. Điều đó được thực hiện bởi việc thiết lập một tuyến dành trước tài nguyên trước khi gửi dữ liệu. Thực chất của mô hình này là các bộ định tuyến và thiết bị mạng phải dành trước nguồn tài nguyên của nó để cung cấp các mức chất lượng dịch vụ cụ thể cho các gói mang lưu lượng người dùng. Điều này yêu cầu các bộ định tuyến phải có khả năng điều khiển các luồng lưu lượng.
Hình 3.1: Mô hình tích hợp dịch vụ Intserv
Cả hai lớp dịch vụ đảm bảo và dịch vụ điều khiển tải phải được cài đặt các đường dẫn và dự trữ các tài nguyên trước khi truyền dữ liệu của họ. Sự điều khiển định tuyến sẽ quyết định cho việc có cấp nguồn cho yêu cầu hay không. Khi bộ định tuyến nhận được gói, bộ phân lớp sẽ thực hiện sự phân lớp đa trường và đưa gói vào hàng đợi đặc biệt dựa trên kết quả của sự phân lớp. Cấu hình gói sau đó sẽ lên lịch trình cho gói để đạt được yêu cầu chất lượng dịch vụ của nó.
Ứng dụng sẽ mô tả lưu lượng và tài nguyên nào mà nó sẽ cần. Sau đó, mạng sẽ sử dụng giao thức dành trước tài nguyên (RSVP) để dành trước băng thông xác định trong mỗi bộ định tuyến dọc theo đường đi. Mỗi bộ định tuyến sẽ kiểm tra xem ở đó nó có đảm bảo tài nguyên được yêu cầu và duy trì tuyến khi được yêu cầu bởi yêu cầu dành trước tài nguyên. Khi tất cả các bước nhảy đã được thiết lập, thiết bị gửi có thể gửi dữ liệu.
Mô hình tích hợp dịch vụ IntServ mô tả các ứng dụng QoS trong mạng IP theo phương pháp nhận dạng luồng lưu lượng với 5 tham số cơ bản sau:
Nhận dạng giao thức
Địa chỉ IP đích
Địa chỉ cổng đích
Địa chỉ IP nguồn
Địa chỉ cổng nguồn
Để dự trữ tài nguyên cho một luồng lưu lượng, ứng dụng nguồn cần phải cung cấp các đặc tính luồng. Đặc tính luồng gồm các đặc tính lưu lượng và các yêu cầu chất lượng dịch vụ cho luồng đó.
Đặc tính lưu lượng bao gồm tốc độ đỉnh, tốc độ trung bình, kích thước bùng nổ và các tham số của gáo rò.
Các yêu cầu dịch vụ gồm băng thông tối thiểu và các yêu cầu hiệu năng như trễ, biến động trễ và tỷ lệ tổn thất gói.
Các dịch vụ tích hợp có thể được chia thành hai mặt bằng: mặt bằng điều khiển và mặt bằng dữ liệu.
Mặt bằng điều khiển thiết lập việc dành trước tài nguyên.
Mặt bằng dữ liệu thực hiện truyền dữ liệu.
Để yêu cầu một dành trước tài nguyên IntServ, trước tiên ứng dụng phải đặc tính hoá được luồng lưu lượng của nó và tập hợp lại trong chỉ tiêu luồng lưu lượng. Sau đó, yêu cầu thiết lập dự trữ tài nguyên có thể được gửi đến mạng. Nếu có thể cam kết việc dự phòng, luồng đó được đưa vào bảng dự phòng tài nguyên. Khi gói tin đến, khối lượng nhận dạng luồng sẽ nhận dạng gói tin thuộc về luồng đặt trước và đặt chúng vào trong hàng đợi phù hợp để nhận được dịch vụ yêu cầu.
Việc lựa chọn đường dẫn phù hợp cho chặng kế tiếp tại một nút là một nhiệm vụ khó khăn do các hạn chế trong việc định tuyến IP truyền thống. Đường dẫn cần được lựa chọn có thể đã đáp ứng được yêu cầu định ra. Tuy nhiên, định tuyến IP thường sử dụng các số đo như trễ, bước nhảy hay một số loại thông số khác để tính toán đường đi ngắn nhất. Do vậy, đường dẫn ngắn nhất có thể không có được khả năng truyền tải, mặc dù đường dẫn khác dài hơn lại có được khả năng đó. Vấn đề định tuyến có thể trở nên phức tạp hơn bởi một số ứng dụng có yêu cầu nhiều tham số QoS (ví dụ, cả băng thông và các yêu cầu về tổn thất gói tin). Tìm kiếm đường dẫn phù hợp trong nhiều điều kiện ràng buộc rất phức tạp. Chính vì lý do đó, mô hình đảm bảo QoS cho IP đầu tiên này không yêu cầu gắn các cơ chế định tuyến đảm bảo QoS trong kiến trúc InterServ. Kiến trúc này giả sử rằng khối chức năng định tuyến của bộ định tuyến sẽ thực hiện định tuyến từng bước (hop by hop).
Tài nguyên dành trước trong InterServ cần phải qua tất cả các nút trên đường dẫn và thiết lập các dự phòng yêu cầu. Nó cũng phải truyền tải thông tin trong các phác thảo lưu lượng và các yêu cầu tài nguyên, do vậy mỗi nút cần quyết định liệu nó có chấp nhận việc dành trước hay không, nhận dạng luồng như thế nào và lập lịch cho gói tin.
Điều khiển chấp nhận
Xử lý hai nhiệm vụ cơ bản là: Chấp nhận hay từ chối các yêu cầu dành trước và giám sát việc sử dụng tài nguyên. Việc dành trước tài nguyên cho một yêu cầu mới không thể được chấp nhận nếu nút không có sẵn tài nguyên yêu cầu. Có hai hướng tiếp cận để quyết định tài nguyên nào là sẵn sàng: Dựa trên đo đạc và dựa theo tham số.
Trong hướng tiếp cận theo tham số, điều khiển chấp nhận sẽ tính toán các tài nguyên khả dụng dựa trên các chỉ tiêu kỹ thuật của yêu cầu dành trước tài nguyên hiện tại.
Trong hướng tiếp cận dựa theo đo đạc, điều khiển chấp nhận đo lưu lượng thực sự trong mạng và sử dụng các phương pháp thống kê để quyết định xem liệu tài nguyên nào là khả dụng. Hướng tiếp cận này có ưu điểm là tối ưu hoá việc sử dụng mạng, mặc dù nó không thể đảm bảo chặt chẽ các cam kết tài nguyên.
Nhận dạng luồng
RSVP Sử dụng 5 trường trong tiêu đề gói tin IP để nhận dạng các gói tin thuộc về các luồng dành trước tài nguyên trong nút. Các trường này bao gồm: địa chỉ IP nguồn, địa chỉ IP đích, nhận diện giao thức, cổng nguồn và cổng đích.
Lập lịch gói tin
Là bước cuối cùng trong việc dành trước tài nguyên. Bộ lập lịch gói tin thực hiện việc cấp pháp tài nguyên. Nó quyết định gói tin nào gửi kế tiếp khi tuyến kết nối đi là sẵn sàng. Do đó nó tác động đến trễ mà gói tin đó phải chịu trong bộ định tuyến và bộ định tuyến không trực tiếp loại bỏ gói tin.
3.1.2 Giao thức dành trước tài nguyên RSVP
(i) Giới thiệu chung
Giao thức dành trước tài nguyên RSVP là một giao thức thiết lập tài nguyên dự phòng QoS IP, RSVP hỗ trợ cả IPv4 và IPv6 cũng như ứng dụng cho cả hai phương thức chuyển phát tin đơn hướng và đa hướng (Unicast và multicast).
Trong giao thức dành trước tài nguyên RSVP, các nguồn tài nguyên được dành trước theo các hướng độc lập. Máy chủ nguồn và máy chủ đích trao đổi các bản tin RSVP để thiết lập các trạng thái chuyển tiếp và phân loại gói tại mỗi nút.
RSVP không phải là giao thức định tuyến mà là giao thức báo hiệu, các bản tin RSVP được chuyển đi trên cùng đường dẫn với các gói tin sẽ được chuyển và được xác định bởi bảng định tuyến trong bộ định tuyến IP.Các máy chủ sử dụng giao thức RSVP để yêu cầu QoS của mạng cho các luồng lưu lượng thực tế. Các bộ định tuyến sử dụng RSVP để tạo ra các yêu cầu QoS cho toàn bộ các bộ định tuyến dọc theo tuyến đường gói tin chuyển qua mạng. Giao thức RSVP cũng sử dụng để duy trì và làm tươi trạng thái cho luồng ứng dụng yêu cầu QoS.
Một số đặc tính cơ bản của giao thức dành trước tài nguyên RSVP được liệt kê dưới đây:
RSVP là giao thức báo hiệu để dành trước tài nguyên trong đường dẫn từ nguồn tới đích.
RSVP báo hiệu tới tất cả các thiết bị mạng về yêu cầu QoS của ứng dụng.
RSVP yêu cầu các ứng dụng khởi tạo yêu cầu.
RSVP hoạt động liên điều hành với các kỹ thuật QoS khác để cải thiện độ đảm bảo cho các tài nguyên dành trước.
Giao thức dành trước tài nguyên RSVP thường được sử dụng cho các ứng dụng yêu cầu đảm bảo các tham số băng thông và độ trễ. Các ứng dụng mạng hiện nay sử dụng RSVP như là giao thức báo hiệu gồm các ứng dụng cho VoIP và kỹ thuật lưu lượng MPLS (Multiprotocol Label Switching).
RSVP được phát triển để chống lại tắc nghẽn mạng bằng cách cho phép các bộ định tuyến được quyết định ở mức cao. Tại mức này các bộ định tuyến có thể đáp ứng các yêu cầu của một luồng ứng dụng và dự trữ tài nguyên mong muốn ngay cả khi mặt bằng chuyển tiếp gói không xử lý được. Mô hình báo hiệu RSVP được dựa trên xử lý đặc biệt kiểu đa phương, mang bản tin báo hiệu tới các nút dọc tuyến đường qua mạng theo luồng thực tế, quản lý trạng thái mềm, trao đổi bản tin, dự phòng tài nguyên và tách báo hiệu QoS khỏi chức năng định tuyến.
(ii) Hoạt động của RSVP
Một phiên làm việc của giao thức dành trước tài nguyên RSVP thường sử dụng 3 tham số sau:
Địa chỉ đích
Nhận dạng giao thức
Địa chỉ cổng đích
Hình 3.2 dưới đây chỉ ra nguyên lý hoạt động của RSVP. Máy chủ nguồn gửi bản tin Path tới đích cho một luồng dữ liệu hay còn gọi là một phiên truyền thông. Bản tin Path chứa các đặc tính cho luồng dữ liệu sẽ được gửi, bản tin Path đi qua các bộ định tuyến trên đường dẫn tới đích. Các bộ định tuyến trên tuyến đăng ký nhận dạng luồng và các đặc tính luồng vào cơ sở dữ liệu. Bản tin Resv được phát ngược từ máy chủ nhận về máy chủ gửi nhằm xác nhận và chỉnh sửa các thông tin yêu cầu đã được gửi đi trong bản tin Path, đây là các thông tin về dự phòng tài nguyên cho đường dẫn mà gói tin sẽ được chuyển qua.
Hình 3.2: Nguyên lý hoạt động của RSVP
RSVP giữ trạng thái mềm các tài nguyên trong các bộ định tuyến. Trạng thái mềm này được cung cấp động theo các thông tin từ các thành viên trong phiên làm việc, tương thích với sự thay đổi định tuyến và các yêu cầu thay đổi tài nguyên của các luồng lưu lượng trong phiên. Thời gian làm tươi định kỳ thông thường là 30s.
(iii) Các kiểu dành trước tài nguyên của RSVP
Trong RFC 2205 [6] định nghĩa 3 kiểu dự phòng tài nguyên (minh hoạ trên hình 3.3). Hai kiểu điều khiển máy gửi được định nghĩa:
Kiểu lựa chọn hiện
Kiểu lựa chọn wildcard.
Kiểu lựa chọn tuyến hiện liệt kê toàn bộ các máy gửi, trong khi đó kiểu wildcard chỉ liệt kê toàn bộ máy chủ trong phiên.
Hình 3.3: Các kiểu dành trước tài nguyên
Điều khiển chia sẻ lưu lượng thực hiện điều khiển các ứng xử tài nguyên dành trước cho các máy gửi khác nhau trong cùng một phiên. Hai kiểu điều khiển chia sẻ lưu lượng được định nghĩa là:
Kiểu dành trước tài nguyên riêng biệt.
Kiểu dành trước tài nguyên chia sẻ.
Trong kiểu dành trước tài nguyên riêng biệt, tài nguyên dành được tạo ra cho từng máy gửi. Trong kiểu dành trước tài nguyên chia sẻ, một tài nguyên chung được chia sẻ bởi các máy gửi trong phiên.
Như chỉ ra trên hình 3.3 có 4 khả năng được tổ hợp từ các cách thức điều khiển chia sẻ tài nguyên và lựa chọn máy gửi. Tuy nhiên, một kiểu không được định nghĩa và ta còn 3 kiểu dành trước tài nguyên là: Kiểu bộ lọc cố định FF (Fixed Filter), Kiểu chia sẻ hiện SE (Shared Explicit) và kiểu bộ lọc Wildcard WF (Wildcard - Filter).
(iv) Các dạng bản tin của RSVP
Khuôn dạng bản tin RSVP có cấu trúc gồm một tiêu đề chung và các trường chức năng thể hiện các đối tượng như chỉ ra trên hình 3.4 (a). Mỗi một đối tượng được cấu trúc bởi tiêu đề đối tượng và nội dung đối tượng.
Khuôn dạng tiêu đề chung được chỉ ra trên hình 3.4 (b) có tổng độ dài là 8 bytes. Nó gồm 4 bit cho số hiệu phiên bản RSVP, 4 bit cờ, 8 bit sử dụng cho kiểu bản tin RSVP; 16 bit tổng kiểm tra, 8 bit sử dụng cho thời gian sống TTL của gói tin IP, 8 bit dự phòng và trường hiện thị độ dài bản tin gồm 16 bit.
Hình 3.4: Khuôn dạng bản tin RSVP và tiêu đề chung RSVP
Nếu trường tổng kiểm tra độ dài chứa toàn bộ giá trị 0, điều đó thể hiện không cần kiểm tra các dữ liệu truyền đi. Độ dài bản tin RSVP bao gồm cả tiêu đề và các đối tượng trong bản tin. RSVP định nghĩa các kiểu bản tin sắp xếp theo thứ tự kiểu bản tin:
Path - Sử dụng để yêu cầu tài nguyên dành trước.
Resv - Gửi đáp ứng bản tin đường để thiết lập và duy trì dự trữ tài nguyên.
PathTear - Sử dụng để xoá dự trữ tài nguyên khỏi mạng theo hướng đi.
ResvTear - Sử dụng để xoá bỏ tài nguyên khỏi mạng theo hướng về.
PathErr – Thông báo lỗi bản tin Path.
ResvErr - Thông báo lỗi bản tin Resv .
ResvConf – Là một bản tin tuỳ chọn, gửi ngược lại tới phía gửi của bản tin Resv để xác nhận rằng tài nguyên dự trữ xác định thực sự đã được cài đặt.
ResvTearConf - Sử dụng để xác nhận dự trữ tài nguyên xác định đã bị xoá khỏi mạng.
Khuôn dạng đối tượng RSVP được chỉ ra trên hình 3.5 dưới đây gồm 32 bit tiêu đề đối tượng và các nội dung đối tượng có độ dài thay đổỉ. Một đối tượng độ dài có 32 bit định nghĩa độ dài tối đa cho phép của đối tượng RSVP là 65,528 byte. Các đối tượng RSVP được tổ chức thành lớp đối tượng và kiểu đối tượng.
Hình 3.5: Khuôn dạng bản tin đối tượng RSVP
Trường chức năng “Class Num” định nghĩa lớp đối tượng và trường chức năng “C Type” định nghĩa đối tượng trong lớp. Các trường chức năng này tổ chức thành một cặp để mô tả các đối tượng trong RSVP. Các lớp đối tượng sau được định nghĩa trong RFC 2205.
NULL - Mô tả trạng thái của phiên.
SESSION – Mô tả phiên.
RSVP_HOP - Thể hiện các bước nhảy của bản tin RSVP.
TIME_VALUE – Mô tả giá trị thời gian chuyển tin.
STYLE – Mô tả kiểu bản tin.
FLOWSPEC – Mô tả đặc tính luồng.
FILTER_SPEC – Mô tả đặc tính bộ lọc.
SENDER_TEMPLATE - Mô tả khuôn dạng gói của đối tượng gửi.
Đối tượng FLOWSPEC chứa các tham số điều khiển lưu lượng gồm: tốc độ gáo rò token; kích thước gáo rò token, tốc độ đỉnh , v..v.
Đối tượng kiểu bản tin (STYLE) được đặt trong “Class num=8”, lớp này chỉ có một đối tượng với C type -1. Đối tượng kiểu định nghĩa các kiểu dành trước tài nguyên.
Hình 3.6: Khuôn dạng đối tượng kiểu
XX bit
Điều khiển chia sẻ
00
01
10
11
Dự phòng
Tài nguyên phân biệt
Tài nguyên chia sẻ
Dự phòng
Bảng 3.1: Các bit sử dụng cho điều khiển chia sẻ
YYY bit
Điều khiển lựa chọn máy gửi
000
001
010
011-111
Dự phòng
Lựa chọn Wildcard
Lựa chọn hiện
Dự phòng
Bảng 3.2: Các bit sử dụng cho điều khiển lựa chọn máy gửi
Hình 3.6 trên đây chỉ ra khuôn dạng của đối tượng kiểu. kiểu dành trước tài nguyên được định nghĩa bởi 5 bit cuối cùng. Trong đó, 2 bit đầu định nghĩa kiểu điều khiển chia sẻ tài nguyên và 3 bit điều khiển lựa chọn máy gửi. Ý nghĩa của các bit được thể hiện trong bảng 3.1 và bảng 3.2.
Hình 3.7: Cấu trúc bản tin Path và Resv trong RSVP
Bản tin Path mô tả thông tin phiên truyền thông qua địa chỉ IP nguồn và địa chỉ IP đích, cùng với một số đặc tính của đường đi được phản ánh trong các đối tượng RSVP_HOP và TIME_VALUE. Khuôn dạng của gói tin sẽ được chuyển đi tương thích với các kiểu lọc được mô tả trong đối tượng SENDER_TEMPLATE, các đặc tính luồng của các ứng dụng từ máy gửi được mô tả trong đối tượng SENDER_TSPEC. Cấu trúc bản tin Path được trình bày trên hình 3.7 (a).
Trên hình 3.7 (b) mô tả cấu trúc chung của bản tin Resv, các đối tượng của bản tin Resv nhằm xác nhận và sửa đổi một số yêu cầu của bản tin Path cho phù hợp với hiện trạng thực tế của mạng.
MÔ HÌNH PHÂN BIỆT DỊCH VỤ DIFFSERV
3.2.1 Tổng quan về kiến trúc DiffServ.
Kiến trúc mô hình phân biệt dịch vụ DiffServ được coi là bước phát triển tiếp theo của mô hình tích hợp dịch vụ IntServ. Một vấn đề lớn nhất còn tồn tại của IntServ là các nguồn tài nguyên cần phải được duy trì trạng thái thông tin theo từng luồng. Với các mạng có số lượng dịch vụ và số lượng thiết bị mạng lớn, vấn đề này trở nên khó khả thi đối với các bộ định tuyến lõi cần phải xử lý lưu lượng rất lớn trong mạng. Tiếp cận của mô hình phân biệt dịch vụ DiffServ là không xử lý theo từng luồng lưu lượng riêng biệt mà ghép chúng vào một số lượng hạn chế các lớp lưu lượng. Trong DiffServ, băng thông và các tài nguyên mạng khác được chỉ định trong các lớp lưu lượng. Mặt khác, DiffServ hướng tới xử lý trong từng vùng dịch vụ phân biệt DS (Differential Service) thay vì xử lý từ đầu cuối tới đầu cuối như trong mô hình tích hợp dịch vụ IntServ.
DiffServ chỉ cung cấp quan hệ ứng xử phân biệt tới các lớp lưu lượng, vì vậy DiffServ không cung cấp mức QoS cụ thể. Để đảm bảo một số mức chất lượng dịch vụ QoS cụ thể, DiffServ được hỗ trợ với điều khiển quản lý tại biên vùng DS nhằm phối hợp điều khiển các luồng lưu lượng vào mạng. Chất lượng dịch vụ được cung cấp bởi mô hình phân biệt dịch vụ DiffServ theo hướng cung cấp thay vì theo hướng dành trước tài nguyên.
Thuật ngữ “DiffServ” mô tả tổng thể cách ứng xử của lưu lượng ứng dụng trong mạng cung cấp dịch vụ, nó định nghĩa dịch vụ mà người sử dụng mong nhận được từ phía nhà cung cấp dịch vụ. Dịch vụ DiffServ được định nghĩa trong các thoả thuận mức dịch vụ SLA của người sử dụng với nhà cung cấp dịch vụ DiffServ.
DiffServ định nghĩa một số tham số mà người sử dụng hiểu rõ cho ứng dụng của họ trong SLA như: Thoả thuận về điều kiện lưu lượng TCA (Traffic Conditioning Agreement), hồ sơ lưu lượng (các tham số của gáo rò token), các tham số hiệu năng (độ thông qua, độ trễ, mức tổn thất gói), cách thức xử lý các gói tin không phù hợp với thoả thuận, luật đánh dấu và chia cắt lưu lượng.
Hình 3.8: Mô hình các bước phân biệt dịch vụ DiffServ
Hình 3.8 trên đây chỉ ra các bước cơ bản liên quan tới vấn đề cung cấp các dịch vụ DiffServ. Các gói tin đến bộ định tuyến có thể đã được đánh dấu hoặc chưa đánh dấu, bộ định tuyến xác định điểm mã điều khiển dịch vụ DSCP của gói tin và phân loại các gói tin theo phương pháp phân loại hành vi kết hợp BA. Các gói tin phân loại thành các lớp BA được chuyển tiếp theo hành vi từng bước PHB (Per Hop Behavior) được định nghĩa trước cho các BA. Mỗi PHB được thể hiện bởi giá trị DSCP và xử lý giống nhau đối với các gói tin trong cùng lớp BA. Các yêu cầu chung của QoS đã được chỉ ra trong chương 2 của tài liệu này gồm chính sách lưu lượng, chia cắt lưu lượng, loại bỏ gói, hàng đợi tích cực và lập lịch gói được áp dụng tại bước này của mô hình phân biệt dịch vụ DiffServ.
Kiến trúc DiffServ hướng tới đảm bảo chất lượng dịch vụ QoS bằng cách kết hợp trạng thái phân loại lưu lượng theo tính chất lưu lượng được phân biệt qua các gói đánh dấu. Các gói được đánh dấu và nhận dạng để nhận được một ứng xử chuyển tiếp ở từng bước cụ thể trên các nút dọc theo đường truyền của chúng.
Hình 3.9: Xử lý gói trong mô hình DiffServ
Kiến trúc xử lý gói theo DiffServ gồm một số các yếu tố chức năng được thực hiện trong các nút mạng và bổ sung các phép ứng xử chuyển tiếp trên từng luồng cùng với các chức năng xử lý lưu lượng như: Chức năng phân loại gói, đánh dấu, định dạng và hoạch định chính sách. Kiến trúc này cho phép mở rộng mạng do thực hiện các chức năng phân lớp và điều khiển phức tạp ở các nút biên mạng
Sự cung cấp dịch vụ và chính sách qui định lưu lượng được tách riêng ra từ các cách ứng xử chuyển tiếp trong phạm vi nội mạng để cho phép thực hiện biến đổi rộng rãi các phép ứng xử.
3.2.2 Miền phân biệt dịch vụ DS và điểm mã phân biệt dịch vụ DSCP
Một miền DS gồm các bộ định tuyến hỗ trợ cơ chế phân biệt dịch vụ, còn gọi là các nút DS hoạt động với một chính sách cung cấp dịch vụ chung và thiết lập các nhóm PHB được thực hiện trên mỗi nút. Một miền DS có biên gồm các nút biên DS và các nút lõi trong miền. Các nút biên DS phân loại và điều khiển lưu lượng đầu vào để đảm bảo rằng các gói đi qua miền được đánh dấu thích hợp để lựa chọn một PHB từ một nhóm các PHB được hỗ trợ trong phạm vi miền. Các nút trong miền DS lựa chọn ứng xử chuyển tiếp cho các gói dựa trên điểm mã dịch vụ DSCP của chúng, sắp xếp vào một trong các PHB theo yêu cầu. Một miền DS thông thường gồm một hay nhiều mạng dưới cùng một chính sách quản trị. Việc quản trị một miền phải đảm bảo tin cậy để đảm bảo rằng các nguồn tài nguyên tương xứng được cung cấp và (hoặc) được dự trữ để hỗ trợ các SLA yêu cầu.
Hình 3.10: Miền phân biệt dịch vụ DS
Một vùng DS là một tập hợp một hay vài miền DS kế tiếp nhau. Các vùng DS có khả năng hỗ trợ các miền DS dọc theo đường dẫn nối các miền trong vùng. Các miền DS trong vùng DS có thể hỗ trợ nội bộ trong các nhóm PHB khác nhau và các điểm mã khác nhau để sắp xếp PHB. Tuy nhiên, để cho phép các dịch vụ nối ngang qua miền, các miền DS ngang hàng phải thiết lập mỗi miền một SLA ngang hàng chứa thoả thuận lưu lượng TCA phù hợp. Một vài miền DS trong một vùng DS có thể kế thừa một chính sách cung cấp dịch vụ chung và có thể hỗ trợ tập hợp chung các nhóm PHB và các cách sắp xếp điểm mã phân biệt dịch vụ DSCP, vì vậy có thể loại bỏ qui định lưu lượng giữa các miền DS đó.
DiffServ sử dụng trường kiểu dịch vụ ToS trong tiêu đề IPv4 (mục 1.13) và trường phân lớp lưu lượng TC (Traffic Class) trong tiêu đề IPv6 để đánh dấu gói. Đối với các bộ định tuyến hoạt động trong miền DS các trường chức năng này được thay bằng trường chức năng dịch vụ phân biệt DS. Trong 8 bit của trường DS, 6 bit được sử dụng cho điểm mã dịch vụ phân biệt DSCP và 2 bit dự phòng. Hình 3.11 dưới đây chỉ ra cấu trúc của trường DS.
Hình 3.11: Cấu trúc của trường phân biệt dịch vụ DS
Các điểm mã phân biệt dịch vụ DSCP được phân thành 3 khối được gọi là các pool. Bảng 3.3 dưới đây chỉ ra các khối của DSCP.
Pool
Điểm mã DSCP
Ứng dụng
1
2
3
XXXXX0
XXXX11
XXXX01
Tiêu chuẩn
Thử nghiệm/nội bộ
Thử nghiệm/nội bộ
Bảng 3.3: Các khối điểm mã dịch vụ phân biệt DSCP
Pool 1 gồm các điểm mã DSCP sử dụng cho toàn cầu, pool 2 và pool 3 sử dụng cho mục đích thử nghiệm và nội bộ miền DS riêng. Như vậy, số phân lớp dịch vụ của pool 1 có thể lên tới 32 và số lớp dịch vụ tối đa của pool2 và pool 3 là 16. Để hỗ trợ cho các bộ định tuyến truyền thống sử dụng các phân lớp của trường ToS trong IPv4. 8 điểm mã DSCP được sử dụng nên DSCP có dạng (XXX000). Dịch vụ nỗ lực tối đa có điểm mã phân biệt dịch vụ DSCP là (000000).
3.2.3 Các phương pháp xử lý gói trong DiffServ.
Qui tắc ứng xử theo từng chặng là sự mô tả bề ngoài của ứng xử chuyển tiếp của một nút DS được áp dụng cho một sự tập ứng xử DS cụ thể. Ứng xử chuyển tiếp mục tiêu giới thiệu trong mục này nhằm sáng tỏ phương pháp xử lý gói trong mô hình DiffServ. Để tạo ra các hành vi chuyển tiếp gói được định nghĩa theo quy tắc ứng xử từng chặng PHB, các cơ cấu kỹ thuật đảm bảo QoS như AQM và lập lịch gói đã được trình bày trong chương 2 được ứng dụng. Một PHB có thể không cần phụ thuộc vào nguyên tắc chung mà có thể được phát triển trên các kỹ thuật riêng của nhà cung cấp thiết bị.
Nhóm làm việc về DiffServ của IETF định nghĩa hai loại PHB trong RFC 2598 [6], RFC 3246 và RFC 2597 [6]: Chuyển tiếp nhanh EF (Expedited Forwarding) và Chuyển tiếp đảm bảo AF (Assured Forwarding).
(i) Chuyển tiếp nhanh EF PHB
Về cơ bản, EF PHB đảm bảo tính năng về mặt tốc độ hơn là độ tin cậy. Nó được yêu cầu đưa ra các dịch vụ với khả năng tổn hao thấp, trễ thấp, rung pha thấp và đảm bảo băng thông. Vì rung pha và trễ gây nên bởi thời gian mà gói sử dụng ở trong bộ nhớ đệm và hàng đợi, một bộ định tuyến EF phải đảm bảo rằng lưu lượng EF được đưa đến những bộ nhớ đệm nhỏ. Tốc độ đầu ra của bộ định tuyến này phải bằng (hoặc cao hơn đầu vào). Khi xảy ra hiện tượng quá tải, nút biên miền DS không cho phép lưu lượng dạng này đi vào trong miền vì nó sẽ là nguyên nhân gây tắc nghẽn tại các bộ định tuyến trong miền DS. Vấn đề này được điều chỉnh bởi xác định mức dịch vụ SLA và xác định lưu lượng truyền có điều kiện.
Hình 3.12: Xử lý chuyển tiếp nhanh EF PHB
Chuyển tiếp EF PHB khả thi nếu băng thông đầu ra và kích thước bộ nhớ đệm đủ để các luồng lưu lượng ra với tốc độ phục vụ m. Tốc độ phục vụ m luôn lớn hơn tốc độ đầu vào l tại các bộ đệm EF. Các luồng không phải là EF ở đây là các luồng dịch vụ nỗ lực tối đa. Với kỹ thuật lập lịch ưu tiên như đã chỉ ra trong chương 3, chuyển tiếp EF đảm bảo được tính ưu tiên cho các luồng lưu lượng theo yêu cầu.
Một tiếp cận khác của chuyển tiếp EF PHB là sử dụng các biến thể của hàng đợi WFQ để phân loại các lưu lượng chuyển tiếp EF.
(ii) Chuyển tiếp đảm bảo AF PHB
Đặc điểm của AF PHB là phân phối dữ liệu đảm bảo với khả năng mất gói thấp. Đó là điều kiện tốt nhất khi sử dụng các giao thức không thực hiện xử lý sửa lỗi hoặc không có giải pháp truyền lại gói.
AF PHB bao gồm 4 lớp chuyển tiếp và mỗi lớp chuyển tiếp có 3 mức ưu tiên loại bỏ gói tin, mỗi lớp được gán một băng thông và khoảng nhớ đệm xác định. Lớp A có thể có bộ nhớ đệm lớn hơn nhưng băng thông nhỏ và lớp D có thể có bộ nhớ đệm nhỏ nhưng băng thông lớn hơn. Nếu một gói phải bị loại bỏ, bộ định tuyến có cách nhận biết gói nào bị loại bỏ đầu tiên. Ngoài ra, mỗi lớp chuyển tiếp được phân bổ một số lượng cực nhỏ băng thông và bộ nhớ đệm. Nếu bộ nhớ đệm đầy, thì quá trình loại bỏ gói sẽ bắt đầu theo trật tự loại bỏ theo mức ưu tiên. Các phân loại AF được thể hiện trên hình 3.13 và trên bảng 3.4.
Hình 3.13: Các phân lớp chuyển tiếp đảm bảo AF PHB
Lớp PHB
Phân lớp
Dự đoán mất gói
DSCP
AF4
AF3
AF2
AF1
AF41
AF42
AF43
AF31
AF32
AF33
AF21
AF22
AF23
AF11
AF12
AF13
Thấp
Trung bình
Cao
Thấp
Trung bình
Cao
Thấp
Trung bình
Cao
Thấp
Trung bình
Cao
100010
100100
100110
011010
011100
100010
010010
010100
010110
001010
001100
001110
Bảng 3.4: Chi tiết các phân lớp chuyển tiếp đảm bảo AF PHB
(iii) PHB và thoả thuận lớp lưu lượng
Các PHB được xác định theo các giới hạn về tài nguyên của chúng (ví dụ: bộ đệm, băng thông) có quan hệ ưu tiên với các PHB khác, hay trong các giới hạn về đặc điểm lưu lượng tường minh (trễ, tổn thất). Các PHB này có thể được dùng như là các khối làm sẵn để cấp phát các tài nguyên và nên được định rõ như một nhóm PHB chắc chắn. Các nhóm PHB thường chia sẻ áp dụng ràng buộc chung cho mỗi PHB trong phạm vi nhóm, như chính sách lập lịch gói hay quản lý bộ đệm. Quan hệ giữa các PHB trong nhóm có thể ở dưới dạng ưu tiên tuyệt đối hay tương đối. Một PHB đơn là trường hợp đặc biệt của nhóm PHB.
PHB được thực hiện trong các nút theo một số cơ cấu quản lý bộ đệm hoặc lập lịch gói. Các nhóm PHB cần được hiểu như sự cấp phát tài nguyên thích hợp giữa các nhóm, và các cơ cấu tích hợp có thể được thực hiện hỗ trợ 2 hay nhiều nhóm. Một định nghĩa nhóm PHB nên xác định rõ khả năng xung đột với các nhóm PHB trước, mà có thể ngăn cản sự hoạt động đồng thời. Một PHB được chọn tại một nút nhờ sắp xếp điểm mã DS trong gói nhận được. Các PHB tiêu chuẩn có một điểm mã được chỉ định. Tuy nhiên, với các PHB chuẩn toàn bộ không gian các điểm mã lớn hơn không gian khả dụng cho các điểm mã được đề nghị, và do đó loại bỏ sự cung cấp cho những sắp xếp cấu hình nội bộ. Một bảng sắp xếp điểm mã cho PHB có thể bao gồm cả sự sắp xếp 1à1 và Nà 1. Tất cả các điểm mã phải được sắp xếp theo một số PHB; khi thiếu một vài chính sách cục bộ, các điểm mã không được sắp xếp theo PHB chuẩn phù hợp với các chi tiết của PHB đó nên được sắp xếp theo PHB mặc định .
Hình3.14: Dịch vụ phân biệt với PHB và TCA
Thực hiện, cấu hình, vận hành và quản lý các nhóm PHB được hỗ trợ trong các nút của miền DS nên được phân một cách hiệu quả tài nguyên của các nút này và các liên kết nội vùng giữa các tập ứng xử, phù hợp với chính sách cung cấp dịch vụ của miền. Các thành phần qui định lưu lượng có thể tăng mức điều khiển sử dụng các tài nguyên này qua sự ép buộc của các TCA và có thể qua hoạt động phản hồi từ các nút và các thành phần qui định lưu lượng trong miền. Mặc dù các dịch vụ có thể được triển khai khi thiếu các chức năng qui định lưu lượng phức tạp, các chức năng như là định chính sách, định dạng, và đánh dấu lại động cho phép triển khai các hệ đo lượng thi hành việc cung cấp các dịch vụ. Cấu hình và ảnh hưởng giữa các thành phần qui định lưu lượng và các nút nội vùng nên được quản lý bằng điều khiển quản trị của miền và có thể yêu cầu điều khiển vận hành qua các giao thức và một thực thể điều khiển.
IP QoS VÀ CHUYỂN MẠCH NHÃN ĐA GIAO THỨC MPLS
Trong một số năm gần đây, công nghệ chuyển mạch nhãn đa giao thức MPLS được coi là công nghệ hàng đầu cho mạng lõi. Sự phát triển công nghệ chuyển mạch MPLS là kết quả của các mô hình ứng dụng công nghệ IP trên nền ATM và FR. Chất lượng dịch vụ mạng QoS chính là yêu cầu thúc đẩy MPLS. So sánh với các yêu cầu khác, như quản lí lưu lượng và hỗ trợ VPN thì QoS không phải là lí do quan trọng nhất để triển khai MPLS. Hầu hết các công việc được thực hiện trong MPLS QoS tập trung vào việc hỗ trợ các dặc tính IP QoS trong mạng. Nói cách khác, mục tiêu là thiết lập điểm tương đồng của các đặc tính QoS giữa IP và MPLS chứ không phải là làm cho MPLS QoS tốt hơn IP QoS.
Một lí do nữa để khẳng định MPLS QoS không phải là IP QoS là MPLS không phải là giao thức xuyên suốt. MPLS không vận hành trong các máy chủ và có thể sẽ tồn tại các mạng IP không sử dụng MPLS. Mặt khác QoS là đặc tính thường trực của liên lạc giữa các LSR cùng cấp. Một cách nhìn khác về vấn đề này là MPLS không thay đổi về căn bản về mô hình dịch vụ IP. Các nhà cung cấp dịch vụ không bán dịch vụ MPLS, họ cung cấp các dịch vụ IP (hay Frame Relay và các dịch vụ khác), và do đó nếu họ đưa ra QoS thì phải dựa trên IP QoS (hay Frame Relay QoS,…) chứ không phải là MPLS QoS.
Điều này không có nghĩa là MPLS QoS không có vai trò như IP QoS. Thứ nhất, MPLS giúp nhà cung cấp đưa ra dịch vụ IP QoS chất lượng hơn. Thứ hai, hiện nay đang xuất hiện một số khả năng QoS mới hỗ trợ qua mạng sử dụng MPLS, tuy không thực sự xuyên suốt nhưng cũng có thể chứng tỏ rất hữu ích, ví dụ như đảm bảo băng thông của LSP.
(i) Mô hình DiffServ và MPLS
Tương tự như DiffServ, MPLS cũng hỗ trợ chất lượng dịch vụ trên cơ sở phân loại các luồng lưu lượng theo các tiêu chí như độ trễ, băng tần. Đầu tiên tại biên của mạng, luồng lưu lượng của người dùng được nhận dạng (băng việc phân tích một số trường trong mào đầu của gói) và chuyển các luồng lưu lượng đó trong các LSP riêng với thuộc tính COS hay QoS của nó. MPLS có thể hỗ trợ các dịch vụ không định trước qua LSP bằng việc sử dụng một trong các kỹ thuật sau:
Bộ chỉ định COS có thể được truyền trong nhãn gắn liền với từng gói. Bên cạnh việc chuyển mạch nhãn tại từng nút LSR, mỗi gói có thể được chuyển sang kênh ra dựa vào thuộc tính COS. Mào đầu đệm (Shim header) của MPLS có chứa trường COS.
Trong trường hợp nhãn không chứa chỉ thị COS hiện tại thì giá trị COS có thể liên quan ngầm định với một LSP cụ thể. Điều đó đòi hỏi LDP hay RSVP gán giá trị COS không danh định cho LSP để các gói được xử lý tương xứng.
Chất lượng dịch vụ QoS có thể được cung cấp bởi một LSP được thiết lập trên cơ sở báo hiệu ATM (trong trường hợp MPLS là mạng ATM-LSR).
Khi một bộ định tuyến MPLS gửi đi một gói tin đến chặng kế tiếp của nó, nó gửi một nhãn đi kèm. Các LSR tuần tự trong mạng đó không cần phân tích mào đầu của gói tin, nó chỉ đọc nhãn MPLS được đánh chỉ số trong bảng đường dẫn định tuyến duy trì tại mỗi LSR. Khi các gói tin được đánh dấu bởi các mã điểm DiffServ đến một mạng MPLS, cần phải có một cách thức chuyển giao thông tin cung cấp bởi các mã điểm vào nhãn MPLS. Việc này cần thực hiện nếu MPLS có khả năng thực hiện các quyết định đáp ứng các yêu cầu dịch vụ khác biệt nhờ đó các gói tin được đánh dấu với MPLS trong mạng, các tiêu đề IP không được kiểm tra khi các gói tin được gán nhãn MPLS. Do vậy các gói tin không thể phân biệt dựa trên các DSCP của chúng do DSCP là một phần của tiêu đề IP. Có hai phương pháp đặt thông tin DSCP vào tiêu đề IP.
Phương pháp thứ nhất sử dụng 3 bit trường EXP của tiêu đề MPLS. Theo cách đó, có tối đa 8 lớp BA và một giá trị EXP được ánh xạ đến một mô tả PHB hoàn chỉnh: trình tự huỷ và xếp hàng.
Phương pháp thứ hai, nếu có hơn 8 lớp dịch vụ, RFC 2309 đề xuất một kiểu LSP khác. Do đó, DSCP được ánh xạ vào một cặp . Nhãn này trao đổi thông tin riêng về hàng đợi và lập lịch L-LSP. ở trên đoạn giữa của LSP, sự phân loại BA được dựa trên EXP hay các trường nhãn của tiêu đề MPLS chứ không phải DSCP được lưu trong tiêu đề IP. Do đó, hành vi cho mỗi chặng của gói tin cũng là duy nhất.
MPLS kết hợp với Diffserv trong mạng lõi đem lại lợi ích cho cả các thành phần của MPLS và Diffserv. MPLS cung cấp các dịch vụ phân biệt Diffserv với đặc tính khôi phục và bảo vệ đường dẫn, trong khi Diffserv hoạt động như một kiến trúc phân lớp dịch vụ cho MPLS. MPLS với Diffserv có thể đưa ra các thiết kế mạng mềm dẻo để cung cấp các xử lý khác nhau cho các lớp dịch vụ CoS trong đường dẫn lưu lượng. Kiểu ghép hai mức được sắp xếp nhờ vào giao thức RSVP, RSVP thiết lập và duy trì một số lượng đường dẫn LSP MPLS và trên các đường dẫn đó được phân lớp dịch vụ theo kiến trúc Diffserv. Để đảm bảo các chức năng của Diffserv qua mạng MPLS, Các điểm mã dịch vụ DSCP được chuyển tới các LSR nhằm chỉ ra các xử lý tương thích với QoS yêu cầu.
(i) Mô hình IntServ và MPLS
MPLS tái sử dụng các giao thức của IP, RSVP cũng là một trong các giao thức được tái sử dụng và được cải thiện. RSVP nguyên thuỷ [RFC 2205] được thiết kết cho các ứng dụng thời gian thực qua mạng Internet. Đã có rất nhiều các ứng dụng mở rộng của RSVP để hỗ trợ thêm các đặc tính như tính bảo mật và khả năng mềm dẻo; hỗ trợ các giao diện tới các thiết bị trong miền Diffserv; hỗ trợ kỹ thuật lưu lượng trong các ứng dụng mới như MPLS và GMPLS (RSVP-TE).
Hình 3.15: Thực hiện phân bổ nhãn qua RSVP-TE
Các đặc tính của RSVP-TE [RFC 3209] là sự mở rộng phần lõi của RSVP để thiết lập các tuyến đường hiện dựa trên định tuyến ràng buộc các LSP trong mạng MPLS sử dụng RSVP làm giao thức báo hiệu. Dự trữ tài nguyên là một thành phần rất quan trọng của xử lý lưu lượng. Đây là một trong số các lý do để nhóm làm việc MPLS chọn RSVP hơn là việc xây dựng mới hoàn toàn một giao thức báo hiệu khác để hỗ trợ các yêu cầu xử lý lưu lượng. RSVP mở rộng thành giao thức báo hiệu để hỗ trợ việc tạo LSPs có thể được định tuyến tự động tránh khỏi lỗi mạng và tắc nghẽn. RSVP đơn giản hoá việc vận hành mạng bằng quá trình xử lý lưu lượng một cách tự động. RSVP-TE sử dụng các bộ định tuyến chuyển mạch để thiết lập, duy trì các đường ống LSP và để phục vụ tài nguyên cho các LSP đó.
RSVP-TE yêu cầu thiết bị có khả năng mang một đối tượng “mờ” (opaque object), nghĩa là các đối tượng này không bị xử lý bởi các thiết bị khác khi truyền trong mạng. RSVP mang các đối tượng trong các bản tin của nó như là các đoạn mờ của thông tin (hình 3.15). Những đoạn mờ này được mang tới các module điều khiển thích hợp trong bộ định tuyến. Phương thức thiết lập báo hiệu dựa trên cơ sở này khuyến khích sự phát triển của các đối tượng RSVP mới. Các đối tượng này có thể được dùng để tạo ra và duy trì các trạng thái được phân phối cho các thông tin khác ngoài vấn đề dự trữ tài nguyên đơn thuần.Tập hợp các mở rộng có thể nhanh chóng và dễ dàng được phát triển qua việc cải thiện RSVP nhằm hỗ trợ các yêu cầu xử lý lưu lượng mang tính tức thời trong vấn đề định tuyến chính xác và giảm độ phức tạp trong quá trình phân phối nhãn.
Hình 3.16: Cấu trúc bản tin RSVP-TE
Các khuyến nghị mới để mở rộng RSVP được yêu cầu tương thích hoàn toàn với RSVP truyền thống. RSVP-TE có thể dễ dàng phân biệt báo hiệu thiết lập đường LSP của MPLS với RSVP truyền thống bằng cách kiểm tra các đối tượng chứa trong các bản tin. Như vậy hệ thống báo hiệu hợp nhất mang mọi đối tượng cần thiết để thiết lập LSP một cách mềm dẻo.
Các đặc điểm cơ bản của RSVP-TE hỗ trợ trong MPLS được tóm tắt dưới đây:
Các kiểu LSP được cung cấp
Giao thức RSVP cung cấp các đường dẫn chuyển mạch định tuyến hiện ER-LSP theo cả hai kiểu chặt và lỏng, chức năng này lợi dụng chính hai kiểu định tuyến trong MPLS (định tuyến hiện và định tuyến từng bước). Đối với phương pháp lỏng trong các đường dẫn ER-LSP, phương pháp định tuyến từng bước được sử dụng để xác định nơi bản tin gửi đến. Vì thế RSVP cũng cung cấp định tuyến từng bước dựa trên yêu cầu đường xuống.
Các tham số QoS
Ban đầu RSVP được thiết kế để cung cấp các dịch vụ tích hợp, nó không có khả năng phân biệt dịch vụ trong các mạng mang. Vì thế RSVP không có khả năng báo hiệu các dịch vụ phân biệt. Để tương thích với các dịch vụ phân biệt RSVP truyền và điều khiển khéo léo các tham số điều khiển QoS như là dữ liệu "mờ", gửi các dữ liệu này tới module điều khiển lưu lượng thích hợp để thực hiện dự trữ tài nguyên cho các lớp dịch vụ phân biệt.
Kiến trúc báo hiệu trong mạng
RSVP-TE được thiết kế dựa trên cây multicast IP, thực hiện thống nhất dự trữ tài nguyên hướng tới thiết bị gửi. Trong phạm vi MPLS, chỉ có kết nối đơn phương được xem xét, nên nó bỏ đi một số kiểu dự trữ và kiến trúc gốc thiết bị gửi. Trong suốt thời gian báo hiệu, các yêu cầu các lớp dịch vụ và QoS thường được khởi tạo từ thiết bị nhận.Với các đường dẫn chuyển mạch định tuyến hiện ER - LSP, nhà quản lý mạng thường xuyên cấu hình và khởi tạo các yêu cầu và chính sách từ thiết bị gửi hơn là từ thiết bị nhận hoặc cả hai.
Chỉ thị lỗi
Do thiếu các cơ chế hỗ trợ vận chuyển tin cậy, RSVP không thể nhanh chóng thông tin cho điểm kết cuối rằng kết nối giữa chúng bị lỗi, RSVP có một bản tin ngắt đường nhưng nó lại không được gửi một cách tin cậy. Chính vì vậy, điểm cuối không thể bắt đầu tái định tuyến cho đến khi kết thúc khoảng thời gian xoá bỏ trạng thái mềm.
Khả năng tái định tuyến
Kiểu dự trữ tài nguyên RSVP SE được sử dụng thiết lập đồng thời 2 đường cho một phiên để định tuyến thích nghi luân phiên xuyên qua mạng bằng cơ chế nối trước khi cắt. Trong kiểu này, một phiên có thể thiết lập một đường khác cho LSP, sử dụng một nhận dạng đường khác với đường ban đầu. Thiết bị gửi gửi một bản tin Path sử dụng đối tượng phiên ban đầu và LSP ID mới và đối tượng tuyến hiện để chỉ thị tuyến mới. Sau đó trên các liên kết mà không chiếm giữ chung, bản tin Path mới được đối xử như là thiết lập LSP mới thông thường. Trên các liên kết được duy trì, đối tượng phiên chia sẻ và kiểu SE cho phép LSP được thiết lập chia sẻ tài nguyên với LSP cũ. Mỗi lần thiết bị gửi nhận một bản tin Resv cho LSP mới, nó có thể truyền lưu lượng vào đó và huỷ bỏ LSP cũ. Đặc điểm này có thể được sử dụng trong việc tối ưu lại lưu lượng, không sử dụng cho công bằng tải. Khi sử dụng đặc tính này, chú ý rằng chỉ có một ER - LSPs mang lưu lượng và tất cả đường thứ hai khác đều trống rỗng.
Quyền giành trước đường
RSVP sử dụng các độ ưu tiên thiết lập và chiếm giữ đường dể xác định đường mới có thể chiếm trước đường đang tồn tại. Cơ chế vận chuyển của RSVP, trên IP có thể gây ra các vấn đề khác nữa đối với việc hỗ trợ đặc điểm này. Bởi vì quyền giành trước thường xuyên được yêu cầu khi mạng đang chạy trong khi thiếu tài nguyên, bản tin báo hiệu RSVP có thể bị mất trong trường hợp này.
Tối ưu lại đường
Khả năng tái định tuyến trong RSVP có thể được sử dụng để tối ưu đường.
Khôi phục lỗi
Các mở rộng của RSVP mang lại đặc điểm tái định tuyến để điều khiển khôi phục lỗi. Nhưng trong trường hợp này, nối trước khi cắt không được sử dụng. RSVP đưa ra một lựa chọn tái định tuyến nhanh cục bộ để điều khiển tình huống lỗi. Tái định tuyến nhanh liên quan đến tính toán đường vòng trước tại mỗi nút dọc theo đường. Tiếp cận này đòi hỏi rất nhiều các giải pháp mở rộng tính toán. Số lượng lớn cả hai đường phải được tính trước, để đảm bảo rằng chúng không nối với nhau và được duy trì để sử dụng trong điều kiện lỗi.
Tách vòng lặp
Để điều khiển tách vòng lặp, đối tượng ghi thông tin tuyến được sử dụng, nó cũng có thể cung cấp thông tin tuyến của LSP xác định cho mục đích chẩn đoán tuyến.
Vấn đề khả năng gia tăng kế thừa
Để giải quyết vấn đề này, các mở rộng gần đây nhất cho phép kết hợp bản tin làm tươi để giảm bớt số lượng bản tin này, khi số lượng lớn LSP tồn tại. Để giảm quá trình nạp các bản tin làm tươi trong một nút, nhận dạng bản tin được đưa ra, mục đích để cho các nút nhận nhanh chóng nhận ra trạng thái thay đổi. Tuy nhiên sử dụng nhận dạng nút (ID node) cần phải quản lý chắc chắn số lượng ID và bản tin để tránh nhiều lỗi có thể. Các mở rộng mới nhất cấm hoàn toàn các bản tin làm tươi. LSR phải sử dụng giao thức mới để phát hiện mất các kế cận.
Hệ thống báo hiệu linh động
Thiết kế trạng thái mềm rất linh động, RSVP có thể linh động đối với các node khi xử lý các tình huống tắc nghẽn nhưng không nhanh chóng trong việc khôi phục LSP.
Tóm tắt chương 3
Chương 3 tập trung vào hai mô hình đảm bảo chất lượng dịch vụ IP: mô hình tích hợp dịch vụ IntServ và mô hình phân biệt dịch vụ DiffServ. Các đặc điểm của hai mô hình được trình bày chi tiết nhằm giúp người đọc nắm bắt rõ các khía cạnh ứng dụng của hai mô hình trong mạng IP thực tế. Một số vấn đề được trình bày trong chương 1 và chương 2 được tổng kết và ứng dụng trong chương 3 tạo ra một cách nhìn nhận xuyên suốt về khía cạnh đảm bảo chất lượng IP. Một số đặc tính cơ bản của mô hình ứng dụng QoS IP được thực hiện trong MPLS được giới thiệu là những thông tin khởi đầu cho một tài liệu tiếp theo.
KẾT LUẬN
Như vậy qua đồ án này ta đã thấy vấn đề chất lượng dịch vụ và đánh giá chất luợng dịch vụ luôn là vấn đề đóng vai trò quan trọng đối với tất cả các loại hình dịch vụ viễn thông .Mỗi loại hình dịch vụ sẽ quan tâm đến QoS ở những khía cạnh khác nhau .Việc đánh giá QoS chính là đánh giá các tham số đặc trưng cho dịch vụ đó với các tiêu chí cụ thể .Trong xu hướng phát triển hiện nay, với sự bùng nổ lưu lượng ,nhu cầu sử dụng các dịch vụ đa phương tiện ,nhu cầu sử dụng di động tích hợp dịch vụ ;phát triển mạng viễn thông lên mạng thế hệ sau NGN dựa trên cơ sở chuyển mạch gói IP hỗ trợ đa giao thức là 1 tất yếu .Việc tích hợp nhiều ứng dụng khác nhau với các yêu cầu về QoS khác nhau đòi hỏi phải có một mô hình đảm bảo QoS cho dịch vụ này .Hướng tiếp cận QoS theo mô hình Diffserv rất phù hợp với các mạng gói IP do đó nó là sự lựa chọn tốt cho mạng NGN .
TÀI LIỆU THAM KHẢO
Kun I.Pack, QoS in Packet Network, The MITE coporation USA, Springer 2005. Print ISBN: 0-387-23389-X.
Markus Peuhkuri, IP Quality of Service, Helsinki University of Technology, Laboratory of Telecommunications Technology, 2000.
Mario Marchese, QoS over Heterogeneous Networks, John Wiley & Sons, 2007.
IP Quality of Service (courses from TRA, Cisco), 2003.
Dương Hồng Sơn, Hoàng Trọng Minh, Hoàng Đức Hải, “ Kỹ thuật điện thoại qua IP và Internet”, NXB Lao động, 2002.
Các file đính kèm theo tài liệu này:
- Tổng quan, kỹ thuật đảm bảo chất lượng dịch vụ QoS IP và mô hình ứng dụng đảm bảo QoS IP.doc