|
GROUP REPORT
Next Generation Protocols (NGP);
An example of a non-IP network protocol architecture
based on RINA design principles
Disclaimer
The present document has been produced and approved by the Next Generation Protocols (NGP) ETSI Industry Specification
Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.
---------------------- Page: 1 ----------------------
2 ETSI GR NGP 009 V1.1.1 (2019-02)
Reference
DGR/NGP-009
Keywords
API, architecture, internet, meta-protocol,
network, next generation protocol, protocol
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
The present document can be downloaded from:
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
If you find errors in the present document, please send your comment to one of the following services:
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© ETSI 2019.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners.
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
---------------------- Page: 2 ----------------------
3 ETSI GR NGP 009 V1.1.1 (2019-02)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 11
3.1 Terms . 11
3.2 Symbols . 13
3.3 Abbreviations . 13
4 Overview and motivation . 15
4.1 What does the present document mean by "network protocol architecture"? . 15
4.2 What is the current network protocol architecture? . 16
4.3 Summary of current issues at the network protocol architecture level . 16
4.3.1 Structure . 16
4.3.2 Protocol design . 17
4.3.3 Naming, addressing and routing . 18
4.3.4 Mobility and multi-homing . 18
4.3.5 Quality of Service, resource allocation, congestion control . 18
4.3.6 Security . 19
4.3.7 Network Management . 19
4.4 Goals for a generic network protocol architecture . 20
5 Structure . 21
5.1 A network service definition . 21
5.2 Networks and distributed computing . 22
5.3 A repeating structural pattern: recursive Distributed IPC Facilities (DIFs) . 22
5.4 Examples of DIF configurations . 24
5.4.0 Introduction. 24
5.4.1 Virtual Private LAN Service (VPLS) . 25
5.4.2 LTE Evolved Packet System (EPS) User Plane . 26
5.4.3 Multi-tenancy Data Centre . 27
5.5 Summary of RINA structural properties . 27
6 Generic protocol frameworks . 28
6.1 Internal structure of an IPC Process . 28
6.2 Data transfer: functions, protocols and procedures . 30
6.2.1 Introduction. 30
6.2.2 DTP PDU abstract syntax . 30
6.2.3 DTCP PDU Formats . 30
6.2.4 Overview of data-transfer procedures . 31
6.3 Layer management: protocol, functions and procedures . 32
6.3.1 Introduction. 32
6.3.2 Layer management functions: enrollment . 32
6.3.3 Layer management functions: namespace management . 33
6.3.4 Layer management functions: flow allocation . 33
6.3.5 Layer management functions: resource allocation . 34
6.3.6 Layer management functions: routing . 34
6.3.7 Layer management functions: security coordination . 34
6.4 Summary of RINA protocol framework design principles . 34
7 Naming and addressing . 35
7.1 Names in RINA and their properties . 35
ETSI
---------------------- Page: 3 ----------------------
4 ETSI GR NGP 009 V1.1.1 (2019-02)
7.2 Implications for multi-homing . 36
7.3 Implications for renumbering . 38
7.4 Implications for mobility . 40
7.5 Summary of RINA architectural properties relevant to naming, addressing and routing . 43
8 QoS, Resource Allocation and Congestion Control . 44
8.1 Consistent QoS model across layers . 44
8.2 Resource Allocation . 45
8.3 Congestion control . 46
8.4 Summary of RINA design principles relevant to QoS, Resource Allocation and Congestion Control . 47
9 Security. 48
9.1 Introduction . 48
9.2 Securing DIFs instead of individual protocols . 48
9.3 Recursion allows for isolation and layers of smaller scope . 50
9.4 Separation of mechanism from policy . 50
9.5 Decoupling of port allocation from synchronization . 51
9.6 Use of a complete naming and addressing architecture . 52
9.7 Summary of RINA design principles relevant to security . 52
10 Network Management . 53
10.1 Common elements of a management framework . 53
10.2 Managing a repeating structure . 55
10.3 Summary of RINA design principles relevant to Network Management . 56
11 Deployment considerations . 56
11.1 General principles. 56
11.1.1 Supporting applications . 56
11.1.2 Overlays: shim DIFs . 57
11.1.3 DIFs as a multi-protocol transport (IP, Ethernet, etc.) . 58
11.1.4 Transport layer gateways . 58
11.2 Example interoperability scenarios . 59
11.2.1 Datacentre networking . 59
11.2.2 Communication/Internet Service Provider . 60
11.2.3 Software-Defined WAN (SD-WAN) . 61
Annex A: Authors & contributors . 63
Annex B: Change History . 64
History . 65
ETSI
---------------------- Page: 4 ----------------------
5 ETSI GR NGP 009 V1.1.1 (2019-02)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Next Generation Protocols
(NGP).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Introduction
Network protocol architecture provides a set of patterns and methodology that guides network (protocol) designers in
carrying out their task. It captures the rules and patterns that are invariant with respect to the specific requirements of each
individual network (cellular, datacentre, sensor, access, core, enterprise, LAN, etc.). Today the prevalent network
protocol architecture (usually referred to as "Internet protocol suite"), loosely based on OSI provides too little patterns
and commonality and has fundamental design flaws in its structure, naming and addressing, service API and security.
These issues contribute to an explosion in the number of the network protocols required, both to cover requirements of
multiple use cases and to work around the fundamental design flaws.
The Recursive InterNetwork Architecture (RINA) is a "back to basics" approach learning from the experience with
TCP/IP and other technologies in the past. Research results to date have found that many long-standing network problems
can inherently be solved by the structure resulting from the theory of networking. Hence, additional mechanisms are not
required.
ETSI
---------------------- Page: 5 ----------------------
6 ETSI GR NGP 009 V1.1.1 (2019-02)
RINA provides the adequate tools to solve the problems of the Internet architecture (complexity, scalability, security,
mobility, quality of service or management to name a few). RINA is based on a single type of layer, which is repeated
as many times as required by the network designer. The layer is called a Distributed IPC Facility (DIF), which is a
distributed application that provides Inter Process Communication (IPC) services over a given scope to the distributed
applications above (which can be other DIFs or regular applications). These IPC services are defined by the DIF API,
which allows instances of applications -including other DIFs- to request IPC flows with certain characteristics (such as
loss, delay, in-order delivery) to other application instances. Hence a layer can is a resource allocator that provides and
manages the IPC service oven a given scope (link, network, internetwork, VPN, etc.). It allocates resources (memory in
buffers, bandwidth, scheduling capacity) to competing flows.
All DIFs offer the same services through their API and have the same components and structure. Each layer features
two sets of protocol frameworks: one for data transfer (called EFCP, Error and Flow Control Protocol), and one for
layer management (CDAP, the Common Distributed Application Protocol). However, not all the DIFs operate over the
same scope and environment nor do they have to provide the same level of service. Hence, invariant parts (mechanisms)
and variant parts (policies) are separated in different components of the data transfer and layer management protocol
frameworks. This makes it possible to customize the behaviour of a DIF to optimally operate in a certain environment
with a set of policies for that environment instead of the traditional "one size fits all" approach or having to re-
implement mechanisms in independent protocols over and over again.
Last but not least, RINA can be deployed incrementally where it has the right incentives, and interoperate with current
technologies such as IP, Ethernet, MPLS, WiFi, Cellular or others.
ETSI
---------------------- Page: 6 ----------------------
7 ETSI GR NGP 009 V1.1.1 (2019-02)
1 Scope
Today most network protocols loosely follow the layering structure of the OSI network architecture. Protocols are
organized in a static number of layers, in which each layer provides a different function to the layer above. The
limitations of such structure have led to an explosion in the number of protocols at each layer with little or no
commonality, layer violations and the need for ad-hoc extensions in the number of layers where the architecture could
not model real-world networks with enough fidelity (e.g. layers 2,5 or 3,5, virtual networks, etc.). SDOs independently
develop protocols for different layers of the protocol architecture, many times replicating each other's work and leading
to inefficiencies at the system level. This results in:
a) networks that are highly complex to operate and troubleshoot;
b) specification and implementation of new protocols which add little value to the existing base; and
c) an overall networked system that is far from an optimal integration level from a systems design perspective.
The present document discusses the properties of a non-IP network architecture based on RINA design principles.
Network architecture captures all the rules and patterns that are independent of the requirements addressed by
individual network protocols. It solves the problems that are generic to any network (e.g. structure, naming and
addressing, security models or QoS) at the architecture level, avoiding the need for individual protocols to solve these
problems by themselves. RINA has been designed to capture the invariants of all forms of networking, providing SDOs
and network designers with a common framework and methodology to design and build protocols for any type of
network. Thus a network protocol architecture like RINA encourages networks with fewer protocols and more
commonality, more cooperation between SDOs and simpler and more predictable networks.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] IETF RFC 62: "A System for Inter-Process Communication in a Resource Sharing Network",
August 1970, D.C. Walden.
NOTE: Available at https://tools.ietf.org/rfc/rfc62.txt.
[i.2] INWG-96 (1975): "Proposal for an International End To End Protocol", V. Cerf, A. McKenzie, R.
Scantleburie, H. Zimmerman.
NOTE: Available at http://dotat.at/tmp/INWG-96.pdf.
[i.3] IETF RFC 793: "Transmission Control Protocol", September 1981, University of Southern
California.
NOTE: Available at https://tools.ietf.org/html/rfc793.
ETSI
---------------------- Page: 7 ----------------------
8 ETSI GR NGP 009 V1.1.1 (2019-02)
[i.4] ETSI GS NGP 007: "Next Generation Protocols (NGP); NGP Reference Model".
NOTE: Available at
https://www.etsi.org/deliver/etsi_gs/NGP/001_099/007/01.01.01_60/gs_NGP007v010101p.pdf.
[i.5] ISO/IEC 7498-1:1994: "Information technology -- Open Systems Interconnection -- Basic
Reference Model: The Basic Model".
[i.6] IETF draft-ietf-taps-arch-02: "An Architecture for Transport Services", January 2018, T. Pauly,
B. Trammell, A. Brunstrom, G. Fairhurst, C. Perkins, P. Tiesel, C. Wood.
NOTE: Available at https://datatracker.ietf.org/doc/draft-ietf-taps-arch/?include_text=1.
[i.7] P. B. Hansen: "The Nucleus of a Multi Programming System", Communications of the ACM 13
(4): 238-241. April 1970.
NOTE: Available at https://dl.acm.org/citation.cfm?id=362278&dl=ACM&coll=GUIDE.
[i.8] J. Day: "Patterns in Network Architecture: A return to Fundamentals". Prentica Hall, 2008.
[i.9] R. Watson: "Timer-based mechanism in reliable transport protocol connection management",
Computer Networks, 5:47-56, 1981.
[i.10] G. Gursun, I. Matta and K. Mattar: "On the Performance and Robustness of Managing Reliable
th
Transport Connections", 8 International Workshop on PFLDNeT, November 2010.
[i.11] G. Boddapati, J. Day, I. Matta, L. Chitkushev: "Assessing the security of a clean-slate Internet
th
architecture", 20 IEEE conference on Network Protocols, 2012.
[i.12] E. Grasa, O. Rysavy, O. Lichtner, H. Asgari, J. Day, L. Chitkushev: "From protecting protocols to
protecting layers: designing, implementing and experimenting with security policies in RINA",
IEEE ICC 2016.
[i.13] IETF RFC 4291: "IPv6 addressing architecture", February 2006, R. Hinden, S. Deering.
NOTE: Available at https://tools.ietf.org/html/rfc4291.
[i.14] IETF RFC 4192: "Procedures for renumbering an IPv6 network without a flag day",
September 2005, F. Baker, E. Lear, and R. Droms.
NOTE: Available at https://tools.ietf.org/html/rfc4192.
[i.15] IETF RFC 5887: "Renumbering still needs work", May 2010, B. Carpenter, R. Atkinson, and
H. Flinck.
NOTE: Available at https://tools.ietf.org/html/rfc5887.
[i.16] D. Leroy and O. Bonaventure: "Preparing network configurations for IPv6 renumbering,"
International Journal of Network Management, vol. 19, no. 5, pp. 415-426,
September/October 2009.
[i.17] J. Small: "Threat analysis of recursive internetwork architecture distributed IPC facilities",
BU Technical report, 2011.
NOTE: Available at http://pouzinsociety.org/research/publications.
[i.18] Eduard Grasa, Leonardo Bergesio, Miquel Tarzan, Diego Lopez, John Day and Lou Chitkushev:
"Seamless Network Renumbering in RINA: Automate Address Changes Without Breaking
Flows!", EUCNC 2017.
NOTE: Available at https://zenodo.org/record/1013204#.WeTDrROCxTY.
[i.19] IETF RFC 5944: "IP mobility support for IPv4, revised", November 2010, C. Perkins.
NOTE: Available at https://tools.ietf.org/html/rfc5944.
ETSI
---------------------- Page: 8 ----------------------
9 ETSI GR NGP 009 V1.1.1 (2019-02)
[i.20] IETF RFC 6275: "Mobility support in IPv6", July 2011, J. A. C. Perkins, D. Johnson.
NOTE: Available at https://tools.ietf.org/html/rfc6275.
[i.21] IETF RFC 5213: "Proxy mobile IPv6", August 2008, S. Gundavelli, K. Leung, V. Devarapalli, K.
Chowdhury and B. Patil.
NOTE: Available at https://tools.ietf.org/html/rfc5213.
[i.22] IETF RFC 6830: "The Locator/ID Separation Protocol (LISP)", January 2013, D. Meyer, D.
Lewis, D. Farinacci, V. Fuller.
[i.23] J. Day and E. Grasa: "Mobility Made Simple". PSOC Tutorial paper, May 2016.
NOTE: Available at http://psoc.i2cat.net/sites/default/files/PSOC-tutorial-Mobility-made-
simple.pdf?_ga=2.45065702.356832367.1537337692-718608749.1512423093.
[i.24] V. Ishakian, J. Akinwumi, F. Esposito and I. Matta: "On supporting mobility and multihoming in
recursive internet architectures", Comput. Commun., vol. 35, no. 13, pp. 1561-1573, July 2012.
[i.25] ETSI GS NGP 001 (V1.3.1): "Next Generation Protocols (NGP); Scenario Definitions".
NOTE: Available at
https://www.etsi.org/deliver/etsi_gs/NGP/001_099/001/01.03.01_60/gs_NGP001v010301p.pdf.
[i.26] IETF RFC 1287: "Towards the Future Internet Architecture", December1991, D. Clark, L. Chapin,
V. Cerf, R. Braden, R. Hobby.
NOTE: Available at https://tools.ietf.org/html/rfc1287.
[i.27] J. Day: "How in the heck do you lose a layer!?", International Conference on the Network of the
Future, 2011.
[i.28] Atlantic Council, Frederik S. Pardee Center for International Futures, Zurich: "Risk Nexus.
Overcome by Cyber Risks? Economic benefits and costs of alternate cyber futures", 2016.
NOTE: Available at http://publications.atlanticcouncil.org/cyberrisks//.
[i.29] IETF RFC 2535: "Domain name system security extensions", March 1999, D. Eastlake.
NOTE: Available at https://tools.ietf.org/html/rfc2535.
[i.30] IETF RFC 2401: "Security architecture for the IP Protocol", December 2005, S. Kent, K. Seo.
NOTE: Available at https://tools.ietf.org/html/rfc2401.
[i.31] IETF RFC 68
...