ETSI GR NGP 003 V1.1.1 (2017-03)

NGP Next Generation Protocol; Packet Routing Technologies

DGR/NGP-003

General Information

• Status: Published
• Publication Date: 29-Mar-2017
• Technical Committee: NGP - Next Generation Protocols
• Current Stage: 12 - Completion
• Due Date: 17-Apr-2017
• Completion Date: 30-Mar-2017

Standards Content (Sample)

GROUP REPORT
NGP Next Generation Protocol;
Packet Routing Technologies
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.

2 ETSI GR NGP 003 V1.1.1 (2017-03)

Reference
DGR/NGP-003
Keywords
flexilink, M2CNP, Next Generation Protocol,
RINA
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

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:
http://www.etsi.org/standards-search
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 only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
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
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
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.

© European Telecommunications Standards Institute 2017.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI GR NGP 003 V1.1.1 (2017-03)
Contents
Intellectual Property Rights . 6
Foreword . 6
Modal verbs terminology . 6
Executive summary . 6
Introduction . 7
1 Scope . 8
2 References . 8
2.1 Normative references . 8
2.2 Informative references . 8
3 Definitions and abbreviations . 10
3.1 Definitions . 10
3.2 Abbreviations . 10
4 RINA (Recursive InterNetwork Architecture) . 12
4.1 Overview . 12
4.1.0 Introduction to RINA . 12
4.1.1 The DIF service definition . 13
4.1.2 The nature of layers (DIFs) . 14
4.1.3 Internals of a DIF: only two protocols required . 14
4.1.4 Naming and addressing . 15
4.1.5 Consistent QoS model across layers . 15
4.1.6 Consistent security model across layers . 16
4.1.7 Network Management . 16
4.2 Data transfer: protocol, functions and procedures . 17
4.2.0 General . 17
4.2.1 DTP PDU Format . 17
4.2.2 DTCP PDU Formats . 18
4.2.3 Overview of data-transfer procedures . 18
4.3 Layer management: protocol, functions and procedures . 19
4.3.1 Common layer management machinery . 19
4.3.2 Layer management functions: enrolment . 20
4.3.3 Layer management functions: namespace management . 20
4.3.4 Layer management functions: flow allocation . 21
4.3.5 Layer management functions: resource allocation . 21
4.3.6 Layer management functions: routing . 22
4.3.7 Layer management functions: security coordination . 22
4.4 Support for mobility . 22
4.5 Support for security . 23
4.6 Addressing and scalability . 24
4.7 Interworking and migration . 24
4.8 Assessment against NGP key issues . 25
5 Flexilink . 26
5.1 Overview . 26
5.1.1 Background . 26
5.1.2 Main differences from IP . 27
5.1.3 Flows, and separation of control and forwarding . 27
5.1.4 Services . 27
5.1.5 Choice of service for data transport . 28
5.2 Packet formats . 29
5.2.1 General . 29
5.2.2 AV packets. 29
5.2.3 IT packets. 29
5.3 Control plane procedures . 30
ETSI
4 ETSI GR NGP 003 V1.1.1 (2017-03)
5.3.1 Message format . 30
5.3.2 Identifiers . 30
5.3.2.1 Equipment identifiers . 30
5.3.2.2 Call, route, and flow identifiers . 30
5.3.2.3 Addressing . 30
5.3.3 Setting up routes . 31
5.3.3.1 Procedure for connection-oriented model . 31
5.3.3.2 Connectionless service . 31
5.3.3.3 Additional information in FindRoute messages . 31
5.3.4 Synchronization of AV flows . 31
5.3.4.1 Slots. 31
5.3.4.2 Frame alignment . 32
5.4 Support for mobility . 32
5.5 Support for security . 32
5.5.1 Authentication . 32
5.5.2 Denial of service . 32
5.6 Addressing and scalability . 33
5.7 Interworking and migration . 33
5.7.1 Definitions . 33
5.7.2 Connecting islands via other technologies . 33
5.7.3 Tunnelling other technologies across isla nds . 34
5.7.4 Other gateway functions . 34
5.8 Assessment against NGP key issues . 35
6 Multi-access, Mobility-aware, Context-aware-Networking Protocol (M2CNP) . 37
6.1 Overview . 37
6.2 System Architecture . 37
6.2.1 Introduction. 37
6.2.2 M2CNP Protocol Management Entities . 38
6.2.2.1 Access EndPoint . 38
6.2.2.2 Access Point . 39
6.2.2.3 Packet Processing Entity . 39
6.2.2.4 Cluster Controller Functional Entity . 39
6.2.2.5 Cluster Member Functional Entity . 40
6.2.2.6 Access Agent Functional Entity . 40
6.2.2.7 Network Subscriber Location Database . 40
6.2.2.8 Cluster Content Routing Database . 40
6.3 Protocol Stack . 41
6.4 Access Agent Functionalities and Benefits . 43
6.4.0 Preview . 43
6.4.1 User Plane Functionality . 43
6.4.1.0 General . 43
6.4.1.1 Network Service Request Handling . 43
6.4.1.1.0 Types of service . 43
6.4.1.1.1 HTTP Request Handling . 43
6.4.1.1.2 Voice Request Handling . 44
6.4.1.2 Context-Driven Intelligent Content Management . 44
6.4.2 Control Functionality . 45
6.4.2.1 User Association . 45
6.4.2.2 User Authentication . 45
6.4.2.3 Address Translation . 45
6.4.2.4 Intra-Cluster Mobility . 45
6.4.2.5 Inter-Cluster Mobility . 45
6.5 Protocol Field Structure/Addressing . 45
6.6 Security . 46
6.7 Routing . 47
6.8 Message Sets . 47
6.8.0 General . 47
6.8.1 Network Services . 48
6.9 M2CNP assessment against criteria . 49
Annex A: Assessment against NGP requirements. 52
ETSI
5 ETSI GR NGP 003 V1.1.1 (2017-03)
Annex B: Authors & contributors . 54
Annex C: Change History . 55
History . 56

