NewArch Final Technical Report

1
New Arch Future Generation Internet Architecture

• NewArch Final Technical Report
• 2007. 10. 29.
• Yoohwa Kang (uflora_at_kaist.ac.kr)
• KAIST

2
Contents

• Introduction
• The nature of network architecture
• Specific project results
• New perspectives

3
1. Introduction

• The goal of NewArch project was to begin
  formulating a new long-term technical road map
  for the Internet
• Approach
• Examination of the changed and changing
  requirements
• Examination of the failures of the original
  architecture
• Consultation with experts in relevant technical
  areas
• Mobility
• Economic model
• Embedded computing
• Development of new architectural principles and
  meta-architectural principles
• Development of proposals for specific design
  principles and approaches
• Implementation of proof-of-concept prototype

4
2. The nature of network architecture

• Modularity in the architecture
• Assuring interoperation
• Specifying function
• The end-to-end arguments in todays world

5
1. Modularity in the architecture

• Layered model
• Functional slices
• Performance specification spans all the layers
• The reality of topology
• Layered and functional slices do not directly
  describe physical distribution
• System topology what is connected to what?
• Physical location what is physically near what?
• Different parts of the system belong to different
  owner/operators
• Cloud model

6
1. Modularity in the architecture

• End-to-end arguments
• Functions in the network should be restricted
  to the lower layers of the dependency/abstraction
  model
• Application layer functions (higher level
  functions) should be moved up through the
  layers and out to the edges
• Produces a middle that can be general, simple,
  and flexible
• Generality and reuse
• Internet is conceived as a general-purpose,
  shared infrastructure
• Reuse of Internets services by multiple
  applications reusable transport service

7
2. Assuring interoperation

• Interoperation
• Ability of a set of computing elements to
  interact successfully when connected in a
  specified way
• Achieved by agreeing on a common definition of
  protocols
• Spanning layer
• At/above such a layer common standards contribute
  to interoperation, while below the layer
  translation is used
• Real interoperation is achieved by the definition
  and use of effective spanning layer
• Internet protocol (IP) as an example
• Other spanning layer examples
• NTSC video delivery
• ATM (Asynchronous Transfer Mode)

8
2. Assuring interoperation

• How to spot a spanning layer
• Below the spanning layer, the architecture
  presumes that there will be different
  technologies with different features
• Spanning layer must allow conversion among these
  different feature sets
• Specification of the end-to-end service what it
  must preserve, and what it can change or ignore,
  in performing the conversion
• Key to network evolution
• Spanning
• Conversion

9
3. Specifying function

• Transparency/Openness
• Network is oblivious to the meaning of the data
  (Syntax)
• Understanding of the meaning lives only at the
  edge (Semantics)
• Not oblivious network Telephone system
• Problems caused by weak network semantics can
  be fixed up at the edge
• Principle of weak semantics is under attack
• Some data impairments that cannot be removed
  telephone calls and real-time interactions
• To fix a problem at the end point may make the
  application designers job harder
• Network providers would like to offer enhance
  services
• Pressure to break the oblivious model and build
  knowledge of the meaning of the data into the
  network

10
4. End-to-end arguments in todays world

• Forces militate against oblivious principle
  Blumen01
• Parties with interests adverse to the user (e.g.
  wiretap) cannot expect the user to implement this
  at the end-point
• Internet service providers who want to enhance
  their service
• IPSs do not control the end-nodes
• ISPs bring knowledge of the application into the
  net, in middleboxes
• Providers want to stratify their users into
  classes
• Providers want to control usage by blocking
  certain applications
• Pressures for the network to move away from
  oblivious transport and start to be cognizant of
  that meaning
• New design goal should be make sure that this
  does not break the deployment of new applications
• Oblivious transport is the necessary building
  block

11
3. Specific project results

• FARA architectural model
• Role-based architecture
• Routing for user empowerment NIRA
• XCP congestion control general QoS framework
• Regions in the architecture
• Internet subscription systems

12
1. FARA architectural model

• The NewArch project
• Top-down architectural design by developing and
  prototyping a new architectural model (FARA)
  FARA03
• High-level model
• Complete architecture as an instantiation of the
  general model M-FARA M-FRAR03
