KỸ THUẬT LƯU LƯỢNG TRONG MPLS - Tính toán và thiết lập tuyến ppsx

Thuật toán CSPF (Constrained shorted path first)
Hoạt động của CSPF
Có hai điểm khác biệt đáng quan tâm giữa SPF bình thường do các giao thức định tuyến
thực hiện và CSPF của MPLS TE.
Thứ nhất, tiến trình thiết lập tuyến không được thiết kế để tìm ra đường đi tốt nhất đến
mọi bộ định tuyến mà chỉ đến điểm cuối đường hầm (tunnel endpoint).
Thứ hai, thay vì chỉ quan tâm đến một loại chi phí trên kết nối giữa hai láng giềng còn
phải quan tâm đến:
- Băng thông (bandwidth)
- Các thuộc tính kết nối (link attributes)
- Trọng số quản trị (Administrative weight)
Bốn thuộc tính được thể hiện trong danh sách PATH/TENT:
{link, cost, next hop, available bandwidth}
Các bước thực hiện thuật toán CSPF như sau:
- Bước 1: Một nút tự đưa thông tin của chính mình vào danh sách PATH với cost = 0,
next hop là chính nó và thiết lập băng thông = N/A.
- Bước 2: Xem xét nút vừa vào danh sách PATH, và gọi nó là nút PATH. Kiểm tra danh
sách các nút láng giềng của nó. Thêm mỗi láng giềng vào danh sách TENT với một next
hop của nút PATH, trừ khi nút láng giềng đã có có danh sách TENT hoặc PATH với chi
phí thấp hơn. Không thêm đường đi này vào TENT trừ khi nó được cấu hình ràng buộc
cho đường hầm – băng thông (bandwidth) và quan hệ (affinity). Nếu nút vừa được thêm
vào danh sách TENT đã có trong danh sách, nhưng với một chi phí cao hơn hoặc thấp
hơn băng thông tối thiểu, thay thế đường đi có chi phí cao hơn bằng đường hiện tại.
- Bước 3: Tìm láng giềng trong danh sách TENT với chi phí thấp hơn, thêm láng giềng
đó vào danh sách PATH, và lặp lại bước 2. Nếu TENT rỗng hoặc trên PATH còn lại nút
ở cuối đường hầm thì dừng.
Ví dụ: Minh họa thuật toán CSPF
Hình 3.1: Mô hình mạng đơn giản minh họa thuật toán CSPF
Quan sát hình 3.1 ta thấy, bộ định tuyến A muốn tạo một đường hầm TE đến bộ định
tuyến D với băng thông 60 Mbps. Mỗi kết nối liệt kê metric và băng thông sẵn có của nó.
Dễ thấy, đường đi tốt nhất từ bộ định tuyến A đến bộ định tuyến D là A->B->C->D, với

