FROM ARCHITECTURE TO REQUIREMENTS* : A TELECOMMUNICATIONS* SUCCESS STORY Pamela Zave AT&T Laboratories—Research Florham Park, New Jersey, USA pamela@research.att.com * * This talk is about end-user Telecommunications is networking requirements only. with an emphasis on real-time communication among people.
FEATURES THE FEATURE- INTERACTION A FEATURE is an increment, often optional, of functionality. PROBLEM A FEATURE-ORIENTED DESCRIPTION: A feature-oriented description is easy to change, especially base feature feature to change by adding new descrip- descrip- descrip- functionality, . . . tion tion tion . . . but feature-oriented composition description makes feature operator interactions implicit, difficult to understand, and difficult FEATURE INTERACTIONS to manage . . . . . . which means preventing A FEATURE INTERACTION is some way in the bad ones and enabling which a feature modifies or influences the good ones. another feature in defining overall system behavior. specific general- for feature interaction is excep- purpose example: an inevitable by- tion feature product of modularity in a feature-oriented override description; it can be operator positive (desirable) or negative (undesirable)
TELECOMMUNICATION REQUIREMENTS OF TODAY REQUIREMENTS FOR NEW, INDIVIDUAL WHY NO GLOBAL FEATURES ARE TAKEN SERIOUSLY, CAN REQUIREMENTS? BE QUITE DETAILED the networks of today have been developing incrementally since the 1960s feature feature feature addresses, features, and descrip- descrip- descrip- other entities are highly tion tion tion ambiguous with respect to meaning and purpose users have conflicting goals REQUIREMENTS FOR FEATURE INTERACTIONS there is little separation ARE HAPHAZARD, LOCAL, USUALLY of concerns between SUPERFICIAL requirements and implementation there are many interoperating networks GLOBAL REQUIREMENTS (PROPERTIES, GUARANTEES) ARE MISSING ALTOGETHER which is a major reason why requirements for feature interactions are poor
WHY ARCHITECTURE? IN THE MID-1990s, NO PROGRESS ON GOALS FOR TELECOMMUNICATION TELECOMMUNICATION ARCHITECTURES: REQUIREMENTS SEEMED POSSIBLE modularity: HOWEVER, INADEQUATE make it easy to add, delete, and REQUIREMENTS WERE NOT THE ONLY change features SOFTWARE PROBLEM RELATED TO FEATURES: feature composition: productivity of the software- automatically eliminate many bad development organization for a large feature interactions, e.g., over- telephone switch: writing a variable 1 line of code per meeting! automatically enable many good feature interactions, e.g., forwarding invokes the features of RECENTLY, MOST RESEARCH IN THIS the forwarded-to address AREA HAS BEEN ARCHITECTURE- ORIENTED structured feature interaction: agent architectures constrain feature interactions stack architectures generality: Intelligent Network architectures encompass all telecommunication services, present and future
DISTRIBUTED FEATURE COMPOSITION (DFC) usage: a dynamically assembled graph internal call: a featureless, point-to- of boxes and internal calls point connection with a two-way signaling channel and any number of box: a concurrent process, providing media channels either interface or feature functions system boundary FB IB IB FB FB DFC router: routes persistent data: feature internal calls to usually partitioned router data boxes by feature FEATURE INTERACTION (COMPONENT COORDINATION) MECHANISMS: two-way signaling along paths the routing algorithm allows forks and consisting of internal calls and intra- joins, enables feature boxes to influence box links routing without knowing about others THE MODULARITY MECHANISM IS PIPES AND FILTERS: each box has transparency, autonomy, and context-independence
DFC WORKS! HISTORY ACCOMPLISHMENTS the concept of DFC was originated in one year, we built an astounding by Michael Jackson and Pamela variety of features (there was a lot Zave 6 years ago of component and code re-use from earlier demos) work began on an IP implementation of DFC 4 years ago within AT&T, we have a reputation for making work what others can't 1 year ago we began building voice- make work over-IP services for customers within AT&T at a recent trade show, we had the coolest demo we are a team of 8 people, plus additional contract programmers despite the penalty we pay for modularity, our performance is comparable 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 A TELECOMMUNICATION NETWORK CONNECTS DEVICES BY CREATING REQUEST CHAINS TARGET SOURCE REGION REGION src=s1 inter- face trg=t2 a feature module performs module src=s2 address translation when it s1 source continues a request chain, feature trg=t2 changing its source or target module all feature src=s2 address in the continuation s1 source modules feature are optional trg=t2 module src=s2 s2 target feature the formal model concerns trg=t1 module the application of features, src=s2 t2 target not module identity (two modules feature could be parts of a whole, there could trg=t1 module be many instances of a module) t1 inter- face module a request can set up a persistent signaling channel; t1 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
FORMAL MODEL: ROUTING ALGORITHM INITIATING NETWORK ROUTER MODULE if (mode==src) then if (src has SFM m) then route to m module mode=src else {mode:=trg; restart routing} s src=s if (mode==trg) then if (trg has TFM m) then route to m else {mode:= end; restart routing} CONTINUING else (mode==end) MODULE if (trg has IM m) then route to m else route to error module mode=trg src unchanged src=s mode=src chain is initiated by a feature module FM src=s mode=src src changed src=s' two continuations mode=end FM IM trg FM of chain unchanged trg=t mode=trg IM FM trg=t mode=trg chain ends at trg changed feature module FM trg=t' This is a simplifcation of DFC routing, to make the work more widely applicable.
ADDRESS-TRANSLATION FUNCTIONS WHAT FUNCTIONS ARE ON WHOSE BEHALF ARE WHY ARE THEY BEING BEING PERFORMED? THEY BEING PERFORMED? PERFORMED? SOURCE TARGET REGION REGION source source target ... src=c1 src=a1 src=a1 feature feature feature module module module trg=a2 trg=c2 c1 a1 a2 and the target if a1 and a2 then the source translation is: identify: translation is: affiliation: affiliate the caller representation: find a groups with the group representative of the group positioning: position the location: find the location of the mobile mobile entity at the location of mobile entity entities the calling device assumption: assume the role resolution: translate the role to roles for the caller the entity playing the role
ORGANIZATION OF ADDRESSES EACH ADDRESS HAS ONE OR MORE OWNERS an owner has rights and responsibilities an owner knows the authentication secret ADDRESSES MUST BE CATEGORIZED ADDRESS CATEGORIES MUST BE ACCORDING TO WHAT THEY IDENTIFY PARTIALLY ORDERED BY OR REPRESENT "ABSTRACTION" for example: by definition: a group is more abstract than a device person representing the group person a person is more abstract than a group device where he is located role and combinations thereof a public role is more abstract than a private identity THE PRIMARY PURPOSE OF ADDRESS TRANSLATION IS TO CHANGE LEVEL OF ABSTRACTION in the source region, source addresses become successively more abstract in the target region, target addresses become successively more concrete
INTERACTION: IDENTIFICATION PEOPLE AND FEATURE MODULES USE A FEATURE THAT PERFORMS ADDRESSES TO IDENTIFY THE ADDRESS TRANSLATION INTERACTS PARTIES WITH WHOM THEY ARE WITH OTHER FEATURES BY COMMUNICATING AFFECTING THE IDENTIFICATION INFORMATION THEY RECEIVE These principles balance conflicting goals: AUTHENTICITY PRIVACY A person should be able to conceal A person should not be able to a more private address that he pose as an owner of an address he owns behind a more public address does not own. that he owns. d2 is not r1 hides d1 d1 is not r2 hides d2 observable as source observable as target upstream downstream src src =d1 =r1 SFM SFM TFM TFM IM IM d1 d1 r2 trg d2 d2 r1 trg trg =d2 =r2 =d2 d1 d2 authentication r1 r2 dialogues
INTERACTION: CONTACT PEOPLE AND FEATURE MODULES USE A FEATURE THAT PERFORMS ADDRESSES TO CONTACT THE ADDRESS TRANSLATION INTERACTS PARTIES WITH WHOM THEY WISH TO WITH OTHER FEATURES BY COMMUNICATE AFFECTING THE CONTACT INFORMATION THEY RECEIVE REVERSIBILITY A target feature module or callee should be able to call the source REPRODUCIBILITY address of a request chain and and thereby target the entity that A feature module or person initiated it. should be able to call the same entity twice and be connected to this is the most abstract the same representative of that source address, not the entity. caller device feature modules in the conflicts with target region must not mobility and change the source address the freedom of representation functions src=s src=s src=s TFM TFM IM
Recommend
More recommend
