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

-1-

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.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-

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

-4-

.................................................................................................PHỤ LỤC HÌNH ẢNH Hình 1: Mô hình Insert..........................................................................................55 Hình 7: Gói RESV Error .......................69 Hình 15 Cài đặt RSVPSender ...............................................................58 Hình 8: Mô hình thực nghiệm ...............................................................................71 Hình 22 debug ip RSVP.....................................................................68 Hình 13: Bandwidth của RSVPRouter........................................................................................................49 Hình 5: Gói Path Tear Massage ............................................................................ ................................................................................ 19 Hình 2: RSVP trong hosts và Routers ............................66 Hình 10: Telnet RSVPRouter.................................................................................................................................. ........................................................................................................................................ 67 Hình 12: Bandwidth của RSVPSender .....................................................................................................69 Hình 16 Cài đặt RSVPRouter ..67 Hình 11: Telnet RSVPReservation....... .........................................................64 Hình 9: Telnet RSVPSender ..................................................70 Hình 17: Kết quả của RSVPReservation ......68 Hình 14 Bandwidth của RSVPReservation ..................71 Hình 20 show ip rsvp request detail của RSVPSender...................................................74 -5- ....52 Hình 6: Gói RESV Message ...................................................................................................................................................................................................................................................................................................21 Hình 3: Router sử dụng giao thức RSVP.........................................................72 Hình 23 debug ip RSVP Path............................................................................................................................................25 Hình 4: Gói Path Meesage .........................70 Hình 19 show ip rsvp reservation của RSVPReservation.................................. ..........................................................................................................................73 Hình 24 debug ip RSVP Traffic control............................................................ ........... ..............71 Hình 21 các RSVP.............................70 Hình 18 Show ip RSVPSender ......................

.................................................74 Hình 26 NetMeeting ................................................................................................................Hình 25-1 Giao diện VPN khi up từ Sender đến Reservation.......................................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 -6- .......76 Hình 28 lưu lượng truyền qua RSVPSender ........................................................................75 Hình 27 gói tín hiệu voice truyền từ pc1 đến pc 2 chưa áp dụng RSVP ..73 Hình 25-2 Thông số của map trong Sender...............................................................................

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ụ -7- .

Về bản chất. 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 -8- . 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.gửi nhận file. Vì vậy đề tài này giúp ta hiểu rõ cách cấu hình. 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. 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). 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. 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. 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. 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.Quality of Service) là một công nghệ xử lý gói ưu tiên. Đồ án sử dụng mô hình hai máy PC kết nối với nhau thông qua Netmeeting để gọi. Đề tài sử dụng ứng dụng có sẵn Netmeeting trong hệ điều hành windows XP để gọi. Giới thiệu RSVP trên nền QoS (Resource reservation protocol . • Tìm hiểu giao thức RFC trong RSVP. • Thiết lập và cài đặt.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. 2.MỞ ĐẦU 1.

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. 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 -9- . 3.

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. Khi nhắc đến đến QoS. thời gian trễ của gói dữ liệu sẽ lớn. 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. Do đó. 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. yếu tố loại gói có chọn lựa và một vài yếu tố khác. Nguyên nhân thành công của giao thức IP chính là sự đơn giản của nó. tốc độ giảm và mất dữ liệu. Nếu hàng đợi dành cho nút mạng kế tiếp quá dài. 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ễ. như hàng đợi cân bằng có trọng số hay hàng đợi thông thường (Custom Queuing). nhưng không đảm bảo độ trễ và mất mát dữ liệu. Như vậy. Băng thông sẽ được . mất mát hay độ biến động trễ (jitter).1. yếu tố phân mảnh và chèn. 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. policing (kiểm soát) và định dạng. Nếu hàng đợi đầy không còn chỗ trống gói dữ liệu sẽ bị hủy. 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. 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. chúng ta nhanh chóng nghĩ rằng đó là các kỹ thuật hàng đợi khác nhau. 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.10 - . Khái quát 1. Các yếu tố QoS còn chứa nhiều loại hơn nữa.1. 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én. Ngoài ra. Và trong mỗi phương pháp QoS còn có nhiều tùy chọn. Vì vậy.1 Giới thiệu Cisco cung cấp nhiều yếu tố QoS trong phần mềm Cisco IOS.Chương 1 Tổng quan về QoS 1.

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.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. trong khi Difserv sẽ quản lý theo kiểu per-hop. Course switching sẽ tập trung vào Diffserv. Trong giải pháp differentiated.Diffserv sẽ quyết định chính sách QoS dựa vào cấu trúc của gói IP.1.2. 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.3. 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.1. 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. 1. 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.11 - . 1. . 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. ứng dụng có thể sử dụng đường truyền. ứng dụng nguồn sẽ được thông báo xác nhận. BEST-EFFORT DELIVERY: Một network chỉ đơn thuần forward những packets mà nó nhận được. RSVP (RFC 1633) là một protocol dạng này. 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. 1.2 Các mô hình QoS 1. IntServ sẽ quản lý theo kiểu per-flow.2. Sau đó.2.1. mỗi routers và switch sẽ quản lý packets riêng lẻ.

1.1. 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ụ. Không chỉ hội tụ về mặt công nghệ. 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.3. 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ụ. Mạng thế hệ sau (Next Generation Network .12 - . Các ứng dụng thời gian thực như dòng Video (Video Streaming). IPTV. v. tương tác (Interactive). 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ụ. xDSL và các mạng di động 2G/3G.v. Theo tốc độ dữ liệu được yêu cầu. đang đặt ra những thách thức mới cho cơ sở hạ tầng mạng. trễ có thể chấp nhận được và tỷ lệ tổn thất. 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 đó. thoại qua IP (VoIP). 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. 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. Dựa trên nền tảng công nghệ IP (Internet Protocol). NGN còn đặc trưng qua sự hội tụ của dịch vụ và ứng dụng. đa phương tiện (Multimedia). ứ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.NGN) đang tiếp tục phát triển hướng tới hội tụ các loại mạng. vv. 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. Kiến trúc mạng NGN bao gồm nhiều chủng loại công nghệ mạng khác nhau. có thể phân loại các ứng dụng như sau: . 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.

Trễ tối đa khoảng 40 ms. Ví dụ về những ứng dụng này là SMS. nhắn tin (paging). 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. điển hình là khoảng 100 ms. thư điện tử. thư thoại. Tỷ lệ tổn thất có thể chấp nhận được là 10-4. ví dụ như điện thoại thấy hình. tải xuống các tệp và cơ sở dữ liệu. Tốc độ dữ liệu từ 176 Kbit/s đến 768 Kbit/s.13 - . nhưng mong muốn thời gian đáp ứng trong khoảng thời gian nào đó. 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.Loại 4: Các ứng dụng băng thông thấp có thể chấp nhận trễ. Nếu những đặc tính về trễ đó không được đảm bảo. dòng video.v. . có đặc điểm là yêu cầu các đặc tính về trễ (transfer delay. ví dụ như video tốc độ bit thay đổi. thoại qua IP (VoIP). Các ví dụ của Loại 5 là nền tảng chuyển tải thư điện tử. mua hàng từ xa. v.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 này có đặc điểm là tỷ lệ lỗi bit rất thấp. thoại hội nghị. Yêu cầu của Loại 1 là thời gian thực. 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. delay jitter…) rất khắt khe. . . Loại 1 và Loại 2 thuộc về các ứng dụng thời gian thực. Trễ có thể chấp nhận từ 40 ms đến 90 ms. Đư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. dữ liệu và tin báo tương tác..v. 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ê.Loại 1: Các ứng dụng băng thông thấp nhạy cảm với trễ.Loại 3: Các ứng dụng băng thông cao chấp nhận trễ. v. hội nghị truyền hình. băng thông thấp và tỷ lệ tổn thất có thể chấp nhận được. .Loại 2: Các ứng dụng băng thông cao nhạy cảm với trễ. nhưng sự tích hợp này sẽ tạo . âm thanh với chất lượng CD. Tốc độ dữ liệu trải từ 8 Kbit/s đến 128 Kbit/s. chất lượng dịch vụ không thể chấp nhận được. Các ứng dụng này không yêu cầu giới hạn về trễ truyền. 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ư thoại tiếng nói. Loại 2 yêu cầu dịch vụ thời gian thực và băng thông cao.

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. Vì thế đôi khi người ta lầm lẫn dùng RSVP để nói về IntServ. cung cấp các dịch vụ. tỉ lệ lỗi bit…).nên những thách thức mới về kỹ thuật cho các hệ thống lớp dưới.2. 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. 1. 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. Đó 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. 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. giúp cho triển khai dịch vụ. đặc biệt là các ứng dụng thời gian thực. đ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ễ. 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. 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. quản lý mạng và hỗ trợ. Thật . Như đã phân tích ở trên. Vì thế.14 - . ứng dụng thời gian thực với chất lượng tốt cho người dùng mạng.

mạng sẽ từ chối. kích thước lớn nhất của gói dữ liệu. Thông tin Tspec phải bao gồm các thông số như: tốc độ đỉnh.2.1. Đặ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). 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ụ. Trong khi đó thông số quan trọng nhất của Rspec là tốc độ dịch vụ.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. 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 thể đáp ứng. 1. . còn RSVP là giao thức báo hiệu cho IntServ. 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. • 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.2. đảm bảo số dữ liệu không bị loại bỏ khi hàng đợi đầy. • 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. • Đ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 phù hợp thì loại bỏ luồng. IntServ là kiến trúc hỗ trợ chất lượng dịch vụ mạng. 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.1. Ngoài giao thức báo hiệu.ra.15 - .

Intserv được đề cập trong RFC 1633. 1. 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.2. 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. 1. 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ụ.2. nó sử dụng nguyên tắc đặt chỗ trước dùng giao thức RSVP. và RFC 2215.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. RFC 2212. 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”. 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. 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.2. 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.16 - . Trong Kiến trúc Intserv.1.2. • Để đ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 . 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).

. bao gồm các ứng dụng thời gian thực thích nghi. Đị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ẹ”. Kiến trúc Intserv đã thỏa mãn cả hai điều kiện cho mạng QoS. 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.17 - . Nó thêm sự phức tạp đáng kể đối với việc vận hành mạng và không linh hoạt. Tuy nhiên triển khai Intserv với RSVP đòi hỏi trạng thái mỗi vi luồng và báo hiệu ở mỗi chặn.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ó thể đạt được các mục tiêu đã đề ra và cung cấp các dịch vụ dự kiến. và IETF đã chuyển sang hướng phát triển Diffserv thay thế và sự phức tạp tối thiểu. Vì thế mô hình Intserv chỉ được triển khai ở một số hữu hạn mạng. 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.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. 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ễ. 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. • 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. Để 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. cả hai đều tập trung vào những đòi hỏi ứng dụng riêng lẻ. một biên trễ đầu cuối-đầu không đổi.

