Giao thức bỏo hiệu RSVP

Sau khi đó xem xột những thành phần chớnh trong cấu trỳc dịch vụ tớch hợp, trong phần này chỳng ta sẽ tập trung vào giao thức bỏo hiệu RSVP đú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 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 về chất lượng dịch vụ 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. Phiờn thường đạ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. Tuy nhiờn, trong phần tiếp theo, một phiờn khụng phải lỳc nào cũng được hiểu theo cỏch hạn chế như vậy.

Khi bộ nhận nhận được bản tin PATH, nú cú thể gửi bản tin RESV trở lại cho bộ gửi. Bản tin RESV 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ộ nhận yờu cầu. Nú cũng bao gồm một vài 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 3.8 biểu diễn trỡnh tự bản tin trao đổi giữa bộ gửi và nhận. Lưu ý rằng, ở đõy 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 năm trường trong phần mào đầu của IP và giao thức truyề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

78

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.9 - Cỏc bản tin PATH, RESV

MPLS hỗ trợ RSVP:

Trong phần này chỳng ta chỉ tập trung vào vai trũ của RSVP trong mạng MPLS về khớa cạnh hỗ trợ QoS, cũn vai trũ của nú trong điều khiển lưu lượng sẽ được đề cập trong phần điều khiển lưu lượng.

Mục tiờu đầu tiờn của việc bổ sung hỗ trợ RSVP vào MPLS là cho phộp cỏc LSR dựa vào việc phõn loại gúi tin theo nhón chứ khụng phải theo mào đầu IP nhận biết cỏc gúi tin thuộc cỏc luồng của cổng dành riờng. Núi cỏch khỏc, cần phải tạo và kết hợp phõn phối giữa cỏc luồng và cỏc nhón cho cỏc luồng cú cỏc cổng dành riờng RSVP. Chỳng ta cú thể xem một tập cỏc gúi tin tạo ra bởi cổng dành riờng RSVP như là một trường hợp riờng khỏc của FEC.

Thiết bị gửi Thiết bị nhận PATH RESV

79

Điều này trở nờn khỏ dễ dàng để kết hợp cỏc nhón với cỏc luồng dành riờng trong RSVP, ớt nhất là với unicast. Chỳng ta định nghĩa một đối tượng RSVP mới là đối tượng LABEL được mang trong bản tin RSVP RESV. Khi một LSR muốn gửi bản tin RESV cho một luồng RSVP mới, LSR cấp phỏt một nhón từ trong tập nhón rỗi, tại một lối vào trong LFIB của nú với nhón lối vào được đặt cho nhón cấp phỏt, và gửi đi bản tin RESV cú chứa nhón này trong đối tượng LABEL. Chỳ ý là cỏc bản tin RESV truyền từ bộ nhận tới bộ gửi là dưới dạng cấp phỏt nhón xuụi.

Khi nhận được bản tin RESV chứa đối tượng LABEL, một LSR thiết lập LFIB của nú với nhón này là nhón lối ra. Sau đú nú cấp phỏt một nhón để sử dụng như là nhón lối vào và chốn nú vào bản tin RESV trước khi gửi nú đi. Rừ ràng là, khi cỏc bản tin RESV truyền lờn LSR ngược thỡ LSP được thiết lập dọc theo tuyến đường. Cũng chỳ ý là, khi cỏc nhón được cung cấp trong cỏc bản tin RESV, mỗi LSR cú thể dễ dàng kết hợp cỏc tài nguyờn QoS phự hợp với LSP. Hỡnh 3.9 minh hoạ quỏ trỡnh trao đổi này. Trong trường hợp này chỳng ta giả sử cỏc mỏy chủ khụng tham dự vào việc phõn phối nhón. LSR R3 cấp phỏt nhón 5 cho cổng dành riờng này và thụng bỏo nú với R2. R2 cấp phỏt nhón 9 cũng cho cổng dành riờng này và thụng bỏo nú tới R1. Bõy giờ đó cú một LSP cho luồng dành riờng từ R1 tới R3. Khi cỏc gúi tin tương ứng với cổng dành riờng này (vớ dụ gúi tin gửi từ H1 tới H2 với số cổng nguồn, đớch thớch hợp và số giao thức giao vận thớch hợp) tới R1, R1 phõn biệt nú bằng cỏc thụng tin mào đầu IP và lớp truyền tải để tạo ra QoS thớch hợp cho cổng dành riờng vớ dụ như đặc điểm và hàng đợi cỏc gúi tin trong hàng đợi lối ra. Núi cỏch khỏc, nú thực hiện cỏc chức năng của một bộ định tuyến tớch hợp dịch vụ sử dụng RSVP. Hơn nữa, R1 đưa mào đầu nhón vào cỏc gúi tin và chốn giỏ trị nhón lối ra là 9 trước khi gửi chuyển tiếp gúi tin tới R2.

Khi R2 nhận gúi tin mang nhón 9, nú tỡm kiếm nhón đú trong LFIB và tỡm tất cả cỏc trạng thỏi liờn quan đến QoS để xem kiểm soỏt luồng, xếp hàng đợi gúi tin, v.v.. như thế nào. Khụng cần kiểm tra mào đầu lớp IP hay lớp truyền tải. Sau đú R2 thay thế nhón trờn gúi tin với một nhón lối ra từ LFIB của nú (mang giỏ trị 5) và gửi gúi tin đi.

