[Olsr-dev] Rounting

[scolfield]

Hello again,

My question may be a little or very stupid. Consider below packet:

------ -------- ---------------------------
| IP | UDP | OLSR Messages |
------ -------- ---------------------------

The OLSR messages came from 698 port number and so, OLSR daemon begin
processing this
messages. My first question is, can I affirm that the OLSR daemon is a
protocol that
belongs a application layer? Because it is started as daemon and not loaded
as kernel
module. I know that the OLSR is a routing protocol that determine which is a
better path
from origin to destine. And so, the data user application can flow on this
better path.

My second question is, consider the data user application over TCP. The
packet format is:

------ -------- ---------------------------------
| IP | TCP | User Data Application |
------ -------- ---------------------------------

OLSR evaluate the IP header and detect that protocol and destine port is
different of UDP/698?
So, OLSR will not process and simply look at the routing table, look the
next hope and forward it?
It is OLSR protocol that perform this?

User Data Application                                               User
Data Application
          ||
                ||
          \/
               \/
    TCP/UDP
    TCP/UDP
          ||
                ||
          \/
               \/
         IP
               IP
          ||
                ||
     MAC/PHY
   MAC/PHY
          ------------------------------ Routers with OLSR
----------------------------

In computer networks lessons, the basic that we learn is that routers may
only to see for
until layer 3, and not above it. But, the OLSR utilize the UDP protocol, and
this confused me.

Can anyone "to remove" my doubts (questions)? I know that my questions maybe
is a
little strangers. But, please, I would like to considers my questions.

Thanks for any help,
--
scolfield
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20110516/9a68284d/attachment.html>