Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
NETWORK ARCHITECTURES AND NETWORK BUILDINGS
Eduard Grasa on behalf of i2CAT, Waterford Institute of Technology, Boston
Uni...
What is an architecture?
“The style of design and method of construction of buildings
and other physical structures”
Archi...
Example: gothic architecture
© ETSI 2014. All rights reserved3
City Hall
Palace
Cathedral Fish market
City gates
Example: modernist architecture
© ETSI 2014. All rights reserved4
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 ...
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 protoc...
Layering architecture (I)
Internet (theoretical model)
© ETSI 2014. All rights reserved8
Host Router Router Border
Router
...
Layering architecture: problems (I)
Internet architecture does not have room for different network
protocols (there is a c...
Layering architecture: problems (II)
Fixed number of layers, sometimes more needed between
transport and application (that...
Layering: a better pattern (I)
Treat layers as units of resource allocation that provide the
same service (distributed IPC...
Layering, a better pattern (II)
Single type of layer, providing an IPC Service that repeats as
many times as needed by the...
Layering: solutions
Number and scope of layers is not decided by architecture but
by the network designer: use the best nu...
NET ARCHITECTURE 2: STRUCTURE OF A LAYER
14 © ETSI 2014. All rights reserved
Protocol proliferation
Multiple types of layers providing different functions, each type
of layer with multiple protocols ...
Protocol proliferation: problems
Proliferation of independently designed protocols leads to
duplication of standards, comp...
Layer structure today (I)
Each layer performs a number of distributed functions
coordinated via network protocols, which c...
Layer structure today (II)
In IEEE protocols usually this functional split is very clean, with
layer management and data t...
Layer structure: a better pattern
Propose to use the clean model of IEEE (data transfer and layer
management protocols ope...
Layer structure: a better pattern (II)
Yes we can! One of the main results discussed in Patterns in
Network Architecture (...
Unified data transfer protocol benefits
Reduce the number of data transfer protocols to a few
(maybe 10 or so?), all shari...
Layer structure: unified layer management
The BGP example being an application protocol is a good clue
towards seeing a si...
Example of unified layer management
infrastructure: RINA
© ETSI 2014. All rights reserved23
Resource Information Base (RIB...
Benefits of unified layer management framework
Only need one common layer management protocol for all layers,
which allows...
CONCLUDING
25 © ETSI 2014. All rights reserved
Conclusions
There’s still much more to discuss: naming and addressing
architecture (in the context of the generic layer an...
Upcoming SlideShare
Loading in …5
×

Architectures and buildings

100 views

Published on

Network architectures vs. network protocols

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Architectures and buildings

  1. 1. 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
  2. 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 © ETSI 2014. All rights reserved2
  3. 3. Example: gothic architecture © ETSI 2014. All rights reserved3 City Hall Palace Cathedral Fish market City gates
  4. 4. Example: modernist architecture © ETSI 2014. All rights reserved4 Houses Hotels Cathedrals Parks Music Halls
  5. 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..) © ETSI 2014. All rights reserved5
  6. 6. NET ARCHITECTURE 1: LAYERING 6 © ETSI 2014. All rights reserved
  7. 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… © ETSI 2014. All rights reserved7 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
  8. 8. Layering architecture (I) Internet (theoretical model) © ETSI 2014. All rights reserved8 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 Host Router Router Border Router Router Router HostBorder 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
  9. 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 © ETSI 2014. All rights reserved9
  10. 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 reserved10
  11. 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) © ETSI 2014. All rights reserved11
  12. 12. 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 Host Router Router Border Router Router Router HostBorder 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
  13. 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? © ETSI 2014. All rights reserved13
  14. 14. NET ARCHITECTURE 2: STRUCTURE OF A LAYER 14 © ETSI 2014. All rights reserved
  15. 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 © ETSI 2014. All rights reserved15
  16. 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? © ETSI 2014. All rights reserved16
  17. 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. © ETSI 2014. All rights reserved17
  18. 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) © ETSI 2014. All rights reserved18
  19. 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? © ETSI 2014. All rights reserved19
  20. 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 reserved20
  21. 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 reserved21
  22. 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 reserved22
  23. 23. Example of unified layer management infrastructure: RINA © ETSI 2014. All rights reserved23 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. 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 reserved24
  25. 25. CONCLUDING 25 © ETSI 2014. All rights reserved
  26. 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 © ETSI 2014. All rights reserved26

×