Architectures and buildings

NETWORK ARCHITECTURES AND NETWORK BUILDINGS

Eduard Grasa on behalf of i2CAT, Waterford Institute of Technology, Boston UniversityDecember 14th 2016

© ETSI 2014. All rights reserved

2

What is an architecture?

“The style of design and method of construction of buildings and other physical structures”

Architecture provides a set of patterns and methodology that guides building designers in carrying out their task

The same architecture is used to design many different buildings with different requirements• Architecture captures the rules and patterns that are invariant with

respect to the specific requirements of each buildings


3

Example: gothic architecture


City Hall

Palace

Cathedral Fish market

City gates

4

Example: modernist architecture

© ETSI 2014. All rights reservedHouses Hotels Cathedrals

Parks

Music Halls

5

One of the NGP’s goal should be to…

Identify a set of architectural patterns and invariants in network protocols, as well as a methodology that allows network designers and SDOs (IETF, IEEE, 3GPP, etc..) to construct better network buildings

Design a few “demonstration” protocols using these patterns and methodology for a few environments (5G, datacentre, IoT, etc) • Just as examples and tutorials on how to use the architectural patterns.

Real protocols for production environments should be designed by corresponding SDOs (e.g. 3GPP for mobile networks, etc..)


6

NET ARCHITECTURE 1: LAYERING


7

Let’s go back to networks

Today, what is the architecture of our networks? What are the patterns that guide network protocol designers doing their job?

Layering: Network buildings more or less based on OSI reference model…


Application

Presentation

Session

Transport

Network

Physical

OSI (Initial)

Application

Transport

Network

LLC

Physical

OSI (Final)

SubNet Indep. C.

SubNet Dep. C.

SubNet Access

Data LinkMAC

Application

Transport

LLC

Physical

Internet (theory)

MAC

Internet

Data Link

and others

and others

For cellularnetworks

Data Link

8

Layering architecture (I)

Internet (theoretical model)


Host Router Router BorderRouter

Router Router HostBorderRouter

Physical Physical Physical Physical Physical Physical PhysicalLLC/MACLLC/MACLLC/MACLLC/MACLLC/MACLLC/MACLLC/MAC

Internet

Transport

Network 1 Network 2

OSI model



Physical Physical Physical Physical Physical Physical PhysicalLLC/MACLLC/MACLLC/MACLLC/MACLLC/MACLLC/MACLLC/MAC

Transport

Network 1 Network 2

SNACSNDC

SNACSNDC

SNIC

Application

Application

9

Layering architecture: problems (I)

Internet architecture does not have room for different network protocols (there is a common Internet layer directly over data link layers)

If a network wants to do its own non-IP forwarding, or do IP forwarding but hide internal routers from the Internet, ad-hoc extensions are required:• “Layers 2.5” -> MPLS• Tunnelling protocols -> e.g. GTP for mobile networks, IP-in-IP tunnelling

protocols, MAC-in-MAC, etc.. (every SDO designing its ad-hoc solution(s) for its problem domain, independently)

Note that this was already covered in the OSI architecture by SNDC and SNAC


10

Layering architecture: problems (II)

Fixed number of layers, sometimes more needed between transport and application (that is both for OSI and Internet)• Need to have concepts such as “overlay”, “VPN”, “virtual networks”,

etc.. -> Protocols such as LISP, VXLAN, NVGRE

Although the need for scope is clear (link, network, Internet, VPN …) layers are organised as units of modularity, with each layer providing a different function to each other• Hard to extract invariances and provide a “closed model” that avoids

proliferation of layers and protocols• Functions in different layers of the same scope usually need to know

about each other to work properly (one of the reasons for “layering considered harmful”)

Conclusion: the layering architecture is broken and doesn’t help network designers, who instead battle with it © ETSI 2014. All rights reserved

11

Layering: a better pattern (I)

Treat layers as units of resource allocation that provide the same service (distributed IPC) over different scopes. The fact that networking provides a distributed IPC service was well recognised since the beginning …

