yờu cầu
Hỡnh 2.19 dưới đõy mụ tả 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 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 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 egress-router (ở đõ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.
Hỡnh 2.19 : Thiết lập LSP với RSVP-TE