One document matched: draft-muramoto-irtf-sam-exp-testbed-00.txt
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
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]
| PAFTECH AB 2003-2026 | 2026-04-24 08:44:11 |