Nếu cơ chế này không tồn tại và sẵn có ở các nút thì khi đó nút gửi tin sẽ dùng một bít thông tin trong phần tiêu đề của gói tin để yêu cầu một phúc đáp từ nút tiếp theo thông qua phần mềm đặc biệt trong DSR. Thông thường phúc đáp qua phần mềm này được truyền trực tiếp tới nút gửi tin. Tuy nhiên nếu đường liên kết giữa hai nút là liên
kết đơn hướng thì phúc đáp này có thể phải đi qua rất nhiều chặng khác nhau để quay lại nút gửi tin
Nếu gói tin được truyền lại qua một số chặng và vượt quá số lần cực đại cho phép mà vẫn chưa nhận được khẳng định từ nút tiếp theo, nút này sẽ gửi bản tin báo lỗi tuyến RERR quay trở lại nút đã gửi bản tin ban đầu để xác minh tuyến bị lỗi từ nút nào. Ví dụ trong hình 2.6 trên : nếu nút C không thể truyền tin đến nút D tiếp theo, C sẽ gửi bản tin RERR về nút A và tường trình rằng tuyến từ C đến D bị đứt. Khi đó A sẽ xóa đường liên kết bị lỗi này khỏi bộ nhớ tuyến của nó. Việc truyền lại bản tin ban đầu bây giờ là nhiệm vụ và chức năng của các thủ tục lớp cao hơn như TCP. Trong trường hợp phải gửi lại gói tin tới chính đích E và nếu trong bộ nhớ tuyến của nút A có một tuyến khác tới E (ví dụ từ các bản tin trả lời tuyến từ các thủ tục khám phá tuyến trước đó hoặc là từ việc nghe lỏm được các thông tin định tuyến từ các gói tin khác) thì nó sẽ gửi ngay gói tin sử dụng tuyến mới đó. Nếu không nó sẽ thực hiện một thủ tục khám phá tuyến mới tới đích E nói trên
2.5 AD HOC ON- DEMAND DISTANCE VECTOR ROUTING (AODV)
AODV cho phép định tuyến nhiều bước giữa các nút mạng để thiết lập và duy trì mạng Ad hoc. AODV dựa trên thuật toán vector khoảng cách nhưng thuộc loại định tuyến theo yêu cầu, nó chỉ yêu cầu đường định tuyến khi cần thiết. Thuật toán định tuyến AODV khá phù hợp cho cấu hình mạng động. AODV đưa ra các tuyến không bị lặp ngay cả khi nó đang sửa các liên kết lỗi. Bởi vì giao thức này không yêu cầu quảng bá tuyến định kỳ trên toàn mạng, nên yêu cầu toàn bộ băng thông có sẵn cho một nút di động thực chất là thấp hơn so với các giao thức khác, những giao thức yêu cầu quảng bá.
AODV sử dụng liên kết đối xứng giữa các hàng xóm. Gói tin không đi theo tuyến đường giữa các nút khi một trong những nút đó không nghe được từ các nút khác. Những nút không nằm trên các tuyến đường hoạt động; chúng sẽ không duy trì bất cứ thông tin định tuyến nào cũng như không tham gia vào bất kỳ sự trao đổi bảng định
tuyến định kỳ nào. Hơn nữa, một nút không phải khám phá và duy trì một tuyến tới nút khác cho tới khi hai nút cần giao tiếp với nhau, trừ khi nút đó đóng vai trò như một trạm chuyển tiếp trung gian để duy trì kết nối giữa hai nút khác . Khi một kết nối cục bộ của nút di động được thiết lập, mỗi nút có thể nhận thấy các nút khác trong vùng lân cận của nó bằng một vài kĩ thuật, bao gồm quảng bá cục bộ các bản tin Hello. Bảng định tuyến của các nút trong vùng lân cận được tạo ra để tối ưu thời gian đáp ứng tới với sự di chuyển cục bộ và cung cấp thời gian đáp ứng nhanh cho các yêu cầu thiết lập tuyến mới.
Mục tiêu chính của thuật toán AODV:
• Gửi broadcast các gói tin khám phá tuyến khi cần thiết.
• Phân biệt giữa phát hiện-quản lý kết nối cục bộ trong vùng lân cận với duy trì topo mạng chung.
• Quảng bá thông tin về sự thay đổi kết nối cục bộ tới các nút hàng xóm mà thực sự cần thông tin.
AODV sử dụng một cơ chế Khám phá tuyến với sự cải biến của thuật toán DSR. Thay vì định tuyến nguồn, AODV tin tưởng vào sự thiết lập động các entry trong Bảng định tuyến ở các nút trung gian.
AODV sử dụng số thứ tự ở nút mạng đích để giúp cho tuyến đường luôn cập nhật và không hình thành đường định tuyến khép kín. Hơn nữa, AODV cũng hỗ trợ định tuyến multicast và giải quyết được vấn đề đếm vô hạn trong thuật toán Bellman Ford.
2.5.1 Khám phá tuyến
Quá trình Khám phá tuyến được khởi tạo bất cứ khi nào một nút nguồn muốn giao tiếp với các nút mạng khác nhưng nó lại không có thông tin định tuyến trong Bảng định tuyến của nó. Mỗi nút duy trì hai bộ đếm: số thứ tự nút và broadcast ID. Nút nguồn khởi tạo Khám phá tuyến bằng cách quảng bá gói tin RREQ tới hàng xóm của nó.
RREQ chứa các trường sau:
Trong đó:
- source _addr: địa chỉ nguồn - source sequence: số thứ tự nguồn - broadcast_id: định danh của RREQ - dest_addr: địa chỉ đích
- dest sequence: số thứ tự đích - hop_cnt : số chặng
Cặp <source_addr, broadcast_id> được xác định duy nhất với mỗi bản tin RREQ. broadcast_id được tăng lên khi nút nguồn khởi tạo một RREQ mới. Mỗi nút hàng xóm khi nhận được bản tin RREQ sẽ gửi lại một bản tin RREP tới nút nguồn nếu nó biết một tuyến tới đích, hoặc tiếp tục quảng bá bản tin RREQ tới nút hàng xóm sau khi tăng hop_cnt. Chú ý rằng mỗi nút có thể nhận được nhiều bản sao của cùng một RREQ từ các hàng xóm. Khi một nút trung gian nhận được một RREQ, nếu nó đã nhận RREQ với cùng broadcast_id và địa chỉ đích, nó sẽ loại bỏ RREQ đó và không chuyển tiếp gói tin đó nữa. Nếu một nút không thể đáp ứng được RREQ, nó sẽ theo dõi các thông tin sau để thiết lập tuyến đường ngược cũng như thiết lập tuyến đường thuận để dành cho việc truyền gói tin RREP.
• Địa chỉ IP đích
• Địa chỉ IP nguồn
• Broadcast ID
• Thời gian hết hạn của entry tuyến đường ngược
• Số thứ tự của nút nguồn
2.5.2 Thiết lập tuyến đường ngược
Có hai số thứ tự được chứa trong một bản tin RREQ: số thứ tự nguồn và số thứ tự đích cuối cùng được biết bởi nguồn. Số thứ tự nguồn được sử dụng để duy trì thông tin mới về tuyến đường ngược tới nguồn, và số thứ tự đích chỉ ra rằng tuyến đường tới đích
phải mới như thế nào để nó có thể được chấp nhận bởi nguồn. Khi bản tin RREQ được gửi từ nút nguồn tới các nút đích khác nhau, nó sẽ tự động thiết lập các tuyến đường ngược từ tất cả các nút đó tới nút nguồn. Để thiết lập tuyến đường ngược, mỗi nút phải ghi lại địa chỉ của hàng xóm mà từ đó nó nhận được bản sao đầu tiên của RREQ. Các entry tuyến đường ngược được duy trì trong khoảng thời gian vừa đủ để bản tin RREQ có thể truyền trên mạng và trả lời lại tới nút gửi.
Hình 2.7 Thiết lập tuyến đường đi ngược