tổng chi phí bằng 12. Nhưng không thỏa băng thông có sẵn bằng 60 Mbps. CSPF cần tính
lại đường đi ngắn nhất với băng thông có sẵn 60 Mbps.
- Bước 1: Đặt “chính nó” vào PATH với giá trị đường đi = 0, nexthop = self, bandwidth
= N/A.
- Bước 2: Đặt các láng giềng của bộ định tuyến A vào TENT.
- Bước 3: Chuyển B từ PATH sang TENT, và đặt láng giềng của B vào TENT.
- Bước 4: Đặt láng giềng của B vào TENT, và chuyển C từ TENT sang PATH.
- Bước 5: Lấy D khỏi TENT. Lúc này, đườc đi tốt nhất đến D nằm trong PATH. Trường
hợp này TENT rỗng; D trở thành nút cuối cùng được xem xét trong SPF. Nếu tìm được
đường đi tốt nhất đến D mà vẫn còn nút trong TENT, thì bạn vẫn dừng thuật toán ở đây.
Trong thực tế việc tính toán phức tạp hơn nhiều. CSPF phải lưu giữ mọi nút trên đường
đi, không chỉ là nút kế tiếp. Cũng như, không chỉ quan tâm đến băng thông mà còn xem
xét đến các thuộc tính kết nối và các phương pháp quyết định (tiebreakers).
Các phương pháp quyết định trong CSPF (Tiebreakers in CSPF)
SPF thông thường (dùng trong OSPF, IS-IS) có thể sử dụng nhiều đường đi đến đích có
cùng chi phí. Điều này thỉnh thoảng được gọi là Nhiều đường đi cùng chi phí (ECMP –
Equal-Cost MultiPath), và nó rất hữu dụng trong giao thức định tuyến nội (IGP – Interior
Gateway Protocol).
Tuy nhiên trong CSPF, không được tính mọi đường đi tốt nhất đến mọi đích có thể. Bạn
phải tìm một đường đi đến một đích. Bạn sẽ làm gì khi đặt một nút vào TENT và nút đó
đã có trong TENT với cùng chi phí? Bạn cần tìm ra một cách để phân biệt các đường đi
với nhau.
Đây là các phương pháp quyết định đường đi có cùng chi phí:
1. Chọn đường đi có băng thông có sẵn tối thiểu rộng nhất.
2. Nếu vẫn chưa được, chọn đường đi có hop count thấp nhất (số lượng bộ định tuyến
trong đường đi).
3. Nếu vẫn chưa thõa, chọn đường đi ngẫu nhiên.
Ghi chú:
Mọi thứ không thực sự là “ngẫu nhiên”. Khi xem xét xa hơn trong quá trình quyết định,
bạn chọn đường đi trên cùng (top path) trong PATH. Không “ngẫu nhiên” khi mọi đường

đi có thể có một cơ hội được lựa chọn, nhưng chọn ngẫu nhiên với đường đi cuối cùng
(ends up on the top) của PATH có cấu trúc độc lập và được thực thi độc lập.
Các phương pháp này đưa ra cho một nút trong TENT. Tại một thời điểm nào đó, một nút
chỉ nên được liệt kê một lần trong TENT. Đây là sự khác biệt với IGP SPF – có thể chọn
nhiều đường cho một nút và chia tải giữa chúng.
Tối ưu hóa lại đường hầm
Điều gì xảy ra nếu trong lúc một đường hầm đang hoạt động, một đường đi khác tốt hơn
xuất hiện. Xem xét hình 3.2:
Hình 3.2: Đường đi mới là một đường hầm TE tốt hơn
Trong hình 5:
- Tất cả kết nối bắt đầu với băng thông dành riêng là 100 Mbps
- Cả bộ định tuyến A và D đều muốn xây dựng đường hầm 60 Mbps đến bộ định tuyến H
- Kết nối giữa bộ định tuyến D và bộ định tuyến H bị đứt.
Ta thấy các sự kiện sau có thể xảy ra:
- bộ định tuyến D tạo đường hầm: D → C → H
- bộ định tuyến A tạo một đường hầm : A → B → C → E → F → G → H
- bộ định tuyến D giảm băng thông dành riêng trên đường D → C → H xuống 30 Mbps
bằng cách cấu hình hoặc điều chỉnh băng thông tự động.
Khi một bộ định tuyến tìm thấy một đường đi tốt hơn đường hầm đã được lập thì được
xem là reoptimization. 4 yếu tố tác động đến reoptimization:
- Tối ưu hóa lại định kỳ (periodic reoptimization)
- Tối ưu hóa lại bằng nhân công (manual reoptimization)
- Tính lại hướng theo sự kiện (Event-driven reoptimization)
Reoptimization không được thực hiện khi đường hầm bị down. Nếu một đường bị down
thì không cần đợi bộ định thời reoptimization (reoptimization timer) kích hoạt trước khi
tìm ra đường hầm mới mà việc tính toán sẽ được thực hiện ngay lập tức.
RSVP-TE có một cơ chế gọi là make-before-break để thực hiện tạo một đường hầm dành
riêng mới mà không làm xáo trộn bất kỳ sự dành riêng đường hầm nào dang tồn tại.
Tối ưu hóa lại định kỳ (periodic reoptimization)
Cisco thực thi một bộ định thời tối ưu hóa lại định kỳ (periodic reoptimization timer), nó

