CHƯƠNG 2: ĐỊNH TUYẾN VÀ BÁO HIỆU TRONG MPLS
2.5. Giao thức RSVP-TE (RSVP Traffic Engineering)
Giao thức RSVP có một số cơ chế cần thiết để thực hiện báo hiệu phân phối nhãn nhằm cưỡng bức định tuyến. IETF đã chuẩn hóa phần mở rộng kỹ thuật lưu lượng RSVP-TE, định nghĩa các ứng dụng của RSVP-TE như hỗ trợ phân phối nhãn theo yêu cầu để cấp phát tài nguyên cho các LSP định tuyến tường minh. Tổng kết cỏch dựng RSVP-TE để hỗ trợ tỏi định tuyến “make-before-break”, theo dừi đường thực sự được chọn qua chức năng ghi tuyến cũng như hỗ trợ ưu tiên và lấn chiếm.
Nguyên lý chức năng của RSVP là thiết lập các dự trữ cho luồng gói đơn hướng. Các bản tin RSVP thường đi theo con đường hop-by-hop của định tuyến IP nếu không hiện diện tùy chọn tuyến tường minh (explicit route). Các router hiểu RSVP dọc theo đường có thể chặn và xử lý bất cứ bản tin nào. RFC 2205 định nghĩa 3 kiểu bản tin RSVP: thiết lập dự trữ (reservation setup), tear down, và error.
RSVP-TE cũng định nghĩa thêm bản tin Hello.
RSVP là giao thức cho phép các ứng dụng thông báo các yêu cầu về QoS với mạng và mạng sẽ đáp ứng bằng những thông báo thành công hoặc thất bại.
RSVP phải mang các thông tin sau:
- Thông tin phân loại, nhờ nó mà các luồng lưu lượng với các yêu cầu QoS cụ thể có thể được nhận biết trong mạng. Thông tin này bao gồm địa chỉ IP phía gửi và phía nhận, số cổng UPD.
- Chỉ tiêu kỹ thuật của luồng lưu lượng và các yêu cầu QoS, theo khuôn dạng Tspec và Rspec, bao gồm các dịch vụ yêu cầu (có bảo đảm hoặc tải điều khiển).
Rừ ràng là RSVP phải mang những thụng tin này từ cỏc mỏy chủ tới tất cả các tổng đài chuyển mạch và các bộ định tuyến dọc theo đường truyền từ bộ gửi đến bộ nhận, vì vậy tất cả các thành phần mạng này phải tham gia vào việc đảm bảo các yêu cầu QoS của ứng dụng.
RSVP mang các thông tin trong hai loại bản tin cơ bản là: PATH và RESV.
Các bản tin PATH truyền từ bộ gửi tới một hoặc nhiều bộ phận có chứa Tspec và các thông tin phân loại do bộ gửi cung cấp. Một bản tin PATH bao giờ cũng được gửi tới một địa chỉ được gọi là địa chỉ phiên, nó có thể là địa chỉ Unicast hoặc Multicast. Chúng ta thường xẹm phiên đại diện cho một ứng dụng đơn, nó được xác nhận bằng một địa chỉ đích và số cổng đích sử dụng riêng cho ứng dụng.
Khi bộ nhận nhận được bản tin PATH, nó có thể gửi bản tin RESV trở lại cho bộ gửi. Bản tin RESV xác nhận phiên có chứa thông tin về số cổng dành riêng
SVTH: Phạm Thanh Hải Trang 56 GVHD: ThS. Đào Minh Hưng
và Rspec xác nhận mức QoS mà bộ nhận yêu cầu. Nó cũng bao gồm một vài thông tin xem xét những bộ gửi nào được phép sử dụng tài nguyên đang được cấp phát.
Hình 2.18 biểu diễn trình tự bản tin trao đổi giữa bộ gửi và nhận. Ở đây lưu ý rằng các cổng dành riêng là đơn công. Nếu cần sử dụng các cổng dành riêng song công (ví dụ như phục vụ cho thoại truyền thống) thì phải có các bản tin bổ sung theo chiều ngược lại. Cũng chú ý rằng các bản tin được nhận và chuyển tiếp bởi tất cả các bộ định tuyến dọc theo đường truyền thông tin, do đó việc cấp phát tài nguyên có thể được thực hiện tại tất cả các nút mạng cần thiết.
Khi các cổng dành riêng được thiết lập, các bộ định tuyến nằm giữa bộ gửi và bộ nhận sẽ xác định các gói tin thuộc cổng dành riêng nào nhờ việc kiểm tra năm trường trong phần mào đầu của IP và giao thức truyền tải đó là: địa chỉ đích, số cổng đích, số giao thức (ví dụ UDP), địa chỉ nguồn và cổng nguồn. Thường gọi tập các gói tin được nhận dạng theo cách này gọi là luồng dành riêng. Các gói tin trong luồng dành riêng thường bị khống chế (đảm bảo cho luồng không phát sinh lưu lượng vượt quá so với thông báo trong Tspec) và xếp vào hàng đợi để phù hợp với yêu cầu về QoS. Ví dụ một cách để có dịch vụ bảo đảm là sử dụng các hàng đợi có trong số (WFQ), ở đây mỗi cổng dành riêng khác nhau được xem như một luồng đối với các hàng đợi, và trọng số được ấn định cho mỗi luồng phù hợp với tốc độ dịch vụ yêu cầu trong Rspec.
Đối với các luồng Unicast thì RSVP là khá đơn giản. Nó trở nên phức tạp hơn trong môi trường Multicast, bởi vì có thể có rất nhiều bộ nhận dành riêng cổng cho một phiên đơn và các bộ nhận khác nhau có thể có rất nhiều bộ nhận dành riêng cổng cho một phiên đơn và các bộ nhận khác nhau có thể yêu cầu các mức QoS khác nhau. Hiện nay MPLS chủ yếu tập trung vào các ứng dụng Unicast của RSVP mà không đi sâu vào khía cạnh Multicast của RSVP.
Điểm cuối cùng phải lưu ý về RSVP là nó là giao thức " trạng thái mềm ".
Đặc tính để phân biệt giao thức trạng thái mềm với các giao thức loại khác là trạng thái sẽ tự động hết hiệu lực sau một thời gian trừ khi nó được làm tươi liên tục theo chu kỳ. Điều đó có nghĩa là RSVP sẽ định kỳ gửi đi các bản tin PATH và RESV để làm tươi các cổng dành riêng tự động bị hủy bỏ.
Thiết bị nhận Thiết bị gửi PATH
RESV
Hình 2.18 : Các bản tin PATH truyền từ bộ gửi tới bộ nhận và các bản tin RESV truyền theo hướng ngược lại
2.5.1. Các bản tin thiết lập dự trữ RSVP
RSVP sử dụng khái niệm dự trữ ở đầu nhận. Trước tiên, đầu gửi phát ra một bản tin PATH nhận diện một luồng và các đặc tính lưu lượng của nó. Bản tin PATH chứa một session-ID, sender-template, label-request, sender-Tspec và tùy chọn là đối tượng tuyến tường minh ERO (explicit route object). Session-ID chứa một địa chỉ IP đích đi kèm một nhận dạng hầm 16 bit (tunnel ID) để nhận diện một đường hầm LSP. Như đã trình bày ở chương trước, chỉ có ingress-LSP mới cần biết về FEC được gán vào một đường hầm LSP. Do đó, không giống như LDP, FEC ánh xạ vào đường hầm LSP không bao gồm trong bất kỳ bản tin RVSP nào. Đối tượng label-request hỗ trợ chế độ công bố nhãn theo yêu cầu. Sender-template chứa địa chỉ IP của đầu gởi đi kèm với một LSP ID có hỗ trợ phương thức “make-before- break” khi thay đổi đường đi của một đường hầm LSP. Đặc tính lưu lượng Tspec sử dụng tốc độ đỉnh (peak rate), thùng token (token bucket) để định nghĩa tốc độ và kích cỡ bùng phát, đơn vị khống chế tối thiểu (minimum policed unit) và kích thước gói tối đa.
Khi bản tin PATH đi đến đích, bên nhận đáp ứng bằng một bản tin RESV nếu nó đồng ý khởi tạo việc gán kết nhãn được yêu cầu trong bản tin PATH. Bản tin RESV được truyền về theo đường ngược chiều với bản tin PATH bằng cách dùng thông tin hop kề trước trong bản tin PATH. RESV cũng chứa cùng session-ID như ở bản tin PATH tương ứng, đối tượng ghi tuyến tùy chọn (route record) và thông tin lệ thuộc kiểu dự trữ (reservation style). Kiểu FF (fixed filter) có một nhãn và Tspec được ấn định cho mỗi cặp sender-receiver. Kiểu SE (shared explicit) ấn định một nhãn khác nhau cho mỗi sender, nhưng tất cả chúng phải áp dụng cùng một dự trữ luồng rừ ràng. Đối tượng record-route ghi nhận tuyến đường thực tế được chọn bởi LSP bắt đầu từ egress dẫn ngược về ingress. Nó có thể được một router dùng để ghim một tuyến tường minh thả lỏng bằng cách copy tuyến ghi được trong bản tin RESV sang đối tượng tuyến tường minh ERO trong một bản tin PATH được gửi theo chiều ngược lại.
2.5.2. Các bản Tear Down, Error và Hello của RSVP-TE
RSVP-TE định nghĩa 2 bản tin dành cho việc giải tỏa LSP là PATH TEAR và RESV TEAR. Hai bản tin này được gửi theo chiều ngược với bản tin PATH và
SVTH: Phạm Thanh Hải Trang 58 GVHD: ThS. Đào Minh Hưng
RESV tương ứng. Bản tin TEAR xóa bỏ bất kỳ trạng thái đã cài đặt liên quan đến bản tin PATH hay RESV. Các bản tin TEAR cũng có thể dùng để xóa các trạng thái đáp ứng cho một lỗi ở bước đầu tiên trong hoạt động tái định tuyến.
Có các bản tin thông báo lỗi cho bản tin PATH và RESV cũng như bản tin RESV CONFIRMATION tùy chọn. Các bản tin lỗi cho biết có sự vi phạm chính sách, mã hóa bản tin hoặc một số sự cố khác. Ví dụ, khi một LSP thấy rằng nó không thể hỗ trợ Tspec đặc tả trong một bản tin RESV, nó sẽ không chuyển tiếp bản tin RESV về cho phía upstream, thay vào đó nó tạo ra một bản tin RESVERR gửi cho phía downstream để xóa bỏ nỗ lực thiết lập LSP. Tuyến tường minh và các tùy chọn record-route của RSVP-TE có một số các mã lỗi để phục vụ cho việc sửa lỗi (debug).
RFC 3209 định nghĩa bản tin Hello tùy chọn cho RSVP-TE. Nó cho phép một LSR phát hiện một neighbor bị lỗi nhanh hơn khi so với RSVP làm tươi tình trạng hoặc phát hiện lỗi đường truyền bằng một giao thức định tuyến IP. Điều này khá hữu ích trong việc tái định tuyến nhanh.
2.5.3. Thiết lập tuyến tường minh trong điều khiển tuần tự theo yêu cầu
Hình 2.19 dưới đây mô tả ví dụ việc trao đổi bản tin RSVP-TE sử dụng đối tượng tuyến tường minh ERO (explicit route object) để cài đặt một LSP đi qua một con đường không phải là đường ngắn nhất. Router R1 xác định rằng nó sẽ ấn định FEC “a.b/16” cho một đường hầm LSP, và nó tính ra một tuyến tường minh R4-R5- R3 để đi đến hop kế cho FEC đó. R1 khởi tạo việc thiết lập LSP này bằng cách phát ra một bản tin PATH đến R4 với một ERO, Tspec, sender template (có chứa địa chỉ của sender) và một đối tượng label request. Mỗi bản tin RESV liên quan đến đường hầm LSP này đều mang session-ID và filter-spec nguyên thủy của sender R1 để giữ mối tương quan với nhau. Tiếp theo, R4 tiếp nhận yêu cầu này và gửi bản tin PATH đến router kế tiếp ghi trong ERO là R5. Đến lượt mình, R5 gửi bản tin này đến egress-router R3.
Tại đích đến của bản tin PATH, R3 xác định rằng liên kết chặng R3-R5 có thể hỗ trợ cho yêu cầu và đó là hop cuối cùng trên đường dẫn cho FEC “a.b/16”. R3 đáp ứng bằng bản tin RESV có chứa ERO, Tspec của dung lượng dự trữ, một filter spec thỏa mãn bên gửi, và gán một nhãn null ngầm (implicit null) cho chặng liên kết này. Theo RFC 3031, nhãn null là một quy ước được dùng trong phân phối nhãn cho phép egress-router (ở đây là R3) báo hiệu cho đối tác upstream của nó biết rằng
đây là hop áp cuối (penultimate hop) của LSP, do vậy cần gỡ nhãn đỉnh của stack (xem LFIB của LSR R5). Tiếp theo, R5 thu nạp bản tin RESV yêu cầu cho chặng R5-R4, ấn định nhãn B và gởi bản tin RESV đến router kề trước trong ERO là R4.
Cuối cùng, R4 chấp nhận yêu cầu, ấn định nhãn A và gởi bản tin RESV ngược về R1. Đến lúc này, đường LSP được thiết lập xong và các gói có nhãn cho FEC
“a.b/16” được chuyển tiếp qua đường hầm.
Khác với giao thức LDP, các bản tin RSVP-TE không mang FEC, vì chỉ duy nhất có R1 cần biết về ánh xạ giữa FEC và đường hầm LSP.
Hình 2.19 : Thiết lập LSP với RSVP-TE 2.5.4. Giảm lượng overhead làm tươi RSVP
RSVP là giao thức trạng thái mềm (soft-state), tiến trình phát một bản tin PATH và bản tin RESV hồi đáp tương ứng phải được định kỳ làm tươi, thường khoảng 30s một lần. Phương pháp làm tươi này đề phòng các bản tin bị mất và trong trường hợp định tuyến từng chặng sẽ tự động chuyển dự trữ tài nguyên sang đường mới khi có bất kỳ thay đổi định tuyến IP. Tất nhiên, việc xử lý dành cho khởi tạo các bản tin PATH và RESV lớn hơn nhiều so với việc làm tươi trạng thái một bản tin đã nhận trước đó, tuy nhiên với một số lượng lớn các LSP thì việc xử lý làm tươi có ảnh hưởng đáng kể đến hiệu năng.
Một cách để giải quyết là tăng chu kỳ làm tươi, nhưng cũng sẽ làm tăng độ trễ báo hiệu khi mất bản tin. RFC 2961 đặc tả một giải pháp cho hạn mức xử lý và vấn đề trễ báo hiệu. Cơ chế này bao gồm việc bó gọn bản tin để giảm tải xử lý, cũng
SVTH: Phạm Thanh Hải Trang 60 GVHD: ThS. Đào Minh Hưng
như các cách để router dễ dàng nhận dạng một bản tin không thay đổi hơn. Việc hồi báo bản tin cũng được bổ sung để chuyển tải tin cậy bản tin RSVP và xử lý trường hợp mất các bản tin PATH TEAR và RESV TEAR vì hai bản tin này không được làm tươi trong hoạt động RSVP. Cuối cùng, giải pháp này định nghĩa một bản tin tổng kết (summary) để làm tươi trạng thái mà không yêu cầu truyền toàn bộ bản tin làm tươi. Các cải tiến này nhằm giảm lượng overhead làm tươi của RSVP trong mạng MPLS.
2.5.5. RSVP và khả năng mở rộng
Một trong những điều chắc chắn về RSVP là nó có thể chịu tổn thất về khả năng mở rộng ở một mức nào đấy. Trong thực tế, đặc tính này không chính xác hoàn toàn. RSVP khởi đầu được thiết kế để hỗ trợ dự trữ tài nguyên cho các luồng ứng dụng riêng và đây là nhiệm vụ với những thách thức về khả năng mở rộng vốn có.
Nói chung thuật ngữ này được sử dụng để chỉ giới hạn sử dụng tài nguyên tăng nhanh như thế nào khi mạng phát triển. Ví dụ: Trong mạng IP quy mô lớn như mạng xương sống nhà cung cấp dịch vụ Internet, chúng ta có thể quan tâm đến việc liệu một bảng định tuyến sẽ chiếm bộ nhớ của bộ định tuyến lớn đến mức nào, khả năng bộ xử lý và băng thông liên kết. Vì thế, bảng định tuyến tăng chậm hơn nhiều so với số người sử dụng kết nối vào mạng.
Dự trữ tài nguyờn cho cỏc luồng ứng dụng riờng rừ ràng là ảnh hưởng xấu đến khả năng mở rộng. Có thể cho rằng mỗi người sử dụng sẽ dự trữ tài nguyên tại một vài tốc độ trung bình, vì thế số tài nguyên dự trữ được tạo ra qua mạng lớn có khả năng tăng nhanh bằng số người sử dụng của mạng. Điều này sẽ dẫn đến chi phí lớn nếu mỗi bộ định tuyến phải lưu trữ trạng thái và tiến trình một vài bản tin cho mỗi tài nguyên dự trữ cho luồng ứng dụng riêng.
Nói tóm lại, sẽ chính xác hơn nếu nói rằng mức dự trữ tài nguyên cho các luồng ứng dụng là kém hơn so với RSVP. Sự khác nhau này đặc biệt quan trọng khi xem xét rằng RSVP không những đòi hỏi cho việc dự trữ tài nguyên cho các luồng ứng dụng riêng mà còn dự trữ tài nguyên cho lưu lượng tổng hợp.