Skip to content

Overall model description

This section describes key common elements in the ENP network model.

ENP network object and ENP sessions

  • A network is represented in ENP model with an Mtn object. This object gives access to all the network elements of the different types in the network (nodes, links, etc.).
  • All Mtn objects are associated with a so-called ENP session with the ENP server the user is connected. An ENP session requires a permanent network connection with the ENP server, that gives access to all the functionalities and operations that can be conducted with the network, via a secured and encrypted communication channel. If the network connectivity stops, the Mtn object becomes unusable.
  • Mtn networks can be loaded and stored in a JSON format, both in the client and the server file system.
  • All the network elements that are part of a network, are subclasses of the MtnNetworkElement class, that implements the IMtnNetworkElement interface. Such class and interface incorporate common behavior shared by all the network elements, like the possibility to assign it a name, a description, user-defined tags (i.e. that permit classifying the elements in different forms), or user-defined key-value attributes to further characterize the element (e.g. introducing a user-defined identifier for the element, information about the element configuration, or about the physical element that this ENP element represents). Additionally, all the network elements have a unique identifier (unique inside the Mtn network)

ENP network nodes

ENP network nodes are objects of the class AbstractNode. These nodes implement the interface ISimpleNode which includes part of its behavior... The hierarchy of nodes is as follows:

  • External nodes. These nodes are of the class NodeExternal. They represent external networks, that can be the origin or destination of IP traffic, and that are connected to regular internal nodes with IP capabilities (ISimpleNodeCapableIpProcessing_Internal).

  • Internal nodes. These nodes are of the class AbstractNodeInternal. They represent regular nodes of any type in the network, i.e. all the nodes in the network (but the external), are subclasses of this class, from simple optical splitters to full IP routers or ODU switches. ENP includes multiple subclasses implementing different types of nodes (IP routers, Ethernet switches, ODU switches, different OTN transponder variants, etc.). ENP can be extended by incorporating new ones. Internal nodes can implement one or more of the following interfaces:

    • ISimpleNodeCapableIpProcessing_Internal. If the node can host IP ports and implement IP capabilities.
    • ISimpleNodeCapableEndEthernet. If the node can end Ethernet links, and ISimpleNodeCapableEthernetMacBasedSwitch can also operate as an Ethernet switch (switch based on MAC addresses)
    • ISimpleNodeCapableEndVirtualCnx. If the node can end so-called virtual transport connections, an abstract form of representing a transport connection between two IP ports.
    • ISimpleNodeCapableEndOts. If the node can end fiber spans of Optical Transmission Sections (OTS) in the OTN hierarchy.
    • ISimpleNodeCapableEndWdm. If the node can end WDM links of Optical Multiplexing Sections (OMS) in the OTN hierarchy.
    • ISimpleNodeCapableEndOch. If the node can end Optical Channels (OCh) in the OTN hierarchy.
    • ISimpleNodeCapableEndOtu. If the node can end Optical Transmission Units (OTU) in the OTN hierarchy.
    • ISimpleNodeCapableEndOdus. If the node can end Optical Data Units (ODU) in the OTN hierarchy.
    • ISimpleNodeCapableOpticalSignalPropagation. If the node can make a transparent optical switching or propagation of the optical signal, using active or passive components, between some of its end ports.
    • ISimpleNodeCapableOchOeoRegeneration. If the node can host Optical-Electrical-Optical (OEO) regenerators, to split OTUs into OChs.
    • ISimpleNodeCapableOduSwitch. If the node can implement ODU switching, i.e. switching an ODU entering the node into an incoming OTU, into an outgoing OTU.

ENP network node aggregations

ENP network nodes can be part of node aggregations. Node aggregations have no simulation effects and are just used for visualization purposes: by aggregating nodes e.g. in the same physical site in the same aggregation, the user can ease the network visualization and can also access statistics computed ad-hoc for the node aggregation (e.g. total in/out traffic of the node, considering only links with an end inside the aggregation and the other end outside it).

Node aggregations are represented in projects of the type NodeAggregation. In addition, the common behavior shared by simple nodes (AbstractNode) and node aggregations, is implemented in the superclass AbstractNodeOrAgg, and the interface ISimpleNodeOrAggregation.

ENP network model has a hierarchical architecture to be able to represent network links and network connections of different technologies and at different network layers. In this section, we provide some information on this.

  • The interface IUnidiP2P and the class AbstractUnidiP2P include general behavior common to all the network elements that have a point-to-point nature. They can be proper links (e.g. IP links), or point-to-point demands (e.g. ODU requests or IP traffic demands between two nodes).

  • The interface IUnidiLink includes general behavior common to all the point-to-point network elements that are actual links.

  • The class AbstractUnidiPortBasedP2P includes general behavior common to all the point-to-point links that are initiated and ended in node ports, belonging to PortGroup elements hosted in the nodes.

  • The interface IUnidiOpticalLink includes general behavior common to both fiber spans and WDM links: the links capable of propagating the optical signal in the OTN hierarchy.

  • The interface ITransportConnectionChoiceBetweenLogicalIpPorts includes general behavior common to the point-to-point elements that can be used to connect IP ports between them, e.g. ODU requests (UnidiOduRequest) for IP ports connected via ODUs in the OTN network, Ethernet links (UnidiEthernetLink) and virtual transport connections (UnidiVirtuallyTransportedLink).

The list below enumerates the point-to-point elements that are not of the link type:

  • [IP] Unicast IP demand (UnidiIpDemand). This element represents an IP unicast traffic demand, between two particular IP nodes, internal or external.