Một vài ứng dụng như là: thoại.3.18 - . Mô hình Intserv Hình 1: Mô hình Intserv.1. ứng dụng giao tiếp thời gian thực…đòi hỏi băng thông cố định và dành riêng và vào đầu những năm 1990s mô hình InServ được giới thiệu để giải quyết vấn đề căn bản trên mạng IP này. 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 . Nguyên lý căn bản của mô hình InServ 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. hội nghị truyền hình.

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. 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. cổng đích…. cổng nguồn. đ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. 1. .1. IP đích. Một luồng được xác định bởi các tham số: địa chỉ IP nguồn. cổng đích…. Hạn chế của mô hình IntServ với hệ thống mạng có số lượng flow lớn. IP đích. báo hiệu). cổng nguồn. 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.4. Một luồng được xác định bởi các tham số: địa chỉ IP nguồn.4.InServ sử dụng giao thức RSVP (Resource Reservation Protocol) để báo hiệu. từ đầu cuối đến đầu cuối (end-to-end). Ví dụ ta dành riêng 2Mbps cho thoại thì chỉ có gói tin thoại mới có thể sử dụng nguồn tài nguyên này. Mặc dù InServ là mô hình đảm bảo chất lượng dịch vụ tuyệt đối.tin nào.InServ sử dụng giao thức RSVP (Resource Reservation Protocol) để báo hiệu. Ưu và khuyết điểm 1.19 - . mặc dù có khi không có một gọi nào qua mạng thì tài nguyên này vẫn được dành riêng và không luồng thông tin dữ liệu có thể chiếm dụng khoảng tài nguyên này Một đặc điểm nữa là mô hình InServ đảm bảo chất lượng dịch vụ theo luồng (flow). Ưu điểm:  Mô hình InServ đảm bảo chất lượng dịch vụ theo luồng (flow).

. không có chính sách lưu lượng trên mặt phẳng chuyển tiếp (forwarding-plane).20 - . Khi sử dụng cho các mục đích khác (như VoIP hay DLSW+reservations).2.4. Khuyết Điểm:  Tốn tài nguyên mạng vô ích. Công việc của RSVP là báo hiệu và duy trì tài nguyên dành riêng qua một mạng. Chương 2: Giao thức RSVP 2. Đảm bảo chất lượng dịch vụ tuyệt đối. Trong MPLS TE. RSVP có thể được dùng để dành riêng không gian hàng đợi công bằng có trọng số (WFQ – Weighted Fair Queuing) hay xây dựng các ATM SVC. RSVP không phải là một giao thức định tuyến.1. RSVP dự trữ băng thông tại mặt phẳng điều khiển (control-plane layer). từ đầu cuối đến đầu cuối (end-toend) 1.  Hạn chế với hệ thống mạng có số lượng flow lớ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. Giới thiệu: RSVP là một cơ chế báo hiệu dùng để dành riêng tài nguyên trên một mạng. Việc quyết định tuyến do IGP (gồm cả các mở rộng TE) và CSPF.

RSVP có ba chức năng cơ bản: • Thiết lập và duy trì đường đi (Path setup and maintenance) • Hủy đường đi (Path teardown) • Báo lỗi (Error signalling) RSVP là một giao thức trạng thái mềm (soft-state protocol).1.Hình 2: RSVP trong Hosts và Routers. Giao thức RSVP 2.1. Nghĩa là cần tái báo hiệu trên mạng để làm tươi định kỳ cho nó. 2.2.1. Các lớp đối tượng của RSVP: .21 - thời gian dành riêng .Chức năng RSVP 2. một yêu cầu bị hủy nếu nó được chỉ định xóa khỏi mạng bằng RSVP hay hết (reservation times out).2.2. Với RSVP.

