ử 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 (ControlledLoad) 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 trafficeng 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 CType 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 tunnels LSP ID. LSP ID khi các đặc tính của đường hầm (tunnels 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 32bit, 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 20bit 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 (8byte). Đố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 0x010x08: Reserved Không có cờ bit được định nghĩa được nêu ra. Msg Type: 8 bit 1 = Path 2 = Resv 3 = PathErr 4 = ResvErr 5 = PathTear 6 = ResvTear 7 = ResvConf RSVP Checksum: 16 bits . 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, bao gồm cả tiêu đề chung và các biến dài theo sau. 2.2.2. Các gói tin RSVP: Hình 3: Router sử dụng giao thức RSVP. 2.2.2.1. Path messages Định dạng của một thông điệp Path như sau: ::= ... ::= 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. Nếu muốn gửi một thông điệp từ một nguồn về một đích, ta có thể dùng cơ chế unicast. 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, ta phải dùng broadcast. 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 phikếtnố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ừ hopbyhop 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úthop 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: ::= ... ::= | 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à packetaudio ::= ::= Ví dụ : Senders: là khoảng 10 cái server onlinepacketradiostation ở 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. ::= | ::= SE style: ::= ::= ::= | 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. ::= ::= (see earlier definition) 2.2.2.4 Resv Teardown Messages: ::= ::= (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. ::= ... ::= (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 hopbyhop để 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. ::= ... 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. WF Style : ::= FF style : ::= SE style : ::= 2.2.2.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. 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 hopbyhop kiểm tra tính toàn vẹn hop theo cơ chế. ::= ::= (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 hopbyhop 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 killerreservation. 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 hopbyhop 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. 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. 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 hopbyhop mô tả cơ chế toàn vẹn trước đó. 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. 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. NonRSVP 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 NonRSVP. Cả hai router RSVP và nonRSVP truyền thông điệp đến địa chỉ bằng việc sử dụng bảng định tuyến unimulticase. Do đó, định tuyến của đường thông điệp duyệt trên một đám mây nonRSVP. 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 nonRSVP, 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à nonRSVP 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ế outofband. 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. Chú ý đồng bộ hóa. H1 và H2 có thể xảy ra trong trật tự. 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). Sau đó, 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. 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 BackusNaur 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 16bit 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 16bit 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 hopbyhop 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ở nonRSVP đá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 nonRSVP, 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 ) > Sessionid , Upcall_Proc_addr) > Sessionid Xác định người gửi Call: SENDER( Sessionid Call , Source_Address , Source_Port , Source_Address , Source_Port , Sender_Template , Sender_Template , Sender_Tspec , Adspec , Sender_Tspec , 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. Nếu bỏ qua, một giao diện mặc định sẽ được sử dụng. Tham số này là cần thiết chỉ trên một máy chủ người gửi. Source_Port Đây là UDP cổng TCP mà từ đó các 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. Sender_Tspec Tham số này mô tả các luồng giao thông được gửi đi. 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. Data_TTL Policy_data Tham số tùy chọn các dữ liệu chính sách cho người gửi. Dữ liệu này có thể được cung cấp bởi một hệ thống dịch vụ, với việc áp dụng nó. Reserve Dự trữ Call: RESERVE( sessionid, receiver_addre