Thực nghiệm ứng dụng RSVP trên QOS

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.

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ệnNguyễ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

hướng kết nối qua mạng IP

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ề QoS1.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:

• 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 luồng và báo hiệu ở mỗi chặn 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 Vì thế mô hình Intserv chỉ được triển khai ở một số hữu hạn mạng, 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í 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ù 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) Một luồng được xác định bởi các tham số: địa chỉ IP nguồn, IP đích, cổng nguồn, cổng đích….InServ sử dụng giao thức RSVP (Resource Reservation Protocol) để báo hiệu

Khi một luồng được thiết lập thì tương ứng với 1 phiên RSVP được thiết lập, điều này dẫn đến một hạn chế là: đối với mạng có lưu lượng cao như mạng ISP hoặc các tổ chức doanh nghiệp lớn thì số lượng luồng có thể lên đến hàng trăm ngàn luồng trong một thời điểm và đẫn đến hiện tượng lãng phí tài nguyên do bandwidth

sử dụng để thiết lập kênh RSVP lên rất nhiều (RSVP không phải là luồng thoại mà chỉ là thông tin điều khiển, báo hiệu) Hạn chế của mô hình IntServ với hệ thống mạng có số lượng flow lớn Mặc dù InServ là mô hình đảm bảo chất lượng dịch vụ tuyệt đối, từ đầu cuối đến đầu cuối (end-to-end), nhưng nó không linh hoạt và khả năng mở rộng thấp nên thường không được lựa chọn để thực hiện QoS trong mạng

 Đảm bảo chất lượng dịch vụ tuyệt đối, từ đầu cuối đến đầu cuối end)

(end-to-1.4.2 Khuyết Điểm:

 Tốn tài nguyên mạng vô ích

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

Chương 2: Giao thức RSVP2.1 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 RSVP không phải là một giao thức định tuyến Việc quyết định tuyến do IGP (gồm

cả các mở rộng TE) và CSPF

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 Trong MPLS TE, RSVP dự trữ băng thông tại mặt phẳng điều khiển (control-plane layer); không có chính sách lưu lượng trên mặt phẳng chuyển tiếp (forwarding-plane) Khi sử dụng cho các mục đích khác (như VoIP hay DLSW+reservations), 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

Hình 2: RSVP trong Hosts và Routers.

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) Nghĩa là cần tái báo hiệu trên mạng để làm tươi định kỳ cho nó Với RSVP, 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 thời gian dành riêng (reservation times out)

2.2 Giao thức RSVP

2.2.1.Chức năng RSVP

2.2.1.1 Các lớp đối tượng của RSVP:

 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 - ms để gửi thông điệp Path hay Resv

 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 RFC 3209 định nghĩa mã lỗi 24, đặc tả lỗi cho MPLS TE Trong MPLS TE, 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 Khi mã lỗi (error code) là 00, giá trị lỗi (error value) cũng là 00 Khi mã lỗi là 24 thì có thể có 10 giá trị 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) Thông thường trường Flags bằng 0 khi sử dụng MPLS TE

 Lớp SCOPE: RFC 2205 xác định lớp SCOPE Lớp SCOPE thực hiện kiểu dành riêng wildcard (wildcard reservation style)

 Lớp STYLE:Lớp STYLE đặc tả kiểu dành riêng Có thể có 3 loại:

• Wildcard Filter

• Fixed Filter

• Shared Explicit

Cisco IOS Software sử dụng Shared Explicit cho sự dành riêng MPLS TE Trường Flags không được sử dụng Option Vector luôn bằng 0x12, chỉ định loại Share Explicit

 Lớp FLOWSPEC:Lớp FLOWSPEC được xác định trong RFC 2210 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 Định dạng FLOWSPEC phức tạp và có nhiều thứ trong đó mà RSVP cho MPLS TE không sử dụng FLOWSPEC được dùng trong các thông điệp Resv - Resv, ResvTear, ResvErr, ResvConf, ResvTearConf MPLS

