Active Network Overlay Network (ANON) Goals: provide an overlay network on top of various existing networks for doing AN experiments, based on the ANEP message format support for point-to-point as well as broadcast configurations no routing or fancy forwarding beyond one ANON network, possibility to interconnect ANON networks Defs: Active node an active networking code execution environment (AN layer) Leaf end node (ANON layer) Bridge intermediate node (ANON layer) Gateway end node (ANON layer) for an active node with two or more leaf interfaces (AN level gateway) AnonAddr A 128 bit string that identifies a leaf node Possible Configurations: A A L-------L two leaf nodes (point-to-point) [the most simple ANON network] A A L-------B-------L N leaf nodes attached starlike to a / bridge: this gives a bus topology A / [this is the other type of ANON networks] L A A L----B-----B----L N leaf nodes attached to two bridges: / \ this gives a bus topology (kind of A / \ A remote bridges) L L [this is one ANON network] A A L----B-----B----L N leaf nodes attached to M fully meshed / \ / \ bridges: this gives a bus topology (kind of A / \ / \ A remote bridges) L B L [this is still one ANON network] A A A L-------G-------L three leaf nodes (point-to-point) one of them with two interfaces [two ANON networks gatewayed at AN level] A A A L----B-----G----L N leaf nodes attached to one bridge, / \ another leaf attached to one of the N nodes A / \ [again two ANON networks, but mixed topologies L B and gatewayed at AN level] etc Two Message Types: i_am_a_leaf sent periodically, asking for delivery of packets for this node (from L nodes towards L or B nodes) i_am_a_bridge sent periodically, asking for forwarding of packets with unknown destination (from B nodes towards L or B nodes) Format of Routing Related ANEP Messages (ANEP type 1) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Routing Protocol ID | protocol dependend fields | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ANON Routing Message ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ANON Routing has the Protocol ID = 1 Format of ANON Routing Messages i_am_a_bridge: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | sequence of | ~ ANEP addresses, ~ | one for each known neighboring bridge | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i_am_a_leaf: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | ANEP typeid to register for | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 128 bits | | ANON address | | for which we want to register | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In both cases must the source identifier be set in order to know under which (UDP) address the client can be reached. Changes/Additions Neccesary for the ANEP document and ANANA: new Scheme Identifiers: ANON identifier 4 (128 bits) IPv4 UDP address 5 (32+16 bits) IPv4 TCP address 6 (32+16 bits) ANANA: new AN TypeId for routing, we assume it is TypeId 1 ANANA: would maintain a list of routing protocols, we assume that ANON receives number 1 we furthermore suggest (ANEP): - to increase the ANEP packet length field to word size - to add a nother Scheme identifier: rfc822 address 7 ('\0' terminated)