ETSI
6 ETSI GR NGP 003 V1.1.1 (2017-03)
Intellectual Property Rights
IPRs essential or potentially essential to the present document 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.
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.
Executive summary
Three technologies are described in the present document.
RINA embodies a theory which is informally known as the Inter-Process Communication (IPC) model. It is structured
around a single type of layer - called Distributed IPC Facility or DIF - that repeats as many times as needed. In RINA,
all layers are distributed applications that provide the same service (communication flows between distributed
applications) and have the same internal structure, divided into data transfer (delimiting, addressing, sequencing,
relaying, multiplexing, lifetime termination, error check, encryption), data transfer control (flow and retransmission
control), and layer management (enrolment, routing, flow allocation, namespace management, resource allocation,
security management).
st
Flexilink is designed for implementation in 21 century digital systems, in which packet forwarding is implemented in
hardware and memory is much more plentiful than when Internet Protocol was developed. The information needed to
route packets is carried separately from the packets themselves; this reduces the size of the packet header by an order of
magnitude, simplifies the forwarding hardware, and allows different addressing mechanisms to be used without
changing the packet format. It supports ultra-low latency live streams; these are needed for some of the new services
that 5G is to support, and also provide a better service for audio and video. They can also be used for file transfer,
eliminating the need for the kind of empirical throughput testing that is a feature of TCP.
M2CNP envisages a packet based routed protocol architecture with the ability to embed protocol control messaging to
provide basic protocol management functions for: security, context-awareness, transmission management, and mobility.
Applications and/or services, running at access network connected devices, communicate using IPC interfaces towards
the M2CNP communications network. Devices may be connected via one or more access technologies at a time and are
capable of mobility from one access point or Temporary Access Points Group (for multiple access) to another. The
M2CNP network consists of M2CNP Packet Processing Entities, which are M2CNP routing entities that are selectively
enabled with various protocol management capabilities of M2CNP and may be deployed in terms of scope in a similar
manner to CE, PE, P scope routers as commonly understood in the legacy IP world.
ETSI
7 ETSI GR NGP 003 V1.1.1 (2017-03)
Introduction
ETSI ISG NGP is tasked with reviewing networking technologies, architectures, and protocols for the next generation
of communication systems.
The present document describes some technologies of which ISG NGP is aware, which could be evaluated against the
requirements listed in ETSI GS NGP 001 [i.1] (Scenarios) and 3GPP TR 23.799 [i.3].
Ideally, ISG NGP would issue a Call for Technology and wait for responses before drafting the present document.
However, new radio interfaces are now being developed for 5G, and if something other than TCP/IP is to be used with
them the developers of the radio technology need to have an indication, early in the process, of the kind of shape the
new protocols might have. Therefore, a first version of the present document is being produced covering technologies
that have been researched by the current members of ISP NGP. It is intended that further versions will be produced,
containing additional architectures.

