A

AA

A

A

AA

A A

A A

A Pamela Zave

AT&T Laboratories—Research

Florham Park, New Jersey, USA

pamela@research.att.com

Telecommunications is networkingwith an emphasis on real-timecommunication among people.

FROM ARCHITECTURE TO REQUIREMENTS* :

A TELECOMMUNICATIONS*

SUCCESS STORY

This talk is about end-userrequirements only.

**

A

AA

A

A

AA

A A

A A

A

FEATURES

A FEATURE is an increment, often optional, of functionality.

A FEATURE-ORIENTED DESCRIPTION:

basedescrip-

tion

featuredescrip-

tion

featuredescrip-

tion

compositionoperator

FEATURE INTERACTIONS

A FEATURE INTERACTION is some way inwhich a feature modifies or influencesanother feature in defining overall system behavior.

THE FEATURE-

INTERACTION

PROBLEM

A feature-oriented descriptionis easy to change, especiallyto change by adding newfunctionality, . . .

. . . but feature-orienteddescription makes featureinteractions implicit, difficultto understand, and difficultto manage . . .

general-purposefeature

specificexcep-

tion

overrideoperator

feature interaction is an inevitable by-product of modularity in a feature-oriented description; it can be positive (desirable) or negative (undesirable)

forexample:

. . . which means preventingthe bad ones and enablingthe good ones.

A

AA

A

A

AA

A A

A A

A

TELECOMMUNICATION REQUIREMENTS OF TODAY

featuredescrip-

tion

featuredescrip-

tion

featuredescrip-

tion

REQUIREMENTS FOR NEW, INDIVIDUAL FEATURES ARE TAKEN SERIOUSLY, CANBE QUITE DETAILED

REQUIREMENTS FOR FEATURE INTERACTIONSARE HAPHAZARD, LOCAL, USUALLYSUPERFICIAL

GLOBAL REQUIREMENTS (PROPERTIES,GUARANTEES) ARE MISSING ALTOGETHERwhich is a major reason why requirements for feature interactions are poor

WHY NO GLOBALREQUIREMENTS?

the networks of todayhave been developingincrementally since the1960s

addresses, features, andother entities are highlyambiguous with respectto meaning and purpose

users have conflictinggoals

there is little separationof concerns betweenrequirements andimplementation

there are manyinteroperating networks

A

AA

A

A

AA

A A

A A

A

WHY ARCHITECTURE?

IN THE MID-1990s, NO PROGRESS ONTELECOMMUNICATIONREQUIREMENTS SEEMED POSSIBLE

HOWEVER, INADEQUATEREQUIREMENTS WERE NOT THE ONLYSOFTWARE PROBLEM RELATED TOFEATURES:

productivity of the software-development organization for a largetelephone switch:

1 line of code per meeting!

RECENTLY, MOST RESEARCH IN THISAREA HAS BEEN ARCHITECTURE-ORIENTED

agent architectures

stack architectures

Intelligent Network architectures

GOALS FOR TELECOMMUNICATIONARCHITECTURES:

make it easy to add, delete, andchange features

automatically eliminate many badfeature interactions, e.g., over-writing a variable

automatically enable many goodfeature interactions, e.g., forwarding invokes the features ofthe forwarded-to address

constrain feature interactions

modularity:

feature composition:

structured feature interaction:

generality:

encompass all telecommunicationservices, present and future

A

AA

A

A

AA

A A

A A

A

usage: a dynamically assembled graphof boxes and internal calls

DISTRIBUTED FEATURE COMPOSITION (DFC)

IB IBFB FB FB

box: a concurrent process, providingeither interface or feature functions

internal call: a featureless, point-to-point connection with a two-waysignaling channel and any number ofmedia channels

system boundary

routerDFC router: routesinternal calls to boxes

featuredata

persistent data:usually partitionedby feature

FEATURE INTERACTION (COMPONENT COORDINATION) MECHANISMS:

two-way signaling along pathsconsisting of internal calls and intra-box links

the routing algorithm allows forks andjoins, enables feature boxes to influencerouting without knowing about others

