[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

INTERNET DRAFT                                      E. Muramoto, Y. Imai
<draft-muramoto-irtf-sam-exp-testbed-00.txt>                        WIDE
                                                              S. Sakurai
                                                             Univ. Tokyo
                                                     F.Kan, N. Kawaguchi
                                                            Univ. Nagoya
                                                     D.Matsui, Y.Shinoda
                                                               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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

      Copyright (C) The IETF Trust (2007).  All Rights Reserved.


   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

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

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,

[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-

[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

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-

[XLIC]  A. Nakano, Innovating Environment to Lay Groundwork for Future
        Network Research, Presentation in JGNII Symposium 2007,

[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-

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

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


      Funding for the RFC Editor function is currently provided by the
      Internet Society.

Muramoto, et al.          Expires November 2007                [Page 12]

Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/