Transcript Internet Evolution & Governance

The Digital Object Architecture
A presentation at
Louisiana State University
Baton Rouge, Louisiana
August 26, 2005
Robert E. Kahn
Corporation for National Research Initiatives
Reston, Virginia
Selected Major Network
Issues
How to get affordable broadband access
to homes, businesses, government, etc.
 How to add more dimensionality to the
mobile wireless experience
 How to take advantage of many
devices/appliances being on the Internet
 Protecting critical elements (including
infrastructure elements such as DNS)
 Stifling SPAM; detecting and fighting
Viruses

Selected Major Issues (con’t)
Identity Management (w/o certificates)
 Trust in the security mechanisms
 Managing Privacy
 How to enable more widespread sharing
of important information on the net
 Trusting your information to the Net
 Managing your information on the Net over
very long periods of time

Infrastructure Development

What is so hard about it?



Getting Buy in




Making it scalable over platforms, size and time
Achieving Critical Mass
Pleasing many essential participants
Displacing prior capabilities
Structuring matters to deal with concerns about empire
building
It’s a lot easier to create brand new capabilities
than to affect existing means of operation
Infrastructure Creation is a
Subtractive Process
Infrastructure reduces a common, shared
capability to its basic and essential attributes
 These attributes are not always recognized
or understood up front
 Upon further scrutiny, capabilities are usually
deleted from a well-conceived architecture
over time
 Consensus develops when no more can be
removed without disabling the infrastructure

What is the Problem?




Managing information in the Net over very long
periods of time – e.g. centuries or more
Dealing with very large amounts of information in
the Net over time
When information, its location(s) and even the
underlying systems may change dramatically
over time
Respecting and protecting rights, interests and
value
A Meta-level Architecture
Allows for arbitrary types of information
systems
 Allows for dynamic formatting and data
typing
 Can accommodate interoperability
between multiple different information
systems
 Allows metadata schema to be identified
and typed

Digital Object Architecture:
Motivation

To reformulate the Internet architecture around the
notion of uniquely identifiable data structures

Enabling existing and new types of information to be
reliably managed and accessed in the Internet
environment over long periods of time

Providing mechanisms to stimulate innovation, the
creation of dynamic new forms of expression and to
manifest older forms

While supporting intellectual property protection, finegrained access control, and enable well-formed
business practices to emerge
Objective of the Framework
Heterogeneous
Networks
Networks
Internet objective
Best-effort Packet Delivery
Information
Information
Systems
Systems
Seamless Interoperability
Organizing Heterogeneous Systems
Digital Object Architecture

Technical Components

Digital Objects (DOs)




Resolution of Unique Identifiers



Maps an identifier into “state information” about the DO
Handle System is a general purpose resolution system
Repositories from which DOs may be accessed


Structured data, independent of the platform on which it was
created
Consisting of “elements” of the form <type,value>
One of which is its unique, persistent identifier
And into which they may be deposited
Metadata Registries



Repositories that contain general information about DOs
Supports multiple metadata schemes
Can map queries into unique DO specifications (via handles)
What is a Digital Object


Defined data structure, machine independent
Consisting of a set of elements



Identifiers are known as “Handles”





Each of the form <type,value>
One of which is the unique identifier
Format is “prefix/suffix”
Prefix is unique to a naming authority
Suffix can be any string of bits assigned by that authority
Data structure can be parsed; types can be resolved
within the architecture
Associated properties record and transaction record
containing metadata and usage information
Interoperability & Federated
Repositories
Create a cohesive interoperable collection
of repository-based systems



Initially, perhaps, around a core set of
projects, content, applications and/or
organizations as in ADL
Demonstrate interoperability between
different repository collections
Develop procedures to insure continued
accessibility to key archival information
Repository Notion
Logical External Interface
RAP
Repository
Access Protocol
Any Hardware & Software
Configuration
Digital Object Repository
• Provides distributed Digital Object storage.
Repository
• May itself be a Digital Object.
• Provides a dynamic acquisition and
execution mechanism for the mobile code that
implements the content type operations.
• Exclusively accessed using the Repository
Access Protocol (RAP).
Deposit
Disseminate
Client
Nesting of Repository
Functionality
Aggregation &
De-aggregation
Content
Core Interface must be present at each level
Other levels could be separately defined later
Structure
Core
Repositories & Digital Objects
Each Digital
Object has its
own unique &
persistent ID
Content Providers
want to assign Ids
IPv6
Objects may be
Replicated in
Multiple Repositories
REPOSITORY
Could be upwards
of trillions of DOs
per Repository
Handle System

Distributed Identifier Service on the Internet

First General Purpose Resolution system

Can be used to locate repositories that contain digital objects
given their handles - and more!

Other indirect references
 Public Keys, Authentication information for Dos

Accommodates interoperability between many different information
systems; for example


DNS was demonstrated on the Handle System in preparation for Y2K
Can support ENUM, RFID, and more
Attributes of the Handle System
The basic Architecture of the Handle
System is flat, scaleable, and extensible
 Logically central, but physically
decentralized
 Supports Local Handle Services, if desired
 Handle resolutions return entire “Handle
Records” or portions thereof
 Handle Records are also

digital objects
 signed by the servers
 doubly certificated by the system

