Dynamic Autoconfiguration in 4G Networks: Problem Statement and ...

Nevertheless, the node implementing the TurfNet gateway insidethe PAN would have to change according to the differentTurfNets the PAN would compose with along the time; currentlythe TurfNet framework does not support this.ANs and Composition. Considering a scenario similar to ours, in[2] a solution enabling automatic and dynamic creation of a PANand selection of the proper access network is provided. Thesolution is based on the Ambient Network (AN) and NetworkComposition concepts being studied in the European project WWIAmbient Networks [6]. Nonetheless, this solution just concernsabout IPv6 and does not address the heterogeneity coming up withcoexistence of IPv4 and IPv6 in the current Internet. Therefore, itjust solves part of the problem presented in Section 3.MANETs autoconfiguration mechanisms. The IETF MANETAUTOCONF working group addresses autoconfiguration inMobile Ad-hoc Networks (MANETs). This group is searching fora standard autoconfiguration solution for MANETs, where eachterminal is always acting as a router and running a routingprotocol to maintain IP connectivity with the other terminals inthe same MANET. Some autoconfiguration protocols forMANETs are already defined [8], and certainly the IETF solutionwill be influenced by them. In contrast with our solution,MANETs require that each terminal acts as a router; in ourapproach terminals may assume different roles along the timeaccording to the network context, and their interaction is based onoffered and required services. Furthermore, current MANETsautoconfiguration and routing protocols suffer from a problemmentioned before: separate solutions are provided concerningeach IP version, and there is no mechanism enabling the selectionof a proper framework considering the network context.6. FURTHER WORKThis paper focused on the autoconfiguration of IP nodes for nextgeneration networks. Other issues that could be consideredinclude mobility, multihoming, and security. These problems arepartially solved by existing frameworks, such as Mobile IP, whichcan be used in conjunction with MAF. Regardingautoconfiguration, work on the link layer still remains to be done.For instance, authentication in wireless LANs raises newautoconfiguration problems that need to be solved before thenetwork layer autoconfiguration can be accomplished. On theother hand, MAF needs to be fully specified and validated. Asdefined now, it does not guarantee session continuity, and theusers will notice service interruption everytime the access IPnetwork changes. The development of a prototype enabling theproof of concept and the evaluation of the Meta-Autoconfiguration Framework (MAF) will be the next step of ourwork.7. CONCLUSIONSIn current IP networks two versions of the same protocol coexist.On the other hand, multiple autoconfiguration frameworksassociated to each version are defined, leading to heterogeneousenvironments. In this scenario, user intervention may be requiredto perform tasks that should be done automatically. Furthermore,existing autoconfiguration frameworks are not sufficient bythemselves to enable autoconfiguration in future dynamiccommunication scenarios, where users will own small networks,instead of single terminals. This paper analysed the shortcomingsassociated to the state of art of autoconfiguration mechanisms. Weconcluded that there is a lack of an integrating solution capable ofunifying the autoconfiguration mechanisms available andautoconfiguring nodes and start network services according tonetwork contexts. In order to improve the current scenario, a newframework was discussed, which enables the integration ofcurrent autoconfiguration mechanisms and addresses the newcommunication paradigms illustrated by the example scenarioprovided.8. ACKNOWLEDGEMENTThe first author would like to thank the support from FCT underthe fellowship SFRH/BD/19429/2004/.9. REFERENCES[1] 3GPP TS 23.060, General Packet Radio Service (GPRS)Service description Stage 2, v6.8.0, March 2005.[2] C. Kappler, N. Akhtar, R. Campos et al., NetworkComposition using Existing and New Technologies, inProceedings of the14th IST Mobile & WirelessCommunications Summit 2005, Dresden, Germany, June 19-23, 2005.[3] D. Haskin, et al., IP Version 6 over PPP, RFC 2472,December 1998.[4] D. Sönnerstam, et al., Specification of the Bluetooth System(version 1.2), November 2003.[5] G. McGregor, The PPP Internet Protocol Control Protocol(IPCP), RFC 1332, May 1992.[6] http://www.ambient-networks.org/[7] http://www.zeroconf.org[8] K. Weniger, et al., Address Autoconfiguration in Mobile AdHoc Networks: Current Approaches and Future Directions,IEEE Network, vol. 18, (August 2004), 6-11.[9] P. Srisuresh, et al., IP Network Address Translator (NAT)Terminology and Considerations, RFC 2663, August 1999.[10] R. Droms, Dynamic Host Configuration Protocol, RFC2131, 1997.[11] R. Droms, et al., Dynamic Host Configuration Protocol forIPv6 (DHCPv6), RFC 3315, July 2003.[12] R. Droms, Stateless Dynamic Host Configuration Protocol(DHCP) Service for IPv6, RFC 3736, April 2004.[13] S. Cheshire, et al., Dynamic Configuration of IPv4 Link-Local Addresses, RFC 3927, May 2005.[14] S. Cheshire, et al., Multicast DNS, Internet Draft, draftcheshire-dnsext-multicastdns-05(work in progress), July2005.[15] S. Cobb, PPP Internet Protocol Control Protocol Extensionsfor Name Server Addresses, RFC 1877, December 1995.[16] S. Schmid, et al., TurfNet: An Architecture for DynamicallyComposable Networks, in Proceedings of the First IFIP TC6WG6.6 International Workshop on AutonomicCommunication, Berlin, Germany, October 2004.[17] S. Thomson, et al., IPv6 Stateless AddressAutoconfiguration, RFC 2462, December 1998.[18] T. Chown, et al., DHCP: IPv4 and IPv6 Dual-Stack Issues,Internet Draft, draft-ietf-dhc-dual-stack-03 (work inprogress), July 2005.[19] T. Narten, et al., Neighbor Discovery for IP Version 6(IPv6), RFC 2461, December 1998.[20] W. Simpson, Ed., The Point-to-Point Protocol (PPP), RFC1661, July 1994