ETSI
8 ETSI GR NGP 003 V1.1.1 (2017-03)
1 Scope
The present document describes packet routing technologies that might be used in 5G radio networks and in the core of
future mobile networks, and would also be suitable for use in the Internet. The description of each technology includes:
• overview of routing approach;
• key fields in user plane packets;
• procedures for setting up routes, etc.;
• support for mobility;
• support for security;
• addressing, including scalability issues.
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] ETSI GS NGP 001 (V1.1.1): "Next Generation Protocol (NGP); Scenario Definitions".
[i.2] ISO/IEC 62379-5-2:2014: "Common control interface for networked digital audio and video
products -- Part 5-2: Transmission over networks -- Signalling".
[i.3] 3GPP TR 23.799: "Study on Architecture for Next Generation System".
[i.4] J. Day: "Patterns in Network Architecture: A return to fundamentals". Prentice Hall, 2008.
[i.5] J. Day, I. Matta, and K. Mattar. 2008: "Networking is IPC: a guiding principle to a better Internet".
In Proceedings of the 2008 ACM CoNEXT Conference (CoNEXT '08).
[i.6] J. Day, E. Grasa: "About layers: more or less".
NOTE: PSOC Tutorial, available online at http://pouzinsociety.org.
[i.7] J. Day: "How naming, addressing and routing are supposed to work".
NOTE: PSOC Tutorial, available online at http://pouzinsociety.org.
[i.8] G. Gursun, I. Matta, and K. Mattar: "On the Performance and Robustness of Managing Reliable
th
Transport Connections". In Proceedings of the 8 International Workshop on Protocols for Future,
Large-Scale and Diverse Network Transports (PFLDNeT), Lancester, PA, November 2010.
ETSI
9 ETSI GR NGP 003 V1.1.1 (2017-03)
[i.9] Boddapati, G.; Day, J.; Matta, I.; Chitkushev, L.: "Assessing the security of a clean-slate Internet
th
architecture". Network Protocols (ICNP), 2012 20 IEEE International Conference on.
[i.10] V. Maffione, F. Salvestrini, E. Grasa, L. Bergesio, M. Tarzan: "A Software Development Kit to
exploit RINA programmability". IEEE ICC 2016, Next Generation Networking and Internet
Symposium.
[i.11] J. Day, E. Grasa: "Mobility made simple".
NOTE: PSOC Tutorial, available online at http://pouzinsociety.org.
[i.12] J. Day, E. Trouva, E. Grasa, P. Phelan, M.P. de Leon, S. Bunch, I. Matta, L.T. Chitkushev,
L. Pouzin: "Bounding the router table size in an ISP network using RINA". Network of the Future
(NOF), 2011.
[i.13] V. Ishakian, J. Akinwumi, F. Esposito, and I. Matta: "On supporting mobility and multihoming in
recursive internet architectures". Comput. Commun. 35, 13 (July 2012),
1561-1573.
[i.14] J. Small: "Threat analysis of Recursive InterNetwork Architecture Distributed IPC Facilities".
BU Technical Report, 2011.
[i.15] 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, Communications and Information Systems Security Symposium.
[i.16] J. Small: "Patterns in Network Security: An analysis of architectural complexity in securing
Recursive Inter-Network Architecture Networks". Master Thesis, 2012.
[i.17] S. León, J. Perelló, D. Careglio, E. Grasa, D. Lopez, Pedro A. Aranda: "Benefits of Programmable
Topological Routing Policies in RINA-enabled Large-scale Datacentres". IEEE Globecom 2016,
NGN Symposium, December 2016.
[i.18] P. Teymoori, M. Welzl, S. Gjessing, E. Grasa, R. Riggio, K. Rausch, D. Siracussa: "Congestion
control in the Recursive Internetwork Architecture (RINA)". IEEE ICC 2016, Next Generation
Networking and Internet Symposium.
[i.19] R. Watson: "Timer-based mechanism in reliable transport protocol connection management".
Computer Networks, 5:47–56, 1981.
[i.20] AES67: "AES standard for audio applications of networks - High-performance streaming audio-
over-IP interoperability"; Audio Engineering Society, New York, NY., US.
[i.21] EBU Doc Tech 3326: "Audio contribution over IP Requirements for Interoperability"; European
Broadcasting Union, Geneva, CH.
[i.22] SMPTE 2022: "Digital video on IP networks"; Society of Motion Picture and Television
Engineers, White Plains, NY., US.
[i.23] ISO/IEC 7498-1: "Information technology - Open Systems Interconnection - Basic Reference
Model: Part 1: The Basic Model". International Standards Organization, Geneva, CH.
[i.24] C. Ge et al.: "QoE-Driven DASH Video Caching and Adaptation at 5G Mobile Edge", in
Proceedings of the 3rd ACM Conference on Information-Centric Networking (ACM-ICN '16),
pp. 237-242, ACM, Kyoto, Japan, 2016.
[i.25] P. Qian et al.: "Enabling Context-aware HTTP with Mobile Edge Hint", to be published in
proceedings of the 14th Annual IEEE Consumer Communications & Networking Conference
(January 2017, Las Vegas, USA).
ETSI
10 ETSI GR NGP 003 V1.1.1 (2017-03)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
cluster: M2CNP aware logical grouping of one or more access points, PPEs and logical protocol control entities
endpoint: service or application or PPE that wishes to communicate with other M2CNP endpoints
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AA Access Agent
ACIP Audio Contribution over IP
ACM Association for Computing Machinery
ACRA Adaptive Code based RACH Access
ADDR ADDRess
AEP Access EndPoint (M2CNP)
AP Access Point ID (M2CNP)
API Application Program Interface
AP-ID Access Point IDentifier
ARP Address Resolution Protocol
ASN.1 Abstract Syntax Notation 1
ATM Asynchronous Transfer Mode
AV Audio-Video
BBC British Broadcasting Corporation
CC Cluster Controller (M2CNP)
CCNC Consumer Communications & Networking Conference
CCRD Cluster Content Routing Database
CDAP Common Distributed Application Protocol
CE Customer Equipment
CEPID Connection EndPoint IDentifier
Cl-ID Cluster ID (M2CNP)
CM Cluster Member (M2CNP)
CRC Cyclic Redundancy Check
DAF Distributed Application Facility
DASH Dynamic Adaptive Streaming over Http
DIF Distributed IPC Facility
DNS Directory Name Server
DST DeSTination
DTCP Data Transfer Control Protocol
DTP Data Transfer Protocol
EBU European Broadcasting Union
ECN Explicit Congestion Notification
EFCP Error and Flow Control Protocol
EN Enabling
EP EndPoint
ETE End To End
FAI Flow Allocator-Instance
FDC Flat Distributed Cloud
FMC Fixed Mobile Convergence
FPGA Field-Programmable Gate Array
GPS Global Positioning System
HD High Definition [television]
HTTP HyperText Transfer Protocol
IE Information Element
IEC International Electrotechnical Commission
ETSI
11 ETSI GR NGP 003 V1.1.1 (2017-03)
IETF Internet Engineering Task Force
IMPL IMPLemented
IMS IP Multimedia Subsystem
IMSI International Mobile Subscriber Identity
IP Internet Protocol
IPC Inter-Process Communication
IPCP Inter-Process Communication Process
ISO International Organization for Standardization
ISP Internet Service Provider
IT Information Technology
LISP Locator-Identifier Separation Protocol
LV Length and Value
M2CNP Multi-Access, Mobility Aware and Context Aware Networking protocol
MAC Media Access Control
MBB Mobile BroadBand
MDP MetaData Protocol
MEC Mobile Edge Computing
MH Mobile Host
MPLS Multi-Protocol Label Switching
MS Message Set
MTU Maximum Transmission Unit
NAS Non-Access Stratum
NEP Network EndPoint (M2CNP)
NFV Network Function Virtualisation
NGP Next Generation Protocols
NM-DMS Network Management - Distributed Management System
NR New Radio
NR-eNB New Radio eNB (base station of 3GPP New Radio RAN)
NS Network Service
NSLD Network Subscriber Location Database
NSM Name Space Manager
OTS Off The Shelf
OTT Over The Top
PC Personal Computer
PDCP Packet Data Convergence Protocol
PDU Protocol Data Unit
PE Provider Equipment
PLMN Public Land Mobile Network
PPE Packet Processing Entities (M2CNP)
PTP Precision Time Protocol
QoE Quality of Experience
QoS Quality of Service
RA Resource Allocator
RACH Random Access CHannel
RAN Radio Access Network
RIB Resource Information Base
RINA Recursive InterNetwork Architecture
RLC Radio Link Control
RMT Relaying and Multiplexing Task
RRC Radio Resource Control
RTP Real Time Protocol
SDN Software-Defined Network
SDO Standards Development Organization
SDP Session Description Protocol
SDU Service Data Unit
SIM SIMulation
SIP Session Initiation Protocol
SMPTE Society of Motion Picture and Television Engineers
SoC System on Chip
SRC SouRCe
TAPG Temporary Access Points Group
TCP Transmission Control Protocol
ETSI
12 ETSI GR NGP 003 V1.1.1 (2017-03)
TLV Tag Length Value
UDP Unacknowledged Datagram Protocol
UE User Equipment
UP User Plane
VAL VALidation
VERS VERSion
VPN Virtual Private Network
WDM Wavelength Division Multiplexing
4 RINA (Recursive InterNetwork Architecture)
4.1 Overview
4.1.0 Introduction to RINA
The Recursive InterNetwork Architecture (RINA) is a computer network architecture that unifies distributed computing
and telecommunications. RINA's fundamental principle is that computer networking is just Inter-Process
Communication or IPC. RINA reconstructs the overall structure of the Internet, forming a model that comprises a single
repeating layer, the DIF (Distributed IPC Facility), which is the minimal set of components required to allow distributed
IPC between application processes. RINA inherently supports mobility, multi-homing, and Quality of Service without
the need for extra mechanisms, provides a secure and programmable environment, motivates for a more competitive
marketplace, and allows for a seamless adoption.
RINA is the result of an effort that tries to work out the general principles in computer networking that apply to
everything. RINA is the specific architecture, implementation, testing platform and ultimately deployment of the theory.
This theory is informally known as the Inter-Process Communication "IPC model" ([i.4] and [i.5]) although it also deals
with concepts and results that are generic for any distributed application and not just for networking. RINA is structured
around a single type of layer - called Distributed IPC Facility or DIF - that repeats as many times as needed by the
network designer (figure 4.1). In RINA all layers are distributed applications that provide the same service
(communication flows between distributed applications) and have the same internal structure. The instantiation of a
layer in a computing system is an application process called IPC Process (IPCP). All IPCPs have the same functions,
divided into data transfer (delimiting, addressing, sequencing, relaying, multiplexing, lifetime termination, error check,
encryption), data transfer control (flow and retransmission control), and layer management (enrolment, routing, flow
allocation, namespace management, resource allocation, security management). The functions of an IPCP are
programmable via policies, so that each DIF can adapt to its operational environment and to different application
requirements.
ETSI
13 ETSI GR NGP 003 V1.1.1 (2017-03)

Figure 4.1: Illustration of the RINA structure: DIFs and internal organization of IPC Processes (IPCPs)
4.1.1 The DIF service definition
The DIF service definition provides the abstract description of an API as seen by an Application Process using a DIF
(specific APIs are system-dependant and may take into account local constraints; in some cases there may not be an API
at all, but an equivalent way to have equivalent interactions). The Application Process might be an IPC Process,
reflecting the recursive nature of RINA (a DIF can be used by any distributed application, including other DIFs). All
DIFs provide the same service, called flows. A flow is the instantiation of a communication service between two or
more application process instances. The DIF API allows application to operate upon flows using the following four
operations:
• Allocate: Allows an application to request a flow to a destination application, providing its application name
and the desired characteristics of the flow (statistical bounds on loss and delay, in-order-delivery, minimum
capacity, etc.). If the flow allocation is successful, the DIF returns a port-id, which is a local handle to the
flow.
• Write: Writes an SDU (Service Data Unit) to the flow identified by a port-id. The application writes a full
SDU of bytes in a single transaction. The integrity of the SDU is maintained by the DIF, which will try to
deliver the whole SDU to the receiving application instance(s). Applications may accept delivery of
incomplete or partial SDUs (this can be specified via the flow allocation request). The DIF may block the
application or return error-on-write if the DIF's flow control or congestion management functions indicate to
do so.
• Read: Reads an SDU from the flow identified by a port-id.
• Deallocate: Causes the DIF to terminate the flow and free all the resources associated to it.
ETSI
14 ETSI GR NGP 003 V1.1.1 (2017-03)
4.1.2 The nature of layers (DIFs)
In contrast with traditional network architectures in which layers have been defined as units of modularity, in RINA
layers (DIFs) are distributed resource allocators [i.6]. It is not that layers perform different functions; they all perform
the same functions at different scopes. They are doing these functions for the different ranges of the environments the
network is targeted at (a single link, a backbone network, an access network, an internet, a VPN, etc.). The scope of
each layer is configured to handle a given range of bandwidth, QoS, and scale: a classic case of divide and conquer.
Layers manage resources over a given range. The policies of each layer will be selected to optimize that range, bringing
programmability to every relevant function within the layer [i.10]. How many layers are needed? It depends on the
range of bandwidth, QoS, and scale: simple networks have two layers, simple internetworks, 3; more complex networks
may have more. This is a network design question, not an architecture question.
4.1.3 Internals of a DIF: only two protocols required
One of the key RINA design principles has been to maximize invariance and minimize discontinuities. In other words,
extract as much commonality as possible without creating special cases. Applying the concept from operating systems
of separating mechanism and policy, first to the data transfer protocols and then to the layer management machinery
(usually referred to as the control plane), it turns out that only two protocols are required within a layer [i.4]:
• A single data transport protocol that supports multiple policies and allows for different concrete syntaxes
(length of fields in the protocol PDUs). This protocol is called EFCP - the Error and Flow Control Protocol -
and is further explained in clause 4.2.
• A common application protocol that operates on remote objects used by all the layer management functions.
This protocol is called CDAP - the Common Distributed Application Protocol - and is further explained in
clause 4.3.
Separation of mechanism and policy also provided new insights about the structure of those functions within the layer,
depicted in figure 4.1. The primary components of an IPC Process are shown in figure 4.2 and can be divided into three
categories:
a) Data Transfer, decoupled through a state vector from;
b) Data Transfer Control, decoupled through a Resource Information Base from;
c) Layer Management.
These three loci of processing are characterized by decreasing cycle time and increasing computational complexity
(simpler functions execute more often than complex ones):
• SDU Delimiting. The integrity of the SDU written to the flow is preserved by the DIF via a delimiting
function. Delimiting also adapts the SDU to the maximum PDU size. To do so, delimiting comprises the
mechanisms of fragmentation, reassembly, concatenation and separation.
• EFCP, the Error and Flow Control Protocol. This protocol is based on Richard Watson's work [i.19] and
separates mechanism and policy. There is one instance of the protocol state for each flow originating or
terminating at this IPC Process. The protocol naturally cleaves into Data Transfer (sequencing, lost and
duplicate detection, identification of parallel connections), which updates a state vector; and Data Transfer
Control, consisting of retransmission control (ack) and flow control.
• RMT, the Relaying and Multiplexing Task. It makes forwarding decisions on incoming PDUs and multiplexes
multiple flows of outgoing PDUs onto one or more (N-1) flows. There is one RMT per IPC Process.
• SDU Protection. It does integrity/error detection, e.g. CRC, encryption, compression, etc. Potentially there can
be a different SDU Protection policy for each (N-1) flow.
The state of the IPC Process is modelled as a set of objects stored in the Resource Information Base (RIB) and accessed
via the RIB Daemon. The RIB imposes a schema over the objects modelling the IPCP state, defining what CDAP
operations are available on each object and what will be their effects. The RIB Daemon provides all the layer
management functions (enrolment, namespace management, flow allocation, resource allocation, security coordination,
etc.) with the means to interact with the RIBs of peer IPCPs. Coordination within the layer uses the Common
Distributed Application Protocol (CDAP). More detail on layer management functions and operation is p
...