Sample requirements

Having motivated and described the network chosen to serve as input to our proof of concept, we now proceed to describe real world requirements that match each of the four requirements described throughout this work.

The campus network has several implicit assumptions which lend themselves for formal- isation as an operational requirement. In each of the next subsections we will translate a real world assumption or expectation into an operational requirement. In order, we cover segmentation, control, time to recovery, and path diversity.

5.4.1. Segmentation

A real world use-case for the segmentation property can be found in the separation of production and management segments of the campus network. We take the example of a residential building, equipped with an edge-switch and multiple access points. Although residents have network access through both types of devices, the devices themselves are also accessible from the network for management purposes. Our chosen segmentation requirement states that a user connected to the switch cannot reach the management network of the access point on the same floor.

5.4.2. Control

To show the versatility of the ability to lift element specific requirements to the abstrac- tion level of a full topology, we choose a non-standard use-case for the control property. Specifically, we define the requirement that traffic from a residential end user to the core network only uses elements with a bandwidth capacity greater than or equal to the bandwidth capacity of the edge port. In other words, we validate that a single edge-user is unable to saturate the uplink, thereby blocking access for his fellow users.

5.4.3. Time to recovery

Table 5.3 shows recovery times for different device roles in the residential subset of the campus network. Using these recovery times, we want to compute the worst case downtime for a single device failure in the residential path to the internet. In particular, we compute the time to recovery for the path between a host connected to a residential

devices

building level access switch 4 hours quarter level distribution switch 3-4 days campus level residential core switch 3-4 days

core router 5 days

links

patch/cable 1 hour fiber ring 3 days

Table 5.3.: Recovery times per device role for residential subset of the campus network, assuming full hardware failure, as estimated by the campus network’s IT staff (numbers are approximate)

access switch and one of the core routers routing the residential subset of the campus network.

We define a recovery time of one day acceptable for the type of outage which requires full replacement of hardware, which will serve as our requirement to test against.

5.4.4. Path diversity

For the same residential to core connection, we check the number of redundant paths available. Combined with the requirement for time to recovery this allows quantification of failure modes.

The residential subset of the campus network has been designed with redundancy in mind. Past the access switches, the entire infrastructure should be redundant. We therefore check whether the infrastructure between a residential access switch and the core network does indeed provide a minimum of two independent paths.

5.4.5. Conversion of the operational requirements

Having described the operational requirements selected for the campus network in gen- eral terms, we will now specifically detail the conversion of each requirement for verifica- tion with netPropCheck. To this end, we briefly return to each of the four requirements.

segmentation In the case of segmentation, the conversion is relatively straightfor- ward. We have modelled a system and connected it to a residential edge switch manu- ally to the campus network topology. Moreover, the wireless access point located closest to the system is identified. To check the segmentation property, we verify segmentation between the outbound interface of the system and inbound interface on the management vlan of the wireless access point.

control To check the segmentation property, we again use the residential system used before, this time with a core router as counterpart. Connection speeds are determined by using the encoding property on NML Ports, information which is contained in the topology description. The different encodings on the physical level are used as an esti- mator for link speeds. The connection speed of the system’s interface is obtained and subsequently compared to all NML ports on the physical layer on the path to the core, forming the control criterion. Because we are only interested in the ability of the user to directly hinder other residential users through direct link saturation, this property is only checked in one direction.

time to recovery The time to recovery property is checked by using the information contained in Table 5.3. We define a recovery cost function by assigning to every NML Port and Link a recovery cost value. The mapping between a switch and its respective device class is given as input to the computation. The devices involved are once again the system connected to a residential edge switch and the core router. The required worst case recovery time is specified as 24 hours.

path diversity Although we stated the intention to check the number of independent paths between the residential system and a core router, this is not possible with the generated topology description. As indicated in Section 5.3.3, the data provided on the physical layer only includes a single connection per pair of devices. And although the residential access switches are connected to the quarter level distribution switches using two distinct links, this gap in the data does not allow us to verify their impact on the overall path diversity. Consequently, we choose to verify the number of distinct paths between the quarter level distribution switch and one of the core routers.

Moreover, to work around an implementation choice for the path selection algorithm combined with the lack of an NML construct for trunking/bonding, the path The re- quired path diversity is specified as 2 independent paths.