• FARA
• Objective to remove the overloading of the IP
  address
• Provides some (minimal) security
• Makes mobility more difficult
• Separate location from identity
• Support general mobility
• Support wide range of routing/forwarding
  architectures (1)
• Support diverse naming schemes (2)
• Decouple routing/forwarding (1) from naming (2)

13
1. FARA architectural model

• Forwarding directive, Association, and Rendezvous
  Architecture (FARA) overview
• Abstractions
• Entity
• Association
• Mechanisms
• Forwarding Directives (FDs)
• Rendezvous
• Slot
• Modularized 2-level architecture
• Upper-level abstractions of entities and
  associations
• Lower-level communication substrate

14
1. FARA architectural model

• Entities
• Host-to-host communication ? Packet exchange
  between entities
• Process, thread, several processes, whole
  machine, cluster
• Entities communicate using association(s)
• Unit of mobility
• Associations
• The use of the (IP address, port number) pair as
  a definition of destination identity ?
  Association
• Logical communication link between two entities
• Sequence of data packets
• Shared communication state
• Association and Association ID (Aid)
• Local to entity
• Unique within entity, not necessarily within node
  or across nodes

15
1. FARA architectural model

• Forwarding Directive (FD)
• The use of the IP address for packet routing ?
  forwarding directive
• Tells the "network" how to deliver a packet to an
  entity/slot
• FD supports a range of forwarding mechanisms
• Might specify globally-unique address
• Might specify a path/explicit route
• May be independent of sender, or not
• Red line
• Separates forwarding (network) from entity
  (application)
• FD provides packet delivery (below the line)
• AID identifies association state (above the line)

16
1. FARA architectural model

• Slots
• Local operating system interface to an entity
• FD actually delivers data to a slot, and hence to
  the entity
• If entity moves to a different slot in the same
  end-system, the FD changes
• Slots are like dynamically-allocated ports
• System model

Source 4 - 20050907_FARA_jslee.ppt
ENTITY
AId1 AId2 AId3 AIdn
Association State
. . .
Communication Substrate
17
1. FARA architectural model

• Rendezvous
• Establishing an association generally requires a
  procedure/mechanism
• Discovery returns a pair (FD, RS)
• Initiation sends RS
• Rendezvous String (RS) contains anything the
  receiving entity needs to establish an
  association
• Examples TCP initialization, URL, Authentication

18
1. FARA architectural model

• Instantiation M-FARA
• M-FARA was designed to illustrate and exercise
  the mobility and addressing generality aspects of
  FARA
• Mechanisms for addressing, forwarding, FD
  management, and security
• To compute an FD, M-FARA assumes the existence of
  a distinguished core domain in the center of
  the topology
• To update FDs for mobility, M-FARA defines
  mobility agents
• A prototype of M-FARA
• Source code is available on http//www.isi.edu/new
  arch/fara.html
• Showed the ability to move between one realm and
  the other

19
2. Role-based architecture

• Under traditional network architecture
• Communication functions are organized into
  protocol layers RFC46
• Metadata that controls packet delivery is
  organized into protocol headers
• Trouble with layering
• Protocol layering has serious architectural
  limitations and problems
• Non-layered architecture Role-Based Architecture
  (RBA) RBA02

20
2. Role-based architecture

• Role
• Communication building block that performs some
  specific function relevant to forwarding or
  processing packets
• Role-based architecture
• Architectural solution to the problems with
  layering
• Design decision
• Structure of metadata in a packet header
  role-specific headers (RSHs)
• Ordering for the processing of metadata
• Encapsulation new organizational principle for
  the data and metadata in a packet
• Compromises with layering
• Architecture could be entirely role-based
• Apply RBA only above a particular layer,
  retaining layering below
• RBA processing would be performed only in end
  systems and middleboxes
• Apply RBA only as an application layer

21
3. Routing for user empowerment NIRA

• New Internet Routing Architecture (NIRA) Yang03
• User choice over domain-level routes
• Provider-rooted hierarchical addressing scheme
• Topology Information Propagation Protocol (TIPP)
• Propagates to users
• Address allocation information
• Topology information based on policy
  configurations
• Name-To-Route Resolution Service (NRRS)
• Tells a user
• Addresses
• Optionally the topology information of another
  user
