A Layered Naming Architecture for the Internet

1
A Layered Naming Architecture for the Internet

• by
• Hari Balakrishnan, Karthik Lakshminarayanan,
  Sylvia Ratnasamy, Scott Shenker, Ion Stoica,
  Michael Walfish
• Position paper, ACM SIGCOMM, Sep 2004
• Presented by
• Shobana Padmanabhan, Andrew Levine
• Sep 28, 2004
• CSE 7701

2
Outline

• Introduction
• Design Principles
• Architecture
• Flat names
• Related work
• Conclusion

Shobana
Andrew
3
Introduction

• Internet has been very successful but its
  architecture is far from ideal.. there have been
  many critiques and counter-proposals..
• Authors liberally borrow from these and
• distill some basic principles and
• synthesis these into a coherent architecture
• Some of the counter-proposal references are
• Preventing DoS with capabilities
• sender should first obtain permission to send in
  the form of tokens or capabilities
• Role-based Architecture, instead of layered
  architecture as layering violations are caused by
  
• middle boxes, multi-way interactions such as
  QoS, multicast, overlay routing, tunneling etc.,
• Programmable routers for end-to-end services,
• IPv6,

4
Internets architectural issues

• Lack of features
• End-to-end QoS, host control over routing,
  end-to-end multicast,
• Lack of protection and accountability
• Denial-of-service (DoS)
• Brittleness of Architecture

Source http//nms.lcs.mit.edu/talks/layerednames-
sigcomm04.ppt
5
Architectural brittleness

• Internet is widely used to access services/ data
  but they are tied to hosts http//www.nasdaq.com/t
  icker.htm
• But a service is more than a host and so problems
  with replication, migration, composition
• Hosts are tied to IP addresses
• Mobility and multi-homing pose problems
• Packets might require processing at
  intermediaries before reaching destination
• Middleboxes (NATs, firewalls, )
• Problems violation of IP semantics, making
  Internet application-specific,

Based on slides at http//nms.lcs.mit.edu/talks/la
yerednames-sigcomm04.ppt
6
Remedy

• Many proposals advocate large-scale architectural
  changes such as routers, end-hosts, services
• But the size of router infrastructure renders
  these changes almost impossible. Ex IPv6 changes
• References
• Decouple transport and networking layers to
  address mobility, multi-homing
• Nimrod, HIP
• Same decoupling to address problems from private
  addressing realms such as NATs
• UIP
• Source-directed indirection
• i3
• SID be flat
• SFR
• EID be flat
• HIP, UIP
• Scalable resolution of flat names
• DHTs

7
Naming

• Authors avoid issues inherently involving routers
  
• Full DoS protection, QoS, fine-grained control
  over routing
• Naming is more malleable and can solve some
  problems
• Layered naming provides layers of indirection and
  shielding
• Proposed changes are only to hosts and name
  resolution and hence more deployable (compared to
  changing routers)

8
Internet naming is host-centric

• Two global namespaces only DNS and IP addresses
• These namespaces are host-centric
• IP addresses network location of host
• DNS names domain of host
• Both closely tied to an underlying structure
• This imposes problems

Source http//nms.lcs.mit.edu/talks/layerednames-
sigcomm04.ppt
9
Problems with host-centric names

• Host-centric names are not direct and are
  impersistent
• If a name is based on mutable properties of the
  element its referring to, its not persistent
• Ex. If ARL web site moves from arl.wustl.edu to
  www.wustl.edu/arl, links to original URL will
  break
• Impersistent names constrain movement
• IP addresses are not stable host names
• DNS URLs are not stable data names
• Impersistent names constrain replication
• In this sense, data and services are second-class
  network citizens

10
Key Architectural Questions

1. Which entities should be named?
2. What should names look like?
3. What should names resolve to?

Source http//nms.lcs.mit.edu/talks/layerednames-
sigcomm04.ppt
11
1 Name services/data, separate from the hosts
Binding principle Names should bind protocols
onlyto relevant aspects of underlying structure
(to avoid limitations in flexibility
functionality)

• Service identifiers (SIDs) are host-independent
  service/ data names
• End-point identifiers (EIDs) are
  location-independent host names
• Protocols bind to names, and resolve them
• Apps should use SIDs as data handles
• Transport connections should bind to EIDs

Source http//nms.lcs.mit.edu/talks/layerednames-
sigcomm04.ppt
12
Key Architectural Questions

1. Which entities should be named?
2. What should names look like?
3. What should names resolve to?

Source http//nms.lcs.mit.edu/talks/layerednames-
sigcomm04.ppt
13
2 SIDs and EIDs should be Flat0axsdfkjl1234sad
fadsf234234sdfasf00df
Flat-name principle Persistent names will not
impose restrictions on the elements they refer to

• Flat names impose no structure on entities
• Structured names stable only if name structure
  matches natural structure of entities
