Luận văn Chuyển mạch nhãn đa giao thức MPLS và ứng dụng

hời gian trễ trước khi dòng lưu lượng đi trên LSP có thể bắt đầu. Tuy nhiên, điều khiển tuần tự cung cấp phương tiện tránh Loop và đạt được mức độ thu gom chắc chắn hơn. Hình 4-7 : Điều khiển tuần tự. Các giao thức phân phối nhãn MPLS. Giao thức phân phối nhãn là một tập các thủ tục mà nhờ nó một LSR có thể lưu thông báo cho một LSR khác biết về các mối gán kết nhãn FEC mà nó đã tiến hành. Kiến trúc MPLS không chỉ định một giao thức phân phối nhãn duy nhất nào, do đó có thể có nhiều lựu chọn, mỗi giao thức có ưu điểm và nhược điểm riêng. Trong các phần tiếp theo giới thiệu một số giao thức phân phối nhãn được dùng phổ biến. - Hình 4-8: Một số giao thức phân phối nhãn. Giao thức LDP (Label Distribution protocol). LDP được chuẩn hóa trong RFC 3036, nó được thiết kế để thiết lập và duy trì các LSP định tuyến không ràng buộc (Unconstraint Routing). Vùng hoạt động của LDP có thể là giữa các LSR láng giềng (Neighbor) trực tiếp hoặc gián tiếp. Hình 4-9: Vùng hoạt động LDP. 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 (Label Advertisement) và thông báo ( Notification). 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 lỳ bản tin Hello nhằm thông 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, 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 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ó có kết quả 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. Hình 4-10: Trao đổi thông điêp LDP. 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 thiết 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. 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 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. LDP PDU. Mỗi PDU của LDP bao gồm một Header LDP và theo sau là một hoặc nhiều thông điệp LDP. Phần header LDP có dạng sau: Hình 4-11: Label Header. PDU Length (2 octec): số nguyên chỉ chiều dài của PDU theo octec, 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. 4 octec đầu là giá trị duy nhất tồn cục nhận dạng LSR, như địa chỉ IP (Router ID) được gán cho LSR. Hai octets sau xác định một không gian nhãn bean trong LSR. 2 octecs này được set về 0 cho không gian nhãn” per-platform”. Định dạng thông điệp LDP. Tất cả các thông điệp LDP có cùng format như sau: Hình 4-12: Format thông điệp LDP. Bit U: bit”Unknown”, luôn là 0 và đặc tả LDP không có kiểu bản tin Unknown. Bảng sau là các giá trị định nghĩa trường Message type. Hình 4-13: Các loại bản tin LDP 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). Message 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 sẽ có cùng Message ID với bản 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 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 theo 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. Các bản tin LDP. Bản tin Notification. 0 1 – 14 15 16 – 30 31 0 Notification (0x0001) Message Length Message ID Status (TLV) Optional Parameters Hình 4-14:Bản tin Notification. LSR sử dụng bản tin Notification để báo cho các LSR cung cấp về các điều kiện bất thường hay có lỗi như : Nhận biết các bản tin bị khiếm khuyết, bị lỗi hay không xác định. Hồn thành đồng hồ keep-alive Việc ngắt (shutdown) bởi một nút mạng. Lỗi trong sự khởi đầu một phiên LDP. Trong một vài trường hợp, LSR có thể kết thúc phiên LDP (đóng kết nối TCP). Cấu trúc của bản tin này được thể hiện như hình II.4-4 Số nhận dạng của bản tin (message ID) là duy nhất cho mỗi bản tin, nó sẽ được mã hóa trong tất cả các bản tin. Trạng thái TLV chỉ thị trạng thái của sự việc. Tham số không bắt buộc là các TLV này : Trạng thái mở rộng. PDU đáp ứng (returned). Bản tin đáp ứng (returned). Khi một LSR nhận một bản tin Notification chứa đựng mã trạng thái chỉ thị lỗi không thể tránh khỏi (fatal error), nó sẽ kết thúc phiên LDP ngay lập tức bằng cách đóng kết nối phiên TCP và loại bỏ tất cả các trạng thái liên quan đến phiên, bao gồm cả việc kết nối nhãn FEC được nhận biết từ phiên làm việc. Bản tin Hello. 0 1 – 14 15 16 – 30 31 0 Hello (0x0100) Message Length Message ID Common Hello Parameters (TLV) Optional Parameters Hình 4-15: Bản tin Hello Bản tin Hello đươc sử dụng để trao đổi giữa 2 thực thể LDP ngang cấp trong suốt quá trình phát hiện LDP. Cấu trúc của bản tin này được thể hiện trên hình trên. Trường Common Hello Parameters : cần nhắc lại rằng các LSR lân cận sẽ trao đổi các bản tin Hello theo chu kỳ với nhau để chắc chắn rằng chúng đang hoạt động. Các TLV này chứa các tham số thông thường để quản lý chi tiết quá trình trao đổi bản tin Hello, nó xác định số bản tin Hello gửi và nhận và ghi nhận số lần bản tin Hello gửi và nhận trong một chu kỳ thời gian. 0 1 2 – 14 15 16 17 – 30 31 0 0 Common Hello Parameters (0x0400) Length Hold Time T R Reserved Hình 4-16: Trường Common Hello parameters TLV Một LSR sẽ duy trì một bản ghi (record) của bản tin Hello nhận từ các LSR cùng cấp. Trường Hello Hold Time xác định thời gian LSR gửi sẽ duy trì bản ghi các bản tin Hello từ LSR nhận mà không nhận thêm một bản tin Hello nào khác. Hai LSR sẽ trao đổi tham số hold time mà chúng sử dụng cho các bản tin Hello. Mỗi bên sẽ đề nghị một tham số Hold Time. Tham số Hold Time được sử dụng sẽ là tham số có giá trị nhỏ nhất. Bit T (Targeted): Nếu bit có giá trị 1 thì bản tin Hello này gọi là bản tin Targeted Hello. Nếu bit có giá trị 0 thì bản tin Hello này gọi là bản tin Link Hello. Bit R (Request Send Targeted Hello): Nếu bit R có giá trị 1 thì phía nhận sẽ được yêu cầu gửi bản tin Targeted Hello về phía khởi đầu bản tin Hello. Còn nếu nó có giá trị là 0 thì sẽ không có yêu cầu nào được đưa ra. Trường Reserved : là trường dự trữ cho tương lai Bản tin Initialization. 0 1 – 14 15 16 – 30 31 0 Initialization (0x0200) Message Length Message ID Common Session Parameters (TLV) Optional Parameters Hình 4-17:Bản tin Initialization Các bản tin thuộc loại này đượ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 và phiên kết thúc. Trường Common Session Parameters: Trường TLV này chứa giá trị từ LSR gửi để thông báo rằng phải thông báo tại mỗi phiên LDP. Các thông số này gồm: Keep-alive time: xác định khoảng thời gian lớn nhất để nhận thành công các PDU từ các LSP cùng cấp trên kết nối phiên TCP. Đồng hồ keep-alive sẽ được reset mỗi khi có một PDU. Loop detection: xác định các vòng là enabled hay disabled PATH vector limit: xác định độ dài lớn nhất của vector PATH. Maximum PDU length: xác định độ dài lớn nhất của một PDU LDP. Receiver LDP identifier: nhận dạng không gian nhãn của người nhận. Bản tin KeepAlive. 0 1 – 14 15 16 – 30 31 0 KeepAlive (0x0201) Message Length Message ID Optional Parameters Hình 4-18: Bản tin KeepAlive. Các bản tin KeepAlive được gửi định kỳ khi không có bản tin nào được 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. Trong trường hợp không xuất hiện bản tin KeepAlive hay một số bản tin khác của LDP trong khoảng thời gian nhất định thì LSR sẽ xác định đối phương hoặc kết nối bị hỏng và phiên LDP bị dừng. Bản tin Address. 0 1 – 14 15 16 – 30 31 0 Address (0x0300) Message Length Message ID Address List (TLV) Optional Parameters Hình 4-19: Bản tin Address. Bản tin Address được một LSR gửi đến LSR cùng cấp của nó để quảng bá về các địa chỉ giao diện. Một LSR nhận một bản tin Address sẽ sử dụng các địa chỉ để duy trì một cơ sở dữ liệu cho việc trao đổi giữa các bộ nhận dạng LDP ngang cấp và các địa chỉ của hop tiếp theo. Trường Address list là một danh sách các địa chỉ IP được phát bởi LSR gửi.Trong bản tin này không có một tham số tuỳ biến nào (optional parameters) Bản tin Address Withdraw. 0 1 – 14 15 16 – 30 31 0 Address Withdraw (0x0301) Message Length Message ID Address List (TLV) Optional Parameters Hình 4-20: Bản tin Address Withdraw Bản tin Address Withdraw xóa bản tin Address và gỡ bỏ các địa chỉ và các giao tiếp địa chỉ được phát trước đó. Trường Address List TLV chứa danh sách các địa chỉ được gỡ bỏ bởi LSR phía phát. Trong bản tin này cũng không có các tham số tuỳ biến Bản tin Label Mapping. Các bản tin Label Mapping được sử dụng để quảng bá liên kết giữa FEC (Prefix địa chỉ) và nhãn. Bản tin Label Withdrawal thực hiện quá trình ngược lại: nó được sử dụng để xóa bỏ liên kết vừa thực hiện. Bản tin này được sử dụng khi có sự thay đổi trong bảng định tuyến (thay đổi Prefix địa chỉ) hay 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 đó. 0 1 – 14 15 16 – 30 31 0 Label Mapping (0x0400) Message Length Message ID FEC TLV Label TLV Optional Parameters Hình 4-21: Bản tin Label Mapping. Trường FEC TLV: chứa nhóm chuyển tiếp tương đương mà nhóm này sẽ được gán cho một nhãn, nhãn này nằm trong trường Label TLV. Trường Label TLV: chứa nhãn được gán cho nhóm chuyển tiếp tương đương. Trường Optional TLV: gồm có số nhận dạng bản tin yêu cầu nhãn, tổng số hop và vector đường (path vector). Bản tin Label Request. 0 1 – 14 15 16 – 30 31 0 Label Request (0x0401) Message Length Message ID FEC TLV Optional Parameters Hình 4-22: Bản tin Label Request. LSR đưa ra bản tin này để yêu cầu một thực thể LDP ngang cấp cung cấp một nhãn cho nhóm chuyển tiếp tương đương FEC. Một LSR có thể gửi bản tin này khi : LSR phát hiện một lớp chuyển tiếp tương đương mới thông qua bảng chuyển tiếp, hop kế tiếp là một thực thể LDP ngang cấp, và LSR không có sự ánh xạ (FEC-label) nào từ hop kế tiếp cho nhóm chuyển tiếp tương đương mới này. Hop kế tiếp có sự thay đổi nhóm chuyển tiếp tương đương FEC mà nó lại không thông báo về sự thay đổi này cho LSR. LSR nhận được một bản tin Label Request cho một nhóm chuyển tiếp tương đương từ một thực thể LDP đường lên ngang cấp. Trường FEC TLV: xác định giá trị nhãn sẽ được yêu cầu. Trường optional TLV: gồm có tổng số hop và vector đường (PATH vector). Bản tin Label Withdraw. 0 1 – 14 15 16 – 30 31 0 Label Withdraw (0x0402) Message Length Message ID FEC TLV Label TLV (optional) Optional Parameters Hình 4-23:Bản tin Label Request. Bản tin này loại bỏ sự ánh xạ giữa các nhóm chuyển tiếp tương đương với các nhãn. Nó được gửi đến 1 thực thể LDP ngang cấp để chỉ thị rằng nút không tiếp tục sử dụng các kết nối giữa nhóm chuyển tiếp tương đương FEC với nhãn mà LSR này đã quảng bá. Một LSR sẽ truyền các bản tin Label Withdraw khi: LSR không còn phát hiện nhóm chuyển tiếp tương đương được biết trước đó mà nó đã quảng bá một nhãn cho FEC đó. LSR đơn phương chấm dứt sự ánh xạ giữa một lớp chuyển tiếp tương đương với một nhãn. Trường FEC TLV xác định các lớp chuyển tiếp tương đương mà các nhãn tương ứng sẽ bị gỡ bỏ. Nếu không có trường Label TLV theo sau FEC TLV thì tất cả các nhãn tương ứng với FEC đó sẽ bị gỡ bỏ. Ngược lại, nếu có trường Label TLV thì chỉ có nhãn được thông báo trong trường này mới bị gỡ bỏ. Một LSR khi nhận được bản tin Label Withdraw thì nó sẽ hồi đáp bằng một bản tin Label Release. Bản tin Label Release. 0 1 – 14 15 16 – 30 31 0 Label Release (0x0403) Message Length Message ID FEC TLV Label TLV (optional) Optional Parameters Hình 4-24: Bản tin Label Release LSR sẽ gửi bản tin này 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 đó. Một LSR sẽ truyền bản tin này khi: LSR gửi ánh xạ nhãn không còn là hop kế tiếp đối với nhóm chuyển tiếp tương đương được ánh xạ nữa. LSR nhận được một ánh xạ nhãn từ một LSR mà nó lịa không phải là hóp kế tiếp đối với nhóm chuyển tiếp tương đương này. LSR nhận được một bản tin Label Withdraw. Trong chế độ hoạt động gán nhãn theo yêu cầu từ phía trước, LSR sẽ yêu cầu gán nhãn từ LSR lân cận phía trước sử dụng bản tin Label Request. 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 với bản tin Label Request Abort. Bản tin Label Abort Request. 0 1 – 14 15 16 – 30 31 0 Label Release (0x0403) Message Length Message ID FEC TLV LSPID TLV (CR-LDP, mandatory) ER-TLV (CR-LDP, optional) Traffic TLV (CR-LDP, optional) Pinning TLV (CR-LDP, optional) Hình 4-25: Bản tin Abort Request Bản tin này bỏ qua các bản tin Label Request Có nhiều lý do như việc quảng bá mào đầu OSPF hay BGP sẽ thay đổi hoạt động yêu cầu nhãn. Trường LSPID TLV là số nhận dạng duy nhất của một CR-LSP. Nó là tập hợp của số nhận dạng LSR và một số nhận dạng một CR-LSP duy nhất đến LSR đó. Trường này được sử dụng trong việc quản lý mạng, trong việc sửa chữa CR-LSP. Trường ER TLV xác định đường được thiết lập bởi LSP. Nó chứa một hoặc nhiều explicit hop TLV. Trường Traffic TLV truyền các thông số của lưu lượng đến các nút CR-LSR khác. Trường Pinning TLV được sử dụng để phân doạn một đường LSP đã được định tuyến. LDP điều khiển độc lập và phân phối theo yêu cầu. Ví dụ dưới đây minh họa việc sử dụng bản tin Label Request và Label Mapping trong chế độ công bố nhãn theo yêu cầu và điều khiển LSP độ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ừ Router lối vào R1 qua R2 rồi đến Router R3 cho một FEC có Prefix”a.b/16”. R1 khởi tạo tiến trình bằng cách yêu một nhãn cho FEC”a.b/16” từ Hop kế của nó là 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ạ từ phía Downstream là R3. Cả R2 và R3 đáp ứng bằng bản tin Labe Mapping, kết quả là trong FIB của R1 và LFIB của R2, R3 có các entry gán kết nhãn hình thành nên đường chuyển mạch nhãn LSP. Hình 4-26: LDP điều khiển độc lập và phân phối 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 yêu cầu (Downstream Unsolicited), các Router 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à 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 ở Router lối ra, rồi sau đó lần lượt ngược về đến Router lối vào. Giao thức CR-LDP (Constrain-Base Routing LDP). CR-LDP là giao thức mở tộng từ LDP (RFE 3212) nhằm hỗ trợ đặc biệt cho định tuyến ràng buộc, kỹ thuật lưu lượng (TE) 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. 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 Tuyến tường minh ER (Explicit Router) Chặng tường minh ER-HOP (Explicit Router Hop). Các tham số lưu lượng. Sự lấn chiếm (Preemptions). Nhận diện LSP (LSPID). Ghim tuyến (Router Pinning). 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ứ năng cần thiết như: Báo hiệu đường đi (Path Signalling). Định nghĩa các tham số lưu lượng. 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, và nếu đường được yêu cầu thõa mãn các ràng buộc (ví dụ đủ 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-LSP. 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à lỗi sec được báo hiệu bằng bản tin Notification. Thiết lập một CR-LSP (Constrain-Base Routing LSP). Để thiết lập một LSP theo một con đường định trước, CR-LSP sử dụng đối tượng tuyến tường minh ER (Explicit Router). ER được chứa trong các bản tin Label. Hình 4-27: Thiết lập LSP với CR-LDP. Xét ví dụ trong hình 4-27. 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 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 sé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 đó. Khi 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 cũng tương tự như ở LSR B. 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 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ập 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 hồn tồ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 dự trữ, Tiến trình dự trữ tài nguyên. Hình 4-28: 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 là Admissicon 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ập 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 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 (Explicit Router Information Base). Rồi nó gọi là 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. Giao thức RSVP-TE (RSVP Traffic Engineering). RSVP có một số cơ chế cần thiết để thực hiện phân phối nhãn nhằm ràng buộc định tuyến. IETF đã chuẩn hóa phần 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ợ 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. Tổng kết cách dùng RSVP-TE để hỗ trợ tái định tuyến”Make-Before-Break”,theo dõi đường thật sự được chọn qua chức năng ghi tuyến cũng như hỗ trợ ưu tiên và lấn chiếm. Nguyên lý chức năng của RSVP là thiết lập các dự trữ cho 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 tùy chọn tuyến tường minh (Explicit Router). 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. 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 Router 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 sood LSP ID có hỗ trợ phương thức”Make-Before-Beark” khi 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 (Share 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 chon 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. Các bản Tear Down, Error và Hello của RSVP-TE. RSVP-TE định nghĩa hai 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 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 Degug. RFE 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 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. Thiết lập tuyến tường minh điều khiển tuần tự theo yêu cầu. Hình 4-29, 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 “a.b./16” cho một đường hầm LSP và 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ội đố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 theo ,R4 tiếp nhận yêu cầu này và gửi bản 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ó thể hỗ trợ cho yêu cầu và đó là Hop cuối cùng trên đường dẫn cho FEC”a.b/16”. R3 đáp ứ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 nhãn Implicit Null cho chặng kế t