a path towards strong architectural foundation for the internet...

COPYRIGHT © 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

A path towards strong architectural foundation for the Internet designDimitri Papadimitriou, Bernard Sales

Alcatel-Lucent, Bell Labs

September 2011

Architecture state of affairs

• Architectural aspects have often been overlooked when designing communication networks

- Applies to the Internet which remains structured along relatively weak foundations in spite of its ubiquitous deployment

- Results in weak understanding of its actual behaviour

• The OSI track- One of the most advanced internationally accepted architecture for communication networks - Standardised in the 80's jointly by CCITT (former name of ITU-T), ISO and IEC

- Protocols derived from the OSI Reference Model (RM) did not reach its initial expectation in terms of deployment

2


- Protocols derived from the OSI Reference Model (RM) did not reach its initial expectation in terms of deployment

• The TCP/IP track (Internet)- Driven since its inception by a small set of design principles rather than derived from a formal architecture

- The TCP/IP model and its associated protocols are used ubiquitously as the technologies of the worldwide Internet that interconnects billion of people and smart objects

Thus, the naive (or provocative?) question: is architectural work a necessary step for the development of the Future Internet?

Design principles or architectural work?

• TCP/IP: weak architectural model with strong reliance on commonly shared design principles

- Architecture evolution is carried out by means of incremental and reactive additions of features to existing protocols (only possible evolution)

- Replacement and/or addition of architectural components implies functional or performance limitations without changing the properties of the architecture

- Now reaching its limits in terms of functionality and maintenance leading to serious and costly operational problems

• OSI: architectural model without design principle

3


• OSI: architectural model without design principle

- OSI RM was specified to abstractly represent existing protocols (X.25, Videotext)

- Design principles regarding the OSI RM were loosely defined

- Resulted in protocol misconceptions and numerous options, i.e. an interop nightmare

- Culminates with the introduction of two incompatible network layers, the so-called “CO/CL” debate, i.e. even a more challenging interop nightmare

Both design principles and strong architectural foundations are necessary

Modeling the world as functions, data and states

• ICT architecture-oriented projects combine three complementary pillars

- Function, i.e. what functions the system does perform

- How values are related to each others and exhibits the functional dependencies.

- Objects/information, i.e. what data the system produce, consumes and manipulates

- Defining what is the organisation of the data, including their relation and their interaction

- States i.e. what is the system behaviour and what are the stimuli that change this behaviour

4


this behaviour

- Sequence of operations in response to external (and internal) stimuli

• Each “domain” of application will exhibit these three pillars

- From e.g. vending machine to avionic systems, railway signaling system, large business and commercial systems, etc

More and more sophisticated service offering over the Future Internet is emphasizing the need for architecture specifications describing three

complementary viewpoints, namely function, data and states

• Specification of these elements is referred to as

- The functional model architecture,

- The information model architecture and

Architecture Definition

1:n 1:1

1.1

Function F1Flow_1

1.2

Function F2

Architecture: set of functions, objects/ information, and states (referred to as "elements") defined together with their behavior, their structure (relationships and interactions), their composition, and their spatio-temporal distribution

5


- The information model architecture and

- The state model architecture, respectively

• The architectural work includes the identification and the documentation of

- The objectives of the architecture

- The principles governing its design and evolution over time

Entity_1 Entity_2Relation_11:n 1:1

State_1 State_2Transition_1

Motivations for architectural work

Favor key structural principles

• Integrate multi-aspects of a system at design time• Structure and organise complex systems

•Modularize (divide to conquer)• Facilitate comparison between different approaches

• Minimise duplicates and misconceptions• Define a common reference “vocabulary“

•Prevents misinterpretation among different dimensions and actors involved.

• Enable an holistic approach starting from the top

Enforce system essential properties

• Robustness: correct operation in the presence of exceptional inputs or stressful environmental conditions

• Reliability: continuity of correct service • Reusable: system entities can be used in different context assuming the pre-conditions are met

• Maintainability: ability to undergo modifications or repairs

• Efficiency: optimise cost/performance ratio• Safety: not being exposed to the risk of harm

6


• Enable an holistic approach starting from the top (top-down)

•Complementary to experimental/bottom-up approach

• Large and expensive systems that affect the activities of many people needs a proper design that usually started by an analysis of the requirements phase and by an architectural (structural and behavioural) analysis phase

• Provide the basic to estimate the involved costs • Provide a reference point for the verification of results (behaviour)

• Safety: not being exposed to the risk of harm

Drive components and software designs

• Serve as a starting point for software design and components development

• Lead to modular and reusable software development

•Standardized reusable modules especially ones that have been formally specified and certified, may be more economical in the long run.

• Allow tracing from implementation back to initial requirements

Achitecturing the Future Internet -- Methodology

Objectives (qualitative and quantitative)Design Principles (≡ guidelines)

Model and components (Functional, Object/information and State dimension)

• Global level: Generic and common specification of elements

