Michael Hicks, Pankaj Kakkar, Jonnathan T. Moore, Carl A. Gunter, and Scott Nettles, Network programming with PLAN,In Proceedings of the IEEE Workshop on Internet Programming Languages(1998).  Home/Search   Document Not in Database   Summary   Related Articles   Check

....it is almost impossible that the single protocol for the ad hoc network becomes the Figure 1. The ad hoc network on the table optimal in all situations. Furthermore, it isn t realistic that preparing several protocols into all mobile hosts for various situations. Recently, the active networks [4, 5, 6] have been proposed for dynamically configuring routers and switchs for the packet exchange based networks such as the Internet. Although these systems utilize a packet which contains a program for flexible network configuration, they do not consider about the ad hoc situations under the mobile ....

....replication. DSR[3] is a dynamic source routing protocol described in last section. AODV[2] can be regarded as a combination of DSR and DSDV. These protocols satisfy the adaptation to the dynamic network change in the ad hoc networks, but do not satisfy the dynamic extension requirement. PLAN[4] is a functional language for active networks. They divide the services and the packets, and provide separate way of extensions. This language did not consider about dynamic change of the network. SmartPacket[O] is a active network project which is using special language Sproket. They also did not ....

Michael Hicks, Pankaj Kakkar, Jonnathan T. Moore, Carl A. Gunter, and Scott Nettles, Network programming with PLAN,In Proceedings of the IEEE Workshop on Internet Programming Languages(1998).

....Finally, multiplexing is achieved by using ATM on the physical link, which relieves the node operating system to perform the multiplexing. The Switchware project [16] takes a language based approach. The memory access is controlled via a type checked Programming Language for Active Networks (PLAN) [17]. Switchware does not support resource partitioning. Multiplexing is implicitly build into the active packet carrying the code to evaluate on intermediate active nodes. The executing code calls in a controlled way previously installed routines on the network node. 15 8 Discussion and Further ....

M. Hicks, P. Kakkar, J. Moore, C. Gunter, S. Nettles, "Network Programming with PLAN," IEEE Workshop on Internet Programming Languages, May 1998.

....the topic [1, 12] Other functions we have implemented as PLAN programs include route scouting which seeks out low congestion routing paths (as described in Section 4) source directed multicast, traceroute, and network DFS, to name a few. More detail about programming with PLAN may be found in [13]. 2.2 PLANet PLANet is our active internetwork implementation based on the PLAN environment described above. Whenever possible, we have drawn from the experience of IP [21, 6] in making implementation decisions, so as to leverage the experience represented by that design. The remainder of this ....

Michael Hicks, Pankaj Kakkar, Jonathan T. Moore, Carl A. Gunter, and Scott Nettles. Network programming with PLAN. In Workshop on Internet Programming Languages. Springer, 1998. To appear.

.... allowed per packet to some constant n, resulting in n O(jpj) O(jpj) The most conservative case would be to set n = 1, allowing only a single send or delivery per packet, matching unicast semantics but prohibiting multicast style programs, and even reasonable implementations of traceroute [6], 20] A more flexible bound, used in our current implementation, is the least n such that multicast may be programmed: n varies per node to be the number of network interfaces on that node. For demux, we permit only one delivery per packet, and force the packet to exit following the delivery. As ....

....V. FLEXIBILITY We have seen how restrictions to SNAP s flexibility imply several important safety properties. To demonstrate that SNAP still retains enough expressibility to be useful, we developed a compiler that translates PLAN into SNAP. PLAN s flexibility is well documented in the literature [6], 7] 8] 9] our compiler thus ensures that SNAP remains useful. Indeed, of the six active applications mentioned in the introduction, two are currently implemented in PLAN, while at least three others could be. 3 Perhaps PLAN s most important application is its internetwork, PLANet [9] In ....

[Article contains additional citation context not shown here]

M. Hicks, P. Kakkar, J. T. Moore, C. A. Gunter, and S. Nettles. Network programming with PLAN. In IEEE Workshop on Internet Programming Languages, May 1998.

No context found.

Michael Hicks, Pankaj Kakkar, Jonathan T. Moore, Carl A. Gunter, and Scott Nettles. Network programming with PLAN. In Luca Cardelli, editor, Proceedings of the IEEE Workshop on Internet Programming Languages, volume 1686 of Lecture Notes in Computer Science, pages 126-143. Springer-Verlag, May 1998.

No context found.

