Personal tools
You are here: Home How to Help Universal Communications Technologies Directory

Directory Overview

by Nepal Studies last modified Feb 08, 2009 04:07 AM

Directory services at both application layer (X.500/LDAP) and network layer (eg DNS, ENUM, DDDS) are critical for UC, with especially complex considerations applying to use in a "sporadically connected" (disruption tolerant) environment.

Introduction

Directory and related registration services are used for both lookup and browsing by end users but also for provisioning and configuration management in network operations.

An initial podcasting network could enable publishers to create and describe "channels" and users to subscribe and unsubscribe  and browse for channels of interest using any sort of database as a catalogue.

But for evolution and scalability it is better for the catalogue to use an X.500 schema implemented with FOSS LDAP technology. This will greatly simplify authentication of end user and publisher actions (including a PKI public key certificate infrastructure that is the only plausible way to support such authentication in a "sporadically connected" environment.

Inevitably requirements for access control on operations by publishers and subscription options for end users will become more complex than initially envisioned and scalability will require the replication and distribution for which directory services are designed.

Later voicemail interconnection with the PSTN and general internet email will certainly require the use of the ENUM facilities of DNS and integration between DNS MX records for routing and LDAP directory entries for provisioning and configuration.

None of these complications are necessary for initial podcasting, nor are the even greater difficulties of integrating a payment system for subscriptions and usage since there are only a small number of institutional "customers" sponsoring larger numbers of publishers and subscribers. But adopting any other kind of catalog system temporarily can only be considered a "throw away" prototype - and very likely a much more difficult approach even for the simplest requirements than the well established facilities offered by directory service.

Registration

Registration of subscribers and administrators  (with access controls and authentication) will be essential. If thought through carefully this can be automated in conjunction with household level records, births, deaths, citizenship etc and cadastral and GIS databases.

Such facilities are useful generally in any developing economy and are necessary for non-residents wishing to establish communications with family or friends back home to browse for their registrations and subscribe to connecting with them. As a result of such a subscription being accepted by the other party, an address book entry can be established linking the two and a folder for exchanging messages created in a Message Store (eg a subfolder for "son" or "mother" within the folder structure of a FAT32 file system on flash card).

Only then can voice recordings placed within such a folder be recognized by the system as intended to be messages for transfer to the currently registered value of the corresponding email address or phone number with the appropriate subscription options (reply paid, retention period, urgency, delivery notification requested etc etc).

A registration system initially designed to handle prioritization of large numbers of podcast channels competing for space on end user file systems could evolve into one aspect of a full voicemail system by considering a communication association between two registered parties as a pair of corresponding podcast channels with one party as publisher and the other as subscriber for each. (However the billing system and reliable notifications will require much more as well).

Even if the design has to be substantially reworked rather than smoothly evolved, a directory based approach from the start will at least ensure familiarization with directory technology, schemas etc necessary for that rework.

DNS, ENUM and DDDS

The internet Domain Name Service is a global scalable replicated natural basis for lookup of internet addressing and email routing information. Among many other things it transparently enables your browser to request this web page by name (URL) instead of needing to know which box on which ISP server this web site is currently hosted.

Similar facilities within the PSTN connect telephone numbers to actual subscriber cables or cell phone handsets.

ENUM links the two so that a phone call can be made to a fixed permanent personal phone number independent of the teleco and country in the same way that web site URLs are independent of the web hosting ISP and country. It also provides connections with other directory information so that a phone call or fax can send a voicemail message or fax image to an internet email mailbox or vice versa.

The Dynamic Delegation Discovery System (DDDS) on which ENUM is based could also be very useful for defining universally unique permanent identifiers (UUPID) for archived documents (including audio).

Such location and time independent Universal Resource Indicators (URI) greatly simplify referencing of content and in particular enable reliable archiving/retrieval and operations on content without unecessary transmission of the entire content (eg to specify a list of items from other podcast channels to include in a particular podcast channel without duplicated transmission or storage).

This can be combined with the use of strong hashes on canonical forms of actual content (eg SHA1) to detect duplicates for efficient cache operation and to correlate multiple versions of essentially the same material despite variations in encoding or accompanying metadata.

Directory Architecture

http://www.x500standard.com/

http://sec.cs.kent.ac.uk/x500book/

Fedora Directory Server

The Fedora LDAP server looks like a suitable FOSS choice from the OpenLDAP family. It has extensive documentation, based on the Red Hat Enterprise Linux version and commercial support from Red Hat

would be available if necessary. See also the OpenLDAP and Microsoft Active Directory documentation and publications for additional information useful in understanding directory issues and ensuring compatability for with existing directory deployments by other organizations.

Failover

An important feature is that up to 4 master servers may be operated simultaneously (connected by high speed links). This ensures that changes can be made to directory entries even when a master server fails or has to be taken offline for routine maintenance. This feature is based on a controversial concept of multi-master replication. It is safer to point all directory writes to a single master with failover to each of the other masters (in strict priority sequence) only when the higher priority server is down. High speed connectivity is necessary to minimize the chance of inconsistent updates during failover and recovery. Some additional info on multi-master issues can be found here

. High availability reads as opposed to writes are available through normal directory replication. The advantage of the multi-master failover feature is simply that it works automatically without requiring complex configuration.

 

Document Actions
Log in


Forgot your password?
New user?