1.7.1.1 Hoạt động của LDP
LDP có 4 chức năng chính là phát hiện LSR láng giếng (neighbor discovery), thiết lập và duy trì phiên, quảng bá nhãn và thơng báo. Tương ứng với các chức năng trên, có 4 lớp thơng điệp LDP sau đây:
• Discovery: Để trao đổi định kỳ bản tin Hello nhằm loan báo và kiểm tra
một LSR kết nối gián tiếp hoặc trực tiếp.
• Session: Để thiết lập, thương lượng các thông số cho việc khởi tạo, duy trì
và chấm dứt các phiên ngang hàng LDP. Nhóm này bao gồm bản tin Initialization ,KeepAlive.
• Advertisement: Để tạo ra, thay đổi hoặc xóa các ánh xạ FEC tới nhãn.
Nhóm này bao gồm bản tin Label Mapping, Label Withdrawal, Label Release, Label Request, Label Request Abort.
• Notification: Để truyền đạt các thông tin trạng thái, lỗi hoặc cảnh báo.
Các thông điệp Discovery được trao đổi trên UDP. Các kiểu thơng điệp cịn lại đòi hỏi phân phát tin cậy nên dùng TCP. Trường hợp hai LSR có kết nối lớp 2 trực tiếp thì thủ tục phát hiện neighbor trực tiếp như sau:
• Một LSR định kỳ gửi đi bản tin Hello tới các cổng UDP 646 địa chỉ multicast.
• Tất cả các LSR tiếp nhận bản tin Hello này trên cổng UDP. Đến một thời điểm nào đó LSR sẽ biết được tất cả các LSR khác mà nó kết nối trực tiếp.
• Khi LSR nhận biết được địa chỉ của LSR khác bằng cơ chế này thì nó sẽ thiết lập kết nối TCP đến LSR đó. Khi đó phiên LDP được thiết lập giữa 2 LSR.
Phiên LDP là phiên song hướng nên mỗi LSR ở hai đầu kết nối đều có thể yêu cầu và gửi liên kết nhãn.
Trong trường hợp hai LSR khơng có kết nối lớp 2 trực tiếp (neighbor gián tiếp) thì LSR định kỳ gửi bản tin Hello đến cổng UDP đã biết tại địa chỉ IP xác định được khai báo khi lập cấu hình. Đầu nhận bản tin này có thể trả lời lại bằng bản tin Hello khác và việc thiết lập các phiên LDP được thực hiện như trên.
1.7.1.2 Cấu trúc thông điệp LDP
Trao đổi thông điệp LDP thực hiện bằng cách gửi các LDP-PDU (Protocol Data Unit) thông điệp qua các phiên LDP trên kết nối TCP. Mỗi LDP-PDU có thể mang một hoặc nhiều thơng điệp, và các thơng điệp này khơng nhất thiết phải có liên quan với nhau.
Mỗi PDU của LDP bao gồm một tiêu đề LDP và theo sau là một hoặc nhiều thông điệp LDP. Phần tiêu đề LDP có dạng như hình 1.26:
Hình 1.26: LDP Hearder
PDU Length (2 octet): số nguyên chỉ chiều dài của PDU theo octet, khơng tính trường Version và PDU Length. LDP Identifier (6 octet): xác định không gian nhãn được cấp phát. Bốn octet đầu là giá trị duy nhất toàn cục nhận dạng LSR, như địa chỉ IP (bộ định tuyến ID) được gán cho LSR. Hai octet sau xác định một không gian nhãn bên trong LSR. Hai octet này được set về 0 cho không gian nhãn “per-platform”.
Tất cả các thơng điệp LDP có cùng format như hình 1.27:
Hình 1.27: Format thơng điệp LDP
Bit U: bit unknown, ln là 0 vì đặc tả LDP khơng có kiểu bản tin Unknown. Message Length : Chiều dài của các trường sau Message Length tính theo octet (gồm Message ID, các tham số bắt buộc và tùy chọn).
Messafe ID đôi khi được dùng để liên kết một số bản tin với các bản tin khác, ví dụ một bản tin đáp ứng có cùng Message ID với bản tin yêu cầu tương ứng. Các tham số bắt buộc và tùy chọn phụ thuộc vào các loại bản tin được gửi, chúng thường dùng kiểu mã hóa TLV (Type-Length-Value). Nói chung, mọi thứ xuất hiện trong một thơng điệp LDP có thể được mã hóa kiểu TLV, tuy nhiên đặc tả LDP không phải lúc nào cũng sử dụng lược đồ TLV.
1.7.1.3 Các bản tin LDP
• Hello: Được trao đổi trong suốt q trình hoạt động LDP như trình bày ở trên.
• Initialization: Được gửi khi bắt đầu một phiên LDP giữa 2 LSR để trao đổi các tham số, các tùy chọn cho phiên. Các tham số này bao gồm:
• Chế độ phân bổ nhãn.
• Các giá trị bộ định thời
• Phạm vi các nhãn sử dụng trong kênh giữa 2 LSR đó.
Cả 2 LSR đều có thể gửi các bản tin Initialization và LSR nhận sẽ trả lời bằng KeepAlive nếu các tham số được chấp nhận. Nếu có một tham số nào đó khơng được chấp nhận thì LSR trả lời thơng báo có lỗi nếu phiên kết thúc.
o KeepAlive : Được gửi định kỳ khi khơng cịn bản tin nào cần gửi để đảm bảo cho mỗi thành phần LDP biết rằng thành phần LDP khác đang hoạt động tốt. Trường hợp không xuất hiện bản tin KeepAlive hay một số bản tin LDP khác trong khoảng thời gian nhất định thì LSR sẽ xác định đối tác LDP hỏng hoặc kết nối có sự cố và phiên LDP chấm dứt.
o Label Mapping : Được sử dụng để quảng bá gán kết giữa FEC và nhãn.
o Label Withdrawal : Thực hiện quá trình ngược lại với bản tin Label Mapping. Nó được sử dụng để xóa bỏ gán kết đã thực hiện trong Label Mapping. Bản tin này được sử dụng trong trường hợp :
Khi có sự thay đổi trong bảng định tuyến (thay đổi tiền tố địa chỉ), lúc đó LSR khơng cịn nhận ra FEC này nữa.
Thay đổi trong cấu hình LSR làm tạm dừng việc chuyển nhãn các gói trong FEC đó.
o Label Release : Được sử dụng bởi LSR khi nhận được chuyển đổi nhãn mà nó khơng cần thiết nữa. Điều đó thường xảy ra khi LSR giải phóng nhận thấy nút tiếp theo cho FEC không phải là LSR quảng bá liên kết nhãn/FEC đó.
o Label Request : Sử dụng trong chế độ hoạt động gán nhãn theo yêu cầu, LSR sẽ yêu cầu gán nhãn LSR kế cận phía đường xuống bằng bản tin này.
o Label Request Abort : Nếu bản tin Label Request cần phải hủy bỏ trước khi được chấp nhận (do nút kế tiếp trong FEC yêu cầu đã thay đổi), thì LSR yêu cầu sẽ loại bỏ yêu cầu trước đó bằng bản tin Label Request Abort.
1.7.1.4 LDP điều khiển độc lập và phân phối theo yêu cầu
Ví dụ dưới đây (hình 1.28) minh họa việc sử dụng bản tin Label Request và Label Mapping.
Trong các chế độ công bố nhãn theo yêu cầu và điều khiển độc lập. Trình tự thời gian trao đổi các bản tin LDP giữa các đối tác (peer) thiết lập một LSP từ bộ định tuyến lối vào R1 qua R2 rồi đến bộ định tuyến lối ra R3 cho một FEC có tiền tố “a.b/16”. R1 khởi tạo tiến trình bằng cách yêu cầu một nhãn cho FEC “a.b/16” từ chặng kế của nó R2. Vì sử dụng điều khiển độc lập nên R2 trả ngay một ánh xạ nhãn về cho R1 trước khi R2 nhận được ánh xạ nhãn từ phía đường xuống là R3. Cả R2 và R3 đáp ứng bằng bản tin Label Mapping, kết quả là trong FIB của R1 và LFB của R2, R3 có các thực thể gắn kết nhãn hình thành nên đường chuyển mạch nhãn LSP.
Hình 1.28: LDP chế độ điều khiển theo yêu cầu
LDP còn hỗ trợ các chế độ phân phối nhãn khác. Khi cấu hình ở chế độ cơng bố khơng cần u cầu (downstream unsolicited), các bộ định tuyến sẽ không dùng bản tin Label Request. Nếu điều khiển tuần tự (ordered control) được cấu hình trên mỗi giao diện, các yêu cầu nhãn sẽ làm cho các bản tin Label Mapping được trả về theo thứ tự từ R3 đến R2, rồi mới từ R2 về R1. Tổng quát, trong chế độ phân phối theo yêu cầu điều khiển tuần tự, ánh xạ nhãn diễn ra đầu tiên ở bộ định tuyến lối ra, rồi sau đó lần lượt ngược về đến bộ định tuyến lối vào.
1.7.2 Giao thức CR-LDP
CR-LDP (constrain-based routing LDP) là giao thức mở rộng từ LDP (RFC 3212) nhằm hỗ trợ đặc biệt cho định tuyến ràng buộc, kỹ thuật lưu lượng và các hoạt động dự trữ tài nguyên. Các khả năng của CR-LDP tùy chọn bao gồm thương lượng các tham số lưu lượng như cấp phát băng thông, thiết lập và cầm giữ quyền ưu tiên.
1.7.2.1 Mở rộng cho định tuyến ràng buộc
CR-LDP bổ sung thêm các đối tượng Type-Length-Value mới sau đây :
• Tuyến tường minh ER
• Chặng tường minh ER-Hop
• Các tham số lưu lượng
• Sự lấn chiếm (Preemptions)
• Nhận diện LSP (LSPID)
• Lớp tài nguyên (Resource Class)
• CR-LSP FEC
Một số thủ tục mới cũng được bổ sung để hỗ trợ các chức năng cần thiết như: o Báo hiệu đường (Path Signalling)
o Định nghĩa các tham số lưu lượng
o Quản lý LSP ( quyền ưu tiên, cam kết quản trị….)
CR-LDP sử dụng cơ chế gán nhãn theo yêu cầu và điều khiển tuần tự. Một LSP được thiết lập khi một chuỗi các bản tin Label Request lan truyền từ ingress-LSR đến egress-LSR, nếu đường được yêu cầu thỏa mãn các ràng buộc (ví dụ như đủ băng thơng khả dụng), thì các nhãn mới được cấp phát và phân phối bởi một chuỗi các bản tin Label Mapping lan truyền ngược về ingress-LSR. Việc thiết lập một CR-LSP có thể thất bại vì nhiều lý do khác nhau và các lỗi sẽ được báo hiệu bằng bản tin Notification.
1.7.2.2 Thiết lập một CR-LSP
Để thiết lập một LSP theo một con đường định trước, CR-LDP sử dụng đối tượng tuyến tường minh ER. ER được chứa trong các bản tin Label.
Xét ví dụ trong hình 1.29. 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 đố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 tiền tố. LSR A sau đó được 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 xét 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. Khu LSR B nhận 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ũng tương tự như ở LSR B.
Hình 1.29: Thiết lập LSP và CR-LD
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 yêu cầu