Architectures and buildings

NETWORK ARCHITECTURES AND NETWORK BUILDINGS
Eduard Grasa on behalf of i2CAT, Waterford Institute of Technology, Boston
University
December 14th 2016
© ETSI 2014. All rights reserved

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
© ETSI 2014. All rights reserved2

Example: gothic architecture
City Hall
Palace
Cathedral Fish market
City gates

Example: modernist architecture
Houses Hotels Cathedrals
Parks
Music Halls

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..)

NET ARCHITECTURE 1: LAYERING
6 © ETSI 2014. All rights reserved

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 Link
MAC
Application
Transport
LLC
Physical
Internet (theory)
MAC
Internet
Data Link
and others
and others
For cellular
networks
Data Link

Layering architecture (I)
Internet (theoretical model)
Host Router Router Border
Router
Router Router HostBorder
Router
Physical Physical Physical Physical Physical Physical Physical
LLC/MACLLC/MACLLC/MACLLC/MACLLC/MACLLC/MACLLC/MAC
Internet
Transport
Network 1 Network 2
OSI model
Router
Router
Physical Physical Physical Physical Physical Physical Physical
LLC/MACLLC/MACLLC/MACLLC/MACLLC/MACLLC/MACLLC/MAC
Transport
Network 1 Network 2
SNAC
SNDC
SNAC
SNDC
SNIC
Application
Application

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

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

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)

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.
Router
Router
Network 1 Network 2
SNAC
SNDC
SNIC
Application
Generic
Layer
Generic
Layer
Generic
Layer
Generic
Layer
Generic
Layer
Generic
Layer
Generic
Layer
Generic Layer Generic Layer
Generic Layer

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?

NET ARCHITECTURE 2: STRUCTURE OF A LAYER

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

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?

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.

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)

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?

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

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

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)

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

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..)

CONCLUDING

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

Architectures and buildings

Related slideshows

More Related Content

Architectures and buildings