Reconstructing computer networking with RINA: how solid scientific foundations can allow Europe to...

Reconstructing computer networking with RINA: how solid scientific foundations can allow Europe to become a world leader in

internetworking

European Commission. Brussels, June 25th 2015

Eduard Grasa, Sergi Figuerola (Fundació i2CAT)With slides and input from John Day, IRATI and PRISTINE consortiums

RINA tutorial to the EC 2

Three ideas to get out of this tutorial• Current networking technology hasn’t got

solid foundations– Just because something is widely used and deployed it

doesn’t mean it’s a good technical solution

• There is a scientific alternative based on a sound theory, which yields cheaper, simpler, more performing, predictable and reliable networks

• Europe has an incredible opportunity to lead this distributed computing and networking revolution, which could impact Europe’s Distributed computing & Telecom industry in a massive way

1

2

3


WARNING!

• Please, please, please, interrupt me at any time, ask questions, etc..

• The goal is not to cover the whole material, but that you understand some/most of the points supporting the three previous ideas

RINA Tutorial to the EC 4

DECONSTRUCTING THE INTERNET1

Lets Get the Bad NewsOut of the Way

• The TCP/IP Model is Fundamentally Flawed – And has been from the Start.

• The Flaws are sufficiently deep that either they are not technically correctable or the socio-political will is not there.

• And a bit of myth-busting: – The Internet was not based on the ARPANET.– It was built on the ARPANET, but it was based on

CYCLADES.– Packet Switching was obvious (depending on your age). ;-) – Datagrams were far from obvious and a major insight.

RINA Tutorial to the EC© John Day, 2014

Rights Reserved 5

What are The Flaws?

• Architecture– Not Understanding that Layers in Networks aren’t just modules (circa

1978)– Lost the Internet Layer (~ 1983)– After an early concern with security (<1974), by the late 70s nobody

cared.

• Naming and Addressing– A IP address names the interface rather than the node (1972, ‘78,

‘92)– Failure to create a complete addressing architecture (circa 1980)

• Protocol Design– Of the 4 protocols that could have become dominant, TCP was the

worst choice– Failure to incorporate Watson’s discovery (1979)– An approach to congestion avoidance that causes congestion,

thwarts any attempt at QoS, and is predatory (1986). The icing on the cake.

• The Problems seen today are mainly Consequences of these more Problems.


Rights Reserved 6

How Did It Happen?

• To some degree, A Major Factor was the Initial Focus– The ARPANET and the Internet were production networks to lower

the cost of research on other topics; – Whereas the focus of CYCLADES was a network to do research on

networks

• A Major Politico-Economic War between Computer Companies and PTTs, Europe vs the US vs Japan and everyone against IBM.– Traditional “beads-on-a-string” vs a more computing model of

networking

• The usual reasons: hubris, tradition, NIH, and an attitude of “if ‘they’ did it we won’t.”

• That’s a bit too brief, so let me elaborate just a bit.


Rights Reserved 7

8

The Beads on A String Model

• The Nature of their early technology led the Phone Companies to Adopt what could be called, a “Beads-on-a-String” architecture.– Deterministic, Hierarchical, master/slave.

• Perfectly reasonable for what they had.

• The model not only organized the work, – But was also used to define markets: Who got sell what.– This was what was taught in most data comm courses prior to the 1980s.

• And for some, in a fundamental sense, never left.

phone CO CO phone

© John Day, 2014 Rights Reserved

RINA Tutorial to the EC

9

Packet Switching

• In the early 1960s, Paul Baran at The Rand Corporation writes a series of reports investigating the networking requirements for the DoD.

• Donald Davies at NPL in the UK had the same idea

• He finds that the requirements for data are very different than those for voice.

• Data is bursty. Voice is continuous.• Data connections are short. Voice connections have long durations.

• Data would be sent in individual packets, rather than as continuous stream, on a path through the network.

• Packet switching is born and

• By the late 1960s, the Advance Research Projects Agency decides building one would reduce the cost of research and so we have the ARPANET.

RINA Tutorial to the EC © John Day, 2014 Rights Reserved

ARPANET Layers

• The ARPANET was the first, so feeling our way.• BBN is building the Subnet and it is necessarily somewhere between a

traditional data comm network and a new packet network, but there are no layer diagrams of it.

• So everyone just sees layers in the host as modularity.• But with the advantage of an example and a lot collaboration with BBN

Physical

IMP-Host

Host-Host (NCP)

Telnet

File Transfer

Physical

IMP-Host

Host-Host (NCP)

Telnet

File Transfer

IMP Subnet

12

But was Packet Switching a Major Breakthrough?

• Strange as it may seem, it depends.• During this period many things are age dependent.

• If your formative years had occurred prior to the mid-60s (pre-boomer), your model of communication was defined by telephony. – Then this is revolutionary.

• If you are younger (boomer), your model is determined by computers.– Data is in buffers, How do you do communications:

• Pick up a buffer and send it.

– What could be more obvious!• That it was independently invented (and probably more than twice) supports

that.

• But there was a more radical idea coming!RINA Tutorial to the EC © John Day, 2014 Rights Reserved

CYCLADES was Building a NetworkTo Do Research on Networks

• The wanted a minimalist network to use as a research tool.• They too saw layering as a good tool for structuring the problem.

• Elie and Zimmermann realized that layers in networks were not only different, but a necessity.

• Layers are a loci of distributed shared state with different scopes• At the very least, differences of scope require different layers.

• This property makes the earlier “beads-on-a-string” model untenable.• Talk of control and data planes is beads-on-a-string.

• Not looking at layers like this underpins many other problems.Host or End System

Router

Incr

easi

ng

Sco

pe


13RINA Tutorial to the EC

The Cyclades Architecture(1972)

• CYCLADES brings the layering from operating systems, but changes it.

• Data Link – corrects media errors, not propagated to a wider scope.• Network – relays using a connectionless datagram network, Cigale

• Transport recovers from loss due to congestion creating a reliable flow.• Yielding a simpler, cheaper, more effective and robust data network. • Since the Hosts won’t trust the network anyway, the network does not have to

be perfect, (and can’t be); it makes a “Best-Effort; need only be sufficiently reliable to make end-to-end cost effective

• This represents a new model, in fact, a new paradigm completely at odds with the beads-on-a-string model.

Physical

Data Link

Network

Transport

Application

Host or End System

Router

TS: End-to-End Reliability

Cigale Subnet



The New Model Had 4 Characteristics• It was a peer network of communicating equals not a hierarchical

network connecting a mainframe master with terminal slaves.• The approach required coordinating distributed shared state at

different scopes, which were treated as black boxes. This lead to the concept of

layers being adopted from operating systems and • There was a shift from largely deterministic to non-deterministic

approaches, not just with datagrams in networks, but also with interrupt driven, as opposed to polled, operating systems, and physical media like Ethernet, and last but far from least,

• This was a computing model, a distributed computing model, not a Telecom or Data comm model. The network was the infrastructure of a computing facility.

• These sound innocuous enough. They weren’t. • They were a direct threat to the business models of IBM and PTTs



After ICCC’72, the Research Networks formed INWG* to developan Internet Transport Protocol

There Were Two Proposals

• INWG 39 based on the early TCP and

• INWG 61 based on CYCLADES TS.

• And a healthy debate, see Alex McKenzie, “INWG

and the Conception of the Internet: An Eyewitness Account” IEEE Annals of the History of Computing, 2011.