IP demands are mainly characterized by their end nodes, the offered IP traffic (which may be satisfied or not), acceptable end-to-end latency, and QoS class.

IP demands can be private or not. Private demands are routed only via specific MPLS-TE tunnels, while non-private demands follow the regular IP forwarding.

  • [IP] Unidirectional IP link (UnidiIpLink). This element represents an IP link between two IP interfaces. IP links are created by the ENP simulator, not by the user when two IP interfaces are in ports connected via a working transport connection (point-to-point, or Ehternet point-to-multipoint).

  • [IP] Unidirectional external injection link (UnidiIpLinkInjection). This element represents a unidirectional part of an IP injection link, existing between an IP external node and an IP internal node.

At most one injection link can exist between the same two nodes. Injection links have infinite capacity and are always coupled in bidirectional couples (two injection links in opposite directions).

  • [IP] Unidirectional MPLS-TE tunnel (UnidiMplsTeTunnel). This element represents a unidirectional MPLS-TE (Traffic Engineering) tunnel defined in the network. See the MPLS-TE simulation section in the documentation for more information on this.

  • [OTN] Unidirectional ODU request (UnidiOduRequest). This element represents a request for a unidirectional ODU (Optical Data Unit), of a particular rate, between two particular end nodes. This request can be realized with an ODU.

The list below enumerates the point-to-point elements that are of the port-based link types:

  • [IP] Unidirectional Ethernet link (UnidiEthernetLink). This element represents an unidirectional Ethernet link, between two end Ethernet ports of the same or different nodes.

  • [Any] Unidirectional virtual transport connection (UnidiVirtuallyTransportedLink). This element represents an unidirectional Virtual Transport connection link, between two end Virtual Transport ports of the same or different nodes. Virtual transport connections are used to connect IP nodes between them when no information is present on the underlying transport technology. These connections are always arranged in bidirectional pairs.

  • [OTN] Unidirectional OTS (fiber span) (UnidiOts). This element represents an unidirectional Optical Transmission Section (OTS) link, between two end OTS ports, belonging to the same or different nodes. An OTS can be part of WDM links or not. In the latter case, they are typically used for connecting nodes inside a site.

  • [OTN] Unidirectional WDM link (UnidiWdm). This element represents an unidirectional WDM (Wavelength Division Multiplexing) link, between two end WDM ports, belonging to the same or different nodes. A WDM can be realized by one or two (1+1) WDM link paths. Each WDM link path traverses a sequence of fiber spans (Optical Transmission Section, OTS), and optical amplification can occur at intermediate nodes (typically called optical line amplifiers)... This element is routed via subpaths of the type UnidiSubpathWdm.

  • [OTN] Unidirectional OCh (UnidiOch). This element represents an unidirectional OCh (Optical Channel), between two OCh ports of the same or different end nodes. An OCh is part of an OTU path (OTU, Optical Transport Unit). OChs are not created by the user directly, but indirectly via the creation of OTUs. An OCh can be realized by one or two (1+1) OCh paths. Each OCh path traverses a sequence of WDM links and/or fiber spans (Optical Transmission Sections, OTSs) from the OCh origin port to the OCh end port... This element is routed via subpaths of the type UnidiSubpathOch.

  • [OTN] Unidirectional OTU (UnidiOtu). This element represents an unidirectional OTU (Optical Transport Unit), between two end OTU ports, belonging or not to the same node. An OTU can be realized by one or two (1+1) OTU paths. Each OTU path traverses a sequence of OChs, and OEO regeneration is implemented in intermediate nodes between consecutive OChs... This element is routed via subpaths of the type UnidiSubpathOtu.

  • [OTN] Unidirectional ODU (UnidiOdu). This element represents an unidirectional ODU (Optical Data Unit), that satisfies a particular ODU request. An ODU starts and ends in ODU ports of the ODU request end nodes, and has the rate indicated in the request satisfied. ODUs can be realized by one or two (1+1) ODU paths. Each ODU path traverses a sequence of OTUs (OTU, Optical Transport Unit) from the ODU start port to the ODU end port. This element is routed via subpaths of the type UnidiSubpathOdu.

ENP failure analysis elements

ENP network model incorporates the following characteristics to represent failure situations in the network, and the network performances respect to them:

  • Vulnerable elements. Network elements can be vulnerable to physical failures, meaning that they when a particular risk situation occurs, the network element stops working. The ENP elements of this type are e.g. IP port, nodes, and optical or injection links. These elements implement the IVulnerableElement interface.

  • Shared risk groups. A shared-risk-group (SRG) is a user-defined set of vulnerable elements, that can fail all at the same time if a particular failure event occurs. For instance, a SRG can be composed of all the optical links inside a particular duct, that simultaneously fail if the duct is cut. Users can define in ENP an arbitrary number of arbitrarily chosen SRGs, represented by Srg objects. These objects are characterized by the elements that fail when the failure event occurs, the average time between events, and the average time to repair for the failure event.

  • SRG types. In common networks, different traffic demands or services can have different fault tolerance requisites. For instance, critical traffic should be fault tolerant to more failure situations than other less-critical services. ENP permits the user to express the fault tolerance requisites independently for each traffic demand and optical ODU request (elements that implement the IServiceRequestWithFaultToleranceRequisites interface). For this, the user should define the SRGs for the risks, and associate to them one or more user-defined SRG types (e.g. 'only-for-critical' and 'for-all'). Then, the user can individually set for each demand, the SRG types for which fault tolerance is requested. In our example, critical demands would request fault tolerance for the SRGs of the type 'only-for-critical' and 'for-all', while less critical traffic would have just the 'for-all' fault tolerance requisites.