Khi một mạng bị lỗi, chính xác hơn, một số thành phần của mạng bị lỗi có thể kéo theo nhiều thứ cũng bị lỗi trong mạng. Có hai loại lỗi là: 1) lỗi đƣờng liên kết, 2) lỗi Node.
Để giảm những ảnh hƣởng của các lỗi trên nhƣ mất gói chẳng hạn, MPLS TE có các cơ chế để giảm thiểu sự mất mát của các gói tin đó là Primary, Secondary Path và
Fast Reroute. Những cơ chế này sẽ đƣợc trình bày ở các phần tiếp theo.
2.3.2.3.1. Con đƣờng chính LSP (Primary LSP Path)
Một LSP có thể có 1 hoặc không có con đƣờng chính (primary path). Giả sử rằng LSP đƣợc thiết lập trong mạng sử dụng một con đƣờng chính, tại một số điểm, một trong số các liên kết bị lỗi và LSP đƣợc chuyển đến đƣờng dự phòng trong mạng, khi con đƣờng chính khôi phục, LSP sẽ thiết lập lại con đƣờng đó. Khả năng sử dụng trở lại của con đƣờng chính đƣợc cấu hình bởi 2 tham số: retry-timer kiểm soát thời gian các router lối vào đợi để thành lập lại đƣờng chính và retry-limit kiểm soát số lần router lối vào nỗ lực thiết lập lại con đƣờng chính. Giá trị mặc định của retry-timer là 30s và có thể đặt lại từ 1 đến 600s. Sau khi con đƣờng chính đƣợc thiết lập lại, các router lối vào sẽ đợi hết thời gian trên trƣớc khi sử dụng con đƣờng chính, giá trị mặc định của retry-limit là 0, có nghĩa là router lối vào liên tục thiết lập lại con đƣờng chính, ngƣời dùng có thể đặt giới hạn cho tham số này, để khi vƣợt qua ngƣỡng đó, router lối vào ngừng việc thiết lập lại con đƣờng, lần sau muốn sử dụng lại con đƣờng chính thì ngƣời sử dụng phải xóa LSP trên router lối vào.
Mỗi LSP định nghĩa 0 hoặc nhiều con đƣờng phụ để chuyển tiếp lƣu lƣợng khi đƣờng chính bị lỗi. Khi router lối vào đƣợc thông báo con đƣờng chính lỗi (thông qua giao thức RSVP, cụ thể là bản tin ResvTear), nó sẽ xóa con đƣờng chính khỏi mạng, thuật toán CSPF sẽ tìm một tập những liên kết cung cấp bởi phần cấu hình con đƣờng phụ, kết quả ERO từ thuật toán CSPF sẽ đƣợc chuyển đến tiến trình xử lý RSVP và con đƣờng phụ đƣợc báo hiệu, khi con đƣờng phụ đƣợc thiết lập xong, lƣu lƣợng sử dụng lại LSP để chuyển tiếp trên toàn mạng.
Sau khi router lối vào xóa con đƣờng chính, sau thời gian retry-time nó sẽ sử dụng thuật toán CSPF để thiết lập lại con đƣờng chính, quá trình này sẽ lặp lại theo chu kỳ là retry-time, nếu giá trị retry-limit=0 thì nó sẽ thực hiện đến khi nào thiết lập lại đƣợc con đƣờng chính.
Thậm chí ngay cả khi con đƣờng chính trở lại trạng thái Up, con đƣờng phụ vẫn là con đƣờng dùng cho LSP, sau thời gian chờ đợi (retry-time), router lối vào mới chuyển đƣờng chính trở về trạng thái active cho LSP. Nhƣ vậy có thể thấy việc chuyển mạch giữa hai con đƣờng chính và phụ không đƣợc thực hiện đồng thời, và vì vậy, trong một số chu kỳ thời gian, router lối vào chuyển tiếp lƣu lƣợng thông qua bảng định tuyến IP của nó. Sự trì hoãn trên hoàn toàn có thể đƣợc loại bỏ nếu con đƣờng phụ đƣợc thành lập trƣớc khi con đƣờng chính bị lỗi, việc này sẽ đƣợc trình bày ở phần dƣới đây.
Dự phòng cho con đường phụ (Standby Secondary Path):
Bất kỳ hoặc tất cả con đƣờng phụ định nghĩa cho LSP có thể đƣợc báo hiệu và thiết lập sau khi con đƣờng chính hoạt động, điều này đƣợc thực hiện thông qua việc thực hiện lệnh standby với định nghĩa con đƣờng, nhƣ ví dụ đoạn cấu hình dƣới đây.
user@Sherry# show label-switched-path Sherry-to-Char
to 192.168.32.1; primary via-Chablis { bandwidth 20m; } secondary via-Chianti { bandwidth 10m; standby; }
Trong trƣờng hợp đặt lệnh standby, khi con đƣờng chính bị lỗi, do con đƣờng
phụ đã ở trạng thái Up nên router lối vào active con đƣờng đó cho LSP. Sau khi liên kết đã hoạt động trở lại, con đƣờng chính đƣợc báo hiệu và thiết lập lại nhƣng không đƣợc chọn là con đƣờng active cho LSP. Sau khi đợi cho con đƣờng duy trì ổ, router lối vào một lần nữa chọn nó làm con đƣờng active cho LSP, và hủy lựa chọn con đƣờng phụ, nhƣng con đƣờng phụ vẫn hoạt động do cấu hình dự phòng.
Trong trƣờng hợp này chỉ khai báo các con đƣờng phụ, các hoạt động giống nhƣ trƣờng hợp trên, tuy nhiên, sau khi liên kết đã hoạt động trở lại, không có cơ chế để LSP lựa chọn lại con đƣờng phụ thứ nhất mà chính con đƣờng phụ thứ 2 là đƣờng active cho LSP.
2.3.2.3.3. Fast Reroute (FRR)
Trong hai phần trên đã trình bày về các cơ chế bảo vệ LSP khi có sự cố xảy ra, các cơ chế này đã thực hiện tốt nhƣ các giải pháp mạng lâu dài, tuy nhiên vẫn chƣa giải quyết triệt để việc rớt gói. Cụ thể, các gói tin vẫn đƣợc đẩy vào LSP bởi router lối vào trong khoảng thời gian từ khi lỗi xảy ra đến khi router lối vào nhận đƣợc bản tin báo lỗi RSVP ResvTear, đối với những ứng dụng quan trọng thì việc rớt gói trong khoảng thời gian này là không thể chấp nhận đƣợc. Giải pháp đƣợc đƣa ra trong tình huống này là sử dụng Fast Reroute trên 1 LSP, cơ sở của nó dựa trên việc thiết lập
những đƣờng vòng qua mạng mà giao tiếp với các phiên RSVP của LSP. Mỗi router dọc theo đƣờng LSP tạo ra những đƣờng vòng để chống lại lỗi của liên kết tiếp hoặc Node tiếp theo.
Trong chế độ này, khi lỗi xảy ra, lƣu lƣợng cho LSP đó lập tức đƣợc chuyển tới một đƣờng vòng, quyết định nhanh chóng này cho phép giảm thiểu số gói tin bị mất, Node này cũng tạo thông báo PathErr ngƣợc lại tới router lối vào, gói tin này báo cho router lối vào biết lỗi xảy ra trên đƣờng LSP và lƣu lƣợng đã đƣợc chuyển qua đƣờng vòng.
Hành động của router lối vào phụ thuộc vào cấu hình của nó và trạng thái của mạng (đã trình bày ở hai phần trƣớc), sau khi router lối vào thiết lập lại đƣờng đi cho LSP, lƣu lƣợng sẽ lại đẩy lại vào LSP.
Có hai loại Fast Reroute quan trọng là: Link protection và Node Protection.
+ Link Protection:
Link Protection có nghĩa là khi một liên kết bị lỗi, những LSPs qua liên kết đó
đƣợc gửi qua những một số con đƣờng khác trong mạng, nó giống nhƣ tất cả những ứng dụng TE khác, chỉ có một hƣớng. Khi cần bảo vệ LSPs từ A đến B trên một liên kết, cần cấu hình bảo vệ trên hƣớng AB, để bảo vệ LSPs từ B đến A trên cùng 1 liên kết, thì cũng cần phải xây dựng một bảo vệ trên hƣớng BA.
Trong nhiều mạng, có những liên kết tốc độ cao mang những luồng thông tin “quan trọng” hoặc “không quan trọng”. Nếu MPLS TE đƣợc triển khai trong mạng, những luồng thông tin “quan trọng” đƣợc chuyển qua “LSP quan trọng”, những LSP này có thể mang những thông tin yêu cầu thời gian thực, vì vậy nó nên đƣợc bảo vệ, và bỏ qua các LSP kém quan trọng hơn. FRR cho phép bảo vệ một số TE tunnels hoặc tất cả TE tunnels. Với link protection, có thể bảo vệ liên kết mà mang LSP quan trọng bằng cách sử dụng các tunnels dự phòng (backup tunnels).
Ví dụ: Khi cấu hình một tunnel chính trên router 7200a (cisco), lênh thực hiện nhƣ sau. 7200a(config-if)#tunnel mpls traffic-eng fast-reroute
Kích hoạt link protection tại PLR:
Một số khái niệm.
PLR (Point of Local Repair) là điểm đầu của tunnel dự phòng, trong hình dƣới,
12008a là tunnel dự phòng.
MP (Merge Point) là điểm mà kết thúc tunnel, trong hình dƣới MP là 12008c.
Nhop (Next-hop router) là router mà tiếp theo PLR 1 Hop, trong hình dƣới
Nhop là 12008c.
NNHop (Next-next-hop router) là router mà tiếp theo PLR 2 Hop, trong hình
dƣới NNHop là 7200c.
Để kích hoạt thì có hai việc cần phải làm là: tạo một đƣờng tunnel dự phòng tới Nhop và cấu hình protection link sử dụng tunnel dự phòng.
Tạo 01 tunnel dự phòng tới Nhop.
Trong chế độ bảo vệ này, một tunnel dự phòng cần đƣợc xây dựng từ PLR tới MP, trong hình dƣới, LSP chính đi từ 7200a đến 7200c, 2 điểm giữa là 12008a và 12008c. Liên kết đƣợc bảo vệ trong ví dụ là liên kết POS giữa 12008a và 12008c trên hƣớng trực tiếp.
Hình 2.19. Chế độ bảo vệ Link
Nếu liên kết cần bảo vệ bị lỗi, những LSP qua liên kết này đƣợc bảo vệ và định tuyến lại tới 12008c, đó là điểm cuối xuôi chiều của liên kết này.
Ví dụ một đoạn cấu hình khai báo tunnel dự phòng.
12008a#show running-config interface tunnel1 interface Tunnel1
ip unnumbered Loopback0 no ip directed-broadcast tunnel destination 11.11.11.11 tunnel mode mpls traffic-eng
tunnel mpls traffic-eng path-option 5 explicit name nhop
Cấu hình protection link sử dụng tunnel dự phòng:
Nếu chỉ cấu hình tunnel dự phòng và gọi con đƣờng này là “backup” thì lƣu lƣợng sẽ không qua tunnel này khi liên kết đƣợc bảo vệ bị lỗi. Sau khi đã xây dựng xong tunnel dự phòng, cần phải thông báo 1 interface sử dụng tunnel này cho việc bảo vệ. Trong ví dụ trên, thông báo cho giao diện Pos1/0 sử dụng tunnel dự phòng, cụ thể xem đoạn cấu hình sau.
12008a#show running-config interface pos1/0 interface POS1/0
ip address 10.0.5.5 255.255.255.0 no ip directed-broadcast
mpls traffic-eng tunnels
mpls traffic-eng backup-path Tunnel1
ip rsvp bandwidth 155000 155000
Lệnh mpls traffic-eng backup-path Tunnel1 bảo vệ giao diện Pos1/0 của router 12008a với tunnel1.
Lúc này, tunnel dự phòng đƣợc báo hiệu và sẵn sàng phục vụ. Nếu lỗi đƣợc phát hiện trên liên kết cần bảo vệ, tất cả lƣu lƣợng từ các LSPs tƣơng ứng đƣợc chuyển tiếp qua tunnel dự phòng, đến thời điểm này, LSP dự phòng vẫn chƣa mang bất kỳ lƣu lƣợng gì.
Dò lỗi:
Một trong những vấn đề rất quan trọng của cơ chế bảo vệ này là vấn đề dò lỗi, bởi vì việc dò và phát hiện lỗi càng nhanh thì cơ chế bảo vệ này càng đƣợc thực hiện sớm và tốt hơn. Có hai phƣơng pháp để dò lỗi là dựa trên cảnh báo Sonet, thời gian để phát hiện lỗi là khoảng 50ms, tuy nhiên phƣơng pháp này chỉ có thể đƣợc áp dụng cho các giao diện Pos; phƣơng pháp thứ 2 là dựa vào bản tin Hello của giao thức RSVP, với bản tin RSVP Hello Node sẽ dò đƣợc lỗi khi không ping thấy Node bên cạnh. Phƣơng pháp này có thời gian dò lỗi lớn hơn, hàng trăm ms, mặc định là 100ms, tuy nhiên có thể cấu hình lại bởi ngƣời sử dụng. Cơ chế sử dụng bản tin RSVP đƣợc xem là cơ chế dò lỗi đầy đủ, bởi vì nó hội tụ nhanh hơn cơ chế IP và MPLS TE không sử dụng FRR.
Hình 2.20. Lỗi đƣợc phát hiện bởi bản tin RSVP hello
Ngay sau khi phát hiện ra lỗi, các PLR có trách nhiệm chuyển lƣu lƣợng truy cập đến tunnel dự phòng. Những tính toán chuyển lƣu lƣợng này sẽ đƣợc nạp vào FIB/LFIB ngay sau khi lỗi đƣợc phát hiện để giảm thiểu gói tin bị lỗi.
Một số kết quả minh họa việc sử dụng cơ chế bảo vệ:
Trƣờng hợp có cấu hình bảo vệ.
Hình 2.21. Trƣờng hợp cấu hình bảo vệ LSP
Hình 2.22. Trƣờng hợp không cấu hình bảo vệ LSP
+ Node Protection:
Trong chế độ này, mỗi router dọc theo đƣờng LSP xây dựng một đƣờng vòng từ nó tới router lối ra, đƣờng này đƣợc tính toán bằng việc sử dụng thông tin trong TED, và một strict-hop ERO đƣợc tạo cho đƣờng vòng. Mục đích của đƣờng vòng là để bảo vệ chống lại những lỗi xảy ra ở Node xuôi chiều kế tiếp trên đƣờng LSP.
Node protection tƣơng tự nhƣ link protection, nó chỉ khác là MP không phải là
NHop mà là NNHop. Với link protection, PLR biết những nhãn nào mà MP đang đợi vì nó nhận ánh xạ nhãn trực tiếp từ MP cho tunnel chính. Tuy nhiên, với node protection, nhãn mà MP muốn thấy không bao giờ đƣợc báo hiệu thông qua RSVP tới
PLR, vì vậy nó sẽ có một số cơ chế khác với link protection.
Hình 2.23. Chế độ bảo vệ Node
Trong ví dụ trên, PLR là 12008a và MP là 7200c.
Tƣơng tự nhƣ trƣờng hợp tạo tunnel dự phòng tới Nhop, ngoại trừ kết thúc tunnel là NNHop chứ không phải là NHop. Ví dụ đoạn cấu hình sau:
12008a#show running-config interface tunnel2 interface Tunnel2
tunnel destination 12.12.12.12
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng path-option 5 explicit name nnhop ip rsvp signalling dscp 0
Việc ghi lại nhãn đƣợc yêu cầu cho tunnel dự phòng NNHOP:
Nhƣ đã trình bày ở trên, MP không biết nhãn nào mà Node dùng cho LSP, trƣờng hợp này, đã sử dụng cờ ghi nhãn (label recording flag). Nó ghi lại nhãn đến (incoming label) sử dụng cho mỗi Hop cho một LSP cho nên PLR trong chế độ protection node biết nhãn nào sử dụng trên LSP đƣợc bảo vệ khi nó chuyển sang tunnel dự phòng (RFC 3902).
Việc ghi đối tƣợng con nhãn trong đối tƣợng RRO (ROUTE_RECORD Object) đƣợc điều khiển bởi cờ ghi nhãn mong muốn trong đối tƣợng SESSION_ATTRIBUTE.
NNHop tunnel điều khiển cả lỗi liên kết và lỗi Node:
Trên hình, chúng ta thấy rằng với tunnel NNHop, khi mà lỗi đƣợc phát hiện trên giao diện Pos1/0 của router 12008a, việc bảo vệ đƣợc kích hoạt, tất cả gói tin đƣợc gửi bởi tunnel chính đƣợc chuyển qua tunnel dự phòng. Nhƣ vậy có thể thấy node protection là bao gồm cả link và node protection.
2.4.Kết luận
Chƣơng 2 đi sâu tìm hiểu chất lƣợng dịch vụ mạng MPLS.
Điều quan trọng nhất đối với mỗi ISP khi triển khai dịch vụ là đảm bảo chất lƣợng dịch vụ cho khách hàng, nó quyết định vị thế, thƣơng hiệu và lợi ích của họ. Khi xây dựng, quy hoạch mạng, các ISP thƣờng xem xét, cân nhắc rất kỹ trong việc lựa chọn công nghệ để triển khai.
Việc đầu tiên của “đảm bảo chất lƣợng dịch vụ” là phải phân loại đƣợc các lớp
dịch vụ cho khách hàng, những dịch vụ quan trọng cơ chế xử lý ƣu tiên hơn những
dịch vụ ít quan trọng. Với công nghệ MPLS, tất cả các thao tác chỉ dừng lại ở mức
nhãn MPLS, nó không thể tƣơng tác lên đƣợc mức IP cho nên không thể dùng các bit
DSCP để phân lớp dịch vụ. Chính vì vậy mà bit Exp trong trƣờng mào đầu MPLS đƣợc sử dụng để phân lớp dịch vụ, do đó có tối đa 8 lớp dịch vụ đƣợc triển khai trong mạng MPLS (nếu triển khai DSCP sẽ đƣợc 64 lớp dịch vụ). Việc ánh xạ giữa các bit Exp và DSCP cũng nhƣ các bit Exp đƣợc gán vào nhãn, đƣợc thao tác trong và ra khỏi mạng MPLS dƣới nhiều hình thức khác nhau tùy theo chế độ sử dụng của các ISP
nhƣ: chế độ Uniform, Short-Pipe hay Pipe. Trên cơ sở đó, các gói tin sẽ đƣợc đối xử
khác nhau khi vào và ra khỏi mạng MPLS.
Thứ hai là phân các gói tin đó vào các hàng đợi tƣơng ứng, mỗi hàng đợi sẽ có những cơ chế xử lý riêng biêt. Một số loại hàng đợi đã đƣợc giới thiệu nhƣ FIFO, CBWFQ, MRRD và LLQ, những hàng đợi này thiết lập ƣu tiên xử lý cho từng loại gói tin trên router trƣớc khi nó đƣợc chuyển tiếp qua giao diện ra của router, đảm bảo ƣu tiên những gói tin quan trọng.
Cơ chế khác đảm bảo chất lƣợng của dịch vụ mạng MPLS là làm rớt gói tin khi hàng đợi đầy hoặc đạt đến ngƣỡng quy định, điều này sẽ tránh đƣợc nghẽn cổ chai tại giao diện ra. Cơ chế WRED vừa tránh đƣợc hiện tƣợng “nghẽn cổ chai” tại giao diện ra vừa phân loại xử lý từng loại gói tin, những gói tin ít quan trọng sẽ bị làm rớt trƣớc những gói tin quan trọng hơn khi nghẽn xảy ra. Bên cạnh đó việc làm rớt gói tin một cách ngẫu nhiên tránh đƣợc một số vấn đề nhƣ: trễ, jitter hay mất mát nhiều thông tin nhƣ khi dùng cơ chế “Tail drop”.
Tuy nhiên, những gói tin có ƣu tiên cao vẫn có thể bị rớt khi nghẽn xảy ra nhiều, trong khi còn những đƣờng khác chƣa bị nghẽn. Kỹ thuật điều khiển lƣu lƣợng (TE)