Michael Hicks, Pankaj Kakkar, Jonathan T. Moore, Carl A. Gunter, and Scott Nettles. Network programming with PLAN. In Henri E. Bal, Boumediene Belkhouche, and Luca Cardelli, editors, Internet Programming Languages, volume 1686 of Lecture Notes in Computer Science, pages 127--143, Chicago, Illinois, May 1998. Springer.

.... allowed per packet to some constant n, resulting in n O(jpj) O(jpj) The most conservative case would be to set n = 1, allowing only a single send or delivery per packet, matching unicast semantics but prohibiting multicast style programs, and even reasonable implementations of traceroute [6], 20] A more flexible bound, used in our current implementation, is the least n such that multicast may be programmed: n varies per node to be the number of network interfaces on that node. For demux, we permit only one delivery per packet, and force the packet to exit following the delivery. As ....

....of the list, we cannot, generally speaking, know how many times to unroll the fold . Therefore, the user provides a conservative upper bound to the compiler. We do not expect this to be a problem in practice, as most uses of fold are on short lists of addresses, e.g. for the multicast program in [6] or the flow based routing program in [9] PLAN differs slightly from SNAP in its execution model. PLAN programs do not evaluate on every active router they traverse, as SNAP programs do, but on the destination only. On the intervening PLAN nodes, a packetspecified routing function is evaluated ....

M. Hicks, P. Kakkar, J. T. Moore, C. A. Gunter, and S. Nettles. Network programming with PLAN. In IEEE Workshop on Internet Programming Languages, May 1998.

....Unchecked, this program will jump back and forth between two nodes forever. To alleviate this problem, PLAN packets have a resource bound counter which is decremented each 1 PLAN programs terminate as long as the services called also terminate. 2 A basic knowledge of PLAN is assumed. See [5] for a detailed description of programming with PLAN. 4 time a new packet is sent. Therefore, the number of hops that a PLAN program or any of its progeny may take are limited by the initial value of this counter. This mimics the functionality of the IP TTL field. However, PLAN alone, even with ....

Michael Hicks, Jonathan T. Moore, Pankaj Kakkar, Carl A. Gunter, and Scott Nettles. Network programming with plan. In IEEE Internet Programming Languages Workshop, Chicago, Illinois, 1998.

....thread scheduling, and garbage collection. Flexibility. Despite being an expression limited language, PLAN has been found useful as a network scripting language for combining node resident services. Examples of PLAN based applications include application specific routing [13] multicast [10], and virtual private networks [22] One awkward point, however, is that the resource bound conservation properties make it difficult (from a programmer s point of view) to apportion a packet s resource bound among multiple children. 3.3 PAN PAN[24, 25] is follow on project to ANTS, also ....

Michael Hicks, Pankaj Kakkar, Jonathan T. Moore, Carl A. Gunter, and Scott Nettles. Network programming with PLAN. In Proceedings of the IEEE Workshop on Internet Programming Languages, May 1998.

No context found.

Mike Hicks, Pankaj Kakkar, Jonathan T. Moore, Carl A. Gunter, and Scott Nettles. Network programming with PLAN. In Workshop on Internet Programming Languages. Springer, 1998. To appear.

....at PLAN evaluation time. In PLANet, service routines are implemented as active extensions written in Caml. This two level architecture of PLAN and service routines is summarized in Table 1, which is drawn from [22] This combination provides a powerful programming style which we describe in [21] and have illustrated in PLANet. PLAN provides very efficient, light weight mobile agents that invoke services to achieve flexible network utilization that can be customized to the needs of particular users or applications. PLANet [23] is an internetwork in which PLAN forms the interoperability ....

Michael Hicks, Pankaj Kakkar, Jonathan T. Moore, Carl A. Gunter, and Scott Nettles. Network programming with PLAN. In Workshop on Internet Programming Languages. Springer, 1998. To appear.

....at PLAN evaluation time. In PLANet, service routines are implemented as active extensions written in Caml. This two level architecture of PLAN and service routines is summarized in Table 1, which is drawn from [22] This combination provides a powerful programming style which we describe in [21] and have illustrated in PLANet. PLAN provides very efficient, light weight mobile agents that invoke services to achieve flexible network utilization that can be customized to the needs of particular users or applications. PLANet [23] is our implementation of an internet work in which PLAN ....

Michael Hicks, Pankaj Kakkar, Jonathan T. Moore, Carl A. Gunter, and Scott Nettles. Network programming with PLAN. In Workshop on Internet Programming Languages. Springer, 1998. To appear.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC