5. Cấu trúc của luận văn
2.2 Khám phá dịch vụ tại tầng định tuyến
Mục đích khi thêm giao thức khám phá dịch vụ vào tầng định tuyến [2] xuất phát từ thực tế là các giao thức khi truyền gói tin thường tồn tại 2 quá trình: quá trình thứ nhất là truyền thông tin dịch vụ giữa các nhà cung cấp và người yêu cầu dịch vụ; quá trình thứ hai là truyền thông tin định tuyến giữa chúng. Kết quả là một nút buộc phải thực hiện thao tác nhiều lần tiêu hao nguồn để tiếp nhận và truyền tải các gói dữ liệu. Cách tiếp cận nhằm mục đích khai thác khả năng thu thập thông tin dịch vụ cùng với thông tin định tuyến bằng cách khám phá dịch vụ tại tầng định tuyến thay vì tầng ứng dụng, để thực hiện khám phá dịch vụ tại tầng định tuyến là sử dụng piggybacking các thông tin dịch vụ vào các thông điệp định tuyến, cho phép các thiết bị có được cả hai: dịch vụ và thông tin định tuyến cùng một lúc, mục đích để giảm chi phí thông tin liên lạc và tiết kiệm pin.
Để thêm khả năng khám dịch vụ cho ZRP, cần nhúng thêm một trường mở rộng trong tin nhắn NDP "Hello" để lưu trữ số ID của dịch vụ. Sử dụng các khái niệm về Nhận dạng phổ duy nhất (UUID) thay cho mô tả dịch vụ để
giữ độ dài gói nhỏ cho các thông báo định tuyến, như vậy không làm gián đoạn quá trình định tuyến (thông điệp càng lớn thì sự chậm trễ và khả năng sai sót càng lớn). Một cách tiếp cận như vậy có nghĩa là tất cả các nút biết một ưu tiên các ánh xạ giữa các dịch vụ được cung cấp trong Manet và UUID. Đây là một giả định phổ biến và được chứng minh bằng thực tế là hầu hết các MANETs được triển khai cho mục đích nhất định, nơi thiếu cơ sở hạ tầng thông tin liên lạc cố định (ví dụ như ở chiến trường hay một địa điểm bị thiên tai). Trong môi trường như vậy, vai trò của tất cả các nút tham gia là cụ thể và có thể dễ dàng phân loại theo dịch vụ. Việc ánh xạ các dịch vụ cho UUID là hiệu quả hơn cho việc phát hiện dịch vụ. Như vậy, bằng cách mở rộng tin nhắn "Hello" với các dịch vụ UUIDs, một nút có thể để biểu thị cả sự hiện diện của nó và các dịch vụ nó cung cấp.
ZRP được tiếp tục sửa đổi để bao gồm thông tin dịch vụ trong tất cả các ngõ định tuyến các thông điệp và bảng định tuyến IARP. IARP lắng nghe thông tin thu thập được từ tin nhắn NDP, cập nhật bảng và sau đó định kỳ quảng bá bảng của mình cho các nút lân cận. Bằng cách này, mỗi nút biết các tuyến đường đến tất cả các nút trong khu vực của nó và các dịch vụ mà các nút cung cấp, do vậy bổ sung thêm khả năng phát hiện dịch vụ cho phần chủ động của ZRP. Phiên bản sửa đổi của ZRP này (gọi là SD-ZRP) có khả năng cung cấp các dịch vụ khám phá chủ động tại tầng định tuyến.
2.3 Bộ lọc Bloom (BL)
Bộ lọc Bloom [9] được sử dụng để mô tả thông tin dịch vụ, BL là những cấu trúc dữ liệu nén nhỏ gọn cho các quyết định thành viên nhanh. Như kỹ thuật mã hóa băm cung cấp một sự thay đổi giữa việc sử dụng không gian hoặc kích cỡ băm và thời gian, bộ lọc Bloom được tìm thấy ở nhiều ứng dụng như tăng tốc độ tra cứu Cache, truy vấn lọc định tuyến và tìm kiếm văn bản miễn phí.
Xét một tập hợp A = {1, 2, ..., an } của n phần tử. Bộ lọc Bloom mô tả
thành viên của A sử dụng vector v của m phần tử (mỗi phần tử là 1 bit), ban đầu tất cả các thiết lập là 0, và sau đó chọn k hàm băm độc lập, h1, h2,..., hk,
mỗi hàm có miền xác định từ 1 đến m. Với mỗi phần tử a A, các bit ở vị trí h1(a), h2(a), ..., hk(a) trong v được thiết lập là 1. Một bit cụ thể có thể được
thiết lập là 1 nhiều lần. Cho một thành viên trên b, các bit ở vị trí h1(b),
h2(b), ..., hk(b) được kiểm tra. Nếu tất cả chúng là 0, thì chắc chắn b A. Ngược lại, chúng ta phỏng đoán rằng b là thuộc tập này.
Hình 2.10. Bộ lọc Bloom với hàm băm k=4
Xây dựng một bộ lọc Bloom
Các thủ tục sau đây xây dựng m bits, Bloom tương ứng với một tập hợp A và sử dụng h1, h2,..., hk hàm băm:
Procedure BloomFilter(set A, hash_function, integer m)
returns filter
filter = allocate m bits initialized to 0
foreach ai in A:
filter [hj(ai)] = 1
end foreach end foreach
return Yes
Nếu ai là thành viên của một tập A, trong kết quả lọc Bloom V tất cả các bits thu được tương ứng với giá trị băm của ai được thiết lập là 1. Thử nghiệm cho các thành viên của một phần tử elm là tương đương với thử nghiệm mà tất cả các bit tương ứng của V được thiết lập:
Procedure MembershipTest (elm, filter, hash_functions)
returns yes/no
foreach hash function hj:
if filter[hj(elm)] != 1 return No
end foreach return Yes
2.4 ZRP và cơ chế hổ trợ khám phá cho dịch vụ sử dụng BL và SD
Để thêm cơ chế khám phá dịch vụ cho giao thức định tyến lai ZRP, cần phải kết hợp một trường bổ sung trong thông điệp "Hello" để lưu trữ các dịch vụ định danh. Sử dụng các khái niệm của bộ lọc Bloom thay vì mô tả dịch vụ để giữ kích thước nhỏ của các gói tin cho việc định tuyến tin nhắn và giảm thiểu tác động trên mạng. Phương pháp này yêu cầu tất cả các nút cùng sử dụng hàm băm MD5 [10] thuật toán mã hóa để chuyển đổi một mô tả dịch vụ vào một bộ lọc Bloom.
ZRP được mở rộng bao gồm các thông tin dịch vụ trong mỗi mục thông báo định tuyến của IARP. Mỗi nút của mạng ad hoc sử dụng một bộ nhớ SvcCache để lưu trữ tất cả các dịch vụ được cung cấp thông qua các thông tin dịch vụ thu thập từ các gói NDP đến.
Hình 2.11: SvcCache và IARP bảng cập nhật và tương tác khi nhận được của NDP "Hello" thông báo dịch vụ video (1000) được cung cấp bởi các nút I và dịch vụ máy in (1100) được cung cấp bởi các nút G. Nút D tìm kiếm một dịch vụ máy in, được chuyển đổi thành một BF (1100), nó sẽ kiểm tra đầu tiên SvcCache của nó, lấy nhà cung cấp dịch vụ của máy in là G và tìm kiếm một con đường đến G trong bảng IARP.
Thông tin dịch vụ được lưu trữ: tên nhà cung cấp dịch vụ, (như là một vector BF). Khi một nút muốn sử dụng một dịch vụ, kiểm tra bộ nhớ cache của nó, nếu nó được tìm thấy, lấy địa chỉ nhà cung cấp và kiểm tra cho một tuyến đường trong bảng định tuyến.
Giao thức sử dụng các dịch vụ địa phương bộ nhớ đệm được quảng cáo bởi các nút láng giềng để tiết kiệm băng thông mạng. Quá trình khám phá dịch vụ và vị trí của nhà cung cấp được mô tả trong thuật toán:
Require: SvcCache not empty 1: if ∃ LookupSvcCache(X) then 2: Px ← LookupSvcCache(X):@ 3: if ∃ RoutingTable(Px) then 4: Return Px 5: end if 6: end if
Khám phá dịch vụ sử dụng MD5 theo cách sau đây: Hàm băm k tạo thành bộ lọc Bloom, được xây dựng từ k nhóm của mỗi r bits theo hoạt động hàm MD5 với 128 bit. Bất kỳ bộ sub-bits từ một đầu ra MD5 có thể được sử dụng như là một đầu vào đến một chức năng độc lập. Mỗi phòng trong các chức năng này k đặt một chút trong bộ lọc v.
Trong BF-SD-ZRP [3] , hàm băm được thực hiện trong thuật toán 2:
Algorithm 2 Calculate the Bloom Filter V for a service X
Require: x ≠ 0 1: a ⇐ MD5(x) 2: r ⇐ k 128 3: for i = 0 TO k do 4: f ← subbits (r*i, (r * (i + 1)) - 1, a) 5: V [f mod m] = 1 6: end for
Các giao thức ZRP là một mô hình lai giữa sở đồ chủ động và bị động. ZRP kết hợp một số giao thức phụ, cụ thể là IARP (bên trong khu vực), IERP(ngoài khu vực), và những giao thức khác (NDP, ICMP và BRP ... v.v.). Các phát hiện của láng giềng được thực hiện bằng cách tham khảo các lớp thấp hơn. ZRP chỉ đơn giản là lấy bảng láng giềng được cung cấp bởi một cơ chế tìm kiếm lân cận. Bảng này sẽ được sử dụng bởi IARP để xây dựng sơ đồ
mạng. Mỗi sửađổi, bổ sung bảng các nút láng giềng sẽ dẫn đến một cập nhật vùng của IARP và cập nhật bảng định tuyến bởi IERP.
Giao thức phát hiện láng giềng (NDP) được thực hiện tại lớp liên kết. Sử dụng NDP, định kỳ mỗi nút phát đi một thông điệp "Hello" để chỉ ra sự hiện diện của nó. NDP cập nhật bảng IARP, IERP sử dụng bảng IARP, IERP sau đó chuyển tiếp các yêu cầu đến các nút biên thông qua BRP. BRP sử dụng bảng IARP hướng dẫn yêu cầu. Và xây dựng thêm một trường trong thông điệp "Hello" để lưu trữ các dịch vụ định danh. Sử dụng các khái niệm của bộ lọc Bloom thay vì một mô tả dịch vụ thường để chiều dài gói tin NDP nhỏ. Chiều dài bộ lọc Bloom được sử dụng trong việc thực hiện là 128 bit.
Vì vậy, giải pháp là phân phối một bản tóm tắt của các dịch vụ được cung cấp trong một vector được mô tả như một bộ lọc Bloom. Một bộ lọc Bloom là một cấu trúc dữ liệu, cho phép các đại diện của một dữ liệu một cách đơn giản và không phô trương. Các gói tin IARP (hình 2.12) mang tất cả các thông tin về các nút láng giềng và các dịch vụ trong một bộ lọc Bloom tới tất cả các nút khu vực.
Hình 2.12 Định dạng gói tin IARP
Mỗi nút có một bộ nhớ cache trong đó lưu trữ tất cả các cung cấp dịch vụ (địa phương và những láng giềng). Trong bộ nhớ cache này, các thông tin được lưu trữ (địa chỉ nhà cung cấp, tên dịch vụ (bộ lọc Bloom) và time to life)
được giữ lại từ các gói NDP nhận được. Khi nhận được gói NDP, một bảng cập nhật nút láng giềng. IARP nghe thông tin thu thập được thông báo từ NDP, cập nhật bảng IARP của nó, và định kỳ phát sóng bảng của nó các nút láng giềng trong gói IARP. Một nút phân phối các IARP cập nhật các gói thiết lập trường TTL với giá trị bán kính vùng định tuyến, do đó các gói tin được giảm xuống khi đến nút biên. Khi nhận được gói IARP, một bản cập nhật nút bộ nhớ cache dịch vụ của mình và bảng định tuyến của nó. Như vậy, mỗi nút biết các tuyến đường đến tất cả các nút trong khu vực cũng như các dịch vụ được cung cấp bởi các nút này.
2.5 Kết luận chương 2
Trong chương này, tôi đã đi sâu phân tích cơ chế hoạt động của giao thức ZRP, và nêu rõ được đặc điểm của các cơ chế định tuyến, đưa ra được các ví dụ để minh họa, làm rõ hơn quá trình họat động của giao thức định tuyến lai ZRP. Và cơ chế hổ trợ khám phá cho dịch vụ sử dụng BL và SD trong ZRP.
CHƯƠNG 3
ĐÁNH GIÁ HIỆU NĂNG CỦA MỘT SỐ GIAO THỨC ĐỊNH TUYẾN TRÊN MẠNG MANET
Để đánh giá hiệu suất hoạt động của các giao thức thông thường người ta có thể dùng các phương pháp như: phương pháp giải tích, phương pháp thử nghiệm hoặc phương pháp mô phỏng. Trong luận văn này, tôi chọn phương pháp mô phỏng để đánh giá hiệu năng hoạt động của giao thức đặc trưng cho giao thức định tuyến lai ghép là ZRP và SD-ZRP dựa trên phần mềm mô phỏng mạng NS2.
3.1 Giới thiệu môi trường mô phỏng NS3.1.1 Tổng quan về NS2 3.1.1 Tổng quan về NS2
NS (Network Simulation) là phần mềm mô phỏng mạng điều khiển sự kiện riêng lẻ hướng đối tượng, được phát triển tại UC Berkely, viết bằng ngôn ngữ C++ và Otcl [18]. NS rất hữu ích cho việc mô phỏng các hệ thống mạng hữu tuyến và vô tuyến, NS có các đặc điểm cơ bản sau:
- Khả năng kiểm tra tính ổn định của các giao thức mạng đang tồn tại. - Khả năng đánh giá các giao thức mạng mới trước khi đưa vào sử dụng. - Khả năng thực thi những mô hình mạng lớn mà gần như ta không thể thực thi được trong thực tế.
- Khả năng mô phỏng nhiều loại mạng khác nhau.
Mục đích của NS2 là tạo ra một môi trường giả lập cho việc nghiên cứu, kiểm tra, thiết kế các giao thức, các kiến trúc mới so sánh các giao thức và tạo ra các mô hình mạng phức tạp. Phiên bản thứ nhất của NS được phát triển vào năm 1995 và phiên bản thứ hai ra đời vào năm 1996. NS2 là phần mềm mã nguồn mở có thể chạy được trên nền của Linux và Window.
NS thực thi các giao thức mạng như: Giao thức điều khiển truyền tải (TCP) và giao thức gói người dùng (UDP), các dịch vụ nguồn lưu lượng như giao thức truyền tập tin (FTP), Telnet, Web, tốc độ bit cố định (CBR) và tốc độ bit thay đổi (VBR), các kỹ thuật quản lý hàng đợi như Vào trước Ra trước (Drop Tail), Dò sớm ngẫu nhiễn (RED) và CBQ, các thuật toán định tuyến như Dijkstra… NS cũng thực thi multicasting và giao thức lớp điều khiển truy cập đường truyền (MAC) đối với mô phỏng LAN.
3.1.2 Kiến trúc của NS2
NS2 là một công cụ giả lập hướng đối tượng được viết bằng ngôn ngữ C++ trong phần nhân và ngôn ngữ thông dịch Otcl ở phần giao tiếp.
Bộ giả lập NS2 bao gồm 3 module chính:
- Module nhân được gọi là Compiler Hierarchy. - Module giao tiếp được gọi là Interpreted Hierarchy.
- Module liên kết là module có tác dụng như một lớp keo dùng để gắn kết các lớp, các đối tượng, các biến tương ứng trong hai module nhân và module giao tiếp với nhau.
NS và bộ biên dịch Tcl mở rộng hướng đối tượng, bao gồm các đối tượng bộ lập lịch sự kiện, các đối tượng thành phần mạng và các mô đun trợ giúp thiết lập mạng.
- OTcl Script: Kịch bản OTcl
- Simulation Program: Chương trình mô phòng - Otcl: Bộ biên dịch Tcl mở rộng hướng đối tượng - NS Simulation Library: Thư viện mô phỏng NS
- Event Scheduler Objects: Các đối tượng bộ lập lịch sự kiện - Network Component Objects: Các đối tượng thành phần mạng - Network Setup Helping Modules: Các mô đun trợ giúp thiết lập mạng - Plumbling Modules: Các mô đun Plumbling
- Simulation Results: Các kết quả mô phỏng - Analysis: Phân tích
- NAM (Network Animator): Minh họa mạng NAM
Để sử dụng NS2, user lập trình bằng ngôn ngữ kịch bản OTcl. User có thể thêm các mã nguồn Otcl vào NS2 bằng cách viết các lớp đối tượng mới trong OTcl. Những lớp này khi đó sẽ được biên dịch cùng với mã nguồn gốc. Kịch bản OTcl có thể thực hiện những việc sau:
- Khởi tạo bộ lập lịch sự kiện
- Thiết lập mô hình mạng dùng các đối tượng thành phần mạng
- Báo cho nguồn traffic khi nào bắt đầu truyền và ngưng truyền packet trong bộ lập lịch sự kiện
Thuật ngữ plumbing được dùng để chỉ việc thiết lập mạng, vì thiết lập một mạng nghĩa là xây dựng các đường dữ liệu giữa các đối tượng mạng bằng cách thiết lập con trỏ “neighbour” cho một đối tượng để chỉ đến địa chỉ của đối tượng tương ứng. Module plumbing OTcl trong thực tế thực hiện việc trên rất đơn giản. Plumbing làm nên sức mạnh của NS.
Thành phần lớn khác của NS bên cạnh các đối tượng Thành phần mạng là bộ lập lịch sự kiện. Bộ lập lịch sự kiện trong NS2 thực hiện những việc sau:
- Huỷ các sự kiện trong hàng đợi sự kiện - Gọi các thành phần mạng trong mô phỏng
Phụ thuộc vào mục đích của user đối với kịch bản mô phỏng OTcl mà kết quả mô phỏng có thể được lưu trữ như file trace. Định dạng file trace sẽ được tải vào trong các ứng dụng khác để thực hiện phân tích:
- File nam trace (file.nam) được dùng cho công cụ minh họa mạng NAM - File Trace (file.tr) được dùng cho công cụ lần vết và giám sát mô phỏng XGRAPH hay TRACEGRAPH
- NAM Visual Simulation: Mô phỏng ảo NAM
- Tracing and Monitoring Simulation: Mô phỏng lần vết và giám sát