Xem mẫu
- Chương 9 : Giao thức RSVP với việc
phân bổ nhãn
Như tên gọi của nó, giao thức dành trước tài nguyên (RSVP)
dùng để dành trước các tài nguyên cho một phiên làm việc (dòng
lưu lượng) trong mạng Internet. Khía cạnh này của Internet là khác
so với dự định thiết kế hệ thống nằm bên dưới ban đầu là chỉ dùng
để hỗ trợ các dịch vụ nỗ lực tối đa mà không xem xét đến các yêu
cầu được xác định trước về chất lượng dịch vụ hay đặc tính lưu
lương của người sử dụng.
RSVP được dự tính để đảm bảo hiệu năng bằng việc dành
trước các tài nguyên cần thiết tại mỗi node tham gia trong việc hỗ
trợ dòng lưu lượng (chẳng hạn như hội nghị video hay audio). Cần
nhớ rằng IP là giao thức không hướng kết nối, nó không thiết lập
trước đường đi cho các dòng lưu lượng, trong khi đó RSVP thiết
lập trước những đường đi này và đảm bảo cung cấp đủ băng tần
cho đường đi đó.
RSVP không cung cấp các hoạt động định tuyến mà sử dụng
IPv4 hay IPv6 như là cơ chế truyền tải giống như cách mà giao
thức bản tin điều khiển Internet (ICMP) và giao thức bản tin nhóm
Internet (IGMP) hoạt động.
RSVP yêu cầu phía thu đưa ra tham số QoS cho dòng lưu
lượng. Các ứng dụng phía thu phải xác định bản ghi QoS và
chuyển tới RSVP. Sau khi phân tích các yêu cầu này, RSVP gửi
các yêu cầu tới tất cả các node tham gia trong việc vận chuyển
dòng lưu lượng.
- Các khía cạnh của RSVP liên quan tới MPLS
Trong phần này chúng ta sẽ tóm tắt ngắn gọn các đặc trưng
RSVP, những đặc trưng này có liên quan đến việc sử dụng RSVP
với MPLS.
RSVP là một giao thức báo hiệu được sử dụng để thiết lập
các yêu cầu dành trước tài nguyên nhằm đảm bảo QoS trong
Internet. Như biểu diễn trong hình 2.25, chất lượng dịch vụ của
một dòng lưu lượng nào đó được thực hiện bằng các kỹ thuật gọi là
điều khiển lưu lượng. Những kỹ thuật này bao gồm (1) Một bộ
phân loại gói (2) Điều khiển chấp nhận kết nối (3) Một bộ lập lịch
gói và (4) Điều khiển chính sách.
Hình 2.25. Các thực thể hoạt động RSVP
Bộ phân loại xác định các lớp QoS (và có thể là các đường
đi) cho mỗi gói, dựa trên sự kiểm tra tiêu đề lớp vận chuyển và lớp
IP. Với mỗi giao diện đầu ra, bộ lập lịch gói hay một cơ chế phụ
thuộc lớp liên kết dữ liệu nào khác sẽ đạt được giá trị QoS như đã
cam kết. Bộ lập lịch gói thực hiện các mô hình dịch vụ QoS đã
được định nghĩa bởi nhóm làm việc các dịch vụ được tích hợp
(IntServ).
- Trong suốt quá trình thiết lập việc dành trước tài nguyên, một
yêu cầu QoS RSVP được chuyển tới hai modul quyết định tại chỗ
là: điều khiển chấp nhận và điều khiển chính sách. Điều khiển
chấp nhận xác định xem node có đủ tài nguyên để cung cấp cho
dòng lưu lượng với mức QoS được yêu cầu hay không. Điều khiển
chính sách xác định xem một dòng lưu lượng nào đó có được cho
phép theo các quy tắc quản lý hay không, chẳng hạn như các địa
chỉ IP nào đó được hay không được cho phép dành trước băng tần;
nhận dạng (ID) giao thức nào đó là được hay không được cho phép
dành trước băng tần…
Các phiên. RSVP xác định phiên là một dòng lưu lượng với
một địa chỉ đích IP và giao thức lớp vận chuyển nào đó. Một phiên
RSVP được xác định bởi địa chỉ đích IP (DestAddress), nhận dạng
giao thức IP (ProtocolId), và nhận dạng cổng đích (DestPort). Địa
chỉ đích IP của gói dữ liệu có thể là địa chỉ đơn hướng hay đa
hướng. ProtocolId là nhận dạng giao thức IP. Tham số chức năng
DestPort là một “cổng đích đã được tổng quát hóa”. DestPort có
thể được xác định bởi trường cổng đích UDP/TCP, hay bởi một
trường tương đương trong giao thức vận chuyển khác.
Các bản tin chính của giao thức RSVP. RSVP yêu cẩu phia
thu đưa ra các tham số QoS cho dòng lưu lượng. Các ứng dụng tiếp
nhận dòng lưu lượng đến phải xác định bản ghi QoS (chứa các
tham số QoS) rồi chuyển tới RSVP. Sau khi phân tích yêu cầu này,
RSVP gửi các bản tin yêu cầu tới tất cả các node tham gia vào việc
vận chuyển dòng lưu lượng. Như được biểu diện trong hình 2.26,
các hoạt động được bắt đầu bằng bản tin Path RSVP. Nó được sử
- dụng bởi phía gửi để thiết lập một đường đi cho phiên (dòng lưu
lượng).
Hình 2.26. Các bản tin Path và Reservation
Hình 2.26 cũng chỉ ra rằng các bản tin Reservation được gửi
bởi phía nhận và chúng cho phép phía gửi cũng như các node trung
gian biết các yêu cầu của phía nhận. Đường đi của bản tin
Reservation là giống với đường đi của bản tin Path, nhưng ở
phương ngược lại.
Điều khiển chấp nhận và Điều khiển chính sách. Nhìn vào
hình 2.25 chúng ta thấy được quá trình RSVP chuyển các yêu cầu
tới điều khiển chấp nhận và điều khiển chính sách. Nếu sự kiểm tra
xảy ra một trong hai điều khiển đó không thành công, sự dành trước
tài nguyên sẽ bị huỷ bỏ và quá trình RSVP trả lại bản tin thông báo
lỗi tới phía nhận tương ứng. Nếu cả hai sự kiểm tra trong hai điều
khiển này thành công thì node sẽ cho phép bộ phân loại gói lựa chọn
các gói dữ liệu – như được xác định bởi filterspec và tương tác với
lớp liên kết dữ liệu tương ứng để đạt được QoS mong đợi – như
được xác định bởi flowspec. Trong phần tới chúng ta sẽ tìm hiểu về
filterspec và flowspec.
Bộ mô tả dòng lưu lượng.
Một bản tin dành trước tài nguyên RSVP đơn giản chứa một
flowspec và một filterspec; hai thành phần này kết hợp với nhau
- được gọi là một bộ mô tả dòng lưu lượng. Xem hình 2.27.
Flowspec xác định tham số QoS được yêu cầu. Filterspec, cùng
với các tham số đặc tả dòng lưu lượng khác, xác định nên một tập
các gói dữ liệu - dòng lưu lượng để nhận được mức QoS như đã
được xác định trong flowspec.
Hình 2.27. Bộ mô tả lưu lượng
Flowspec thiết lập các tham số ở trong bộ lập lịch gói hay ở
trong các cơ chế lớp liên kết dữ liệu khác và filterspec thiết lập các
tham số ở trong bộ phân loại gói. Các gói dữ liệu được đánh địa
chỉ cho một dòng lưu lượng nào đó nhưng không phù hợp với mọi
filterspec cho dòng lưu lượng (phiên) đó được xử lý như là dòng
lưu lượng của dịch vụ “nỗ lực tối đa”.
Flowspec trong bản tin yêu cầu dành trước tài nguyên thường
bao gồm một lớp dịch vụ và hai tập các tham số có tính chất con
số: (1) Rspec (R-Reserve) dùng để xác định mức QoS mong muốn
và (2) Tspec (T-Traffic) dùng để mô tả dòng lưu lượng. Khuôn
- dạng và nội dung của các Tspec và Rspec được xác định bởi các
mô hình dịch vụ được tích hợp (xem RFC 2210).
Các trường bên trong các bản tin RSVP được gọi là các đối
tượng. Từ khi RSVP ra đời, nhiều đối tượng đã liên tục được bổ
sung. Chúng ta sẽ đề cập đến những đối tượng trong các bản tin
RSVP liên quan đến MPLS trong phần tiếp theo.
Sự liên quan giữa các khái niệm trong MPLS và RSVP
Sự mở rộng của RSVP dùng để hỗ trợ MPLS trong việc thiết
lập các LSP bằng cách sử dụng hay không sử dụng việc đặt trước
tài nguyên. Những mở rộng này cũng dùng để tái định tuyến LSP,
cân bằng tải, định tuyến cưỡng bức và phát hiện lặp vòng. Những
mở rộng này của RSVP phản ánh nhiều hoạt động trong LDP như
đã nói ở trên.
Các host và các router hỗ trợ cả RSVP và MPLS có thể kết
hợp các nhãn và các dòng lưu lượng RSVP. Mỗi lần một LSP được
thiết lập, lưu lượng đi qua đường dẫn này được xác định bởi giá trị
nhãn đã được gắn vào gói tại lối vào của LSP. Tập các gói được ấn
định cùng giá trị nhãn thuộc về cùng một FEC và cũng giống như
tập các giá trị nhãn ấn định cho dòng lưu lượng cho RSVP. Khi các
nhãn được kết hợp với các dòng lưu lượng, thì router có thể nhận
ra các trạng thái dành trước RSVP tương ứng cho mỗi gói, dựa trên
giá trị nhãn của gói.
Mô hình RSVP/MPLS sử dụng phân bổ nhãn theo yêu cầu
đường xuống. Trong hình 2.26, chúng ta thấy rằng các node đường
lên yêu cầu một ràng buộc nhãn (A tới B, B tới C…). Một yêu cầu
để ràng buộc nhãn với một đường hầm LSP được khởi tạo bởi
- node lối vào (node A trong hình 2.26), thông qua bản tin Path
RSVP, bản tin này chứa một đối tượng LABEL_REQUEST. Đối
tượng này chứa các giá trị nhãn được gợi ý, có thể bao gồm các số
kênh ảo ATM và FR (nếu cần).
Các nhãn được chỉ định từ các router đường xuống và được
phân bổ ngược trở lại đường lên bởi các bản tin Reservation. Để
thực hiện mục đích này, bản tin Reservation RSVP được mỏ rộng
với một đối tượng LABEL. Đối tượng này chứa nhãn được sử
dụng giữa các node lân cận. Chẳng hạn, trong hình 2.26, bản tin
Path giữa các node B và C chứa đối tượng LABEL_REQUEST và
bản tin Reservation chứa đối tượng LABEL.
Đối tượng LABEL được chèn vào bên trong danh sách
filterspec ngay sau filterspec mà nó liên quan. Sự tiếp nhận nhãn
cho phép node cập nhật ILM (Ánh xạ nhãn lối vào) của nó.
Định tuyến hiện. Sự mở rộng của RSVP cũng hỗ trợ định
tuyến hiện, thường được biết như là định tuyến cưỡng bức trong
các miền MPLS. Hoạt động này được thực hiện bằng việc đặt đối
tượng EXPLICIT_ROUTE vào trong bản tin Path. Trong hình 2.28
các node D, J, E và F được thiết lập cho LSP.
- Hình 2.28 Đối tượng SESSION và EXPLICIT_ROUTE
Đối tượng EXPLICIT_ROUTE chứa các chặng cho các LSP
được định tuyền hiện. Các đường đi được định tuyến hiện có thể
được cấu hình bởi nhà quản trị hay được tính toán tự động bằng
một thực thể phù hợp dựa trên các yêu cầu QoS và chính sách, có
tính cả trạng thái mạng hiện thời, nhưng RSVP không xác định
đường đi định tuyến hiện được quyết định như thế nào. Tuy nhiên,
các chặng của đường đi định tuyến hiện được nhận ra bởi (a) tiền
tố địa chỉ IPv4, (b) tiền tố địa chỉ IPv6 hay (c) số của hệ thống tự
quản. Ngoài ra, định tuyến hiện cho phép sử dụng định tuyến chặt
hay lỏng. Chức năng của nó là tương tự như các chức năng của
định tuyển nguồn IP (việc này hiếm khi được sử dụng). Định tuyến
lỏng là một tập các chặng được gợi ý và định tuyến chặt là một tập
các chặng được yêu cầu.
- Xác định các node lối vào và các node lối ra. Đối tượng
SESSION, như được biểu diễn trong hình 2.28 là một trường hữu
ích với các nhà quản lý mạng muốn điều khiển các node lối vào và
các node lối ra của LSP mà không cần phải điều khiển mỗi node từ
lối vào đến lối ra. Để thực hiện chức năng này đối tượng SESSION
phải chứa địa chi IP của node lối ra.
Các mức độ ưu tiên của phiên. Một trường khác được định
nghĩa trong RSVP mở rông là SESSION_ATTRIBUTE. Nó được
sử dụng bởi các node RSVP/MPLS để nhận ra độ ưu tiên của dòng
lưu lượng (LSP trong MPLS) tương ứng với quyền được sử dụng
tài nguyên tại các node đó. Ngoài ra nó cũng được sử dụng để
quyết định xem một phiên (dòng lưu lượng) nào đó có thể được ưu
tiên hơn phiên khác hay không.
Ngoài những mở rộng này, RSVP cón được mở rộng trong
khía cạnh kỹ thuật lưu lượng, định tuyến lại….Những chi tiết này
xin phép không trình bày trong phạm vi đồ án này.
nguon tai.lieu . vn