có thể được cấu hình toàn cục. Sau khi một đường hầm đi vào hoạt động, tiến hành một
sự cố gắng tìm ra một đường đi mới cho nó, theo các ràng buộc được cấu hình của đường
hầm. Ngầm định, việc này được thực hiện 1 lần mỗi giờ; Bộ định thời này được cấu hình
bằng lệnh mpls traffic-eng tunnels reoptimize timers frequency 0-604800. 0-604800 là
thời gian tính bằng giây mà Cisco IOS Software tìm kiếm một đường đi tốt nhất cho một
đường hầm.
Thiết lập bộ định thời này bằng 0 nghĩa là đường hầm không bao giờ reoptimize sau khi
chúng được thiết lập.
Ghi chú: dù reoptimization timer chỉ được cấu hình toàn cục nhưng được lưu theo từng
đường hầm. Giả sử, có 20 đường hầm khác nhau (từ T1 đến T20), mỗi đường hầm được
thiết lập cách nhau 2 phút (T1 thiết lập tại 00:00, T2 là 00:02,…T20 lúc 00:40). 20 phút
sau đó bộ định thời reoptimization toàn cục (global reoptimization timer) cho T1 kích
hoạt và cố tìm một đường đi tốt hơn, nhưng chỉ cho T1. T20 không thực hiện reoptimize
đến thời điểm sau khi nó được thiết lập 1 giờ (01:40).
Tối ưu hóa lại bằng nhân công (manual reoptimization)
Khi có một thay đổi trong mạng mà bạn không muốn đợi reoptimization timer của đường
hầm kích hoạt trước khi tìm ra đường đi tốt hơn, bạn có thể sử dụng lệnh mức enable
(enable-level) mpls traffic-eng reoptimize [tunnel-name] để buộc bộ định tuyến thực hiện
reoptimize một đường hầm cụ thể tại bất kỳ lúc nào.
Tối ưu hóa hướng theo sự kiện (Event-driven reoptimization)
Hãy xem kết nối giữa RtrD và RtrH trong hình 5. Nếu kết nối hoạt động, RtrD có nên
reoptimize đường hầm D → H của nó để đường hầm này đi qua đường kết nối trực tiếp
này? Có thể! Nhưng có một cách mà một kết nối thiết lập nhưng không cần kích hoạt một
reoptimization.
Cú pháp lệnh:
Code:
mpls traffic-eng reoptimize events link-up
Giao thức chiếm trước tài nguyên (RSVP - Resource Reservation Protocol)
RSVP là một cơ chế báo hiệu dùng để dành riêng tài nguyên trên một mạng. RSVP
không phải là một giao thức định tuyến. Việc quyết định tuyến do IGP (gồm cả các mở

rộng TE) và CSPF.
Công việc của RSVP là báo hiệu và duy trì tài nguyên dành riêng qua một mạng. Trong
MPLS TE, RSVP dự trữ băng thông tại mặt phẳng điều khiển (control-plane layer);
không có chính sách lưu lượng trên mặt phẳng chuyển tiếp (forwarding-plane). Khi sử
dụng cho các mục đích khác (như VoIP hay DLSW+reservations), RSVP có thể được
dùng để dành riêng không gian hàng đợi công bằng có trọng số (WFQ – Weighted Fair
Queuing) hay xây dựng các ATM SVC.
RSVP có ba chức năng cơ bản:
- Thiết lập và duy trì đường đi (Path setup and maintenance)
- Hủy đường đi (Path teardown)
- Báo lỗi (Error signalling)
RSVP là một giao thức trạng thái mềm (soft-state protocol). Nghĩa là cần tái báo hiệu
trên mạng để làm tươi định kỳ cho nó. Với RSVP, một yêu cầu bị hủy nếu nó được chỉ
định xóa khỏi mạng bằng RSVP hay hết thời gian dành riêng (reservation times out).
Bảng3.2: Liệt kê chín loại thông điệp RSVP khác nhau được định nghĩa
Các chức năng của RSVP
+Thiết lập và duy trì đường đi
Thiết lập đường đi (Path Setup):
Sau khi đầu đường hầm (tunnel headend) hoàn thành CSPF cho một đường hầm cụ thể,
nó gửi một thông điệp Path đến nút kế tiếp (next-hop) dọc theo đường đi đã tính toán đến
đích. LSR gửi thông điệp Path được gọi là LSR ngược dòng (upstream router), và LSR
nhận thông điệp được gọi là LSR xuôi dòng (down-stream router) hay trạm trước đó
( phop – previous hop).
Sau khi LSR xuôi dòng nhận một thông điệp Path, nó kiểm tra định dạng của thông điệp,
sau đó kiểm tra lượng băng thông mà thông điệp yêu cầu. Tiến trình này được gọi là điều
khiển nhấp nhận (admission control).
Nếu việc kiểm tra này thành công và thông điệp Path được phép dành riêng băng thông
như nó yêu cầu, LSR xuôi dòng tạo một thông điệp Path mới và gửi đến nút kế trong đối
tượng tuyến tường minh (ERO – Explicit Route Object). Thông điệp Path tiếp tục được
chuyền đi đến khi nào chúng đến được nút cuối cùng trong ERO – đuôi đường hầm