TE sử dụng phần tốc độ trong bình của FLOWSPEC để chỉ định băng thông mong muốn, tính bằng byte (không phải bit) Vì thế nếu bạn cấu hình với tunnel mpls traffic-eng 100000 để yêu cầu 100 Mbps băng thông, nó phát tín hiệu 12,500,000 bytes trong một giây (100 Mb = 100,000 Kb = 100,000,000 bits = 12,500,000 bytes)

 Lớp FILTER_SPEC: Lớp FILTER_SPEC được xác định trong RFC 2205 RFC 3209 thêm vào C-Type 7, LSP Tunnel IPv4 Trường IPv4 Tunnel Sender Address cho biết router ID của đầu đường hầm TE (TE tunnel headend), và trường LSP ID cho biết tunnel's LSP ID LSP ID khi các đặc tính của đường hầm (tunnel's properties) thay đổi (băng thông, đường đi thay đổi) FILTER_SPEC chỉ dùng trong các thông điệp liên quan Resv (ResvTear, ResvErr, )

 Lớp SENDER_TEMPLATE: Thường chỉ thấy lớp SENDER_TSPEC trong thông điệp Path Giống như FLOWSPEC, MPLS TE chỉ quan tâm tới phần tốc độ trung bình (average rate section)

 Lớp ADSPEC: Xác định trong RFC 2210 Giống SENDER_TSPEC, ADSPEC chỉ dùng trong các thông điệp Path

 Lớp RESV_CONFIRM: RESV_CONFIRM được xác định trong RFC 2205

Nó gửi tín hiệu yêu cầu một chấp nhận (confirmation); nó xuất hiện trong các thông điệp Resv và ResvTear Lớp RESV_CONFIRM thỉnh thoảng xem như CONFIRM

 Lớp RSVP_LABEL: Lớp RSVP_LABEL (thỉnh thoảng được gọi là LABEL) được xác định trong RFC 3209 kích thước 32-bit, mọi đối tượng RSVP phải là bội số của 4 byte, nhưng trong chế độ khung (frame mode), nó mang nhãn 20-bit dùng cho một đường hầm cụ thể (particular tunnel) Lớp RSVP_LABEL chỉ có trong thông điệp Resv.

 Lớp LABEL_REQUEST:Đối tượng LABEL_REQUEST yêu cầu một nhãn 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 Nó chứa, trong 16 bit cao, Layer 3 Protocol Identifier (L3PID) được mang trong nhãn Cisco IOS luôn báo hiệu 0x800 (IP); 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, thường được gọi là ERO, và được xác định trong RFC 3209.ERO chỉ có trong thông điệp Path ERO là một tập các đối tượng con (8-byte) Đối tượng con IPv4 Prefix hiện tại chỉ được hỗ trợ bởi Cisco IOS

2.2.1.2 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

Msg Type: 8 bit

1 = Path

2.2.2.1 Path messages

Định dạng của một thông điệp Path như sau:

<Path Message> ::= <Common Header> [ <INTEGRITY> ]

• 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 Đị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 Một thiết bị L2 switch không thể nhận biết được vị trí của địa chỉ multicast đích Tất cả các gói sẽ được phát tán ra tất cả các port ở chế độ mặc định

• Các traffic dạng multicast thường là một chiều (unidirectional) Do có nhiều host nhận cùng một dữ liệu, 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 Một host đích sẽ trả traffic ngược về nguồn theo cơ chế unicast Cơ chế multicast cũng sẽ được truyền theo kiểu phi-kết-nối (connectionless) Multicast dùng UDP chứ không dùng TCP

• 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

 Unicast Sessions:

• Các gói tin được gửi từ một địa chỉ nguồn đến một địa chỉ đích 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 Nếu một thiết bị là L2, nó chỉ cần dựa vào địa chỉ MAC

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

• Phương thức dùng unicast không có khả năng mở rộng

2.2.2.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, dọc theo đường dẫn ngược của lớp dữ liệu Đị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, thu được từ đường dẫn Các nguồn địa chỉ IP là một địa chỉ của các nút gửi tin nhắn

Đị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> ]

<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, 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 Sau này tất cả các sender sẽ share nhau tài nguyên này Cách dành riêng này phù hợp với các ứng dụng unicast như là packet-audio

<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

Các router trung gian hỗ trợ RSVP

 FF style: thiết lập một kênh dành riêng cho các sender ở phía trên, nhưng việc dành riêng này là có lựa chọn sender

<flow descriptor list> ::=

