# ARCFIRE: Experimentation with the Recursive InterNetwork Architecture
## 2 Modeling a Converged Network Operator
Small networks can start with a small number of DIFs, in order to minimize the protocol and management overhead, and scale by introducing new ones in different parts of the network when needed. Applications are not restricted to use a specific top-level DIF, they can use whatever DIF provides the scope and quality that fulfils the application requirements. The network operator can exploit this ability to provide optimized DIFs that let customers communicate at lower layers, with the benefit of increased performance. For example, customers that are physically close to each other could communicate directly via a DIF that directly sits on top of the access network layers. Or the operator can leverage this ability to provide Mobile Edge Computing (MEC) services via DIFs that give access to latency-critical applications hosted in micro-DCs at the edge of the network. A RINA-based CON uses a single management protocol, and all DIFs have the same base object model that captures that DIF's common behavior. Individual policies provide information about their state and configuration by extending that base model. RINA networks feature a converged model and northbound management interface for any network segment (access, aggregation, core, interconnect); thus, facilitating the re-use of operations support systems (OSS) applications for fault, configuration, security, accounting and performance management. In comparison, current OSS systems are usually tied to a specific vendor, equipment model or software version. A full discussion of these architectural properties is provided in Section 3.8 of ARCFIRE's Deliverable D2.2 [5]. \begin{table}
\begin{tabular}{c c c} \hline \hline
**CON Design** & **with Current Network Architectures** & **with RINA** \\ \hline \multirow{8}{*}{_Resource allocation and Quality of Service (QoS)_} & Lack of consistent QoS model, each protocol family has its own & Consistent QoS model across layers, from application to physical layers \\ \cline{2-3}  & Only end-to-end congestion control loops—reaction time is maximized & Congestion control loops shorter, closer where congestion occurs \\ \cline{2-3}  & Implicit congestion detection in many cases—false positives and overreaction & Explicit Congestion Detection always, for a precise response \\ \cline{2-3}  & Homogeneous congestion control policies for heterogeneous networks & Per-layer congestion control policies: optimal reaction to congestion in different parts of the network \\ \hline \multirow{8}{*}{_Security_} & Most protocol enforce their own security model, introducing complexity & Secure layers instead of individual protocols: consistent security model \\ \cline{2-3}  & Use of well-known ports facilitates transport layer attacks & Use of application names, dynamic transport port allocation \\ \cline{2-3}  & Network addresses exposed to applications, facilitates network scanning & Addresses are internal to a layer and never exposed outside of it \\ \hline \multirow{8}{*}{_Network Management_} & Too little commonality in network protocols, making management of CONs increasingly complex & Two immutable protocol frameworks and a well-defined set of policies simplify the network structure \\ \cline{2-3}  & No well-defined model for the interaction between layers & Consistent service definition and function structuring across layers \\ \cline{2-3}  & Different protocols and object modelling frameworks for network management & Single network management protocol and common layer object model \\ \hline \hline \end{tabular}
\end{table} 
Table 1: _Cont._