• Two sticking points– How fragmentation should work– Whether the data flow was an undifferentiated stream or maintained the integrity of the units

sent (letter).

• These were not major differences compared to the forces bearing down on them.



After a Hot Debate

• A Synthesis was proposed: INWG 96

• There was a vote in 1976, which approved INWG 96.

• As Alex says, NPL and CYCLADES immediately said they would convert to INWG 96; EIN said it would deploy only INWG 96.

• “But we were all shocked and amazed when Bob Kahn announced that DARPA researchers were too close to completing implementation of the updated INWG 39 protocol to incur the expense of switching to another design. As events proved, Kahn was

wrong (or had other motives); the final TCP/IP specification was written in 1980 after at least four revisions.” – Neither was right. The real breakthrough came two years later.

• But the differences weren’t the most interesting thing about this event.



The Similarity Among all 3 Is Much More Interesting

• This is before IP was separated from TCP. All 3 of the Proposed Transport Protocols carried addresses.

• This means that the Architecture that INWG was working to was:

• Three Layers of Different Scope each with Addresses.• If this does not hit you like a ton of bricks, you haven’t been

paying attention.• This is NOT the architecture we have.

Internetwork Transport Layer

Network Layer

Data LinkLayer



Internet Model (1976)

• An Internet Layer addressed Hosts and Internet Gateways.

• Several Network Layers of different scope, possibly different technology, addressing hosts on that network and that network’s routers and its gateways.– Inter-domain routing at the Internet Layer; Intra-Domain routing at the

Network Layer.

• Data Link Layer smallest scope with addresses for the devices (hosts or routers) on segment it connects

• The Internet LOST A LAYER!!

Data Link

Network

Internet Transport

Application

HostInternet Gateways

Data Link

Network

Internet Transport

Application

Host

Network 1 Network 2 Network 3



• It is not obvious.

• At first glance, one might say the Network Layer.– After all the Protocol is called IP! – Removing the ARPANET, “removed” the Network Layer, – Everything just dropped down.

• But the IP Address names the Interface, something in the layer below, just like ARPANET addresses did!– More like IP replaced the ARPANET.– At best, IP names a network entity of some sort, at worst, a data

link entity– Actions speak louder than words

• We must conclude that, . . .

So What Layer Did They Lose?

They Lost the Internet Layer!!!© John Day, 2014

Rights Reserved24RINA Tutorial to the EC

MAC

TCP

An Ethernet

IP

PPP

TCP

MAC

IP IP

MAC

TCP

PPP

IP IP

MAC

TCP

IP

An Ethernet

Leased Line

HostHost

Router Router

TCP Was Split the Wrong Way

• A Careful Analysis of this Class of Protocols shows that the Functions naturally cleave (orthogonally) along lines of Control and Data.– This also facilitates the separation of mechanism and policy

• In this case, the Fragmentation problem simply doesn’t occur.

• All of the other proposals made this Split between Control and Data.

Relaying/ Muxing

DataTransfer

Data TransferControl

Delimiting

Seq Frag/Reassemb

SDU Protection

Retransmission and Flow Control



Watson’s Insight (1978)

• Richard Watson proves that the necessary and sufficient conditions for distributed synchronization requires only that 3 timers are bounded:

• Maximum Packet Lifetime• Maximum number of Retries• Maximum time before Ack

• Develops delta-t to demonstrate the result, which has some unique implications:– Assumes all connections exist all the time.– TCBs are simply caches of state on ones with recent activity

• Watson shows that TCP has all three timers and more.– delta-t is more robust under harsh conditions and more secure than TCP.– SYNs, FINs are unnecessary.

• Also defines the bounds of networking or InterProcess Communication:– It is IPC if and only if Maximum Packet Lifetime can be bounded.– If MPL can’t be bounded, it is remote storage. © John Day, 2014


Computer Networks are notDataComm Networks

• In telephony and datacom networks everyone did addressing by just numbering the ports or the wires coming from the switches, the end devices were simple and mostly passive.– So Did BBN, we were IMP 12.

• But in a network of peers, end-devices were “participants” in the network.

• Then Tinker AFB joined the ‘Net exposing the multihoming problem.

• This looks like two hosts to the network. It doesn’t know the two wires go to the same place.

• Need to name the node and only name the interface if it has multiple destinations.– Everyone else got this right: XNS, CYCLADES, DECNET, OSI, etc.

8 6

Host

IMP IMP



Making the Generality

• Directory provides the mapping between Application-Names and the node addresses of all Applications reachable without an application relay.

• Routes are sequences of node addresses used to compute the next hop.

• Node to point of attachment mapping for all nearest neighbors to choose path to next hop. (Because there can be multiple paths to the next hop.)

• This last mapping and the Directory are the same: – Mapping of a name in the layer above to a name in the layer below of all nearest neighbors.

Here

And Here

Directory

Route

Path

Application Name

Node(Logical Address)

Point of Attachment

(Physical Address)



Not in the Internet

• The Internet only has a Point of Attachment Address, an interface.– Which is named twice!– No wonder there are addressing problems

• There are no node addresses or application names.– Domain names are macros for IP addresses– Sockets are Jump points in low memory– This is why mobility is so hard.

MAC Address

IP Address

Socket (local)

ApplicationApplication

Name

Node Address

Point of AttachmentAddress

As if your computer worked only with absolute memory addresses.(kinda like DOS, isn’t it?)



IPv6: Makes Matters Worse

• Primary Problem: Router Table Size; secondarily address exhaustion.

• 1992 Rejection of IPv7 (CLNP), which named the node and was already deployed and operational in the routers. (the transition was over.)

– By continuing to name the interface, avoided reducing router table size by a factor 3 – 4 times (as well as address usage) Reducing router table size was Major Problem

– This decision above all was totally irresponsible, but typical of mob rule– Not only does it make multihoming impossible, but makes mobility the

cumbersome mess MIPv6 creates.– Long list of problems today, and loc/id split only dug the hole deeper.

• But did get more addresses, but can only route on /64, the rest are for NSA.– Barely able to route 1 IPv4 address space, no idea how to route 4.3 billion.– But that is okay, as we will see a global address space is unnecessary in a

well-formed architecture. (More addresses isn’t a problem).• Yes, there is good news a-comin’! 31RINA Tutorial to the EC

Then in ‘86: Congestion Collapse

• Caught Flat-footed. Didn’t realize it could happen.• Implies didn’t understand the rationale for Transport when e2e paper was written

• Why? Everyone knew about this?– Had been investigated for 15 years at that point

• Most important property of any congestion control scheme is minimizing time to notify. Internet maximizes it and its variance.

• Strong oscillations by TCP, thwarts any to attempt to provide QoS

• And implicit detection makes it predatory.– Virtually impossible to fix

• Whereas,© John Day, 2014


Congestion Control in an Internet isClearly a Network Problem

• With an Internet Architecture, it clearly goes in the Network Layer– Which was what everyone else thought.

• Time to Notify can be bounded and with less variance.• Explicit Congestion Detection confines effects to a specific layer in

a specific network, allows different strategies for different QoS Classes

• I don’t see any way out of this in the current ‘Net that isn’t very painful! This may be worse than the addressing problems.

Data Link

Network

Internet Transport

Application

HostInternet Gateways

Data Link

Network

Internet Transport

Application

Host

Network 1 Network 2 Network 3



36

Would be Nice to Manage the Network

• All Management is Overhead! We need to minimize it.– Then need Efficiency, Commonality, Minimize Uncertainty

