MÔ HÌNH ỨNG DỤNG ðẢ M BẢO QOS IP
3.3IP 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
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 <Label, EXP>. Nhãn này trao ựổi thông tin riêng về hàng ựợi và lập lịch L-LSP. ở trên ựoạn giữa của LSP, sự phân loại BA ựược dựa trên EXP hay các trường nhãn của tiêu ựề MPLS chứ không phải DSCP ựược lưu trong tiêu ựề IP. Do ựó, hành vi cho mỗi chặng của gói tin cũng là duy nhất.
MPLS kết hợp với Diffserv trong mạng lõi ựem lại lợi ắch cho cả các thành phần của MPLS và Diffserv. MPLS cung cấp các dịch vụ phân biệt Diffserv với ựặc tắnh khôi phục và bảo vệ ựường dẫn, trong khi Diffserv hoạt ựộng như một kiến trúc phân lớp dịch vụ cho MPLS. MPLS với Diffserv có thể ựưa ra các thiết kế mạng mềm dẻo ựể cung cấp các xử lý khác nhau cho các lớp dịch vụ CoS trong ựường dẫn lưu lượng. Kiểu ghép hai mức ựược sắp xếp nhờ vào giao thức RSVP, RSVP thiết lập và duy trì một số lượng ựường dẫn LSP MPLS và trên các ựường dẫn ựó ựược phân lớp dịch vụ theo kiến trúc Diffserv. để ựảm bảo các chức năng của Diffserv qua mạng MPLS, Các ựiểm mã dịch vụ DSCP ựược chuyển tới các LSR nhằm chỉ ra các xử lý tương thắch với QoS yêu cầu.
(i) Mô hình IntServ và MPLS
MPLS tái sử dụng các giao thức của IP, RSVP cũng là một trong các giao thức ựược tái sử dụng và ựược cải thiện. RSVP nguyên thuỷ [RFC 2205] ựược thiết kết cho các ứng dụng thời gian thực qua mạng Internet. đã có rất nhiều các ứng dụng mở rộng của RSVP ựể hỗ trợ thêm các ựặc tắnh như tắnh bảo mật và khả năng mềm dẻo; hỗ trợ các giao diện tới các thiết bị trong miền Diffserv; hỗ trợ kỹ thuật lưu lượng trong các ứng dụng mới như MPLS và GMPLS (RSVP-TE).
Hình 3.15: Thực hiện phân bổ nhãn qua RSVP-TE
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 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
một bản tin Resv cho LSP mới, nó có thể truyền lưu lượng vào ựó và huỷ bỏ LSP cũ. đặc ựiểm này có thể ựược sử dụng trong việc tối ưu lại lưu lượng, không sử dụng cho cân bằng tải. Khi sử dụng ựặc tắnh này, chú ý rằng chỉ có một ER - LSPs mang lưu lượng và tất cả ựường thứ hai khác ựều trống rỗng.
Quyền giành trước ựường
RSVP sử dụng các ựộ ưu tiên thiết lập và chiếm giữ ựường dể xác ựịnh ựường mới có thể chiếm trước ựường ựang tồn tại. Cơ chế vận chuyển của RSVP, trên IP có thể gây ra các vấn ựề khác nữa ựối với việc hỗ trợ ựặc ựiểm này. Bởi vì quyền giành trước thường xuyên ựược yêu cầu khi mạng ựang chạy trong khi thiếu tài nguyên, bản tin báo hiệu RSVP có thể bị mất trong trường hợp này.
Tối ưu lại ựường
Khả năng tái ựịnh tuyến trong RSVP có thể ựược sử dụng ựể tối ưu ựường.
Khôi phục lỗi
Các mở rộng của RSVP mang lại ựặc ựiểm tái ựịnh tuyến ựể ựiều khiển khôi phục lỗi. Nhưng trong trường hợp này, nối trước khi cắt không ựược sử dụng. RSVP ựưa ra một lựa chọn tái ựịnh tuyến nhanh cục bộ ựể ựiều khiển tình huống lỗi. Tái ựịnh tuyến nhanh liên quan ựến tắnh toán ựường vòng trước tại mỗi nút dọc theo ựường. Tiếp cận này ựòi hỏi rất nhiều các giải pháp mở rộng tắnh toán. Số lượng lớn cả hai ựường phải ựược tắnh trước, ựể ựảm bảo rằng chúng không nối với nhau và ựược duy trì ựể sử dụng trong ựiều kiện lỗi.
Tách vòng lặp
để ựiều khiển tách vòng lặp, ựối tượng ghi thông tin tuyến ựược sử dụng, nó cũng có thể cung cấp thông tin tuyến của LSP xác ựịnh cho mục ựắch chẩn ựoán tuyến.
Vấn ựề khả năng gia tăng kế thừa
để giải quyết vấn ựề này, các mở rộng gần ựây nhất cho phép kết hợp bản tin làm tươi ựể giảm bớt số lượng bản tin này, khi số lượng lớn LSP tồn tại. để giảm quá trình nạp các bản tin làm tươi trong một nút, nhận dạng bản tin ựược ựưa ra, mục ựắch ựể cho các nút nhận nhanh chóng nhận ra trạng thái thay ựổi. Tuy nhiên sử dụng nhận dạng nút (ID node) cần phải quản lý chắc chắn số lượng ID và bản tin ựể tránh nhiều lỗi có thể. Các mở rộng mới nhất cấm hoàn toàn các bản tin làm tươi. LSR phải sử dụng giao thức mới ựể phát hiện mất các kế cận.
Hệ thống báo hiệu linh ựộng
Thiết kế trạng thái mềm rất linh ựộng, RSVP có thể linh ựộng ựối với các node khi xử lý các tình huống tắc nghẽn nhưng không nhanh chóng trong việc khôi phục LSP.
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.
BÀI TẬP
Bài 1: Xác ựịnh màu gói tin trong srTCM
Hình1- BT1: Lưu ựồ nguyên lý ựánh dấu
Hình2- BT1: Lưu ựồ nguyên lý srTCM Giả thiết:
Phương thức hoạt ựộng mù màu CIR = 1000 byte/s
CBS = 50 token EBS = 400 token
Tại thời ựiểm t, Tc=10 token, Te=70 token. Tại thời ựiểm t, một gói có kắch thước 5 byte ựến.
Yêu cầu
Căn cứ theo nguyên lý trên hình1-BT1 Xác ựịnh màu của gói tin
Tắnh Te và Tc sau khi xử lý gói.
Bài 2: Xác ựịnh trạng thái gáo rò sau một khoảng thời gian
Hình 1-BT2:đánh dấu 3 màu tốc ựộựơn Giả thiết:
Phương thức hoạt ựộng mù màu CIR = 100 byte/s
CBS = 50 token EBS = 400 token
Tại thời ựiểm t, Tc=10 token, Te=50 token. Thời gian cập nhật token tỖ = t + (1/100) Sau 2 giây, không có gói ựến
Yêu cầu
Căn cứ theo nguyên lý trên hình1-BT1 Xác ựịnh trạng thái Te và Tc sau 2 giây.
Hình 1-BT3: Hàng ựợi cân bằng trọng số
Giả thiết:
Có 3 hàng ựợi
Hàng ựợi 1: 20% BW; Hàng ựợi 2: 30% BW; Hàng ựợi 3: 50% BW. Các gói có kắch thước như hình 1BT3.
Yêu cầu
Xác ựịnh thứ tự các gói tại cổng ựầu ra.