Đồ án Sử dụng giao thức RSVP (Resource reservation protocol) để ứng dụng trong mạng bị nghẽn

LỜI CẢM ƠN Em xin chân thành cảm ơn quý thầy cô Khoa Công Nghệ Thông Tin Trường Đại Học Kỹ Thuật Công Nghệ Thành Phố Hồ Chí Minh đã tận tình chỉ dạy, truyền đạt kinh nghiệm cho chúng em trong những học kỳ vừa qua. Em trân trọng gửi lòng biết ơn đến thầy Văn Thiên Hoàng là người đã tận tình hướng dẫn, luôn cởi mở nhiệt tình giúp em định hướng và thực hiện đề tài này. Em cũng xin gửi lời cảm ơn đến cha, mẹ người đã sinh ra và nuôi dưỡng em đến ngày hôm nay. Xin cảm ơn anh, em trong gia đình, những người luôn sẽ chia, và động viên em trong lúc thực hiện đề tài. Xin cảm ơn những người bạn luôn kề bên giúp đỡ, hỗ trợ em để hoàn thành đề tài này. Vì điều kiện thời gian không nhiều, kinh nghiệm còn thiếu, không tránh được những thiếu sót khi thực hiện đồ án. Em mong nhận được các ý kiến đóng góp của thầy cô và các bạn để rút ra những kinh nghiệm quí báo đế áp dụng cho cuộc sống sau này. Sinh viên thực hiện Nguyễn Minh Huy MỤC LỤC PHỤ LỤC HÌNH ẢNH 5 DANH MỤC VIẾT TẮT 7 MỞ ĐẦU 8 CHƯƠNG 1 TỔNG QUAN QOS 10 1.1 Khái quát 10 1.1.1.Giới thiệu 11 1.2. Các mô hình Qos 11 1.2.1. Best-Effort Delivery 11 1.2.2. Integrate Services Model 11 1.2.3 Differentiated Services Model 11 1.1.3. Cơ chế thực hiện QoS 12 1.2. Dịch vụ IntServ 14 1.2.1. Các lớp dịch vụ 15 1.2.1.1. Đảm bảo dịch vụ 15 1.2.1.2. Kiểm soát tải 16 1.2.2. Kiến trúc IntServ 16 1.3. Mô hình Intserv 18 1.4. Ưu và nhược điểm 19 1.4.1 Ưu điểm 19 1.4.2Nhược điểm 19 CHƯƠNG 2: GIAO THỨC RSVP TRÊN NỀN VPN 20 2.1. Giới thiệu 20 2.2. Giao thức RSVP 21 2.2.1. Chức năng RSVP 21 2.2.1.1. Các lớp đối tượng RSVP 21 2.2.1.2. Common Header 23 2.2.2. Các gói tin RSVP 24 2.2.2.1. Path Message 25 2.2.2.2. Resv Massage 26 2.2.2.3. PathTear Massage 27 2.2.2.4. ResvTear 28 2.2.2.5. Path Error 28 2.2.2.6. ResvError 26 2.2.2.7. ResvConf 29 2.2.3. Teardown 30 2.2.4. Các lỗi trong đường truyền 31 2.2.5. Cơ chế chứng thực 31 2.2.6. Bảo mật trong RSVP 32 2.2.7. Non RSVP clouds 33 2.2.8. Các host mẫu 34 2.3. Các thành phần cơ bản trong giao thức RSVP 35 2.3.1. Định dạng gói tin 35 2.3.2. Các port được sử dụng trong giao thức 35 2.3.3. Gửi gói tin RSVP 36 2.3.4. Các gói tin báo loops 37 2.3.5. Các thông số thời gian 39 2.3.6. Ứng dụng RSVP giao diện 39 3.1.VPN 44 3.1.1. Giới thiệu 44 3.1.2. VPN site to site 44 3.1.3. Tính bảo mật của VPN 45 CHƯƠNG 3: PHÂN TÍCH GÓI TIN 48 3.1. Path Message 48 3.2. Path Tear Message 51 3.3. RESV Massege 54 3.4. RESV ERROR 57 3.5 RESV Tear Massage 59 CHƯƠNG 4 THỰC NGHIỆM ỨNG DỤNG RSVP TRONG QOS.60 4.1. Code cấu hình 60 4.2. Thực nghiệm 63 4.2.1. Mục tiêu thực nghiệm 63 4.2.2. Thực nghiệm 63 4.2.2.1. Mô hình 63 4.2.2.2.Mô tả 64 4.3.Các bước thực hiện 65 Kết luận 78 Hướng phát triển đề tài 78 Tài liệu tham khảo 79 PHỤ LỤC HÌNH ẢNH Hình 1: Mô hình Insert 19 Hình 2: RSVP trong hosts và Routers 21 Hình 3: Router sử dụng giao thức RSVP. 25 Hình 4: Gói Path Meesage . 49 Hình 5: Gói Path Tear Massage . 52 Hình 6: Gói RESV Message 55 Hình 7: Gói RESV Error 58 Hình 8: Mô hình thực nghiệm 64 Hình 9: Telnet RSVPSender 66 Hình 10: Telnet RSVPRouter. 67 Hình 11: Telnet RSVPReservation 67 Hình 12: Bandwidth của RSVPSender 68 Hình 13: Bandwidth của RSVPRouter. 68 Hình 14 Bandwidth của RSVPReservation 69 Hình 15 Cài đặt RSVPSender 69 Hình 16 Cài đặt RSVPRouter 70 Hình 17: Kết quả của RSVPReservation 70 Hình 18 Show ip RSVPSender 70 Hình 19 show ip rsvp reservation của RSVPReservation. 71 Hình 20 show ip rsvp request detail của RSVPSender. 71 Hình 21 các RSVP. 71 Hình 22 debug ip RSVP. 72 Hình 23 debug ip RSVP Path. 73 Hình 24 debug ip RSVP Traffic control. 74 Hình 25-1 Giao diện VPN khi up từ Sender đến Reservation. 73 Hình 25-2 Thông số của map trong Sender 74 Hình 26 NetMeeting 75 Hình 27 gói tín hiệu voice truyền từ pc1 đến pc 2 chưa áp dụng RSVP 76 Hình 28 lưu lượng truyền qua RSVPSender 76 Hình 29 gói tín hiệu voice truyền đã áp RSVP 77 Hình 30 lưu lương qua RSVPSender khi áp RSVP……………………………………77 Danh mục viết tắt Viết tắt Tiếng Anh Tiếng Việt ATM Aysnchronous Transfer Mode Phương thức truyền tin không đồng bộ IP Internet Protocol Giao thức Internet LAN Local Area Network Mạng cục bộ NGN Next Generation Network Mạng thế hệ sau RSVP Resource Reservation Protocol Giao thức giành tài nguyên TCP Transport Control Protocol Giao thức điều khiển truyền tải TDP Tag Distribution Protocol Giao thức phân bố thẻ ToS Type of Service Kiểu dịch vụ UDP User Datagram Protocol Giao thức điều khiển truyền thông không hướng kết nối qua mạng IP VPN Virtual Private Network Mạng riêng ảo WAN Wide Area Network Mạng diện rộng TTL Time To Live Thời gian sống của gói tin  QoS Quality of Service Chất lượng dịch vụ  MỞ ĐẦU 1. Giới thiệu RSVP trên nền QoS (Resource reservation protocol - Quality of Service) là một công nghệ xử lý gói ưu tiên. Về bản chất, QoS cho phép bạn xử lý các gói thông tin nhạy cảm với mức ưu tiên cao hơn các gói khác. Trong số các ứng dụng của mạng có các ứng dụng thời gian thực và ứng dụng không thời gian thực. 2. Mục tiêu đề tài: Mục tiêu đề tài là sử dụng giao thức RSVP (Resource reservation protocol) để ứng dụng trong mạng bị nghẽn. Cho thấy rõ tính hiệu quả của giao thức RSVP trong công nghệ mạng bị nghẽn khi mà ngày nay chất lượng dịch vụ ngày càng đòi hỏi cao. Đề tài sử dụng ứng dụng có sẵn Netmeeting trong hệ điều hành windows XP để gọi,gửi nhận file,video…Qua đó vai trò của giao thức RSVP ngày càng quan trọng đối với cơ sở hạ tầng mạng. Cạnh đó thấy rõ được tính hiệu quả to lớn của QoS như thế nào khi mà giao thức RSVP chỉ là phần nhỏ của ứng dụng QoS. Vì vậy đề tài này giúp ta hiểu rõ cách cấu hình, cài đặt trên các ứng dụng có sẵn (Netmeeting) và các phần mềm tiện ích giả lập (GNS3). Mục tiêu đề tài nhằm vào các vấn đề sau: Tìm hiểu các khái niệm về giao thức RSVP. Tìm hiểu giao thức RFC trong RSVP. Thiết lập và cài đặt. Đồ án sử dụng mô hình hai máy PC kết nối với nhau thông qua Netmeeting để gọi, gửi nhận file cũng như video…Đây chỉ là một phần nhỏ của giao thức để ta thấy được phần nào tầm quan trọng của giao thức RSVP cho cơ sở hạ tầng mạng khi mà thời đại công nghệ thông tin ngày càng phát triển đòi hỏi chất lượng dịch vụ tốt hơn và nhanh chóng hơn. 3. Cấu trúc đề tài: Gồm 4 chương: Chương 1: Tổng quang QOS Chương 2: Giao thức RSVP Chương 3: Phân tích gói tin RSVP Chương 4: Thực nghiệm ứng dụng RSVP trên QOS Chương 1 Tổng quan về QoS 1.1. Khái quát 1.1.1 Giới thiệu Cisco cung cấp nhiều yếu tố QoS trong phần mềm Cisco IOS. Khi nhắc đến đến QoS, chúng ta nhanh chóng nghĩ rằng đó là các kỹ thuật hàng đợi khác nhau, như hàng đợi cân bằng có trọng số hay hàng đợi thông thường (Custom Queuing). Các yếu tố QoS còn chứa nhiều loại hơn nữa, yếu tố phân mảnh và chèn, nén, policing (kiểm soát) và định dạng, yếu tố loại gói có chọn lựa và một vài yếu tố khác. Và trong mỗi phương pháp QoS còn có nhiều tùy chọn. Nguyên nhân thành công của giao thức IP chính là sự đơn giản của nó. Mọi tính năng phức tạp được cài đặt tại đầu cuối mạng còn mạng lõi thì đơn giản. Bộ định tuyến trong mạng sẽ căn cứ vào địa chỉ IP và các nút trong mạng để tìm nút mạng kế tiếp được nhận gói. Nếu hàng đợi dành cho nút mạng kế tiếp quá dài, thời gian trễ của gói dữ liệu sẽ lớn. Nếu hàng đợi đầy không còn chỗ trống gói dữ liệu sẽ bị hủy. Như vậy, mạng IP chỉ cung cấp mô hình dịch vụ “nỗ lực tối đa ” best effort service_có nghĩa là mạng sẽ khai thác hết khả năng trong giới hạn cho phép, nhưng không đảm bảo độ trễ và mất mát dữ liệu. Vì vậy, khi có nhiều luồng lưu lượng truyền đi trong mạng và vượt quá khả năng của mạng, dịch vụ không bị từ chối nhưng chất lượng dịch vụ giảm: thời gian trễ tăng, tốc độ giảm và mất dữ liệu. Do đó, mạng IP không thích hợp với những ứng dụng yêu cầu thời gian thực. Ngoài ra, với thông tin đa điểm (multicast) đồng thời phục vụ hàng triệu khách hàng thì hiện nay mạng IP không thực hiện được. Nếu có thể triển khai tốt thông tin quảng bá có thể tích hợp phát thanh truyền hình vào mạng IP. Sự ra đời các giao thức chất lượng dịch vụ QoS cung cấp cho mạng các tính năng giúp mạng có thể phân biệt được các lưu lượng có đòi hỏi thời gian thực với các lưu lượng có độ trễ, mất mát hay độ biến động trễ (jitter). Băng thông sẽ được quản lý và sử dụng hiệu quả để có thể đáp ứng những yêu cầu về chất lượng của các luồng lưu lượng. Mục tiêu của QoS là cung cấp một số mức dự báo và điều khiển lưu lượng. 1.1.2 Các mô hình QoS 1.1.2.1. BEST-EFFORT DELIVERY: Một network chỉ đơn thuần forward những packets mà nó nhận được. Switch và routers chỉ cố gắng hết sức (best-effort) để forward packets đi mà không bận tâm đến kiểu của traffic hay độ ưu tiên của dịch vụ. 1.1.2.2. INTEGRATED SERVICE MODEL Sắp xếp đường đi trước từ nguồn đến đích cho các dữ liệu được ưu tiên. RSVP (RFC 1633) là một protocol dạng này. RSVP sẽ yêu cầu trước băng thông và giữ (reserve) bw trên cả đường đi từ nguồn đến đích. Mỗi thiết bị mạng trên đường đi phải kiểm tra xem nó có thể hỗ trợ cho yêu cầu trên hay không. Khi yêu cầu tối thiểu được đáp ứng, ứng dụng nguồn sẽ được thông báo xác nhận. Sau đó, ứng dụng có thể sử dụng đường truyền. 1.1.2.3. DIFFERENTIATED SERVICES MODEL Giải pháp IntServ tỏ ra không hiệu quả và không có khả năng mở rộng khi nhiều source phải cạnh tranh với nhau về băng thông. Trong giải pháp differentiated, mỗi routers và switch sẽ quản lý packets riêng lẻ. Mỗi routers sẽ có một chính sách riêng để quản lý và sẽ tự quyết định cách thức chuyển packet theo cách riêng. IntServ sẽ quản lý theo kiểu per-flow, trong khi Difserv sẽ quản lý theo kiểu per-hop.Diffserv sẽ quyết định chính sách QoS dựa vào cấu trúc của gói IP. Course switching sẽ tập trung vào Diffserv. 1.1.3. Cơ chế hỗ trợ cho các ứng dụng thời gian thực trong mạng hỗn hợp cố định và di động: Một trong những nhu cầu của người dùng dịch vụ và ứng dụng hiện nay là có thể dễ dàng sử dụng dịch vụ, ứng dụng truyền thông mọi lúc mọi nơi và nhất là khi di chuyển giữa các mạng có dây và không dây. Mạng thế hệ sau (Next Generation Network - NGN) đang tiếp tục phát triển hướng tới hội tụ các loại mạng. Nhân tố cơ bản đằng sau NGN là sự hội tụ của mạng cố định và không dây, hội tụ đa dạng dịch vụ với những yêu cầu rất khác nhau về lưu lượng và chất lượng dịch vụ. Kiến trúc mạng NGN bao gồm nhiều chủng loại công nghệ mạng khác nhau. Ngoài những công nghệ truyền thống đã có thêm nhiều công nghệ mạng mới cố định và không dây như WLAN, xDSL và các mạng di động 2G/3G, vv. Không chỉ hội tụ về mặt công nghệ, NGN còn đặc trưng qua sự hội tụ của dịch vụ và ứng dụng. Dựa trên nền tảng công nghệ IP (Internet Protocol), NGN có thể tận dụng được nguồn các ứng dụng tiềm tàng đang có và ngày càng được phát triển nhiều trên Internet. Trong số các ứng dụng của mạng hội tụ có ứng dụng thời gian thực và ứng dụng không thời gian thực. Các ứng dụng thời gian thực như dòng Video (Video Streaming), thoại qua IP (VoIP), IPTV, đa phương tiện (Multimedia), tương tác (Interactive), v.v, có những yêu cầu khắt khe và đa dạng về lưu lượng và chất lượng dịch vụ, đang đặt ra những thách thức mới cho cơ sở hạ tầng mạng. Mặt khác môi trường mạng di động và mạng cố định có những đặc tính hết sức khác nhau. Hỗ trợ các ứng dụng thời gian thực trong ngữ cảnh hội tụ mạng cố định – di động là một vấn đề nan giải đặt ra đối với việc phát triển NGN. Một câu hỏi đặt ra là cần xem xét và có phương án gì để đảm bảo chất lượng dịch vụ cho các ứng dụng thời gian thực trong môi trường mạng hỗn hợp đó. Theo tốc độ dữ liệu được yêu cầu, trễ có thể chấp nhận được và tỷ lệ tổn thất, có thể phân loại các ứng dụng như sau: - Loại 1: Các ứng dụng băng thông thấp nhạy cảm với trễ. Yêu cầu của Loại 1 là thời gian thực, băng thông thấp và tỷ lệ tổn thất có thể chấp nhận được, ví dụ như thoại tiếng nói, thoại hội nghị. Tốc độ dữ liệu trải từ 8 Kbit/s đến 128 Kbit/s. Tỷ lệ tổn thất có thể chấp nhận được là 10-4. Trễ tối đa khoảng 40 ms. - Loại 2: Các ứng dụng băng thông cao nhạy cảm với trễ. Loại 2 yêu cầu dịch vụ thời gian thực và băng thông cao, ví dụ như điện thoại thấy hình, hội nghị truyền hình, thoại qua IP (VoIP), âm thanh với chất lượng CD. Tốc độ dữ liệu từ 176 Kbit/s đến 768 Kbit/s. Trễ có thể chấp nhận từ 40 ms đến 90 ms. Loại 1 và Loại 2 thuộc về các ứng dụng thời gian thực, có đặc điểm là yêu cầu các đặc tính về trễ (transfer delay, delay jitter…) rất khắt khe. Nếu những đặc tính về trễ đó không được đảm bảo, chất lượng dịch vụ không thể chấp nhận được. - Loại 3: Các ứng dụng băng thông cao chấp nhận trễ. Loại này cũng yêu cầu dịch vụ thời gian thực nhưng chỉ cần các giới hạn trễ thống kê. Các ứng dụng thuộc loại này phát ra các dòng dữ liệu băng thông cao, ví dụ như video tốc độ bit thay đổi, dòng video, mua hàng từ xa, v.v. - Loại 4: Các ứng dụng băng thông thấp có thể chấp nhận trễ. Các ứng dụng của loại này có đặc điểm là yêu cầu băng thông thấp và trễ có thể chấp nhận được. Ví dụ về những ứng dụng này là SMS, nhắn tin (paging), thư thoại, thư điện tử, dữ liệu và tin báo tương tác. Các ứng dụng này không yêu cầu giới hạn về trễ truyền, nhưng mong muốn thời gian đáp ứng trong khoảng thời gian nào đó, điển hình là khoảng 100 ms. - Loại 5: Các ứng dụng băng thông cao không nhạy cảm với trễ. Các ứng dụng băng thông cao không nhạy cảm với trễ là các ứng dụng phi thời gian thực. Các ví dụ của Loại 5 là nền tảng chuyển tải thư điện tử, tải xuống các tệp và cơ sở dữ liệu, v.v. Các ứng dụng này có đặc điểm là tỷ lệ lỗi bit rất thấp.  Các dòng lưu lượng của các ứng dụng này được ghép kênh thống kê và chia sẻ các tài nguyên chung của mạng. Đưa tất cả các dịch vụ vào dịch vụ mang chung được xem là lợi thế chủ yếu của các mạng không dây thế hệ sau, nhưng sự tích hợp này sẽ tạo nên những thách thức mới về kỹ thuật cho các hệ thống lớp dưới. Đó cũng là nhu cầu có tính quyết định cho các chiến lược phát triển để hợp nhất hiệu quả các loại lưu lượng này. Như đã phân tích ở trên, đa số các loại hình dịch vụ đều có những yêu cầu nhất định về chất lượng dịch vụ (thể hiện qua các đặc tính về trễ, tỉ lệ lỗi bit…), đặc biệt là các ứng dụng thời gian thực. Vì thế, nghiên cứu phát triển các giải pháp hỗ trợ các ứng dụng thời gian thực (cũng là các ứng dụng đa phương tiện) và các cơ chế điều khiển nhằm đáp ứng các mục tiêu về hiệu năng cho các loại lưu lượng khác nhau trong khi cho phép sử dụng hiệu quả tài nguyên mạng là những thách thức và nhu cầu cấp thiết. Bên cạnh đó, tính đa dạng trong phương thức xử lý lưu lượng cho các ứng dụng nêu trên cũng như đặc tính hỗn hợp của mạng hội tụ cũng là những thách thức đối với việc đảm bảo chất lượng dịch vụ cho các ứng dụng thời gian thực.  Xuất phát từ cơ sở khoa học và nhu cầu thực tế nêu trên, bài báo đặt vấn đề nghiên cứu tìm ra giải pháp hỗ trợ các ứng dụng thời gian thực cho mạng hỗn hợp cố định – di động. Mục tiêu hướng tới của bài báo là đưa ra mô hình hệ thống và một cơ chế điều khiển hỗ trợ ứng dụng thời gian thực cùng với những phân tích và đánh giá và thử nghiệm, giúp cho triển khai dịch vụ, quản lý mạng và hỗ trợ, cung cấp các dịch vụ, ứng dụng thời gian thực với chất lượng tốt cho người dùng mạng. 1.2. Dịch vụ IntServ: Mô hình IntServ được IETF 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ụ từ đầu cuối tới đầu cuối. Các ứng dụng sẽ nhận được băng thông đúng yêu cầu và truyền đi trong mạng với độ trễ cho phép. Trên thực tế giao thức RSVP là giao thức duy nhất dùng để báo hiệu cho mô hình IntServ. Vì thế đôi khi người ta lầm lẫn dùng RSVP để nói về IntServ. Thật ra, IntServ là kiến trúc hỗ trợ chất lượng dịch vụ mạng, còn RSVP là giao thức báo hiệu cho IntServ. Ngoài giao thức báo hiệu, mô hình tích hợp dịch vụ còn định nghĩa thêm một số lớp dịch vụ. 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 luồng 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 gói dữ liệu căn cứ vào mức yêu cầu chất lượng dịch vụ của gói. • Hàng đợi và lập lịch (queuing and 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. 1.2.1. Các lớp dịch vụ: Có hai loại dịch vụ: đảm bảo dịch vụ (Guaranteed Service) và kiểm soát tải (Control load service). 1.2.1.1 Đả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. 1.2.1.2. 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”. 1.2.2. Kiến trúc Intserv Kiến trúc Intserv mô phỏng lại như mạng chuyển mạch kênh trước đây, nó sử dụng nguyên tắc đặt chỗ trước dùng giao thức RSVP. Nó hướng việc giám sát QoS theo luồng (flow) nghĩa là các kênh truyền được thiết lập và giám sát trong quá trình hoạt động. Intserv yêu cầu các ứng dụng đưa ra các tham số cho phiên liên lạc thông qua yêu cầu phục vụ. Intserv được đề cập trong RFC 1633, RFC 2212, và RFC 2215. Trong Kiến trúc Intserv, giữa các đầu cuối liên lạc phải tồn tại giao thức trao đổi định tài nguyên nên phải xử lý qúa nhiều làm cho nó khó có khả năng mở rộng để thích hợp với mạng lõi (nhất là mạng core là internet).  Intserv đã định nghĩa những đòi hỏi cho quá trình QoS để thỏa mãn hai mục đích: Để phục vụ các ứng dụng thời gian thực. Để điều khiển việc chia sẽ băng thông giữa các cấp độ lưu lượng khác nhau Hai kiểu dịch vụ đã được định nghĩa tuân theo kiến trúc Intserv: Dịch vụ bảo đảm (Guaranteed Service) và dịch vụ tải được điều khiển (Controlled load Service), cả hai đều tập trung vào những đòi hỏi ứng dụng riêng lẻ. Dịch vụ đảm bảo được định nghĩa để cung cấp mức độ chắc chắn của băng thông, một biên trễ đầu cuối-đầu không đổi, không mất hàng đợi và nó dự kiến cho ứng dụng thời gian thực như thoại và video. Định nghĩa dịch vụ tải được điều khiển không bao gồm bất kì một sự đảm bảo chất lượng chắc chắn nhưng nó đúng hơn là “một sự xuất hiện của một mạng tải nhẹ”. Nó dự định dành cho các ứng dụng mà có thể dùng sai trong một khoảng giới hạn lượng mất mát và trễ, bao gồm các ứng dụng thời gian thực thích nghi. Để có thể đạt được các mục tiêu đã đề ra và cung cấp các dịch vụ dự kiến, mô hình Intserv bao gồm rất nhiều các tham số lưu lượng như tốc độ và giới hạn chúng (slack term) cho dịch vụ đảm bảo, tốc độ trung bình và kích cỡ bùng nổ (burst sie) cho dịch vụ tải được điều khiển. Để thiết lập giá trị những tham số này trong một mạng và để cung cấp dịch vụ đảm bảo cho lưu lượng thời gian thực, RSVP được phát triển như giao thức báo hiệu cho việc dành sẵn. Kiến trúc Intserv đã thỏa mãn cả hai điều kiện cho mạng QoS.Nó cung cấp băng thông thích hợp và tài nguyên hàng đợi cho mỗi luồng ứng dụng. Tuy nhiên triển khai Intserv với RSVP đòi hỏi trạng thái mỗi vi