<SE flow descriptor> ::=

<FLOWSPEC> <filter spec list>

<filter spec list> ::= <FILTER_SPEC>

| <filter spec list> <FILTER_SPEC>

2.2.2.3 Path Teardown Messages:

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,

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 Thông điệp ResvTear được gửi để hồi đáp cho PathTear báo hiệu đuôi đường hầm PathTear và ResvTear cũng được gửi để trả lời một điều kiện lỗi trong mạng

<PathTear Message> ::= <Common Header> [ <INTEGRITY> ]

<SESSION> <RSVP_HOP>

[ <sender descriptor> ]

<sender descriptor> ::= (see earlier definition)

2.2.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.2.2.5 Path Error Messages:

Thỉnh thoảng, tín hiệu RSVP có thể bị lỗi Các lỗi này được báo hiệu bằng thông điệp PathErr hay ResvErr Thông điệp lỗi được gửi ngược dòng về phía nguồn của lỗi; 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

<PathErr message> ::= <Common Header> [ <INTEGRITY> ]

<SESSION> <ERROR_SPEC>

[ <POLICY_DATA> ]

[ <sender descriptor> ]

<sender descriptor> ::= (see earlier definition)

2.2.2.6 Resv Error Messages

Resv Error Messages báo lỗi trong việc xử lý tin nhắn, hoặc nó có thể báo

tự động đến dự trữ tài nguyên

Resv Error Messages phân luồng thích hợp xuống cho người nhận, sử dụng giao thức hop-by-hop để dự trữ trước tài nguyên Tại mỗi hop , địa chỉ đích IP là địa chỉ là địa chỉ Unicast của một nút hop tiếp theo.

<ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]

<SESSION> <RSVP_HOP>

<ERROR_SPEC> [ <SCOPE> ]

[ <POLICY_DATA> ]

<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ả, đối tượng được yêu cầu để được như mô tả trước đó được phân vào một luồng

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

Một tin nhắn ResvConf được gửi đến địa chỉ unicast của một host nhận, địa chỉ được thu được từ các đối tượng RESV_CONFIRM Tuy nhiên, một tin nhắn ResvConf được chuyển cho hop nhận, để chứa các hop-by-hop kiểm tra tính toàn vẹn hop theo cơ chế

<ResvConf message> ::= <Common Header> [ <INTEGRITY> ]

<SESSION> <ERROR_SPEC>

<RESV_CONFIRM>

<STYLE> <flow descriptor list>

<flow descriptor list> ::= (see earlier definition)

2.2.3.Teardown

Gói tin RSVP "teardown" loại bỏ Path hoặc Reservation ngay lập tức Mặc dù

nó không cần thiết phải rõ ràng, đề 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 Có hai loại gói tin teardown RSVP là

PathTear và ResvTear 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, cũng như tất cả các tiểu bang đặt phòng phụ thuộc, dọc theo đường Một gói tin ResvTear xóa các nút mà nó nhận được 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.

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), hoặc bằng một router là kết quả của thời gian chờ của dịch vụ Một khi bắt đầu, một teardown yêu cầu phải được chuyển tiếp hop-by-hop không chậm trễ Một teardown xóa quy định tại các nút mà nó là nhận được Như mọi khi, sự thay đổi này sẽ được tuyên truyền ngay lập tức đến nút kế tiếp, nhưng chỉ khi nào sẽ có một mạng lưới thay đổi sau khi sát nhập Kết quả là, một gói tin ResvTear prune trở lại

Giống như tất cả các gói tin RSVP khác, yêu cầu không được giao teardown đáng tin cậy 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 Nếu một gói tin teardown bị mất, 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 Giả sử xác suất RSVP mất tin là nhỏ, 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

Một gói tin ResvTear xác định được phong cách và bộ lọc; bất kỳ flowspecđược bỏ qua Flowspec Dù là ở vị trí này sẽ được loại bỏ nếu tất cả specs của nó lọc được

2.2.4 Lỗi:

Có hai RSVP thông báo lỗi là ResvErr và PathErr Tin hiệu PathErr rất đơn giản, 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 Chỉ có một vài nguyên nhân có thể có lỗi đường dẫn.