“Networking is Interprocess Communication” Bob Metcalfe (1972)“I believe it is natural to think of resources as being associated with processes<1> and available only through communication with these processes. Therefore, I view the fundamental problem of resource sharing to be the problem of interprocess communication. I also share with Carr, Crocker, and Cerf [2] the view that interprocess communication over a network is a subcase of general interprocess communication in a multi-programmed environment”. D.C. Walden (RFC 62 https://tools.ietf.org/html/rfc62, 1970)“End-to-end protocols (often called "Host-Host" protocols) are installed on top of the packet switching service to provide users with an interprocess communication facility. “ Cerf, McKenzie, Zimm. (INWG96 http://dotat.at/tmp/INWG-96.pdf, 1974) “...Thus, all communication is viewed as interprocess communication“.DARPA (RFC 793, TCP spec https://tools.ietf.org/html/rfc793, 1981)


https://tools.ietf.org/html/rfc62


http://dotat.at/tmp/INWG-96.pdf

http://dotat.at/tmp/INWG-96.pdf



Layering, a better pattern (II)

Single type of layer, providing an IPC Service that repeats as many times as needed by the network designer• IPC service allocates flows between processes, with specific properties

(delay, loss, in-order-delivery, capacity, etc.)

A layer is a resource allocator that provides an manages the IPC service over a given scope (link, network, Internet, VPN, etc.). A layer allocates resources (memory in buffers, scheduling capacity, bandwidth) to competing flows.

© ETSI 2014. All rights reserved12



Network 1 Network 2

SNACSNDC

SNIC

Application

GenericLayer

GenericLayer

GenericLayer

GenericLayer

GenericLayer

GenericLayer

GenericLayer

Generic Layer Generic Layer

Generic Layer

13

Layering: solutions

Number and scope of layers is not decided by architecture but by the network designer: use the best number for each building

Invariant structure with respect to the type of network being designed: the repeating building block with a consistent service interface (IPC) helps network designers to bound structural complexity

We still face the problem of what is the internal structure of such a generic IPC layer? How many protocols? How do they look like? Are there invariants we can extract to further simplify and streamline the process of network design?


14

NET ARCHITECTURE 2: STRUCTURE OF A LAYER


15

Protocol proliferation

Multiple types of layers providing different functions, each type of layer with multiple protocols to carry out these functions, with protocols independently designed from scratch by different SDOs (even within the same SDO) means problems


16

Protocol proliferation: problems

Proliferation of independently designed protocols leads to duplication of standards, complexity, unforeseen interactions between protocols, a network more complicated to understand, operate and troubleshoot, etc … operator costs go up and network reliability goes down

Even if this is the landscape, can we see some structure or invariant elements within a layer?


17

Layer structure today (I)

Each layer performs a number of distributed functions coordinated via network protocols, which can be categorised:

• Data transfer (or data plane) functions. The functions that are associated to every single packet (PDU), such as multiplexing, scheduling, forwarding, addressing, concatenation, fragmentation, sequencing, encryption, etc..

• Data transfer control (or also data plane) functions. Feedback functions that are loosely associated to the data transfer ones, such as flow control, congestion control or retransmission control.

• Layer management (or control plane) functions. Functions to manage the functioning of a layer, not directly associated to the data of the layer users, such as: authentication, access control, routing, resource allocation, security management.


18

Layer structure today (II)

In IEEE protocols usually this functional split is very clean, with layer management and data transfer protocols in the same layer (e.g. IEEE 802.11)

IETF usually has control plane and data plane protocols in different layers • According to the model BGP is actually an “application protocol” –

works over transport – controlling the routing in the Internet layer• According to the model OSPF is a “transport protocol” – works over

“Internet” – controlling the routing in the Internet layer

3GPP also uses a similar approach to IETF (calling the two types user plane and control plane protocols)


19

Layer structure: a better pattern

Propose to use the clean model of IEEE (data transfer and layer management protocols operating in the same layer), but go one step further.

Given the fact that we have generic IPC layers that perform the same functions (over different scopes), can we reduce the number of required protocols to the bare minimum?

Each layer has different requirements, so we cannot have the same protocols in all of them, but can we abstract invariances so that we end up with:• 1 protocol (framework) for data transfer?• 1 protocol (framework) for layer management?


20

Layer structure: a better pattern (II)

Yes we can! One of the main results discussed in Patterns in Network Architecture (PNA), later formalised in RINA.• PNA/RINA only proof this is possible and show a way of arriving to the

result. If others propose simpler frameworks with the same capabilities we should definitely go for them.

By separating data transfer protocol elements between mechanism (invariant) and policy (variant), it is possible to specify a data transfer protocol framework from which multiple data transfer protocols can be generated by• Choosing a concrete syntax (length of PCI fields)• Plugging in the right policies

See EFCP specification for an example of such protocol framework© ETSI 2014. All rights reserved

21

Unified data transfer protocol benefits

Reduce the number of data transfer protocols to a few (maybe 10 or so?), all sharing the same abstract syntax and the same mechanisms• Much easier to specify, implement and debug

Networks become much easier to understand, manage and troubleshoot -> cheaper to operate and more reliable

Innovation becomes much easier -> don’t need to design and implement full-fledged protocols, just new policies • E.g. almost all TCP variants are just a little change in the congestion

control policy• We can share some work done on PRISTINE to understand what it

means to specify/develop this data transfer policies© ETSI 2014. All rights reserved

22

Layer structure: unified layer management

The BGP example being an application protocol is a good clue towards seeing a simplifying pattern: layers are distributed applications that perform and manage IPC• Members of a layer need an application protocol to exchange layer

management information and operate on each other

Layer management functions benefit from a common application protocol that allows them to exchange information, and a generic “distributed memory manager” that distributes and makes information available as needed• 80% of what routing protocols do is managing a distributed database

of <routing> information, which has nothing to do with routing per se• Some have already identified this and are trying to generalize

“routing” implementations (e.g. Facebook Open/R)© ETSI 2014. All rights reserved

23

Example of unified layer management infrastructure: RINA


Resource Information Base (RIB): Schema that defines the external representation of the set of objects that model the state of the IPCP (object names, attributes, relationships, allowed CDAP operations and their effects)

Common Distributed Application Protocol (CDAP): Application protocol that allows two applications to operate on the objects of each other’s RIB. Provides 6 operations (create/delete/read/write/start/stop).

RIB Daemon: Entity that processes incoming CDAP messages (delegating RIB operations to layer mgmt tasks) and generates outgoing CDAP messages from layer management tasks’ requests

24

Benefits of unified layer management framework

Only need one common layer management protocol for all layers, which allows layer management functions to remotely operate on objects (which model the function’s externally visible state)

Only need one common distributed memory/database manager for layer management functions• With pluggable replication policies (on demand, event-based, periodic, etc..)

Layer management functions just need to specify an object schema, and the behaviour when the common protocol operations are invoked on the objects

This is a huge reduction in network complexity, coming from a world were every single layer management/control plane function has one or more standalone protocols, independently designed (ICMP, RSVP, OSPF, RIP, BGP, IS-IS, ARP, DNS, etc..)© ETSI 2014. All rights reserved

25

CONCLUDING


26

Conclusions

There’s still much more to discuss: naming and addressing architecture (in the context of the generic layer and generic protocols), security, QoS, network management, etc..

Maximizing commonality (invariances) in a common network protocol architecture that all SDOs use to develop complete network protocols for their problem domain(s) is the only way to bound complexity and avoid an explosion in the proliferation of network protocols