MPLS TE (tunnel tail).
Đuôi đường hầm thực hiện điều khiển chấp nhận trên thông điệp Path giống như các LSR
xuôi dòng khác. Khi nó nhận ra rằng nó là đích đến của thông điệp Path nó trả lời lại
bằng thông điệp Resv. Resv đóng vai trò như là một ACK báo về cho LSR ngược dòng.
Resv chứa một thông báo rằng thõa mãn sự dành riêng đến cuối đường hầm và thông tin
nhãn đến (incoming label) cho LSR ngược dòng sử dụng để gửi các gói dọc theo TE LSP
đến đích. Hình 3.3 cho thấy sự trao đổi các thông điệp RSVP Path và Resv trong suốt quá
trình thiết lập LSP.
Thông điệp RSVP Path và Resv trong quá trình thiết lập LSP
Hình 3.3 có 10 bước. Giả sử rằng R1 thực hiện CSPF xong và biết rằng nó muốn dành
riêng băng thông dọc theo đường R1 → R2 → R3 → R5 → R6 → R7:
1. R1 gửi một thông điệp Path đến R2. R2 nhận thông điệp Path , kiểm tra cú pháp thông
điệp và kiểm ra bằng bộ quản lý kết nối TE (TE Link Manager) để chắc rằng băng thông
mà R1 yêu cầu hiện đang có sẵn. Nếu xảy ra lỗi R2 gửi thông điệp Error lại cho R1. Giả
sử mọi thứ đều tốt thì chuyển sang bước 2.
2. R2 gửi thông điệp Path đến R3. R3 thực hiện kiểm tra giống R2.
3. R3 gửi thông điệp Path đến R4. R4 thực hiện kiểm tra giống R3.
4. R4 gửi thông điệp Path đến R5. R5 thực hiện kiểm tra giống R4.
5. R5 gửi thông điệp Path đến R6. R6 thực hiện kiểm tra giống R5.
6. R7, đuôi của đường hầm, gửi một thông điệp Resv đến R6. Resv chỉ định nhãn R7
muốn thấy trên gói đến; vì R7 là đuôi nên nó gửi implicit-null.
7. R6 gửi một thông điệp Resv cho R5 và chỉ định nó muốn thấy nhãn đến là 42 cho
đường hầm này. Nghĩa là khi R6 nhận nhãn 42, nó thực hiện hủy nhãn (vì implicit-null)
và gửi thông điệp về cho R7.
8. R5 gửi thông điệp Resv cho R3, báo hiệu nhãn 10921. Khi R5 nhận một gói với nhãn
10921, nó đổi (swap) nhãn đó thành nhãn 42 và gửi gói đến R6.
9. R3 gửi một thông điệp Resv cho R2, báo hiệu nhãn 21.
10. R2 gửi một thông điệp Resv cho R1, báo hiệu nhãn 18.
Lúc này, R1 nhận một thông điệp Resv cho đường hầm đến R7 và nó biết nhãn ra
(outgoing label) nào được sử dụng. Giao tiếp đường hầm trên R1 trở thành up/up (trước

thời điểm này là up/down).
Duy trì đường đi (Path Maintenance)
Thoạt nhìn, việc duy trì đường đi giống như thiết lập đường đi. Mỗi 30 giây đầu đường
hầm gửi một thông điệp Path đến láng giềng xuôi dòng của nó. Nếu một LSR gửi đi một
dãy 4 thông điệp Path và không thấy Resv, nó nghĩ rằng sự dành riêng bị mất và gửi một
thông điệp ngược dòng (message upstream) báo rằng sự dành riêng bị mất.
Các thông điệp Path và Resv được gửi độc lập và bất đồng bộ giữa các láng giềng với
nhau. Mỗi 30 giây, R1 gửi thông điệp Path cho một sự dành riêng của nó tới R2. Và mỗi
30 s, R2 gửi một thông điệp Resv đến R1 với cùng sự dành riêng đó. Tuy nhiên hai thông
điệp này không liên hệ nhau. Thông điệp Resv được dùng để làm tươi (refresh) một sự
dành riêng dang tồn tại chứ không phải trả lời cho thông điệp Path.
+Hủy đường đi
Nếu một nút (thường là đầu đường hầm) quyết định một sự dành riêng không còn cần
thiết trong mạng, nó gửi một thông điệp PathTear dọc theo đường thông điệp Path đã đi
và một ResvTear dọc theo đường của Resv.
Thông điệp ResvTear được gửi để hồi đáp cho PathTear báo hiệu đuôi đường hầm.
PathTear và ResvTear cũng được gửi để trả lời một điều kiện lỗi trong mạng.
Không giống thông điệp làm tươi, PathTear không cần đi đến hết downstream trước khi
nhận được kết quả. Trong hình 1, nếu R1 gửi PathTear đến R2, ngay lập tức R2 trả lời
bằng một ResvTear, sau đó gửi PathTear xuôi dòng của nó
+Báo lỗi
Thỉnh thoảng, tín hiệu RSVP có thể bị lỗi. Các lỗi này được báo hiệu bằng thông điệp
PathErr hay ResvErr. Thông điệp lỗi được gửi ngược dòng về phía nguồn của lỗi; một
PathErr được gửi ngược dòng từ một nút xuôi dòng và một ResvErr được gửi xuôi dòng
từ một nút ngược dòng.
Các gói RSVP
Định dạng gói RSVP khá đơn giản. Mỗi thông điệp RSVP gồm có một tiêu đề chung
(common header), theo sau là một hoặc nhiều đối tượng. Số lượng đối tượng phụ thuộc
vào thông điệp đang cố hoàn thành.
Tiêu đề chung RSVP

