Đồ án Chất lượng dịch vụ trên Linux

CHƯƠNG I TỔNG QUAN I.1 Đặt vấn đề Ngày nay, Internet phát triển nhanh chóng và dần trở thành mạng đa dịch vụ, việc sử dụng các ứng dụng VOIP và video call ngày càng phổ biến. Từ đó, việc triển khai chất lượng dịch vụ trong các công ty để đảm bảo hoạt động của các ứng dụng yêu cầu thời gian thực, độ trễ thấp, băng thông rộng cũng phát triển theo. Tuy nhiên, đối với các công ty vừa và nhỏ, việc đầu tư hàng ngàn đôla cho bộ định tuyến cứng hỗ trợ chất lượng dịch vụ vẫn còn là vấn đề nan giải. Bộ định tuyến mềm với chi phí nhỏ và khả năng linh hoạt được hỗ trợ bởi hệ điều hành nguồn mở Linux ra đời đã khắc phục được vấn đề về chi phí đầu tư cho các công ty vừa và nhỏ. I.2 Nhiệm vụ của đồ án I.2.1 Bài toán Hệ thống mô tả mô hình mạng của công ty TNHH NetNam. Công ty này có nhiều chi nhánh đặt tại Hồ Chí Minh và Hà Nội. Mỗi chi nhánh có một mạng nội bộ riêng và bao gồm rất nhiều phòng ban như: phòng nhân sự, phòng kế toán, phòng kinh doanh, phòng kĩ thuật,…Riêng trụ sở chính đặt tại Hồ Chí Minh sẽ có hệ thống máy chủ đó là: Web Server, FTP Server và Mail Server. Mô hình mạng của công ty như sau: Hình 1.1: Mô hình công ty Để tiết kiệm chi phí về vấn đề bản quyền hệ điều hành và phần mềm cho các máy tính, nên công ty đã áp dụng mô hình mạng gồm 100% máy tính chạy trên hệ điều hành Linux. Đối với bộ chuyển mạch (switch), công ty dùng các thiết bị chuyên dụng của hãng Cisco. Dữ liệu của công ty gồm có: Thông tin khách hàng Hóa đơn Báo cáo kinh doanh, kế toán,… Dữ liệu backup Dữ liệu từ Web Server, FTP Server và Mail Server Như vậy các ứng dụng thường được sử dụng trong hệ thống là: Trình duyệt web (Web Browser): để truy cập web, FTP và mail Hệ quản trị cơ sở dữ liệu MySQL Các phần mềm văn phòng: Word, Excel,… I.2.2 Vấn đề cần giải quyết Hằng ngày sẽ có rất nhiều lưu lượng khác nhau (Web, FTP, Mail,…) giữa các chi nhánh với hệ thống máy chủ. Vấn đề xảy ra đó là có những thời điểm một số máy trạm truy xuất dữ liệu rất chậm, trong khi một số máy trạm khác lại truy xuất bình thường. Lý do chính là máy nào truy xuất dữ liệu trước và truy xuất dữ liệu có dung lượng lớn sẽ chiếm hết băng thông của những máy trạm truy xuất sau. Ví dụ Khi 50% máy trạm ở chi nhánh 1 cùng đồng thời tải dữ liệu FTP từ máy chủ xuống, thì 50% máy trạm còn lại sẽ gởi/nhận email hay truy cập web với tốc độ rất chậm (vì FTP đã chiếm hết băng thông của hệ thống, không còn băng thông dành cho lưu lượng web và mail). Yêu cầu đặt ra là phải làm sao để mỗi loại dịch vụ (Web, FTP, Mail,…) chỉ chiếm băng thông đã cấp riêng cho dịch vụ đó, không được phép giành băng thông của các dịch vụ khác. Nếu yêu cầu được đáp ứng thì các dịch vụ luôn có thể thể truy xuất ở mọi thời điểm. Có hai giải pháp được đề xuất, đó là: Giải pháp 1: Nâng cấp toàn bộ hệ thống mạng để làm tăng băng băng thông. Công việc phải làm là thuê đường truyền có băng thông lớn hơn giữa các chi nhánh để tăng băng thông cho mạng WAN và nâng cấp băng thông mạng LAN từ 100MB/s lên 1GB/s bằng cách mua card mạng hỗ trợ tốc độ 1GB/s rồi gắn vào các máy tính trong toàn hệ thống mạng,… Giải pháp 2: Triển khai chất lượng dịch vụ mạng (QoS) trên hệ thống có sẵn. Giải pháp này cực kì đơn giản đó là chỉ cần sử dụng tiện ích “tc” (traffic control) đã được tích hợp sẵn trong hầu hết các phiên bản của linux. Tiện ích “tc” dùng để triển khai chất lượng dịch vụ mạng rất hiệu quả. Nó có thể đánh dấu trường DSCP của mỗi gói tin để hệ thống ưu tiên trong việc xử lý và nó có thể hạn chế băng thông cho từng loại dịch vụ của từng mạng. Ví dụ Với tiện ích “tc” chúng ta có thể điều khiển được băng thông trên hệ thống mạng bằng cách giới hạn lưu lượng FTP được sử dụng 40% băng thông hệ thống, lưu lượng HTTP và Mail được sử dụng 30% băng thông của hệ thống, các lưu lượng khác được sử dụng 30% băng thông còn lại của hệ thống. Đây chính là các giá trị băng thông cố định (Fixed Bandwidth) hay còn gọi là băng thông đảm bảo (Guaranteed Bandwidth). Ngoài ra, tiện ích “tc” còn cung cấp cơ chế mượn băng thông rất hay đó là: khi một dịch vụ đang thiếu băng thông thì nó có thể tăng băng thông lên bằng cách mượn băng thông của các dịch vụ khác đang dư hoặc không sử dụng băng thông. Ví dụ Có những thời điểm mà 40% băng thông dành cho FTP vẫn chưa đủ để đáp ứng nhu cầu cho các máy trạm thì hệ thống sẽ tự động tìm băng thông dư thừa ở các dịch vụ khác. Nếu hệ thống phát hiện băng thông được cấp riêng cho HTTP và Mail chỉ đang sử dụng 10%, thì 20% băng thông dư thừa sẽ được đẩy qua cho băng thông FTP. Như vậy, tiện ích tc đã cung cấp tính năng triển khai chất lượng dịch vụ mạng nói chung và khả năng giới hạn băng thông cho từng loại dịch vụ rất hiệu quả. Tóm lại, nếu xét về vấn đề kinh tế thì giải pháp thứ hai sẽ không tốn chi phí, trong khi giải pháp 1 lại cần rất nhiều kinh phí để mua card mạng cũng như số tiền thuê đường truyền WAN hàng tháng sẽ tăng lên đáng kể. Nếu xét về vấn đề hiệu quả, thì giải pháp thứ hai đã đáp ứng đầy đủ nhu cầu về chất lượng mạng của công ty. Cụ thể giải pháp thứ hai luôn đảm bảo mỗi loại dịch vụ có một băng thông cam kết. Do đó, các dịch vụ không còn hiện tượng giành băng thông của nhau. Vì băng thông hiện tại của hệ thống đã thực sự đủ đối với nhu cầu sử dụng cho công việc của công ty TNHH NetNam nên việc tăng thêm băng thông mạng LAN và WAN là một giải pháp lãng phí và không hiệu quả. Lý do không hiệu quả là vì nếu tăng thêm băng thông mà không giới hạn băng thông cho từng loại dịch vụ thì hiện tượng các dịch vụ chiếm băng thông của nhau vẫn tiếp tục xảy ra. Để việc chiếm băng thông không ảnh hưởng gì đến tốc độ truy xuất của các dịch vụ khác thì đòi hỏi công ty phải thuê đường truyền WAN với tốc độ rất lớn. Và hệ quả của giải pháp thứ nhất chính là sự lãng phí. Trong khi đó, tài nguyên mạng của hệ thống hiện tại đã đủ, vấn đề chỉ là giới hạn băng thông cho từng loại dịch vụ mạng. Do đó, giải pháp thứ hai là một giải pháp hoàn hảo cho các công ty có quy mô không lớn như NetNam. I.3 Cấu trúc đồ án Đồ án gồm 5 chương: Chương I Giới thiệu tổng quan về vai trò của chất lượng dịch vụ trên hệ điều hành linux. Ngoài ra, chương I cũng trình bày rất kĩ mô hình mạng thực tế của công ty TNHH NetNam. Thông qua mô hình thực tế này, chương I đã chỉ ra các vấn đề cần giải quyết của công ty về vấn đề truy xuất dữ liệu đến máy chủ. Cuối cùng, chương I đã đề ra các giải pháp và vẽ mô hình thực nghiệm để chương III và chương IV chứng minh tính khả thi của giải pháp thông qua quá trình demo. Chương II Cung cấp các nền tảng lý thuyết về QoS nói chung và QoS trên Linux. Đặc biệt, mô hình phân biệt dịch vụ (DiffServ) được trình bày khá chi tiết (vì đây chính là mô hình sẽ được demo ở chương III và chương IV). Chương III Trình bày vai trò của từng máy tính trong mô hình hệ thống. Đồng thời hướng dẫn cách xây dựng, cấu hình để có thể xây dựng mô hình này trên hệ thống các máy ảo. Chương IV Đây là chương demo việc triển khai chất lượng dịch vụ trên linux. Trong phần đầu tiên của chương sẽ hướng dẫn cách kiểm tra việc triển khai chất lượng dịch vụ đã thành công hay chưa. Tiếp theo là ba kịch bản liên quan đến ba vấn đề khác nhau trong việc triển khai chất lượng dịch vụ mạng. Kịch bản 1: Chỉnh sửa trường DSCP của gói tin Kịch bản 2: Giới hạn băng thông - không cho phép mượn băng thông Kịch bản 3: Giới hạn băng thông - cho phép mượn băng thông Trọng tâm của chương IV chính là kịch bản 3 vì nó thể hiện tính linh động trong việc sử dụng băng thông. Chương V Trình bày các đúc kết sau khi hoàn thành đồ án. Các đúc kết bao gồm: tóm lược vấn đề đã trình bày, cách thức giải quyết vấn đề, kết quả đạt được, điểm nổi bật, hạn chế và cuối cùng là phương hướng mở rộng đề tài. CHƯƠNG II LÝ THUYẾT CHẤT LƯỢNG DỊCH VỤ (QoS) II.1 Định nghĩa QoS QoS là thuật ngữ được dùng để định nghĩa khả năng cung cấp các cấp độ khác nhau về sự bảo đảm dịch vụ đối với nhiều loại lưu lượng của một mạng.QoS là một tập các kỹ thuật xử lý lưu lượng trong mạng truyền số liệu nhằm đảm bảo các loại lượng có yêu cầu chất lượng dịch vụ khác nhau được đối xử ưu tiên khác nhau. QoS cung cấp các độ ưu tiên khác nhau đối với từng dòng liệu, người dùng, ứng dụng khác nhau để đảm bảo một mức độ hoạt động ổn định của dòng dữ liệu. Ví dụ: trong mạng IP có hai ứng dụng phổ biến là truyền file FTP và dịch vụ gọi điện thoại IP telephony. Ứng dụng IP telephony đòni hỏi dữ liệu phải được truyền liên tục, độ trễ thấp , còn ứng dụng FTP thì không yêu cầu cao về độ trễ, miễn là truyền đủ và chính xác nội dung dữ liệu. Để thực hiện được yêu cầu ứng dụng IP Telephony hoạt động được ổn định cho dù xảy ra tranh chấp tài nguyên khi 2 ứng dụng cùng chạy song song hoạt nghẽn mạng thì ta cần phải áp dụng các kỹ thuật xử lý và phân loại lưu lượng và áp dụng các chính sách ưu tiên khác nhau nhằm đảm bảo lưu lượng IP telephony phải có độ ưu tiên đường truyền cao hơn lưu lượng FTP. QoS hoạt động dựa trên các bước cơ bản sau: Phân lớp và dánh dấu Kiểm tra chính sách định tuyến Đưa vào hàng đợi hoặc đánh rớt II.2 Các tiêu chí đánh giá QoS Hiệu quả của chất lượng dịch vụ (QoS) được đánh giá dựa vào các thông số sau: Tỷ lệ mất gói: tham số này cho biết tỷ lệ phần trăm số gói tin bị mất trên tổng số gói tin đầu gửi đã chuyển cho đầu nhận. Độ trễ gói: tham số này cho biết khoảng thời gian gói tin được chuyển từ đầu gởi đến đầu nhận. Độ biến thiên trễ: tham số này cho biết sự dao động về độ lớn của độ trễ gói Khả năng đáp ứng của dịch vụ: tham số này cho biết xác suất sử dụng thành công dịch vụ II.3 Phân lớp lưu lượng Việc phân lớp lưu lượng được thực hiện tại cả lớp 2 (lớp liên kết dữ liệu - Datalink layer) và lớp 3 (lớp mạng Network layer) trong mô hình OSI. II.3.1 Phân lớp lưu lượng ở mức lớp mạng Để sắp xếp các luồng dữ liệu IP thành các lớp khác nhau nhằm phục vụ cho các chính sách QoS khác nhau, 3 bit đầu tiên trong trường loại dịch vụ (Service Type - ToS) trong phần IP header của gói dữ liệu sẽ được sử dụng. 3 bit này được gọi là trường IP Precedence và có giá trị mặc định là 0. Trường IP Precedence bằng 0, có nghĩa là gói tin này sẽ được truyền theo kiểu hiệu quả tối đa (Best Effort). 7 giá trị còn lại của trường IP Precedence dùng để phân chia lưu lượng IP thành 7 lớp dịch vụ có thứ tư ưu tiên tăng dần. Hình 2.1: Các trường trong IPv4 và IPv6 headers Hình 2.2: Các tham số của trường ToS trong IPv4 header Trong trường hợp cần thiết phải phân chia nhiều hơn 8 lớp lưu lượng, 6 bit đầu tiên của trường ToS gọi là trường DSCP sẽ được sử dụng. Trường DSCP có giá trị từ 0 đến 63, do đó nó cho phép phân chia lưu lượng IP thành 64 lớp dịch vụ khác nhau. Tuy nhiên, một số thiết bị mạng cũ có thể không hỗ trợ việc phân lớp lưu lượng sử dụng trường DSCP này. Thực tế, trường IP Precedence là nằm trong trường DSCP nên ta không thể cùng lúc vừa phân lớp lưu lượng theo IP Precedence và vừa theo DSCP Hình 2.3: Trường DSCP II.3.2 Phân lớp lưu lượng ở mức lớp liên kết dữ liệu Trong phần mào đầu của khung dữ liệu ở lớp liên kết dữ liệu không có trường nào phục vụ cho việc phân lớp lưu lượng. Tuy nhiên ta có thể phân lưu lượng dựa vào việc chèn thêm các thẻ định danh VLAN gọi là tag theo giao thức 802.1Q/p. Mỗi tag gồm 4 byte trong đó trường CoS gồm 3 bit (cấu trúc chi tiết của tag được trình bày trong hình vẽ) được dùng để phân lớp lưu lượng. Như vậy tại mức liên kết dữ liệu chúng ta cũng có thể phân chia lưu lượng thành 8 lớp với các mức ưu tiên tăng dần tương tự như khi sử dụng IP Precedence tại lớp mạng của gói tin Hình 2.4: Cấu trúc tag trong khung dữ liệu 802.1Q/p Tóm lại, việc phân lớp lưu lượng dữ liệu có thể được thực hiện ở tầng data link hoặc network như mô tả trong hình II.4: Hình 2.5: Phân lớp dữ liệu trên 2 tầng network và datalink Mức độ ưu tiên ở cả 2 tầng đều được sắp xếp theo thứ tự từ thấp đến cao, 0 là giá trị thấp nhất, tương đương với không thiết lập độ ưu tiên cho gói dữ liệu và 7 là độ ưu tiên cao nhất. Giá trị DSCP (Differentiated Services Code Point ) không những dùng để phân lớp cho lưu lượng ưu tiên mà còn dùng để chỉ định khả năng rớt gói của phân lớp đó. Hình 2.6: Các giá trị DSCP và độ ưu tiên tương ứng Lớp cs là những giá trị ưu tiên gốc (pre-dating DSCP), lớp af (assured forwarding) được định nghĩa trong RFC 2597 và lớp ef (expedited forwarding) được định nghĩa trong RFC 2958. Ví dụ: lưu lượng thuộc lớp af33 sẽ có độ ưu tiên cao hơn lưu lượng thuộc lớp af21 nhưng khả năng mất gói lại lớn hơn lưu lượng thuộc lớp af31. II.4 Giải pháp QoS II.4.1 Mô hình dịch vụ cố gắng tối đa Đây là dịch vụ phổ biến trên mạng internet, dữ liệu đi vào mạng đều tuân theo quy tắc FIFO (First in first out). Không có sự đối xử nào của QoS đối với dữ liệu. Điều này dẫn đến rất khó hỗ trợ các dịch vụ đòi hỏi độ trễ thấp như các dịch vụ thời gian thực hay video. II.4.2 Mô hình tích hợp dịch vụ (Integrated Services – IntServ) Được ITEF giới thiệu vào giữa thập niên 90 với mục đích hỗ trợ chất lượng dịch vụ end-to-end, IntServ là kiến trúc hỗ trợ QoS cho các ứng dụng trên mạng internet. Tất cả các bộ định tuyến trên đường truyền của gói thông tin đầu-cuối phải được cài đặt IntServ để đảm bảo cung cấp chất lượng dịch vụ theo yêu cầu. Để thực hiện được điều đó, cần phải có một giao thức để ứng dụng thông báo yêu cầu QoS đến từng bộ định tuyến. Điều này được thực hiện bởi giao thức RSVP. Một ứng dụng sẽ xác định đặc tính của luồng lưu lượng mà nó đưa vào mạng đồng thời xác định một số yêu cầu về mức dịch vụ mạng. Đặc tính của lưu lương Tspec (Traffic Specification) yêu cầu mức chất lượng dịch vụ Rspec (Required Specification). Vì thế các bộ định tuyến phải có khả năng thực hiện các công việc sau: Kiểm soát (policing): kiểm tra TSpec của lưu lượng, nếu không phù hợp thì loại bỏ luồng. Điều khiển chấp nhận: kiểm tra xem tài nguyên mạng có đáp ứng được yêu cầu của ứng dụng hay không. Nếu không thể đáp ứng, mạng sẽ từ chối. Phân lớp (classification): phân loại dữ liệu căn cứ vào mức yêu cầu của chất lượng dịch vụ của gói Hàng đợi và lập lịch (queuing và scheduling): đưa gói dữ liệu vào hàng đợi tương ứng và quyết định hủy gói dữ liệu nào khi xảy ra xung đột. Các lớp dịch vụ: có 2 loại dịch vụ là đảm bảo dịch vụ (Guaranteed Service) và kiểm soát tải (control load service) Đảm bảo dịch vụ: Cho phép giới hạn thời gian chuyển tiếp các gói dữ liệu đến đích trong một khoảng thời gian nhất định, đảm bảo số dữ liệu không bị loại bỏ khi hàng đợi đầy. Thông tin Tspec phải bao gồm các thông số như: tốc độ đỉnh, kích thước lớn nhất của gói dữ liệu. Trong khi đó thông số quan trọng nhất của Rspec là tốc độ dịch vụ. Thông số này cho phép xác định băng thông mà lưu lượng cần khi đi trong mạng. Thông số này cùng với các thông số trong Rspec cho phép xác định thời gian trễ lớn nhất có thể chấp nhận được của dữ liệu. Nhược điểm của lớp dịch vụ này là hiệu quả sử dụng tài nguyên mạng thấp vì nó đòi hỏi mỗi luồng lưu lượng có hàng đợi riêng. Kiểm soát tải: Các ứng dụng của dịch vụ này có thể chấp nhận khả năng mất dữ liệu và thay đổi độ trễ ở một mức độ nhất định. Luồng dữ liệu khi đi vào mạng sẽ được kiểm tra đối chiếu với những đặc tả lưu lượng Tspec đã được đăng ký. Nếu không phù hợp với các đặc tả đã được đăng ký trước thì dữ liệu sẽ được chuyển tiếp theo phương thức “nỗ lực tối đa”. Giao thức dành trước tài nguyên RSVP RSVP là giao thức báo hiệu cung cấp thủ tục để thiết lập và điều khiển quá trình chiếm giữ tài nguyên, hay nói cách khác RSVP cho phép các chương trình ứng dụng thông báo cho mạng những yêu cầu về mức chất lượng dịch vụ; và mạng sẽ hồi đáp chấp nhận hoặc không chấp nhận yêu cầu đó. Các bản tin RSVP được các bộ định tuyến hay các bộ chuyển mạch 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 có 2 bản tin cơ bản: bản tin Path và bản tin Resv. Bản tin Path mang thông tin về đặc tả luồng lưu lượng Tspec và các thông tin như: địa chỉ IP của nút gửi, địa chỉ IP nút nhận, chỉ số cổng UDP. Và khi nhận được bản tin Path, nút mạng đích sẽ gửi lại bản tin Resv. Bản tin Resv sẽ gửi kèm theo phần mô tả yêu cầu RSpec chỉ định kiểu dịch vụ tích hợp là kiểm soát tải hay đảm bảo dịch vụ; ngoài ra còn có dấu hiệu nhận dạng luồng (flow descriptor) mà mỗi bộ định tuyến dùng để nhận diện mỗi phiên chiếm giữ tài nguyên. Khi nhận được bản tin Resv, mỗi bộ định tuyến trung gian sẽ tiến hành quá trình điều khiển chấp nhận (admission control). Nếu yêu cầu không được chấp nhận, do không đủ tài nguyên mạng thì bộ định tuyến sẽ báo lỗi về phía đầu thu. Nếu yêu cầu được chấp nhận thì bộ định tuyến sẽ gửi bản tin Resv đến bộ định tuyến đã gửi bản tin Path cho nó Hình 2.7: Mô hình INTSERV Bản tin thông báo lỗi và xác định lại (Error and confirmation message) Ba loại bản tin thông báo lỗi và xác định lại là : bản tin báo lỗi đường đi (path error message – Patherr), bản tin báo lỗi yêu cầu giành trước tài nguyên ( Reservation request error message – Resverr) và bản tin chấp nhận yêu cầu giành tài nguyên ( Reservation request Acknowledment message – Resvconf) Bản tin Patherr và Resverr được gởi ngược lại về phía người gửi đã tạo ra lỗi, nhưng chúng không mô tả trạng thái của đường đi mà chúng đi qua. Bản tin Patherr chỉ ra lỗi trong tiến trình xử lý trạng thái của đường đi và được gửi lại cho người gửi dữ liệu. Bản tin Resverr chỉ ra lỗi trong tiến trình xử lý yêu cầu giành tài nguyên và được gửi đến người nhận (Trong RSVP chỉ duy nhất người nhận mới có thể thiết lập một dòng dữ liệu RSVP) Các bản tin báo lỗi có thể bao gồm như sau: Admission failure Ambigous path Bandwidth unavailable Bad Flow specification Service not supported Teardown Message : được dùng để gỡ bỏ trạng thái giành tài nguyên và đường đi từ tất cả các nodes đang ở trạng thái giành tài nguyên. Teardown message có thể được khởi tạo từ node gửi hoặc node nhận hay một node bất kì nào đó trên đường đi của dòng dữ liệu. Có 2 loại teardown message được hỗ trợ bởi RSVP là : path teardown và reservation request teardown. Path teardown xóa bỏ trạng thái của bản tin path và các trạng thái giành tài nguyên được kết hợp trong đường đi của dòng dữ liệu. Reservation request teardown xóa bỏ trạng thái giành trước tài nguyên nhưng giữ lại đường đi của dòng dữ liệu đã được chỉnh sửa. Nguyên lý căn bản của mô hình IntServ là dành riêng tài nguyên mạng (băng thông, độ trễ…) cho từng luồng thông tin xuyên suốt từ nguồn đến đích. Tài nguyên này được chiếm dụng và không được tận dụng cho bất kỳ một luồng thông tin nào. Nếu tài nguyên bị chiếm dụng mà không dùng thì hiện tượng lãng phí tài nguyên sẽ xảy ra. Một đặc điểm nữa là mô hình IntServ đảm bảo chất lượng dịch vụ theo luồng (flow). Một luồng được xác định bởi các tham số: địa chỉ IP nguồn, IP đích, cổng nguồn, cổng đích… Khi một luồng được thiết lập thì tương ứng với 1 phiên RSVP được thiết lập, điều này dẫn đến một hạn chế là: đối với mạng có lưu lượng cao như mạng ISP hoặc các tổ chức doanh nghiệp lớn thì số lượng luồng có thể lên đến hàng trăm ngàn luồng trong một thời điểm và đẫn đến hiện tượng lãng phí tài nguyên do bandwidth sử dụng để thiết lập kênh RSVP lên rất nhiều (RSVP không phải là luồng thoại mà chỉ là thông tin điều khiển, báo hiệu). Hạn chế của mô hình IntServ với hệ thống mạng có số lượng lưu lượng lớn: Mặc dù InServ là mô hình đảm bảo chất lượng dịch vụ tuyệt đối từ đầu cuối đến đầu cuối (end-to-end), nhưng nó không linh hoạt và khả năng mở rộng thấp nên thường không được lựa chọn để thực hiện QoS trong mạng có quy mô lớn. Vì vậy mô hình IntServ chỉ thích hợp cho những mạng nhỏ với ít luồng lưu lượng. II.4.3 Mô hình phân biệt dịch vụ Mô hình DiffServ được thiết kế để khắc phục những hạn chế của mô hình InServ. Mô hình DiffServ có khả năng linh hoạt cao và khả năng mở rộng lớn. Thay vì thực hiện chất lượng dịch vụ xuyên suốt và thống nhất trên cả đường truyền như mô hình InServ, mô hình DiffServ thực hiện chất lượng dịch vụ riêng lẽ trên từng router, với cách thực hiện như vậy mô hình DiffServ không cần phải tiến hành báo hiệu theo từng luồng nên tiết kiệm băng thông và có khả năng mở rộng lớn rất phù hợp trong mô hình hệ thống mạng lớ