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
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
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