Tuy nhiên, 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 Một nút cũng có thể quyết định có quyền đặt phòng được thành lập Việc xử lý gói tin ResvErr là phức tạp 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, một lỗi đặt phòng phải được báo cáo đến tất cả những người nhận Ngoài ra, 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 reservation", trong đó một trong những yêu cầu có thể từ chối dịch vụ khác Thực tế, có hai killer-reservation

2.2.5 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 Để ngăn ngừa sự lạm quyền, 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ữ Vd vài sự

ép buộc được thiết lập bởi chính sách quyền admin, 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, 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

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 Khi có 1 việc lưu trữ mới đc yêu cầu, 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” Đồng thời, cả

2 phải thuận lợi cho RSVP thực hiện việc lưu trữ

2.2.6 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 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ã 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, mà giả định rằng RSVP chia sẻ một bí mật Mặc dù cơ chế này là một phần của cơ sở của RSVP, đặc điểm kỹ thuật của nó được miêu tả trong một tài liệu đồng hành [Baker96]

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 Cho đến khi trở thành

cơ sở hạ tầng hiện có, 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

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 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ệ Đặc điểm kỹ thuật của giấy chứng nhận là một vấn đề trong tương lai

Mặc dù không có giấy chứng nhận trên toàn cầu, 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, sử dụng hop-by-hop mô tả cơ chế toàn vẹn trước

đó

Hai vấn đề đầu tiên bảo mật liên quan hoạt động của RSVP Một vấn đề quan ngại an ninh thứ ba đặt nguồn suối an toàn cho dữ liệu Đặc biệt, 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, 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

Để giải quyết vấn đề này, 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

2.2.7 Non-RSVP clouds:

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 Hơn nữa, RSVP không bao giờ có thể được triển khai ở khắp mọi nơi RSVP do đó phải cung cấp giao thức hoạt động chính xác, 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 Tất nhiên, 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 Tuy nhiên, nếu như một đám mây có đủ năng lực, nó vẫn có thể cung cấp dịch vụ hữu ích gian thực

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 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 Do đó, định tuyến của đường thông điệp duyệt trên một đám mây non-RSVP 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

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, thì những nút có khả năng sẽ có trong general perturb mà QoS cung cấp đến bên nhận

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, 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 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, 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 Để xử lý các trường hợp giao diện sai, một "Hợp Lý Giao diện Handle" (LIH) được sử dụng 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ả các giá trị được lưu trữ trong tiểu đường 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, nghĩa là các giao diện đó sẽ nhận được các yêu cầu đặt.

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, để đồ giữa lớp IP và lưu lượng liên kết các thực thể lớp

2.2.8 Host mẫu:

Trước khi một phiên họp có thể được tạo ra, việc xác định phiên làm việc (DestAddress, ProtocolId [, 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 Khi một phiên RSVP được thiết lập, các sự kiện sau đây xảy ra tại các hệ thống kết thúc

 H1 nhận A tham gia nhóm multicast được chỉ định bởi DestAddress, using IGMP DestAddress, sử dụng IGMP

 H2 Một người gửi tiềm năng RSVP Path bắt đầu gửi tin nhắn đến

DestAddress

 H3 Một ứng dụng máy thu nhận được một thông điệp Path

 H4 nhận phù hợp Resv bắt đầu gửi tin nhắn

 H5 Một ứng dụng gửi nhận tin nhắn Resv

 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, 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 đó, các dữ liệu ban đầu có thể vào thu mà không có QoS mong muốn Người gửi có thể giảm nhẹ vấn đề này bằng cách chờ đến của tin nhắn Resv đầu tiên (H5) trước khi nhận bất kỳ thông điệp Path (H3), RSVP sẽ trở lại các thông báo lỗi đến người nhận

2.3 Các thành phần cơ bản trong giao thức RSVP:

2.3.1 Định dạng các gói tin:

Một gói tin RSVP gồm có một tiêu đề chung, theo sau là bao gồm một số biến chiều dài, gõ "đối tượng" Các phần phụ sau xác định các định dạng của các tiêu đề phổ biến, tiêu đề đối tượng tiêu chuẩn, và mỗi loại thông điệp RSVP

Đối với mỗi loại thông điệp RSVP, 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 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ự BNF Các hàm ý một đơn đặt hàng cho các đối tượng trong tin nhắn Tuy nhiên, 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 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, nhưng chấp nhận các đối tượng trong bất kỳ thứ tự cho phép

2.3.2 Các ports được sử dụng:

Một phiên RSVP thường được xác định bởi ba: (DestAddress, ProtocolId, DstPort) 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) 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

RSVP cho phép bất kỳ giá trị cho ProtocolId Tuy nhiên, 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, và đặc biệt là các giá trị cho UDP và TCP (17 và 6 tương ứng) 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:

• xác định khác không DstPort cho một giao thức mà không có UDP / TCP

• xác định một số không DstPort cho một giao thức rằng không có gì có UDP / TCP

Lọc số kỹ thuật và người gửi mẫu xác định các cặp: (SrcAddress, SrcPort), nơi SrcPort là một UDP / TCP nguồn cổng trường (tức là, một số lượng 16-bit thực tại octet offset 0 trong tiêu đề giao thông) SrcPort có thể được bỏ qua (thiết lập để không) trong các trường hợp nhất định

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

2.3.3 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 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, 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, 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, PathTear, và ResvConf phải được gửi với tùy chọn Router IP Alert trong tiêu đề IP 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

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 Tuy nhiên, đâ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) 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