• With a choice between a object-oriented protocol (HEMS) and a “simple” approach (SNMP), IETF goes with “simple” to maximize inefficiency

– Must be simple, has Largest Implementation of the 3: SNMP, HEMS, CMIP.– Every thing about it contributes to inefficiency

• UDP maximizes traffic and makes it hard to snapshot tables• No means to operate on multiple objects (scope and filter). Can be many

orders of magnitude more requests• No attempt at commonality across MIBs.• Polls?! Assumes network is mostly failing!• Use BER, with no ability to use PER. Requests are 50% - 80% larger

• Not secure, can’t use for configuration



But What About Security?

• Security?

• Don’t you read the papers?!– It is terrible! And all signs are getting worse.– IPsec makes IP connection-oriented, so much for resiliency to failure.– Everything does their own, so very expensive.

• Privacy? Can’t fix it, so same reaction as for QoS– You don’t need it in the brave new world.

• They say the Reason is that Never Considered It at the Beginning.– Later we will see how ignoring security can lead to better security.

• There have been a lot of “after the fact” attempts to improve it.– With the usual results: greater complexity, overhead, new threats.



So Why Is TCP/IP Dominant?

• The Usual Reason:

• He with the deepest pockets wins.– Especially when it is someone else’s money.

• DARPA was spending orders of magnitude more on networking than everyone else combined and then gave it away for free. – Even then, it was loose change to the DoD

• Believe it or not, there is strong evidence that business left to its own devices would have come very close to getting it right. – Not entirely, but close enough to be fixed.



Want to Feel Really Bad?

• A New eBook* James Pelkey’s "Entrepreneurial Capitalism and Innovation: A History of Computer Communications, 1968-1988” paints a different picture:–First companies were developing LAN products

• Workstations coming in but SNA is still dominant

–Then products to connect LANs together in the workplace.• Novell and others are making inroads.

–Then connecting LANs over distances to create corporate networks.• Corporations were concerned about security and wanted their own networks

–By the late-80s, corporations wanted their suppliers on their networks.–The next step would have been so many corporate networks wanting their

suppliers on them, that it would have been advantageous to have a single network connecting the corporate networks.

–Notice this is a natural progression to the INWG Model.

• How Do I Know This is What Would Have Happened?–Because It Did.

In the Middle of this is dumped free software and a subsidized ISP but with a flawed architecture and a lot of hype: The Internet!!



• With a Transport Layer, this is the same as the INWG model.• OSI stayed the course with a similar split to TCP/IP.• So OSI had an Internet Architecture and the Internet has a Network

Architecture.

• And signs of a repeating structure.

Transport Layer

Subnet Independent

Subnet Dependent

Subnet Access

Data Link LLC

Data Link MAC

The OSI network layer

was soon subdivided into 3 layers

Relaying and multiplexing

Error and flow control





Data link scope

Network scope

Internetwork scope

OSI also came to the INWG model

43

• INWG and OSI where on the right track, but did not see the repeating pattern and generalize it…

• Doesn’t seem to be, what about VPNs over the Internet?– Another layer on top of the Internet

• What about virtual networking? (e.g. VXLAN, STP, etc.)

• What about an internetwork of internetworks?

• There doesn’t seem to be a fixed number of layers, it all depends on the scenarios and use cases. Therefore the fundamental architecture of computer networks is…

Internet Gateways

Data Link

Network

Internet

Application

Data Link

Network

Internet

Application

Net 1 Net 2 Net 3

Host Host

So is this the definitive architecture?




INTRODUCING RINA2

RINA Architecture• A structure of recursive

layers that provide IPC (Inter Process Communication) services to applications on top

• There’s a single type of layer that repeats as many times as required by the network designer

• Separation of mechanism from policy

• All layers have the same functions, with different scope and range.– Not all instances of layers may need all functions, but don’t need more.

• A Layer is a Distributed Application that performs and manages IPC.– A Distributed IPC Facility (DIF)

• This yields a theory and an architecture that scales indefinitely, – i.e. any bounds imposed are not a property of the architecture itself.



47

Naming and addressing in RINA• All application processes

(including IPC processes) have a name that uniquely identifies them within the application process namespace.

• In order to facilitate its operation within a DIF, each IPC process within a DIF gets a synonym that may be structured to facilitate its use within the DIF (i.e. an address).

The scope of an address is the DIF, addresses are not visible outside of the DIF.

The Flow Allocator function of the DIF finds the DIF IPC Process through which a destination Application process can be accessed.

Because the architecture is recursive, applications, nodes and PoAs are relative For a given DIF of rank N, the IPC Process is a node, the process at the layer

N+1 is an application and the process at the layer N-1 is a Point of Attachment.

1 2 3 4

1 2 1 2 3 1 2

1 21 2

DIF A

DIF BDIF C

DIF D

DIF E DIF F


That’s Pretty Bleak

The Good News Better Be Pretty Good

• Actually, It Is. In fact, very good.

• Networking is far simpler, less complex, more secure, considerably more powerful and far less cost both capex and opex.

• It turns out there aren’t 5 or 7 layers, but 1 that repeats.

• Networking is Interprocess Communication (IPC) and only IPC.

• A Layer provides and manages IPC for a range of bandwidth, QoS and Scale, it is a unit of resource allocation.



Just That Yields

• Multihoming for free; yields better resiliency, faster fail over, and of course, routing tables 3 – 4 times smaller without doing anything.

• Mobility is free (Just multihoming with more frequent failures): no special protocols required, no home routers, no foreign routers and no tunnels to be created.

– Much, much simpler and more secure, because

• The layer is a securable container eliminating the need for firewalls, and with the repeating structure far less expensive.

• Recursion allows the impact of changing addresses on mobile hosts to scale.

• Recursion allows arbitrarily Bounding Router Table Size

• Most addresses belong to the owner of the Network, little need of a central authority.

• Congestion control is done within QoS classes, so is not one size impacts all and tighter QoS classes.

• Commonality across layers makes management simpler, more effective and efficient. Less expensive staff needed. © John Day, 2014

Rights ReservedRINA Tutorial to the EC 49

But There is More!• Separating mechanism and policy implies one data

transfer protocol and one application protocol.– Layers are tailored to the needs of their networks, not the

vendors– Applications can be created and deployed faster and at

much less cost.

• A complete naming and addressing architecture that allows application name space to have greater scope than any address space and not requiring applications to figure out what “wire” or what network an application is on implies a Global Address space is not necessary.– This is huge. This opens the door for infinite routing with

small addresses and with greater security. Address spaces of limited scope can contain bad guys and isolate.© John Day, 2014


Not Just a Network Model• A Layer is a Distributed Application that Does IPC

• That Forced Us to Answer: What is a Distributed Application?

• We now are working with a Unified Model for

Printer

USB-DIF

WiFi-DIF

OS - DAF

DiskLaptopOperating Systems

IRM

Distributed Applications

IRM

NetworksTask sched

MemMngt

IPC

Tasks

Application Processes



What a Layer Looks Like

• Processing at 3 timescales, decoupled by either a State Vector or a Resource Information Base

– IPC Transfer actually moves the data ( ≈ IP + UDP)– IPC Control (optional) for retransmission (ack) and flow control, etc.– IPC Layer Management for routing, resource allocation, locating applications, access

control, monitoring lower layer, etc.

• Remember that within a scope if there is a partitioning of functions, it will be orthogonal? Well, here it is.

IPCTransfer

IPCControl

IPC Management

