MPLS không yêu cầu phải có giao thức phân bổ nhãn riêng, vì một vài giao thức định tuyến đang được sử dụng OSPF có thể hỗ trợ phân bổ nhãn. Tuy nhiên, IETF đã phát triển một giao thức mới để bổ sung cho MPLS. Được gọi là giao thức phân bổ nhãn LDP.Một giao thức khác, LDP cưỡng bức (CR-LDP), cho phép các nhà quản lý mạng thiết lập các đường đi chuyển mạch nhãn (LSP) một cách rõ ràng. CR-LDP là một sự mở rộng của LDP. Nó hoạt động độc lập với mọi giao thức cổng đường biên bên trong (IGP) khác. Nó được sử dụng cho các dòng lưu lượng nhạy cảm với trễ và mô phỏng mạng chuyển mạch kênh.RSVPcó thể được sử dụng để
phân phối nhãnbằng việc sử dụng các bản tin Reservation và PATH, nó hỗ trợ các hoạt động ràng buộc và phân bổ nhãn.
BGP cũng là một sự lựa chọn tốt cho giao thức phân bổ nhãn. Nếu cần phải ràng buộc nhãn với prefix địa chỉ, thì BGP có thể được sử dụng. Một bộ phản hồi (reflector) BGP có thể được sử dụng để phân bổ nhãn.
Giao thức phân phối nhãn LDP
Hình 2.10Vị trí giao thức LDP trong bộ giao thức MPLS
Giao thức phân phối nhãn được IETF đưa ra trong RFC 36. Vị trí của giao thức LDP và các mối liên kết chức năng cơ bản của LDP với các giao thức khác thể hiện trên hình 2.10
Giao thức phân bố nhãn là một thiết lập các thủ tục bởi một LSR cho biết một LSR khác nhãn sử dụng để chuyển hướng lưu lượng giữa và qua chúng.
LDP có thể hoạt động giữa các LSR kết nối trực tiếp hay không được kết nối trực tiếp. Các LSR sử dụng LDP để hoán đổi thông tin ràng buộc FEC và nhãn được gọi là các thực thể đồng cấp LDP, chúng hoán đổi thông tin này bằng việc xây dựng các phiên LDP.
Các loại bản tin LDP
Bản tin thăm dò (Discovery): dùng để thông báo và duy trì sự có mặt của 1 LSR trong mạng. Theo định kỳ, LSR gửi bản tin Hello qua cổng UDP với địa chỉ multicast của tất cả các router trên mạng con.
Bản tin phiên (Session): dùng để thiết lập, duy trì, và xoá các phiên giữa các LSR. Hoạt động này yêu cầu gửi các bản tin Initialization trên TCP. Sau khi hoạt động này hoàn thành các LSR trở thành các đối tượng ngang cấp LDP
Bản tin phát hành (Advertisement): dùng để tạo, thay đổi và xoá các ràng buộc nhãn với các FEC. Những bản tin này cũng mang trên TCP. Một LSR có thể yêu cầu 1 ánh xạ nhãn từ LSR lân cận bất cứ khi nào nó cần. Nó cũng phát hành các ánh xạ nhãn bất cứ khi nào nó muốn một đối tượng ngang cấp LDP nào đó sử dụng ràng buộc nhãn.
Bản tin thông báo (Notification): dùng để cung cấp các thông báo lỗi, thông tin chẩn đoán, và thông tin trạng thái. Những bản tin này cũng mangtrên TCP.
Thủ tục thăm dò LSR lân cận
Thủ tục LSR lân cận của LDP chạy trên UDP và thực hiện như sau (minh hoạ trên hình 2.11).
Một LSR định kỳ gửi bản tin Hello tới tất cả giao diện của nó. Những bản tin này được gửi trên UDP, với địa chỉ multicast của tất cả router trên
mạng con.
Tất cả các LSR tiếp nhận bản tin Hello này trên cổng UDP. Như vậy, tại 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 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 hai chiều có nghĩa là mỗi LSR ở hai đầu kết nối đều có thể yêu cầu và gửi ràng buộc nhãn.
Đa số các bản tin LDP chạy trên giao thức TCP để đảm bảo độ tin cậy của các bản tin. (ngoại trừ bản tin thăm dò).
Trong trường hợp các LSR không kết nối trực tiếp trong một mạng con, người ta sử dụng một cơ chế bổ sung như sau:
LSR định kỳ gửi bản tin Hello trên UDP đến địa điạ chỉ IP đã được khai báo khi lập cấu hình. Phía nhận bản tin này có thể trả lời lại bằng bản tin HELLO khác truyền ngược lại đến LSR gửi và việc thiết lập các phiên LDP được thực hiện nhưtrên.
Hình 2.11 Thủ tụcpháthiệnLSR lân cận
* Các bản tin DP
Tiêu đề bản tin LDP
Mỗi một bản tin LDP được gọi là đơn vị dữ liệu giao thức PDU, được bắt đầu bằng tiêu đề bản tin và sau đó là các bản tin LDP như đã trình bày trên đây. Hình2.12 chỉ ra các trường chức năng của tiêu đề LDP và các trường này thực hiện các
.
Hình 2.12 Tiêu đề LDP
* Phiên bản: Số phiên bản của giao thức, hiện tại là phiên bản 1.
* Độ dài PDU: Tổng độ dài của PDU tính theo octet, không tính trường phiên bản và trường độ dài. (adsbygoogle = window.adsbygoogle || []).push({});
* Nhận dạng LDP: Nhận dạng không gian nhãn của LSR gửi bản tin này. Bốn octet đầu tiên chứa địa chỉ IP được gán cho LSR: nhận dạng bộ định tuyến. Hai octet cuối nhận dạng không gian nhãn bên trong LSR.Với LSR có không gian nhãn lớn, trường này có giá trị bằng 0.
Khuôn dạng bản tin LDP
Tất cả các bản tin LDP có khuôn dạng sau:
Hình 2.13 Khuôn dạng các bản tin LDP
thông dịch bởi phía nhận, lúc đó bản tin bị bỏ qua mà không có phản hồi.
* Kiểu bản tin: Chỉ ra kiểu bản tin là gì.
* Chiều dài bản tin: Chỉ ra chiều dài của các phần nhận dạng bản tin, các thông số bắt buộc, và các thông số tuỳ chọn.
* Nhận dạng bản tin: là một số nhận dạng duy nhất bản tin. Trường này có thể được sử dụng để kết hợp các bản tin Thông báo với một bản tin khác.
* Thông số bắt buộcvàThông số tuỳ chọn tuỳ thuộc vàobản tinLDP.
2.2.4Giao thức dự trữ tài nguyên RSVP
- RSVP là giao thức báo hiệu đóng vai trò quan trọng trong mạng MPLS, được sử dụng để dành trước tài nguyên cho một phiên truyền trong mạng Internet.
- RSVP được thiết kế để thiết lập các đường truyền cũng như bảo vệ giải thông trên các đường truyền trong khi các giao thức IP là giao thức không kết nối nó không hỗ trợ việc thiết lập các đường cho luồng lưu lượng
- RSVP yêu cầu các máy nhận lưu lượng về yêu cầu chất lượng dịch vụ QoS cho luồng dữ liệu. Các ứng dụng tại máy nhận phải giải quyết các thuộc tính QoS sẽ được truyền tới RSVP. Sau khi phân tích các yêu cầu này, RSVP được sử dụng để gửi các bản tin tới tất cả các nút nằm trên tuyến đường của gói tin.
RSVP mang các thông tin sau:
Thông tin phân loại nhờ nó mà các luông lưu lượng với các yêu cầu QoS cụ thể có thể được nhận biết trong mạng. Thông tin này bao gồm địa chỉ IP phía gửi và phía nhận, số cổng UDP.
Chỉ tiêu kỹ thuật của luồng lưu lượng và các yêu cầu QoS, theo khuôn dạng TRpec và Rspec bao gồm các dịch vụ yêu cầu (có bảo đảm hoặc tải điều khiển)
RSVP sử dụng bản tin trao đổi tài nguyên dành trước qua mạng cho luồng IP. RSVP là giao thức riêng ở mức IP. Nó sử dụng các gói dữ liệu IP hoặc UDP ở phần biên của mạng để thông tin giữa các LSR đồng cấp.Nó không đòi hỏi duy trì phiên TCP, nhưng sau phiên này nó phải xử lý những mất mát của các bản tin điều
Ingress
LSR Egress LSR
R1 R4 R8 R9
Route RSVP = {R1, R4, R8, R9}
Hình 2.14: Ví dụ về giao thức dành sãn tài nguyên
- RSVP sẽ thiết lập một giao thức dành sãn tài nguyên đi theo đường xác định theo tuyến từ R1 đến R9 đã được lựa chọn theo IGP. Và sau đó phân phối nhãn ngược trở lại để thiết lập đường truyền vận chuyển lưu lượng.
Các bản tin RSVP được các router hoặc các switch trên liên kết giữa hai đầu cuối gửi và nhận trao đổi với nhau để đáp ứng yêu cầu về mức chất lượng dịch vụ của ứng dụng.RSVP mang thông tin trong đó có hai loại cơ bản là PATH và RESV để xác định luồng và các QoS cho luồng. Các yêu cầu này chỉ ra dịch vụ được bảo vệ, ví dụ tốc độ đính cho luồng dữ liệu, kích thước cụm.Một bản tin PATH bao giờ cũng được gửi tới một địa chỉ gọi là địa chỉ phiên, nó có thể là địa chỉ đơn hướng hoặc đa hướng. Chúng ta thường xem phiên đại diện cho một ứng dụng đơn, nó được xác nhận bằng một địa chỉ đích và số cổng đích sử dụng riêng cho ứng dụng.
Khi bộ thu nhận bản tin PATH nó có thể gửi bản tin RESV trở lại cho bộ phát,
bản tin RESV dùng để xác nhận phiên có chứa thông tin về số cổng dành riêng và Rspec xác nhận mức QoS mà bộ thu yêu cầu. Nó cũng bao gồm một số thông tin xem xét những bộ phát nào được phép sử dụng tài nguyên đang được cấp phát.
Khi cổng dành riêng được thiết lập, các bộ định tuyến nằm giữa bộ phát và bộ thu sẽ xác định các gói tin thuộc cổng dành riêng nào nhờ kiểm tra năm trường trong mào đầu IP và giao thức truyền tải đó là: địa chỉ nguồn, số cổng nguồn, số giao thức (UDP,TCP….), địa chỉ đích, số cổng đích. Tập hợp các gói tin được nhận dạng theo cách này được gọi là luồng dành riêng. Các thông tin trong luồng dành riêng được khống chế để đảm bảo không phát sinh lưu lượng vượt quá so với thông
báo trong Tspec và được xếp vào hàng đợi phù hợp theo yêu cầu QoS. Thiết lập đường sử dụng RSVP
RSVP đóng vai trò quan trọng trong việc thiết lập đường LSP và hỗ trợ các ứng dụng unicast hoặc multicast. RSVP thích ứng với các thay đổi trong nhóm multicast hoặc trong bảng định tuyến. Việc duy trì được thực hiện thông qua việc gửi các bản tin làm tươi định kì gửi theo LSP để duy trì trạng thái. Trong kỹ thuật lưu lượng, các phiên RSVP xảy ra giữa các router ở các điểm đầu cuối trung kế. Các bản tin được sử dụng trong quá trình thiết lập đường bao gồm: PATH, RESV, PATH_TEAR, PATH_ERR, RESV_ERR.
2.2.4.1 Bản tin Path yêu cầu thiết lập đường RSVP (adsbygoogle = window.adsbygoogle || []).push({});
Hình 2.15: Bản tin PATH
Quá trình thiết lập đường được khởi xướng bởi router đầu dòng với bản tin PATH mang các thông tin như sau:
1. Đối tượng yêu cầu nhãn Label_Request
Đối tượng này được sử dụng để yêu cầu các router trung gian thực hiện hoán đổi nhãn cho phiên.Nó cũng xác định giao thức lớp mạng trên đường đó. Lí do là giao thức lớp mạng được gửi qua LSP không nhất thiết phải là IP và giao thức này cũng không thể được suy luận từ mào đầu lớp 2 vốn chỉ nhận biết giao thức lớp cao hơn như MPLS. Đối tượng này có thể có 3 Class_Types:
* Loại 1 : yêu cầu nhãn thông thường, là nhãn MPLS 32 bit nằm giữa mào đầu lớp liên kết và lớp mạng.
hỗ trợ bởi switch đầu tiên. Loại này được sử dụng khi nhãn MPLS được mang trong mào đầu ATM.
*Loại 3: loại này đặc tả số lượng tối thiểu các giá trị DLCI được hỗ trợ trên switch đầu tiên. Loại này được sử dụng khi nhãn MPLS được mang trong mào đầu Frame Relay.
Khi bản tin PATH đến một LSR, đối tượng Label_Request được lưu giữ trong khối trạng thái đường để sử dụng cho các bản tin làm tươi trong tương lai. Khi bản tin PATH đến đầu nhận, đối tượng này yêu cầu đầu nhận cấp phát nhãn và đặt nhãn đó trong đối tượng Label của bản tin RESV. Nếu nút không thể thực hiện hoán chuyển nhãn nó sẽ gửi lại bản tin PATH_ERR với lỗi “unknown object class”.Nếu đối tượng Label_request không được hỗ trợ end to end, nút gửi sẽ được thông báo bởi nút đầu tiên không cung cấp hỗ trợ này.
2. Đối tượng định tuyến hiện ExplicitRouting
Đối tượng này được sử dụng để đặc tả một đường rõ ràng đi qua mạng độc lập với đường đặc tả bởi IGP. Nội dung của ERO là 1 chuỗi mục dữ liệu có chiều dài thay đổi gọi là các đối tượng phụ (subobjects).
Một đối tượng phụ là 1 nút trừu tượng, có thể là 1 nút hoặc 1 tập hợp nút như 1 miền tự trị. Điều này có nghĩa là đường tường minh có thể đi qua nhiều miền tự trị.
Đối tượng phụ này chứa 1 bit L (Loose Route). Nếu bit này được thiết lập bằng 1, nó sẽ xác định đối tượng phụ này là 1 hop lỏng (loose hop) trên đường tường minh. Nếu bit này được thiết lập bằng 0, nó sẽ xác định rằng đối tượng phụ này là 1 hop chặt (strict hop). Một hop chặt xác định hop này kế cận về mặt vật lí với nút trước đó trên đường.
Đối tượng phụ này cũng chứa 1 trường Type bao gồm các giá trị sau:
* 1: tiền tố IPv4, xác định 1 nút trừu tượng với 1 tập hợp tiền tố IP nằm trong tiền tố Ipv4 này.Mỗi tiền tố có độ dài 32 bit là 1 nút đơn.
* 2: tiền tố Ipv6, xác định 1 nút trừu tượng với 1 tập hợp tiền tố IP nằm trong tiền tố Ipv6 này.Mỗi tiền tố có độ dài 128 bit là 1 nút đơn
* 32 :số miền tự trị, xác định 1 nút trừu tượng bao gồm 1 tập hợp các nút thuộc về miền tự trị.
Ví dụ về strict hop:
Trong hình LSR ngõ vào A gửi bản tin PATH đến LSR D với ERO xác định 1 hop chặt qua B(192.213.1.1), C(192.213.2.1) và D(192.213.3.1). Khi B nhận bản tin PATH, nó sẽ quảng bá bản tin này đến C, và C quảng bá bản tin này đến D. Ở chiều ngược lại, D gửi bản tin RESV đến A qua cùng con đường. Mỗi nút trong danh sách ERO sẽ loại bỏ thông tin của nó khỏi bản tin PATH trước khi chuyển tiếp nó đi.
Hình 2.16: Ví dụ về hop chặt Ví dụ về loose hop:
Trong hình LSR ngõ vào A gửi bản tin PATH đến LSR D với ERO xác định hop chặt đến B. Từ router B hop lỏng được sử dụng. Khi B nhận bản tin PATH nó có thể chuyển tiếp bản tin PATH đến D qua bất kì con đường nào sẵn có. Trong hình ta thấy có 2 con đường đến D, một qua kết nối trực tiếp đến C và 1 đường khác qua router E. Việc họn đường nào phụ thuộc vào tuyến IGP đến D đang sẵn sàng.
Hình 2.17: Ví dụ về hop lỏng
Các LSR trung gian giữa đầu gửi và đầu nhận có thể thay đổi bằng cách chèn các đối tượng phụ. Ví dụ như khi LSR thay đổi 1 tuyến lỏng bằng 1 tuyến chặt buộc lưu lượng đi theo 1 đường cụ thể. Sự hiện diện của các nút lỏng trong tuyến tường minh có thể dẫn đến lặp vòng.Vấn đề này có thể được xác định bởi đối tượng Record_Route (RRO).
3.Đối tượng định tuyến mảnh tin Record_Route (RRO)
RRO được sử dụng để thu thập thông tin tuyến chi tiết, xác định lặp vòng hoặc chẩn đoán. Bằng cách thêm RRO vào bản tin PATH, đầu gửi có thể nhận được thông tin về đường thực sự mà LSP đi trên đó. Con đường cuối cùng được ghi nhận bởi RRO có thể khác với ERO được đặc tả bởi đầu gửi. RRO có thể hiện diện trong cả bản tin PATH và ESV.RRO hiện diện trong bản tin RESV nếu RRO được ghi nhận trong bản tin PATH cần phải được gửi trở về LSR ngõ vào.
RRO ban đầu chỉ chứa địa chỉ IP của đầu gửi. Khi các router trung gian nhận bản tin PATH chứa RRO, chúng sẽ lưu trữ 1 bản sao của RRO này trong khối trạng thái đường đồng thời thêm địa chỉ IP của nó vào RRO và chuyển tiếp bản tin PATH đến router tiếp theo. Khi đầu nhận gửi RRO lại cho đầu gửi qua bản tin RESV, RRO mang thông tin tuyến LSP trọn vẹn từ ngõ vào đến ngõ ra.
4. Đối tượng Session_Attribute
Đối tượng này cho phép RSVP TE thiết lập các độ ưu tiên, lấn chiếm và các đặc điểm định tuyến nhanh khác nhau.Chúng được sử dụng để chọn các LSP khác khi xảy ra lỗi trong mạng.Đối tượng này bao gồm các trường như độ ưu tiên thiết
lập, độ ưu tiên cầm giữ. Các trường này ảnh hưởng đến việc 1 phiên này có thể lấn chiếm hoặc bị lấn chiếm bởi các phiên khác. Trường cờ (flag) được sử dụng với các lựa chọn như các router chuyển tiếp có thể sử dụng các cơ chế cục bộ để can thiệp vào ERO và thực hiện sửa chữa cục bộ. Các cờ khác chỉ ra rằng nút ngõ vào có thể lựa chọn để tái định tuyến mà không cần loại bỏ đường hầm.
Các router trung gian trên đường thực hiện điều khiển chấp nhận (admission control) bằng cách xem xét nội dung trong đối tượng Session_Attribute. Nếu nút không thể đáp ứng được yêu cầu nó sẽ gửi lại bản tin PATH_ERR, nếu có thể đáp ứng thì thông tin nút đó sẽ được lưu trong Record_Route.
(adsbygoogle = window.adsbygoogle || []).push({});