• Global level: Specialization of elements specification (per domain)

• Local level: Specialization of elements specification (per domain)

Descriptive and informal

Declarative and formal

Practice and

Architecture

7


Modelling techniques• Function, information/data, state

• Relationship (uses, specialises, inherit from, …)

How to use existing modeling techniques

Practice and applicability statements

Tools

Building block design style

Applications (proof-cases)

Steps in Models and Components

network

Step 1 Global level/GenericGeneric & common

specification of elements

Step 2Global level/per

domain

Specialization of elements specification (per domain e.g.,

media, IoT, etc.)

8


building block design

system

media, IoT, etc.)

Step 3Local level/per

domain

Specialization of elements specification (per domain e.g., media, IoT, etc.)

Local architecture

(system-wide level)

Experimental Models and ComponentsIn practice

Specialized IoT Media Cloud

...

Specialized

elements

feed feed

IoT Media Cloud

feed

9


feedGlobal architecture

network-wide level

...

Specialized

elements

feed feed

IoT Media Cloud

Generic and common elements (including behavior, structure (relationships and interactions),

composition, and spatio-temporal distribution

Putting models in perspective

Global generic

Design principles

Objectives

Future Internet TCP/IP OSI RM

Design principles

Objectives Objectives

Function Data States Function States

Global generic

10


Solutions design

SystematicAnalytical

EmpiricalIterative

No deployment

Solutions design Solutions design

Global specific

Local specific

Global specific

Global level/per domain -- Specialization of elements specification for routing

11


Local level/per domain Specialization of elements specification for routing

12


FIArch

• FIA working group created by the European Commission in May 2010

• Define a common reference architecture that can guide and unify key technology developments based on common problem statement and set of architectural design principles

• Created with an open perspective and aiming to integrate different efforts in the research fields of "Future Internet"

- Set of experts, CSAs and projects representing the different areas of the future Internet

• FIArch methodology: defined to achieve, step by step, shared and agreed by various stakeholders, a reference architecture

13


Doc'sFIArchgroup

Research community

• FIArch results- Documented in a set of public, technical reports shared and agreed by significant representation

and coverage of FI stakeholders, including FIA projects

- Outcome of the task (content) should have a long-term, worldwide validity

Set the standardisation approach for research projects

Needs a well-defined methodology

- Identify what we need to standardise (interfaces, etc) to allow the technology proposed by the project to be interoperable/deployable at a large scale which implies the identification of a “rough” architecture)

- Identify the role and impacts of standardisation bodies on the segmenttargeted by the research project

- Standardisation activities is a food chain model

- Do we need to improve the standardisation eco-system to maximise the

1

2

3

14


- Do we need to improve the standardisation eco-system to maximise the chance of success

- Create new Technical Committee, working groups and/or

- Attract major actors

No need for standards

Direct channel to standards

Structuredincubation

- Identify the “structuring” aspects when choosing standardisation target

3

4

Moving to standards

• What needs to be standardised?

- (Design) principles (i.e. guidelines)

- Model and components (Functional, Object/information and State dimension)

- Global level: Generic and common specification of elements

- Global level: Specialization of elements specification (per domain e.g., media, IoT, etc.)

- Local level: Specialization of elements specification (per domain e.g., media, IoT, etc.)

• Role and impacts of standardisation bodies

- Potential candidates includes ETSI, ITU-T and IRTF

• Do we need to improve the standardisation eco-system

1

2

3

15


• Do we need to improve the standardisation eco-system

- Need a pre-standardisation group, see next step 4

• Structuring aspects

- it is very unlikely that a standardisation body will accept to incorporate this work in its standardisation work program

- one could argue that this architectural needs to be validated.

- As a result, we need to incubate the work in a pre-standardisation group

- Validate a possible reference architecture model for the future Internet (specified by FIArch)

- Give guideline on alternative models (if applicable)

- Explore possible directions for further standardization.


3

4

Purposes

• Validate a possible reference architecture model for the future Internet

• Give guideline on alternative models (if applicable)

• Explore possible directions for further standardization

Benefits

Future Internet architecturepre-standardisation: benefits


16


Benefits

• Cross domain validation

• Gain experience in building architecture

• Build critical mass (open to any research community and attract people outside the EU research space)

• More flexible than regular standardization groups

• Label (outcome will get some form of official status)

• Hosted standardization body logistics

• Accelerate engineering community acceptance

•Objectives•Principles•Experimental Model and components (Step 1)

Specify

Prerequisite

Design

InfluenceGeneric and common External

Influence

EU ResearchFIArch

Future Internet Architecture pre-standardisation: actors and roles

17


– Experimental Model and components (Steps 2 & 3)

Cookbook (how to apply to specific/to other domains)

+

Set of specifications/technical reports

Feed

Produce

Design

Design

Domainspecific

IoT, Media, Cloud, etc


18


19


a path towards strong architectural foundation for the internet...

Documents