DelimitingTransfer

Relaying/ MuxingPDU Protection Common Application

Protocol

Applications, e.g., routing, resource allocation, access control, etc.

Application-entities Application Process



Only Three Kinds of Systems

• Middleboxes? We don’t need no stinking middleboxes!

• NATs: either no where or everywhere,• NATs only break broken architectures

• The Architecture may have more layers, but no box need have more than the usual complement.– Hosts may have more layers, depending on what they do.

Hosts

InteriorRouters

BorderRouters



All Communication goes through Three Phases

• Enrollment– Operations to create sufficient state within the network to allow an

instance of communication to be created.

• Allocation (also known as Establishment)– Operations required to allocate an instance of communication creating

sufficient shared state among instances to support the functions of the data transfer phase.

• Data Transfer– Operations to provide the actual transfer of data and functions which

support it.

• Most of our attention has been on the last two. The first has often been ignored and is usually seen as necessarily ad-hoc. But enrollment turns out to be key.



How Does It Work? Enrollment or Joining a Layer

• Nothing more than Applications establishing communication (for management)

– Authenticating that A is a valid member of the (N)-DIF– Initializing it with the current information on the DIF – Assigning it a synonym to facilitate finding IPC Processes in the DIF, i.e. an address– (see the Enrollment specification for an example.)

(N-1)-DIF

(N)-DIF

A



How Does It Work?Establishing Communication

• Simple: do what IPC tells us to do.– A asks IPC to allocate comm resources to B– Determine that B is not local to A use search rules to find B– Keep looking until we find an entry for it.– Then go see if it is really there and whether we have access.– Then tell A the result.– (See Flow Allocator specification)

• This has multiple advantages.– We know it is really there.– We can enforce access control– We can return B’s policy and port-id choices– If B has moved, we find out and keep searching

A BAhh, look there!



Routing at Different Layers

• With a Recursive Model, there are levels of routing with border routers acting as the step-down function creating interior flows.

• This tends toward a “necklace” configuration.

Hosts

InteriorRouters

BorderRouters



Implications of the Model & Names (Routing Table Size)

• Recursion either reduces the number of routes or shortens them.

Backbone

Regionals

Metros



This Bounds Router Table Size

• There will be Natural Subnets within a layer around the Central Hole.• Each can be a routing domain; Each Subnet is one hop across the Hole.

– The hole is crossed in the layer below.

• A Topological Space is imposed on the Address Space of Each Layer

Backbone

Regionals

Metros

(N)-Routing Domains

(N-1)-Routing Domains



Names & Implications of the Model(Basics)

• We have made a big deal of node and point of attachment, but they are relative, not absolutes.

– An (N)-IPC-Process is a node in the (N)-DIF.• An (N-1)-IPC-Process is a node in the (N-1)-DIF

– An (N-1)-IPC-Process is a point of attachment to an (N)-IPC-Process.– An (N)-address is a synonym for an (N)-IPC-Process.

• So as long as we keep that straight, there is no point to making the distinction.

• Note that it is the port-id that creates layer independence. With a port-id, No Protocol-Id Field is Necessary, or if there is such a field something is wrong.

Address

Port -id

(N)-IPC-Process

(N-1)-IPC-Process



.

Implications of the Model & Names(Multihoming)

• Yea, so? What is the big deal? It just works

– PDU arrives at an (N-1)-IPC Process. If the address designates this (N-1)-IPC Process, the CEP-id is bound to the port-id, so after stripping off (N-1)-PCI, it passes it up. PDUs arrive on different (N-1)-DIFs? So?

– The process repeats. If the address in the (N)-PCI is this IPC-Process, it looks at the CEP-id and pass it up as appropriate.

– Normal operation. Yes, the (N-1)-bindings may fail from time to time.

– Not a big deal. Because not routing to the (N-1)-address, but to the (N)-address

– Need an example?

(Destination) AddressPort -id

(N)-IPC-Process

(N-1)-IPC-Process



Consider the Following Network

• Since we want to emphasize that we are naming interfaces, lets give addresses to each of the interfaces.

• Now lets say that A wants to send a PDU to H, so it goes to DNS and looks up the address and gets 9. Now these guys have been running a routing algorithm and the route is A, B, D, F, H.

• So what do the router tables look like, (next slide)

G

A

B

C E

D

F

H

1

26

5

8

3 14

1817 16

15

19

21

13

209

11

10

12

4

7

22



A PDU is Sent With

Destination Address 9 From A

• A consults its Forwarding Table and sends it on outgoing address 1, next hop 22.

• B consults its FT and sends it on outgoing address 7, next hop 15.• D consults its FT and sends it on outgoing address 14, next hop

20.• F consults its FT and sends it on outgoing address 11, next hop 9.• Now another PDU is sent from A to address 9, just after it leaves,

the interface goes down.

G

A

B

C E

D

F

H

1

26

5

8

3 14

1817 16

15

19

21

13

209

11

10

12

4

7

22



What Happens When Link From F to H Fails?

• What happens if Link with address 9 goes down?– In a few 10s of ms, a routing update is done, and Addresses 9 and 11 are

eliminated from the forwarding table.– After several seconds and many retries, A determines that Address 9 is not

responding,– All TCP connections with Address 9 are terminated. (The pseudo header kills

them.)– All packets enroute to 9 are lost.– Hopefully, there is a second DNS entry that lists H as also at Address 10.– Connections are re-established using address 10. Several seconds have elapsed.

G

A

B

C E

D

F

H

1

26

5

8

3 14

1817 16

15

19

21

13

209

11

10

12

4

7

22



Consider the Following NetworkWith Node Addresses

• Since we want to emphasize that we are naming nodes, lets just use the letters for addresses. But we still have to say which wire to send them on.

– There are two cases in general:• Point-to-point Wire: No need for lower layer addresses use local identifiers.• Multi-access wired or wireless: Here we need addresses, use MAC addresses

– We have only wires, so lets assign small integers as the local interface identifiers.

• Now lets say that A wants to send a PDU to H, so it goes to DNS and looks up the address and gets H. Now these guys have been running a routing algorithm and the route is A, B, D, F, H.

• So what do the router tables look like, (see next slide)

G

A

B

C E

D

F

H

12

3

1

21

3

4

12

3

12

3

1 2

3

1

1

22

2



Sending a PDU from A to H

• A has a PDU addressed to H:– A consults its Forwarding Table and sends the PDU on interface 2 to

B.– B consults its Forwarding Table and sends the PDU on interface 2 to

D.– D consults its Forwarding Table and sends the PDU on interface 2

to F.– F consults its Forwarding Table and sends the PDU on interface 2 to

H

G

A

B

C E

D

F

H1

2

3

1

21

3

4

12

3

12

3

1 2

3

1

1

22

2



What Happens When Link From F to H Fails?

• What happens if just after the PDU is sent the Link from F to H fails?

– In a few 10s of ms, a routing update is done, and a new Routing Table is generated.

– The PDU gets to D after the routing update has concluded and is delivered to H as if nothing happened.

– PDUs that might have been between B, D, and F might get re-routed. Only PDUs on the wire from F to H would be lost.

G

A

B

C E

D

F

H1

2

3

1

21

3

4

12

3

12

3

1

3

1 22

2



Comments on the Example• One of the excuses for not solving this a long time ago

was: only a few needed it so the burden shouldn’t be on everyone.– Burden? What Burden!

• Not only is it free! It is far less expensive. • Notice how much smaller the router tables were? Factor 3!• Fail over times are reduced by orders of magnitude.

