Figure 17.5 is a schematic of the main components of a SatNode. The structure bears resemblance to the MobileNode in the wireless extensions, but there are several differences. Like all ns nodes, the SatNode has an ``entry'' point to a series of classifiers. The address classifier contains a slot table for forwarding packets to foreign nodes, but since OTcl routing is not used, all packets not destined for this node (and hence forwarded to the port classifier), are sent to the default target, which points to a routing agent. Packets destined on the node for port 255 are classified as routing packets and are also forwarded to the routing agent.
Each node contains one or more ``network stacks'' that include a generic SatLinkHead at the entry point of the link. The SatLinkHead is intended to serve as an API to get at other objects in the link structure, so it contains a number of pointers (although the API here has not been finalized). Packets leaving the network stack are sent to the node's entry. An important feature is that each packet leaving a network stack has its iface_ field in the common packet header coded with the unique NetworkInterface index corresponding to the link. This value can be used to support distributed routing as described below.
The base class routing agent is class SatRouteAgent; it can be used in conjunction with centralized routing. SatRouteAgents contain a forwarding table that resolves a packet's address to a particular LinkHead target- it is the job of the SatRouteObject to populate this table correctly. The SatRouteAgent populates certain fields in the header and then sends the packet down to the approprate link. To implement a distributed routing protocol, a new SatRouteAgent could be defined- this would learn about topology by noting the interface index marked in each packet as it came up the stack- a helper function in the node intf_to_target() allows it to resolve an index value to a particular LinkHead.
There are pointers to three additional objects in a SatNode. First, each SatNode contains a position object, discussed in the previous section. Second, each SatNode contains a LinkHandoffMgr that monitors for opportunities to hand links off and coordinates the handoffs. Satellite nodes and terminal nodes each have their specialized version of a LinkHandoffMgr.
Finally, a number of pointers to objects are contained in a SatNode. We discussed linklisthead_ and nodehead_ in the previous subsection. The uplink_ and downlink_ pointers are used for convenience under the assumption that, in most simulations, a satellite or a terminal has only one uplink and downlink channel.
Tom Henderson 2011-11-05