THE MODULARITY MECHANISM IS PIPES AND FILTERS:

each box has transparency, autonomy,and context-independence

A

AA

A

A

AA

A A

A A

A

DFC WORKS!

HISTORY

the concept of DFC was originatedby Michael Jackson and PamelaZave 6 years ago

work began on an IPimplementation of DFC 4 years ago

1 year ago we began building voice-over-IP services for customerswithin AT&T

we are a team of 8 people, plusadditional contract programmers

ACCOMPLISHMENTS

in one year, we built an astoundingvariety of features (there was a lotof component and code re-use fromearlier demos)

within AT&T, we have a reputation for making work what others can't make work

at a recent trade show, we had the coolest demo

despite the penalty we pay formodularity, our performance iscomparable to other voice-over-IP services, is improving steadily

we are at the forefront of standards work related to feature interaction in voice-over-IP

we have had no trouble integrating Web services with our voice-over-IP services

FORMAL MODEL: REQUEST CHAINS

trg=t2

trg=t2

trg=t2

src=s1

src=s2

src=s2

src=s2

src=s2trg=t1

trg=t1

inter-face

module

inter-face

module

sourcefeaturemodule

sourcefeaturemodule

targetfeaturemodule

targetfeaturemodule

s1

s1

s2

t2

t1

t1

all feature modulesare optional

the formal model concernsthe application of features,not module identity (two modulescould be parts of a whole, there couldbe many instances of a module)

a request can set up a persistent signaling channel;all signals related to the request travel on this channel;media is controlled logically (but not physically) by these signals

any part of a signaling channel can be torn down at any time

A

AA

A

A

AA

A A

A A

A

SOURCEREGION

a feature module performsaddress translation when itcontinues a request chain, changing its source or targetaddress in the continuation

A TELECOMMUNICATION NETWORK CONNECTS DEVICES BY CREATINGREQUEST CHAINS

TARGETREGION

A

AA

A

A

AA

A A

A A

A

FORMAL MODEL: ROUTING ALGORITHM

mode=src

mode=src

mode=srcsrc=s

src=s

src=s

mode=trg

mode=trg

mode=trgtrg=t

trg=t

mode=end

src=s'

trg=t'

srcunchanged

src changed

trgunchanged

trg changed

CONTINUINGMODULE

INITIATINGMODULE

module

s

if (mode==src) then if (src has SFM m) then route to m else {mode:=trg; restart routing}

if (mode==trg) then if (trg has TFM m) then route to m else {mode:= end; restart routing}

else (mode==end) if (trg has IM m) then route to m else route to error module

NETWORK ROUTER

FM

FM

FM

FM

FM

IM

IM

chain is initiated by a feature module

two continuationsof chain

chain ends atfeature module

This is a simplifcation of DFC routing, to make the work more widely applicable.

A

AA

A

A

AA

A A

A A

A

ADDRESS-TRANSLATION FUNCTIONS

SOURCEREGION

TARGETREGION

src=c1 src=a1 src=a1

trg=a2 trg=c2

sourcefeaturemodule

sourcefeaturemodule

targetfeaturemodule

c1 a1 a2

WHAT FUNCTIONS ARE BEING PERFORMED?

WHY ARE THEY BEINGPERFORMED?

ON WHOSE BEHALF ARETHEY BEING PERFORMED?

if a1 and a2identify:

then the source translation is:

and the targettranslation is:

groups affiliation: affiliate the callerwith the group

positioning: position the mobile entity at the location ofthe calling device

assumption: assume the rolefor the caller

representation: find a representative of the group

location: find the location of themobile entity

resolution: translate the role tothe entity playing the role

mobileentities

roles

...

A

AA

A

A

AA

A A

A A

A

ADDRESSES MUST BE CATEGORIZEDACCORDING TO WHAT THEY IDENTIFYOR REPRESENT

ADDRESS CATEGORIES MUST BEPARTIALLY ORDERED BY"ABSTRACTION"

ORGANIZATION OF ADDRESSES

EACH ADDRESS HAS ONE OR MOREOWNERS