Resolution Mechanism
Handle
Handle
Record
Multiple Sites
Multiple Servers
Handle System
<www.handle.net>
•
•
•
•
System is non –nodal
Scaleable & Distributed
Supports global (and local) resolution
With backup for reliability, mirroring for efficiency
Type Resolution
Types are resolvable in the Handle
System
 Types may be created dynamically
 Types may be locally named, mapped into
bit strings without semantics
 Primary prefix zero “0” is used for system
identifiers
 0.type/<type> is the system handle for
type
 Other handles may cross reference this

Handle Format
2304.40/1234
Prefix
Authority
Item ID
(any format)
Prefix
Suffix
In use, a Handle is an opaque string.
Other examples of
Handles
2304/general info
2304/1
2304. HQ/staff
2304.1/memo123
2304.22.Pub/2004
Direct Access and Proxies
Direct
Access
Indirect
Access
One or more
Proxy Servers
Redirection of Handle Requests
General Registry of all
Naming Authorities
Direct
Access
Redirection
Information
One or more
Local Handle
Services
Literary Music Video Financial Grid Enum RFID
“SimpleLookup URL IPaddresses “Unfederated Databases”
Digital Object Overview
Information
Unique Identifier
Handle
Content Type(s)
Disseminations
Digital Object
Access
Requests
Digital Object Overview
Hamlet
Hamlet
It’s a Book
Get Page(2)
Digital Object Overview
Hamlet
Hamlet
Content Type
Operations
Data
Element
Content Type
Operations
Data
Element
•Digital objects are uniquely identified in a given identifier space.
•Data elements reference sequences of typed data.
•A Digital Object can have zero or more Content Types to reflect
intended uses by its creator.
•Content Type Operations are accessible as DOs
The Digital Object Identifier
(DOI®)
Used by the International DOI
Foundation (IDF) to reference highquality materials of publishers (and
other owners of IP)
 Major Commercial User of the Handle
System at present with approximately
12 Million handles
 Usage growing at about 4 Million per
year
 DNS domain names, by comparison,

Setting up a Local Handle
Service...

Download the software from http://www.handle.net

Follow the instructions in the installation script.

Send your “site bundle”, containing the IP address of
your server and your administrator information, to the
Global Handle Registry® (GHR) administrator

Site is under re-development to accommodate
widespread use via automated means

Experimental Repository software also available online
Managing Rights & Interests





Not just about copyright
Terms and Conditions (T&Cs) for use may be
contained within each DO; also information
about intrinsic value, such as monetary value
T&Cs are intended to indicate clearly what one
can and/or cannot do with a given DO, where
such clarity is intended by the owner of the DO
Not an enforcement means, although it may be
used by an enforcement system
Mobile programs that are Digital Objects may
apply such terms to themselves and to any
digital objects they contain
Handle-DNS Integration

Developing Environment


C/C++, Linux/Windows
Additional Modules
DNS Interface integrated with handle server
 Cache/Preload Module
 Database Connection Pools
 C-Version Handle-DNS Admin Toolkit


Performance Improvements
Exceptional Processing
 Memory Leak Protection
 Thread Pool Management

Design &
Implementation

Simple Handle Server Workflow (C-Version)
Handle Server
Handle Requests
Thread Pool
Message
Listener
Processor
Storage
Management
Interface
Client
Database
Connection Pool
DB
External Protocol Converter
Latency
DNS Protocol
53
Converter
Handle Protocol 8000
Handle
Process
2641
Module
Handle Server
DNS Protocol
Plug & Play Interfaces

Integrate DNS Interface with Handle Server
DNS Protocol
DNS Message
Handle Protocol
8000
2641
Processor
Handle
Message
Processor
Handle Server
53
Cache & Storage Management
Preload Handle Records
from Database into RAM




User Transparent



Storage
Management
Interface
Reduce Database Access
Times
Improve Throughput of
Handle Server
Storage Management
API
RAM or Database
Combination of RAM and
Database
Multiple Database
Interfaces

Mysql, PostgreSQL, etc.
Delete

Operations
Modify
Preload (Cache)
Module
Create

RAM
Periodic
Update
Data Base
Storage Management API
Benchmark
UDP Interface for DNS Protocol
 Compared to BIND 9.3.0

Handle-DNS VS Bind
Handle-DNS
Bind
16000
Responses per Second
14000
12000
10000
8000
6000
4000
2000
0
2 8 14 20 26 32 38 44 50 56 62 68 74 80 86 92 98
3
Number of Client Requests(10 )
Business Potential
Selling infrastructure technology
 Providing identification, management and
Metadata services
 Enabling third-party value-added
capabilities
 Helping organizations manage their own
information better & offer new types of
services
 Stimulating access to “surface information”
and “embedded information” with
appropriate access controls and conditions
of use

Conclusions






Managing Digital Objects for long-term access is a
key challenge
Initial Technology Components are available;
Industry is expected to generate more over time
Third-party value-added providers in the private
sector will ultimately shape the long-term evolution
Interoperability and reliable information access is a
critical objective
A diversity of applications (with user-friendly
interfaces) need to be developed & deployed
Application Projects have a central role to play in
demonstrating the technology and using it effectively