any direct hierarchical relationship between these network categories at all. For example, depending on the network topology in a particular area, a LAN may just connect directly to a WAN. In another, it may need to connect to a MAN, which itself connects to a WAN. The specifics in this regard are location and implementation choices made by those network operators.
As well as a different physical scale, the purposes of each of these types of networks are different from one another. A LAN is typically used to connect endpoints within a single building or campus together or to other network resources, whereas a MAN is often used to connect multiple LANs to each other across an area such as a city. A WAN, then, is typically used to connect one network or endpoint to a network resource that is a significant distance away, hence its “wide area” naming.
3.8 Interconnection and Exchange
As mentioned previously, the internet is far more than the combination of physical infrastructure and logical protocols; it is a network of networks that are joined as much by agreements between their operators towards a mutual benefit as they are by anything else. This can be best seen in the way in which the networks of different operators interconnect and exchange data. This exchange of data between networks is essential; without it, endpoints of one network would not be capable of accessing resources or endpoints on another network, making the internet we know today useless.
The large‐scale exchange of data between networks typically occurs inside an internet exchange (IX). Often, IXs are located within large data centres which terminate a high number of WANs inside the facility. The higher the number of networks aggregated into one location, the higher the theoretical value of that IX as a place for networks to exchange data. Chapter 7 focuses on this interconnection.
The physical locations of IXs are of considerable interest when thinking about infrastructure edge computing. Our previous example describes only the location of the IX itself, and not the locations of any of the endpoints which are ultimately sending and receiving the traffic. Consider the scenario, however, where these two endpoints are located close together but neither is near to an IX. In this example, each endpoint is connected to a different access network, and so for the data that they are sending each other to reach its destination, it must go all the way to the IX, be exchanged between their networks in that remote location, and then it will be sent all the way back to those endpoints.
Where the endpoints are using applications that rely on either very low latencies between endpoints or are sending a large amount of data, this is not an ideal network topology. For the former, latency is added between the source and destination of the traffic due to its need to traverse the IX before it can be delivered to its target endpoint, which would be minimised if a point of data exchange were available closer to those endpoints. For the latter, network resources are used between each of the endpoints and the IX to transfer the traffic, which some entity (even if it is not the users of each of the endpoints themselves directly) must pay for, with the possibility to introduce congestion as well.
These factors have led to the need for more distributed points of data exchange across the internet. Infrastructure edge computing addresses this challenge by the implementation of an edge exchange (EX) within infrastructure edge data centres. Conceptually, this idea is simple; a smaller‐scale version of the functions performed by an IX can be implemented inside an infrastructure edge data centre to allow networks to exchange data at locations closer to the endpoints, which are generating the traffic in order to decrease latency and minimise the cost of data transportation. This topic will be explored in a later chapter in this book, but its existence is a useful primer for the reader at this point as well.
Many agreements to exchange data between networks are reciprocal. One network may agree to interconnect with another because each network would bring a roughly equivalent benefit to the other, in terms of accessible endpoints and resources as well as establishing a balance in terms of the volume of traffic that each sends and receives with the other network, creating an equilibrium.
However, this understanding has been tested in recent years by the widespread use of streaming video services and other networks which send orders of magnitude more traffic than they receive. These services can place significant strain on the networks which they interconnect with due to the sheer bandwidth use generated by the widespread adoption of these services. This has prompted some network operators to move such relationships away from traditional reciprocal agreements.
Other agreements are considered “pay to play” arrangements, where a network may agree to interconnect with another network only if that other network agrees to pay for them to do so. Future payments may then be organised on a usage basis or on some other means as agreed between the parties involved. Although unpopular with some, the idea of paying for interconnection is a viable option where one party requires an additional incentive to interconnect with another. Alternatively the interconnection may not occur, reducing the overall ability of the internet to grow over time.
On‐ramps are an interesting part of network interconnection and exchange which have become more prominent over the past decade with the rise of cloud computing. Although there is some variation in how the term is used, an on‐ramp generally refers to a dedicated piece of network infrastructure which gives one or more parties direct access to the network of a cloud provider. Examples of these on‐ramp services include Amazon Web Services (AWS) Direct Connect [3] and Microsoft Azure ExpressRoute [4]. As more applications operate from cloud instances, such services become increasingly important to minimise latency and the cost of data transportation long term.
3.9 Fronthaul, Backhaul, and Midhaul
Much like the term edge itself, fronthaul, backhaul, and midhaul are all contextual terms. Whether a particular segment of network connectivity fits into any of these three categories depends primarily on the context in which it is observed, specifically by the locations where the network connectivity begins and where it ends combined with the point of view of the person using the terms. Whenever these terms are used, it is worthwhile clarifying the context of the speaker so that the topology that is being described can be fully understood to help to minimise the chance of any resulting confusion.
In the context of infrastructure edge computing, we will use the infrastructure edge data centre as the starting point for our network connectivity when using these terms. This means that when we refer to fronthaul connectivity in this context, it is network connectivity between an infrastructure edge data centre and a piece of network infrastructure such as a telecoms tower or cable headend.
Midhaul in this context refers to the network infrastructure that is used to connect infrastructure edge data centres to one another across an area such as a city. This network is often an example of a MAN, as it connects network endpoints together across an area which is typically the size of a city. Building upon our use of LAN, MAN, and WAN in an earlier section, each infrastructure edge data centre can be considered a LAN in itself, and so the midhaul network infrastructure often does fit our description of a MAN as a network connecting many LANs distributed across a specific area.
Backhaul, when used in the context of infrastructure edge computing, refers to the range of network infrastructure which is used to connect an infrastructure edge data centre back to a piece of regional network or data centre infrastructure. An example of this is a WAN link, which is used to connect one or more infrastructure edge data centres to an IX in a neighbouring city. As such, this connectivity is typically a WAN although, depending on the distance required, it may alternatively be called a MAN.
The way in which we will use these terms throughout this book can be seen in the diagram in Figure 3.4. Terms denoting geographical network scale such as LAN, MAN, and WAN are overlaid as appropriate:
