Tweet
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:
- 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:
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.
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
Đị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
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.
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)
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:
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.
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
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ảnMỗ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
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
Comment