Re: active networking in ns

[Guillermo Rodriguez Garcia <guille@iies.es>]

>Sender: yamamoto@run.montefiore.ulg.ac.be
>Date: Tue, 19 Oct 1999 10:55:56 +0200
>From: Lidia Yamamoto <yamamoto@run.montefiore.ulg.ac.be>
>To: Guillermo Rodriguez Garcia <guille@iies.es>
>Subject: Re: active networking in ns
>Content-Length: 3612
>
>Hi Guillermo,
>
>[I guess you forgot to send a copy of your message to the list, if that's the
>case, you may also forward this reply to the list]
>
>> think you are supposed to build your own agents in top of ANAgent, (and
>> of course write a new packet format) and ANActiveAgent is provided as an
>> example only (but I might be wrong).
>
>I think so too, but that makes the whole thing look too much like traditional
>networking. You need to define the packet type and the corresponding
fields (with
>their types and sizes) for each new capsule type. In this sense, could we
>consider diffserv as AN? Or RSVP? Actually I think yes, they could be
considered
>as a primitive form of AN, but AN is of course not restricted to this.
>
>> exactly the same way. But your solution won't work with dynamic
>> routing, while PANAMA's will. So I think theirs is more generic
>
>With my current temporary hack you are right. My solution requires routing
at the
>AN level, while benefitting from routing at the IP level only between AN
hops.
>Since I haven't implemented routing at the AN level yet, I cheated by
copying the
>results from the static IP routing tables and making that my AN routing
table.
>For the moment this is enough for my tests, since my active packets are
far from
>well defined, I change them all the time, and therefore I need something
flexible
>(no compilation if possible...)
>
>> There is one thing that is not entirely clear for me yet. With
>> your solution, if you need to have custom fields in the active
>> packet header, how/where do yo carry them? In other words, how
>> do you store state information associated with each active
>> packet? Just imagine a simple, stupid active packets that
>> records routes from source to destination. Implementation
>> should be straightforward with PANAMA's approach because
>> you have a new packet format for each new active protocol,
>> so you can just carry a list of node addresses and append
>> each node that you visit as you travel the network. How
>> would you do this with your approach?
>
>State is carried in the procedure's parameters. Here is an example traceroute
>capsule evaluated at each "$ee" on the path to the destination:
>
># "traceroute", method "record path"
>proc traceroute2 {return path srcee dstee ee} {
>    if {$return} {
>        if {$ee == $dstee} {
>            $ee debug "path to [[$srcee set node_] id] is: $path"
>        } else {
>            set capsule "traceroute2 $return $path $srcee $dstee"
>            $ee forward $capsule $dstee
>        }
>    } else {
>        set newpath "${path}_[[$ee set node_] id]"
>        if {$ee == $dstee} {
>            set capsule "traceroute2 1 $newpath $dstee $srcee"
>            $ee forward $capsule $srcee
>        } else {
>            set capsule "traceroute2 0 $newpath $srcee $dstee"
>            $ee forward $capsule $dstee
>        }
>    }
>}
>
>[ As you can see "path" is not a list of nodes but a string of the form
>"node1_node2_node3". This is only for convenience, so that I didn't have to
>worry about treating a list parameter. ]
>
>This example is not simulating the fact that an application issues a
traceroute
>request and prints the response, so the capsule itself prints the
>response.
>
>> >optimised implementation before this date, since the implementation I have
>> now is
>> >not really intended for thousands of nodes.
>>
>> I would like to have an eye at it when it is ready anway,
>> even when I won't probably be able to use it for this project.
>
>I'll prepare a neat version as soon as I can... I'll probably include the
>possibility to use "router alert" as well, you've convinced me :-)
>
>Kind regards,
>
>Lidia.
>
>
>
--
Guillermo Rodriguez Garcia
<guille@iies.es>