Thiết lập LSP và CR-LD

Một phần của tài liệu đồ án: Kỹ thuật lưu lượng trong MPLS và cơ chế bảo vệ khôi phục đường và dựng chương trình mô phỏng MPLS-TE (Trang 32 - 35)

Khi bản tin đến LSR D, LSR D nhận thấy rằng nó là nút cuối cùng trong đối tượng ER. Vì vậy, LSR D tạo nên một bản tin Label Mapping và gửi nó đến LSR C. Bản tin này để 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ập theo 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ữ.

1.7.2.3 Tiến trình dự trữ tài nguyên

. Khi một nút CD-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 ngun được 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 kề sau.

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-LDP được yêu cầu vào bảng cơ sở thông tin tuyến tường minh ERB (Explicit Route information Base). Rồi nó gọi Resource Manager để taọ một bảng 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.7.3 Giao thức RSVP-TE

RSVP có một số 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. IETF đã chuyên hóa mở rộng kỹ thuật lưu lượng RSVP-TE, định nghĩa các ứng dụng của RSVP-TE như hỗ trợc phân phối nhãn theo yêu cầu để cấp phát tài nguyên cho các LSP định tuyến tường minh.

1.7.3.1 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 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ợ phương thức “make-before-breal” khi thay đổi đường đi của một đường hầm LSP. Đặc tính lưu lượng của Tspec sử dụng tốc độ đỉnh (peak rate), thùng token (token bucket) để định nghĩa tốc độ và kích thước bùng phát, đơn vị khống chế tối thiểu 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 tao 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 chặng kề trước trong bản tin PATH. RESV cũng chứa cùng sesion-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 (share explicit) ấn định một nhãn khác nhau cho mỗi sender, nhưng tất cả chúng ta 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ừ lối ra dẫn ngược về lối vào. Nó có thể được một bộ định tuyến dùng để ghim một tuyến tường minh thả lỏng bằng cách copy tuyến ghi được trong một 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.

1.7.3.2 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 lạ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ỗi lỗi ở bước đầu tiên trong hoạt động đị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 đường lên, thay vào đó nó tạo ra một bản tin RESVERR gửi cho phía đường xuống để xóa bỏ nỗ lực thiết lập LSP. Tuyến tường minh và các tùy chọn tuyến ghi 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 mớ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.

1.7.3.3 Thiết lập tuyến tường minh điều khiển tuần tự theo u cầu

Hình 1.30 ví dụ việc trao đổi bản tin RSVP-TE sử dụng đối tượng tuyến tường minh ERO (expplicit route object) để cài đặt một LSP đi qua một con đường không phải là đường ngắn nhất. Bộ định tuyến R1 xác định rằng nó sẽ ấn định FEC “a.b/16” cho một đường hầm LSP, và nó tính ra một tuyến tường minh R4-R5-R3 để đi đến chặng 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 mang session-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 bộ định tuyến kế tiếp ghi trong ERO là R5. Đến lượt mình, R5 gửi bản tin này đến lối ra của bộ định tuyến 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ó thể hỗ trợ cho yêu cầu và đó là chặng cuối cùng trên đường dẫn FEC “a.b/16”. 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 thời RFC 3031, nhãn null là một quy ước được dùng trong phân phối nhãn cho phép lối ra của bộ định tuyến (ở đây là R3) báo hiệu cho đối tác đường lên của nó biết rằng đây là chặng áp cuối (penulitmate hop) của LSP, do vậy cần gỡ nhãn đỉnh của ngăn xếp. Tiếp theo, R5 thu nạp bản tin RESV ngược về R1. Đến lúc này, đường LSP được thiết lập xong và các gói có nhãn cho FEC “a.b/16” được chuyển tiếp qua đường hầm.

Một phần của tài liệu đồ án: Kỹ thuật lưu lượng trong MPLS và cơ chế bảo vệ khôi phục đường và dựng chương trình mô phỏng MPLS-TE (Trang 32 - 35)

Tải bản đầy đủ (DOC)

(83 trang)
w