INTERNET DRAFT E. Muramoto, Y. Imai WIDE S. Sakurai Univ. Tokyo F.Kan, N. Kawaguchi Univ. Nagoya D.Matsui, Y.Shinoda JAIST May, 2007 Expires November, 2007 Experimental Deployment Method for Router Supported ALM using PlanetLab Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The IETF Trust (2007). All Rights Reserved. Abstract This document describes the experiment method of router supported ALM using PlanetLab. 1. Introduction Muramoto, et al. Expires November 2007 [Page 1] Internet Draft draft-muramoto-irtf-sam-exp-testbed-00.txt May 2007 Test-BED sometimes accelerates research work and deployment activity. PlanetLab is famous test-BED for P2P researchers and there are several trial services like CDN service, DNS service, file transfer, and conferencing service (End System Multicast), etc. But the researchers can not have an experiment of routing function or routing protocol itself in PlanetLab because it does not provide separate routing table and routing engine for each experimenter. We have made a routing related experiment in PlanetLab using UML( User Mode Linix). We selected XCAST6 as representative protocol of the router supported ALM and had experiment on a few PlanetLab nodes. This document describes the experiment method as an informative reference for SAM-RG community. Next section, we introduce XCAST6 as router supported ALM. We enumerate requirements for deployment method of Router Support ALM in section 3,. The experiment method in PlanetLab is described in section 4. We refer several related work in section 5 and conclude this document in section 6. 2. XCAST6 as router support ALM This section introduces XCAST6 as an example of router supported ALM. 2-1. Advantage and Disadvantage of ALM The one of the advantage of ALM is easy-boot strap. To start up IP- multicast[DEER] service, they have to make their entire routers IP- multicast capable. It sometimes disturbed the spread of those services[AMMAR]. On the other hand, to start up ALM service, they need not install any equipment in the network at all and they can easily start up ALM service. But many researcher points out problems of selfish routing in overlay approach [TAON], [SROU]. The logical group management function optimizes its own performance goal not considering system-wide criteria. It means traffic cannot be controlled by the network operator at all. 2-2. XCAST6 as Router Supported ALM eXplicit Multi-Unicast (Xcast)[XCAST] is a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address. Therefore, the data packets have knowledge about distribution tree. It might mean Xcast packet could give the network operator the chance to estimate the traffic trend and to increase the bandwidth properly. That is, Xcast packet is treated as normal unicast packet in Xcast-unaware-router. If the entire routers in a network operator are Xcast-unaware router, the packet travels end to end in daisy chain. If the network operator installs Xcast-aware-router in the major traffic exchange point of Muramoto, et al. Expires November 2007 [Page 2] Internet Draft draft-muramoto-irtf-sam-exp-testbed-00.txt May 2007 the Xcast traffic, the traffic will be decreased. In another word, Xcast is "router supported ALM". If a Xcast-aware-router is settled properly, Xcast packet travels ideally. 3. Requirements of Deployment method of Router Supported ALM The traffic of the router support ALM would be decreasing if the router settled. To test such kind of feature in the real field, we need appropriate test-BED for that purpose. Moreover, the advantage of ALM approach is easy boot strapping. The protocol experimenter or candidate service provider requires real-field test-BED involving number of participant to maximize the advantage of ALM. This section describes the requirements of test-BED for the Router Support ALM. 1) Real code is executable There are several step in development of network protocol development. In early stage, they use network simulator like ns-2[NS-2] to test the functionally itself of confirm the feature in various environment. In the later stage, we require the test BED for the real implementation of the protocol. The excitability of the real code is important in such stage. 2) User opt-in As described in previous section, the advantage of ALM approach is easy boot strapping of service. The function that end user can involved in is necessary for deployment test of ALM service. 3) Deployment over the Internet The larger of the coverage of network service is the more benefit of communication via the network. To maximize the benefit of easy boot strapping network service capablility, the coverage of the test-BED should be as large as the Internet. 4) Scalability of number of participant To confirm the applicability of the future ALM service, the capacity of the test-BED itself should also as much as the expected scale of the service. 5) Easy to create a network topology To confirm the router support functionality, the topology of the test-BED should be flexible. That is, easiness to create a experimental network topology is important. Muramoto, et al. Expires November 2007 [Page 3] Internet Draft draft-muramoto-irtf-sam-exp-testbed-00.txt May 2007 6) Easy to modify the protocol In feasible study activity, the protocol experimenter wants to modify his/her protocol several times. The test-BED should be capable to provide the easy protocol updating function and to restart or sometimes to stop the experiment as the experimenter requires. 7) Manageability of the experimental node In the field experiment, it is suitable to exchange the experimental node because the nodes are sometimes broken physically or sometimes power down or network down for maintenance occurs. The functionality to replace the experiment node is important. 4. XCAST6 TestBED over the PlanetLab We have implemented and tested our test-BED on PlanetLab which intend to satisfy the requirements described previous section. This section describes the details of the test-BED and experimental trial for XCAST6 deployment using it. 4-1. Implementation XCAST6 routing function on a PlanetLab node (sliver) We have implemented XCAST6 routing function in a PlanetLab node. PlanetLab node is called "sliver" which provides for an experimenter end node function. The normal sliver does not have routing capability. That is, the experimenter can install the end host implementation on a sliver and test it. But he/she cannot test the routing function in PlanetLab. To solve the problem, we utilize the UML (user mode linx) to be installed in sliver. We have applied XCAST6 kernel patch to the UML source code and made XCAST6 enable UML kernel. UML can be installed in the normal PlanetLab. Therefore, the requirement 1,3 and 7 could be satisfied. Figure 1 explains the key components. The PlanetLab slivers have the above described UML and the UML-UDP which is the modified version of UML-switch capable to connect another UML in another sliver of PlanetLab using IPv6 over UDP/IPv4 packet. Muramoto, et al. Expires November 2007 [Page 4] Internet Draft draft-muramoto-irtf-sam-exp-testbed-00.txt May 2007 PlanetLab node +----------------------------+ | sliver | | +-----------------+ | | | UML(XCAST6) | | | | +-----------+ | | | | | IPv6 | | | | | | Routing | | | | | | table | | | | | | + | | | | | | Routing | | | | | | engine | | | | | +-----------+ | | | | | | | | | +-----------+ | | | | | UML switch| | | | | | UML-UDP | | | | | +-----------+ | | | +-----|------|----+ | | UDP over IPv4 | | | | | +--------|------|------------+ | | | +--- another UML switch in another sliver + --------- Figure 1 Node A(ASIA) Node B(U.S.) +------------+ +------------+ | Sliver A | | Sliver B | | +-------+ | | +-------+ | | | UML | | | | UML | | | | | | | | | | | +-------+ | | +-------+ | | | | | | | | | +----|--|----+ +----|--|----+ | | IPv6 over UDP/IPv4 | | | +---------------------+ | | | | Node C(E.U.) | | +------------+ | | | Sliver C | | | | +-------+ | | | | | UML | | | | | | | | | Muramoto, et al. Expires November 2007 [Page 5] Internet Draft draft-muramoto-irtf-sam-exp-testbed-00.txt May 2007 | | +-------+ | | | | | | | | | +----|--|----+ | | | | | +-----------+ +------------+ Figure 2 Figure 2 explains the image of experiment on the PlanetLab. The experimenter can install UML to the sliver on several PlanetLab nodes and configure virtual tunnel between them. The IPv6 (XCAST6) packet travels between UMLs and the UML looks up the IPv6 routing table, copy and forward if necessary as defined in XCAST6 protocol. 4-2. Automatic configuration using Orbit To satisfy the above described requirement 5 (easy to create the topology) and 6(easy to modify the protocol) , we have developed automatic configuration tool called "Orbit". With "Orbit", the experimenter can describe his/her arbitrary topology and routing information in YAML(Yet Another Markup Language) format. The "Oribit" read the described configuration and generate a setup script which transfer the appropriate execute module like UML module or configuration file for UML-UDP to each slivers and invoke those module automatically. Moreover, we have developed visual configuration tool of the YAML file by Java, because it is still difficult for the experimenter to understand the topology which is written in plain text. The visual configuration tool generates the YAML format for "Orbit" according to the graphically described topology. 4-3. Deployment method using PlanetLab and Orbit The methodology which satisfies the requirement 2( User-opt-in), 4( Scalability ) and 8( Manageability) is required for a protocol promoter or for the person who want to spread a router support ALM service, because they want to have large scale experiment which involve normal user and operate them even if some experimental node might be broken or stop the entire experiment safely if unexpected problem might be occurred. For requirement 2( User-opt-in), we are planning to have settle l2tp-server in the UML and modify the UML-UDP to support to forward l2tp packet at the sliver to the l2tp-server in the UML. End user would install l2tp-client to be provided IPv6 connectivity in IPv4 network and XCAST6 enable vic and rat for XCAST6 video confirenceing. For requirement 4 and 8, we have been taking gradual experiment step. First we have tested our experiment in 4 nodes using Private PlanetLab with MyPLC. MyPLC is the administrative control center of sliver nodes of PlanetLab for private use. We have demonstrated them in CCNC2007[CDEM]. In addition we have made the Muramoto, et al. Expires November 2007 [Page 6] Internet Draft draft-muramoto-irtf-sam-exp-testbed-00.txt May 2007 same but the larger experiment environment with 11 nodes which emulate Internet2 backbone topology in StarBED[SBED,SPOS]. StarBED is the large scale internet emulator located in Japan. In StarBED, all experimental nodes have 2 type of network interface. One is for emulation of the Internet topology. The interface connects to the configurable VLAN switch and the experimenter configures them to emulate arbitrary topology. Another interface connects to the infrastructure switch which is for controlling node in the experiment. The experimenter can login the node from the infrastructure based interface anytime in the experiment even if the routing for the interface to the configurable VLAN switch is broken in the experiment. That is, in StarBED they could have controllable nodes for safety routing experiment. Using StarBED and MyPLC[MPLC], for example, the router support ALM service promoter will be able to emulate almost the same experiment topology like the ISP back bone and start the user-opt-in experiment connecting the configurable VLAN switch to several internet access points. They might be able to train the experiment operator or practice the emergency procedure to abort the experiment for unexpected trouble like spreading virus or routing black hole. 4-4. Performance Consideration Our method utilizes UML as routing engine. It is just a user-land process; therefore there might be specious performance problem. We have briefly measured one aspect of the performance. We have settled 2 UML installed different sliver in PlanetLab and measured average RTT of ping. By native ping, it returns 16ms. On the other hand, it takes 17ms between the UMLs at the same machines. It means the overhead of UML routing is only 1ms in ping. It might not serious problem for routing. But we think further performance analysis is required. 5. Related Work This section compares our work with the state of arts. 5-1. VINI VINI[VINI] is the test-BED for routing protocol using PlanetLab. In VINI, they utilize UML as the routing engine and the user of VINI can test his/her own routing daemon implementation in VINI environment. But current VINI implementation mainly supports IPv4 and it is not intended to test the router support routing engine itself. Our method intended to provide the test method of IPv6 the router supported protocol and gradual and safety service deployment method. 5-2. Xlice Muramoto, et al. Expires November 2007 [Page 7] Internet Draft draft-muramoto-irtf-sam-exp-testbed-00.txt May 2007 Prof. Nakao of Tokyo University have developed and demonstrated the implantation of Xlice[XLIC]. Xlice enable to allocate Xen[XEN] to slivers. Whith Xlice we might not worry about the performance problem. Each experimenter individually might be able to plan the performance intensive experiment including router supported protocol. But Xlice is still working in progress activity and to utilize Xlice they have to deploy the Xlice enable node over the Internet. 5-3. X-bone X-bone[XBON] is another example of test-BED for routing protocol. But it also request users to deploy their terminal by themselves. And they develop GX-bone[GXBN] as a global infrastructure for testing overlay networks. But X-bone node uses two-layer IP-in-IP encapsulation, therefore if experimenter want to add routing function, he/she have to settle X-bone node by himself/herself. 6. Conclusion We have developed the test-BED method for router supported protocols to satisfy the requirement for next generation protocol development and deployment of user-opt-in services. We utilized UML(User Mode Linux) on PlanetLab to realize the separate routing engine for each sliver of the individual experimenter. We also developed a tunnel configuration tool named "Orbit" to create an overlay topology on PlanetLab connecting each UML with IPv6 over UDP/IPv4 tunnel. Additionally we have developed graphical configuration tool for "Orbit". We exemplified the use case of our method with 4 nodes and 11 nodes. We are taking gradual experiential step and we have tested them in StarBED. We think the global PlanetLab is now a kind of infrastructure and we should not stop the experiment service of them when we are performing the routing support ALM experiment. The routing related activity like integration of IP-multicast and ALM using AMT [JBUF] is in the scope in SAM-RG activity. We think the flexible test-BED for routing related research activity would accelerate SAM-RG activity too. "Orbit" is available at [OURL]. Our future works on this are to add the user-opt-in function to the UML, to evaluate the performance performing a trial with them. 7. Informative References [DEER] S. Deering, "Multicast Routing in a datagram internetwork", PhD thesis, December 1991..IP [AMMAR] 8 Mostafa H. Ammar, "Why Johnny Can't Multicast, Lessons about the Evolution of the Internet", 13th Intl. Workshop on Network and Operating Sys. Support for Digital Audio and Video (NOSSDAV 2003) Muramoto, et al. Expires November 2007 [Page 8] Internet Draft draft-muramoto-irtf-sam-exp-testbed-00.txt May 2007 [TAON] Junghee Han, David Watson, and Farnam Jahanian, Topology Aware Overlay Networks, INFOCOM 2005 [SROU] Lili Qiu, Yang Richard Yang, Yin Zhang, Scott Shenker, On Self- ish Routing in Internet-Like Environments, SIGCOMM 2003 [XCAST] R. Boivie, N. Feldman , Y. Imai , W. Livens , D. Ooms, O. Pari- daens, Explicit Multicast (Xcast) Basic Specification, draft- ooms-xcast-basic-spec-11.txt, March 2007. [NS-2] NS-2 homepage http://www.isi.edu/nsnam/ns/ [CDOM] N.Kawaguchi, XCAST PlanetLab integration, http://www.samrg.org/p2pm07/presentations/XcastOnPlanet- Lab20070111.pdf [SBED] StarBED homepage, http://www.starbed.org/ [SPOS] T.Miyachi, K.Chinen, Y.Shinoda, StarBED and SpringOS: Large- scale General Purpose Network Testbed and Supporting Software, International Conference on Performance Evaluation Methodlogies and Tools (Valuetools) 2006, ACM Press, ISBN 1-59593-504-5, Pisa, Italy, Oct.2006. [MPLC] My PLC user's guide homepage, http://www.planet- lab.org/doc/myplc [PLAB] B. Chuu, D. Culler, T.Roscoe, A.Bavier, L. Peterson, M. Wawrzo- niak, M. Bowman, PlanetLab: An Overlay Testbed for Broad Cover- age Services, http://www.planet-lab.org/, (2003) [VINI] A. Bavier, N.Feamster, M. Huang, L. Peterson, and J.Rexford, In VINI Veritas: Realistic and Controlled Network Experimention, in: Conference on Computer Communications(SIGCOMM2006) [XBON] J. Touch, Dynamic Internet Overlay Deployment and Management Using the X-Bone, Computer Networks, pp. 117-135(2001) [GXBN] J. Touch, Y. Wang, V. Pingali, L. Eggert, R. Zhou, G. Finn, Global X-Bone for Network Experiments, Proc. of IEEE Tridentcom 2005,pp.194-203(2005) Muramoto, et al. Expires November 2007 [Page 9] Internet Draft draft-muramoto-irtf-sam-exp-testbed-00.txt May 2007 [UML] J. Dike, User-Mode Linux, http://user-mode-linix.source- forge.net/ [XLIC] A. Nakano, Innovating Environment to Lay Groundwork for Future Network Research, Presentation in JGNII Symposium 2007, http://www.jgn.nict.go.jp/sympo2007/program/data/nakao.pdf [XEN] Xen homepage, http://www.xensource.com/xen/index.html [JBUF] J. Buford, Hybrid Overlay Multicast Framework, draft-irtf-sam- hybrid-overlay-framework-01.txt, January 2007. [OURL] Experimental code of Orbit, http://www.xcast.jp/~nano- dayo/orbit.tar.gz 8. Authors Addresses Eiichi Muramoto WIDE project in Japan E-mail: muramoto@wide.ad.jp Yuji Imai WIDE project in Japan E-mail: ug@xcast.jp Nobuo Kawaguchi Graduate School of Engineering, Nagoya University, Email: kawaguti@nagoya-u.jp Fumihiro Kan Graduate School of Engineering, Nagoya University, Email: kanon@el.itc.nagoya-u.ac.jp Satoru Sakurai Graduate School of Frontier Science, The University of Tokyo, Email: sakurai@yayoi.wide.ad.jp Muramoto, et al. Expires November 2007 [Page 10] Internet Draft draft-muramoto-irtf-sam-exp-testbed-00.txt May 2007 Daisuke Matsui Japan Advanced Institute of Science and Technology, Email: nanodayo@jaist.ac.jp Yoichi Shinoda Japan Advanced Institute of Science and Technology, Email: shinoda@jaist.ac.jp 9. Full Copyright Statement Copyright (C) The Internet Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 10. IPR Notices The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Muramoto, et al. Expires November 2007 [Page 11] Internet Draft draft-muramoto-irtf-sam-exp-testbed-00.txt May 2007 Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Muramoto, et al. Expires November 2007 [Page 12]