Hỡnh 3.10 - Nhón phõn phối trong bảng tin RESV

Do việc tạo ra nhón kết hợp được điều khiển bởi cỏc bản tin RSVP vỡ vậy việc kết hợp được điều khiển như trong cỏc mụi trường khỏc của MPLS. Đõy cũng là một vớ dụ chứng tỏ việc mang thụng tin kết hợp nhón trờn một giao thức cú sẵn khụng cần một giao thức riờng như LDP.

H1 PATH RESV R1 R2 R3 H2 RESV Nhón =9 RESV Nhón =5

80

Một kết quả thỳ vị của việc thiết lập một LSP cho một luồng với cổng dành riờng RSVP là chỉ cú bộ định tuyến đầu tiờn trong LSP mà trong vớ dụ trờn là R1 liờn quan tới việc xem liệu cỏc gúi tin thuộc luồng dành riờng nào. Điều này cho phộp RSVP được ỏp dụng trong mụi trường MPLS theo cỏch mà nú khụng thể thực hiện được trong mạng IP truyền thống. Theo qui ước, cỏc cổng dành riờng RSVP cú thể tạo chỉ cho những luồng ứng dụng riờng lẻ, tức là những luồng được xỏc định nhờ năm trường mào đầu như mụ tả phớa trước. Tuy nhiờn, cú thể đặt cấu hỡnh R1 để lựa chọn cỏc gúi tin dựa trờn một số cỏc tiờu chuẩn. Vớ dụ, R1 cú thể lấy tất cả cỏc gúi tin cú cựng một tiền tố ứng với một đớch và đẩy chỳng vào LSP. Vỡ vậy thay vỡ cú một LSP cho mỗi luồng ứng dụng riờng, một LSP cú thể cung cấp QoS cho nhiều luồng lưu lượng. Một ứng dụng của khả năng này là cú thể cung cấp “đường ống” với băng thụng đảm bảo từ một Site của một cụng ty lớn đến một Site khỏc, thay vỡ phải sử dụng đường thuờ bao riờng giữa cỏc Site này. Khả năng này cũng hữu ớch cho mục đớch điều khiển lưu lượng, ở đõy một lưu lượng lớn cần được gửi dọc theo cỏc LSP với băng thụng đủ để tải lưu lượng.

Để hỗ trợ một vài cỏch sử dụng tăng cường của RSVP, MPLS định nghĩa một đối tượng RSVP mới cú thể mang trong bản tin PATH là: đối tượng LABEL_REQUEST. Đối tượng này thực hiện hai chức năng. Thứ nhất, nú được sử dụng để thụng bỏo cho một LSR tại phớa cuối của LSP gửi RESV trở về để thiết lập LSP. Điều này hữu ớch cho việc thiết lập cỏc LSP Site-to-Site. Thứ hai, khi LSP được thiết lập cho một tập cỏc gúi tin, khụng chỉ là một luồng ứng dụng riờng, đối tượng chứa một trường để xỏc định giao thức lớp cao hơn sẽ sử dụng LSP. Trường này được sử dụng giống như ethertype hoặc tương tự như mó đế phõn kờnh để xỏc định giao thức lớp cao hơn (IPv4, IPX, v.v..), vỡ vậy sẽ khụng cú trường phõn kờnh trong mào đầu MPLS nữa. Do vậy, một LSP cú thể cần được thiết lập cho mỗi giao thức lớp cao hơn nhưng ở đõy khụng giới hạn những giao thức nào được hỗ trợ. Đặc biệt, khụng yờu cầu cỏc gúi tin mang trong LSP được thiết lập sử dụng RSVP phải là cỏc gúi tin IP.

81

CHƯƠNG 4 ỨNG DỤNG MẠNG RIấNG ẢO VPN TRấN MẠNG MPLS

Trong chương này chỳng ta sẽ tỡm hiểu MPLS hỗ trợ mạng riờng ảo (VPN) như thế nào. Chỳng ta sẽ nghiờn cứu giải phỏp VPN dựa trờn MPLS – BGP/MPLS VPN. Như thể hiện trong tờn gọi, giải phỏp này là sự kết hợp của hai cụng nghệ đú là BGP và MPLS, tiếp theo, chỳng ta sẽ đề cập đến cỏc khớa cạnh bảo mật và chất lượng dịch vụ của giải phỏp.

Khụng giống như IPsec, cỏc chức năng phự hợp với vựng biờn ngoài mạng thỡ MPLS lại triển khai rất tốt trong vựng mạng lừi của cỏc nhà cung cấp dịch vụ. Đõy là nơi mà QoS, kĩ thuật quản lý lưu lượng (traffic engineering), và sử dụng băng thụng hoàn toàn cú thể được quản lý. Việc triển khai ứng dụng VPN dựa trờn MPLS tạo ra khả năng mở rộng, cơ chế quản lý chất lượng dịch vụ QoS mạnh và cỏc khả năng điều khiển lưu lượng cao, cho phộp cỏc nhà cung cấp mạng đưa ra cỏc dịch vụ giỏ trị gia tăng trờn nền IP với cỏc thoả thuận cam kết mức dịch vụ chất lượng cao (SLA-Service Level Agreement). Cú hai loại mụ hỡnh chớnh để triển khai VPN/MPLS đú là: mụ hỡnh ngang hàng và mụ hỡnh chồng lấn. [9]