On Evolvability, Architecture, Tussle, Layering and Signalling Mark - - PowerPoint PPT Presentation

on evolvability architecture tussle layering and
SMART_READER_LITE
LIVE PREVIEW

On Evolvability, Architecture, Tussle, Layering and Signalling Mark - - PowerPoint PPT Presentation

On Evolvability, Architecture, Tussle, Layering and Signalling Mark Handley UCL Change Huge innovation email WWW phone... in applications SMTP HTTP RTP... TCP UDP Ossification of the core IP protocols ethernet PPP CSMA


slide-1
SLIDE 1

On Evolvability, Architecture, Tussle, Layering and Signalling

Mark Handley UCL

slide-2
SLIDE 2

email WWW phone... SMTP HTTP RTP... TCP UDP… IP ethernet PPP… CSMA async sonet... copper fiber radio...

Change

Huge innovation in applications Ossification

  • f the core

protocols Relentless evolution

  • f the underlying

technology

slide-3
SLIDE 3

Tussle and the death of end-to-end.

Different parties want varying degrees of control over connections.

 End systems (obviously) - to enable applications.  Firewalls - to enhance security.  Deep packet inspection - to differentiate service.  Link layers - to enhance transport performance.  Transparent caches - to enhance application performance,

reduce bandwidth costs.

 Security services - to be spooky.

slide-4
SLIDE 4

Current Layered E2E Architecture

Link IP TCP App Link IP TCP App IP IP

Link Link Link Link

slide-5
SLIDE 5

Current Sort-of-Layered Sort-of-E2E Architecture

Link IP TCP App Link IP TCP App IP IP

Link Link Link Link

IP

TCP TCP App App

slide-6
SLIDE 6

Evolvability

 Any new architecture must permit tussles to play out within the

architecture.

 Alternative is:

 Difficult to evolve because of unintended feature interactions.  Eventual ossification and stagnation.

slide-7
SLIDE 7

Some New Approaches

 Role-based Architecture.  Connection Signalling.

slide-8
SLIDE 8

Role-based Architecture

 Break packets into separable functionality.

 Avoids unnecessary coupling as the architecture evolves.

 Address sub-packets to entities that perform specific roles.

 Provides a way to talk to an entity (eg Firewall) other than

the remote end system.

 May not know its address (or it may not have an address).

 Allow entities along the path to add or remove sub-packets as

required to perform their job.

 Provides a place in the architecture for them.

slide-9
SLIDE 9

Roles and Role-Specific Headers

App Payload RSH 1 RSH 2 RSH 3 Role 1 Role 2 Role 3 packet

slide-10
SLIDE 10

Contrived Example

RSH( Forward.HbH@*; B, A) RSH( AppMux@B; destPort, SrcPort ) RSH( Firewall@*; ``Disable = Cache'') RSH( Cache@*; ) RSH( DestApp@B; <payload>)

 Directive indicates data can be cached, but then indicates

to the firewall to disable the Caching directive.

 Allows caching only within the firewall.

slide-11
SLIDE 11

Connection Signalling

Use a signalling protocol (“CSP”) to initiate all transport connections.

 Not VCs though, connections can still be datagrams.

Not strictly layered under or over transport protocols.

 More like alongside, akin to how ICMP is to IP.

Provides a hook within the architecture for different entities to signal their needs.

IP TCP

CSP

SCTP

CSP

UDP

CSP ICMP

HTTP, SMTP, RTP, …

slide-12
SLIDE 12

Firewall redirect to offpath proxy

A B

Setup(A,p1↔B,80) OK CSP aware Firewall OK Redirect(A,p1↔P:B,80) Setup(A,p1↔P:B,80) Setup(P,p1↔B,80) HTTP Connection HTTP Connection HTTP Proxy

slide-13
SLIDE 13

Hidden Mobile Server

OK

moves

Setup(A,p1↔S,p2) Redirect(A,p1↔S:B,p2)+nonce+sig Detach+ Attach+Nonce+Sig Data Transfer (A,p1↔B,p2)

A S HA At B

Register(S at B)

At C

OK Data Transfer (A,p1↔C,p2)

S

Setup(A,p1↔S:B,p2) Setup(A,p1↔S:B,p2) OK