THE PRIMARY PURPOSE OF ADDRESSTRANSLATION IS TO CHANGE LEVELOF ABSTRACTION

an owner has rights and responsibilitiesan owner knows the authenticationsecret

for example:devicepersongrouprole

by definition:a group is more abstract than aperson representing the groupa person is more abstract than adevice where he is locateda public role is more abstract thana private identity

in the source region, source addressesbecome successively more abstractin the target region, target addressesbecome successively more concrete

and combinations thereof

A

AA

A

A

AA

A A

A A

A

IM

INTERACTION: IDENTIFICATION

PEOPLE AND FEATURE MODULES USEADDRESSES TO IDENTIFY THEPARTIES WITH WHOM THEY ARECOMMUNICATING

A FEATURE THAT PERFORMSADDRESS TRANSLATION INTERACTSWITH OTHER FEATURES BYAFFECTING THE IDENTIFICATIONINFORMATION THEY RECEIVE

PRIVACY AUTHENTICITY

A person should be able to conceala more private address that heowns behind a more public addressthat he owns.

A person should not be able topose as an owner of an address hedoes not own.

These principles balance conflicting goals:

IMSFM SFM TFM TFMd1 d1

d1

r1

r1

r2

r2

d2

d2

d2

src=d1

src=r1

trg=r2

trg=d2

trg=d2

authenticationdialogues

r1 hides d1as source

d1 is notobservabledownstream

d2 is notobservableupstream

r2 hides d2as target

A

AA

A

A

AA

A A

A A

A

REPRODUCIBILITY

A feature module or personshould be able to call the sameentity twice and be connected tothe same representative of thatentity.

INTERACTION: CONTACT

PEOPLE AND FEATURE MODULES USEADDRESSES TO CONTACT THEPARTIES WITH WHOM THEY WISH TOCOMMUNICATE

A FEATURE THAT PERFORMSADDRESS TRANSLATION INTERACTSWITH OTHER FEATURES BYAFFECTING THE CONTACTINFORMATION THEY RECEIVE

REVERSIBILITY

A target feature module or callee should be able to call the sourceaddress of a request chain and and thereby target the entity thatinitiated it.

src=s src=s src=sTFM TFM IM

feature modules in thetarget region must notchange the source address

conflicts withmobility and

the freedom ofrepresentation functions

this is the most abstractsource address, not thecaller device

A

AA

A

A

AA

A A

A A

A

INTERACTION: INVOCATION

THE ADDRESSES IN A REQUESTCHAIN DETERMINE WHICH FEATUREMODULES ARE IN THE CHAIN

A FEATURE THAT PERFORMSADDRESS TRANSLATION INTERACTSWITH OTHER FEATURES BYAFFECTING WHICH FEATURES AREINVOKED

BOUNDEDNESS

The numbers of source andtarget feature modules in a chainshould be bounded.

MONOTONICITY

In a region, the feature modulesof more concrete addressesshould be closer to the outer endof the region than featuremodules of more abstractaddresses.leads

to

SOURCEREGION

TARGETREGION

concrete concreteabstract abstract

each feature module knows where themore abstract and more concretefeatures are

features can be prioritized andcoordinated (e.g., by token passing)without knowledge of other features

A

AA

A

A

AA

A A

A A

A

IDEAL ADDRESS TRANSLATION . . .

. . . IS A SET OF CONSTRAINTS . . .

. . . THAT GUARANTEE PROPERTIES . . .

. . . BASED ON THE PRINCIPLES . . .

. . . IN A WAY THAT IS . . .

THE CONSTRAINTS OF IDEAL ADDRESS TRANSLATION ARE GLOBALCOORDINATING CONVENTIONS FOR TELECOMMUNICATION FEATURES

Constraint 1: A targetfeature module in arequest chain does not change the sourceaddress of the chain.

Constraint 2s: If a sourcefeature module in a request chain translates the sourceaddress, the new sourceaddress is more abstractthan the old one.

Constraint 2t: If a targetfeature module in a requestchain translates the targetaddress, the new targetaddress is more concretethan the old one.

