b) Các phần tử định tuyến c-ỡng bức
3.2.4.3. Giao thức RSVP
Sau khi đó đó phõn tớch những nội dung chớnh trong giao thức LDP và CR-LDP, trong phần này chỳng ta sẽ tập trung vào giao thức bỏo hiệu RSVP là giao thức bỏo hiệu đúng vai trũ rất quan trọng trong MPLS. RSVP là giao thức cho phộp cỏc ứng dụng thụng bỏo cỏc yờu cầu về QoS với mạng và mạng sẽ đỏp ứng bằng những thụng bỏo thành cụng hoặc thất bại. RSVP phải 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 UPD.
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 TSpec 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)
Rừ ràng là RSVP phải mang những thụng tin này từ cỏc mỏy chủ tới tất cả cỏc tổng đài chuyển mạch và cỏc bộ định tuyến dọc theo đường truyền từ bộ gửi đến bộ nhận, vỡ vậy tất cả cỏc thành phần mạng này phải tham gia vào việc đảm bảo cỏc yờu cầu QoS của ứng dụng.
RSVP mang cỏc thụng tin trong hai loại bản tin cơ bản là: PATH và RESV. Cỏc bản tin PATH truyền từ bộ gửi tới một hoặc nhiều bộ nhận cú chứa TSpec và cỏc thụng tin phõn loại do bộ gửi cung cấp. Một lý do cho phộp cú nhiều bộ nhận là RSVP được thiết kế để hỗ trợ multicast. Một bản tin PATH bao giờ cũng được gửi tới một địa chỉ được gọi là địa chỉ phiờn, nú cú thể là
địa chỉ unicast hoặc multicast. 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. Trong phần tiếp theo chỳng ta sẽ thấy rằng khụng cú lý do nào để xem xột một phiờn theo cỏch hạn chế như vậy.
riờng và RSpec xỏc nhận mức QoS mà bộ nhận yờu cầu. Nú cũng bao gồm một số thụng tin xem xột những bộ gửi nào được phộp sử dụng tài nguyờn đang được cấp phỏt. Hỡnh II-16 biểu diễn trỡnh tự bản tin trao đổi giữa bộ gửi và nhận. Ở đõy chỳng ta lưu ý rằng cỏc cổng dành riờng là đơn cụng. Nếu cần sử dụng cỏc cổng dành riờng song cụng (vớ dụ như phục vụ cho thoại truyền thống) thỡ phải cú cỏc bản tin bổ sung theo chiều ngược lại. Cũng chỳ ý rằng cỏc bản tin được nhận và chuyển tiếp bởi tất cả cỏc bộ định tuyến dọc theo đường truyền thụng tin, do đú việc cấp phỏt tài nguyờn cú thể được thực hiện tại tất cả cỏc nỳt mạng cần thiết.
Khi cỏc cổng dành riờng được thiết lập, cỏc bộ định tuyến nằm giữa bộ gửi và bộ nhận sẽ xỏc định cỏc gúi tin thuộc cổng dành riờng nào nhờ việc kiểm tra 5 trường trong phần mào đầu của IP và giao thức chuyển tải đú là: địa chỉ đớch, số cổng đớch, số giao thức (vớ dụ UDP), địa chỉ nguồn và cổng nguồn. Chỳng ta gọi tập cỏc gúi tin được nhận dạng theo cỏch này gọi là luồng dành riờng. Cỏc gúi tin trong luồng dành riờng thường bị khống chế (đảm bảo cho
luồng khụng phỏt sinh lưu lượng vượt quỏ so với thụng bỏo trong TSpec) và xếp vào hàng đợi để phự hợp với yờu cầu về QoS. Vớ dụ một cỏch để cú dịch vụ bảo đảm là sử dụng cỏc hàng đợi cú trọng số (WFQ), ở đõy mỗi cổng dành riờng khỏc nhau được xem như một luồng đối với cỏc hàng đợi, và trọng số được ấn định cho mỗi luồng phự hợp với tốc độ dịch vụ yờu cầu trong RSpec của nú.
Đối với cỏc luồng unicast thỡ RSVP là khỏ đơn giản. Nú trở nờn phức tạp hơn trong mụi trường multicast, bởi vỡ cú thể cú rất nhiều bộ nhận dành riờng cổng cho một phiờn đơn và cỏc bộ nhận khỏc nhau cú thể yờu cầu cỏc mức QoS khỏc nhau. Hiện nay MPLS chủ yếu tập trung vào cỏc ứng dụng unicast của RSVP, chỳng ta sẽ khụng đi sõu vào khớa cạnh multicast của RSVP.
Điểm cuối cựng phải chỳ ý về RSVP là nú là giao thức “trạng thỏi mềm”. Đặc tớnh để phõn biệt giao thức trạng thỏi mềm với cỏc giao thức loại khỏc là trạng thỏi sẽ tự động hết hiệu lực sau một thời gian trừ khi nú được làm tươi
liờn tục theo chu kỳ. Điều đú cú nghĩa là RSVP sẽ định kỳ gửi đi cỏc bản tin PATH và RESV để làm tươi cỏc cổng dành riờng. Nếu chỳng khụng được gửi trong một khoảng thời gian xỏc định thỡ cỏc cổng dành riờng tự động bị huỷ bỏ.
Hỡnh 3-11. Gửi và nhận cỏc bản tin PATH và RESV