Hình 3.15 là ví dụ về việc trao đổi bản tin RSVP-TE sử dụng đối tượng tuyến tường minh ERO (expplicit route object) để cài đặt một LSP đi qua một con đường không phải là đường ngắn nhất. Bộ định tuyến 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 chặng 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 bộ định tuyến kế tiếp ghi trong ERO là R5. Đến lượt mình, R5 gửi bản tin này đến lối ra của bộ định tuyến 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à chặng cuối cùng trên đường dẫn 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 thời RFC 3031, nhãn null là một quy ước được dùng trong phân phối nhãn cho phép lối ra của bộ định tuyến (ở đây là R3) báo hiệu cho đối tác đường lên của nó biết rằng đây là chặng áp cuối (penulitmate hop) của LSP, do vậy cần gỡ nhãn đỉnh của ngăn xếp. Tiếp theo, R5 thu nạp 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.