Giao thức định tuyến nguồn động là một trong nhưng giao thức định tuyến dựa theo yêu cầu, và có nền tảng là định tuyến nguồn. Trong định tuyến nguồn, phần tiêu đề của gói tin của nút gửi có danh sách đầy đủ các đường đi mà gói tin phải đi qua đến nút đích. Do đó, các nút trên đường đi chỉ chuyển tiếp gói tin đến chặng tiếp theo được quy định trong phần mào đầu mà không phải kiểm tra bảng định tuyến như trong các giao thức định tuyến dựa trên bảng có sẵn. Bên cạnh đó, các nút không phải định kỳ quảng bá các bảng định tuyến tới các nút lân cận. Điều này tiết kiệm rất nhiều băng thông mạng. Hai giai đoạn của giao thức này được mô tả như sau:
Giai đoạn tìm đƣờng
Trong giai đoạn này, nút nguồn tìm kiếm một đường đi bằng việc quảng bá các gói tin yêu cầu đường đi (RREQ) tới các nút lân cận. Mỗi nút lân cận sau khi nhận gói tin quảng bá này sẽ kiểm tra gói tin này để xác định áp dụng các điều kiện nào sau đây: (a) Gói tin RREQ này đã nhận được trước đó? (b) Bộ đếm thời gian TTL (Time To Live) lớn hơn 0? (c) Chính nó có phải đích của gói tin RREQ không? (d) Nó có nên quảng bá gói tin RREQ này tới các nút lân cận không? Các điều kiện (request id) này được sử dụng để xác định xem trước đó yêu cầu đường đi này đã được nút nhận hay chưa. Mỗi nút chưa một bảng các
RREQ nhận gần nhất. Mỗi dòng trong bảng là một cặp <nguồn, request id> . Nếu nút nhận hai RREQ có cùng <nguồn,, request id>, nó chỉ quảng bá RREQ đầu tiên và loại bỏ RREQ thứ hai. Cơ chế này cũng ngăn chặn thông tin định tuyến bị lặp trong mạng. Khi gói tin RREQ đến được nút đích, nút đích gửi một gói tin trả lời (RREP) ngược trở lại nút gửi. Gói tin trả lời này chứa đường đi đã được lưu lại tới đích đó.
Hình 2.15 mô tả một ví dụ về giai đoạn tìm kiếm đường đi. Khi nút A muốn gửi thông tin đến nút G, nó khởi tạo cơ chế tìm đường và gửi quảng bá một gói tin yêu cầu (RREQ) tới nút lân cận là B, C và D như hình vẽ. Tuy nhiên, nút C cũng nhận được các gói tin quảng bá giống như vậy từ B và D. Nút C sẽ loại bỏ các gói tin trùng này và quảng bá gói tin RREQ đã nhận trước đó tới các nút lân cận. Các nút khác sẽ tiếp tục thực hiện quá trình này. Khi gói tin này đến được nút G, nó chèn địa chỉ nút G và gửi ngược trở lại đơn hướng tới nút nguồn đã gửi gói tin RREQ.
Nút đích truyền đơn hướng đường đi tốt nhất (là đường đi mà nó nhận được sớm nhất) và lưu đường đi này cho lần sử dụng tiếp theo vào bộ đệm. Mỗi nút khi nhận được một yêu cầu đường đi và tìm thấy một đường đi cho nút đích trong bộ đệm của nó, nó gửi một gói tin RREP thay cho việc gửi quảng bá.
2.15 Tìm đường trong DSR
Duy trì đƣờng
Giai đoạn duy trì đường đi được thực hiện mỗi khi giữa hai nút bị đứt liên kết. Sự đứt liên kết được một nút hoặc quá trình quét phát hiện. Như trong hình
2.16, khi một đứt liên kết (F-G) xảy ra, một gói tin báo lỗi đường đi (RERR) được gửi bởi nút trung gian đến nút nguồn. Nút nguồn khởi tạo lại quá trình tìm đường để tìm đường đi mới đến đích. Nó cũng loại bỏ các dòng định tuyến trong bộ đệm tới đích đó.
Hình 2.16 : Duy trì đường trong DSR
Lợi thế của DSR là các nút trung gian không cần phải giữ thông tin định tuyến luôn cập nhật để định tuyến gói tin mà chúng nhận được. Tuy nhiên, khi quy mô của mạng tăng lên, chi phí cho định tuyến cũng tăng do mỗi gói tin phải mang toàn bộ đường đi của nó đến đích . Việc sử dụng bộ đệm định tuyến là một cơ chế tốt để giảm trễ truyền nhưng việc lạm dụng bộ đệm có thể gây ra hiệu năng bị suy giảm. Một vấn đề khác của DRS là mỗi khi liên kết bị gián đoạn, gói tin RERR truyền đến nút nguồn ban đầu, điều này làm sinh ra một quá trình tìm đường mới. Liên kết này không được sửa chữa tại chỗ. Một số đề xuất để tối ưu DSR được đưa ra, chẳng hạn như các yêu cầu định tuyến không quảng bá (khi gửi RREQ, các nút thiết lập giới hạn chặng bằng 1 để ngăn chặn việc quảng bá lại), trả lời định tuyến ngẫu nhiên (khi một nút nghe thấy một gói tin với địa chỉ của chính nó nằm trong phần tiêu đề, nó gửi một RREP tới nút nguồn bỏ qua các chặng trước, vv…