• Compatible with IPv6 to facilitate deployment

22
4. XCP congestion control

• XCP (eXplicit Control Protocol) XCP02
• Internet congestion control that allows
  individual flows to obtain large end-to-end
  throughput
• Explicit Congestion Notification proposal (ECN)
• XCP routers inform the senders about the degree
  of congestion at the bottleneck, instead of the
  one-bit used by ECN,
• Per-flow congestion control state is carried in
  the data packets
• Decoupling of utilization control from fairness
  control
• XCP was extended to provide quality of service
  (QoS)

23
5. Regions in the architecture

• Region abstraction
• Scaling
• Heterogeneity in a variety of different domains
• Internet packet routing uses a two-tiered design
• Benefits of regions design
• Allows discovery and exchange of information
  about individual resources through the region
  abstraction
• Designs and builds an adaptation framework for
  regions

24
6. Internet subscription systems

• Mechanisms for notifying subscribers
• Existing approaches to Internet subscription
  systems
• Unicast systems clog network routers with
  numerous copies of the same message
• Single-identifier multicast cannot handle
  complex and evolving subscription categories
  efficiently
• Content-based multicast systems take a long time
  to process notification messages
• Alternative approach to Internet subscription
  systems (F3 Fast, Flexible Forwarding System)
• For large-scale, complex applications
• Distributed multicast mechanisms

25
4. New perspectives

• In confidence we trust
• Architecting a networked application
• Mobility

26
1. In confidence we trust

• In the current Internet
• global communication with local trust
• Transparent Internet among trusting users
• Not reasonable to expect trust among all parties
• Constraint rather than transparency is going to
  be needed
• To implement constraints
• Identity and the trust assertion for the identity
  must be a recognized part of the architecture
• Application architecture call for an end-node to
  choose to protect itself by moving some of its
  constraints externally

27
2. Architecting a networked application

• Application design techniques/goals
• Try to sort out the motivations of the parties
  that may participate in the application
• Consider the importance of user empowerment
• Use encryption as a tool to control what can be
  seen
• Design for the life cycle of an application
• Include full application entity information in
  the messages themselves
• Do not create a new form of spam in a new
  application
• Do not provide an unwitting tool for attack
  amplification
• Include a concept of identity

28
2. Architecting a networked application

• Possible changes to the network architecture
• New modes of routing to support applications
• Routing to an identity that is not an IP address,
  to protect the address and control the traffic to
  the destination
• Means to link application-level identity to
  packet-level identity
• A service that provides abstracted information
  about network topology and performance

29
3. Mobility

• Several types
• Entity Mobility entity moves to a new end-system
• Physical Mobility end-system moves to new
  network attachment point
• Virtual Mobility entity moves to a different
  slot (think port) in current end-system
• All require FD changes
• Mobile entities can be found using agents

30
References

• Blumen01 M. Blumenthal and D. Clark, Rethinking
  the Design of the Internet the End-to-End
  Argument vs. the Brave New World, Proc. ACM Trans
  Internet Technology, 1, 1, August 2001.
• CWSB02 D. Clark, J. Wroclawski, K. Sollins, and
  R. Braden, Tussle in Cyberspace Tomorrows
  Internet, ACM SIGCOMM 2002, August 2002.
• FARA03 D. Clark, R. Braden, A. Falk, and V.
  Pingali, FARA Reorganizing the Addressing
  Architecture. Proc. ACM SIGCOMM FDNA Workshop,
  Karlruhe, August 2003.
• M-FARA03 V. Pingali, A. Falk, T. Faber, and R.
  Braden. M-FARA Prototype Design Document. USC
  Information Sciences Institute. Available from
  http//www.isi.edu/newarch.
• RFC46, E. Meyer, ARPA Network Protocol Notes.
  RFC 46, Network Working Group, April 1970.
• RBA02 R. Braden, T. Faber, and M. Handley, From
  Protocol Stack to Protocol Heap Role-Based
  Architecture, Proc. Hotnets I, Princeton, NJ,
  October 2002.
• Yang03 X. Yang, NIRA A New Internet Routing
  Architecture,
• 2003 Workshop, Karlsruhe, August, 2003.
• XCP02