Trong phiên bản này của spec, mỗi gói tin RSVP phải chiếm datagram IP một cách chính xác Nếu nó vượt quá MTU, 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, đ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, khoảng 64K byte

• Không bị ngăn trở non-RSVP đám mây có thể mất mảnh tin cá nhân, và bất

kỳ đoạn bị mất sẽ mất toàn bộ tin nhắn

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 Dưới tình trạng quá tải mạng, 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 Để kiểm soát việc chậm trễ xếp hàng

và thả các gói RSVP, router phải được cấu hình để cung cấp cho một lớp ưa thích của dịch vụ 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, 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

2.3.4 Các gói tin báo Loops:

Chuyển tiếp tin nhắn RSVP phải tránh Looping Trong trạng thái ổn định, 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 Điều này tránh các gói Looping, nhưng vẫn là một khả năng tự động làm mới loop Như tự động làm mới hoạt động "mãi mãi", ngay cả khi các nút cuối cùng

đã kết thúc làm mới nó, 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 Mặt khác, 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

Thông tin từng loại tin

• 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ì 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, mà chúng ta bỏ qua ở đây), ngay cả trong một topo với chu kỳ

• 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 PathErr

Kể từ khi thông điệp Path không lặp, 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 PathErr luôn hướng đến người gửi cụ thể và

do đó có thể không lặp

• Gói tin Resv

Gói tin Resv trực tiếp tới người gửi cụ thể (tức là, với lựa chọn người gửi rõ ràng) có thể không lặp Tuy nhiên, 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

• Gói tin ResvTear

Mặc dù gói tin ResvTear được định tuyến cũng giống như gói tin Resv, 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ỏ Do đó không có vấn đề Looping ở đây

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

2.3.5 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, và nhà nước địa phương đời L 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 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

2.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 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; sau đây có thể đề nghị các chức năng cơ bản thực hiện Một số thông tin để gây ra các cuộc gọi được trả lại không đồng bộ

• Đăng ký kỳ họp

Call: SESSION( DestAddress , ProtocolId, DstPort

[ , SESSION_object ]

[ , Upcall_Proc_addr ] ) -> Session-id [, Upcall_Proc_addr]) -> Session-id

• Xác định người gửi

Call: SENDER( Session-id Call

[ , Source_Address ] [ , Source_Port ] [, Source_Address] [, Source_Port]

[ , Sender_Template ] [, Sender_Template]

[ , Sender_Tspec ] [ , Adspec ] [, Sender_Tspec] [, Adspec]

Tham số này mô tả các luồng giao thông được gửi đi

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), nó là địa chỉ IP của một trong các giao diện của nút Các `Policy_data’ dữ liệu xác định chính sách cho người nhận Các cuộc gọi trả về dự trữ ngay lập tức Sau một cuộc gọi Reserve, một lỗi hay sư kiện không đồng bộ có thể xảy ra bất cứ lúc nào

• Release Thoát

Call: RELEASE( session-id )