ATM-LSR C gửi một bản tin chuyển đổi nhãn luồng hướng đi để đáp lại bản tin yêu cầu nhãn và bản tin này sẽ được truyền ngược trở lại trên LSP cho đến khi nó tới ATM-LSR là cổng vào của FEC (ở đây là ATM-LSR A). Khi quá trình này kết thúc, LSP đã sẵn sàng để truyền dữ liệu. Phương pháp này hoạt động rất có hiệu quả trừ khi các bản tin yêu cầu nhãn hoặc chuyển đổi nhãn được chuyển tiếp giữa các ATM-LSR dựa trên các thông tin định tuyến không chính xác. Tình trạng này xảy ra giống với trường hợp sử dụng TTL được trình bày trước đây và tạo nên một chuyển tiếp vòng các thông tin điều khiển. Tất nhiên hiện tượng này phải được ngăn ngừa bằng cách sử dụng cơ chế bổ sung.
Lưu ý: Hiện tượng chuyển tiếp vòng thông tin điều khiển chỉ xảy ra khi sử dụng các ATM-LSR không có khả năng hợp nhất. Đó là vì một ATM-LSR sẽ trở thành ATM-LSR hợp nhất khi phải hợp nhất ít nhất hai ATM-LSR trong một FEC và nó được đặt cấu hình là hỗ trợ VC hợp nhất.
Cơ chế bổ sung hoạt động dựa trên việc sử dụng bộ đếm nút mạng TLV, trong đó có chứa số lượng các ATM-LSR mà các bản tin yêu cầu nhãn và chuyển đổi nhãn đi qua. Khi một ATM-LSR nhận được một bản tin yêu cầu nhãn và nếu như nó không phải là ATM-LSR cổng ra của FEC hoặc nó không có nhãn của FEC thì ATM-LSR đó sẽ khởi tạo một bản tin yêu cầu nhãn và gửi nó tới nút ATM-LSR tiếp theo. Nút ATM-LSR tiếp theo này được xác định dựa vào bảng định tuyến.
Nếu như bản tin yêu cầu nhãn khởi đầu có chứa bộ đếm nút mạng TLV thì khi ATM-LSR truyền đi bản tin yêu cầu nhãn của nó sẽ chứa trường này nhưng bộ đếm nút mạng đã được tăng lên một đơn vị. Nó ngược so với việc sử dụng TTL trong đó mỗi khi qua một nút mạng TTL lại giảm đi một đơn vị. Khi ATM-LSR nhận được một bản tin chuyển đổi nhãn, nếu như bản tin này có chứa bộ đếm nút mạng TLV thì bộ đếm này cũng được tăng lên một đơn vị khi bản tin chuyển đổi nhãn được gửi tới nút tiếp theo.
110 trang |
Chia sẻ: huong.duong | Lượt xem: 1408 | Lượt tải: 0
Bạn đang xem trước 20 trang tài liệu Tầng trình diễn (Presentation Layer), để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
ệc chuyển đổi giữa các FEC và LSP chỉ được giới hạn trong LSR tại một đầu của LSP. Nói một cách khác, việc quyết định gói IP nào sẽ định tuyến hiện như thế nào hoàn toàn do LSR tính toán xác định tuyến. Như đã trình bày ở trên, đây chính là chức năng cần thiết để hỗ trợ định tuyến cưỡng bức.
Cũng như các chức năng khác của MPLS, chức năng định tuyến hiện của MPLS cũng được chia làm 2 phần: điều khiển và chuyển tiếp. Phần tử điều khiển chịu trách nhiệm thiết lập trạng thái chuyển tiếp (nhãn) dọc theo tuyến hiện. Phần tử chuyển tiếp sử dụng trạng thái chuyển tiếp được thiết lập bởi phần tử điều khiển cũng như các thông tin có trong các gói tin để truyền các gói tin dọc theo tuyến hiện.
III.4.3. Giao thức RSVP
Giao thức 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 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 TSpec và RSpec, bao gồm các dịch vụ yêu cầu (có đảm bảo 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à bộ các đị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 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 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ợ đa hướng. 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ỉ đơ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. 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.
Khi bộ nhận nhận được bản tin PATH, có thể gửi bản tin RESV trở lại 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ộ phậ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 III.15 biểu diễn trình tự bản tin trao đổi giữa bộ gửi và bộ 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ụ 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, nên 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.
Hình III.15: Gửi và nhận các bản tin PATH và RESV
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ờ kiểm tra 5 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à nguồn cổng. Chúng ta gọi tập các gói tin được nhận dạng theo cách này 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 đơn hướng thì RSVP khá đơn giản. Nó phức tạp hơn trong môi trường đa hướng, bởi vì có thể rất nhiều bộ nhận dành riêng cổng cho một phiên đơn và các bộ phậ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 đơn hướng của RSVP, chúng ta sẽ không đi sâu vào khía cạnh đa hướng của RSVP.
Điểm cuối cùng phải chú ý về RSVP vì đây 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 loại giao thức 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 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 đi trong một khoảng thời gian xác định thì các cổng dành riêng bị tự động hủy bỏ.
III.4.3.1. MPLS hỗ trợ RSVP
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.
Đ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 đơn hướng. 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 một bản tin RESV cho một luồng 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. Chú ý là các bản tin RESV truyền từ bộ nhận tới bộ gửi 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 đế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 III.16 minh hoạ quá trình trao đổi này. ở đây chúng ta giả thiết 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 tớ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 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 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 R2.
Hình III.16: Nhãn phân phối trong bản tin RESV
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 việc kiểm soát luồng, xếp hàng đợi gói tin…như thế nào. Điều này tất nhiên không cần kiểm tra mào đầu 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.
Lưu ý rằng, 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 nên việc kết hợp được điều khiển như trong các môi trường khác của MPLS. Lưu ý đâ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.
Một kết quả quan trọng 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 xét 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 quy ước, các cổng dành riêng RSVP có thể chỉ tạo cho những luồng ứng dụng riêng lẻ, tức là những luồng được xác định nhờ 5 trường mào đầu như mô tả trong phần trên. 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 bảo đảm từ một side của một công ty lớn đến một side khác, thay vì phải sử dụng đường thuê bao riêng giữa các side 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.
Chương IV
Các vấn đề kỹ thuật trong MPLS
IV.1. Chất lượng dịch vụ
Chất lượng dịch vụ QoS (Quality of Service) là một trong những yếu tố thúc đẩy MPLS. So sánh với các yếu tố khác như quản lý lưu lượng và hỗ trợ VPN thì QoS không phải là lí do quan trọng nhất để triển khai MPLS. Như chúng ta sẽ thấy dưới đây, hầu hết các công việc được thực hiện trong MPLS QoS được tập trung vào việc hỗ trợ các thuộc tính của IP QoS trong mạng. Nói cách khác, mục tiêu là thiết lập sự giống nhau giữa các thuộc tính QoS của IP và MPLS, chứ không phải là làm cho MPLS QoS có chất lượng cao hơn IP QoS.
Một trong những lý do để khẳng định MPLS không giống như IP là MPLS không phải là giao thức xuyên suốt. MPLS không chạy trong máy chủ, và trong tương lai nhiều mạng IP không sử dụng MPLS vẫn tồn tại. Mặt khác QoS là thuộc tính xuyên suốt của liên lạc giữa các LSR cùng cấp. Ví dụ, nếu một kênh kết nối trong tuyến xuyên suốt có độ trễ cao, độ tổn thất lớn, băng thông thấp sẽ giới hạn QoS cung cấp dọc theo tuyến đó. Một cách nhìn nhận khác về vấn đề này là MPLS không thay đổi về căn bản mô hình dịch vụ IP. Các nhà cung cấp dịch vụ không bán dịch vụ MPLS, họ bán dịch vụ IP (hay dịch vụ Frame Relay và các dịch vụ khác). Do đó, nếu họ đưa ra QoS thì họ phải đưa ra IP QoS (Frame Relay QoS …) chứ không phải là MPLS QoS.
Điều đó không có nghĩa là MPLS không có vai trò trong IP QoS. Thứ nhất, MPLS có thể giúp nhà cung cấp đưa ra các dịch vụ IP QoS hiệu quả hơn. Thứ hai, hiện đang xuất hiện một số khả năng QoS mới hỗ trợ qua mạng sử dụng MPLS không thực sự xuyên suốt. Tuy nhiên, một trong số những điều hữu ích là băng thông bảo đảm của LSP.
Do mối quan hệ gần gũi giữa IP QoS và MPLS QoS, nên phần này sẽ xoay quanh các thành phần chính của IP QoS. IP cung cấp hai mô hình QoS: Dịch vụ tích hợp IntServ (sử dụng chế độ đồng bộ với RSVP) và dịch vụ DiffServ.
IV.1.1. Dịch vụ Best Effort
Đây là dịch vụ thường gặp trên mạng Internet hay là mạng IP nói đến chung. Các gói thông tin được chuyển đi theo nguyên tắc “đến trước được phục vụ trước” mà không yêu cần quan tâm đến đặc tính lưu lượng của dịch vụ đòi hỏi độ trễ thấp như các dịch vụ thời gian thực hay video. Cho đến thời điểm hiện nay, đa phần các dịch vụ cung cấp bởi Internet vẫn sử dụng nguyên tắc Best Effort.
IV.1.2. Mô hình dịch vụ tích hợp (IntServ)
Đứng trước nhu cầu ngày càng tăng trong trong việc cung cấp các dịch vụ thời gian thực (thoại, video) và băng thông cao (đa phương tiện) dịch vụ tích hợp IntServ đã ra đời. Đây là sự phát triển của mạng IP nhằm đồng thời cung cấp dịch vụ truyền thống Best Effort và các dịch vụ thời gian thực. Động lực thúc đẩy mô hình này chủ yếu do những lý do cơ bản sau đây:
Dịch vụ Best Effort không còn đủ tốt nữa: ngày càng có nhiều ứng dụng khác nhau có những yêu cầu khác nhau về đặc tính lưu lượng được triển khai, đồng thời người sử dụng ngày càng yêu cầu cao hơn về chất lượng dịch vụ.
Các ứng dụng đa phương tiện ngày càng xuất hiện nhiều: mạng IP phải có khả năng hỗ trợ không chỉ đơn dịch vụ mà phải hỗ trợ tích hợp đa dịch vụ của nhiều loại lưu lượng khác nhau từ thoại, số liệu đến video.
Tối ưu hóa hiệu suất sử dụng và tài nguyên mạng: đảm bảo hiệu quả sử dụng và đầu tư. Tài nguyên mạng sẽ được dự trữ cho lưu lượng có độ ưu tiên cao hơn, phần còn lại sẽ dành cho số liệu dạng dạng Best Effort.
Cung cấp dịch vụ tốt nhất: mô hình dịch vụ IntServ cho phép nhà cung cấp mạng cung cấp được dịch vụ tốt nhất khác biệt với các nhà cung cấp cạnh tranh khác.
Mô hình IntServ được mô tả trong hình IV.1.
Dữ liệu
Thiết lập
ứng dụng
Phân loại
Thiết bị phân phối
Giao thức đinh tuyến / CSDL
Thiết lập
Phân loại
Thiết bị phân phối
Điều khiển chấp nhận/cưỡng bức
Các bản tin thiết lập đặt trước
Dữ liệu IP
Hình IV.1: Mô hình dịch vụ IntServ
Theo mô hình này có một số thành phần tham gia như sau:
Giao thức thiết lập: Thiết lập (Setup) cho phép các máy chủ và các bộ định tuyến dự trữ động tài nguyên trong mạng để xử lý các yêu cầu của các luồng lưu lượng riêng, RSVP là một trong những giao thức đó.
Đặc tính luồng: Xác định chất lượng dịch vụ QoS sẽ cung cấp cho luồng riêng biệt. Luồng được định nghĩa như một dòng gói từ nguồn đến đích có cùng yêu cầu về QoS. Về nguyên tắc có thể hiểu đặc tính luồng như băng tần tối thiểu mà mạng bắt buộc phải cung cấp để bảo đảm QoS cho luồng yêu cầu.
Điều khiển lưu lượng: trong các thiết bị mạng (máy chủ, bộ định tuyến, chuyển mạch) có các thành phần điều khiển và quản lý tài nguyên mạng để hỗ trợ QoS theo yêu cầu. Các thành phần điều khiển lưu lượng này có thể được khai báo bởi các giao thức báo hiệu RSVP hay nhân công. Thành phần điều khiển lưu lượng bao gồm:
+ Điều khiển chấp nhận: xác định thiết bị mạng có khả năng hỗ trợ QoS theo yêu cầu hay không.
+ Thiết bị phân loại (Classifer): nhận dạng và lựa chọn lớp dịch vụ dựa vào nội dung của một số trường nhất định trong mào đầu gói.
+ Thiết bị phân phối (Scheduler): cung cấp các mức chất lượng dịch vụ QoS trên kênh ra của thiết bị mạng.
Các mức chất lượng dịch vụ cung cấp bởi IntServ bao gồm:
Dịch vụ bảo đảm GS (Guranteed Service): băng tần dành riêng, trễ có giới hạn và không bị thất thoát gói tin trong hàng. Các ứng dụng cung cấp thuộc loại này có thể kể đến: hội nghị truyền hình chất lượng cao, thanh toán tài chính thời gian thực…
Dịch vụ kiểm soát tải CL (Controller Load Service): không bảo đảm về băng tần hay trễ nhưng khác Best Effort ở chỗ không giảm chất lượng một cách đáng kể khi tải mạng tăng lên. Nó phù hợp cho các ứng dụng không nhạy cảm như truyền đa hướng âm thanh/hình ảnh chất lượng trung bình.
IV.1.3. Mô hình dịch vụ DiffServ
Việc đưa ra mô hình IntServ có vẻ như đã giải quyết được nhiều vấn đề liên quan đến QoS trong mạng IP. Tuy nhiên trên thực tế, mô hình này không thực sự đảm bảo được QoS xuyên suốt (End-to-End). Đã có nhiều cố gắng để thay đổi điều này nhằm đạt được một mức QoS cao hơn cho mạng IP. Một trong những cố gắng đó là sự ra đời của DiffServ. DiffServ sử dụng đánh dấu gói và xếp hàng theo loại để hỗ trợ các dịch vụ ưu tiên qua mạng IP. Hiện tại IETF đã có một nhóm làm việc DiffServ để đưa ra các tiêu chuẩn RFC về DiffServ.
Nguyên tắc cơ bản của DiffServ như sau:
Định nghĩa một số lượng nhỏ các lớp dịch vụ hay mức ưu tiên. Một lớp dịch vụ có thể liên quan đến đặc tính lưu lượng (băng tần nhỏ nhất/lớn nhất, kích cỡ burst, thời gian kéo dài burst…).
Xếp loại và đánh dấu các gói riêng biệt tại biên của mạng vào các lớp dịch vụ.
Các thiết bị chuyển mạch, bộ định tuyến trong mạng lõi sẽ phục vụ các gói theo nội dung của các bit đã được đánh dấu trong mào đầu của gói.
Với nguyên tắc này, DiffServ có nhiều lợi thế hơn so với IntServ:
Không yêu cầu báo hiệu cho từng luồng.
Dịch vụ ưu tiên có thể áp dụng cho một số luồng riêng biệt cùng một lớp dịch vụ. Điều này cho phép nhà cung cấp dịch vụ dễ dàng cung cấp một số lượng nhỏ các mức dịch vụ khác nhau cho khách hàng có nhu cầu.
Không yêu cầu thay đổi tại các máy chủ hay các ứng dụng để hỗ trợ dịch vụ ưu tiên. Đây là công việc của thiết bị biên.
Hỗ trợ rất tốt dịch vụ VPN.
Tuy nhiên có thể nhận thấy DiffServ vẫn có một số vấn đề cần giải quyết sau:
Không có khả năng cung cấp băng tần và độ trễ đảm bảo như GS của IntServ.
Thiết bị biên vẫn yêu cầu bộ phân loại (Classifier) chất lượng cao cho từng gói giống như mô hình IntServ.
Vấn đề quản lý trạng thái phân loại của một số lượng các thiết bị biên là một vấn đề không nhỏ cần quan tâm.
Chính sách khuyến khích khách hàng trên cơ sở giã cước cho dịch vụ cung cấp cũng ảnh hưởng đến giá trị của DiffServ.
Mô hình DiffServ tại biên và lõi được mô tả trong hình IV.2.
Phân loại Multi-byte
Giám sát
Đánh dấu gói
Quản lý hàng đợi và phân phối
Bộ định tuyến biên
Phân loại
DS-byte
Quản lý hàng đợi và phân phối
Bộ định tuyến lõi
Hình IV.2: Mô hình DiffServ tại biên và lõi của mạng
Mô hình DiffServ bao gồm một số thành phần như sau:
DS-Byte: byte xác định DiffServ là thành phần ToS của Ipv4. Các bit trong byte này thông báo gói tin nhận được thuộc dịch vụ nào.
Các thiết bị biên (bộ định tuyến): đặt tại lối vào hay lối ra của mạng cung cấp DiffServ.
Các thiết bị bên trong của mạng DiffServ.
Giám sát: các công cụ và nhà quản trị mạng giám sát và đo kiểm đảm bảo SLA (Service Level Agreement) giữa mạng và người dùng.
IV.1.4. Mô hình chất lượng dịch vụ MPLS
Tương tự như DiffServ, MPLS cũng hỗ trợ chất lượng dịch vụ trên cơ sở phân loại các luồng lưu lượng theo các tiêu chí như độ trễ, băng tần… Đầu tiên tại biên của mạng, luồng lưu lượng của người dùng được nhận dạng (bằng việc phân tích một số trường trong mào đầu của gói) và chuyển các luồng lưu lượng đó trong các LSP với các thuộc tính CoS (Classes of Service) hay QoS của nó. MPLS có thể hỗ trợ các dịch vụ không định trước qua LSP bằng việc sử dụng một trong các kỹ thuật sau:
Bộ chỉ thị CoS hiện có thể được truyền đi trong nhãn gắn liền với từng gói. Bên cạnh việc chuyển mạch các nhãn tại từng nút LSR, mỗi gói có thể được chuyển sang kênh ra dựa trên thuộc tính CoS. Mào đầu đệm (Shim header) MPLS có chứa trường CoS.
Trong trường hợp nhãn không chứa chỉ thị CoS hiện thì giá trị CoS có thể liên quan ngầm định với một LSP cụ thể. Điều đó đòi hỏi LDP hay RSVP gán giá trị CoS không danh định cho LSP để các gói được xử lý phù hợp.
Chất lượng dịch vụ QoS có thể được cung cấp bởi một LSP được thiết lập trên cơ sở báo hiệu ATM (trong trường hợp này mạng MPLS là mạng ATM-LSR).
IV.2. Kỹ thuật lưu lượng trong MPLS
Kỹ thuật điều khiển lưu lượng là quá trình điều khiển các luồng lưu lượng qua mạng để tối ưu hệ số sử dụng tài nguyên và hiệu suất mạng.
Bài toán điều khiển lưu lượng trong mạng IP gặp một số khó khăn sau:
Thứ nhất, thuật toán tìm đường đi ngắn nhất thường gây ra tắc ngẽn vì đường đi được chọn không đủ tài nguyên đáp ứng yêu cầu về lực lượng hoặc phân bổ tài nguyên mạng không hiệu quả (dồn nhiều luồng cùng đi qua một liên kết hoặc một nút).
Thứ hai, việc thay đổi tham số IGP có thể gây ảnh hưởng đến hoạt động của toàn mạng và không hiệu quả.
Ngoài ra trong kỹ thuật điều khiển lượng dựa vào IP khó giải quyết được bài toán cân bằng tải lưu lượng trên toàn mạng.
Định tuyến cưỡng bức tìm đường đi theo yêu cầu lưu lượng và tài nguyên hiện có trong mạng nên tránh được vấn đề tắc nghẽn xảy ra khi dồn nhiều lưu lượng vào một liên kết không đủ tài nguyên. Ngoài ra, MPLS còn cho phép thiết lập nhiều đường giữa hai cặp nút với tỉ lệ thích hợp để giải quyết vấn đề cân bằng tải. Do vậy, vấn đề thứ nhất được giải quyết. MPLS đưa ra khái niệm đường đi LSP nên tránh được vấn đề dao động lưu lượng mạng. MPLS còn đưa ra khái niệm FEC cho phép nhóm các luồng lưu lượng với kích cỡ thích hợp. Như vậy, định tuyến cưỡng bức kết hợp với MPLS giải quyết được phần nào những hạn chế của vấn đề điều khiển lưu lượng trong mạng IP theo cách tiếp cận tích hợp với chi phí thấp hơn giải pháp IP over ATM.
IV.2.1. Các thành phần trong kỹ thuật lưu lượng MPLS
Kỹ thuật điều khiển lưu lượng dùng MPLS gồm các thành phần chính như trong hình IV.3.
MPLS signaling
(CR-LDP/RSVP)
Contraint-based
Routing
Extented IGP routing
protocol
Link-state database with traffic engineering extension
Hình IV.3: Các thành phần của kỹ thuật lưu lượng dựa vào MPLS
Khi trạng thái mạng thay đổi, giao thức định tuyến IGP mở rộng sẽ gửi các bản tin cập nhật để thông tin về trạng thái mạng tại mỗi nút bám sát tài nguyên mạng hiện có. Khi có một yêu cầu lưu lượng mới, hoặc dựa vào chính sách quản trị, định tuyến cưỡng bức sẽ dựa vào các thông tin mới nhất có trong cơ sở dữ liệu để tìm đường đi thỏa mãn yêu cầu QoS. Tiếp theo, để đảm bảo là tài nguyên vẫn còn trên đường đi vừa chọn được và dành tài nguyên đó cho yêu cầu mới, các giao thức báo hiệu MPLS sẽ thực hiện việc thiết lập đường đi LSP qua mạng đáp ứng đòi hỏi của lưu lượng yêu cầu. Nếu đường đi đó không đủ tài nguyên để đáp ứng yêu cầu này, định tuyến ràng buộc sẽ được thông báo để tính lại một đường khác hoặc thực hiện các thao tác liên quan đến chính sách quản trị (như thỏa thuận giữa khách hàng và nhà cung cấp dịch vụ, hoặc chấp nhận chỉ đáp ứng với mức chất lượng dịch vụ thấp hơn yêu cầu). Quá trình kiểm tra tài nguyên hiện có để đáp ứng yêu cầu QoS được gọi là quá trình điều khiển thu nhận (Admission Control). Sau khi đường đi LSP được thiết lập qua mạng, tài nguyên hiện có của mạng sẽ thay đổi và cập nhật vào cơ sở dữ liệu link-state.
IV.2.1.1. Các khái niệm
FEC: là một nhóm các gói dữ liệu được chuyển tiếp qua mạng theo cùng một cách (ví dụ như đi qua cùng một đường và được xử lý như nhau) nên các gói dữ liệu này được ánh xạ trên cùng một đường LSP. Mỗi một đường LSP có một FEC tương ứng với nó được báo hiệu vào lúc thiết lập đường. Mỗi một FEC có thể được xem như một bộ lọc gói IP để quyết định gói nào được ánh xạ lên đường LSP nào. MPLS sử dụng khái niệm FEC để gom các luồng lưu lượng với kích cỡ thích hợp. Trong cùng một mạng có thể có nhiều FEC với mức độ gom khác nhau.
Trung kế lưu lượng (Traffic Trunk): là một tập hợp các luồng dữ liệu theo cùng một loại được đặt trong một đường LSP. Về bản chất, traffic trunk là cách trừu tượng hóa các luồng lưu lượng cùng loại với các đặc điểm cụ thể được gán liền với nó. Đường LSP được thiết lập để truyền tải traffic trunk qua đó phải thỏa mãn các đặc điểm của traffic trunk.
Physical link
LSP LSP
FECs FECs
LSP LSP
FECs FECs
Hình IV.4: FEC, Traffic trunk, LSP
Hình IV.4 minh họa quan hệ giữa các khái niệm này. Các gói được phân thành từng loại FEC ở đầu vào của mạng. Sau đó, các FEC cùng loại được gom lại thành traffic trunk. LSP được thiết lập qua mạng MPLS phải có đặc điểm của traffic trunk. Và trên cùng một liên kết vật lý, có thể có nhiều đường LSP đi qua.
Vấn đề căn bản của kỹ thuật điều khiển lưu lượng sử dụng MPLS là: ánh xạ các gói tin vào các FEC, ánh xạ các FEC thành các trung kế lưu lượng, ánh xạ trung kế lưu lượng lên cấu trúc vật lý của mạng thông qua các LSP. Các gói tin sẽ được phân tích và ánh xạ vào FEC tùy vào mức độ chi tiết của FEC. Các FEC có cùng chung một đặc điểm (đầu vào, đầu ra, các tham số QoS …) sẽ được ánh xạ vào cùng một traffic trunk. Để điều khiển đường LSP một cách hiệu quả, mỗi một LSP được gắn một hay nhiều thuộc tính là các thuộc tính của traffic trunk xác định các đặc điểm hoạt động của nó. Việc chọn đường và thiết lập đường LSP phải dựa vào các thuộc tính này. Các thuộc tính này được tóm tắt trong bảng IV.1.
Thuộc tính
Ngữ nghĩa của thuộc tính
Băng thông
Yêu cầu băng thông tối thiểu của LSP
Thuộc tính đường (Path attribute)
Xác định đường được nhà quản trị cấu hình hay được tính toán bằng định tuyến ràng buộc
Quyền ưu tiên thiết lập (Setup priority)
Xác định đường ưu tiên thiết lập khi có nhiều LSP cùng thiết lập
Quyền ưu tiên chiếm (Holding priority)
Sau khi LSP được thiết lập, nó có một mức ưu tiên để giữ tài nguyên mà nó vừa dành được
Lực hấp dẫn (affinity/ color)
Là thuộc tính quản trị, xác định những loại lưu lượng mạng nào được xét đến khi tìm đường LSP
Tính tương thích (Adaptability)
Cho phép một LSP được chuyển đến một đường tối ưu hơn khi trạng thái mạng thay đổi
Tính phục hồi (Resilience)
Khi đường LSP đang sử dụng bị lỗi, thuộc tính này cho phép định tuyến lại LSP hay không
Bảng IV.1: Thuộc tính của traffic trunk
IV.2.1.2. Chọn đường
Để giải quyết bài toán tìm đường trong mạng MPLS, có hai cách tiếp cận: (1) cấu hình các đường đi, (2) tính đường (dùng định tuyến cưỡng bức). Định tuyến cưỡng bức được sử dụng để tự động hóa quá trình tìm đường và cân bằng tải lưu lượng trong toàn mạng. Trong mạng MPLS, định tuyến cưỡng bức được sử dụng để phục vụ cho những mục đích sau: (1) định tuyến động, (2) tối ưu lại các LSP và (3) phục hồi các đường LSP.
IV.2.1.2.1. Định tuyến ràng buộc trực tuyến (online) và ngoài tuyến (offline)
Định tuyến ràng buộc có thể được thực hiện trực tuyến (online) ngay trong mạng hay bên ngoài mạng (offline). Định tuyến ràng buộc offline là quá trình tính toán thực hiện ngoài mạng. Quá trình tính toán thực hiện với sơ đồ cấu trúc mạng chính xác và chi tiết để tìm ra các đường đi cho ma trận lưu lượng biết trước. Mục đích của quá trình tính toán bên ngoài mạng là tối ưu hệ số sử dụng tài nguyên mạng biết trước các yêu cầu về lưu lượng. Vì quá trình tính toán ở bên ngoài mạ
Các file đính kèm theo tài liệu này:
- DAN080.doc