Hình 3.4. Định dạng RSVP common header
Bảng 3.3: Các trường trong tiêu đề chung RSVP
Định dạng lớp đối tượng RSVP
Các đối tượng RSVP có cùng định dạng cơ bản, như trong hình 4-13
Hình 3.5. Định dạng đối tượng RSVP
Bảng 3.4: Mô tả các trường trong định dạng đối tượng RSVP cơ bản
Mỗi lớp có không gian chỉ số C-Type của riêng nó. Các chỉ số C-Type là duy nhất trong
một lớp.
Ví dụ: lớp SESSION có 4 loại C-Types: IPv4, IPv6, LSP_TUNNEL_IPv4, và
LSP_TUNNEL_IPv6. Các chỉ số được gán cho C-Types này là 1, 2, 7, and 8.
LABEL_REQUEST có 3 C-Types: Without Label Range, With ATM Label Range, và
With Frame Relay Label Range. Các số được gán là 1, 2, và 3. Nếu chỉ có C-Type = 1 thì
không đủ để xác định duy nhất nội dung một thông điệp; Bạn cần phải xem xét cả lớp và
chỉ số C-Type.
Một thông điệp RSVP chứa một hoặc nhiều đối tượng. Số đối tượng trong thông điệp phụ
thuộc vào định nghĩa của thông điệp.
Bảng 3.5: Các lớp và C-Types được dùng trong RSVP-TE của Cisco
Ghi chú: tham khảo định dạng cụ thể của các lớp đối tượng của RSVP trong phụ lục D
Hoạt động của RSVP
Make-Before-Break
Make-before-break là một cơ chế RSVP-TE cho phép thay đổi một số đặc tính của đường
hầm TE (tên, băng thông và đường đi) mà không làm mất dữ liệu và không cần double-
booking bandwidth.
Hình 3.6. Mạng có Make-Before-Break
Băng thông được chỉ định trước khi bất kỳ băng thông nào được được dành riêng từ
mạng.
Nếu R1 truyền tính hiệu yêu cầu 35 Mb đến mạng, nó đi trên đường R1 → R2 → R5.
Còn lại băng thông có sẵn trên R1 → R2 10 Mb và trên R2 → R5 65 Mb.
Điều gì xảy ra nếu R1 muốn tăng kích thước băng thông dành riêng của nó lên 80 Mb?
Băng thông này phải đi từ đường dưới vì không có cách nào lấy được băng thông dành

