RSVP có một 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. Nguyên lý chức năng của RSVP là thiết lập các dự trữ cho các 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 tuỳ chọn tuyến t-ờng minh. 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.
a. 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.
b. 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à 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 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.
c. Thiết lập tuyến t-ờng minh điều khiển tuần tự theo yêu cầu
Hình 32 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 mangsession-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 egressrouter (ở đâ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.
Hình 32: Thiết lập LSP với RSVP-TE
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.
d. 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 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.