Xét ví dụ trong hình trên. Giả sử LSR A muốn thiết lập một con đ-ờng t-ờng minh là B-C-D. Để thực hiện việc này, LSR A xây dựng một đối t-ợng ER chứa tuần tự 3 nút trừu t-ợng là LSR B, LSR C, LSR D. Mối nút đ-ợc đại diện bằng một địa chỉ IP prefix. LSR A sau đó xây dựng một bản tin Label Request có chứa đối t-ợng ER mới tạo. Khi bản tin đ-ợc tạo xong, LSR A sẽ xem nút trìu
t-ợng đầu tiên trong đối t-ợng ER là LSR B, tìm kết nối đến LSR B và gửi bản tin Label Request trên kết nối đó. Khi LSR B nhận đ-ợc bản tin Label Request, LSR B nhận thấy nó là nút trừu t-ợng đầu tiên trong đối t-ợng ER. LSR B sau đó
tìm kiếm nút trìu t-ợng kế tiếp là LSR C và tìm kết nối đến LSR C. Sau đó LSR B thay đổi đối t-ợng ER và gửi bản tin Label Request đến LSR C, lúc này đối
t-ợng ER chỉ gồm LSR C và LSR D. Việc điều khiển bản tin này tại LSR C cũng t-ơng tự nh- ở LSR B.
Khi bản tin đến LSR D, LSR D nhận thấy nó là nút cuối cùng trong đối t-ợng ER. Vì vậy, LSR D tạo một bản tin Label Mapping và gửi nó đến LSR C. Bản tin này bao gồm đối t-ợng nhãn. Khi nhận bản tin này LSR C dùng nhãn chứa trong bản tin để cập nhật LFIB. Sau đó, LSR C gửi bản tin Label Mapping
đến LSR B. Bản tin này cũng chứa nhãn mà LSR C đã quảng bá. Việc điều khiển bản tin Label Mapping ở LSR B hoàn toàn t-ơng tự nh- ở LSR C. Cuối cùng, LSR A nhận đ-ợc bản tin và LSP đ-ợc thiết lậptheo con đ-ờng định tuyến t-ờng minh cho tr-ớc để mang thông tin về tài nguyên cần phải dự trữ.
c. Tiến trình dự trữ tài nguyên
Hình 31: Tiến trình dự trữ tài nguyên
Tiến trình dự trữ tài nguyên nh- trong hình trên. Khi một nút CR-LDP nhận
đ-ợc một bản tin Label Request, nó gọi Admission Control để kiểm tra xem nút này có các tài nguyên đ-ợc yêu cầu không. Nếu có đủ tài nguyên khả dụng, Admission Control dự trữ nó bằng cách cập nhật bảng Resource. Sau đó bản tin Label Request đ-ợc chuyển tiếp đến nút MPLS cận kề.
Khi nút CR-LDP nhận bản tin Label mapping, nó l-u thông tin nhãn và giao diện vào bảng LIB, l-u thông tin CR-LSP đ-ợc yêu cầu vào bảng cơ sở thông tin tuyến t-ờng minh ERB (ER Information Base). Rồi nó gọi Resource Manager để tạo một hàng đợi phục vụ cho CR-LSP đ-ợc yêu cầu, và l-u Service ID của nó vào bảng ERB. Cuối cùng, nó chuyển tiếp bản tin LSP Mapping tới nút MPLS kề tr-ớc.
1.3.3 Giao thức RSVP- TE (RSVP- Traffic Engineering)
RSVP có một cơ chế cần thiết để thực hiện báo hiệu phân phối nhãn nhằm
ràng buộc định tuyến. Nguyên lý chức năng của RSVP là thiết lập các dự trữ cho các luồng gói đơn h-ớng. Các bản tin RSVP th-ờng đi theo con đ-ờng hop-by-
hop của định tuyến IP nếu không hiện diện tuỳ chọn tuyến t-ờng minh. Các router hiểu RSVP dọc theo đ-ờng có thể chặn và xử lý bất cứ bản tin nào. RFC 2205 định nghĩa 3 kiểu bản tin RSVP: Thiết lập dự trữ (reservation setup), tear down và error. RSVP-TE cũng định nghĩa thêm bản tin Hello.
a. Các bản tin thiết lập dự trữ RSVP
RSVP sử dụng khái niệm dự trữ ở đầu nhận. Tr-ớc tiên đầu gửi phát ra một bản tin PATH nhận diện một luồng và các đặc tính l-u l-ợng của nó. Bản tin PATH chứa một session-ID, sender-template, label-request, sender-Tspec và tùy
chọn là đối t-ợng tuyến t-ờng minh ERO (explicit route object). Session-ID
chứa một địa chỉ IP đích đi kèm một nhận dạng hầm 16 bit (tunnel ID) để nhận diện một đ-ờng hầm LSP. Nh- đã trình bày ở ch-ơng tr-ớc, chỉ có ingress-LSP
mới cần biết về FEC đ-ợc gán vào một đ-ờng hầm LSP. Do đó, không giống nh- LDP, FEC ánh xạ vào đ-ờng hầm LSP không bao gồm trong bất kỳ bản tin RVSP nào. Đối t-ợng label-request hỗ trợ chế độ công bố nhãn theo yêu cầu. Sender-template chứa địa chỉ IP của đầu gởi đi kèm với một LSP ID có hỗ trợ SK}|QJ WKằF iPDNH-before-EUHDNjkhi thay đổi đ-ờng đi của một đ-ờng hầm LSP. Đặc tính l-u l-ợng Tspec sử dụng tốc độ đỉnh (peak rate), thùng token (token bucket) để định nghĩa tốc độ và kích cỡ bùng phát, đơn vị khống chế tối thiểu (minimum policed unit) và kích th-ớc gói tối đa. Khi bản tin PATH đi đến
đích, bên nhận đáp ứng bằng một bản tin RESV nếu nó đồng ý khởi tạo việc gán kết nhãn đ-ợc yêu cầu trong bản tin PATH. Bản tin RESV đ-ợc truyền về theo đ-ờng ng-ợc chiều với bản tin PATH bằng cách dùng thông tin hop kề tr-ớc trong bản tin PATH. RESV cũng chứa cùng session-ID nh- ở bản tin PATH
t-ơng ứng, đối t-ợng ghi tuyến tùy chọn (route record) và thông tin lệ thuộc kiểu dự trữ (reservation style). Kiểu FF (fixed filter) có một nhãn và Tspec đ-ợc ấn định cho mỗi cặp sender-receiver. Kiểu SE (shared explicit) ấn định một nhãn khác nhau cho mỗi sender, nh-ng tất cả chúng phải áp dụng cùng một dự trữ luồng rõ ràng. Đối t-ợng record-route ghi nhận tuyến đ-ờng thực tế đ-ợc chọn bởi LSP bắt đầu từ egress dẫn ng-ợc về ingress. Nó có thể đ-ợc một router dùng
để ghim một tuyến t-ờng minh thả lỏng bằng cách copy tuyến ghi đ-ợc trong bản tin RESV sang đối t-ợng tuyến t-ờng minh ERO trong một bản tin PATH đ-ợc gửi theo chiều ng-ợc lại.
b. Các bản Tear Down, Error và Hello của RSVP- TE
RSVP-TE định nghĩa 2 bản tin dành cho việc giải tỏa LSP là PATH TEAR và RESV TEAR. Hai bản tin này đ-ợc gửi theo chiều ng-ợc với bản tin PATH và RESV t-ơng ứng. Bản tin TEAR xóa bỏ bất kỳ trạng thái đã cài đặt liên quan đến bản tin PATH hay RESV. Các bản tin TEAR cũng có thể dùng để xóa các trạng thái đáp ứng cho một lỗi ở b-ớc đầu tiên trong hoạt động tái định tuyến.
Có các bản tin thông báo lỗi cho bản tin PATH và RESV cũng nh- bản tin RESV CONFIRMATION tùy chọn. Các bản tin lỗi cho biết có sự vi phạm chính sách, mã hóa bản tin hoặc một số sự cố khác. Ví dụ, khi một LSP thấy rằng nó không thể hỗ trợ Tspec đặc tả trong một bản tin RESV, nó sẽ không chuyển tiếp bản tin RESV về cho phía upstream, thay vào đó nó tạo ra một bản tin RESVERR gửi cho phía downstream để xóa bỏ nỗ lực thiết lập LSP. Tuyến t-ờng minh và các tùy chọn record-route của RSVP-TE có một số các mã lỗi để phục vụ cho việc debug.
RFC 3209 định nghĩa bản tin Hello tùy chọn cho RSVP-TE, nó cho phép một LSR phát hiện một neighbor bị lỗi nhanh hơn khi so với RSVP làm t-ơi tình
trạng hoặc phát hiện lỗi đ-ờng truyền bằng một giao thức định tuyến IP. Điều này khá hữu ích trong việc tái định tuyến nhanh.
c. Thiết lập tuyến t-ờng minh điều khiển tuần tự theo yêu cầu
Hình 32 ví dụ việc trao đổi bản tin RSVP-TE sử dụng đối t-ợng tuyến t-ờng
minh ERO (explicit route object) để cài đặt một LSP đi qua một con đ-ờng không phải là đ-ờng ngắn nhất. Router R1 xác định rằng nó sẽ ấn định FEC
iDEjFKRPưW~}đQJ KP/63YQĐWÂQKUDPưW WX\QW}đQJPLQK5-R5-
R3 để đi đến hop kế cho FEC đó. R1 khởi tạo việc thiết lập LSP này bằng cách phát ra một bản tin PATH đến R4 với một ERO, Tspec, sender template (có chứa địa chỉ của sender) và một đối t-ợng label request. Mỗi bản tin RESV liên quan đến đ-ờng hầm LSP này đều mangsession-ID và filter-spec nguyên thủy của
sender R1 để giữ mối t-ơng quan với nhau. Tiếp theo, R4 tiếp nhận yêu cầu này và gửi bản tin PATH đến router kế tiếp ghi trong ERO là R5. Đến l-ợt mình, R5 gửi bản tin này đến egress-router R3.
Tại đích đến của bản tin PATH, R3 xác định rằng liên kết chặng R3-R5 có
WKKôWU²FKR\zXFXY~ĐOKRSFXơLF³QJWUzQ~}đQJGQFKR)(&iDEj R3 đáp ứng bằng bản tin RESV có chứa ERO, Tspec của dung l-ợng dự trữ, một
filter spec thỏa mãn bên gửi, và gán một nhãn null ngầm (implicit null) cho chặng liên kết này. Theo RFC 3031, nhãn null là một quy -ớc đ-ợc dùng trong phân phối nhãn cho phép egressrouter (ở đây là R3) báo hiệu cho đối tác upstream của nó biết rằng đây là hop áp cuối (penultimate hop) của LSP, do vậy cần gỡ nhãn đỉnh của stack (xem LFIB của LSR R5). Tiếp theo, R5 thu nạp bản tin RESV yêu cầu cho chặng R5-R4, ấn định nhãn B và gởi bản tin RESV đến router kề tr-ớc trong ERO là R4. Cuối cùng, R4 chấp nhận yêu cầu, ấn định nhãn A và gởi bản tin RESV ng-ợc về R1. Đến lúc này, đ-ờng LSP đ-ợc thiết
Hình 32: Thiết lập LSP với RSVP-TE
Khác với giao thức LDP, các bản tin RSVP-TE không mang FEC vì chỉ duy nhất có R1 cần biết về ánh xạ giữa FEC và đ-ờng hầm LSP.
d. Giảm l-ợng Overhead làm t-ơi RSVP
RSVP là giao thức trạng thái mềm (soft-state), tiến trình phát một bản tin PATH và bản tin RESV hồi đáp t-ơng ứng phải đ-ợc định kỳ làm t-ơi, th-ờng khoảng 30s một lần. Ph-ơng pháp làm t-ơi này đề phòng các bản tin bị mất và trong tr-ờng hợp định tuyến từng chặng sẽ tự động chuyển dự trữ tài nguyên sang đ-ờng mới khi có bất kỳ thay đổi định tuyến IP. Tất nhiên, việc xử lý dành cho khởi tạo các bản tin PATH và RESV lớn hơn nhiều so với việc làm t-ơi trạng thái một bản tin đã nhận tr-ớc đó, tuy nhiên với một số l-ợng lớn các LSP thì việc xử lý làm t-ơi có ảnh h-ởng đáng kể đến hiệu năng. Một cách để giải quyết là tăng chu kỳ làm t-ơi, nh-ng cũng sẽ làm tăng độ trễ báo hiệu khi mất bản tin. RFC 2961 đặc tả một giải pháp cho hạn mức xử lý và vấn đề trễ báo hiệu. Cơ chế này bao gồm việc bó gọn bản tin để giảm tải xử lý, cũng nh- các cách để router dễ dàng nhận dạng một bản tin không thay đổi hơn. Việc hồi báo bản tin cũng đ-ợc bổ sung để chuyển tải tin cậy bản tin RSVP và xử lý tr-ờng hợp mất các
bản tin PATH TEAR và RESV TEAR vì hai bản tin này không đ-ợc làm t-ơi trong hoạt động RSVP. Cuối cùng, giải pháp này định nghĩa một bản tin tổng kết (summary) để làm t-ơi trạng thái mà không yêu cầu truyền toàn bộ bản tin làm
t-ơi. Các cải tiến này nhằm giảm l-ợng overhead làm t-ơi của RSVP trong mạng MPLS.
1.3.4 Giao thức BGP (Boder Gateway Protocol)
a. BGPv4 và mở rộng cho MPLS
BGPv4 (Border Gateway Protocol) là một giao thức định tuyến để gắn kết tập hợp các mạng cung cấp dịch vụ trên Internet. Vì nó chỉ là giao thức sử dụng giữa các nhà cung cấp, RFC 4271 đã mở rộng BGP hỗ trợ phân phối nhãn MPLS để có thể thiết lập các LSP liên mạng.
BGP có một tập thuật ngữ riêng. Một khái niệm quan trọng là số AS duy nhất (Autonomous System), đ-ợc định nghĩa là một tập hợp router thực hiện một chính sách định tuyến ngoại thống nhất có thể nhận thấy đối với router của AS khác. BGP không truyền các thông tin topology nội giữa các AS, nó chỉ cung cấp các thông tin về các prefix địa chỉ mà có thể tìm đến hoặc đi quá giang qua đó. Sử dụng BGP giữa các router biên (border) nội trong một AS đ-ợc gọi là BGP nội (iBGP), còn sử dụng BGP giữa các router trong các AS khác nhau đ-ợc gọi là BGP ngoại (eBGP).
BGP chạy trên một phiên TCP vì nó cần độ tin cậy, phân phát đúng thứ tự. Nó có 3 phase hoạt động: thiết lập phiên, trao đổi bản tin cập nhật, và chấm dứt phiên. Trong thiết lập phiên, các đối tác BGP (BGP peer) trong các AS lân cận trao đổi các bản tin OPEN có chứa AS number, một giá trị keep-alive timeout, và
các tham số tùy chọn nh- nhận thực. Các BGP peer định kỳ trao đổi bản tin keep-alive, nếu phát hiện timeout sẽ chấm dứt phiên. Sau khi thiết lập phiên, các BGP peer trao đổi các bản tin UPDATE có chứa các prefix địa chỉ có thể đến đ-ợc hiện hành (reachability), đ-ợc gọi là NLRI (Network Layer Reachability
Information). Sau khi trao đổi đồng bộ khởi tạo, các thay đổi định tuyến gia tăng đ-ợc liên lạc bằng bản tin UPDATE.
Nội dung bản tin BGP UPDATE gồm 3 phần: các tuyến thu hồi (withdrawn route), một danh sách các prefix địa chỉ NLRI, và một danh sách tùy chọn các thuộc tính liên quan. Các BGP peer tạo quyết định chính sách cục bộ khi xem xét công bốự một NLRI với các thuộc tính đ-ờng đ-ợc chọn hay thu hồi thông cáo tr-ớc đó. Chính sách th-ờng dùng là chọn NLRI có prefix địa chỉ đặc tả so trùng nhất, chọn một đ-ờng có số hop AS ít nhất.
Hình 33: Nội dung bản tin BGP Update
Khi bản tin UPDATE chứa thông tin NLRI, một số thuộc tính đ-ờng là bắt buộc trong khi một số khác là tùy chọn. Các thuộc tính đ-ờng bắt buộc là: ORIGIN, ASPATH, và NEXT-HOP. ORIGIN nhận diện nguồn gốc của NLRI, thí dụ nó đ-ợc học qua giao thức đinh tuyến nội hay ngoại. AS-PATH liệt kê một
path-vector gồm một tập AS đã đi qua đến thời điểm hiện tại (một chuỗi thứ tự các AS). Vì chiều dài của AS-PATH th-ờng là yếu tố quyết định chọn một tuyến, nên BGP đ-ợc gọi là giao thức định tuyến path-vector. Các router sử dụng AS-PATH để tránh loop bằng cách không chuyển tiếp các thông cáo tuyến có chứa số AS của chúng. NEXT-HOP nhận diện địa chỉ IP của router biên cần dùng để tìm đến NLRI. BGP có một số tham số tùy chọn có thể thực hiện một dạng cân bằng tải: LOCALPREF và MED. LOCALPREF cho phép AS đầu gởi chỉ định một sự -u tiên (preference) định tuyến l-u l-ợng đi ra trên nhiều liên kết đến AS khác; trong khi MED (multiple exit discriminator) cho phép một AS phía nhận chỉ định một -u tiên cho l-u l-ợng đến từ một AS khác.
RFC 2283 định nghĩa các mở rộng đa giao thức cho BGP để phân phối nhãn MPLS nằm trong một phần của NLRI. Các BGP peer th-ơng l-ợng hỗ trợ cho
khả năng tùy FKăQQ\YROảFWKLWOSSKLzQ7K´WãFF|EQOiNÀVLQKjYLF phân phối nhãn theo kiểu không cần yêu cầu song song khi thực hiện phân phối
tuyến BGP.
b. Kết nối MPLS qua nhiều nhà cung cấp
Hình 34: BGP phân phối nhãn qua nhiều Autonomous System
BGP có thể dùng để thiết lập phân phối nhãn cho các LSP đi xuyên qua các mạng của nhiều nhà cung cấp khác nhau. Hình trên gồm 3 hệ tự trị là A, B và C.
AS A cấp SKWFKRNKFKKQJSUHIL[~ÊDFK)(&iDEj5RXWHUC3 quảng bá nó nh- một NLRI cho AS-A và AS-B bằng bản tin BGP UPDATE có chứa
next-hop và ASPATH. Bản tin UPDATE đ-ợc gởi bởi C3 đến A3 còn mang một QK[Wá)(&iDEjVDQJ nhãn L. Router A3 trong AS A thu thập tất cả các thông cáo này vào trong bảng RIB của nó, thí dụ thông qua một l-ới các phiên
L%*3KRFPưWiURXWHUHIOHFWRUj1KP tìm cách tốt nhất để chuyển tiếp các gói
~QSUHIL[iDEj$FĐWK[F~ÊQKUQJ đ-ờng AS ngắn nhất là qua hop kế A3 sử dụng nhãn L. Nhờ định tuyến nội và giao thức phân phối nhãn của mình,
router A1 cũng biết rằng tuyến tốt nhất để đến A3 là đi qua A2 sử dụng nhãn M.
push tiếp nhãn M trên đỉnh stack. Nh- vậy, một LSP đ-ợc chui bên trong một đ-ờng hầm LSP khác. LSP1 bên ngoài kéo dài từ A1 đến A3. Trong khi đó, LSP2 kéo dài từ AS A đến AS C và có một đoạn chui bên trong LSP1.
1.4 Ưu , nh-ợc điểm của công nghệ MPLS 1.4.1 Ưu điểm của công nghệ MPLS
a. Đơn giản hoá chức năng chuyển tiếp
MPLS sử dụng cơ chế chuyển tiếp căn cứ vào nhãn có độ dài cố định nên