Source Privacy: If s1 is a sourceaddress in a request chain, and if s1 hasa source feature module that changesthe source address to s2 in this chain,then s1 is not observable as a sourcedownstream of this module.

Target Privacy: If t2 is a targetaddress in a request chain, and if t2 hasa target feature module that changesthe target address to t1 in this chain,then t1 is not observable as a targetupstream of this module.

privacyauthenticity

reversibility boundednessmonotonicity

modular: modules do not cooperateexplicitly with other modules, or knowwhich modules are present

extensible: adding (or deleting) featuresdoes not require changing existing (orremaining) features

A

AA

A

A

AA

A A

A A

A

RELATION OF IDEAL ADDRESS TRANSLATION TO

REQUIREMENTS ENGINEERING

THE PRINCIPLES OF PRIVACY,AUTHENTICITY, REVERSIBILITY, ANDBOUNDEDNESS ARE"PROTO-REQUIREMENTS"

Privacy: A person should be able toconceal a more private address that heowns behind a more public addressthat he owns.

vague, informal

THE ARCHITECTURE IS FORMALLYDEFINED, STRESSES MODULARITYAND EXTENSIBILITY

modules can be added easily

each module iscontext-independent

THE PROPERTIES ARE PRECISE ANDFORMAL; THEY SATISFY THE PRINCIPLESIN A WAY THAT IS EASY TO UNDERSTAND,MODULAR, AND EXTENSIBLE

Source Privacy: If s1 is a source addressin a request chain, and if s1 has a sourcefeature module that changes the sourceaddress to s2 in this chain, then s1 is notobservable as a source downstream ofthis module.

formalized interms of request chains

we know whatconcealment is(observable bymodule = observable byowner of module's address)

there are no truerequirements,satisfiable bysystems with anyarchitecture

this is not the onlyway that the goalscould be achieved

without the clarityprovided by thearchitecture, theprinciples wouldnot have beendiscovered yet

A

AA

A

A

AA

A A

A A

A

RELATION OF IDEAL ADDRESS TRANSLATION TO

THE REAL WORLD OF NETWORKING

THERE ARE MANY REASONS WHY THEREAL WORLD MIGHT NOT CONFORMTO THE IDEAL

inadequate infrastructure

legacy of noncompliant features oraddress mappings

interoperation with untrustednetworks

unwise optimizations

one legitimate case in whicha constraint is (deliberately)too strong

THERE ARE MANY WAYS TO COPEWITH THESE EXCEPTIONS

DESPITE THE EXCEPTIONS, IDEAL ADDRESSTRANSLATION HAS PROVEN VERY USEFULBECAUSE . . .

refine or adapt the reasoning

trace which properties do and donot hold

enforce the constraints in asubnetwork only

. . . even a subnetwork can have very complex feature interactions

. . . principles, constraints, properties, and reasoning are all models that we approximate as closely as possible

. . . it helps us understand infrastructure requirements

A

AA

A

A

AA

A A

A A

A

switchingor conferencing

shared

augmentation

reused replacement

INSIGHT ACCELERATES INSIGHT

THIS IS PART OF A DFC USAGE—NOW IT SEEMS POSSIBLE TO ANALYZE THIS!

including:

extend ideal address translation tounrestricted usages like this one

strengthen the properties, becausethe model describes more of whatis going on

e.g., prove that the current far-partyaddress correctly identifies who you are talking to

(before, the model only told you abouthow the usage was constructed byrouting)

A

AA

A

A

AA

A A

A A

A

CONCLUSIONS

TELECOMMUNICATIONREQUIREMENTS USED TO SEEMINTRACTABLE, AND NOW THERE IS AFEELING OF REAL PROGRESS

OBSERVATIONS ABOUT WHAT WORKS

sometimes architecture mustprecede requirements

I made most of this progress after Istopped trying to accommodate alllegacy systems

above all, be domain-specific

NOW:

http://www.research.att.com/info/pamela

AFTER 15 June 2003, including referenceson address translation:

http://www.research.att.com/projects/dfc