Chuyển mạch nhãn đa giao thức

0%, ngược dòng VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 119 9 1 5 95 Y 95%, ngược dòng 10 2 3 97 Y 96%, 97% 11 -3 6 94 Y 96%, 95%, xuôi dòng (3) Làn tràn những thay đổi không quan trọng một cách định kỳ, nhưng thường xuyên hơn khoảng thời gian làm tươi IGP. Thời gian định kỳ ngầm định là 180 giây (3 phút). Nhưng có thể thay đổi bằng cách cấu hình sử dụng lệnh toàn cục sau: lsr1(config)#mpls traffic-eng link-management timers periodic-flooding 0-3600 second interval Những thông tin này được làm tràn nếu băng thông có sẵn thay đổi và nó chưa được làm tràn. Công việc ngầm định là kiểm tra quản trị kết nối TE (TE link manager) mỗi 3 phút, nếu băng thông dành riêng có thay đổi trên bất kỳ kết nối nào thì làm tràn những thông tin mới về kết nối đó. Thông tin kỹ thuật lưu lượng MPLS không cần làm tràn định kỳ (3 phút) nếu không có sự thay đổi. Chỉ khi có những thay đổi trong vòng 3 phút thì được làm tràn. Chỉ làm tràn định kỳ những thông tin chưa được làm tràn (như một thay đổi băng thông không vượt qua ngưỡng làm tràn). Cài đặt mpls traffic-eng link-management timers periodic-flooding bằng 0 làm vô hiệu việc làm tràn định kỳ. Nghĩa là thông tin băng thông được làm tràn chỉ theo nguyên tắc 1 và 3. Nếu một thay đổi chưa được làm tràn thì xem như gây ra một lỗi, phải làm tràn ngay: RSVP gửi một lỗi khi một thiết lập đường đi không thành công do thiếu băng thông. Nếu một router nhận một yêu cầu dành riêng băng thông nhiều hơn băng thông hiện có trên một kết nối cụ thể, băng thông kết nối có sẵn được thay đổi tại thời điểm làm tràn thông tin gần nhất vì thế rotuer nhận được sự tiếp nhận dành riêng để bộ định tuyến gửi sự dành riêng chứa những thông tin trong cơ sở dữ liệu cấu trúc mạng (topology database) của nó và thực hiện tái làm tràn (reflood). Tính toán và thiết lập tuyến Thuật toán CSPF (Constrained Shortest 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. VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 120 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 Quan sát hình trên ta thấy, Router A muốn tạo một đường hầm TE đến router 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ừ router A đến Router 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. PATH TENT {A,0,self,N/A} (empty) Bước 2: Đặt các láng giềng của router A vào TENT. PATH TENT {A,0,self,N/A} {B,5,B,100} {C,10,C,100} Bước 3: Chuyển B từ PATH sang TENT, và đặt láng giềng của B vào TENT. PATH TENT VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 121 {A,0,self,N/A} {C,10,C,100} {B,5,B,100} {D,13,B,90} Bước 4: Đặt láng giềng của B vào TENT, và chuyển C từ TENT sang PATH. PATH TENT {A,0,self,N/A} {D,13,B,90} {B,5,B,100} 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ì vẫn dừng thuật toán ở đây. PATH TENT {A,0,self,N/A} {B,5,B,100} {C,10,C,100} {D,13,B,90} 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à 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í: - Chọn đường đi có băng thông có sẵn tối thiểu rộng nhất. - Nếu chưa được, chọn đường đi có hop count thấp nhất (số lượng router trong đường đi). - 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 đó, VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 122 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. Giả sử, trong mạng hình bên dưới bạn muốn tạo một đường hầm từ RtrA tới RtrZ với băng thông 10 Mbps. Mỗi đường đi trong mạng này phù hợp với mô tả đó. Khi đó bạn chọn đường nào? Có 5 đường có thể đi từ A đến Z, gọi là P1 đến P5 (từ trên xuống dưới). Bảng 3 liệt kê các thuộc tính đường đi. Tên đường Các router trên đường đi Chi phí Băng thông tối thiểu P1 RtrA→RtrL1→RtrR1→RtrZ 21 100 P2 RtrA→RtrL2→RtrR2→RtrZ 19 81 P3 RtrA→RtrL3→RtrM3→RtrR3→RtrZ 19 90 P4 RtrA→RtrL4→RtrR4→RtrZ 19 90 P5 RtrA→RtrL5→RtrR5→RtrZ 19 90 A lựa chọn một trong những đường sau: P1 không được sử dụng vì có chi phí đường đi cao hơn các đường khác. P2 không được chọn vì có băng thông tối thiểu là 80 Mbps, thấp hơn băng thông tối thiểu của những đường khác. P3 không chọn vì có hop count = 5, các đường khác có hop count = 4. RtrA chọn P4 hay P5 ở phía trên của TENT. Những yếu tố khác ảnh hưởng đến CSPF Phần chia sẻ thông tin cho biết cách sử dụng và cấu hình của băng thông (bandwidth), các thuộc tính kết nối (link attributes), và trọng lượng quản trị (administrative weight) trong hoàn cảnh làm tràn thông tin (information flooding). Nó cũng cho biết cách cấu hình một đường hầm MPLS TE sử dụng các thuộc tính này. Băng thông khá quan trọng. Một đường đi không được chọn sử dụng cho một đường hầm MPLS TE cụ thể VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 123 nếu nó không có đủ băng thông yêu cầu. Nếu các affinity bits của một đường hầm không phù hợp với chuỗi thuộc tính được cấu hình trên một kết nối, kết nối đó không được lựa chọn để sử dụng cho một đường hầm MPLS TE cụ thể. Trọng lượng quản trị được sử dụng bởi IGP khi nó làm ngập lụt thông tin điều khiển lưu lượng (traffic enfineering information). Ngầm định chỉ trọng lượng quản trị được dùng để tính toán đường đi của đường hầm. Tuy nhiên, nếu chỉ thay đổi trọng lượng quản trị cho một kết nối cụ thể thì khó có thể tạo nên sự mềm dẻo cần thiết. IGP metric thường được xuất phát từ băng thông. Trong OSPF, metric ngầm định của kết nối là băng thông tham chiếu/ băng thông kết nối (reference-bandwidth/link bandwidth). Băng thông tham chiếu ngầm định (có thể được thay đổi bằng lệnh auto-cost reference-bandwidth) là 108, nghĩa là bất kỳ một kết nối nào 100 Mbps hoặc hơn có chi phí là 1. Ta cũng có thể thiết lập trên một kết nối riêng (individual link) với lệnh ip ospf cost cost. Trong IS-IS, chi phí kết nối ngầm định là 10. Có thể thay đổi chi phí này bằng lệnh isis metric. OSPF và IS-IS thường dùng metric để mã hóa vài số đo của băng thông kết nối. Điều này chỉ tốt cho các mạng chỉ truyền dữ liệu. Cơ chế kiểm soát nghẽn mạng của TCP, khi liên kết với hàng đợi DiffServ, có thể giúp cải tiến băng thông. Nhưng với thoại thì sao? Thoại (voice) đòi hỏi ít hơn về băng thông và độ trễ lớn hơn. Nhưng không có cách thông báo độ trễ trên một kết nối? Hay nó ở đâu? Có thể vận dụng metric của kết nối IGP để đại diện cho độ trễ hơn là băng thông. Nhưng điều này có thể làm giảm khả năng định tuyến luồng dữ liệu một cách chính xác làm ảnh hưởng nghiêm trọng tới mạng. Xem xét cấu trúc mạng trong hình sau: Ba đường đi giữa RtrA và RtrZ là: P1 là một đường vệ tinh OC3 với 150 Mbps băng thông có sẵn và độ trễ cao. P2 là đường viễn thông OC3 với độ trễ thấp. Tuy nhiên, đường viễn thông OC3 không có băng thông có sẵn – tất cả băng thông được dành riêng. P3 là một đường viễn thông DS3 với 45 Mbps băng thông có sẵn và độ trễ thấp. Vì độ trễ thấp (low-delay), đường đi băng thông lớn (high-bandwidth path) đầy, ta có thể lừa các độ ưu tiên và điều khiển lưu lượng để đường viễn thông OC3 không bị đầy, nhưng không được đề cập trong ví dụ này. Nó dẫn đến hai câu hỏi đơn giản: ta chọn đường đi băng thông cao, độ trễ cao hay đường đi băng thông ít, độ trễ thấp? Trả VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 124 lời: “Tùy trường hợp”. Dữ liệu thì vẫn ổn với những đường đi độ trễ cao, thoại thì yêu cầu băng thông ít hơn. MPLS TE cho ta khả năng quan tâm đến cả băng thông và độ trễ của kết nối, vì thế ta có thể xem xét riêng biệt chi phí của các đường hầm thoại và dữ liệu. Để thực hiện điều này, phải thực hiện các bước sau: Bước 1: Cấu hình độ trễ của kết nối bằng lệnh mpls traffic-eng administrative-weight 0-4294967295 Bước 2: thay đổi tiến trình quyết định đường hầm (tunnel-decision) trên các đường hầm dữ liệu để dùng IGP metric hơn là dùng TE metric, vì tính đến chi phí kết nối. Bạn có thể thực hiện điều này bằng lệnh toàn cục mpls traffic-eng path-selection metric igp, hay lệnh trên đường hầm tunnel mpls traffic-eng path-selection metric igp. Không có đơn vị nào cố hữu được kết hợp với cấu hình của trọng lượng quản trị. Nếu bạn cấu hình mpls traffic-eng administrative-weight 10, giá trị 10 có thể được giải thích theo nhiều cách. 10 có phải là độ trì hoãn chuyển tải tính bằng micro giây? Phần trăm giây? Mili giây? Giây? Tuy nhiên nên tính độ trễ theo mili giây (ms) vì: TE metric là một lượng 32 bit, nghĩa là có thể tính độ trễ trong khoảng 0 – 4.294.967.295 ms (tương đương 7 tuần, một độ trễ lớn chưa từng thấy). Ứng dụng VoIP tính độ trễ bằng ms nên thật sự không cần xem xét độ trễ kết nối bằng bất cứ một đơn vị nào khác. Thật khó đánh giá cụ thể độ trễ đầu cuối (end-to-end latency) trên một mạch (circuit) cụ thể một cách chi tiết với một đơn vị khác ms. Có ba cách đánh giá độ trễ. Xét theo tính phức tạp tăng dần như sau: - Ping từ một router này tới một router khác. - Chỉ định độ trễ mong muốn dựa trên khoảng cách định tuyến (router-miles). - Dùng SAA để chỉ định độ trễ. CSPF Knobs Có 3 mảng lớn về tính toán tuyến cần quan tâm là: - Cấu hình tùy chọn đường đi ở đầu đường hầm - Bộ định thời CSPF biến thiên (Various CSPF timers) - Các lệnh hiển thị CSPF thay đổi (Various CSPF show commands) Cấu hình tùy chọn đường đi (path-option) Ví dụ : lặp lại cấu hình đường hầm cơ bản interface Tunnel0 ip unnumbered Loopback0 tunnel mode mpls traffic-eng tunnel destination destination-ip tunnel mpls traffic-eng path-option 10 dynamic path-option chỉ định một hoặc nhiều đường đi có thể tạo đường hầm. Hoàn tất cú pháp lệnh như sau : tunnel mpls traffic-eng path-option preference [dynamic | explicit [identifier identifier | name name]] {lockdown} Cú pháp lệnh của tunnel mpls traffic-eng path-option như sau: VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 125 Lệnh Mô tả tunnel mpls traffic-eng path- option preference Xác định một tùy chọn đường đi (path-option) cho đường hầm, tham biến là một giá trị từ 1 đến 1000. dynamic Cho router biết nó tính toán đường đi tốt nhất phù hợp với cấu hình các ràng buộc của đường hầm, như băng thông và các affinity bits. explicit Cho phép chỉ định một đường đi tường minh (explicit path) đi qua mạng mà đường hầm được thiết lập. Đường tường minh này phải thõa các ràng buộc cấu hình, và tunnel headend sẽ kiểm tra đường tường minh để chắc rằng các ràng buộc được thõa mãn trước khi truyền tín hiệu trên đường đi. identifier identifier | name name Khi các đường tường minh được tạo ra, được định danh hoặc chỉ định. Tùy chọn này chỉ định tùy chọn đường đi nào cần quan tâm. lockdown Cấu hình lockdown để ngăn một đường hầm TE khỏi bị periodically reoptimized. Lệnh cấu hình thường dùng là tunnel mpls traffic-eng path-option 10 dynamic. Tạo một đường đi tường minh (Explicit Path) Sử dụng tùy chọn nhiều đường đi (Multiple path option) Tính lại đường hầm (tunnel reoptimization) Đ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. Trong hình trên: Tất cả kết nối bắt đầu với băng thông dành riêng là 100 Mbps Cả router A và D đều muốn xây dựng đường hầm 60 Mbps đến router H VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 126 Kết nối giữa router D và router H bị đứt. Ta thấy các sự kiện sau có thể xảy ra: Router D tạo đường hầm: D → C → H Router A tạo một đường hầm : A → B → C → E → F → G → H Router 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 router tìm thấy một đường đi tốt hơn đường hầm đã được lập thì được xem là reoptimization. Các yếu tố tác động đến reoptimization: - Tính lại định kỳ (periodic reoptimization). - Tính lại thủ 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 đang tồn tại. Reoptimization định kỳ (periodic reoptimization) Cisco thực thi một bộ định thời reoptimization đị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). Reoptimization thủ 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: mpls traffic-eng reoptimize [tunnel-name] để buộc router thực hiện reoptimize một đường hầm cụ thể tại bất kỳ lúc nào. Reoptimization hướng theo sự kiện (Event-driven reoptimization) Xem xét kết nối giữa RtrD và RtrH trong hình trên. 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: mpls traffic-eng reoptimize events link-up VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 127 Lockdown Có thể có một vài đường hầm không cần reoptimize. Có thể thực hiện điều này trong phần cơ sở của đường hầm sử dụng tùy chọn lockdown trong các lệnh tùy chọn đường đi: tunnel mpls traffic-eng path-option preference {dynamic | explicit name name | identifier id>} {lockdown} Ví dụ: mỗi kết nối bắt đầu với 100 Mbps băng thông có sẵn Tại thời điểm hai đường hầm được thiết lập, kết nối bên dưới giữa RtrC và RtrD bị down. Một lúc sau hoạt động trở lại. Một đường hầm 60 Mbps từ RtrA đến RtrE qua kết nối trên C → D và một đường hầm RtrB đến RtrE đi trên cùng kết nối như hình sau: Khi reoptimize xảy ra trên các đường hầm này, giả sử xem xét trên đường hầm B → E, kết quả là đường hầm B → E được reoptimize. VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 128 Nhưng nếu không muốn đường hầm B → E reoptimize thì cấu hình đường hầm đó với tunnel mpls traffic-eng path-option … lockdown, nó sẽ không reoptimize và chuyển sang kết nối khác. Tuy nhiên, nó sẽ đổ về 1 kết nối C → D nếu kết nối C → D phía trên bị đứt. Giao thức dành riêng tài nguyên (RSVP- Resource Reservation Protocol) Sau khi một đường đi được tính toán theo CSPF, đường đi đó được báo hiệu qua mạng nhằm: - Thiết lập một chuỗi các nhãn theo từng chặn (hop-by-hop chain of labels) đại diện cho đường đi. - Để sử dụng bất kỳ tài nguyên nào có thể dùng được (băng thông) trên đường đi. Việc báo hiệu hoàn thành bằng RSVP, cùng với RSVP mở rộng cho MPLS TE. RSVP được xác định RFC 2205, có một số mở rộng trong RFC 2210. MPLS TE mở rộng thêm RSVP được xác định trong RFC 3209. Tổng quan về RSVP 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-); 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. Ba chức năng cơ bản của RSVP có : - 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 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). Chín loại thông điệp RSVP khác nhau được định nghĩa như sau: Loại thông điệp Mô tả Path Dùng để thiết lập và duy trì sự dành riêng Resv Gửi hồi đáp cho các thông điệp Path để thiết lập và duy trì sự dành riêng PathTear Tương tự các thông điệp Path, nhưng được dùng để hủy sự dành riêng ra khỏi mạng. ResvTear Tương tự như các thông điệp Resv, nhưng dùng để hủy sự dành riêng ra khỏi mạng. PathErr Được gửi bởi phía nhận thông thiệp Path báo rằng phát hiện ra một lỗi trong thông điệp đó. ResvErr Được gửi bởi phía nhận thông thiệp Resv báo rằng phát hiện ra một lỗi trong thông điệp đó. VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 129 ResvConf Tùy chọn gửi lại cho phía gửi thông điệp Resv để báo rằng tài nguyên dành riêng đưa ra đã được thiết lập. ResvTearConf Một thông điệp riêng của Cisco tương tự như ResvConf. Báo rằng sự dành riêng đã bị hủy khỏi mạng. Hello Một sự mở rộng được xác định trong RFC 3209 cho phép kết nối cục bộ (link-local) được duy trì giữa hai láng giềng RSVP kết nối trực tiếp. 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. Sự trao đổi các thông điệp RSVP Path và Resv trong suốt quá trình thiết lập LSP như sau: 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. VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 130 (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 (Path Teardown) 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 trên, 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 VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 131 Đị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. RSVP common header Các trường trong tiêu đề chung RSVP: Trường Mô tả Version Phiên bản của giao thức RSVP. Flags Chưa có cờ nào được định nghĩa. Message Type 1 = Path message 2 = Resv message 3 = PathErr message 4 = ResvErr message 5 = PathTear message 6 = ResvTear message 7 = ResvConf message 10 = ResvTearConf message 20 = Hello message RSVP Checksum Kiểm tra lỗi của thông điệp RSVP. Send TTL Giá trị TTL trên gói IP. Reserved Không sử dụng. RSVP Length Chiều dài của thông điệp RSVP tính bằng byte bao gồm cả tiêu đề chung, tối thiểu là 8 byte. Đị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ư sau: Các trường trong định dạng đối tượng RSVP cơ bản: Trường Mô tả Object Length Kích thước của đối tượng RSVP, gồm cả tiêu đề đối tượng (object header), tối thiểu là 4. Nó phải là bội số của 4. Class-Num Lớp của đối tượng (object's class). C-Type Loại lớp của đối tượng. C-Type là một số duy nhất trong lớp. VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 132 Object Contents Bản thân đối tượng đó. 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. Các lớp và C-Types được dùng trong RSVP-TE của Cisco: Lớp đối tượng C-Type Giá trị C_type SESSION LSP Tunnel IPv4 4 TIME_VALUES Refresh Period 1 ERROR_SPEC IPv4 Error Spec 1 SCOPE List of IPv4 Source Addresses 1 STYLE Flags and Option Vector 1 FLOWSPEC Intserv Flowspec 2 FILTER_SPEC LSP Tunnel IPv4 7 SENDER_TEMPLATE LSP Tunnel IPv4 7 SENDER_TSPEC Intserv Sender Tspec 2 ADSPEC Intserv Adspec 2 RESV_CONFIRM IPv4 RevConfirm 1 RSVP_LABEL Label 1 LABEL_REQUEST Without Label Range 1 EXPLICIT_ROUTE Explicit Route 1 RECORD_ROUTE Record Route 1 HELLO Request 1 HELLO Acknowledgment 2 SESSION_ATTRIBUTE LSP Tunnel 7 Lớp SESSION Đối tượng SESSION được xác định trong RFC 2205. RFC 3209 định nghĩa C-Type 7 (LSP_TUNNEL_IPV4), có 4 trường được mô tả trong bảng 4-25. VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 133 Các trường trong lớp SESSION: Trường Nội dung IPv4 Tunnel Endpoint Address Router ID của đuôi đường hầm. Reserved = 0 Tunnel ID Một 16-bit ID xác định duy nhất đường hầm này. Đây là chỉ số giao tiếp ở đầu đường hầm (vì thế Tunnel8 có Tunnel ID bằng 8). Extended Tunnel ID Một 32-bit ID. Thiết lập tất cả bằng 0 hoặc một địa chỉ IP của giao tiếp. Lớp TIME_VALUES RFC 2205 định nghĩa đối tượng TIME_VALUES như là chu kỳ làm tươi (refresh period) (tính bằng mili giây - ms để gửi thông điệp Path hay Resv. Lớp ERROR_SPEC RFC 2205 định nghĩa đối tượng ERROR_SPEC và cũng xác định các mã lỗi từ 00 đến 23. RFC 3209 định nghĩa mã lỗi 24, đặc tả lỗi cho MPLS TE. Trong MPLS TE, rất dễ gặp mã lỗi 00 ( Sự xác nhận (Confirmation) — gửi trong phúc đáp cho một thông điệp chứa đối tượng CONFIRMATION) hay mã lỗi 24. Khi mã lỗi (error code) là 00, giá trị lỗi (error value) cũng là 00. Khi mã lỗi là 24 thì có thể có 10 giá trị. Cũng có một mã lỗi 25 nhưng chỉ thấy khi sử dụng tái định tuyến nhanh (Fast Reroute). Thông thường trường Flags bằng 0 khi sử dụng MPLS TE. Lớp SCOPE VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 134 RFC 2205 xác định lớp SCOPE. Lớp SCOPE thực hiện kiểu dành riêng wildcard (wildcard reservation style) Lớp STYLE Lớp STYLE đặc tả kiểu dành riêng. Có thể có 3 loại: Wildcard Filter Fixed Filter Shared Explicit Cisco IOS Software sử dụng Shared Explicit cho sự dành riêng MPLS TE. Trường Flags không được sử dụng. Option Vector luôn bằng 0x12, chỉ định loại Share Explicit. Lớp FLOWSPEC VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 135 Lớp FLOWSPEC được xác định trong RFC 2210. Cisco IOS Software yêu cầu dịch vụ tải được điều khiển (Controlled-Load) khi dành riêng cho một đường hầm TE. Định dạng FLOWSPEC phức tạp và có nhiều thứ trong đó mà RSVP cho MPLS TE không sử dụng. FLOWSPEC được dùng trong các thông điệp Resv - Resv, ResvTear, ResvErr, ResvConf, ResvTearConf. MPLS TE sử dụng phần tốc độ trong bình của FLOWSPEC để chỉ định băng thông mong muốn, tính bằng byte (không phải bit). Vì thế nếu bạn cấu hình với tunnel mpls traffic-eng 100000 để yêu cầu 100 Mbps băng thông, nó phát tín hiệu 12,500,000 bytes trong một giây (100 Mb = 100,000 Kb = 100,000,000 bits = 12,500,000 bytes). Lớp FILTER_SPEC Lớp FILTER_SPEC được xác định trong RFC 2205. RFC 3209 thêm vào C-Type 7, LSP Tunnel IPv4. Trường IPv4 Tunnel Sender Address cho biết router ID của đầu đường hầm TE (TE tunnel headend), và trường LSP ID cho biết tunnel's LSP ID. LSP ID khi các đặc tính của đường hầm (tunnel's properties) thay đổi (băng thông, đường VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 136 đi thay đổi). FILTER_SPEC chỉ dùng trong các thông điệp liên quan Resv (ResvTear, ResvErr, ...). Lớp SENDER_TEMPLATE Lớp SENDER_TEMPLATE được xác định trong RFC 2205, và RFC 3209 xác định C-Type 7, LSP Tunnel IPv4. Có cùng định dạng và mục đích như lớp FILTER_SPEC nhưng khác hướng. Lớp SENDER_TSPEC Thường chỉ thấy lớp SENDER_TSPEC trong thông điệp Path. Giống như FLOWSPEC, MPLS TE chỉ quan tâm tới phần tốc độ trung bình (average rate section). Lớp ADSPEC VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 137 Xác định trong RFC 2210. Giống SENDER_TSPEC, ADSPEC chỉ dùng trong các thông điệp Path. Lớp RESV_CONFIRM RESV_CONFIRM được xác định trong RFC 2205. Nó gửi tín hiệu yêu cầu một chấp nhận (confirmation); nó xuất hiện trong các thông điệp Resv và ResvTear. Lớp RESV_CONFIRM thỉnh thoảng xem như CONFIRM. Lớp RSVP_LABEL Lớp RSVP_LABEL (thỉnh thoảng được gọi là LABEL) được xác định trong RFC 3209. kích thước 32-bit, mọi đối tượng RSVP phải là bội số của 4 byte, nhưng trong chế độ khung (frame mode), nó mang nhãn 20-bit dùng cho một đường hầm cụ thể (particular tunnel). Lớp RSVP_LABEL chỉ có trong thông điệp Resv. Lớp LABEL_REQUEST Đối tượng LABEL_REQUEST yêu cầu một nhãn. Một đối tượng RSVP_LABEL trả lời cho nó. Đối tượng LABEL_REQUEST chỉ có trong thông điệp Path. Nó chứa, trong 16 bit cao, Layer 3 Protocol Identifier (L3PID) được mang trong nhãn. Cisco IOS luôn báo hiệu 0x800 (IP); sự tồn tại của L3PID mang tính lịch sử. Sự tồn tại của VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 138 đối tượng LABEL_REQUEST đủ để báo cho nút xuôi dòng (downstream node) là nó tiếp nhận nhãn đưa ra. Lớp EXPLICIT_ROUTE Đối tượng EXPLICIT_ROUTE đường đi cho đường hầm MPLS TE, thường được gọi là ERO, và được xác định trong RFC 3209. ERO chỉ có trong thông điệp Path. ERO là một tập các đối tượng con (8-byte). Đối tượng con IPv4 Prefix hiện tại chỉ được hỗ trợ bởi Cisco IOS. Các trường trong ERO: Trường Nội dung L(Loose) Một bit để xác định là một trạm ràng buộc chặt (strict) hay lỏng (loose) Type Loại đối tượng. IPv4 loại 1. Còn có loại khác như: IPv6, AS Length Chiều dài đối tương (tính bằng byte) IPv4 Address Địa chỉ IP kế tiếp trong ERO Prefix Length Chiều dài prefix của địa chỉ IP Reserved Dành riêng (chưa dùng) Lớp RECORD_ROUTE Đối tượng RECORD_ROUTE được mô tả trong RFC 3209. Có hai đối tượng con RECORD_ROUTE khác nhau; một để lưu địa chỉ IP ở mỗi trạm (hop) , và một để lưu nhãn (label) được dùng ở mỗi trạm. Các trường trong đối tượng RECORD_ROUTE: VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 139 Trường Nội dung Type 0x1 cho địa chỉ IPv4. 0x3 cho nhãn. Length Chiều dài của đối tượng. IPv4 Address Một địa chỉ IP mà LSP này đi qua. Prefix Length =32. Flags (trong đối tượng con địa chỉ IP) 0x1 chỉ định sẵn sàng bảo vệ cục bộ (Local Protection Available). 0x2 chỉ định bảo vệ cục bộ (Local Protection) đang được dùng. Flags (trong đối tượng con - nhãn) 0x1 xác định nhãn vừa được ghi là từ không gian nhãn toàn cục. C-Type C-Type của nhãn. Giống như C-Type cho đối tượng RSVP_LABEL. (Hiện tại giá trị được định nghĩa là 1) Contents Nhãn của nó, được mã hóa trong đối tượng RSVP_LABEL. Lớp HELLO Lớp HELLO có hai C-Types: Hello Request (Type 1) và Hello ACK (Type 2). Cả hai được mã hóa giống nhau. Source Instance và Destination Instance để lưu trạng thái láng giềng RSVP (RSVP neighbor state); xem thông điệp HELLO như là báo hiệu tồn tại mức RSVP (RSVP-level keepalives). Lớp SESSION_ATTRIBUTE Lớp SESSION_ATTRIBUTE đuợc định nghĩa trong RFC 3209. SESSION_ATTRIBUTE chỉ có trong thông điệp Path. SESSION_ATTRIBUTE có hai loại—có hoặc không có resource affinity (RA). Hiện tại, Cisco IOS chỉ hỗ trợ LSP Tunnel C-Type không có RA (C-Type 7). Các trường trong đối tượng SESSION_ATTRIBUTE: Trường Nội dung Setup Priority Độ ưu tiên thiết lập Holding Priority Độ ưu tiên chiếm giữ Flags 0x2 = bản ghi nhãn (Label recording) 0x1 = Sự bảo vệ cục bộ (Local protection) VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 140 0x4 = Kiểu SE. Name Length Chiều dài của chuỗi Session Name, tính bằng byte. Session Name Tên được gán cho LSP này. Hoạt động của RSVP-TE Bạn tự hỏi làm thế nào các giao thức có thể phối hợp với nhau. Phần này sẽ trả lời câu hỏi: Make-before-break là gì? Cơ chế làm tươi (refresh mechanism) hoạt động như thế nào? Các thông điệp được gửi khi nào, ở đâu và cho ai? Các đối tượng cin ERO chặt (strict) và lỏng (loose) là gì? Báo hiệu Implicit và explicit null ở trạm cuối là gì? 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. 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) VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 141 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). Chia sẻ tường minh 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 và 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 bộ năm thông số 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). Ba 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ệ. 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 ID, nên khác LSP nhưng chúng được chia xẻ băng thông. Các bước trong Make-Before-Break: Bước R1 R2 1 Gửi một sự dành riêng cho {SA=1.1.1.1, LSP ID=1, EA=5.5.5.5, TID=8, XTID=0}, yêu cầu 35 Mb dọc đường đi R1→ R2 → R5 . Gọi là sự dành riêng Res1. Chuyển tiếp sự dành riêng đến R5. Đánh dấu đường đi R2 → R5 là 35 Mb được dành riêng cho đường hầm cà còn lại 65 Mb . VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 142 2 Gửi một yêu cầu dành riêng cho {SA=1.1.1.1, LSP ID=2, EA=5.5.5.5, TID=8, XTID=0} dọc đường đi R1→R3→R4→R2→R5, yêu cầu băng thông 80 Mb. Gọi là Res2. Kiểm tra sự dành riêng và thấy rằng sự dành riêng này giống với sự dành riêng đã có ngoại trừ LSP ID. Cho phép sự dành riêng mới đụng độ với băng thông dành riêng đã có và định phần cho đường hầm này là 80 – 35 = 45 Mbps nhiều hơn băng thông trên kết nối R2 → R5. R2 → R5 dánh dấu băng thông dành riêng là 80 Mbps và 20 Mbps chưa đuợc sử dụng. 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 và 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: 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 dưới cho thấy thông điệp Path và Resv được gửi một cách độc lập và định thời làm tươi củ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. VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 143 Các thông điệp được gửi khi nào? Đến đâu? Và cho ai? Các loại thông điệp RSVP: Thông điệp Chức năng Hướng Địa chỉ đích Cảnh báo router Path Gửi tín hiệu yêu cầu tài nguyên lên mạng. Xuôi dòng Đuôi (tail) Có Resv Trả lời thông điệp Path thành công. Ngược dòng Trạm kế (next hop) Không PathErr Gửi về đầu đường hầm khi có lỗi ở thông điệp Path. Ngược dòng Trạm kế Không ResvErr Gửi về phía đuôi nếu có một lỗi trong việc xử lý thông điệp Path. Xuôi dòng Trạm kế Không PathTear Gửi về đuôi đường hầm để hủy một sự dành riêng đang tồn tại. Xuôi dòng Đuôi Có ResvTear Gửi về đầu đường hầm để hủy một sự dành riêng dang tồn tại. Ngược dòng Trạm kế Không ResvConf Gửi phúc đáp cho Resv hay ResvTear yêu cầu xác nhận thông điệp. Xuôi dòng Đuôi Có ResvTearConf Gửi hồi đáp cho một ResvTear bao gồm một thông điệp Confirm. Xuôi dòng Trạm kế Không Hello Gửi tới một láng giềng RSVP trên một kết nối trực tiếp. Ngược dòng / Xuôi dòng Trạm kế Không VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 144 Chú ý: RFC 2113 giới thiệu một tùy chọn IP được gọi là tùy chọn cảnh báo router (RA – Router Alert). Hiện tại RA được sử dụng trong cả IGMP và RSVP. Nó cho phép bộ định tuyến kiểm tra các gói được truyền và cho bộ định tuyến tùy chọn sửa đổi gói đó trước khi chuyển tiếp đi. Mọi thông điệp có thiết lập tùy chọn RA được gửi theo hướng xuôi dòng. Mọi thông điệp có thiết lập tùy chọn RA có địa chỉ IP đích là đuôi đường hầm. Mọi thông điệp có thiết lập tùy chọn RA hay đặt trạm kế (xuôi dòng hoặc ngược dòng) địa chỉ giao tiếp là địa chỉ đích trên gói. Thực hiện như thế cho phép bộ định tuyến phát hiện ra các bộ định tuyến không hỗ trợ RSVP (non-RSVP), vì không thể xây dựng một đường hầm TE qua một bộ định tuyến không giao tiếp với RSVP do MPLS TE không chỉ cần băng thông dành riêng mà còn cần sự định vị nhãn. Các đối tượng con ERO strict và loose ERO được mã hóa như làm một loạt các đối tượng con được gọi là nút trừu tượng (abstrat nodes). Một nút trừu tượng có thể là địa chỉ IPv4, IPv6, hay một AS (autonomous system). Đối tượng con có thể là một trạm chặt hay lỏng. Cisco thường dùng trạm chặt (strict hop). Khi một bộ định tuyến xử lý một trạm chặt, địa chỉ IPv4 trong đối tượng con phải là kết nối trực tiếp của bộ định tuyến thực hiện xử lý . Khi bộ định tuyến xử lý một trạm lỏng (loose hop), nó phát sinh một tập các trạm chặt để lấy thông điệp Path về đích và thay thế trạm lỏng đó bằng một tập các trạm chặt mới được phát sinh. Implicit và Explicit Null Đuôi đường hầm có hai loại tín hiệu nhãn—implicit null và explicit null. Explicit null sử dụng giá trị 0 và Implicit null dùng giá trị 3 trong trường Label của đối tượng LABEL. Ngầm định nút cuối đường hầm gửi tín hiệu implicit null trong thông điệp Resv của nó: LABEL type 1 length 8 : 00000000 Với chất lượng dịch vụ thì cần explicit null. Cách khoảng thông điệp RSVP (RSVP spacing) Khi có một sự cố trong mạng (đứt kết nối, khởi động lại router, ...). Điều này tạo ra một lượng rất lớn sự báo hiệu. Nếu đứt kết nối, cần gửi PathErr hay ResvErr cho các đường hầm đi qua kết nối. Nếu có 2000 đường hầm TE qua kết nối thì cần 2000 PathErr/ResvErr. Mỗi thông điệp RSVP đến hàng đợi ngõ vào của một router khác. Hàng đợi này có kích thước ngầm định là 75 gói. Nếu quá nhiều thông điệp và hàng đợi đầy thì có thể làm mất gói. Một điểm không may nữa, khi thông điệp RSVP mất, nút gửi đi sẽ phải đợi đến thời gian làm tươi mới gửi lại thông điệp – 30 s ±- 50%. Giải quyết bằng cách tăng bộ đệm? Tăng bao nhiêu cho đủ? Kết quả truyền loạt có thể làm mất gói và hội tụ chậm. Giải pháp tốt nhất là cách khoảng thông điệp RSVP (RSVP Message Pacing), kiểm soát tốc độ các thông điệp RSVP được gửi để hàng đợi ở đầu cuối kết nối không bị tràn. Thực hiện cấu hình chức năng này bằng lệnh ip rsvp msg-pacing ? với các tùy chọn như sau : Các tùy chọn của lệnh ip rsvp msg-pacing ?: Tùy chọn Chức năng Mặc định burst Số lượng tối đa các thông điệp RSVP có thể được gửi trong một loạt truyền 200 VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 145 maxsize Số lượng tối đa các thông điệp được vào hàng đợi để truyền 500 period Khoảng thời gian mà một loạt thông điệp được truyền 1 Chuyển tiếp lưu lượng xuống đường hầm Phần này ta sẽ khảo sát ba phương pháp chuyển tiếp lưu lượng mpls xuống đường hầm. Một là dùng các tuyến tĩnh (static routes). Hai là dùng định tuyến dựa trên chính sách (policy base routing). Ba là định tuyến tự động (Autoroute). Sử dụng định tuyến tĩnh (static route) Cách đơn giản nhất để định tuyến một luồng lưu lượng xuống một giao tiếp đường hầm là sử dụng định tuyến tĩnh (static route). Nó hoạt động giống như định tuyến IP bình thường. Ví dụ: ip route 10.0.0.0 255.0.0.0 Tunnel0 ip route 10.0.0.0 255.0.0.0 POS0/0 Sử dụng định tuyến tĩnh đệ quy : ip route 192.168.1.1 255.255.255.255 Tunnel0 ip route 10.0.0.0 255.0.0.0 192.168.1.1 (với: 192.168.1.1 : địa chỉ cuối đường hầm) Định tuyến dựa trên chính sách (policy base routing) PBR (Policy Base Routing) được phép sử dụng ánh xạ tuyến theo chính sách áp dụng cho giao tiếp ngõ vào. Với PBR bạn có thể gửi loại lưu lượng cụ thể xuống một giao tiếp đường hầm mà không cần sửa đổi bảng định tuyến của bộ định tuyến. Ví dụ: Có hai loại lưu lượng gửi đến Dst – thoại và dữ liệu. Nếu chỉ muốn lưu lượng thoại qua Tunnel0, bạn có thể thực hiện bằng PBR. Thực hiện cấu hình trên bộ định tuyến A như sau : interface Ethernet0/0 ip policy route-map foo route-map foo match ip address 101 set interface Tunnel0 access-list 101 permit ip any host 5.5.5.5 VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 146 Định tuyến tự động Nếu có nhiều loại giao tiếp trong Cisco IOS Software (một giao tiếp vật lí, giao tiếp con, hay đường hầm GRE), bạn cần cho phép giao thức cổng nội (IGP – Interior Gateway Protocol) trên giao tiếp để thiết lập giao thức định tuyến láng giềng, học tuyến, và xây dựng một bảng định tuyến cho giao tiếp đó. Ví dụ về hoạt động chuyển tiếp lưu lượng xuống đường hầm Ở đây ta quan tâm đến bảng định tuyến của bộ định tuyến A sau khi sử dụng định tuyến tĩnh, định tuyến dựa trên chính sách và định tuyến tự động trong mạng. Các kết nối đều có chi phí là 10. Bảng định tuyến ban đầu của A: Trạm đích Trạm kế Chi phí A Chính nó 0 B B 10 C C 10 D C 20 E B 20 F B 30 G B 30 H B 40 I B 40 Định tuyến tĩnh: Ta cấu hình cho lưu lượng đến G ip route router G's RID 255.255.255.255 Tunnel0 Bảng định tuyến của A như sau: Trạm đích Trạm kế Chi phí A Chính nó 0 B B 10 C C 10 D C 20 E B 20 F B 30 G Tunnel0 30 H B 40 I B 40 Định tuyến dựa trên chính sách Không làm thay đổi bảng định tuyến vì quyết định chuyển tiếp gói dựa trên chính sách được cấu hình và giao tiếp, không dựa trên bảng định tuyến. VnPro – Cisco Authorized Training Center Trần Thị Tố Uyên 147 Định tuyến tự động Router xây dựng lại bảng định tuyến để bất kỳ đích đến (đuôi đường hầm nào cũng được định tuyến xuống đường hầm). Router A thực hiện tiến trình IGP SPF với định tuyến tự động được cho phép trên đường hầm đến router E. Bảng định tuyến của A sau quá trình này như sau: Trạm đích Trạm kế Chi phí A Chính nó 0 B B 10 C C 10 D C 20 E Tunnel0 20 F Tunnel0 30 G Tunnel0 30 H Tunnel0 40 I Tunnel0 40