• To be generous, this shows how tradition trumps science in the Internet.

– To be less generous, in their rush to not do anything OSI did, they cut off their nose to spite their face.

• Suppose that points of attachment (interfaces) fail frequently, is that a problem?

– No, we call that. . .



Names & Implications of the Model(Mobility)

• Yea, so? What is the big deal?– It just works just like multihoming only the (N-1)-port-ids come and go a bit

more frequently.

• O, worried about having to change address if it moves too far? Easy.• Assign a new synonym to it. Put it in the source address field on all outgoing

traffic. Stop advertising the old address as a route to this IPC-Process.• Want to renumber the DIF for some reason? Same procedure.

• Again, no special cases. No special protocols. No concept of a home router. Okay, policies in the DIF may be a bit different to accommodate faster changing points of attachment, but that is it.

Address

Port -id

(N)-IPC-Process

(N-1)-IPC-Process

New Address



Implications of the Model & Names (Choosing a Layer)

• In building the IPC Model, the first time there were multiple DIFs (data link layers in that case), to maintain the API a task was needed to determine which DIF to use.

IAPDir

MuxFlowMgr

– User didn’t have to see all of the wires– But the User shouldn’t have to see all of the “Nets” either.

• This not only generalizes but has major implications.



Implications of the Model & Names(A DIF Allocator)

• A DIF-Allocator incorporating a Name Space Management function determines via what DIFs applications are available.– If this system is a not member, it either joins the DIF as before– or creates a new one.

• Which Implies that the largest address space has to be only large enough for the largest e-mall.

• Given the structure, 32 or 48 bits is probably more than enough.

• You mean?• Right. IPv6 was a waste of time . . .• Twice.

DIF-Allocator



So a Global Address Space is Not Required but

Neither is a Global Application Name Space

Inter-DIFDirectory

To PeersIn Oher DIFs

Actually one could still have distinct names spaces within a DIFs (synonyms) with its own directory database.

• Not all names need be in one Global Directory.

• Coexisting application name spaces and directory of distributed databases are not only possible, but useful.

• Needless to say, a global name space can be useful, but not a requirement imposed by the architecture.

• The scope of the name space is defined by the chain of databases that point to each other.



Scope is Determined by theChain of Places to Look

• The chain of databases to look for names determines the scope of the name space.– Here there are 2 non-intersecting chains of

systems, that could be using the same wires, but would be entirely oblivious to the other.© John Day, 2014


“Internet” Congestion Control

• Congestion Control has been a known issue since 1972.– Except in the Internet who only discovered it when it crashed around their ears in 86

• The effectiveness of any congestion control is directly related to the time to effect a change.

– The longer it takes the less effective the congestion control

• End-to-end implicit notification is predatory.– Longest response time. Will work against any attempt to do it at a lower level with shorter scope and better response

time.

• The Internet has network congestion control, – not internet congestion control



How Does It Work?“Congestion Control”

• Congestion Control in TCP was always known to be a stop-gap.

• A DIF always has the potential for the full capability of functions.

• Do flow control (without retransmissions) between intermediate points.– Better congestion control, really flow control– Allocate different resources to different e-malls.– Allows provider much more effective management of resources.– Provides means to throttle flows being used for denial of service attacks– All of these places? Probably not all in the same DIF. Major Area for Research

T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

79

How Does It Work?Security

• A Hacker in the Public Internet cannot connect to an Application in another DIF without either joining the DIF, or creating a new DIF spanning both. Either requires authentication and access control.

– Non-IPC applications that can access two DIFs are a potential security problem.

• Certainly promising

Public Internet

ISP 1 ISP 2 ISP 3

Internet Rodeo Drive

Utility SCADAMy NetFacebook Boutique

Internet Mall of America



The Recursion Provided Isolation

• Security by isolation, (not obscurity)

• Hosts can not address any element of the ISP.

• No user hacker can compromise ISP assets.• Unless ISP is physically compromised.

