Hình 2-17 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, sau đó 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ữ
Hình 2-17: Thiết lập LSP với RSVP-TE
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.
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.