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.
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
[ , 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.
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
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: <Upcall_Proc>( ) -> 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: <Upcall_Proc>( ) -> 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.
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: <Upcall_Proc>( ) -> 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.
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: <Upcall_Proc>( ) -> 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: <Upcall_Proc>( ) -> 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)
• 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ã