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

ed 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 = 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 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: ::= [ ] [ ] [ ] [ ... ] ::= | 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 ::= ::= 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. ::= | ::= [ ] 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 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. ::= [ ] [ ] [ ...] [ ] 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ậnyê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ế. ::= [ ] ::= (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. 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 hop-by-hop 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. 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. 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 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] 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( session-id, [ receiver_address , ] [ CONF_flag, ] [ Policy_data, ] 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 '. Cuộc gọi Reserve đầu tiên sẽ bắt đầu việc truyền định kỳ các gói tin Resv. 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). 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 ) Cuộc gọi này loại bỏ RSVP cho các session xác định bởi session-id. 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: ( ) -> session-id, Info_type, Hiện nay, năm loại upcall, phân biệt bởi các tham số Info_type. Việc lựa chọn các thông số thông tin tùy thuộc vào loại này. 1. 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, 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. Upcall: ( ) -> session-id, Info_type=PATH_EVENT, Sender_Tspec, Sender_Template Sender_Tspec, Sender_Template [ , Adspec ] [ , Policy_data ] Upcall này trình bày các Sender_Tspec, các Sender_Template, các Adspec, và dữ liệu từ chính sách bất kỳ một thông điệp Path. 2. 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, hoặc bằng cách sửa đổi của một reservation trước, cho session này. Upcall: ( ) -> session-id, Info_type=RESV_EVENT, Style, Flowspec, Filter_Spec_list [ , Policy_data ] Đây `Flowspec 'sẽ là QoS có hiệu quả mà nó đã được nhận. Lưu ý rằng một gói tin FF-Resv có thể dẫn đến upcalls nhiều RESV_EVENT, một cho mỗi dòng mô tả. 3. 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. Upcall: ( ) -> session-id, Info_type=PATH_ERROR, Error_code , Error_value , Error_Node , Sender_Template [ , 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 về lỗi. Tham số Error_Node sẽ ghi rõ địa chỉ IP của nút đó phát hiện các lỗi. Policy_data_list tham số, nếu có sẽ chứa bất kỳ đối tượng POLICY_DATA từ gói tin Path đã thất bại. 4. Info_type = RESV_ERR An Resv Error event indicates an error in a reservation message to which this application contributed. 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: ( ) -> session-id, Info_type=RESV_ERROR, Error_code , Error_value , Error_Node , Error_flags , Flowspec, Filter_spec_list [ , 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. 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. 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. Filter_spec_list. List_count sẽ chỉ định số FILTER_SPECS trong Filter_spec_list. Tham số Policy_data_list sẽ chứa bất kỳ đối tượng POLICY_DATA từ gói tin ResvErr. 5. 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. Upcall: ( ) -> session-id, Info_type=RESV_CONFIRM, Style, List_count, Flowspec, Filter_spec_list [ , Policy_data ] 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 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: 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. 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. Chương 3 Phân Tích Các Gói Tin RSVP 3.1. Path Message: Hình 4 Giao diện gói tin Path Message. RSVP version: 1 Có giá trị là 4bit, số phiên bản giao thức là 1 Flag: 00 Có giá trị 4bit Message type: PATH message. Có giá trị là 8bit. Đây là kiểu gói tin path Message checksum: 0xe590 Có giá trị là 16bit. Khi tất cả giá trị = 0 thì checksum không được truyền đi. Sending TTL: 225 Có giá trị là 8bit. Ý nghĩa là tin nhắn được gửi đi. Message length: 108 Có giá trị là 16bit. 108 Là tổng chiều dài của gói tin RSVP trong byte. Trong RSVP thì các đối tượng có cùng định dạng như trên vậy. Và mối đối tượng thì có 1 cái c-type riêng biệt. Đối với đối tượng session này thì có 4 loại c-type: ipv4,6,lsp-turnel4, lsp-turnel6. Length: có độ dài gói tin là 12 được gửi đi để chứng thực 2 phiên kết nối. Tính bằng đơn vị là bytes/s. Object class: chính là tên đối tượng capture được. C-type: Đối với Session thì các chỉ số của c-type là 1-2-7-8. Trong trường hợp này là 1. Destination address: là địa chỉ đích 30.0.0.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. Với các giá trị min 0, max 1500, rate là 125. Data length: Độ dài dữ liệu truyền đi là 7 từ. Length of service 1 data: độ dài của mạng trong 1 dữ liệu là 6 từ. Cái này tuong tự sender tpsec. Chỉ xác định trong thông điêp path. Length ở đây chính là byte dùng trong thông điệp path. Xác đinh trong rfc2210. Chu kỳ refresh. Trong rfc2205. 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. 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, B, 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. Lớp này được xác định trong RFC 2205 c-type :1 , và RFC 3209 xác định C-Type 7, LSP Tunnel IPv4. Có cùng định dạng và mục đích như lớp FILTER_SPEC nhưng khác hướng. 3.2. Path Tear: Hình 5: Giao diện gói tin Path Tear. RSVP version: 1 Có giá trị là 4bit, số phiên bản giao thức là 1 Flag: 00 Có giá trị 4bit Message type: Path message. Có giá trị là 8bit. Đây là kiểu gói tin Path Tear. Message checksum: 0x943d Có giá trị là 16bit. Khi tất cả giá trị = 0 thì checksum không được truyền đi. Sending TTL: 2532 Có giá trị là 8bit. Ý nghĩa là tin nhăn đực gửi đi. Message length: 164 Có giá trị là 16bit. 164 Là tổng chiều dài của gói tin RSVP trong byte. Tương tự gói tin Path Message. Chỉ khác địa chỉ đích là 192.168.1.3 Tương tự gói tin Path Resv. Chỉ khác địa chỉ cạnh là 192.168.1.1 Tương tự gói tin Path Resv. Tương tự gói tin Path Resv Cái này thường xuất hiện trong thông điệp Path. Với các giá trị min 0, max 1500, rate là 1250. Data length: Độ dài dữ liệu truyền đi là 7 từ. Length of service 1 data: độ dài của mạng trong 1 dữ liệu là 6 từ. Tương tự gói tin Path Resv 3.3. Resv Massage: Hình 6: Giao diện gói tin Resv. RSVP version: 1 Có giá trị là 4bit, số phiên bản giao thức là 1 Flag: 00 Có giá trị 4bit Message type: RESV message. Có giá trị là 8bit. Đây là kiểu gói tin path Message checksum: 0x80b1 Có giá trị là 16bit. Khi tất cả giá trị = 0 thì checksum không được truyền đi. 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. 108 Là tổng chiều dài của gói tin RSVP trong byte. Tương tự gói tin Path Message. Length: có độ dài gói tin là 12 được gửi đi để chứng thực 2 phiên kết nối. Tính bằng đơn vị là bytes/s. Object class: chính là tên đối tượng capture được. 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,6,lsp-turnel4, lsp-turnel6. Trong trường hợp này là 1 – Ipv4. Destination address: là địa chỉ đích 192.168.1.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.0.0.2 Tương tự gói tin Path Message. Là chu kì refesh. 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. Lớp STYLE đặc tả kiểu dành riêng . Ở đây lớp style thuộc kiểu Fixed Filter. Được dùng trong các thông điệp Resv. Data length: Độ dài dữ liệu 10 từ. Service header: 2 Parameter 127 data length: là độ dài dữ liệu tham số 127 là 5 từ. Các giá trị min là 0, max là 1500. Parameter 130 data length: là độ dài dữ liệu tham số 130 là 2 từ. FILTER_SPEC chỉ dùng trong các thông điệp liên quan Resv. FILTER_SPEC được xác định trong RFC 2205. Sender Ipv4 address: 172.32.0.2 là địa chỉ ip của Sender. 3.4. Resv Error: Hình 7 Giao diện gói tin Resv Error. RSVP version: 1 Có giá trị là 4bit, số phiên bản giao thức là 1 Flag: 00 Có giá trị 4bit Message type: RESV ERROR message. Có giá trị là 8bit. Đây là kiểu gói tin path Message checksum: 0xb783 Có giá trị là 16bit. Khi tất cả giá trị = 0 thì checksum không được truyền đi. Sending TTL: 255 Có giá trị là 8bit. Ý nghĩa là tin nhăn đực gửi đi. Message length: 112 Có giá trị là 16bit. 112 Là tổng chiều dài của gói tin RSVP trong byte. Tương tự gói tin Path Message. Chỉ khác địa chỉ đích là 192.168.1.3 Tương tự gói tin Tear. Error code: xác định mã lỗi là 3. Xuất hiện lỗi ở nút 192.168.1.1 Error value: giá trị lỗi là 0 Lớp STYLE đặc tả kiểu dành riêng . Ở đây lớp style thuộc kiểu Fixed Filter. 3.5 RESV Tear: Chương 4 Thực nghiệm ứng dụng trong QoS 4.1. Code cấu hình: RSVPSender crypto isakmp policy 10 encr aes hash md5 authentication pre-share crypto isakmp key 123 address 70.0.0.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.0.0.2 set transform-set RSVPSender-RSVPReservation match address 110 interface FastEthernet0/0 ip address 172.32.0.1 255.255.0.0 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.0.0.1 255.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.0.0 0.255.255.255 area 0 network 172.32.0.0 0.0.255.255 area 0 ip rsvp sender 193.168.0.2 172.32.0.2 TCP 0 0 172.32.0.2 FastEthernet0/0 10 5 access-list 110 permit ip 172.32.0.0 0.0.0.255 193.168.0.0 0.0.0.255 access-list 110 permit ip host 50.0.0.1 193.168.0.0 0.0.0.255 access-list 110 permit ip 172.32.0.0 0.0.0.255 host 70.0.0.2 RSVPRouter interface Serial1/0 ip address 50.0.0.2 255.0.0.0 fair-queue 64 256 37 serial restart-delay 0 ip rsvp bandwidth 1158 1158 interface Serial1/1 ip address 70.0.0.1 255.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.255.255.255 area 0 network 70.0.0.0 0.255.255.255 area 0 RSVPReservation crypto isakmp policy 10 encr aes hash md5 authentication pre-share crypto isakmp key 123 address 50.0.0.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.0.0.1 set transform-set RSVPSender-RSVPReservation match address 110 interface FastEthernet0/0 ip address 193.168.0.1 255.255.255.0 ip virtual-reassembly duplex auto speed auto no keepalive fair-queue 64 256 235 ip rsvp bandwidth 7500 7500 interface Serial1/0 ip address 70.0.0.2 255.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 70.0.0.0 0.255.255.255 area 0 network 192.168.1.0 0.0.0.255 area 0 ip rsvp reservation 193.168.0.2 172.32.0.2 TCP 0 0 193.168.0.2 FastEthernet0/0 FF RATE 10 5 access-list 110 permit ip 193.168.0.0 0.0.0.255 172.32.0.0 0.0.0.255 access-list 110 permit ip host 70.0.0.2 172.32.0.0 0.0.0.255 access-list 110 permit ip 193.168.0.0 0.0.0.255 host 50.0.0.1 4.2. Thực nghiệm: 4.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 bảo chất lượng của việc truyền tín hiệu voice. 4.2.2. Thực nghiệm: 4.2.2.1.Mô hình: Hình 8: Mô hình thực nghiệm. 4.2.2.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. PC 2 kết nối RSVPReservation. 3 Router đều được cấu hình theo giao thức RSVP Đã cài đặt NetMeeting cho 2 PC. Công cụ dùng để thực nghiệm: Phần mềm: GNS3 (giả lập Router thật). Vmware 6.5.3 chạy source WinXP Sử dụng IOS 3600 cho Router. 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 , hội nghị và làm việc chung thông qua Internet. Microsoft NetMeeting hỗ trợ : Gọi cho người khác thông qua hệ thống mạng hay modem. Tổ chức hội thảo với nhiều người khác thông qua Internet. Nhìn thấy người đang nói chuyện với mình. 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 . 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. Sử dụng trình Whiteboard để vẽ và diễn tả ý tưởng của mình trong cuộc hội thảo. Gửi file và message cho các thành viên trong hội thảo. Thiết bị phần cứng: PC cấu hình như sau: CPU Pentium IV RAM 512Mb HDD 40G Card Mạng Headphone. Webcam Cable: Cable nối 2 PC: dung cable chéo. 4.3. 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. Địa chỉ ip của các cổng như sau: F1/0: 172.32.0.1 Subnet Mask 255.255.0.0 S0/0: 50.0.0.1 Subnet Mask 255.0.0.0 Router RSVP: Hình 10: Giao diện telnel của Router RSVP. Địa chỉ ip của RSVPRouter: S0/0 50.0.0.2 Subnet Mask 255.0.0.0 S0/1 70.0.0.0.1 Subnet Mask 255.0.0.0 RSVP Reservation: Hình 11: Giao diện telnel của Router Reservation. Địa chỉ ip của RSVPReservation: S0/0 70.0.0.2 Subnet Mask 255.0.0.0 F1/0 192.168.1.1 Subnet Mask 255.255.255.0 Kết quả: Các Router và PC đã kết nối với nhau. 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: 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.168.1.2 đến máy 172.32.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.32.0.2 sang máy 192.168.1.2 Sử dụng giao thức TCP không dùng port RSVP Router: 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. 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. Bandwidth BPS 10K RSVP Reservation: show ip rsvp reservation Hình 19: Giao diện show ip rsvp reservation của Router Reservation. 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.32.0.2 sang 192.168.1.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. Dùng Wireshark ta bắt được các gói tin RSVP đã được phân tích ở trên. Bước 3: Các lệnh debug ip rsvp debug ip rsvp detail: hiển thị chi tiết băng thông của giao thức RSVP đã cấu hình. Hình 22: Giao diện debug ip rsvp detail. Các gói tin từ 192.168.1.2 truyền qua không được police xử lí mà truyền qua luôn. Tốc độ trung bình là 1250 byte/second truyền được 5000byte PC2 (192.168.1.2) nhận gói tin Path thông qua cổng FastEthernet từ PC1 (172.32.0.2) 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. Hình 23: giao diện debug ip rsvp Path. Gửi gói tin Path cho PC2 (192.168.1.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 debug ip rsvp traffic-control: kiểm tra lưu lượng của giao thức RSVP Hình 24 : Giao diện debug ip rsvp traffic-control. Bước 4: Giao diện VPN khi up. RSVPSender#sh crypto isakmp sa Hình 25-1: Giao diện VPN khi up từ Sender đến Reservation. Hình 25-2: Thông số của map trong Sender. Bước 5. Thực nghiệm giao thức Resource Reservation Protocol qua công cụ Netmeeting Cài đặt Netmeeting cho 2 PC Hình 26: Giao diện Netmeeting. 2 PC đã kết nối với nhau thong qua mô hình mạng như trên. Ở 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: 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. Không đều Lúc này ở PC 2 nhận âm thanh không ổn định. 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 Bước 2: Ta áp dụng RSVP vào thì tín hiệu tốt hơn, âm thanh ít bị đứt quả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, những ứng dụng ngày càng đòi hỏi cao về chất lượng. 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. 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, 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, không có độ jitter và độ trễ vượt quá giới hạn. 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. Qua đó đề tài này giúp ta hiểu rõ hơn về giao thức RSVP, cách thực hiện các ứng dụng nổi bật của giao thức. 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. Hướng phát triển đề tài: Tuy nhiê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. 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. Tài liệu tham khảo: [1] [2] [3] [4]