CHƢƠNG 2 : MỘT SỐ ỨNG DỤNG CỦA MPLS
2.2. ỨNG DỤNG MPLS TRONG QOS
2.2.3. Khả năng hỗ trợ các dịch vụ của MPLS
Tiếp nối các kết quả của mô hình dịch vụ IntServ/RSVP, mô hình DifServ được phát triển nhằm hỗ trợ cho các ứng dụng Web trên mạng IP phạm vi rộng. Do cả MPLS và DifServ đều có triển vọng được ứng dụng trong các mạng cung cấp dịch vụ (ISP network) nên điều cần thiết là phải kết hợp được hoạt động của hai công nghệ này.
CR-LDP và RSVP đang được lựa chọn làm giao thức báo hiệu trong mạng MPLS. CR-LDP là giao thức mở rộng của LDP, nên nếu sử dụng CR-LDP sẽ không
57
phải bổ sung thêm nhiều giao thức khác, còn RSVP là một giao thức riêng biệt nên nếu sử dụng RSVP thì hiển nhiên là đồng thời chúng sẽ phải sử dụng thêm một số giao thức khác.
Khả năng hỗ trợ RSVP của MPLS.
MPLS hỗ trợ RSVP cho phép các LSR có thể nhận biết các dòng lưu lượng khác nhau đã được cài đặt mức dành riêng tài nguyên khác nhau. Nói cách khác là cần tạo dựng một ánh xạ tương ứng giữa dòng lưu lượng ưu tiên với nhãn đã quy định được dành trước tài nguyên. Vì vậy có thể xem một tập các gói tin được dành trước tài nguyên như một trường hợp cụ thể của FEC.
Việc liên kết nhãn với các dòng lưu lượng đã được dành trước tài nguyên trong RSVP là tương đối đơn giản. Một đối tượng RSVP mới, gọi là đối tượng Label được định nghĩa và được mang bản tin RSVP RESV.
Trong khi hoạt động, khi một LSR muốn gửi một bản tin RSVP cho một dòng lưu lượng RSVP mới, nó lấy nhãn trong số các nhãn còn dự trữ của nó tạo lối vào trong LFIB có chứa nhãn trong đối tượng Label. Trong lúc nhận bản tin RESV có chứa đối tượng Label, LSR đưa nhãn đó vào LFIB với tư cách là một nhãn đi ra (outgoing label). Sau đó nó cấp một nhãn mới, sử dụng nhãn đó làm nhãn tới (incomming label) và gài vào trong bản tin REVS trước khi gửi đi.
Trong quá trình bản tin RESV truyền, LSP được thiết lập dọc đường đi. Do các nhãn được phân phối liên tục theo các bản tin RESV nên mỗi LSR đều dễ dàng gắn kết tài nguyên QoS tương ứng với LSP (giả thiết trong quá trình hoạt động, các host không tham gia vào quá trình phân phối nhãn)
Trong mô hình như hình vẽ 2.2.3, LSR R3 cung cấp nhãn 40 cho quá trình dành trước tài nguyên và truyền ngược lên tới LSR lân cận R2. Sau đó LSR R2 cấp nhãn 60 cho quá trình dành trước tài nguyên và chuyển nó tới LSR R1. Sau toàn bộ quá trình này, một đường chuyển mạch nhãn LSP cho dòng lưu lượng đã được dành trước tài nguyên từ R1 tới R3.
Khi gói tin liên quan đến quá trình dành trước tài nguyên cần gửi đi (với các số hiệu cổng đích và cổng nguồn, số hiệu giao thức truyền thông tương ứng) tới R1,
58
đồng thời thực hiện các thao tác QoS tương ứng cho quá trình dành trước tài nguyên (ví dụ như kiểm soát là lập danh mục các gói ở đầu ra). Nói tổng quát, có nghĩa là LSR R1 thực hiện tất cả các chức năng của một IntServ router sử dụng RSVP. Ngoài ra R1 còn đưa tiêu đề nhãn vào các gói tin và chèn giá trị 60 vào các gói trước khi chuyển tiếp các gói này tới LSR R2. Khi R2 nhận được các gói tin có nhãn 60, nó có thể tìm thấy nhãn đó trong LFIB và nó tiếp tục tìm các thông tin trạng thái cần thiết liên quan đến QoS để đưa ra cách thức kiểm soát dòng lưu lượng, tổ chức các hàng đợi… Sau đó nó thực hiện thao tác tháo nhãn trên và đặt thêm nhãn đầu ra giá trị 40 do LFIB cung cấp và chuyển gói đi. Toàn bộ quá trình chuyển gói này được minh họa như trong hình 2.2.3 dưới đây:
Hình 2.2.3: Hoạt động của IntServ router.
Khi thiết lập LSP cho mỗi dòng lưu lượng dùng RSVP để dành trước tài nguyên có một số ưu điểm là chỉ duy nhất LSR R1 phải chú ý đến xem gói tin nào thuộc vào dòng lưu lượng nào. Điều này đem lại cho phép RSVP có thể ứng dụng trong MPLS những khả năng mà mạng IP thông thường không thể có. Các quá trình dành trước tài nguyên RSVP thường chỉ được thực hiện cho từng dòng lưu lượng nhỏ (microflow).
Để hỗ trợ các ứng dụng cải tiến của RSVP, MPLS định nghĩa một đối tượng RSVP mới có thể được mang trong bản tin PATH là đối tượng Label-Request, đối tượng này thực hiện hai chức năng sau:
Thông báo cho LSR tại đầu cuối của LSP gửi lại bản tin RESV để thiết lập LSP, điều này là cần thiết để thiết lập các site-to-site LSP.
Do các LSP có thể được thiết lập cho một nhóm các gói bất kỳ (chứ không phải chỉ cho các microflow) nên có một đối tượng bao gồm một trường nhận dạng giao thức lớp cao hơn sử dụng LSP.
LSR R2 LSR R3
LSR R1
59
Khả năng hỗ trợ DifServ của MPLS
Mô hình DiffServ chỉ có vài lớp lưu lượng khác nhau (ít hơn nhiều so với IntServ) nên thông số chỉ thị lớp của gói có thể được đánh dấu ngay trên gói. Thông số đó gọi là DiffServ Code Point (ký hiệu DSCP). Giá trị DSCP được mang trên trường DiffServ (gồm 6 bít) trên tiêu đề gói IP (ban đầu là một phần của byte ToS: Type of Service). Trên lý thuyết, với 6 bít DSCP có thể có tới 26=64 lớp dịch vụ khác nhau. Tuy nhiên trên thực tế, số lượng các DSCP được sử dụng trên một mạng thường ít hơn rất nhiều. Trong một mạng đơn giản chỉ với 2 lớp dịch vụ như trên được xem là giải pháp ứng dụng khởi đầu phù hợp cho DiffServ
Một số vấn đặc điểm cần chú ý về DSCP:
Bằng cách nào chúng ta có thể xác định được các gói sẽ được xử lý “ưu tiên” hơn các gói khác? (Tức là làm sao để có thể gán các giá trị phù hợp cho DSCP)
Thành phần nào của mạng sẽ có nhiệm vụ gán giá trị DSCP cho các gói tin?
Các router sẽ xử lý như thế nào khi nhận được một gói với một giá trị DSCP xác định?
Giá trị DSCP mang thông tin chỉ thị cho router về cách thức xử lý gói trên ba phương diện QoS. Thông thường mỗi DSCP xác định một “PHB: Per-Hop- Behavior”. Một số PHB tiêu chuẩn bao gồm:
Default (mặc định): không có bất kỳ ưu tiên xử lý gói nào (tương đương với best-effort)
EF (Expedited Forwarding): chuyển gói được thúc đẩy: Các gói được đánh dấu EF sẽ được chuyển với trễ nhỏ nhất và tỷ lệ mất gói thấp nhất. Điều đó có thể được thực hiện bằng cách đưa tất cả các gói trong lớp vào một hàng đợi EF dành riêng và đảm bảo tần suất đến hàng đợi của các gói nhỏ hơn tần suất dịch vụ
AF (Assuared Forwarding): chuyển gói được đảm bảo: một tập các AF được định nghĩa như sau: mỗi PHB trong tập AFxy có giá trị x,y nằm trong một khoảng nhất định. Trong đó x chỉ thị lớp AF và thường lựa chọn hàng đợi cho gói, còn y chỉ thị mức độ ưu tiên gói. Do vậy, các gói AF11, AF12, AF13 đi trên cùng một hàng đợi, nhưng các gói AF13 có nhiều khả năng bị mất do tắc nghẽn hơn so với
60
khác các gói AF1y. Số lượng các AF PHB được khuyến nghị là 12, bao gồm 4 lớp AF và 3 mức ưu tiên mất gói khác nhau cho mỗi lớp.
Muốn hỗ trợ DiffServ trên một mạng có hỗ trợ MPLS là chúng ta phải đảm bảo các phép xử lý phải được thực hiện tại mỗi LSR trên mạng theo các mức ưu tiên tương ứng với giá trị DSCP mang trên gói. Tuy nhiên giá trị này được ghi trên phần tiêu đề IP của gói mà các LSR trong quá trình chuyển gói không hề xét đến phần tiêu đề gói. Do vậy cần có một phương pháp để các LSR có thể nhận được giá trị PHB từ tiêu đề nhãn. Trên thực tế có hai phương pháp giải quyết vấn đề này như sau là:
Nhãn được chèn vào phần Header
Chèn vào phần tiêu đề lớp liên kết như đối với trường hợp tiêu đề của ATM cell
Shim Header của MPLS có 3 bít Exp được dành cho thử nghiệm. Mục đích ban đầu của trường Exp là hỗ trợ việc đánh dấu các gói DiffServ. Tuy nhiên, dễ dàng nhận thấy một điều là trường Exp chỉ có 3 bít trong khi trường DSCP lại có tới 6 bít. Nguyên nhân lịch sử của vấn đề này là trường Exp được định nghĩa dựa trên các thông tin của nhóm chuyên đề DiffSer của IETF tại thời điểm mà đa số router chỉ sử dụng 3 bít tiêu đề gói IP (trường IP cũ) để đánh dấu mức độ dịch vụ. Ngoài ra, người ta mong muốn càng làm giảm kích thước của Shim Header MPLS càng tốt để tránh cồng kềnh trong gói tin. Đồng thời với 3 bít Shim Header đã tạo ra được 8 lớp dịch vụ, 8 lớp dịch vụ này là tương đối nhiều. Do mô hình dịch vụ “best effort” với duy nhất một lớp dịch vụ là phổ biến hiện nay nên người ta cho rằng việc nâng cấp lên 2, 3 lớp dịch vụ đã là nhiều, là một bước thay đổi lớn cả về tính năng lẫn mức độ phức tạp trong hoạt động của mạng. Tuy nhiên vấn đề tồn tại là các chuẩn DiffServ cho phép tối đa 64 DSCP còn MPLS Shim Header chỉ có thể mang tối đa 8 giá trị khác nhau trên trường Exp.