riêng 80 Mb trên đường R1 → R2 → R5. Còn lại băng thông có sẵn 20 Mb trên mỗi kết
nối của đường dưới. Trong một khoảng thời gian ngắn, R1 dành riêng băng thông qua cả
hai đường và vì thế dành riêng tổng cộng là 115 Mb (35 Mb đường trên và 80 Mb qua
đường dưới). Tuy nhiên, sự dành riêng 35 Mb sớm được giải phóng sau khi sự dành riêng
80 Mb được tạo ra.
Nguyên tắc của make-before-break làm cho đầu đường hầm (tunnel headend) không giải
phóng sự dành riêng cũ đến khi có sự dành riêng mới thay thế giúp giảm tối thiểu việc
mất dữ liệu.
++Kiểu dành riêng chia sẻ tường minh (Shared Explicit Reservation Style)
Hình 3.7. Sự cần thiết cho Make-Before-Break
Tương tự như trên, R1 cố gắng dành riêng 80 Mb qua R1 → R3 → R4 → R2 → R5.
Nhưng không thể! Vì hiện giờ băng thông có sẵn trên R2 → R5 chỉ còn 65 Mb!
R1 có thể teardown dành riêng trên đường R1 → R2 → R5 và sau đó xây dựng sự dành
riêng trên R1 → R3 → R4 → R2 → R5. Không nên thực hiện như vậy!!!
Có cách tốt hơn để khắc phục hiện tượng này. RSVP có một khả năng gọi là chia xẻ
tường minh (SE – Share Explicit). SE là một kiểu dành riêng cho phép một LSP đang tồn
tại chia sẻ băng thông với chính nó để tránh xảy ra double booking.
Hoạt động SE gồm hai phần :
- Yêu cầu kiểu dành riêng SE từ mạng
- Xác định sự dành riêng yêu cầu trùng với sự dành riêng dang tồn tại để chia xẻ băng
thông
Đầu đường hầm yêu cầu kiểu dành riêng SE sử dụng một cờ (flag) trong đối tượng
SESSION_ATTTRIBUTE.
Còn một cách giải quyết khác liên quan đến SE được gọi là Bộ lọc tích hợp (FF – Fixed
Filter) nhưng không được Cisco MPLS TE thực hiện. Nó không cho phép chia xẻ băng
thông như SE nhưng cũng có thể giải quyết được hiện tượng trên.
Mọi sự dành riêng RSVP được xác định duy nhất bằng một five-tuple {Sender Address,
LSP ID, Endpoint Address, Tunnel ID, Extended Tunnel ID}. Hai mục đầu chứa trong
đối tượng SENDER_TEMPLATE (và FILTER_SPEC). 3 mục sau chứa trong đối tượng
SESSION. Nếu hai thông điệp Path có 5 mục yêu cầu này trùng nhau thì chúng cùng

