Tweet
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 ràng buộ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 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ỏ.
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
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 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ỏ.
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
Lê Huy – VnPro