Date post: | 26-Dec-2015 |
Category: |
Documents |
Upload: | curtis-armstrong |
View: | 214 times |
Download: | 0 times |
2
Recall of Internet (’74) Design Goals
(0) To connect existing networks (1) Survivability (2) To support multiple types of services (3) To accommodates a variety of physical networks (4) To allow distribute network management (5) To be cost effective (6) To allow host attachment with a low level of effort (7) To allow resource accountability
Design Principles Layering (design goal – 0, 3) Packet Switching (design goal – 5) A network of collaborating networks (design goal – 1, 4) Intelligent end-system / end-to-end arguments (design
goal – 1, 5) DHCP (design goal – 6), SNMP (design goal – 7)
3
Changes of Networking
Environment Trusted => Untrusted
Users Researchers => Customers
Operators Nonprofits => Commercial
Usages Host-oriented => Data-centric
Connectivity E2E IP => Intermittent Connection
4
Assumptions Incremental Design
A system is moved from one state to another with incremental patches
How should the Internet look tomorrow ? IETF and IPv6 perspective
Clean-Slate Design The system is re-designed from scratch How should the Internet look in 15 year ?
Future Internet It is assumed that the current IP’s shortcomings will not be
resolved by conventional incremental and “backward-compatible”
style designs. So, the Future Internet designs must be made
based on clean-slate approach.
5
Problem Statement (1/4)
1. Basic Problems 1.1. Routing Failures and scalability
The problems have been examined as being caused by mobility, multi-homing, renumbering, PI routing, IPv6 impact, etc. on the current Internet architecture.
1.2. Insecurity As current communication is not trusted, problems are self-
evident, such as the plague of security breaches, spread of worms, and
denial of service attacks.
1.3. Mobility Current IP technologies was designed for hosts in fixed locations,
and ill-suited to support mobile hosts. Mobile IP was designed to support host mobility, but Mobile IP has
problems on update latency, signaling overhead, location
privacy, etc.
6
Problem Statement (2/4)1. Basic Problems 1.4. Quality of Service
Internet architecture is not enough to support quality of service from
user or application perspective. It is still unclear how and where to integrate different levels of
quality of service in the architecture.
1.5. Heterogeneous Physical Layers and Applications Recently, IP architecture is known as a “narrow waist or thin
waist”. Physical Layers and Applications heterogeneity poses
tremendous challenges for network architecture, resource allocation, reliable transport, context-awareness, re-configurability, and security.
1.6. Network Management The original Internet lacks in management plane.
Source : Steve Deering,IPv6 :addressing the future
Narrow Waist forInternet Hourglass
(Common Layer = IP)
7
Problem Statement (3/4)1. Basic Problems 1.7. Congestive Collapse
Current TCP is showing its limits in insufficient dynamic range to handle
high-speed wide-area networks, poor performance over links withunpredictable characteristics, such as some forms of wireless link,
poorlatency characteristics for competing real-time flows, etc.
1.8 Opportunistic and Fast Long-Distance NetworksOriginal Internet was designed to support always-on connectivity,
shortdelay, symmetric data rate and low error rate communications, butmany evolving and challenged networks do not confirm to this designphilosophy. E.g., Intermittent connectivity, long or variable delay, asymmetric
data rates, high error rates, fast long-distance communications, etc. 1.9. Economy and Policy
The current Internet lacks explicit economic primitives.There is a question of how network provider and ISP continue to makeprofit.
8
Problem Statement (4/4)
2. Problems with Original Design Principles 2.1. Packet Switching
Packet switching is known to be inappropriate for the core of networks and high capacity switching techniques (e.g.,
Terabit). 2.2. Models of the End-to-End Principle
The Models of the end-to-end principle have been progressively eroded, most notably by the use of NATs, which modify
addresses, and firewalls and other middle boxes End hosts are often not able to connect even when security
policies would otherwise allow such connections.2.3. Layering Layering was one of important characteristics of current IP technologies, but at this phase, it has inevitable inefficiencies. One of challenging issues is how to support fast mobility in heterogeneous layered architecture.
10
Internet: Success Story Packet Switching (1962) ARPANet (1969) Internet Concept (1974) : “inter-net” TCP/IP protocol suite (1978) 1st IETF meeting at San Diego (1986) World Wide Web (1993)
11
New Design Goals
Scalability Security Mobility Quality of Service Heterogeneity Robustness Customizability Economic Incentives
12
Design Goals (1/4)
Scalability Scalability issue is emerging as continuous growth
of cultural demands for networking in the future. Routing and addressing architecture Multi-homing and PI routing
Security The FN should be built on the premise that security must be protected from the plague of security breaches, spread of worms and spam, and denial
of service attacks, etc .
13
Design Goals (2/4)
Mobility The FN should support mobility of devices,
services,users and/or groups of those as seamlessly, as itsupports current wired and wireless Supporting New Devices/Networks Context-awareness Multi-homing and Seamless Switching
Quality of Service The FN should support quality of service (QoS)
fromuser and/or application perspectives.
14
Design Goals (3/4) Heterogeneity
The FN should provide much better support for a broadrange of applications/services and enable newapplications/services. In addition, it should accommodateheterogeneous physical environments. Application/Service Heterogeneity Physical Media Heterogeneity Architecture Heterogeneity
Robustness The FN should be robust, fault-tolerant and
available as the wire-line telephone network is today.
Re-configurability Manageability
15
Design Goals (4/4)
Customizability The FN should be customizable along with various user requirements. Context-Aware Numbering and Content-Centric
Service Service-Specific Overlay Control and Service
Discovery Economic Incentives
The FN shall provide economic incentives to the components/participants that contribute to the networking.
16
Building Blocks
Meta architecture (diverse architecture)
Architecture Mechanism Service/ applications
17
Internet vs. FI
Current Internet :Architecture – TCP/IP (Narrow Arch.)Mechanism – SNMP, IPsec …Application – Web, E-mail …
FI :Meta Architecture : Multiple Architectures ArchitectureArchitecture – TCP/IP, Intermittent X, ….Mechanism – SNMP, IPsec, Cognitive, Cooperative,Application – Web, E-mail, Sensor, Vehicle/aircraft, Satellite
18
Meta Architecture
Network virtualization Realize virtual network with programmable network elements. Multiple architectures architecture or no architecture
Federation of different architecture regions Heterogeneous networks with heterogeneous
architectures
connected with gateway New layered architecture
Violate strict layering abstraction Instead, use other layers’ functionalities (APIs) to do something efficiently
Diverse models of the end-to-end principle
19
Network Virtualization
De-ossifying the current Internet Multiple virtual networks co-exist on top of a shared substrate. Different virtual networks provide alternate
end-to-endpacket delivery systems and may usedifferent protocols and packet formats.
Easily programmable Can experiment on any level (optical to apps)
E.g., GENI (Global Environment for NetworkInnovations)
21
Testbed vs. Infrastructure
GENI in Progress
Success Story (spiral
development)
• PlanetLab : http://www.planet-lab.org
• VINI (Virtual Network Infrastructure)
http://www.vini-veritas.net
22
PlanetLab(1) What is PlanetLab?
Consortium: joint Academic, Government, Industry venture Formally formed January 2004 Hosted by Princeton University, UC Berkeley, and U. of
Washington United States Government funded (NSF and DARPA) Hewlett Packard and Intel as founding Industrial members
AT&T, France Telecom, Polish Telecom, Google, NEC, … Facility: Planetary-scale “overlay” and “underlay” network
700+ Linux-based servers at 300+ sites in 30+ countries Researchers can get a virtual machine on each server (SLICE) In a SLICE across PlanetLab researchers can deploy & evaluate … … distributed systems services and applications “The next Internet will be created as an overlay in the current
one” … network architectures and protocols “The new Internet will be created in parallel next to the current
one”
23
PlanetLab(2) PlanetLab Facility Today
784 servers at over 382 sites Co-located throughout the (developed) world @ Uni. &
Companies Co-located at network crossroads (Internet2, RNP,
CERNET, …)
24
PlanetLab(3)
The Importance of Systems Building Systems-oriented CS research needs to
build and try out its ideas to be effectivePaper designs are just idle speculationSimulation is only occasionally a substitute
We need:Real implementationReal experienceReal network conditionsReal usersTo live in the future
25
PlanetLab(4)
Limitations of Traditional Approaches Simulation based on limited models
Topologies, administrative policies, workloads, failures…
Emulation (and “in lab” tests) are similarly limited Only as good as the models
Conventional testbeds are (too narrowly) targeted Not cost-effective to test every good idea Often of limited reach; no real users Often with limited programmability
26
VINI (1)
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. VINI allows researchers to deploy and to deploy and evaluate their ideas with real routing software, evaluate their ideas with real routing software, traffic loads, and network eventstraffic loads, and network events. To provide researchers flexibility in designing their experiments, VINI supports simultaneous experiments with arbitrary network topologies on a shared physical infrastructure.
VINI currently consists of 37 nodes at 22 sites connected to the National LambdaRail, Internet2, and CESNET (Czech Republic).
28
Different Arch. & Gateway
Tie together heterogeneous networks Gateway spans multiple architecture regions
that use different protocols Applications can communicate across multiple architecture regions
E.g., DTN Bundle Layer and Gateway
29
DTNs Delay-Tolerant Networking (DTN) is an approach
to computer network architecture that seeks to address the technical issues in mobile or extreme environments, such as deep-space, that lack continuous network connectivity
Goals Support interoperability across ‘radically heterogeneous’
networks Tolerate delay and disruption
Acceptable performance in high loss/delay/error/disconnected environments
Decent performance for low loss/delay/errors Components
Flexible naming scheme Message abstraction and API Extensible Store-and-Forward Overlay Routing Per-(overlay)-hop reliability and authentication
32
Cross-Layer Communications
Avoid Layering Concept Exploit the dependency between protocol layers to obtain performance gains Direct communication between protocols at nonadjacent layers or sharing variables between layer
Optimization Abstraction E.g., Cross-layer Design for Wireless Mobile Network
Create new interfaces between layers, redefine the layer boundaries, design protocol at a layer based on the details of how another layer is designed, joint tuning of
parameters across layers, or create complete new abstraction
33
Cross-Layer Design Proposals
Source : V. Srivastava et al., Cross-layer design, IEEE Comm. Magazine, 2005
34
Diverse E2E Communications
Original E2E Concerned with end-to-end services and protocols
implemented in hosts, such as transport protocols and implementation architecture for high performance.
e.g., presentation layer design, application-layer framing, high performance host interfaces, and efficient protocol implementation techniques.
EME (End-Middle-End) While still end-to-end in many ways, connection
establishment in the Internet today involves state and functionality in the middle in the form of NATs, firewalls, proxies and so on .
The current Internet architecture does not reflect this resulting in a mismatch between design and practice.
There are some signaling based solutions to connection establishment
35
Architecture Components
Network addressing and naming Routing protocols Backbone design Circuit & Packet Heterogeneous physical layers Heterogeneous applications Security
36
Architecture (E.g.) (1/2) Data Oriented Network Architecture
Data dissemination rather than p2p conversation DONA : The Data-Oriented Network Architecture
explores a clean-slate data-centric approach to Internet architecture. The key observation that motivates this design is that the vast majority of current Internet usage is data retrieval, where the user cares about content and is oblivious to its location.
CCN: Content Centric Network Autonomic Communication
Manageability ANA: Autonomic Network Architectures CASCADAS:Component-ware for Autonomic Situation-aware
Communications, and Dynamically Adaptable Services Bio-Inspired Network
Use biological concept for network Service generation with natural selection/ evolution Security with immune system
37
Architecture (E.g.) (2/2)
Opportunistic Communication Send packet according to the link condition Store & forward DTN Haggle: A European Union funded project in
Situated and Autonomic Communications I3
Mobility Internet indirection infrastructure
38
I3 (Internet Indirect Infrastructure)
Each packet is associated with an id this id is used by the receiver to obtain delivery of the packet. host R that inserts a trigger (id, R) in the i3 infrastructure to receive all packets with identifier id.
When a host changes its address, the host needs only to update its trigger.
When the host changes its address from R1 to R2, it updates its trigger from (id, R1) to (id, R2).
As a result, all packets with identifiers id are correctly forwarded to the new address.
40
Mechanisms Wireless
Cognitive Cooperative Coopcom: http://www.coopcom.eu.org/home.php Viral network
Optical P2p
DHT(Distributed Hash Table) Pastry
Security Self-revealing content Public key/ ECC
Manageability High level Abstraction
Building Block Lego like building blocks
42
Global Collaboration (1/3)
ISO/IEC JTC1/SC6 Ad-hoc Meeting for Future Network (Paris, 4-5 Sept. 2007) SC6 Meeting (Geneva, April 2008)
Trial for initiation of NP Ballot within JTC1 Start New Work from the end of 2008 It may be almost aligned with possible activities for the next study period of ITU-T (2009-2012)
43
Global Collaboration (2/3)
ITU-T NGN-GSI, SG13
New Question Proposal on the Future Network (Sept. 2007, Geneva New Question Proposal on the Future Network (Jan. 2008, Seoul)
SG17 New Questions on Future Open System Communications Technology
44
Global Collaboration (3/3)
IRTF The Chairs of six of the fourteen Research Groups comprising IRTF have funded FIND proposals -
dtnrg, eme, end2end, imrg, p2prg, rrg New Works Considered
Network virtualization RG QoS policy framework RG Cross-layer communication in TSV
45
Conclusions
Detailed specifications for optimal architecture?
Implementation and Testbed Other considerations?
46
References Myung-ki Shin, Meta Architecture for Future Internet, HSN 2008
Presentation Material PlanetLab : http://www.planet-lab.org VINI (Virtual Network Infrastructure)
http://www.vini-veritas.net http://i3.cs.berkeley.edu/ IPv6: Addressing the future
http://www.6journal.org/archive/00000012/01/steve_deering.pdf DTN,
http://www.cs.berkeley.edu/~demmer/talks/dtn-tutorial-mobihoc-may06.ppt
http://www.ipnsig.org/reports/DTN_Tutorial11.pdf Haggle, http://www.haggleproject.org/index.php/Main_Page