quan tâm đến một sự dành riêng.
Địa chỉ người gửi (Sender Address) là RID của đầu đường hầm. Địa chỉ điểm cuối
(Endpoint Address) là RID của đuôi đường hầm. Extended Tunnel ID là 0 hoặc địa chỉ IP
trên bộ định tuyến ; nó được dùng trong một số kỹ thuật bảo vệ. Và Tunnel ID là chỉ số
giao tiếp đường hầm tại đầu đường hầm.
LSP ID như là ‘bộ đếm (instantiation counter)’ : Mỗi lần đường hầm thay đổi băng thông
yêu cầu của nó hay đường đi, LSP ID tăng lên 1.
Nguyên tắc của tiến trình dành riêng ES cho MPLS TE là nếu hai sự dành riêng có các
phần trong five-tuple giống nhau, chỉ khác khác LSP IDs, nên khác LSP nhưng chúng
được chia xẻ băng thông.
Bảng 3.6 : Các bước trong Make-Before-Break
Theo cách này cả Res1 và Res2 được phép cùng tồn tại đến khi Res1 bị xóa khỏi mạng.
Sau khi Res2 được chia xẻ băng thông với Res1, thì Res1 sẽ không cố gắng sử dụng băng
thông cùng thời điểm với Res2.
Cơ chế làm tươi
RSVP là một giao thức soft-state, sự dành riêng được làm tươi định kỳ. Sự dành riêng
được gửi bằng thông điệp Path và Resv. Việc làm tươi để kiểm tra xem sự dành riêng
đang tồn tại với five-tuple có phù lợp với yêu cầu trong thông điệp Path hay Resv không.
Hai điểm chính cần nắm khi nói đến cơ chế làm tươi là:
- Bộ định thời làm tươi được kích hoạt.
- Thông điệp Path và Resv được gửi độc lập giữa hai bộ định tuyến.
Các thông điệp Path và Resv được gửi mỗi 30 giây. Tuy nhiên không thật sự là mỗi 30s;
chúng gửi trên một bộ định thời 30s nhưng kích hoạt 50 %. Vì thế sự dành riêng đưa ra
có thông điệp Path gửi để làm tươi mỗi 15 đến 45 giây. Tương tự với thông điệp Resv.
Việc tính toán làm tươi được xác định trong RFC 2205. Thông thường một láng giềng
gửi khoảng thời gian làm tươi R (Refresh interval) tới láng giềng của nó trong đối tượng
TIME_VALUES trong thông điệp Path và Resv. Mỗi bộ định tuyến cũng biết được bao
nhiêu thông điệp sẽ được bỏ qua trước khi tuyên bố sự dành riêng mất đi (gọi là K).
Các láng giềng tính toán thời gian giữ (holdtime) thông điệp này bằng công thức:
Code:

L >= (K + 0,5) * 1,5 * R
Hiện tại, R = 30s và K = 3. Suy ra L ít nhất là 157,5 s. Nghĩa là bộ định tuyến có thể đợi
157,5 s trước khi tearing down một láng giềng.
Hình 3.8 cho thấy định thời làm tươi gủa thông điệp Path là 00:00 và 00:45, và của thông
điệp Resv là 00:15 và 00:30.
Hình 3.8. Thông điệp Path và Resv được gửi một cách độc lập