đặc tả lỗi cho MPLS TE. ResvErr. ResvTear. FLOWSPEC được dùng trong các thông điệp Resv . ResvTearConf. Cũng có một mã lỗi 25 nhưng chỉ thấy khi sử dụng tái định tuyến nhanh (Fast Reroute). Định dạng FLOWSPEC phức tạp và có nhiều thứ trong đó mà RSVP cho MPLS TE không sử dụng. Trong MPLS TE.  Lớp ERROR_SPEC: RFC 2205 định nghĩa đối tượng ERROR_SPEC và cũng xác định các mã lỗi từ 00 đến 23.  Lớp STYLE: Lớp STYLE đặc tả kiểu dành riêng. Cisco IOS Software yêu cầu dịch vụ tải được điều khiển (Controlled-Load) khi dành riêng cho một đường hầm TE. • Fixed Filter • Shared Explicit Cisco IOS Software sử dụng Shared Explicit cho sự dành riêng MPLS TE. Có thể có 3 loại: • Wildcard Filter. Vì thế nếu bạn cấu hình với . Khi mã lỗi (error code) là 00.  Lớp FLOWSPEC: Lớp FLOWSPEC được xác định trong RFC 2210.Resv. tính bằng byte (không phải bit). MPLS TE sử dụng phần tốc độ trong bình của FLOWSPEC để chỉ định băng thông mong muốn. ResvConf. Trường Flags không được sử dụng. Thông thường trường Flags bằng 0 khi sử dụng MPLS TE. giá trị lỗi (error value) cũng là 00.  Lớp SCOPE: RFC 2205 xác định lớp SCOPE. Option Vector luôn bằng 0x12. chỉ định loại Share Explicit.22 - . RFC 3209 định nghĩa mã lỗi 24. Khi mã lỗi là 24 thì có thể có 10 giá trị.ms để gửi thông điệp Path hay Resv. Lớp TIME_VALUES: RFC 2205 định nghĩa đối tượng TIME_VALUES như là chu kỳ làm tươi (refresh period) (tính bằng mili giây . Lớp SCOPE thực hiện kiểu dành riêng wildcard (wildcard reservation style). rất dễ gặp mã lỗi 00 ( Sự xác nhận (Confirmation) — gửi trong phúc đáp cho một thông điệp chứa đối tượng CONFIRMATION) hay mã lỗi 24.

nó phát tín hiệu 12. LSP ID khi các đặc tính của đường hầm (tunnel's properties) thay đổi (băng thông.  Lớp LABEL_REQUEST: Đối tượng LABEL_REQUEST yêu cầu một nhãn.000 bytes). Nó gửi tín hiệu yêu cầu một chấp nhận (confirmation).000 bits = 12. Trường IPv4 Tunnel Sender Address cho biết router ID của đầu đường hầm TE (TE tunnel headend).000. nhưng trong chế độ khung (frame mode). kích thước 32-bit. Nó chứa. LSP Tunnel IPv4. đường đi thay đổi). RFC 3209 thêm vào C-Type 7.000 bytes trong một giây (100 Mb = 100. .  Lớp SENDER_TEMPLATE: Thường chỉ thấy lớp SENDER_TSPEC trong thông điệp Path.tunnel mpls traffic-eng 100000 để yêu cầu 100 Mbps băng thông. Lớp RESV_CONFIRM thỉnh thoảng xem như CONFIRM. Layer 3 Protocol Identifier (L3PID) được mang trong nhãn. ADSPEC chỉ dùng trong các thông điệp Path.500. nó xuất hiện trong các thông điệp Resv và ResvTear.  Lớp ADSPEC: Xác định trong RFC 2210.23 - . nó mang nhãn 20-bit dùng cho một đường hầm cụ thể (particular tunnel). ResvErr. Giống SENDER_TSPEC.  Lớp FILTER_SPEC: Lớp FILTER_SPEC được xác định trong RFC 2205. Cisco IOS luôn báo .500. Lớp RSVP_LABEL chỉ có trong thông điệp Resv.  Lớp RESV_CONFIRM: RESV_CONFIRM được xác định trong RFC 2205. mọi đối tượng RSVP phải là bội số của 4 byte. FILTER_SPEC chỉ dùng trong các thông điệp liên quan Resv (ResvTear. và trường LSP ID cho biết tunnel's LSP ID...000 Kb = 100. trong 16 bit cao. Một đối tượng RSVP_LABEL trả lời cho nó. Đối tượng LABEL_REQUEST chỉ có trong thông điệp Path. MPLS TE chỉ quan tâm tới phần tốc độ trung bình (average rate section).  Lớp RSVP_LABEL: Lớp RSVP_LABEL (thỉnh thoảng được gọi là LABEL) được xác định trong RFC 3209. Giống như FLOWSPEC.).

ERO chỉ có trong thông điệp Path. Common Header: Các phần trong common header như sau: Vers: 4 bit Flags: 4 bit 0x01-0x08: Reserved Không có cờ bit được định nghĩa được nêu ra. sự tồn tại của L3PID mang tính lịch sử. Sự tồn tại của đối tượng LABEL_REQUEST đủ để báo cho nút xuôi dòng (downstream node) là nó tiếp nhận nhãn đưa ra.  Lớp EXPLICIT_ROUTE: Đối tượng EXPLICIT_ROUTE đường đi cho đường hầm MPLS TE.hiệu 0x800 (IP). Msg Type: 8 bit 1 = Path 2 = Resv 3 = PathErr 4 = ResvErr 5 = PathTear 6 = ResvTear 7 = ResvConf .24 - . và được xác định trong RFC 3209. 2.1. thường được gọi là ERO. ERO là một tập các đối tượng con (8byte). Đối tượng con IPv4 Prefix hiện tại chỉ được hỗ trợ bởi Cisco IOS.2.2.

bao gồm cả tiêu đề chung và các biến dài theo sau.2. Các gói tin RSVP: Hình 3: Router sử dụng giao thức RSVP.1. Path messages Định dạng của một thông điệp Path như sau: <Path Message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP_HOP> <TIME_VALUES> .2. 2.2. Send_TTL: 8 bits Giá trị mà gói tin được gửi đi RSVP Length: 16 bits Tổng chiều dài của gói tin RSVP trong byte.25 - .2. 2.RSVP Checksum: 16 bits .

ta phải dùng broadcast. Địa chỉ đích tượng trưng bằng các hosts muốn nhận traffic này. Mặc định. một router hoặc một L3 switch sẽ không chuyển các gói tin này trừ khi phải cấu hình multicast routing. ] [ <sender descriptor> ] <sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> [ <ADSPEC> ]  Multicast Sessions: • Cơ chế gửi một thông điệp từ một nguồn duy nhất đến một nhóm chọn lựa các địa chỉ đích thông qua một hạ tầng mạng lớp 3 trong một dòng dữ liệu. Tất cả các gói sẽ được phát tán ra tất cả các port ở chế độ mặc định. Một thiết bị L2 switch không thể nhận biết được vị trí của địa chỉ multicast đích.  Unicast Sessions: . • Các traffic dạng multicast thường là một chiều (unidirectional).. Multicast dùng UDP chứ không dùng TCP. nên thông thường các gói tin không được phép gửi ngược về máy nguồn trên cơ chế multicast. • Các gói được gửi từ một địa chỉ nguồn đến một nhóm các máy tính. Nếu muốn gửi một thông điệp từ một nguồn về một đích. Nếu muốn gửi một thông điệp từ một nguồn đến tất cả các đích trong một phân đoạn mạng. Cơ chế multicast cũng sẽ được truyền theo kiểu phi-kết-nối (connectionless). Một host đích sẽ trả traffic ngược về nguồn theo cơ chế unicast.[ <POLICY_DATA> .26 - . Do có nhiều host nhận cùng một dữ liệu. • Các host muốn nhận dữ liệu từ một nguồn multicast có thể tham gia hoặc rời khỏi một nhóm multicast ở bất kỳ thời điểm nào.. ta có thể dùng cơ chế unicast.

2 Resv Messages: Tin nhắn Resv mang theo những yêu cầu từ hop-by-hop từ người nhận đến người gửi. Địa chỉ đích IP của một tin nhắn Resv là địa chỉ unicast của một nút-hop trước.• Các gói tin được gửi từ một địa chỉ nguồn đến một địa chỉ đích.. Các nguồn địa chỉ IP là một địa chỉ của các nút gửi tin nhắn. • Phương thức unicast yêu cầu rằng các ứng dụng video gửi một bản copy của từng gói tin đến mọi địa chỉ unicast của các thành viên của nhóm. thu được từ đường dẫn. ] <STYLE> <flow descriptor list> <flow descriptor list> ::= <empty> | <flow descriptor list> <flow descriptor> Các kiểu dành tài nguyên: WF Style: Tạo ra 1 tài nguyên dành chung cho tất cả các sender ở phía upstream có cùng session.2. • Phương thức dùng unicast không có khả năng mở rộng. 2.27 - . Định dạng của một thông điệp Path như sau: <Resv Message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP_HOP> <TIME_VALUES> [ <RESV_CONFIRM> ] [ <SCOPE> ] [ <POLICY_DATA> . Nếu một thiết bị là L2. Một router hoặc một thiết bị lớp 3 sẽ chuyển các gói tin bằng cách tìm địa chỉ đích trong bảng định tuyến.2. Sau này tất cả các sender sẽ share nhau tài nguyên .. nó chỉ cần dựa vào địa chỉ MAC. dọc theo đường dẫn ngược của lớp dữ liệu. và đẩy bản tin thông báo dành tài nguyên này lên tất cả các sender ở trên.

2. Các router trung gian hỗ trợ RSVP. <flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC> | <flow descriptor list> <FF flow descriptor> <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> SE style: <flow descriptor list> ::= <SE flow descriptor> <SE flow descriptor> ::= <FLOWSPEC> <filter spec list> <filter spec list> ::= <FILTER_SPEC> | <filter spec list> <FILTER_SPEC> 2. Cách dành riêng này phù hợp với các ứng dụng unicast như là packetaudio <flow descriptor list> ::= <WF flow descriptor> <WF flow descriptor> ::= <FLOWSPEC> • Ví dụ : Senders: là khoảng 10 cái server online-packet-radio-station ở Mỹ. Receivers:" là một số users ở VN.2. nhưng việc dành riêng này là có lựa chọn sender.28 - .này.  FF style: thiết lập một kênh dành riêng cho các sender ở phía trên.3 Path Teardown Messages: .

2.2. Thông điệp lỗi được gửi ngược dòng về phía nguồn của lỗi. Các lỗi này được báo hiệu bằng thông điệp PathErr hay ResvErr.2.4 Resv Teardown Messages: <ResvTear Message> ::= <Common Header> [<INTEGRITY>] <SESSION> <RSVP_HOP> [ <SCOPE> ] <STYLE> <flow descriptor list> <flow descriptor list> ::= (see earlier definition) 2. <PathTear Message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP_HOP> [ <sender descriptor> ] <sender descriptor> ::= (see earlier definition) 2.29 - .. nó gửi một thông điệp PathTear dọc theo đường thông điệp Path đã đi và một ResvTear dọc theo đường của Resv. một PathErr được gửi ngược dòng từ một nút xuôi dòng và một ResvErr được gửi xuôi dòng từ một nút ngược dòng. PathTear và ResvTear cũng được gửi để trả lời một điều kiện lỗi trong mạng.Nếu một nút quyết định một sự dành riêng không còn cần thiết trong mạng. tín hiệu RSVP có thể bị lỗi.2.5 Path Error Messages: Thỉnh thoảng.] .. <PathErr message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <ERROR_SPEC> [ <POLICY_DATA> . Thông điệp ResvTear được gửi để hồi đáp cho PathTear báo hiệu đuôi đường hầm.

] <STYLE> [ <error flow descriptor> ] Những quy tắc xác định sự phụ thuộc vào một lỗi hợp lệ của dòng mô tả. <ResvErr Message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <RSVP_HOP> <ERROR_SPEC> [ <SCOPE> ] [ <POLICY_DATA> . hoặc nó có thể báo tự động đến dự trữ tài nguyên.. Tại mỗi hop .[ <sender descriptor> ] <sender descriptor> ::= (see earlier definition) 2. WF Style : <error flow descriptor> ::= <WF flow descriptor> FF style : <error flow descriptor> ::= <FF flow descriptor> SE style : <error flow descriptor> ::= <SE flow descriptor> . Resv Error Messages phân luồng thích hợp xuống cho người nhận. địa chỉ đích IP là địa chỉ là địa chỉ Unicast của một nút hop tiếp theo.6 Resv Error Messages Resv Error Messages báo lỗi trong việc xử lý tin nhắn..30 - . đối tượng được yêu cầu để được như mô tả trước đó được phân vào một luồng. sử dụng giao thức hop-by-hop để dự trữ trước tài nguyên.2.2.

Một gói tin PathTear đi hướng tới tất cả các máy thu hạ lưu của nó từ điểm khởi đầu và xóa các con đường dẫn.3. một teardown yêu cầu phải được chuyển tiếp . để chứa các hop-by-hop kiểm tra tính toàn vẹn hop theo cơ chế. Một gói tin PathTear (ResvTear) có thể được hình thành như môt tin nhắn đảo ngược ý nghĩa.7 Confirmation Messages: Tin nhắn ResvConf được gửi đến (probabilistically) thừa nhận yêu cầu dành trước tài nguyên.2.2.31 - . Tuy nhiên. Một gói tin ResvTear xóa các nút mà nó nhận được. Một khi bắt đầu. Một tin nhắn ResvConf được gửi đến địa chỉ unicast của một host nhận. cũng như tất cả các tiểu bang đặt phòng phụ thuộc. đề nghị tất cả các máy chủ gửi một yêu cầu kết thúc teardown ngay sau khi kết thúc một ứng dụng.2. một tin nhắn ResvConf được chuyển cho hop nhận. hoặc bằng một router là kết quả của thời gian chờ của dịch vụ. <ResvConf message> ::= <Common Header> [ <INTEGRITY> ] <SESSION> <ERROR_SPEC> <RESV_CONFIRM> <STYLE> <flow descriptor list> <flow descriptor list> ::= (see earlier definition) 2. Có hai loại gói tin teardown RSVP là PathTear và ResvTear. Mặc dù nó không cần thiết phải rõ ràng.2. dọc theo đường. Một yêu cầu teardown có thể được bắt đầu bởi một ứng dụng trong một hệ thống cúi (người gửi hoặc nhận). địa chỉ được thu được từ các đối tượng RESV_CONFIRM. Một tin nhắn được gửi ResvConf như kết quả của sự xuất hiện của một đối tượng RESV_CONFIRM trong tin nhắn Resv.Teardown Gói tin RSVP "teardown" loại bỏ Path hoặc Reservation ngay lập tức.

Việc xử lý gói tin ResvErr là phức tạp. một gói tin ResvTear prune trở lại. nó đơn giản là gửi ngược dòng đến người gủi và tạo ra các lỗi và không thay đổi các nút mặc dù cố vượt qua.hop-by-hop không chậm trễ. Như mọi khi. Nếu một gói tin teardown bị mất. bất kỳ flowspec được bỏ qua. Kết quả là. Một teardown xóa quy định tại các nút mà nó là nhận được. Một gói tin ResvTear xác định được phong cách và bộ lọc. một lỗi đặt phòng phải được báo cáo đến tất cả những người nhận. Tuy nhiên. router mà không nhận được thông báo thời gian ra khỏi và bắt đầu một tin nhắn mới teardown vượt mất điểm. Một nút cũng có thể quyết định có quyền đặt phòng được thành lập.32 - . sự thay đổi này sẽ được tuyên truyền ngay lập tức đến nút kế tiếp.2. có một số cách cho một yêu cầu đặt phòng cú pháp hợp lệ tại một số nút dọc theo con đường. việc sáp nhập các yêu cầu không đồng nhất tạo ra một khó khăn tiềm năng được gọi là "killer . Lỗi: Có hai RSVP thông báo lỗi là ResvErr và PathErr. Giả sử xác suất RSVP mất tin là nhỏ. Tin hiệu PathErr rất đơn giản. Ngoài ra. thời gian dài nhất để xóa hiếm khi vượt quá một khoảng thời gian chờ mới. Giống như tất cả các gói tin RSVP khác. nhưng chỉ khi nào sẽ có một mạng lưới thay đổi sau khi sát nhập. 2. yêu cầu không được giao teardown đáng tin cậy.4. Flowspec Dù là ở vị trí này sẽ được loại bỏ nếu tất cả specs của nó lọc được. Chỉ có một vài nguyên nhân có thể có lỗi đường dẫn. Sự mất mát của một gói tin yêu cầu teardown sẽ không gây ra lỗi giao thức vì ngay cả khi nó không phải xóa. Từ một yêu cầu không thể là kết quả của việc sáp nhập một số lượng yêu cầu.

2. hay nó có thể phụ thuộc vào vài dạng phản hồi của ng sử dụng như hóa đơn cước phí lưu trữ. Trong bất kì trường hợp nào. RSVP bảo vệ chống lại các cuộc tấn công như vậy với một hop-by-hop cơ chế xác thực bằng cách sử dụng một hàm băm mật mã. Bảo mật: • Thông báo toàn vẹn và nút xác thực: Yêu cầu giả mạo có thể dẫn đến hành vi trộm cắp dịch vụ trái phép của các bên hoặc từ chối dịch vụ do các khóa lên tài nguyên mạng. Đồng thời.33 - . Để ngăn ngừa sự lạm quyền. trong đó một trong những yêu cầu có thể từ chối dịch vụ khác. Cơ chế này được hỗ trợ bởi các đối tượng toàn vẹn mà có thể xuất hiện trong bất kỳ thông điệp RSVP. Những đối tượng sử dụng một key mật mã kỹ thuật. cả 2 phải thuận lợi cho RSVP thực hiện việc lưu trữ. 2. Mặc dù cơ chế này là một phần của cơ sở của RSVP.reservation". có hai killer-reservation. Vd vài sự ép buộc được thiết lập bởi chính sách quyền admin. Thực tế. Cơ chế chứng thực: RSVP – những yêu cầu QoS trung gian cho phép những người sử dụng cụ thể được ưu tiên vào nguồn hệ thống mạng. vài dạng ép buộc sẽ được yêu cầu rộng rãi đối với người dùng làm công việc lưu trữ. mỗi giao điểm phải trả lời 2 câu hỏi: “ có đủ nguồn để đáp ứng yêu cầu này ko” và “ người dùng này có đc cho phép lưu trữ ko” 2 quyết định này dựa trên quyết định “ kiểm soát chính sách “ và quyết định “ kiểm soát quyền hạn”. có thể cần đến việc nhận diện ng sử dụng được tin cậy hay lựa chọn admin nếu như việc lưu trữ đc yêu cầu. .5. đặc điểm kỹ thuật của nó được miêu tả trong một tài liệu đồng hành [Baker96].6.2. mà giả định rằng RSVP chia sẻ một bí mật. Khi có 1 việc lưu trữ mới đc yêu cầu. 2. Thuật ngữ “ chính sách kiểm soát” đc dùng cho cơ chế mà yêu cầu sự hỗ trợ việc đi vào và ép buộc cho việc lưu trữ RSVP.

Mặc dù không có giấy chứng nhận trên toàn cầu.2. • Người dùng xác thực: Chính sách kiểm soát sẽ phụ thuộc vào tính xác thực của người sử dụng chịu trách nhiệm cho từng yêu cầu. việc sử dụng IPSEC (IP Security) trong luồng dữ liệu đặt ra một vấn đề cho RSVP: nếu vận chuyển và tiêu đề cấp cao hơn được mã hóa. Non-RSVP clouds: . Cho đến khi trở thành cơ sở hạ tầng hiện có. Đặc biệt. Một vấn đề quan ngại an ninh thứ ba đặt nguồn suối an toàn cho dữ liệu.7. quản lý khóa chủ chốt sẽ được yêu cầu để bảo đảm tính toàn vẹn thông điệp RSVP.34 - . sử dụng hop-by-hop mô tả cơ chế toàn vẹn trước đó. người sử dụng kiểm chứng có thể cung cấp xác thực người sử dụng thực tế trong nhiều trường hợp bằng cách thiết lập một chuỗi sự tin tưởng. Để giải quyết vấn đề này. • An toàn dữ liệu: Hai vấn đề đầu tiên bảo mật liên quan hoạt động của RSVP. Đặc điểm kỹ thuật của giấy chứng nhận là một vấn đề trong tương lai. một phần mở rộng RSVP đã được định nghĩa trong đó nhận diện hiệp hội bảo mật (IPSEC SPI) đóng một vai trò khoảng tương đương với các ports tổng quát.Lan rộng việc sử dụng các cơ chế toàn vẹn RSVP sẽ đòi hỏi sự sẵn có của việc quản lý chủ chốt và cơ sở hạ tầng phân phối cho các router. Chính sách dữ liệu do đó có thể bao gồm giấy chứng nhận sử dụng mã hóa để bảo vệ. 2. RSVP của số ports không thể được sử dụng để xác định một phiên làm việc hoặc người gửi.

một "Hợp Lý Giao diện Handle" (LIH) được sử dụng. Tuy nhiên. Các thông tin hop trước đây bao gồm trong một thông điệp Path không chỉ các địa chỉ IP của nút trước đó. Cả hai router RSVP và non-RSVP truyền thông điệp đến địa chỉ bằng việc sử dụng bảng định tuyến uni/multicase. Một thông điệp Resv truyền trực tiếp đến router ké tiếp có khả năng RSVP theo đường trở về nguồn gửi thông điệp. Một tin nhắn Resv đến nút địa chỉ mang cả hai địa chỉ IP và LIH của giao diện đi đúng. RSVP không bao giờ có thể được triển khai ở khắp mọi nơi. Tất nhiên. RSVP do đó phải cung cấp giao thức hoạt động chính xác. một đám mây trung gian mà không hỗ trợ RSVP là không thể thực hiện đặt phòng tài nguyên. . tin nhắn đó phải được chuyển tiếp mà không cần chế biến thêm bằng nút này. thì những nút có khả năng sẽ có trong general perturb mà QoS cung cấp đến bên nhận . Thậm chí mặc dù RSVP có hoạt động một cách chính xác thông qua đám mây non-RSVP.Không thể để triển khai RSVP (hoặc bất kỳ giao thức mới) vào cùng thời điểm trên khắp toàn bộ mạng Internet.35 - . định tuyến của đường thông điệp duyệt trên một đám mây non-RSVP. nghĩa là các giao diện đó sẽ nhận được các yêu cầu đặt. nếu như một đám mây có đủ năng lực. cả các giá trị được lưu trữ trong tiểu đường. nó vẫn có thể cung cấp dịch vụ hữu ích gian thực. hoặc để đến giao diện của nút chính xác. Một quá trình RSVP phải được chuẩn bị để xử lý hoặc là tình hình. Do đó. Một số cấu trúc liên kết của RSVP router và non-RSVP router có thể gây ra tin nhắn Resv đến RSVP. Hơn nữa. RSVP được thiết kế để hoạt động một cách chính xác thông qua một đám mây Non-RSVP. Nếu địa chỉ đích không phù hợp bất kỳ giao diện và thông điệp không phải là Path hoặc PathTear. ngay cả khi hai RSVP router có khả năng được tham gia bởi một đám mây "tuỳ tiện" không RSVP router. Để xử lý các trường hợp giao diện sai.

DestAddress.36 - . using IGMP. sử dụng IGMP. có thể vào thu mà không có QoS mong muốn.8. các dữ liệu ban đầu.  H1 nhận A tham gia nhóm multicast được chỉ định bởi DestAddress. và có nhận nhưng không có tin nhắn Resv đến người gửi nào được nêu ra Sau đó.  Giả sử một người gửi mới bắt đầu gửi dữ liệu (H6) nhưng không có các tuyến đường multicast bởi vì không nhận đã tham gia vào nhóm (H1). dữ liệu sẽ bị bỏ tại một số nút router cho đến khi người nhận (s) xuất hiện. Người gửi có thể giảm nhẹ vấn đề này bằng cách chờ đến . Khi một phiên RSVP được thiết lập. Chú ý đồng bộ hóa. DstPort]) phải được chỉ định và truyền đạt đến tất cả những người gửi và nhận bởi cơ chế out-of-band.  H4 nhận phù hợp Resv bắt đầu gửi tin nhắn. Sau đó.  H3 Một ứng dụng máy thu nhận được một thông điệp Path. để đồ giữa lớp IP và lưu lượng liên kết các thực thể lớp.  H1 và H2 có thể xảy ra trong trật tự. việc xác định phiên làm việc (DestAddress.Các LIH cũng có thể hữu ích khi RSVP được thực hiện trên một liên kết lớp phức tạp. Host mẫu: Trước khi một phiên họp có thể được tạo ra.  H5 Một ứng dụng gửi nhận tin nhắn Resv.  H2 Một người gửi tiềm năng RSVP Path bắt đầu gửi tin nhắn đến DestAddress. 2. ProtocolId [.  H6 người gửi A bắt đầu gửi dữ liệu gói.  Giả sử một người gửi mới bắt đầu gửi tin nhắn Path (H2) và dữ liệu (H6) đồng thời. các sự kiện sau đây xảy ra tại các hệ thống kết thúc.2.

37 - . có một tập các quy tắc cho sự lựa chọn cho phép của các loại đối tượng. tiêu đề đối tượng tiêu chuẩn. BNF Các hàm ý một đơn đặt hàng cho các đối tượng trong tin nhắn.2. 2. theo sau là bao gồm một số biến chiều dài. kết thúc triển khai hệ thống của RSVP có thể biết về các giá trị nhất định cho lĩnh vực này. DstPort). gõ "đối tượng". nhưng chấp nhận các đối tượng trong bất kỳ thứ tự cho phép.3. Định dạng các gói tin: Một gói tin RSVP gồm có một tiêu đề chung. trong nhiều (nhưng không phải tất cả các trường hợp) đối tượng làm cho không có sự khác biệt hợp lý. Một hệ thống kết thúc có thể đưa ra một lỗi cho một ứng dụng mà một trong hai: . Đối với mỗi loại thông điệp RSVP. Tuy nhiên. DstPort có thể được bỏ qua (thiết lập không) nếu ProtocolId chỉ định một giao thức mà không có một port field trong định dạng được sử dụng bởi UDP và TCP. Các thành phần cơ bản trong giao thức RSVP: 2. Các phần phụ sau xác định các định dạng của các tiêu đề phổ biến. Tuy nhiên.3. và đặc biệt là các giá trị cho UDP và TCP (17 và 6 tương ứng).3. RSVP cho phép bất kỳ giá trị cho ProtocolId.của tin nhắn Resv đầu tiên (H5) trước khi nhận bất kỳ thông điệp Path (H3). Một thực hiện nên tạo tin nhắn với các đối tượng theo thứ tự được hiển thị ở đây. 2. và mỗi loại thông điệp RSVP. Các ports được sử dụng: Một phiên RSVP thường được xác định bởi ba: (DestAddress. RSVP sẽ trở lại các thông báo lỗi đến người nhận. ProtocolId. Những quy tắc này được quy định bằng cách sử dụng Backus-Naur Form (BNF) ghép với các dấu ngoặc vuông bao quanh tùy chọn phụ trình tự.1. Dưới đây là một DstPort UDP / TCP trường điểm đến cổng (nghĩa là một số lượng 16-bit thực tại octet bù đắp 2 trong tiêu đề giao thông).

SrcPort). nơi SrcPort là một UDP / TCP nguồn cổng trường (tức là. và ResvConf phải được gửi với tùy chọn Router IP Alert trong tiêu đề IP. 2.38 - . một số lượng 16-bit thực tại octet offset 0 trong tiêu đề giao thông). mặc dù nó cũng có thể gói gọn RSVP tin nhắn như UDP datagrams cho các đầu cuối truyền thống. Các quy tắc sau đây giữ cho việc sử dụng số không DstPort và / hoặc SrcPort trường trong RSVP. Nguyên tắc này là cần thiết để ngăn chặn cơn bão gói dữ liệu trên mạng LAN phát sóng.3. • xác định một số không DstPort cho một giao thức rằng không có gì có UDP / TCP. Khi xuất hiện của một thông điệp M RSVP thay đổi trạng thái một nút phải gửi sửa đổi ngay lập tức.• xác định khác không DstPort cho một giao thức mà không có UDP / TCP. Gửi các gói tin RSVP: Gói tin RSVP được gửi hop-by-hop giữa RSVP có khả năng định tuyến là "datagrams IP thô" với 46 số giao thức.3. đây không phải kích hoạt gửi một tin nhắn trên giao diện thông qua đó M đến (mà có thể xảy ra nếu việc thực hiện chỉ cần kích hoạt làm mới ngay lập tức cho tất cả các phiên). SrcPort có thể được bỏ qua (thiết lập để không) trong các trường hợp nhất định. Lọc số kỹ thuật và người gửi mẫu xác định các cặp: (SrcAddress. PathTear. Tùy chọn này có thể được sử dụng trong đường dẫn chuyển tiếp nhanh chóng của một bộ định tuyến tốc độ cao để phát hiện datagrams đó có yêu cầu xử lý đặc biệt. như mô tả tại Phụ lục C. đóng gói UDP là cần thiết cho hệ thống mà không thể nào để mạng lưới thô / O. Gói tin Path. . Nguyên datagrams IP cũng dự định sẽ được sử dụng giữa một hệ thống kết thúc và / trước router hop qua. Tuy nhiên.

3. Mặt khác. • Không bị ngăn trở non-RSVP đám mây có thể mất mảnh tin cá nhân. mỗi gói tin RSVP phải chiếm datagram IP một cách chính xác. một giá trị lớn hơn có thể được sử dụng cho các yếu tố thời gian chờ K. Điều này tránh các gói Looping. và bất kỳ đoạn bị mất sẽ mất toàn bộ tin nhắn. khoảng 64K byte. 2. Trong trạng thái ổn định. router phải được cấu hình để cung cấp cho một lớp ưa thích của dịch vụ. ngay cả khi các nút cuối cùng đã kết thúc làm mới nó. nhưng vẫn là một khả năng tự động làm mới loop.39 - . điều này có một số hậu quả: • Một RSVP đơn thư không thể vượt quá kích thước tối đa của IP datagram. Nếu gói RSVP kinh nghiệm thiệt hại đáng chú ý khi đi qua không bị ngăn trở đám mây non-RSVP. Dưới tình trạng quá tải mạng. Như tự động làm mới hoạt động "mãi mãi". RSVP sử dụng các cơ chế làm mới định kỳ để phục hồi gói không thường xuyên. lỗi và gói tin teardown được chuyển tiếp ngay lập tức và do đó phải trực tiếp Looping. tuy nhiên thiệt hại đáng kể của gói tin RSVP có thể gây ra một sự thất bại của tài nguyên. Nếu nó vượt quá MTU.Trong phiên bản này của spec. chẳng hạn một datagram sẽ được phân mảnh bởi IP và tại nút người nhận. .4. Các gói tin báo Loops: Chuyển tiếp tin nhắn RSVP phải tránh Looping. Để kiểm soát việc chậm trễ xếp hàng và thả các gói RSVP. gói tin Path và Resv được chuyển tiếp hop mỗi ngày chỉ một lần mỗi khoảng thời gian làm mới. cho đến khi nhận rời khỏi nhóm multicast hoặc những người gửi những gửi gói tin Path.

xác định đường đi một vòng đảo ngược đường dẫn đến mỗi người gửi. • Gói tin PathTear Gói tin PathTear sử dụng định tuyến giống như gói tin Path và do đó có thể không lặp. • Gói tin ResvTear Mặc dù gói tin ResvTear được định tuyến cũng giống như gói tin Resv.Thông tin từng loại tin. trong lần thứ hai vượt qua một vòng lặp sẽ không có bất kỳ gói tin ResvTear bị bỏ. mà chúng ta bỏ qua ở đây).40 - . Tuy nhiên. Vì vậy không nên có vòng thư Path (ngoại trừ có lẽ cho vòng lặp định tuyến thoáng qua. • Gói tin Resv Gói tin Resv trực tiếp tới người gửi cụ thể (tức là. • Gói tin ResvErr Gói tin ResvErr cho WF có thể lặp cho cùng một lý do cơ bản mà gói tin Resv lặp. . • Gói tin PathErr Kể từ khi thông điệp Path không lặp. • Gói tin Path Thông điệp Path được chuyển tiếp trong cách chính xác giống như IP của gói dữ liệu. với lựa chọn người gửi rõ ràng) có thể không lặp. gói tin Resv lựa chọn người gửi với ký tự đại diện (WF phong) có một tiềm năng tự động lặp lại. Do đó không có vấn đề Looping ở đây. Gói tin PathErr luôn hướng đến người gửi cụ thể và do đó có thể không lặp. ngay cả trong một topo với chu kỳ.

Mỗi Resv RSVP hoặc gói tin Path TIME_VALUES chứa một đối tượng xác định giá trị R đã được sử dụng để tạo mới một gói tin. Source_Port ] [. Source_Port] .3.6. Ứng dụng RSVP / giao diện: Phần này mô tả một giao diện chung giữa một ứng dụng và một quá trình kiểm soát RSVP. Một số thông tin để gây ra các cuộc gọi được trả lại không đồng bộ. Upcall_Proc_addr]) -> Session-id • Xác định người gửi Call: SENDER( Session-id Call [ . ProtocolId. Các thông số thời gian: Có hai thông số thời gian có liên quan đến mỗi phần tử của RSVP path hay reservation đặt tại một nút: R khoảng thời gian làm mới giữa các thế hệ kế tiếp làm mới cho tiểu bang của các nút hàng xóm.5.41 - .• Gói tin ResvConf Gói tin ResvConf được chuyển tiếp hướng tới một địa chỉ người nhận cố định unicast và có thể không lặp. Source_Address] [. 2. 2. và nhà nước địa phương đời L. Giá trị R là sau đó được sử dụng để xác định giá trị cho L khi đã nhận được và được lưu trữ. Các giá trị của R và L có thể khác nhau từ hop to hop. Các chi tiết của một giao diện thực sự có thể được điều hành hệ thống phụ thuộc. DstPort [ . sau đây có thể đề nghị các chức năng cơ bản thực hiện.3. SESSION_object ] [ . • Đăng ký kỳ họp Call: SESSION( DestAddress . Upcall_Proc_addr ] ) -> Session-id [. Source_Address ] [ .

một giao diện mặc định sẽ được sử dụng. - Source_Port Đây là UDP / cổng TCP mà từ đó các dữ liệu sẽ được gửi.42 - . Sender_Template] [ . Sender_Tspec ] [ . Tham số này là cần thiết chỉ trên một máy chủ người gửi. Adspec] Các tham số SENDER được giải thích như sau: - Source_Address Đây là địa chỉ của giao diện từ đó dữ liệu sẽ được gửi. - Sender_Template Tham số này được bao gồm như là một cơ chế thoát ra để hỗ trợ một định nghĩa tổng quát hơn của người gửi ( "cổng nguồn tổng quát"). Thông thường tham số này có thể được bỏ qua. Nếu bỏ qua. - Data_TTL - Policy_data .[ . Sender_Template ] [. Adspec ] [. - Adspec Tham số này có thể được chỉ định để khởi tạo các tính toán của QoS dọc theo đường dẫn. - Sender_Tspec Tham số này mô tả các luồng giao thông được gửi đi. Sender_Tspec] [.

Dữ liệu này có thể được cung cấp bởi một hệ thống dịch vụ. Info_type. • Reserve Dự trữ Call: RESERVE( session-id. [ receiver_address . Sau một cuộc gọi Reserve. ] [ CONF_flag. Các tùy chọn `receiver_address’ tham số có thể được sử dụng bởi một bộ tiếp nhận trên một máy chủ lưu trữ multihomed (hoặc router). ] Một người nhận cuộc gọi này sử dụng để thực hiện hoặc sửa đổi một đặt phòng tài nguyên cho các phiên đăng ký như `session-id '. • Release Thoát Call: RELEASE( session-id ) Cuộc gọi này loại bỏ RSVP cho các session xác định bởi session-id. một lỗi hay sư kiện không đồng bộ có thể xảy ra bất cứ lúc nào. Một cuộc gọi sau này có thể dự trữ được để sửa đổi các tham số của cuộc gọi trước (nhưng lưu ý rằng việc thay đổi đặt phòng hiện có thể dẫn đến thất bại kiểm soát). Nút này sau đó sẽ gửi gói tin teardown phù hợp và ngừng gửi làm mới lại session-id này. . • Error/Event Upcalls Dạng thức thông thường của một upcall là như sau: Upcall: <Upcall_Proc>( ) -> session-id.Tham số tùy chọn các dữ liệu chính sách cho người gửi. nó là địa chỉ IP của một trong các giao diện của nút. ] [ Policy_data. Các cuộc gọi trả về dự trữ ngay lập tức. với việc áp dụng nó. Các `Policy_data’ dữ liệu xác định chính sách cho người nhận.43 - . Cuộc gọi Reserve đầu tiên sẽ bắt đầu việc truyền định kỳ các gói tin Resv.

các Adspec. các Sender_Template. hoặc bằng cách sửa đổi của một reservation trước. Adspec ] [ . phân biệt bởi các tham số Info_type. Info_type=PATH_EVENT. Info_type = PATH_EVENT Một Path Sự kiện upcall kết quả từ khi nhận được gói tin Path đầu tiên cho phần này. Sender_Template Sender_Tspec. 1. Việc lựa chọn các thông số thông tin tùy thuộc vào loại này. Policy_data ] . Flowspec. Filter_Spec_list [ . năm loại upcall. cho session này. Info_type = RESV_EVENT Một upcall Resv sự kiện được kích hoạt bằng việc nhận được gói tin RESV đầu tiên. 2. Sender_Tspec. Info_type=RESV_EVENT. Style.44 - . Sender_Template [ . Policy_data ] Upcall này trình bày các Sender_Tspec. Upcall: <Upcall_Proc>( ) -> session-id.Hiện nay. Upcall: <Upcall_Proc>( ) -> session-id. và dữ liệu từ chính sách bất kỳ một thông điệp Path. chỉ ra cho một ứng dụng nhận rằng có ít nhất một người gửi đang hoạt động. hoặc thay đổi đường dẫn.

một cho mỗi dòng mô tả. Upcall: <Upcall_Proc>( ) -> session-id. nếu có sẽ chứa bất kỳ đối tượng POLICY_DATA từ gói tin Path đã thất bại. Sender_Template [ . Error_code . Lưu ý rằng một gói tin FF-Resv có thể dẫn đến upcalls nhiều RESV_EVENT. Error_value . Policy_data_list tham số. Policy_data_list ] Tham số Error_code sẽ xác định lỗi.Đây `Flowspec 'sẽ là QoS có hiệu quả mà nó đã được nhận. Tham số Error_Node sẽ ghi rõ địa chỉ IP của nút đó phát hiện các lỗi. Info_type = RESV_ERR An Resv Error event indicates an error in a reservation message to which this application contributed. Info_type = PATH_ERROR Một Path Lỗi sự kiện chỉ ra một lỗi trong thông tin người gửi được xác định trong một cuộc gọi SENDER. Error_Node . An Resv Lỗi sự kiện chỉ ra một lỗi trong một thông báo đặt phòng mà ứng dụng này đã đóng góp. Upcall: <Upcall_Proc>( ) -> session-id. . Info_type=RESV_ERROR. Info_type=PATH_ERROR.45 - . 3. và Error_value có thể cung cấp một số (có lẽ bổ sung hệ thống cụ thể) dữ liệu về lỗi. 4.

Policy_data_list ] Tham số Error_code sẽ xác định lỗi và Error_value có thể cung cấp một số (có lẽ bổ sung hệ thống cụ thể) dữ liệu. Error_Node . Filter_spec_list [ . Upcall: <Upcall_Proc>( ) -> session-id. Error_flags . Filter_spec_list.Error_code . Tham số Policy_data_list sẽ chứa bất kỳ đối tượng POLICY_DATA từ gói tin ResvErr. Style. Tham số Error_Node sẽ ghi rõ địa chỉ IP của nút đó phát hiện các sự kiện đang được báo cáo. Info_type=RESV_CONFIRM. Info_type = RESV_CONFIRM Một sự kiện xác nhận chỉ ra rằng một gói tin ResvConf đã được nhận. Filter_spec_list [ .46 - . List_count sẽ chỉ định số FILTER_SPECS trong Filter_spec_list. Flowspec. There are two Error_flags: Có hai Error_flags: - InPlace Filter_spec_list và Flowspec sẽ chứa các đối tượng tương ứng từ các dòng mô tả lỗi. 5. List_count. Flowspec. Policy_data ] . Error_value .

Các tham số được diễn giải như trong upcall Resv Error.
Mặc dù thông điệp RSVP chỉ đường dẫn path hoặc các sự kiện resv có thể được
nhận định kỳ, API sẽ làm cho upcall tương ứng không đồng bộ để ứng dụng duy
nhất trên sự xuất hiện đầu tiên hoặc khi những thông tin được báo cáo thay đổi.
Tất cả các lỗi và xác nhận sự kiện cần được báo cáo vào ứng dụng.
3.1. VPn:
3.1.1. Giới thiệu:
Về căn bản, mỗi VPN là một mạng riêng rẽ sử dụng một mạng chung (thường
là internet) để kết nối cùng với các site (các mạng riêng lẻ) hay nhiều người sử
dụng từ xa. Thay cho việc sử dụng bởi một kết nối thực, chuyên dụng như đường
leased line, mỗi VPN sử dụng các kết nối ảo được dẫn đường quaInternet từ mạng
riêng của các công ty tới các site hay các nhân viên từ xa. Trong đề tài, chúng ta sẽ
xét tới một số các khái niệm cơ bản của VPN và tìm hiểu về các thành phần cơ bản
của VPN, các công nghệ, bảo mật VPN và đường truyền dẫn.
3.1.2. VPN site to site:
Ở đề tài này ta sử dụng VPN loại Site-to-Site: Bằng việc sử dụng một thiết bị
chuyên dụng và cơ chế bảo mật diện rộng, mỗi công ty có thể tạo kết nối với rất
nhiều các site qua một mạng công cộng nhưInternet. Các mạng Site-to-site VPN
có thể thuộc một trong hai dạng sau:
• Intranet-based: Áp dụng trong truờng hợp công ty có một hoặc nhiều địa
điểm ở xa, mỗi địa điểm đều đã có 1 mạng cục bộ LAN. Khi đó họ có thể xây
dựng một mạng riêng ảo VPN để kết nối các mạng cục bộ đó trong 1 mạng
riêng thống nhất.

Extranet-based: Khi một công ty có một mối quan hệ

mật thiết với một công ty khác (ví dụ như, một đồng nghiệp, nhà hỗ trợ hay
- 47 -

khách hàng), họ có thể xây dựng một mạng extranet VPN để kết nối kiểu mạng
Lan với mạng Lan và cho phép các công ty đó có thể làm việc trong một môi
trường có chia sẻ tài nguyên.

Hình : Ba loại mạng riêng ảo.
3.1.3. Tính bảo mật của VPN:
Một mạng VPN được thiết kế tốt sẽ đáp ứng được các yêu cầu sau:
• Bảo mật (Security)
• Tin cậy (Reliability)
• Dễ mở rộng, nâng cấp (Scalability)
• Quản trị mạng thuận tiện (Network management)
• Quản trị chính sách mạng tốt (Policy management)
Một VPN được thiết kế tốt thường sử dụng vài phương pháp để duy trì kết nối
và giữ an toàn khi truyền dữ liệu:

- 48 -

Bức tường lửa - Một tường lửa (firewall) cung cấp biện pháp ngăn chặn
hiệu quả giữa mạng riêng của bạn với Internet. Ta có thể sử dụng tường lửa
ngăn chặn các cổng được mở, loại gói tin được phép truyền qua và giao
thức sử dụng. Một vài sản phẩm VPN, chẳng hạn như Cisco's 1700 router,
có thể nâng cấp để bao gồm cả tường lửa bằng cách chạy Cisco IOS tương
ứng ở trên router. Bạn cũng nên có tường lửa trước khi bạn sử dụng VPN,
nhưng tường lửa cũng có thể ngăn chặn các phiên làm việc của VPN.

• Mã hoá - Đây là quá trình mật mã dữ liệu khi truyền đi khỏi máy tính theo
một quy tắc nhất định và máy tính đầu xa có thể giải mã được. Hầu hết các
hệ thống mã hoá máy tính thuộc về 1 trong 2 loại sau:
+ Mã hoá sử dụng khoá riêng (Symmetric-key encryption)
+ Mã hoá sử dụng khoá công khai (Public-key encryption)
Trong hệ symmetric-key encryption, mỗi máy tính có một mã bí mật sử dụng để
mã hoá các gói tin trước khi truyền đi. Khoá riêng này cần được cài trên mỗi máy
tính có trao đổi thông tin sử dụng mã hoá riêng và máy tính phải biết được trình tự
giải mã đã được quy ước trrước. Mã bí mật thì sử dụng để giải mã gói tin. Ví dụ:
Bạn tạo ra một bức thư mã hoá mà trong nội dung thư mỗi ký tự được thay thế
bằng ký tự ở sau nó 2 vị trí trong bảng ký tự . Như vậy A sẽ được thay bằng C, và
B sẽ được thay bằng D. Bạn đã nói với người bạn khoá riêng là Dịch đi 2 vị trí
(Shift by 2). Bạn của bạn nhận được thư sẽ giải mã sử dụng chìa khoá riêng đó.
Còn những người khác sẽ không đọc được nội dung thư.
Máy tính gửi mã hoá dữ liệu cần gửi bằng khoá bí mật (symetric key), sau đó mã
hoá chính khóa bí mật (symetric key) bằng khoá công khai của người nhận (public
key). Máy tính nhận sử dụng khoá riêng của nó (private key) tương ứng với khoá
public key để giải mã khoá bí mật (symetric key), sau đó sử dụng khoá bí mật này
để giải mã dữ liệu.

- 49 -

Hệ Public-key encryption sử dụng một tổ hợp khoá riêng và khoá công cộng để
thực hiện mã hoá, giải mã. Khoá riêng chỉ sử dụng tại máy tính đó, còn khoá công
cộng được truyền đi đến các máy tính khác mà nó muốn trao đổi thông tin bảo
mật. Để giải mã dữ liệu mã hoá, máy tính kia phải sử dụng khoá công cộng nhận
được, và khoá riêng của chính nó. Một phần mềm mã hóa công khai thông dụng là
Pretty Good Privacy (PGP) cho phép bạn mã hoá đựợc hầu hết mọi thứ. Bạn có
thể xem thêm thông tin tại trang chủ PGP.
 Giao thức bảo mật IPSec - Internet Protocol Security Protocol cung cấp các

tính năng bảo mật mở rộng bao gồm các thuật toán mã hóa và xác thực tốt hơn.
IPSec có hai chế độ mã hoá: kênh tunnel và lớp truyền tải transport. Mã hoá kênh
Tunnel mã hoá cả header và nội dung mỗi gói tin trong khi mã hoá lớp truyền tải
chỉ mã hoá nội dung gói tin. Chỉ có những hệ thống sử dụng IPSec tương thích
mới có khả năng tiên tiến này. Mặc dù vậy, tất cả các thiết bị phải sử dụng một
khoá dùng chung và các tường lửa ở mỗi mạng phải có chính sách cấu hình bảo
mật tương đương nhau. IPSec có thể mã hoá dữ liệu truyền giữa rất nhiều thiết bị,
chẳng hạn như:



Từ router đến router
Từ firewall đến router
Từ PC đến router
Từ PC đến server

 Máy chủ xác thực, xác nhận và quản lý tài khoản AAA Server (Authentication,

Authorization, Accounting Server) được sử dụng để tăng tính bảo mật trong truy
nhập từ xa của VPN. Khi một yêu cầu được gửi đến để tạo nên một phiên làm
việc, yêu cầu này phải đi qua một AAA server đóng via trò proxy. AAA sẽ kiểm
tra.

- 50 -

Message length: 108 Có giá trị là 16bit. Khi tất cả giá trị = 0 thì checksum không được truyền đi.51 - . Sending TTL: 225 Có giá trị là 8bit. 108 Là tổng chiều dài của gói tin RSVP trong byte. Ý nghĩa là tin nhắn được gửi đi. số phiên bản giao thức là 1 Flag: 00 Có giá trị 4bit Message type: PATH message. RSVP version: 1 Có giá trị là 4bit.Chương 3 Phân Tích Các Gói Tin RSVP 3. Đây là kiểu gói tin path Message checksum: 0xe590 Có giá trị là 16bit. Path Message: Hình 4 Giao diện gói tin Path Message. Có giá trị là 8bit. .1.

2 Protocol: trường này sử dụng giao thức ICMP Cái này thường xuất hiện trong thông điệp Path.6. max 1500. lsp-turnel6.52 - .Trong RSVP thì các đối tượng có cùng định dạng như trên vậy. C-type: Đối với Session thì các chỉ số của c-type là 1-2-7-8. Và mối đối tượng thì có 1 cái c-type riêng biệt. Trong trường hợp này là 1. Length: có độ dài gói tin là 12 được gửi đi để chứng thực 2 phiên kết nối. Với các giá trị min 0. .lsp-turnel4. Đối với đối tượng session này thì có 4 loại c-type: ipv4. Destination address: là địa chỉ đích 30. rate là 125.0. Object class: chính là tên đối tượng capture được.0. Tính bằng đơn vị là bytes/s.

Length là độ dài gói tin làm tươi với chu kỳ 1 gói là 30000 mili second/goi để gửi thông diệp path hay resv. . Xác đinh trong rfc2210. Chỉ xác định trong thông điêp path. Cái này tuong tự sender tpsec. Dối tượng Hop có tác dụng báo cho router nhận biết rằng sau địa chỉ tiếp theo của router gửi mà gói tin sẽ phải đi qua. VD Có 3 router theo thứ tự A. Chu kỳ refresh. B. Trong rfc2205. Length of service 1 data: độ dài của mạng trong 1 dữ liệu là 6 từ.53 - . C thì giá trị trườngNext Hop của gói tin RIPv2 Update mà B gửi cho A sẽ là địa chỉ của C. Length ở đây chính là byte dùng trong thông điệp path.Data length: Độ dài dữ liệu truyền đi là 7 từ.

Lớp này được xác định trong RFC 2205 c-type :1 . và RFC 3209 xác định C-Type 7. Ý nghĩa là tin nhăn đực gửi đi. Có giá trị là 8bit. LSP Tunnel IPv4. . • Sending TTL: 2532 Có giá trị là 8bit. • Message checksum: 0x943d Có giá trị là 16bit. • RSVP version: 1 Có giá trị là 4bit. Đây là kiểu gói tin Path Tear. Path Tear: Hình 5: Giao diện gói tin Path Tear.54 - .2. Có cùng định dạng và mục đích như lớp FILTER_SPEC nhưng khác hướng. Khi tất cả giá trị = 0 thì checksum không được truyền đi. số phiên bản giao thức là 1 • Flag: 00 Có giá trị 4bit • Message type: Path message. 3.

168.1.1 Tương tự gói tin Path Resv.1. Chỉ khác địa chỉ cạnh là 192. 164 Là tổng chiều dài của gói tin RSVP trong byte.3 Tương tự gói tin Path Resv.55 - .• Message length: 164 Có giá trị là 16bit.168. Tương tự gói tin Path Resv . Tương tự gói tin Path Message. Chỉ khác địa chỉ đích là 192.

56 - . max 1500. Tương tự gói tin Path Resv . Data length: Độ dài dữ liệu truyền đi là 7 từ. Với các giá trị min 0. Length of service 1 data: độ dài của mạng trong 1 dữ liệu là 6 từ. rate là 1250.Cái này thường xuất hiện trong thông điệp Path.

57 - . Đây là kiểu gói tin path • Message checksum: 0x80b1 Có giá trị là 16bit. 108 Là tổng chiều dài của gói tin RSVP trong byte. Resv Massage: Hình 6: Giao diện gói tin Resv. • Sending TTL: 255 Có giá trị là 8bit. Ý nghĩa là tin nhăn đực gửi đi. • Message length: 108 Có giá trị là 16bit.3. số phiên bản giao thức là 1 • Flag: 00 Có giá trị 4bit • Message type: RESV message. Khi tất cả giá trị = 0 thì checksum không được truyền đi.3. Có giá trị là 8bit. • RSVP version: 1 Có giá trị là 4bit. .

58 - .0. Là chu kì refesh.3 Protocol: trường này sử dụng giao thức TCP Tương tự gói tin Path Message như khác ở địa chỉ cạnh là 70. . C-type: Đối với Session thì các chỉ số của c-type là 1-2-7-8 và 4 loại c-type ipv4.168.lsp-turnel4.0. Tính bằng đơn vị là bytes/s.6. Object class: chính là tên đối tượng capture được. Destination address: là địa chỉ đích 192. Length: có độ dài gói tin là 12 được gửi đi để chứng thực 2 phiên kết nối. Length là độ dài gói tin làm tươi với chu kỳ 1 gói là 30000 ms/goi để gửi thông diệp path hay resv. lsp-turnel6.1. Trong trường hợp này là 1 – Ipv4.Tương tự gói tin Path Message.2 Tương tự gói tin Path Message.

Được dùng trong các thông điệp Resv.Lớp STYLE đặc tả kiểu dành riêng . Các giá trị min là 0. Data length: Độ dài dữ liệu 10 từ.59 - . Service header: 2 Parameter 127 data length: là độ dài dữ liệu tham số 127 là 5 từ. Parameter 130 data length: là độ dài dữ liệu tham số 130 là 2 từ. . max là 1500. Ở đây lớp style thuộc kiểu Fixed Filter.

FILTER_SPEC được xác định trong RFC 2205. Đây là kiểu gói tin path • Message checksum: 0xb783 Có giá trị là 16bit.32. • Sending TTL: 255 Có giá trị là 8bit. Sender Ipv4 address: 172. Resv Error: Hình 7 Giao diện gói tin Resv Error. Khi tất cả giá trị = 0 thì checksum không được truyền đi.60 - . Có giá trị là 8bit. .FILTER_SPEC chỉ dùng trong các thông điệp liên quan Resv.2 là địa chỉ ip của Sender.4.0. 3. số phiên bản giao thức là 1 • Flag: 00 Có giá trị 4bit • Message type: RESV ERROR message. • RSVP version: 1 Có giá trị là 4bit. Ý nghĩa là tin nhăn đực gửi đi.

• Message length: 112 Có giá trị là 16bit.61 - .1 Error value: giá trị lỗi là 0 Lớp STYLE đặc tả kiểu dành riêng .1. . 112 Là tổng chiều dài của gói tin RSVP trong byte. Error code: xác định mã lỗi là 3. Chỉ khác địa chỉ đích là 192. Tương tự gói tin Path Message.168. Xuất hiện lỗi ở nút 192.168. Ở đây lớp style thuộc kiểu Fixed Filter.1.3 Tương tự gói tin Tear.

62 - .3.5 RESV Tear: .

0.2 set transform-set RSVPSender-RSVPReservation match address 110 interface FastEthernet0/0 ip address 172.255.1.0 .0.0.Chương 4 Thực nghiệm ứng dụng trong QoS 4.63 - .0.0.0. Code cấu hình: • RSVPSender crypto isakmp policy 10 encr aes hash md5 authentication pre-share crypto isakmp key 123 address 70.2 no crypto isakmp ccm crypto ipsec transform-set RSVPSender-RSVPReservation ah-sha-hmac esp-aes mode transport crypto map mapvpn 10 ipsec-isakmp set peer 70.32.1 255.

0.0.0.64 - .0.2 FastEthernet0/0 10 5 .0.0.32.1 255.0 0.255.255.0.255.ip virtual-reassembly duplex auto speed auto no keepalive fair-queue 64 256 235 ip rsvp bandwidth 7500 7500 interface Serial1/0 ip address 50.32.255 area 0 network 172.168.2 TCP 0 0 172.0.0.0 ip virtual-reassembly no keepalive serial restart-delay 0 clockrate 64000 no dce-terminal-timing-enable fair-queue 64 256 37 crypto map mapvpn ip rsvp bandwidth 1158 1158 router ospf 100 log-adjacency-changes network 50.0.2 172.255 area 0 ip rsvp sender 193.32.0 0.0.

255.2 • RSVPRouter interface Serial1/0 ip address 50.0.0.255.0.0.0.0.0 0.0.0.access-list 110 permit ip 172.0.0.0.0 0.0 0.0 0.0.168.32.1 193.255 193.0.255 area 0 network 70.0.0.0.0 fair-queue 64 256 37 serial restart-delay 0 ip rsvp bandwidth 1158 1158 router ospf 100 log-adjacency-changes network 50.0.0 0.0.0.65 - .255 host 70.0.255 access-list 110 permit ip 172.32.0.0 fair-queue 64 256 37 serial restart-delay 0 ip rsvp bandwidth 1158 1158 interface Serial1/1 ip address 70.0.2 255.0.0.0.255 access-list 110 permit ip host 50.0.0.168.0.1 255.255.255.0 0.255 area 0 .

• RSVPReservation crypto isakmp policy 10 encr aes hash md5 authentication pre-share crypto isakmp key 123 address 50.0.66 - .0 ip virtual-reassembly duplex auto speed auto no keepalive fair-queue 64 256 235 .168.1 no crypto isakmp ccm crypto ipsec transform-set RSVPSender-RSVPReservation ah-sha-hmac esp-aes mode transport crypto map mapvpn 10 ipsec-isakmp set peer 50.255.0.1 set transform-set RSVPSender-RSVPReservation match address 110 interface FastEthernet0/0 ip address 193.1 255.0.0.0.255.

255 host 50.0.0.0 0.0 0.67 - .0 0.255 access-list 110 permit ip 193.1 .2 255.0.255.0.32.0.0.0.0.255 172.2 TCP 0 0 193.0 ip virtual-reassembly no keepalive serial restart-delay 0 clockrate 64000 no dce-terminal-timing-enable fair-queue 64 256 37 crypto map mapvpn ip rsvp bandwidth 1158 1158 router ospf 100 log-adjacency-changes network 70.168.0.2 172.168.0.0.168.0.255 area 0 network 192.0.32.0.0.0.0.168.0.0.255 access-list 110 permit ip host 70.32.1.0.0.ip rsvp bandwidth 7500 7500 interface Serial1/0 ip address 70.0 0.0.0 0.255.0.168.2 172.2 FastEthernet0/0 FF RATE 10 5 access-list 110 permit ip 193.0.0.0.255 area 0 ip rsvp reservation 193.0 0.0.

4.2.2. Thực nghiệm: 4.2.  PC 2 kết nối RSVPReservation. • Công cụ dùng để thực nghiệm: .  3 Router đều được cấu hình theo giao thức RSVP  Đã cài đặt NetMeeting cho 2 PC.2. 4.68 - .1.2. Mô tả:  Mô hình trên gồm 3 Router và 2 PC được gán IP như mô hình  PC 1 kết nối với RSVPSender. 4.2.2.2.1 Mục tiêu của thực nghiệm: Mục tiêu của bài thực nghiệm này là ứng dụng giao thức Resource Reservation Protocol cho QoS và dùng NetMeeting để tố chức cuộc họp thông qua Internet.Mô hình: Hình 8: Mô hình thực nghiệm. Thực nghiệm: 4. Đảm bảo chất lượng của việc truyền tín hiệu voice.2.

 Xem danh sách các thành viên hiện có mặt trên hệ thống mạng thông qua danh sách SpeedDial. hội nghị và làm việc chung thông qua Internet.Card Mạng .NetMeeting: Dùng để trao đổi thông tin giữa 2 PC với nhau Giới thiệu NetMeeting Chương trình Microsoft NetMeeting cung cấp một phương thức hòan tòan mới trong việc hội thọai .  Gửi file và message cho các thành viên trong hội thảo.CPU Pentium IV . . Microsoft NetMeeting hỗ trợ :  Gọi cho người khác thông qua hệ thống mạng hay modem.5.Sử dụng IOS 3600 cho Router. .GNS3 (giả lập Router thật).Phần mềm: .  Tổ chức hội thảo với nhiều người khác thông qua Internet.  Sử dụng trình Whiteboard để vẽ và diễn tả ý tưởng của mình trong cuộc hội thảo.RAM 512Mb .3 chạy source WinXP .HDD 40G .  Làm việc chung và chia xẻ tài liệu với nhiều người trên cùng một ứng dụng .69 - .  Nhìn thấy người đang nói chuyện với mình.Vmware 6. Thiết bị phần cứng: • PC cấu hình như sau: .

0 S0/0: 50..0 Router RSVP: .1 Subnet Mask 255.0.70 - .32.Headphone. Các bước thực hiện: Bước 1: Cấu hình IP cho Router theo mô hình: Router Sender: Hình 9: Giao diện telnel của Router Sender.0.0.255.0.Cable nối 2 PC: dung cable chéo.3. 4. Địa chỉ ip của các cổng như sau: F1/0: 172. .Webcam • Cable: .0.1 Subnet Mask 255.0.

Địa chỉ ip của RSVPRouter: S0/0 50.0 RSVP Reservation: Hình 11: Giao diện telnel của Router Reservation.71 - .2 Subnet Mask 255.1 Subnet Mask 255.Hình 10: Giao diện telnel của Router RSVP.0.0.0 S0/1 70. Địa chỉ ip của RSVPReservation: S0/0 70.0.0.0.0.0.0 .0.0.2 Subnet Mask 255.0.0.0.0.

168.F1/0 192.255.0 Kết quả: Các Router và PC đã kết nối với nhau.255.72 - . Bước 2: Cấu hình giao thức RSVP theo mô hình RSVP Sender: Hình 12: Banhwidth Của Router RSVPSEnder ở RSVPSender: ta cấu hình bandwidth là 7500K cho cổng FastEthernet cổng Serial ta cấu hình bandwidth 1158K RSVP Router: Hình 13: Bandwidth của RSVPRouter Cổng Serial: bandwidth là 1158K và allocated là 10K RSVP Reservation: .1 Subnet Mask 255.1.

73 - .1.1.2 đến máy 172.2 Sử dụng giao thức TCP không dùng port RSVP Router: .Hình 14: Bandwidth của RSVPReservation Cổng FastEthernet có bandwidth là 7500K Cổng Serial có bandwidth là 1158K Kết quả cài đặt RSVP từ máy 192.0.2 RSVP Sender: Hình 15: Kết quả cài đặt của Router Sender. Ta cấu hình Sender từ máy 172.168.2 sang máy 192.32.0.32.168.

Bandwidth BPS 10K RSVP Reservation: show ip rsvp reservation . Kết quả cài đặt cho RSVP Sender và RSVP Reservation: RSVP Sender: show ip rsvp sender Hình 18: Giao diện show ip rsvp sender của router Sender.74 - .Hình 16: Giao diện kết quả cài đặt của Router ở RSVPRouter sẽ làm trung gian chuyển gói tin từ PC 1 sang PC 2 thông qua gia thức TCP RSVP Reservation: Hình 17: Giao diện kết quả cài đặt của Router Reservation.

32. Kiểm tra thông tin gửi từ RSVP Sender đến RSVP Reservation: RSVP Sender: show ip rsvp request detail Hình 20: Giao diện show ip rsvp request detail của Router Sender Gói tin này thuộc giao thức TCP truyền từ 172.2 Bandwidth tối đa là 5K byte và trung bình mỗi giây bandwidth là 10K bit Kiểm tra các RSVP local của RSVP Router: show ip rsvp neighbor Hình 21 Các RSVP Kết quả: mô hình các Router đã hoạt động trên giao thức RSVP.75 - . .Hình 19: Giao diện show ip rsvp reservation của Router Reservation.1.2 sang 192. Dùng Wireshark ta bắt được các gói tin RSVP đã được phân tích ở trên.0.168.

Tốc độ trung bình là 1250 byte/second truyền được 5000byte PC2 (192.0.32.Bước 3: Các lệnh debug ip rsvp .168.168.2) .2 truyền qua không được police xử lí mà truyền qua luôn. .debug ip rsvp Path: hiển thị chi tiết nội dụng của gói tin Path được gửi đi qua các node.2) nhận gói tin Path thông qua cổng FastEthernet từ PC1 (172.debug ip rsvp detail: hiển thị chi tiết băng thông của giao thức RSVP đã cấu hình.1.1. Các gói tin từ 192. Hình 22: Giao diện debug ip rsvp detail.76 - .

Gửi gói tin Path cho PC2 (192.1.debug ip rsvp traffic-control: kiểm tra lưu lượng của giao thức RSVP .168.Hình 23: giao diện debug ip rsvp Path.77 - .2) qua cổng s0/0 Tốc độ trung bình là 1250 byte/sec nhận được 5000 bytes và peak rate là 193000 byte/sec .

78 - . - RSVPSender#sh crypto isakmp sa Hình 25-1: Giao diện VPN khi up từ Sender đến Reservation.Hình 24 : Giao diện debug ip rsvp traffic-control. Bước 4: Giao diện VPN khi up. .

Cài đặt Netmeeting cho 2 PC .Hình 25-2: Thông số của map trong Sender.79 - . Thực nghiệm giao thức Resource Reservation Protocol qua công cụ Netmeeting . Bước 5.

.Hình 26: Giao diện Netmeeting.Ở PC 1 ta gõ ip PC 2 và gọi. .Trao đổi thông tin giữa 2 PC và ta thu được kết quả thực nghiệm Demo Thực hiện demo như sau: Pc1 dùng Netmeeting gọi Pc2 Bước 1: Lúc mạng nghẽn chưa áp dụng RSVP ta được như sau: . .80 - .2 PC đã kết nối với nhau thong qua mô hình mạng như trên.

Không đều Lúc này ở PC 2 nhận âm thanh không ổn định.81 - . Kết luận khi chưa dùng RSVP thì tín hiệu không tốt khi mạng bị nghẽn .Hình 27: Dùng Wireshark bắt gói tín hiểu truyền từ Pc1 đến Pc2 Hình 28: Dùng Netflow bắt lưu lượng Khi ta gọi từ PC1 thì âm thanh được truyền đi bị đứt quãng.

82 - . âm thanh ít bị đứt quản.Bước 2: Ta áp dụng RSVP vào thì tín hiệu tốt hơn. như sau: Hình 29: Dùng WireShark bắt gói tín hiệu voice khi áp dụng RSVP Thời giant trung bình truyền mỗi gói tin là 1278 ms Lúc này dùng Netflow ta bắt được như sau: Dùng Netflow ta được như sau: Hình 30: Dùng NetFlow bắt lưu lượng RSVP Lúc này ta thấy âm thanh từ PC1 truyền đi ổn định Kết luận: giao thức RSVP hỗ trợ tốt cho audio. Kết Luận: .

Ngày nay với việc công nghệ thông tin ngày càng phát triển. do kiến thức còn hạn hẹp và thời gian cũng không nhiều nên luận văn này thực hiện chỉ dừng lại ở Ipv4. Khi mà nhu cầu về việc truyền dữ liệu ngày càng đòi hỏi về chất lượng cũng như sự nhanh chóng.83 - . Các ứng dụng thời gian thực như dòng Video (Video Streaming). v. Qua đó đề tài này giúp ta hiểu rõ hơn về giao thức RSVP. tương tác (Interactive). Một trong những xu hướng lớn nhất trong vấn đề kết nối mạng ngày nay là việc truyền cả tín hiệu thoại và video trên các mạng dữ liệu truyền thống. IPTV. các gói thoại và video cần phải phân phối đến người nhận một cách nhanh chóng và có độ tin cậy cao. 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ụ. Hướng phát triển ở tương lai là sẽ phát triển trên môi trường Ipv6 và các ứng dụng của Ipv6. Một trong những vấn đề về việc hội tụ này là cách thực hiện như thế nào. . đa phương tiện (Multimedia). Hướng phát triển đề tài: Tuy nhiên.v. đang đặt ra những thách thức mới cho cơ sở hạ tầng mạng. không có độ jitter và độ trễ vượt quá giới hạn. những ứng dụng ngày càng đòi hỏi cao về chất lượng. thoại qua IP (VoIP). cách thực hiện các ứng dụng nổi bật của giao thức.

org/ .cisco.nhatnghe.Tài liệu tham khảo: [1] http://www.ietf.84 - .com [3] http://www.com [2] http://www.com [4] http://www.vnpro.

Sign up to vote on this title
UsefulNot useful