ISP Hosts and ISPs do not share DIFS.(ISP may have more layers



82

• Benefits of having an architecture instead of a protocol suite: the architecture tells you where security related functions are placed.

– Instead of thinking protocol security, think security of the architecture: no more ‘each protocol has its own security’, ‘add another protocol for security’ or ‘add another box that does security’

Allocating a flow to destination application

Access control

Sending/receiving PDUsthrough N-1 DIF

Confidentiality, integrity

Placement of security related functions

N DIF

N-1 DIF

IPC Process IPC Process

IPC Process

IPC ProcessJoining a DIF

authentication, access control

Sending/receiving PDUsthrough N-1 DIF


Allocating a flow to destination application

Access control

IPC Process

Appl. Process

Access control(DIF members)


Authentication

Access control(Flow allocations to apps)

DIF OperationLogging

DIF OperationLogging


A Very Unexpected Result

• A DIF with no explicit security mechanisms is inherently more secure than the current Internet under the same conditions!

• It would appear that – A DIF is a Securable Container.



Other Things Fall Into Place

• Data Transfer in RINA is based on Delta-t (Watson, 1980)

• Lot has happened in 30 years, many attacks on TCP have been found:– Port scanning – Reset Attacks– SYN attacks – Reassembly Attacks

• Long after delta-t was designed, what about delta-t?

• Short answer: – None of them work (Boddapati, et al., 2012)

• Amazing, totally unexpected

– Why not?

• Multiple fundamental reasons, but all inherent in the structure:– First, have to join the DIF (all members are authenticated)

– Second, No Well-Known Ports• Would have to scan all possible application names!

– Third and more importantly, . . .



Decoupling Port Allocation and Synchronization

• No Way to Know What CEP-ids are Being Used, Since There is No Relation Between Port-id and CEP-id.– SYN-Ack Attack: must guess which of 2^16 CEP-id.– Data Transfer: must guess CEP-id and seq num within window!– Reassembly attack: Reassembly only done once.– No well-known ports to scan.

Synchronization

ConnectionEndpoint

Port Allocation

Port-id

Connection



RINA is Inherently More Secureand Less Work

• A DIF is a Securable Container. (Small, 2011)

– What info required to mount an attack, How to get the info

– Small does a threat analysis at the architecture level

• Implies that Firewalls are Unnecessary, – The DIF is the Firewall!

• RINA Security is considerably Less Complex than the Current Internet Security (Small, 2012)

– Only do a rough estimate counting protocols and mechanisms.

• See paper for details.



Internet RINA

Protocols 8 0

Non-Security Mechanisms

59 0

Security Mechanisms 28 7

To AddSecurity



Why Is Internet Security So Bad?

• The Standard Rationale One Sees is that They Didn’t Think About It at the Beginning.– Neither did We.– Nor did Watson.– But RINA and delta-t are more secure.

• That Seems to Imply that– Good Design May be More Important to

Security than Security Is.© John Day, 2014



IMPLICATIONS AND IMPACT3

T-5 Alternatives to TCP/IP 92

SIMPLER, CHEAPER, MORE PREDICTABLE NETWORKS

Simpler networks• Clean and simple structure at the macro-level: single type

of layer that repeats as needed, uniform API between layers– No need to differentiate “physical” vs. “virtual”, vs overlays, etc..

– Much simpler networks, with less devices and no middleboxes (no need for firewalls, NATs, tunnel terminators, DPI, etc). Just three types of systems: hosts, interior routers and border routers.

– Unification of all forms of I/O and networking under the IPC paradigm

– Applications can communicate with other applications just by name – regardless of their location – and request specific characteristics for the communication instance (max. delay, max loss, in order delivery, …)

– See next two slides


Network layers today (example)

Host Enterprise router

IEEE 802.3 (Ethernet)

Enterprise router

TCP/UDP

App A

Application A

Sockets API

OS SocketsLayer

1. Bind/Listen to interface and port

2. Accept incoming connections

3. Connect to a remote address/port

4. Send datagram

5. Write data (bytes) to socket

6. Read data (bytes) from socket

7. Destroy socket

IP

IEEE 802.11 (WiFi)

Carrier Ethernet Switch

IEEE 802.1q (VLAN)

IEEE 802.1ah (PBB)

Each tech has a different API, and all are different from the application API

Carrier Ethernet Switch


Network layers with RINA (example)

Host

Border router Interior Router

DIF

DIF DIF

Border router

DIFDIF

DIF

App A

The layer API is always the same (and the

same as the application API)

Application A

Layer (DIF) API

IPC Process

1. Register application

2. Allocate/Deallocate flows

3. Write data (SDUs) to flows

4. Read data (SDUs) from flows

5. Get layer information (QoS cubes, Max SDU size, etc..)


Simpler networks (II)• Each layer has the same components and structure,

programmable via “policies” to optimize each layer for its operating environment– No need to define new protocols for different layers, just

different policies

– Implementations can leverage this structure to obtain a more compact, simple, reliable and performing “network stack”

– Given that layers have the same API and internal structure, interactions between layers become simpler and predictable. Multi-layer network management becomes much more simple, allowing for more sophisticated automation deployed at larger scales.

– A layer is just a distributed application dedicated to do Inter Process Communication (IPC). An instantiation of a layer in a computing system is called IPC Process.

– See next slideRINA Tutorial to the EC 96

Internal structure of an IPC Process

IPCProcess

IPC API

Data Transfer Data Transfer Control Layer Management

SDU Delimiting

Data Transfer

Relaying and Multiplexing

SDU Protection

Retransmission Control

Flow Control

RIB Daemon

RIBRIB

CDAP Parser/Generator

CACEP

Enrollment

Flow Allocation

Resource Allocation

Routing

Authentication

State VectorState VectorState Vector

Data Transfer Data Transfer



Flow ControlFlow Control

Namespace Management

Security Management

Increasing timescale (functions performed less often)

System (Host)

• Each IPC Process has components to provide IPC (data transfer and data transfer control), as well as components to manage IPC (enrollment, routing, flow allocation, resource allocation, security management, etc..). – Layer management components use a common abstraction (the RIB) and protocol (CDAP)

to exchange information with neighbor IPCPs. This exchange of information is modeled as 6 remote operations (create, delete, reqd, write, start, stop) on obects.

RINA Tutorial to the EC97

98

Service Provider NetworksExample scenario (Fixed networks)

BorderRouterHost

Home /Enterprise DIF

Customer network

(Simplification, can have more internal structure probably)

Access DIF

BorderRouter

InteriorRouter

P2P DIF P2P DIF

BorderRouter

P2P DIF

InteriorRouter

P2P DIF

BorderRouter

P2P DIF P2P DIF

InteriorRouter

BorderRouter

Provider 1 Backbone DIF

P2P DIF

BorderRouter

Provider 1 Regional DIF

P2P DIF

BorderRouter

Provider 1 Metropolitan DIF

BorderRouter

P2P DIF P2P DIF

Provider 2 Metro DIF

InteriorRouter

P2P DIFP2P DIF

Public Internet DIF

Application-specific DIF

DAP

Provider 1 network Provider 2 network


99

Backbone DIF

RegionalDIF

SubDIF 1Subnetwork 2

SubDIF 3

SubDIF 4Access DIF Access DIF

InteriorRouter

Service Provider NetworksProvider 1 Network

BorderRouter

InteriorRouter

P2P DIF P2P DIF

BorderRouter

P2P DIF

InteriorRouter

P2P DIF

BorderRouter

P2P DIF P2P DIF

InteriorRouter

BorderRouter

Provider 1 Backbone DIF

P2P DIF

BorderRouter

Provider 1 Regional DIFBorderRouter

Provider 1 Metropolitan DIF

P2P DIF

InteriorRouter

P2P DIF P2P DIF

SubDIF 1

SubDIF 2 SubDIF 3

SubDIF 4 SubDIF 5

SubDIF 4

SubDIF 7

SubDIF 8Metropolitan DIF

Access DIF


100

E-mallDIF

E-mallDIF

Metropolitan DIFConnectivity graph and example policies

• Supports different “e-malls” – DIFs designed to support applications.• Organized in subDIF, each subDIF could map to a city.• Topological addressing (<city.IPCP>), link state within a subDIF. • Need to multiplex traffic from potentially very different characteristics:

need to provide multiple QoS cubes.• Strong security requirements since the DIF is exposed to customer

routers

MRBR

BR

IR

BR

BR

ISPBR

BR

BR

IRIR

BR

IR

IR

IR

MRBR

BR

BR

IR BRBR

SubDIF 3

BR

SubDIF 1

SubDIF 2

Regional DIF

E-mallDIF

E-mallDIF

E-mallDIF

E-mallDIF

E-mallDIF

E.mallDIF

IR = IPCP at Interior RouterBR = IPCP at Border Router

E-mallDIF


101

Regional DIFConnectivity graph and example policies

• Provides connectivity to the different subDIFs of the metropolitan DIF.• Organized in subDIF, each subDIF could map to a region.• Topological addressing (<region.IPCP>), link state within a subDIF.• Traffic more aggregated than in metros, still probably need to

provide support for multiple QoS cubes.

MRBR

BR

IR

BR

BR

ISPBR

BR

BR

IRIR

BR

IR

IR

IR

MRBR

BR

BR

IRMRBRBRBR

SubDIF 3

BR

SubDIF 1

SubDIF 2

Backbone DIF

MetroDIF

Metro DIF

Metro DIFMetro

DIF

MetroDIF

MetroDIF



102

Backbone DIFConnectivity graph and example policies

• Provides connectivity to the different subDIFs of the regional DIF. • Traffic is aggregated and therefore more deterministic, more

connection-oriented like resource allocation policies make sense.• Security policies can be more relaxed: all the infrastructure is in control

of the provider and not exposed outside.• Relatively small number of IPCPs: flat addressing and link-state routing

may be enough (no subDIFs).• Meshed connectivity graph.


BRBR

BR

BR

BR

BR

IR

IR

IR

IR

IR

IR

IR

RegionalDIF

RegionalDIF

RegionalDIF

RegionalDIF

RegionalDIF

RegionalDIF


103

INTERNETWORKING

How Does It Work?The Internet and ISPs

• The Internet floats on top of ISPs, a “e-mall.”– One in the seedy part of town, but an “e-mall”– Not the only emall and not one you always have to be connected to.

Public Internet

ISP 1 ISP 2 ISP 3



How Does It Work?The Internet and ISPs

• But there does not need to be ONE e-mall.– You mean!

• Yes, it is really an INTERnet!

Public Internet

ISP 1 ISP 2 ISP 3

Internet Rodeo Drive

Utility SCADAMy NetFacebook Boutique

Internet Mall of America



How Does It Work?The User’s Perspective

In this case, one host on the local network chooses to join one of the available e-malls.

e-common DIFs

Provider Network

Local Customer Network

Peering DIF

A Customer Network has a border router that makes several e-malls available. A choice can be made whether the entire local network joins, a single host or a single application.

e-common DIFs

Provider Network

Local Customer Network

Peering DIF



107

5G


Why do we have a separate mobile network architecture?

• RINA can be used to design and build mobile access networks, no need for a separate architecture– It provides an ideal framework to materialize the “5G”

concepts, unifying: fixed networks, mobile networks, wireless, virtual networks, overlays, etc.


109

BorderRouter

Service Provider NetworksExample scenario (Mobile networks)

P2P DIF

Metro DIF

Provider Fixed Network(necklace with e-mall at the top)

P2P DIF

BorderRouter

P2P DIF

Border Router

Interior Router

(Base Station)

Host (Mobile)

Multi-access DIF(radio) P2P DIF

District DIF

Metro DIF

Regional DIF

Public Internet DIF

Application-specific DIF

DAP

BorderRouter

Regional DIF

P2P DIF

Mobile Infrastructure NetworkCustomer Terminal

P2P DIF

InteriorRouter

BorderRouter

P2P DIF

Backbone DIF

Regional

Metro

District

P2P DIF

InteriorRouter


110

Radio Access DIF and District DIFExample connectivity graphs

Multi-homed host

BR

BS

H H H

BS

H

MetroDIF

MetroDIF

MetroDIF

BR

BS

H H H

BS

H

MetroDIF

MetroDIF

MetroDIF

Multi-homed host

MetroDIF

MetroDIF

MetroDIF

District DIF 1 District DIF 2

Radio DIFRadio

DIF Radio DIFRadio

DIF

DISTRICT DIF

BS = IPCP at Base Station H = IPCP at Host

BR = IPCP at Border Router

BS

H

BS

H HH

H

Multi-access DIF 1(radio) Multi-access DIF 2

(radio)

DistrictDIF

DistrictDIF

DistrictDIF

DistrictDIF

DistrictDIF

DistrictDIF

MULTI-ACCESS RADIO DIF

BS = IPCP at Base Station H = IPCP at Host


111

E-mallDIF

Metro DIF and Regional DIFExample connectivity graphs

METRO DIF

H = IPCP at HostBR = IPCP at Border Router

H H H H H

BR

H H H H H

BR

Multi-homed host

Reg.DIF

H H H HH

BR

H

DistrictDIF

DistrictDIF

DistrictDIF

BR

RegionalDIF

H

H H HH H HH H H HH H HH H H HH H HH H H HH H H

MetroDIF

BR

HH H HH H H HH H HH H H HH H HH H HH H HH

MetroDIF

BR

BRMetro DIF

(fixed)

Public Internet DIF REGIONAL DIF

H = IPCP at HostBR = IPCP at Border Router


112

Mobility, what is needed?

• Nothing new!

• Enrollment to new DIFs follows usual procedures

• Allocation of flows follows usual procedures

• Changing address of IPCPs within a DIF as they move through it as described before

• New lower layer DIFs (points of attachment) are acquired as usual

• Current points of attachment are discarded when they can no longer provide an acceptable QoS (defined per DIF)


113

QUALITY OF SERVICE, NET NEUTRALITY


114

Net neutrality (I)

• Lots of definitions, but the aim is protecting the user/consumer. As with other businesses, it should be regulated by outcomes, not trying to specify how networks should process packets.

• “All packets should be treated equal” doesn’t make sense:– Assumes all applications will have the same requirements (WRONG!

interactive vs. bulk)– Assumes all traffic is equally valid (WRONG! What about spam?)– Assumes different traffic streams are perfectly isolated (WRONG! My video

stream is your Denial of Service attack)– Assumes individual packets are significant (WRONG! Flows are what matters)

• Why on earth shouldn’t network operators be able to provide a differentiated service offering to their customers?– Do we ban airlines from providing business class?– Do we ban restaurants from serving different meals with different quality at a

different price?– Etc …



Net neutrality (II)

• What matters is that (as in any other business)– Operators have a clear service offering, based on

measurable outcomes (e.g. you will get a delay of less than 200 ms 95% of the time, and in any case no bigger than 1 s).

– Operators don’t discriminate users based on sex, religion, etc..

• But providing quality of service in the current Internet is hard.. what about RINA networks?– Next slide


Propagating QoS requirements through the layers

Host

Border router Interior Router

DIF

DIF DIF

Border router

DIFDIF

DIF

App A

The layer API is always the same (and the

same as the application API)

Application A

Layer (DIF) API

IPC Process

1. Register application

2. Allocate/Deallocate flows

3. Write data (SDUs) to flows

4. Read data (SDUs) from flows

5. Get layer information (QoS cubes, Max SDU size, etc..)

117

DEPLOYING RINA TODAY


Transition? No, Adoption

Public Internet

Rina Provider

RINA Network

RINA ApplicationsRINA supported Applications

• Adopt. Don’t transition. – If the old stuff is okay in the Internet e-mall, leave it there.– Do the new capabilities in RINA

• Operate RINA over, under, around and through the Internet.– The Internet can’t be fixed, but it will run better over RINA.– New applications and new e-malls will be better without the legacy and

run better along side or over the Internet.• The Microsoft Approach or the Apple approach?

– Microsoft tried to prolong the life of DOS. It still haunts them.

• A clean break with the past. The legacy is just too costly.• We need engineering based on science, not myth and tradition.


119

Shim DIFsGeneral requirements

• The task of a shim DIF is to put a small as possible veneer over a legacy protocol to allow a RINA DIF to use it unchanged.

• The shim DIF should provide no more service or capability than the legacy protocol provides.


Shim DIF over 802.1QEnvironment

• (Disclaimer: Other shim DIFs over Ethernet are possible: with no VLANs; using LLC; over carrier Ethernet; …)

• A shim DIF over Ethernet maps to a VLAN– The DIF name is the VLAN name

• The shim DIF only supports on class of service: unreliable

• ARP can be used to map upper layer IPC Process names to shim DIF addresses (MAC addresses)


Shim DIF over Ethernet

Ethernet II PCI Application data

121

Shim DIF over TCP/UDP

• Wraps an IP network with the DIF IPC API

• Two QoS cubes possible: reliable and in-order-delivery of flows (TCP), unreliable (UDP)

– More could be possible depending on the capabilities of the underlying IP network

• IPCP name is mapped to an IP address and a port number– Using proprietary procedures or leveraging DNS (via SRV records)

IPCP a.1

IPCP b.1

Shim DIF over IP networks

IP layer

UDP Port:2524UDP Port:2524

Shim IPCP X.1

Shim IPCP Y.1

IP: 4.3.2.1 IP: 5.3.5.8

2 5

Flow


122

RINA under IP

• RINA-based ISP, internal layers are RINA, can transport IP (can be treated as just another app) and/or other DIFs.

• Almost all routing is done in RINA layers. From the IP layer perspective, the ISP is a single hop– Directly connects access routers between them or with border

routers

App

Customer network Home router

Regional DIF

ISP access router

Shim DIF

Shim DIF

Shim DIF

Shim DIF

Backbone DIF

Regional router

Regional-bacbone border router

Backbonerouter

ISP border router (runs BGP sessions with peers)

Customer network is not RINA enabled

Public Internet layer (IP)

Data transfer/control: TCP/IP Layer management: ICMP, BGP, etc…

Access network layer (e.g Ethernet)

AS-to-AS layer(e.g Ethernet)

Peer AS is not RINA-enabled


123

Faux sockets APIAn aid to adoption

• Sockets API implementation that internally maps sockets API calls to RINA IPC API calls– Allows applications to be deployed over RINA networks

unchanged (won’t leverage the full RINA benefits)

• Mapping– Need to map hostnames and transport ports to RINA names

• Applications that pass IP addresses are more problematic to support

– Binding a socket = Registering an application to a DIF• Single DIF vs. Multiple DIFs

– Connecting a socket = Allocating a flow to a destination app• No need to perform DNS lookup since names are resolved by DIFs

– Accepting incoming connections = Accepting incoming flows

– Read/write to a socket = Read/write to a flow

– Closing a socket = Deallocating a flowRINA Tutorial to the EC


RINA STATUS, HOW CAN THE EC HELP MOVE RINA FORWARD?

4

T-5 Alternatives to TCP/IP 125

RINA state of the art

• Draft RINA reference model and specifications

• Theoretical and experimental research on RINA properties (using FIRE, GENI, particular testbeds)– BU John Day’s team– EC projects: FP7 IRATI, FP7 PRISTINE, G3+ OC winner IRINA

• Open source implementations– IRATI (FP7 IRATI, FP7 IRINA, FP7 PRISTINE)– protoRINA– RINAsim (a simulator under development by FP7 IRATI)

• PSOC (Pouzin Society): coordination of international R&D activities, maintenance of draft reference model and specifications

126

Flow of RINA R&D activities

Prototyping & ToolDevelopment

Different Platforms

Java VM

Linux OS

Android OS

NetFPGA

Coexisting with

different technologies

TCP/UDP/IP

VLANs

WiFi

LTEMPLS

Prototypes & Tools

Tools

Test apps

Prot. analyz

SDKs

Research on RINA

reference model

Core RINA specs

Research on policies for

different areas

Data transfer

Management

Security

Routing Resource allocation

Enrollment

Application discovery

MultiplexingDIF

creation

Policy specs

Design and development of

simulators

Simulators

Study different use cases and deployment

options

Use case analy

sis

Experimentation and validation

Data and

conclusions

New Insights &

Invariances


IRATI @ a Glance

• What? Main goals– To advance the state of the art of RINA towards an architecture

reference model and specifications that are closer to enable implementations deployable in production scenarios.

– The design and implementation of a RINA prototype on top of Ethernet will enable the experimentation and evaluation of RINA in comparison to TCP/IP.

Budget

Total Cost 1.126.660 €

EC Contribution 870.000 €

Duration 2 years

Start Date 1st January 2013

External Advisory Board

Juniper Networks, ATOS, Cisco Systems, Telecom Italia

5 activities:

WP1: Project management

WP2: Arch., Use cases and Req.

WP3: SW Design and Implementation

WP4: Deployment into OFELIA

WP5: Dissemination, Standardisation and Exploitation

Who? 5 partners

127

From 2014

128

IRATI contributions to RINA roadmap

• Reference model and core specifications– Detect inconsistencies and errors

• Research on policies for different areas– Routing (link-state), Shim DIF over Ethernet VLANs (802.1q), shim DIFs for

Hypervisors, Faux sockets API

• Use cases– Corporate VPNs and VM networking

• Prototyping– Initial implementation for Linux OS (user-space and kernel)

• Experimentation– First experimental analysis of RINA against TCP/IP in similar conditions

(focusing in LAN environments)

PRISTINE @ a Glance

• What? Main goals– To design and develop an SDK for the IRATI RINA prototype, to unleash the

programmability provided by RINA.

– To use the SDK to design, implement and trial a set of a policies to create optimized DIFs for different use cases: distributed cloud, datacenter networking and network service provider.

– To design and implement the first RINA multi-layer management system.

Budget

Total Cost 5.034.961 €

EC Contribution 3.337.000 €

Duration 2.5 years

Start Date 1st January 2014

External Advisory Board

Cisco Systems, Telecom Italia, Deutsche Telekom, Colt Telecom, BU, Interoute

7 activities: WP1: Project management

WP2: Use cases, req. analysis and programmable reference architecture

WP3: Programmable performance-enhancing functions and protocols

WP4: Innovative security and reliability enablers

WP5: Multi-layer management plane

WP6: System-level integration, validation, trials and assessment

WP7: Dissemination, standardisation and exploitation

Who? 15 partners

WIT-TSSG, i2CAT, TID, Ericsson, NXW, Thales, Nexedi, Atos, BISDN, Juniper, Telecom SudParis, U Brno, UiO, CREATE-NET, iMinds

130

PRISTINE contributions to RINA roadmap• Reference model and core specifications

– Detect inconsistencies and errors

• Research on policies for different areas– Congestion control, distributed resource allocation, addressing, routing,

authentication, access control, encryption, DIF management

• Use cases– Decentralized cloud, DC networking, network service provider

• Prototyping– Build on IRATI implementation for Linux OS. Develop SDK to allow easier

customization, develop sophisticated policies with SDK. Prototype first DIF Management System

• Simulators– Development of a RINA simulator, based on OMNeT++

• Experimentation– More realistic experimentation, with more complex deployments, coexisting

with several technologies at once (IPv4, IPv6, Ethernet)

131

IRINA @ a glance

• What? Main goals

– To make a study of RINA against the current networking state of the art and the most relevant clean-slate architectures under research.

– To perform a use-case study of how RINA could be better used in the NREN scenario, and showcase a lab-trial of the use case

– To involve the NREN and GEANT community in the different steps of the project, in order to to get valuable feedback

Budget

Total Cost 199.940 €

EC Contribution 149.955 €

Duration 18 months

Start Date 1st November 2013

5 activities: WP1: Technical coordination and

interaction with GEANT3+

WP2: Comparative analysis of network architectures

WP3: Use case study and lab trials

WP4: Dissemination and workshop organization

Who? 4 partners

132

IRINA contributions to RINA roadmap

• Reference model and core specifications– Compare with other architectures

• Use cases– Research network operators (NRENs and GEANT environment)

• Prototyping– Little adaptations to the IRATI prototype (Linux OS), to be able to

trial the use case in the lab

• Experimentation– Focus on the requirements of NRENs

133

Open source IRATI

• IRATI github side• http://irati.github.io/stack

• Hosts code, docs, issues• Installation guide• Experimenters (tutorials)

• Developers (software arch)

• Mailing list for users and developers• [email protected]

• Procedures to contribute under discussion, doc ongoing


How could the EC contribute? (I)

• In general– Get more informed on RINA and potential impacts. Don’t believe

it: understand it!– Consider motivating research on RINA by including it as a

relevant item in future work programmes– Europe can lead this networking and distributed computing

revolution this time! (unlike with the Internet or SDN)

• FIRE– A RINA testbed to do research in networking would facilitate

spreading the technology and its concepts among academics, research centres, SMEs and industry

• 5G– RINA provides the perfect foundation to support the

requirements of the 5G vision (blog post by ICT pristine)

1

2

3


How could the EC contribute? (II)

• Operating Systems Research– Recursive Operating Systems would also simplify current

OSs, making them more flexible and robust (recursion as opposed to virtualization)

• Distributed applications research– The DAF model provides a generic framework that would

speed up the development of robust and flexible distributed applications

4

5

Thanks for your attention!ict-pristine.eu

pouzinsociety.org@ictpristine

@iratiproject

Reconstructing computer networking with RINA: how solid scientific foundations can allow Europe to...

Internet

Transcript of Reconstructing computer networking with RINA: how solid scientific foundations can allow Europe to...