• Can be resolved scalably using, e.g., DHTs
• Flat names can be used to name anything
• Once you have a large flat namespace, you never
  need other global handles

Source http//nms.lcs.mit.edu/talks/layerednames-
sigcomm04.ppt
14
Key Architectural Questions

1. Which entities should be named?
2. What should names look like?
3. What should names resolve to?

Source http//nms.lcs.mit.edu/talks/layerednames-
sigcomm04.ppt
15
3 Resolution and Delegation
Delegation principle A network entity should be
able to direct resolutions of its name not only
to its ownlocation, but also to chosen delegates

• Names usually resolve to location of entity
• SID would resolve to (EID, transport, port)
  triple
• EID would resolve to an IP address
• Packets might require processing at
  intermediaries before reaching destination
• Such processing today violates trust and
  layering
• Only element identified by packets IP
  destination should inspect higher layers
• Fix, by making delegation part of architecture

Based on slides at http//nms.lcs.mit.edu/talks/la
yerednames-sigcomm04.ppt
16
4 Sequence of destinations
Sequence principle Destinations, as specified by
sources and also resolution of SIDs and EIDs,
should be generalizable to sequences of
destinations

• Traditional IP routing
• Routing protocol chooses packets path through
  network
• Source routing protocols
• Sources can specify path
• In loose source routing, multiple points in the
  path
• Make this available at endpoint and service
  layers
• (i.e.) sources and receivers should be able to
  specify a sequence of destinations
• endpoints (EIDs) or services (SIDs)
• Combining this with Principle 3
• Endpoints and services should be able to have
  their names resolve to a sequence of IDs (IP
  addrs or EIDs)

17
Architecture - two new naming layers
User-level descriptors(e.g., email id, search
string)
App-specific search/lookup returns SID
App session
Resolves SID to gt1 (EID,transport,port) Opens
transport conns
Transport
Resolves EID to IP
IP
Source http//nms.lcs.mit.edu/talks/layerednames-
sigcomm04.ppt
18
Architecture SID resolution details

• If SID is a data item
• SID resolution layer would also receive an
  application directive
• Ex for a web page, pathname on the web server
  might also be returned
• Functionality in an application-independent
  library
• But since it would be under apps control and
  since some apps might want different behavior,
  lets look at what app does instead
• From the triple, app would communicate with the
  specified EID using the specified transport and
  port
• The transport protocol, now bound to EIDs, would
  use hosts EID as src and the one from triple as
  destination
• Multiple triples for simultaneous connections or
  back-up if a connection failed
• If all triples fail, app would reinvoke SID
  resolution layer to re-resolve SID for new triples

19
Architecture EID resolution details

• The transport protocol prepares packet(s) to send
  and passes them down to EID resolution layer
• Destination EID is resolved into IP address(es)
• Multiple IPs for multi-homed hosts
• Also, when a logical endpoint represented a
  collection of machines, each with its own IP
  address
• Hosts IP address becomes the src IP and the IP
  from the resolution layer is the destination IP
• If dest host is unreachable, EID layer uses other
  IP addresses, if any
• If all fail, it will re-resolve EID, in case the
  dest IP has changed

20
Architecture EIDs and SIDs in packets

• Since end-hosts are identified by EIDs, they go
  in the packet
• Since SIDs name services or data, they only go in
  each application data unit (ADU) communicated
  between sender and receiver
• Actual location in data streams would vary by app
  and what the SID is being used for
• Ex SID for SMTP server would be in email header
• SID for HTTP web proxy in HTTP header

21
Architecture not so brittle anymore

• SIDs overcome problems with DNS-based URLs
• EIDs provide natural solution to mobility and
  multi-homing
• If endpoint changes its IP address, EID
  resolution layer will re-resolve to find the new
  IP address
• gt continued operation when mobile hosts
• Smooth failover for multi-homed hosts
• Delegation gracefully replaces middleboxes with
  intermediaries

22
Backup slides
23
Domain Name System (DNS)

• DNS maps user-friendly names into router-friendly
  addresses
• Naming system, in general, maintains bindings of
  names values
• Name server is a specific implementation of a
  resolution mechanism that is on the network and
  that can be queried by sending a message
• Prior to DNS, a central table in hosts.txt was
  manually maintained and mailed out for deployment
  and hosts did a local look-up in their copy!
• DNS uses hierarchical name space. The table is
  partitioned into disjoint pieces and distributed
  (in name servers) throughout Internet.
• Logical
• Implementation

24
Domain Name System (DNS)

• Clients query name servers (for translating URLs,
  mail ids etc.) and if they dont have the info,
  they return a pointer to a server that the client
  should query next.
• Thus, DNS is a hierarchy of name servers rather
  than domains
• Resource records ltname, value, type, class,
  TTLgt
• Caching servers caches replies