chapter 5.1 functional requirements
DESCRIPTION
TRANSCRIPT
![Page 2: Chapter 5.1 Functional requirements](https://reader036.vdocuments.us/reader036/viewer/2022082623/54642eb6af79596b4d8b5d68/html5/thumbnails/2.jpg)
Table of Contents1. Requirement for GENI 1.1 Multiple Simultaneous Experiments
1.2 Generality
1.3 Support for Real Applications
1.4 Support for Real Users
1.5 Fidelity
1.6 Support for All Aspects of a New Network Architecture
1.7 Support for Experimenters
1.8 Federation & Sustainability
1.9 Striking a Balance
2. Related Work 2.1 PlanetLab & Virtual Network Infrastructure
2.2 User Controlled LightPath & Articulated Private Network
2.3 Relation among PlanetLab, VINI and UCLP
![Page 3: Chapter 5.1 Functional requirements](https://reader036.vdocuments.us/reader036/viewer/2022082623/54642eb6af79596b4d8b5d68/html5/thumbnails/3.jpg)
1. Requirement for GENI
![Page 4: Chapter 5.1 Functional requirements](https://reader036.vdocuments.us/reader036/viewer/2022082623/54642eb6af79596b4d8b5d68/html5/thumbnails/4.jpg)
1.1 Multiple Simultaneous Experiments• The concept behind GENI - It can be used to multiple ideas and concepts
• To support multiple experiments simultaneously
=> The concept of slices - The resources of GENI can be divided up among many different researchers in
such a way that each can run his own experiment
• Virtualization - One approach to slices
- A processor, a fiber link, wireless system, ...
• Controlled Isolation - GENI must provide strong containment for experiments
- GENI must support controlled interconnection of slices to each other and to the
current Internet
![Page 5: Chapter 5.1 Functional requirements](https://reader036.vdocuments.us/reader036/viewer/2022082623/54642eb6af79596b4d8b5d68/html5/thumbnails/5.jpg)
1.2 Generality• We want to build an experimental platform that can support
a wide range of future Internets
• How much generality is required to support the anticipated
experiments? - To experiment with packet formats that materially differ from those of the
Internet
- To move beyond the paradigm of packet switching and explore other modes for
sharing and resource allocation
- To exploit specific features of the different technologies included in GENI
- To experiment with architectures that include network-level operations other
than simple packet forwarding
• Diversity of technology
• Balancing generality with cost
![Page 6: Chapter 5.1 Functional requirements](https://reader036.vdocuments.us/reader036/viewer/2022082623/54642eb6af79596b4d8b5d68/html5/thumbnails/6.jpg)
1.3 Support for Real Applications• GENI should be able to support not just a future network,
but also the applications that might run on that network
• To attract real applications, the GENI must include facilities
for development and deployment of applications, not just
data transport
![Page 7: Chapter 5.1 Functional requirements](https://reader036.vdocuments.us/reader036/viewer/2022082623/54642eb6af79596b4d8b5d68/html5/thumbnails/7.jpg)
1.4 Support for Real Users• If we are to gain real experience with real applications, we
must allow real users to try them out, and make real use of
them
• What does it mean to support real users? - The GENI facility must reach “to the edge” of the network, where the users
connect
- There must be a rich connectivity between GENI and the Internet of today
- There must be an adequate pool of potential users that have end-node
computers directly connected to, and a part of, the GENI infrastructure
- Some support for slices needs to be provided for the end-nodes that are
attached to GENI
![Page 8: Chapter 5.1 Functional requirements](https://reader036.vdocuments.us/reader036/viewer/2022082623/54642eb6af79596b4d8b5d68/html5/thumbnails/8.jpg)
1.5 Fidelity• Reach - As wide a reach as possible
• Topology - Keeping delays within a small factor of physical distance
- Path diversity
- Underlying fiber paths
- Major interconnection points (exchange points, aggregation points)
• Realism of virtualization
• Physical distribution
• Scale
• Failure modes - Intentionally induced failure, unanticipated failure
![Page 9: Chapter 5.1 Functional requirements](https://reader036.vdocuments.us/reader036/viewer/2022082623/54642eb6af79596b4d8b5d68/html5/thumbnails/9.jpg)
1.6 Support for All Aspects of a New Network Architecture
• Support for management - It must important that the management aspects of all devices be fully virtualized
- We can have the equivalent of “virtual system operators”
• Support for security - The GENI infrastructure itself must be stable and secure
- The mechanisms for isolation among slices must be very robust
- There may be a requirement for specialized security technology
• Support for anticipated future capabilities - In 10 years, there may be features that will be commonplace then, but are not
yet realized in any effective way
![Page 10: Chapter 5.1 Functional requirements](https://reader036.vdocuments.us/reader036/viewer/2022082623/54642eb6af79596b4d8b5d68/html5/thumbnails/10.jpg)
1.7 Support for Experimenters• Ease of Use - GENI must remove as many practical barriers as possible to researchers being
able to make full use of the facility
• Observability - GENI must offer strong support for measurement-based quantitative research
• Fail-safe - GENI must be secure, so that its resources cannot accidentally or maliciously
be used to attack today’s Internet
• Sources of real traffic - GENI must provide a way experiments can be run with real traffic
- One approach: to have several large-scale popular services
ex) content distribution networks
![Page 11: Chapter 5.1 Functional requirements](https://reader036.vdocuments.us/reader036/viewer/2022082623/54642eb6af79596b4d8b5d68/html5/thumbnails/11.jpg)
1.8 Federation & Sustainability• GENI must be designed for a 15-20 year lifetime
• To ensure the sustainability - Support for federation
- Design with operational costs in mind
• Addition of new technology - Open hardware interfaces
- The ability to virtualize devices
- The ability to incorporate new devices into the GENI management mechanisms
• Living in the future - GENI is supposed to be a tolerably realistic emulation of a networking
technology base 10 years in the future
![Page 12: Chapter 5.1 Functional requirements](https://reader036.vdocuments.us/reader036/viewer/2022082623/54642eb6af79596b4d8b5d68/html5/thumbnails/12.jpg)
1.9 Striking a Balance• What makes GENI a unique and compelling instrument is
how it balances requirements to support research that
simply cannot be done today - Resolving conflicts among requirements (ex. Sliceability vs Fidelity)
- Recognizing the specific combination of capabilities that are unique to GENI
(1) wide-spread deployment
(2) a diverse and extensible collection of network technologies
(3) support for real user traffic
![Page 13: Chapter 5.1 Functional requirements](https://reader036.vdocuments.us/reader036/viewer/2022082623/54642eb6af79596b4d8b5d68/html5/thumbnails/13.jpg)
2. Relate Work
![Page 14: Chapter 5.1 Functional requirements](https://reader036.vdocuments.us/reader036/viewer/2022082623/54642eb6af79596b4d8b5d68/html5/thumbnails/14.jpg)
2.1 PlanetLab & VINI• PlanetLab - PlanetLab is a global overlay network for developing and accessing broad-
coverage network services [Chun 03]
- PlanetLab allows multiple services to run concurrently and continuously, each in
its own slice of PlanetLab [Chun 03]
* Slice: A horizontal cut of global resources [Chun 03]
The substrate resources bound to a particular experiment [Clark 07]
• Virtual Network Infrastructure (VINI) - VINI is a virtual network infrastructure that allows network researchers to
evaluate their protocols and services in a realistic environment that also
provides a high degree of control over network conditions.
- PL-VINI is a prototype of a VINI that runs on the public PlanetLab. PL-VINI
enables arbitrary virtual networks, consisting of software routers connected by
tunnels, to be configured within a PlanetLab slice.
![Page 15: Chapter 5.1 Functional requirements](https://reader036.vdocuments.us/reader036/viewer/2022082623/54642eb6af79596b4d8b5d68/html5/thumbnails/15.jpg)
2.2 UCLP & APN• User Controlled LightPath (UCLPv2) - UCLP is a network virtualization management tool built using web services
[Lemay 06]
ex) XC-WS(Cross Connect Web Service) for SONET, SDH and Lambda Cross
Connects
- Users can create several parallel application specific networks from a single
physical network through UCLP [Lemay 06]
• Articulated Private Network (APN)
- An aggregate mix of resources [St.Arnaud 07]
![Page 16: Chapter 5.1 Functional requirements](https://reader036.vdocuments.us/reader036/viewer/2022082623/54642eb6af79596b4d8b5d68/html5/thumbnails/16.jpg)
2.3 Relation among PlanetLab, VINI and UCLP
<Current Relation> <Target Relation>