On Service Chaining and Segment Routing · Segment routing is a very new technology and many elds...

Bachelor Informatica

On Service Chaining andSegment Routing

Blaser, Johannes

8th June 2018

Supervisor(s): Dr. Grosso, Paola

Co-Supervisor(s): MSc. Kaat, Marijke

Informatica—

Universiteit

vanAmst

erdam

Abstract

Segment routing is a modern incarnation of the source routing paradigm. In addition todefining the destination of a packet the path can also be defined through a list of segments.This gives great traffic engineering capabilities and packets can be manipulated so that theyadhere to a specific requirement.

The segments can also represent network functions and local instructions which areapplied to the packets. When chained together these functions allow for a complex pro-grammable network to be built from simple building blocks through the segment list.

The purpose of this research is to analyse the usability, effectiveness, and drawbacks ofusing segment routing to implement service chaining. Analytic experiments show segmentrouting like behaviour only occurs roughly 40% of the time at best under very specificcircumstances using destination based routing. The performance impact is found to increaseproportionally to the size of the segment list with one segment introducing a roughly 40%path length increase. Ordering the segments optimally negates this impact significantly. Asegment list containing five segments shows a 20% path length reduction. Anycast segments– multiple services responding to the same address – allow for similar improvements.

This research concludes by sketching the outlines of a tool used for optimising the imple-mentation of a service chain by using segment routing given a certain topology. This is donebased on the information and conclusions drawn from the experiments and their results.

3

Contents

1 Introduction 71.1 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2 Research Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Background 112.1 Layers and Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Destination-Based Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.1 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3 Segment Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.1 IPv4: Multi-Protocol Label Switching . . . . . . . . . . . . . . . . . . . . 122.4 IPv6: Segment Routing version 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.1 Optional Type Length Value Objects . . . . . . . . . . . . . . . . . . . . . 142.5 Support for Segment Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.6 Service Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.6.1 SR-Aware Network Functions . . . . . . . . . . . . . . . . . . . . . . . . . 152.6.2 SR-Unaware Network Functions . . . . . . . . . . . . . . . . . . . . . . . 15

2.7 Service Chaining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.8 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.9 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Simulation 193.1 Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.1 Abstract Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.1.2 Real Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.1 Random or Topology-Aware Placement . . . . . . . . . . . . . . . . . . . 23

3.3 Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Why Segment Routing? 254.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1.1 VNF Traversal Probability and Expectations . . . . . . . . . . . . . . . . 254.2 Specific Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27


4.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.4.1 Caveat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.4.2 Benefit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5

5 Performance Impact 335.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.1.1 Path Lengths and Expectations . . . . . . . . . . . . . . . . . . . . . . . . 335.2 Specific Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35


5.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.4.1 Caveat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.4.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6 Service Order 436.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.1.1 Topology Unaware Ingress . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.1.2 Segment List Structuring . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.1.3 Commutability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.1.4 Random Shuffling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.1.5 Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.2 Specific Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46


6.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.4.1 Caveat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.4.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7 Anycast-Prefix Segments 537.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.1.1 Anycast-Prefix Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.1.2 Performance Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.1.3 Expectations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7.2 Specific Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56


7.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607.4.1 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

8 Overall Discussion 638.1 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638.2 Hop Count and other Performance Metrics . . . . . . . . . . . . . . . . . . . . . 648.3 Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

9 Towards a Prediction Tool 679.1 IEEE Software Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689.3 Overall Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699.4 Specific Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

10 Conclusion 73

6

CHAPTER 1

Introduction

Computer networks are everywhere. The largest and best-known protocol is the Internet Protocol– IP for short. This protocol is part of a larger stack of protocols that together form functionalnetworks where data can flow from one device to another. These networks grow and develop allthe time and one of these recent developments is the focus of this research: segment routing.

The internet protocol itself offers the addressing scheme [19] of the internet protocol stack[13]. The other protocols in the stack determine how the data gets to the destination. Since theinternet protocol only specifies the final destination of the data the stack of protocols in essenceoffers a destination based routing approach.

The intermediate nodes in the network use the final destination and look up which interfacecorresponds to that address. This information determines the path used. Since this evaluationoccurs at each intermediate node the path is traversed and determined in a hop-by-hop fashion.The full path is thus never really defined anywhere but inferred as a consequence of the currentstate of the network. This allows the packets to be simpler, but leaves limited traffic engineeringcapabilities.

At the time the internet protocol was introduced [23] the source routing paradigm was alsointroduced. Source routing not only contained the final destination of the packets but also alist of intermediate nodes the packet ought to traverse along the way. This offered great trafficengineering capabilities as the paths were now defined in full at the source node. Based onload or any other factor packets could be routed so that they adhered to a desired behaviourcharacteristic. At the time source routing was commonly used to perform troubleshooting on anetwork.

Outside of traffic engineering capabilities source routing potentially allowed for network func-tions to be applied to the traversing data. By hosting specific services in certain nodes of thenetwork they could be addressed through the list of addresses. Packets of data could thus select-ively be routed through these services. This made the network as a whole programmable andvastly expanded the possibilities.

As with many technologies however ways were found to exploit this behaviour. Addressspoofing and amplified Distributed Denial of Service (DDoS) attacks were some of these exploits.The security concerns associated with source routing later led to its deprecation.

These security concerns are addressed and presented alongside a great deal of new function-alities in the new life of source routing: segment routing. Network programmability for exampleis extended by the inclusion of metadata. Other concepts like anycasts where multiple networknodes respond to the same address are included to spread load and reduce latency. All thistogether creates a system that promises simple deployment, great scalability, network program-mability, failure protection, and mostly excellent traffic engineering capabilities [4].

Segment routing thus brings source routing into the IPv6 era. It solves the concerns that camewith source routing and introduces many new functionalities. Still new and in development at thetime of this writing the full scope of segment routing’s possibilities – and potential complications– is not yet fully known, though use-cases seem plentiful. It is clear however the desire for controlover data did not disappear with source routing.

7

1.1 Research Questions

Segment routing is a very new technology and many fields are yet to be explored. This researchtakes a high-level analytic approach to segment routing. Through a number of experiments thisresearch aims to figure out whether segment routing indeed offers something new and useful thatother routing paradigms could not have offered. Even if segment routing offers something unique,it would be downright unusable if it brought on excessive performance impacts. Whether thereis a performance impact and how big it is if there is one is also investigated in this research. Ifa significant performance impact does exist there are likely also ways of reducing and mitigatingthe impact at least somewhat.

These topics can be roughly divided into four research question:

• How often does segment traversal occur in destination-based routing paradigms? Segmenttraversal might occur coincidentally in destination-based routing paradigms. If this occursoften enough or can be made to occur sufficiently often segment routing might not offer asignificant advantage. This research question is analysed in chapter 4.

• What is the performance impact – if any – of segment routing? The behaviour segmentrouting offers could offer a plethora of use-cases but if the performance impact makes thenetwork practically unusable it may not be desirable to use segment routing after all. Thisquestion quantifies the performance impact through an experiment presented in chapter 5.

• What is the effect of the order of segments in a segment list? The order the segmentsare traversed in could be quite consequential to the performance of a given service chain.Bouncing data across the entire network multiple times could be quite time-consuming.This question analyses how much the order of the traversed segments matters for pathlength performance through the experiment presented in chapter 6.

• What is the effect of using anycast-prefix segments in segment routing? The aforementionedanycast segments are one singular address that has multiple service nodes responding to it.This question analyses the effects of the number of nodes that respond to the same addresson path length performance. The research question is analysed through an experiment inchapter 7.

These results will indicate the usefulness of segment routing for implementing a chain ofservices. Since there are likely quite a few variables with segment routing there is probablyroom for optimisation when implementing a chain of services with segment routing in a givennetwork. Reasoning from the answers to the above research questions this research will presentthe theoretical outline of a tool that can make suggestions and optimisations for implementing aservice chain with segment routing in a given network. The tool is aimed at network operatorswanting to implement a service chain with segment routing.

8

1.2 Research Outline

This research starts by explaining the history and workings of segment routing in chapter 2.The implementation of the experiments is then explained in chapter 3. This chapter describesthe part of the simulations that is shared among all simulations as well as the topologies andnetworks used in the experiments.

The four chapters 4, 5, 6, and 7 describe and present the individual experiments. First thecorresponding research question is presented and the purpose of the experiment is explained.The implementation specific to that experiment is then provided alongside the expectations andspeculations for the outcome. The results are presented and discussed thereafter.

The following chapter 8 discusses the combined findings of the experiments. It reflects onhow the experiments were performed and possible additions to them as well as summing up theresults and their implications.

Based on the discussion in chapter 8 chapter 9 presents the theoretical outline of the optim-isation tool. This chapter first notes the relevant information from the experiments and thendescribes how this can be used to create a tool to best implement a chain of service functionsthrough segment routing in a given network.

The research closes with a conclusion presented in chapter 10 where all the findings are brieflysummarised and presented.

9

CHAPTER 2

Background

As the introduction mentioned segment routing is based on the source routing [32] paradigm andis not a new concept in itself. This chapter starts by explaining where segment routing camefrom and how it is different from the commonly in use destination-based routing paradigms. Theinner-workings of segment routing and how it can be implemented are then discussed in moredetail. Lastly other methods to define a path and guarantee its traversal are discussed briefly.

2.1 Layers and Routing

Like most networks the internet is built on layers of protocols each responsible for a specificfunction [27][3]. In the internet this stack is referred to as the Internet Protocol Suite [13].Similar to in the Open Systems Interconnection (OSI) model [38] packets travel through thelayers as the packets traverse a network. The lowest layers are responsible for transmissionacross physical links while higher layers offer functions like message authentication and more.

The Internet Protocol (IP) [13] is the layer responsible for providing addressing in a network.Every interface in the network is provided a unique address so that it can communicate with otherinterfaces. The internet protocol offers a way to define the source and destination of packets.Other supporting protocols like Open Shortest Path First (OSPF) [28][9] provide the actual paththe data takes through the network based on the addressing information supplied by the internetprotocol. In this way the routing is based on the destination given by the internet protocol.Segment routing offers a way to define not only the source and destination of data but also a listof intermediate addresses that have to be traversed. The actual routing – generating the path toget data from source to destination – is still performed by underlying supporting protocols likeOSPF.

2.2 Destination-Based Routing

Most current networks are built on these destination-based routing paradigms. The most commonexample is the internet protocol, which comes in two version: the Internet Protocol version 4(IPv4) [23] and the Internet Protocol version 6 (IPv6) [19][6]. Segment routing offers supportfor both the IPv4 and IPv6 dataplanes. Since these two versions are implemented in a slightlydifferent way they are both explained in more detail in the following sections. The focus of thisresearch is the implementation for the IPv6 dataplane.

2.2.1 Addressing

Most destination-based routing paradigms function in a similar fashion: they include in oneway or another the destination information of the data. One such example is the IPv6 headerwhich includes both the source and destination of the packets [19]. This is shown in figure 2.1.Though some other information can also be included in the IPv6 header there is no way to include

11

intermediate hops in this header. Protocols like these are referred to as destination-based routingparadigms in the context of this research.

Each interface has a unique IP address. In IPv4 this was a 32-bit address [23]. Since thisallowed for only around four billion unique addresses to be created the internet “ran out” ofavailable addresses as the internet grew. To combat this lack of address availability IPv6 uses a128-bit address instead [19].

Figure 2.1: The IPv6 header as given by its specification [19].

2.3 Segment Routing

Both the IPv4 and IPv6 implementations of segment routing allow for the definition of a list ofsegments that have to be traversed by the packets. In this sense segment routing is a segment-based routing paradigm instead of a destination-based routing paradigm. If no segments aredefined in the segment list segment routing is no different than destination-based routing andfunctionality is identical. Segment routing merely offers the ability to define paths through thesegment list. Calculating such a segment list in addition to the final destination does introducemore complexity than in a strictly destination-based routing paradigm.

Each segment on the segment list is referred to by its Segment IDentifier (SID) [11]. Thissegment list can be defined either strictly or loosely. When the segment list is defined strictlythe segments and only the segments that are in the segment list are allowed to be traversed.The full path of the packet is thus specified in full in the segment list.

The loose definition requires all the segments on the segment list to be traversed, thoughadditional nodes can also be traversed in between even if they are not in the segment list. Thesame underlying routing protocols are used to route between the segments in the segment list asare used in regular IP. One such example would be Open Shortest Path First (OSPF) routing[28][9].

2.3.1 IPv4: Multi-Protocol Label Switching

In the IPv4 dataplane segment routing can be encoded as a direct addition to the Multi-ProtocolLabel Switching (MPLS) [37] paradigm without requiring any additional changes to the for-warding plane [1]. In MPLS long IP addresses are replaced by simple and short path labels.This avoids relatively complex lookup tables which at the time MPLS was created brought a

12

significant performance advantage. These MPLS packets could encapsulate data from multipleother protocols which is where it gets the multi in its name from. Since the introduction of newand significantly faster switching techniques [15] the main use of MPLS shifted from a speedadvantage to a traffic control advantage.

MPLS works by prefixing packets with an MPLS header containing a number of labels. Thecollection of all labels is referred to as the label stack. Each entry in the stack contains four fieldsto identify the label, traffic class, bottom-of-stack indicator, and time-to-live indicator. This isshown in figure 2.2.

Figure 2.2: The MPLS label stack entry as per specification [37].

As labels are traversed through Label Switch Routers they are popped off the stack. Theold label is thus removed from the header and replaced with the next label. At the edges of theMPLS domain Label Edge Routers form the ingress and egress nodes to the MPLS domain. Theypush MPLS labels onto incoming packets and pop them off of outgoing packets. Label SwitchedPaths are thus created at these edge routers.

Segment Routing with Multi-Protocol Label Switching

Segment routing is implemented in the MPLS dataplane by simply encoding a Segment ID (SID)as one of these labels. This requires no alteration to the MPLS forwarding plane. The label stackthus forms the segment list. As the data traverses the network the segments are still popped offthe label stack or segment list. At the egress node the MPLS header – and thereby the segmentrouting information – is in essence stripped.

2.4 IPv6: Segment Routing version 6

Figure 2.3: The SRv6 header as given in its draft specification [31].

Implementing segment routing on the IPv6 dataplane requires a bit more work. Here SegmentRouting version 6 (SRv6) adds a new extension header – the Segment Routing Header (SRH).This header is shown in figure 2.3. Similar in general structure to the IPv6 header this SRv6header adds a list containing n Segment IDs (SIDs) along with some additional information.

13

The segments in the segment list are encoded as regular IPv6 addresses. In this way SRv6 com-bines the expandability, scalability, and usability of IPv6 with the traffic engineering capabilitiesbrought by the source routing paradigm. The rest of the networking stack remains unalteredand the same protocols are used as in the regular IPv6 dataplane, making the implementationof SRv6 relatively conceptually straightforward.

The SRH contains some information along with the list of segments to be traversed. TheNext Header and Hdr Ext Len field are as defined in the IPv6 specification [19] [31]. These pointto the next header and the length of the extension header in octets respectively. The RoutingType field is yet to be defined at the time of this writing.

The Segments Left field defines how many segment are left that need to be processed [31].The Last Entry field refers to the zero-based index of the last element that was processed inthe segment list. In MPLS processed labels are popped off of the label stack. In SRv6 howeverthe list remains intact within the SR domain. If there are more than 0 segments left the nextsegment is processed as per usual. Because this field consists of 8 bits the maximum segmentlist length is 28 = 256 segments.

The Flags field contains 8 flag bits. Currently only flag 4 (zero-indexed) is defined in thesegment routing draft. Flag 4 indicates whether Hashed Message Authentication Code (HMAC)is used in the Optional Type Length Value Objects field of the SRH. This HMAC can be usedfor security purposes. It consists of a HMAC key and HMAC itself. Using these it checks boththe integrity and authenticity of the data in the packet [31]. The other flags are currently unusedand reserved for future use.

The Tag field allows the packet to be tagged as part of a certain communication stream,class, or group. This way certain types of data can be processed independently. Following thisis the list of segments themselves defined as IPv6 addresses. At the end of the SRH there is anoptional field that can be used for appending specific data like the aforementioned HMAC.

2.4.1 Optional Type Length Value Objects

The optional Type Length Value objects (TLVs) follow the format given in figure 2.4. The typefield defines the type of TLV that is included and the length field defines its length. What comesbehind it depends on the type of field that is used. The aforementioned HMAC TLV is one suchexample though similar TLVs exist for padding and can be further extended for future uses.

Figure 2.4: The optional Type Length Value objects field format as given in its draft specification[31].

The TLVs thus contain data that may be used by the destination node of the packet. Theinformation is not intended to be transferred to different protocol stack layers. Encoding multipleTLVs in the same header is allowed. Fully SR capable routing nodes are able to alter theinformation in and restructure completely the optional TLVs in the SRH. Whether this is allowedby the sender is indicated by setting the most significant bit of the TLV type field to 0 or onefor immutable or mutable TLVs respectively [31].

14

2.5 Support for Segment Routing

At the time of this research segment routing is still very much in its development phase. WithRequests for Comments (RFCs) and Internet Drafts still actively being put out there is still a lotof development to come. Since Linux Kernel version 4.10 the dataplane functionalities enablingsegment routing packet generation have become available. At present not all endpoint functionsused by the final destination of the segment routing packets have been implemented [12] [4].

Similarly the Fast Data Project (FD.io) [8] is working on an implementation of segment rout-ing for IPv6 and currently provide an up-to-date implementation of SRv6 network programmingsupport [8]. Their implementation leverages the Vector Packet Processing paradigm.

The spring working group from the IETF [11] is the main working group responsible forpublishing most of the publications and drafts on segment routing at the time of this research.There are also some books published on the topic [10]. Clearly however there is still a long wayto go in terms of implementation and support for segment routing.

2.6 Service Functions

Segment routing packages may encode simple routing instructions for forwarding packets alonga specific path but may also encode rich behaviours to support advanced use cases. One suchexample are Service Functions or Network Functions (SFs or NFs) [5].

These functions are executed on the packets traversing them. Network or service functions –virtual [18] or physical – form a network-architectural concept for creating functional “blocks”.These can be used to create, connect, or chain communication services in a given network. AVirtual Network Function (VNF) [2] for example could be a load balancing service that routespackets based on the current network load.

In the context of segment routing service functions can exist both virtually or physically.The segments then address these service functions through the SID. The segment list containsnot only nodes the data has to merely traverse but can also include functions that have to beapplied to the packets [5]. IPv6 also natively supports the transfer of metadata making theimplementation simpler using SRv6.

Since these service functions can be both virtual or physical they can be easily deployed indifferent situations. Network functions can be capable of dealing with segment routing nativelyand fully support its operations or not. When speaking of a function that can behave properly inthe presence of SR information it is referred to as an SR-aware network function [5]. Converselyincapable network functions are referred to as SR-unaware network functions.

2.6.1 SR-Aware Network Functions

A fully SR-aware function is able to process all the information given in the SRH. An SR-awarefirewall for example might be able to filter data based on its final destination. This informationcan be extracted from the SRH. The underlying system the network function is running oncan directly feed the packet into the SR-aware network function. These functions are able andallowed to retrieve from, store in, or modify altogether the information in the TLV fields [5].

2.6.2 SR-Unaware Network Functions

SR-unaware network functions are incapable of dealing with information provided in the SRH.When these functions receive a packet with an SRH it might drop the packet altogether or takeerroneous decisions based on misinterpreted information from the SRH. These could be networkfunctions designed to deal with regular IP headers or raw data instead of SRv6 data. The systemthese SR-unaware functions are running on thus must strip the segment routing information fromthe packets before passing them on to the service functions [5].

This could be achieved by completely stripping and storing the SRH at the node the VNFruns on. The decapsulated packet could then be passed on to the network function. When thefunction returns the data the node would reappend the SRH to the correct packet. The packetwould then be reintroduced into the SR domain.

15

2.7 Service Chaining

The real power of using these network functions however lies in chaining multiple simplisticnetwork functions together to form a complex chain of network functions – a service functionchain. Since segment routing allows individual network functions to be addressed and suppliedlocal instructions they can be chained together using the segment list in the SRH. The servicefunctions are selected by a service classifier. The ordered set of service functions form the ServiceFunction Path (SFP) for the associated Service Function Chain (SFC) [17]. The service classifierwould need to attach all the relevant information to the packet specifying which Service FunctionForwarders (SFFs) and service functions ought to be traversed by the traffic, associated SFC, orthe partial SFP.

Looking at figure 2.5 for example two distinct flows of traffic are visible. The blue traffic visitstwo service functions, service functions B and F. SF B could contain a compression function whileF contains an encryption function. The green traffic would have the same final destination butno need to traverse these functions. Instead it would only traverse a firewall located in servicefunction C. The traffic flows and associated segment lists from the SRH are illustrated in figure2.5 and table 2.1 respectively.

Figure 2.5: An example network with two classes of traffic routed through it [4].

Traffic Class Green Traffic Blue Traffic

Segment Source Node A Node A

Segment 0 Service function C Service function BSegment 1 N/A Service function F

Segment Destination Node Z Node Z

Table 2.1: An example segment list corresponding to the traffic flows given in figure 2.5.

2.8 Use Cases

The chaining of services offers many possibilities. A website that allows for the uploading ofdata might want to have all the incoming data to go through a firewall, be compressed, and beencrypted. Doing all of this in the servers of the website could be too complex or simply notpossible. If the services could be split and spread across the network the data might have allthese operations applied to it before it arrives at the target website, saving significant complexityat the website. Segment routing is one way to achieve such service chains efficiently and reliably.

As the website grows more popular it could be desirable to host more of the same functionsand spread them across the network. Instead of simply duplicating the service and manuallyaddressing either one or the other the usage of anycast segments allows a group to be definedwhere all the included services respond to the same address and perform identical operations. Tosegment routing this still appears like a single address but the underlying protocol can return adifferent member of the anycast-group for different situations. Protocols like Equal-Cost Multi-Path [20] routing could return whichever anycast-group member is closest to a given ingress node

16

for example. This approach would also be very scalable, especially if the services are virtual. Asthe load increases new services could be spun up dynamically and traffic rerouted through themto balance the load based. Using these anycasts is simple to implement with segment routing.

Security too could benefit from using segment routing. In a Distributed Denial of Service(DDoS) attack a given server is flooded with data; rendering it inoperable. By routing all thetraffic through firewalls – which could be spread out to deal with the load using the anycastsegments again – the traffic could be marked as “safe” or “unsafe”. The safe traffic could beinjected back into the network as per usual, while the unsafe data could first be routed througha scrubber before being re-injected into the network. This could all happen without overloadingthe target server [7].

2.9 Related Work

Segment routing is not the only way to achieve path-based routing however. The aforementionedMPLS for example offers the ability to specify paths in a network. MPLS however offers littlecapability to use network functions and create a chainable and programmable network.

Network programmability and service chaining is not only achievable through segment routingeither though. Other methods like the Network Service Header (NSH) [33] imposed on packets orframes also offer the ability to realise Service Function Paths (SFPs). Much like segment routingNSH is also capable of exchanging metadata along the instantiated service path. Through NSHencapsulation service function chains can also be implemented. NSH works by introducing newheaders and using encapsulation to send the original packets through a network.

Segment routing then isn’t the only way to achieve network programmability. This researchhowever focuses on the specific set of functionalities offered by segment routing and the compar-ison between destination-based routing and segment-based routing.

17

CHAPTER 3

Simulation

To be able to answer the research questions a general framework is used to run simulationsand perform experiments on a number of network topologies. The simulations aid in analysingtraversal statistics, performance impacts, and optimisations of implementing service chains withsegment routing. Since the experiments are performed on simulations the service functions usedare referred to as strictly Virtual Network Functions (VNFs). The experiments are detailed inthe following chapters.

The topologies used in the simulations are outlined in section 3.1. Section 3.2 will discuss theframework of the simulations. Each research question requires a slightly different approach to itsimplementation. This chapter describes the shared commonalities of the simulation frameworkin section 3.2. The source code of the simulations is available at the end of this chapter in section3.3.

3.1 Topologies

To answer the research questions multiple simulations are performed. The simulations investigatetwo main categories of topologies: abstract and real network topologies. The prior are based onrough network types like a star graph with a central node, or a ladder graph with long stretchingpaths.

These abstract topologies are unlikely to be found in actual networks since a ladder graphis often not practical in real networks due to its long longest paths. Similarly graphs like thestar graph have an increased complexity in the centre node which forms a vulnerable centralsingle point of failure. A star graph can be completely taken down by the centre node goingdown. Since failures and maintenance are relatively common in networks this makes a stargraph poorly applicable in real life applications [35]. These abstract network types thus won’tnecessarily be found often in real networks. They are analysed though as they could show certaintopology-based characteristics when combined with segment routing.

Three real network topologies are also used. These are based on national and internationalresearch networks and will likely show more useful results for real-world applications.

3.1.1 Abstract Topologies

The abstract topologies symbolise a general network style. Though real networks won’t oftenhave one singular node in the centre like a star graph, they might be arranged with a moretightly connected centre and lose branches originating therefrom. The experiments also look atwhether these abstract network types exhibit defining characteristics and are recognisable in thereal networks.

To show the effect of different sizes of these networks on the experiment a small, medium, anda large network are used. In the experiments the small graph consists of 15 nodes, the mediumgraph of 30 nodes, and the large graph of 60 nodes. Across all experiments the graph is onlyaccepted if all nodes are connected. Disconnected graphs are not considered.

19

(a) Simple (Barabasi Albert) graph (b) Star graph

(c) Tree graph (d) Ladder graph

Figure 3.1: A collection of the four abstract network topologies used in the experiments. Alsoincludes a path from ingress to egress over a given function node. Except in the star topologythe source is node 0, and the target is node 19. The function node is randomly allocated to beneither one of these.

The simulations use four abstract network styles. Possibly the most realistic of these isthe simple graph shown in figure 3.1a. This is generated as a Barabasi-Albert network usingNetworkx [16].

Symbolising a highly centralised network with one node in the centre is the star graph shownin figure 3.1b.

Another network with a central connection is the tree graph, though this allows for branchesand satellite nodes coming out from the centre. This is shown in figure 3.1c.

Lastly a ladder graph is used. This topology has a long backbone of cross-connected nodes.As the network grows the entire ladder grows as well. This means that larger network sizes resultin far longer longest paths in the network, symbolising the characteristics of a linearly connectedgraph though with slightly more interconnections. This is illustrated in figure 3.1d.

An overview of all abstract topologies is given in figure 3.1.

3.1.2 Real Topologies

The realistic topologies implement a number of real (National) Research and Educational Net-works ((N)RENs). The used examples are the NORDUnet topology [29], the GEANT network

20

topology [14], and the SURFnet topology [36]. The former two are acquired from their officialwebsites, and the latter is acquired directly from the co-supervisor of this research.

The topologies are implemented in Networkx where the nodes are simple numbers and thespecific characteristics of the links are not taken into account. These can include physical distanceand available bandwidth. Performance is generally measured in number of hops in the contextof this research. These topologies simulate real network interconnections and do not simulaterealistic bandwidths nor latencies.

The smallest real network used in the experiments is the NORDUnet topology. With only24 nodes this network is closest to the medium size of the abstract topologies. The topology ofthe network is given in figure 3.2. Visually this topology bears closest resemblance to the ladderor simple graph since it lacks an explicitly centrally connected node.

Figure 3.2: The NORDUnet [29] topology provided on their official website at the time of thisresearch.

The next considered REN is GEANT. This network does appear to have more centralisednodes with satellite branches coming out. Germany for example contains such a central node.This makes it visually more similar to the tree graph mentioned before.

Figure 3.3: The GEANT [14] topology provided on their official website at the time of thisresearch.

21

Lastly SURFnet’s topology is implemented. This networks consists of central nodes andnodes along a linear path. The topology is shown in figure 3.4.

Figure 3.4: The SURFnet [36] topology provided by the co-supervisor of this research. Thenetwork used is SURFnet’s core network.

3.2 Implementation

The experiments performed in chapters 4, 5, 6, and 7 are implemented in the Python program-ming language. To create and perform operations on the networks described previously thepython library Networkx [16] is used. Built-in functions like the one to calculate the shortestpath between two nodes are used to determine the routes through the network.

In this sense there exists no routing table that is set up before the experiments – there is noknowledge of the paths a priori. Whenever two nodes are picked as the source and destinationthe shortest path is looked up using the Networkx built-in functions. Depending on the routingprotocol and its specifics these paths represent a path a packet would take in a similar realnetwork. Not using a table with a priori path knowledge saves some implementational complexityin these experiments.

It can occur – especially in topologies like the ladder graph – that many multiple equallength shortest paths exist. Whenever multiple paths of equal length are encountered in any ofthe experiments an arbitrary choice is made between them. In this case whichever path Networkxreturns first is used, unless otherwise specified in the experiment’s description.

In general the experiments are set-up to run in a double loop. The outer loop is labelledtopologies and defines how many times the graph is recreated and the VNFs are placed in thenetwork. For the real networks this does not make a difference except for where randomly placedfunctions are located in the network. A randomly generated Barabasi-Albert network howeverwill be regenerated this many times.

In the experiments both the results and spread thereof are interesting. The standard deviationis taken as a measure to indicate what the range of spread is. This gives an idea of how consistentthe results are and how precisely they describe the results.

The inner loop is how many unique source and destination pairs are taken and averaged. Thisis labelled cycles. The standard deviation and average are taken. For these general statisticsNumerical Python (Numpy) [30] and Scientific Python (Scipy) [25] packages are used.

The statistics are visualised using the Matplotlib (Pyplot) [21] package. In general howeverthe blue colour symbolises random VNF placement, and the green colour symbolises topology-aware VNF placement if applicable.

22

3.2.1 Random or Topology-Aware Placement

During the experiments the VNFs are placed randomly or in a topology-aware manner. Whenplacing the VNF randomly there are no restrictions other than that the node be connected tothe graph and can be neither the source nor destination nodes. The VNFs are placed beforethe source and destination pairs are picked so this consideration is done when placing the sourceand destination nodes. Placing the VNF on either one of these would result in a guaranteedtraversal probability with path length equal to the shortest path from source to target. Likewisethe source and destinations nodes can’t be placed on the same node. The path length would bezero hops and neither of these cases would be interesting.

Topology-aware node placement refers to placing the node in a manner that maximises thelikelihood of traversing the node on the shortest path. When referring to topology-aware place-ment the nodes are placed in order of decreasing degree. If one VNF is placed, the highest degreenode is used as a location for the VNF. In the case of two VNFs the two nodes of highest degreeare used. And so on and so forth for the desired number of VNFs.

Since the ladder graph contains only equally connected nodes – apart from the ends – theVNFs will be placed along the centre of the network. Additional VNFs will be placed alternatingto the left and right of this centre, meaning the “cluster” of VNFs grows from the centre outwards.This does imply the VNFs will be placed as neighbours which is not necessarily the case in theother networks.

Lastly star graphs always have their VNFs placed at the centre, though this is by verydefinition also always the most connected node. Additional VNFs can only be placed arbitrarilyas all nodes other than the centre node are equal.

3.3 Source Code

The source code used for the experiments presented in the previous chapter is hosted on Github.All the files are accessible via the following link:

https://github.com/Johanmyst/segment

.

23



CHAPTER 4

Why Segment Routing?

This chapter looks at the experiment corresponding to the first research question:

• How often does segment traversal occur in destination-based routing paradigms?

4.1 Description

Segment routing offers guaranteed segment traversal. Segments – specific nodes in the network– might also be traversed coincidentally when using destination-based routing however. Thisexperiment aims to quantify how often segment traversal occurs in destination-based routing. Ifthis namely occurs sufficiently often segment routing might offer little advantage over destination-based routing.

4.1.1 VNF Traversal Probability and Expectations

Picking an arbitrary path through a network means some nodes will be on this path and otherswill not be. Making this observation for many arbitrary paths yields a probability any givennode will be on an arbitrary path – the traversal probability. It seems likely certain nodes aremore likely to be traversed than others. More connected nodes have more connections, so morepaths through them are possible. More paths suggests a higher traversal probability. If a VNFis placed on this node the traversal probability would thus equally be higher. When the VNF istraversed coincidentally this is the same behaviour offered by segment routing. This probabilityis likely heavily topology-dependent.

Destination-based routing paradigms offer optimal path routes. In the context of this researchand experiment optimal is only defined by the path length. Whenever a given VNF happens tolie on this path there is no increase in path length of routing through the VNF. The traversalprobability is thus likely directly correlated to the path length.

Questions

The questions posed for this experiment are as follows:


– What is the probability of VNF traversal in simple and real network topologies?

– What is the influence of VNF placement on said probability?

– What is the effect of the number of VNFs on said probability?

25

4.2 Specific Set-Up

To do this the probability of traversing one and two VNFs in a given network topology is analysedfor both abstract and real topologies.

A network is generated 1000 times and VNFs are replaced at every network generation.Within this network a VNF is placed either at random (shown in blue in the results) or topology-aware (shown in green in the results). Each network then has 100 unique source and destinationpairs evaluated.

When more than one VNF are placed in the network their order is predetermined and set. Incase of random VNF placement the order will also be random. In case of topology-aware VNFplacement the order will be in terms of decreasing degree. VNFs that are equally well connectedare picked based on Networkx’s order of returning the degree sequence. Segment list reorderingis analysed in chapter 6.

The shortest path between a source and destination pair is taken. The simulation thendetermines whether the VNF was on the path or not. The number of times the VNF was on thepath is divided over the number of source and destination pairs considered to yield the traversalprobability.

For each network the standard deviation of the sample is also determined. The averageprobability and standard deviation are then visualised in a bar graph.

26

4.3 Results

The following two sections show the results of the experiment for abstract and real networktopologies in order.


Figure 4.1: The probability of traversing a randomly or non-randomly placed VNF in differentnetwork topologies using destination-based routing algorithms. Here one singular VNF is used.The graphs are regenerated 1000 times, and the average over 1000 cycles per graph is taken. Theerror bars represent the average standard deviation per graph.

The probability of traversing one VNF in an abstract network is given in figure 4.1. Topology-aware placement appears to yield a significantly higher traversal probability. The star topologyachieves certainty of traversal when placing the VNF in the centre of the network. For the treegraph there is also still a significant increase in probability when using topology-aware placement.Ladder graphs and simple graphs however show less of an improvement.

The random VNF placement also shows a larger deviation in the samples. As the size ofthe network grows this spread does not appear to reduce nor increase significantly. The overallprobability of traversal appears to decrease as the network size increases.

27

Figure 4.2: The probability of traversing two randomly or non-randomly placed VNFs in differentnetwork topologies using destination-based routing algorithms. Here two unique VNFs are used.The graphs are regenerated 1000 times, and the average over 1000 cycles per graph is taken. Theerror bars represent the average standard deviation per graph.

The probability of traversing two VNFs is given in figure 4.2. The overall probability de-creased significantly though topology-aware placement still outperforms random VNF placement.

Simple graphs show only a marginal probability with topology-aware VNF placement. Bothtopology-aware or random VNF placement in star topologies yields no traversal probability. Thetree and ladder graphs seem to be impacted differently than the simple and star graphs. Thesimple and star graphs have a vastly diminishing traversal probability when traversing multipleVNFs. The tree and especially ladder graph however show a significantly lower decrease.

28


Figure 4.3: The probability of traversing a randomly or non-randomly placed VNF in differentnetwork topologies using destination-based routing algorithms. Here one singular VNF is used.The graphs are regenerated 1000 times, and the average over 1000 cycles per graph is taken. Theerror bars represent the average standard deviation per graph.

The probability of traversing one singular VNF in the real networks is given in figure 4.3. Thenetworks appear to behave relatively similarly though NORDUnet shows the smallest differencebetween random and topology-aware VNF placement. GEANT’s network shows the largestprobability increase from using topology-aware VNF placement. SURFnet performs closer toNORDUnet. All three show a significant and comparable decrease in standard deviation whenusing topology-aware VNF placement however.

29

Figure 4.4: The probability of traversing two randomly or non-randomly placed VNFs in differentnetwork topologies using destination-based routing algorithms. Here two unique VNFs are used.The graphs are regenerated 1000 times, and the average over 1000 cycles per graph is taken. Theerror bars represent the average standard deviation per graph.

Traversing two unique VNFs in these networks yields the probabilities visualised in figure 4.4.The overall probability seems to drop substantially. The spread appear smaller, and the overallshape of the graph is similar to the single VNF probability.

30

4.4 Discussion

When only a single VNF is traversed a traversal probability of roughly 30% to 40% can beachieved through topology-aware placement, though how much exactly is quite topology-dependent.Topologies with central “hub” locations benefit more than networks that are more interconnected.

Full mesh networks would then likely be the worst-case scenario for replicating segment rout-ing behaviour through destination-based routing paradigms. Due to its high interconnectednessthe traversal probability would be low as there exist numerous equal length paths from sourceto destination. It would also be difficult to place VNFs in a topology-aware manner as there areno central nor highly connected nodes.

Comparing the case of one and two VNFs shows a diminishing probability of traversal. Theladder topology however stands out as particularly robust to increasing the number of VNFs.This is likely due to the clustered VNFs. The ladder graph contains a long string of connectednodes placing the VNF in the middle means there is a significant probability of traversing theVNF when crossing the middle of the network. Since the probability of picking a source anddestination at each side of the centre is 50% half of the pairs should cross the centre. This followsfrom the following:

Pleft = 0.5 & Pright = 0.5

Psourceleft == Pdestinationleft == Psourceright == Pdestinationright

Pbothleft = Psourceleft ∗ Pdestinationleft == Psourceleft ∗ Pdestinationleft = Pbothright

Pbothleft = 0.5 ∗ 0.5 = 0.25 = Pbothright

Ptraversecentre = 1 − Pbothleft − Pbothright = 1 − 0.25 − 0.25 = 0.5

When only one VNF is placed at the centre the probability should be roughly half of thissince there are two paths traversing the centre. The case of two VNFs (figure 4.2) shows a slightincrease in traversal probability. This follows from the above since both paths through thecentre now have a VNF on them. This would apply if only one of two VNFs had to be traversedhowever. Since both have to be traversed the probability is still lower.

Comparing figures 4.1 (abstract) and 4.3 (real) show abstract topology characteristics presentin the real topologies. In this sense the traversal probability in NORDUnet’s network bears moreresemblance of the simple and ladder graphs, while GEANT and SURFnet more closely resemblea tree or star graph. This confirms the visual speculations made in chapter 3. The traversalprobability characteristics of a network appears to be indicative and informative of the underlyingnetwork topology structure. Chapter 5 looks at whether the same applies to the performancecharacteristics of a given topology.

The size of the deviation indicates that especially with random VNF placement the resultsare quite spread out. When placing VNFs in a topology-aware manner the spread decreasessignificantly – especially in the single VNF case. This indicates using topology-aware placementincreases uniformity as well as overall traversal probability which may be a desirable quality tohave.

The results make it clear that – especially as the number of VNFs in the segment list increases– destination-based routing paradigms are not particularly well suited for VNF traversal. Alsoclear is the effectiveness of topology-aware placement such as described in chapter 3. PlacingVNFs on the most connected nodes, or in the centre of a star or ladder graph yields significantlyincreased probabilities.

4.4.1 Caveat

Though traversal probability becomes higher placing VNFs at the most connected nodes mightnot be desirable. Placing VNFs on a node increases their complexity. Central nodes in particulardeal with a lot of traffic. Burdening these nodes with complex VNFs might overload those nodes.Attaching VNFs directly to the central nodes instead would yield a small but constant cost.

These central nodes could also house clusters of VNFs similar to the topology-aware VNFplacement in the ladder graph. As shown this scales much better with longer segment lists.

31

Having such a cluster as a directly-attached network could be a good combination of centralityand performance. This will be analysed further in chapter 5. Through destination-based routingparadigms this VNF could never be traversed however as it would only be connected by adedicated direct path.

4.4.2 Benefit

It is evident that traversal probability is rather topology-dependent and may even be indicativeof the topology structure. Through topology-aware VNF placement the traversal probability canbe significantly increased. This can mostly be done by placing VNFs on the central nodes. Theseare often left as simple as possible due to the high data throughput. Increasing complexity inthese central nodes is therefore most likely not an ideal solution.

By definition segment routing offers a perfect traversal probability. Destination based routingdoes not exhibit similar behaviour. This makes segment routing the easier and better solution.

32

CHAPTER 5

Performance Impact

This chapter poses an experiment to investigate the second research question:

• What is the performance impact, if any, of segment routing?

5.1 Description

Chapter 4 looked at how regularly segment routing’s behaviour occurs using destination-basedrouting paradigms. A VNF is only traversed with a certain probability using destination-basedrouting paradigms. This probability could be optimised somewhat. Destination-based routingparadigms follow the optimal path by design. In the context of this research this optimal path istaken to be the shortest path. This implies that when the VNF is not traversed on this shortestpath, the path over the VNF must be longer. Segment routing thus trades guaranteed traversalfor path length optimisation. This experiment aims to quantify this trade-off.

In the context of this experiment and thereafter the term performance refers specifically tothe performance in path length. In real networks these aren’t necessarily directly correlated sincesome links can be shorter than others or have less latency than others meaning some paths canbe faster than others. Observing the path length however should provide a reasonable conceptualtool.

5.1.1 Path Lengths and Expectations

The path lengths over the VNFs are likely to depend strongly on the network topology. If thereexist many paths between all nodes the longest path in the network can not be as long as in onecontinuous line of nodes. The ladder graph is by design much closer to a line with its backboneof linearly connected nodes. The simple graph on the other hand is randomly interconnected sothe longest shortest path is likely not as long as in the ladder graph.

The maximum path length increase when traversing a service chain with segment routingcan’t be greater than the longest shortest path in the network. It seems likely the actual pathlength increase lies somewhere between the optimal situation (as if destination-based routing wasused) and the longest shortest path in the network accounting for going to and from the VNF.

As the experiment in chapter 4 showed placing VNFs in more central nodes resulted in ahigher probability of the VNF lying on the shortest path. The more this happens, the lowerthe impact. It is thus likely the path length increase can be mitigated somewhat by placing theVNFs in a topology-aware manner.

Adjusting the number of VNFs in the segment list also likely increases the path length more.Unless all VNFs happen to be on the shortest path between source and destination the path islonger. As chapter 4 confirmed the probability of multiple VNFs being on the shortest path isextraordinarily low, thus the path with segment routing will almost certainly be longer. As moreVNFs are added to the list it seems likely the path length increase will increase further.

33

As mentioned in chapter 4 it seems probable the ladder graph will incur a lower additionalpath length increase as the segment list grows since the VNFs are clustered. Once the clusteris reached the other VNFs will be relatively closeby. In a ladder graph the cluster is placed onthe ladder’s centre so paths going through the centre already traverse the cluster which growsproportional to the segment list. The maximum distance from any node to the centre of the ladderis half the ladder’s length. Since the distribution of nodes is uniform the expected distance tothe cluster of VNFs should be a quarter of the ladder’s length. Additional VNFs should onlyincrease this distance marginally. As the size of the segment list increases the performance is likelyimpacted little when using topology-aware VNF placement. This experiment also investigatesthe effectiveness of clustering VNFs.

Questions

The question the following experiment will investigate are as follows:

• What is the performance impact – if any – of segment routing?

– What is the performance impact in abstract and real network topologies?

– What is the influence of VNF placement strategy on said impact?

– What is the effect of the number of VNFs on said impact?

– What is the effect of clustering VNFs?

5.2 Specific Set-Up

The average path length increase when using segment routing is analysed for both abstract andrealistic networks for one, two, and three segments in the segment list.

The networks are regenerated 1000 times. In the abstract networks such as the Barabasi-Albert network the connections are thus also regenerated 1000 times. The VNFs are also relo-cated here. Either at random (shown in blue), or in a topology-aware manner (shown in green).For each of these generations of the network 100 cycles are run where one unique source anddestination pair is drawn per cycle.

The error bars display the standard deviation in the cycles. This spread is averaged overthe number of times the network is regenerated. This is then compared against the case whenthere are no VNFs representing destination-based routing algorithms. By subtracting and thendividing over the destination-based routing case the relative path length increase is calculated.This relative impact is then visualised as a bar graph.

34

5.3 Results

The results for the abstract topologies and realistic topologies are shown in that order. Theresults for using one, two, and three VNFs in the segment list are presented in increasing order.


Figure 5.1: The expected path length increase when routing through one singular VNF for anumber of abstract topologies. The single VNF is placed randomly (green) or non-randomly(blue). The optimal path length (destination-based routing) is shown as well (red). The experi-ment is run over 1000 graphs and 1000 unique source and destination pairs per graph. The errorbars show the average standard deviation per graph.

The results of the experiment with one VNF is shown in figure 5.1. A significant differencebetween the impact when using topology-aware and random VNF placement is visible. A cleardifference is also visible between the different topology types when traversing one VNF.

As the network size increases the path length increases as well. It is visible some networktypes are more impacted by size than others. The shape of the discrepancy between random andtopology-aware VNF placement remains relatively similar independent of network size.

35

Figure 5.2: The expected path length increase when routing through two unique VNFs fora number of abstract topologies. The two VNFs are either placed randomly (green) or non-randomly (blue). The optimal path length (destination-based routing) is shown as well (red).The experiment is run over 1000 graphs and 1000 unique source and destination pairs per graph.The error bars show the average standard deviation per graph.

The case with two VNFs is shown in figure 5.2. A very sudden degradation in the performanceof the star topology is clear. The overall impact seems considerably higher compared to the singleVNF case. In the ladder topology especially the discrepancy between topology-aware and randomVNF placement appears to grow.

36

Figure 5.3: The expected path length increase when routing through three unique VNFs fora number of abstract topologies. The three VNFs are either placed randomly (green) or non-randomly (blue). The optimal path length (destination-based routing) is shown as well (red).The experiment is run over 1000 graphs and 1000 unique source and destination pairs per graph.The error bars show the average standard deviation per graph.

Lastly the three VNF case is shown in figure 5.3. The overall path length increase is higherand appears to follow the same pattern. All segment list sizes show a significant improvementfrom using topology-aware VNF placement.

37


Figure 5.4: The expected path length increase when routing through one singular VNF for anumber of realistic topologies. The single VNF is placed randomly (green) or non-randomly(blue). The optimal path length (destination-based routing) is shown as well (red). The experi-ment is run over 1000 graphs and 1000 unique source and destination pairs per graph. The errorbars show the average standard deviation per graph.

The results of the experiment in real networks with one VNF is shown in figure 5.4. The overallshape appears similar to the abstract graph’s shape, and the path length increase is roughlysimilar for each network. The most significant difference between the graphs seems to be in thedifferent placement strategies: random and topology-aware.

38

Figure 5.5: The expected path length increase when routing through two unique VNFs fora number of realistic topologies. The two VNFs are either placed randomly (green) or non-randomly (blue). The optimal path length (destination-based routing) is shown as well (red).The experiment is run over 1000 graphs and 1000 unique source and destination pairs per graph.The error bars show the average standard deviation per graph.

The same shape is still visible when using two VNFs, as shown in figure 5.5. NORDUnetshows the lowest improvement from using topology-aware placement.

39

Figure 5.6: The expected path length increase when routing through three unique VNFs fora number of realistic topologies. The three VNFs are either placed randomly (green) or non-randomly (blue). The optimal path length (destination-based routing) is shown as well (red).The experiment is run over 1000 graphs and 1000 unique source and destination pairs per graph.The error bars show the average standard deviation per graph.

Even more pronounced is the three VNF case shown in figure 5.6. This graph shows a largeincrease in average path length. GEANT’s topology appears to benefit the most from usingtopology-aware VNF placement.

40

5.4 Discussion

Segment routing guarantees traversal by design. Because these segments aren’t always on theoptimal path it consequently does not necessarily guarantee shortest path traversal from sourceto destination. The path length increase can be significant but depends on the topology. Thereal networks showed similar behaviour across the experiment. For introducing one VNF theperformance impact seems to be around 40%. Using two VNFs this increases to roughly 80%.Using three VNFs this impact can go up to 175%. This suggests an exponential performanceincrease, though there is too little data to claim this with certainty. These impacts used topology-aware placement and are a rough estimate of the performance in the NORDUnet network. Theperformance impact is quite topology-dependent.

Placing VNFs in a topology-aware manner is beneficial to the path length, though howmuch depends on the topology. Networks like NORDUnet have a smaller benefit from placingthe VNFs based on the topology. This could be due to the limited size of the network. TheVNFs might be placed at opposite ends if they are simply placed at central locations, leadingto reduced performance benefits. Interestingly enough the visual estimation was made thatNORDUnet appeared closer to the ladder graph. It showed the lowest resemblance to this graphwith decreasing effectiveness of topology-aware VNF placement as the segment list grew. This iscontrary to the expectation. Still the performance appears characteristic of the abstract networktype, though in a different relation than with traversal probability.

The ladder graph behaviour indicates clustering of VNFs is effective. The average pathlength increase grows slowly as the number of VNFs in the cluster grows whereas other topolo-gies showed significant increase with each additional VNF. In the ladder graph the path lengthincrease remained roughly around half the shortest path length. Structuring VNFs as such in anetwork topology would thus be beneficial. Networks like NORDUnet could potentially benefitfrom clustering VNFs given their relatively poor performance even with topology-aware VNFplacement.

The star graph lacks any slowdown in the case of a single VNF because all paths alreadytraverse the centre node – as confirmed in chapter 4. The minimal sliver of average path lengthincrease is because either the source or destination nodes can happen to be placed in the centrewhen there is no VNF occupying it. This ought to happen proportionally to the network size, asthe probability of either the source or destination node being placed on the centre node is givenby the following formula: 1

num nodes .As discussed in chapter 4 it might not be desirable to place all VNFs on the central nodes in

the network due to throughput and complexity constraints. Placing VNFs as directly attachednetworks would only introduce an extra path length of two hops – one hop from the node to theVNF, and one hop back. Since this path wouldn’t be used on any other paths in the network itwould only receive traffic dedicated for the VNFs limiting traffic constraints. This ensures bothcentralised VNF placement as well as the significant performance increase from topology-awareVNF placement.

It seems that topology size matters little for the path length. Though NORDUnet has only24 nodes while SURFnet has 50 there is little difference in their performance nor performanceimpact. The same is true for the simple graph. The only significant difference appears to bein the effectiveness of topology-aware VNF placement. Graphs with long paths like the laddergraph scale worse when using.

The size of the error bars also seems to be quite topology-dependent. The abstract star andsimple topologies have a relatively low spread while the tree, ladder, and real topologies have asignificantly larger deviation. Especially in the real topologies it seems that placing the VNFs ina topology-aware manner yields lower deviation. As the VNFs are randomly placed in the othercase it makes sense the spread is somewhat high. With topology-aware placement the VNFsare in the same locations so the error bars simply represent the range of relative path lengthincreases for different source and destination pairs.

In the abstract topologies this discrepancy also seems logical. When a VNF is placed inthe centre of a ladder topology for example the maximum distance from any given node to theVNF can’t exceed half of the ladder’s length. When the VNF is placed at the very end howeverthe maximum distance can be equal to the length of the ladder itself, twice as long. It follows

41

that the expected range of path lengths follows this pattern and is around twice as large as fortopology-aware centre placement of the VNFs. In the star graph on the other hand any VNFplacement that is not the centre node yields identical results, thus there is hardly any spread.The small deviation that is visible is the proportion of cases where the VNF is coincidentallyplaced in the centre of the star. This should occur proportionally often to the size of the stargraph, again following the following formula: 1

num nodes . With topology-aware placement thecentre node is reserved by a VNF so there is no deviation in path lengths. After the placing thefirst VNF in the star graph the remaining nodes are identical and arbitrary.

Between the three segment list sizes the path length appears to increase linearly or exponen-tially, particularly for the real networks. This excludes the case of the ladder topology with itsclustered VNF placement. However, within this cluster the path length increase might still in-crease linearly, though the overall effects are less pronounced on the overall path length increase.It would be interesting to plot the relative change from using one VNF to using two VNFs in thesegment list. This would show which strategies and topologies are more resilient to the growthof the segment list.

5.4.1 Caveat

Using an immutable segment list has the risk the network has to be traversed multiple times,possibly even via the same path. The clusters in the ladder graph could for example be placed atthe ends of the ladder. If the segment list contained these end-clusters in an alternating fashionthe entire ladder would have to be traversed multiple times. This is an extreme case and chapter6 will investigate this more in-depth.

5.4.2 Benefits

Segment routing offers flexibility and control through defining the path in a network. However,doing so in a careless way evidently has a large path length increase. This impact can be mitigatedto a degree by placing the VNFs in specific place depending on the topology. However, as thesize of the segment list grows the path length will increase proportionally. Proper considerationand care ought to be taken to ensure the path length is increased as little as possible.

42

CHAPTER 6

Service Order

This chapter focuses on the experiment corresponding to the third research question:

• What is the effect of the order of VNFs in a segment list?

6.1 Description

As a segment list grows the path through the network grows accordingly. Shown in chapter 5this segment list was taken to be immutable. In a worst-case scenario the VNFs on the segmentlist are all placed the longest path’s distance away from one another in the network. This impliesthe maximum path length with multiple VNFs in the segment list is equal to the length ofthe segment list multiplied by the longest path’s distance. It seems probable there could besubstantial performance gains from rearranging the segment list optimally. It also seems likelythere is more performance to be gained the more VNFs are in the segment list.

6.1.1 Topology Unaware Ingress

In the abstract ladder topology there exists a central cluster of VNFs. If this cluster was insteadsplit in two and placed at either end of the ladder the distance between them would be equal tothe length of the ladder. If the segment list contained nodes alternating between the one clusterand the other the entire ladder would have to be traversed for every node in the segment list.This would result in the following worst-case scenario where sl is the segment list, s the source,t the target, d() the shortest distance function, and l the length of the ladder:

distance(sl) = d(s, sl[0]) +∑i∈sl

l + d(sl[−1], t)

This is a worst-case scenario but if the segment list could instead be reordered to first traverseall the nodes in one cluster and then the other this could be reduced to (both assuming no internaldistance in the clusters):

distance(sl) = d(s, sl[0]) + d(sl[−1], t)

The ladder will only have to be traversed once fully and twice partially to get to and fromthe source and target. Evidently this path is significantly shorter. In real network topologiesthis benefit might not be in this same order of magnitude but could still be significant.

6.1.2 Segment List Structuring

As mentioned in chapter 2 ingress nodes create the segment list whenever a segment routingpacket is created. Fully SR-aware nodes are allowed to modify the optional type-length-value

43

objects in the segment routing header but not the segment list itself. At the point where thesegment list is created it might thus be interesting to structure this list in an optimal manner.

This experiment aims to analyse the absolute best possible performance increase. The as-sumption is made that all the paths in the domain are known at the ingress node. If only thedistance to each node from the ingress node was known this could yield a sub-optimal path ifthe closest node is in the opposite direction of the target destination. The most likely optionwould be that the ingress node places the VNF closest to it at the top of the list, and there thenext hop is figured out. This doesn’t guarantee the optimal path. This experiment assumes theingress node is fully aware of the network and can arrange nodes in the absolute optimal manner.The other case is implicitly analysed in chapter 7.

6.1.3 Commutability

Reordering assumes the VNFs in the segment list are commutable. Take for example a firewalland compression VNF. The order of execution does not matter with these VNFs – they arecommutable.

Encryption and compression on the other hand could potentially not be commutable. If theencryption fully scrambles the data the compression function likely performs significantly worseas data with maximum entropy can’t be compressed. Though both orders will make it throughthe network; compressing before encrypting will likely yield better compression performance andthe output could be different. It may be faster as well to first compress data since less data toencrypt takes less time to be encrypted.

Segment list reordering assumes commutability. The non-commutable case is investigatedin chapter 5, as that segment list is assumed to be immutable. This experiment looks at thebenefits of reordering the segment list.

6.1.4 Random Shuffling

If a particular VNF is busy or otherwise congested the ingress node could – if the functions arecommutable – decide to first route the data through the other functions. This way the congestedVNF would be offloaded temporarily. This could offer a temporary window where the VNFis able to resume normal operation. If the congestion persists however rerouting the packetsthrough the overloaded VNF last will simply postpone the delay.

The window of offloading might be large enough to compensate congestion in some caseshowever. This experiment analyses whether this reordering of the segment list introduces a sig-nificant performance degradation. If reordering the segment list based on congestion introducesa large performance impact it may not be desirable to do so. Since congestion is hard to predictthis is simulated by randomly shuffling the segment list. This would simulate random VNFsbecoming overloaded and the segment list ordered accordingly. The performance of this shuffledlist (shown in blue in the results) is analysed alongside the optimal segment list ordering (shownin green in the results).

6.1.5 Questions

From the above the following questions are derived:

• What is the effect of the order of VNFs in a segment list?

– What is the effect of the order of VNFs in a segment list in real network topologies?

– What is the influence of the number of VNFs in the segment list on said effect?

– What is the influence of the placement strategy of the VNFs on said effect?

6.2 Specific Set-Up

To analyse the performance gains of reordering the segment list the abstract and realistic networksare considered. The experiment is performed twice. Once using random VNF placement andonce using topology-aware VNF placement. These are presented separately.

44

Using random VNF placement the VNFs are reallocated 100 times. Each generation of VNFsis then cycled 50 times. The 50 cycles mean the smallest network still has enough unique sourceand destination pairs available even with five VNFs reserved. To do this there must be at leasteight free nodes left over. This yields 56 unique pairs. 5+8 = 13 nodes are thus required at least.NORDUnet is the smallest network with 23 nodes which is ample. The previous experimentsshowed little meaningful difference between the different network sizes for the abstract topologies.Hence only the medium abstract topology size of 30 nodes is considered in this experiment.

Each cycle the path length is determined in threefold. Firstly for the segment list as is withoutreordering it as in the experiment presented in chapter 5. Secondly the path length is calculatedwith a shuffled version of the segment list. Thirdly and lastly the segment list is restructuredin the optimal way. This is done by taking all possible permutations of the segment list andcalculating all of their path lengths. The shortest path is taken. If multiple path lengths areequal the first entry Networkx returns is taken.

The distances are averaged and their standard deviation is calculated. The default non-reordered segment list – similar to the experiment in chapter 5 – is subtracted from the othercases. The other cases are then divided over the no-reordering case. This yields the relativeperformance improvement when compared to no reordering. This is then plotted in a bar chartwhere green represents reordering and blue the random shuffling.

The experiment is run from a segment list length of two VNFs – as the case with zero VNFsand one VNF are trivial – until five VNFs. Since the path length of all possible permutationsof the segment list are calculated the computational complexity increases in the order of O(n!).Hence the longest segment list analysed contains five segments. In an actual segment routingnetwork this wouldn’t have to be calculated for each packet that arrives at the ingress node,instead a lookup table would be used, removing the majority of the computational complexity.Searching this would still be in the order of O(n!), but the operations would be faster. Dedicatedand offline route-calculating network controllers do exist. One such example is Juniper’s North-Star Controller system [26]. For the purposes of the experiment however this implementationsuffices.

45

6.3 Results

The following section presents the result of the abstract and real topologies in order. First therandom VNF placement is presented and then the topology-aware VNF placement. Do note they-axis is not consistent across the plots. Within the context of this experiment performance isagain defined as the path length in number of hops.


Random VNF Placement

Figure 6.1: The performance impact of re-ordering, shuffling, or leaving the order of the segmentlist untouched. This is tested for the four abstract topologies. The performance is given in pathlength (number of hops) and this is tested for different lengths of segment lists. Here the VNFsare placed randomly in the network. This placement is generated 100 times. Each iteration istested with 50 unique source and destination pairs. The error bars show the average standarddeviation of each combination of VNFs.

Using random VNF placement the results are shown in figure 6.1. The star graph lacks any im-provement. Each topology appears to benefit slightly differently from reordering the segment list,

46

though all show a performance improvement. Longer segment lists benefit more from reordering.The spread also appears to be topology-dependent.

Topology-Aware VNF Placement

Figure 6.2: The performance impact of re-ordering, shuffling, or leaving the order of the segmentlist untouched. This is tested for the four abstract topologies. The performance is given in pathlength (number of hops) and this is tested for different lengths of segment lists. Here the VNFsare placed randomly in the network. This placement is generated 100 times. Each iteration istested with 50 unique source and destination pairs. The error bars show the average standarddeviation of each combination of VNFs.

Performing the experiment using topology-aware VNF placement is shown in figure 6.2. Thestar graph exhibits similar behaviour. The ladder graph notably drops in performance benefit.Both the simple and tree graph show an increased benefit when combined with topology-awareVNF placement.

47



Figure 6.3: The performance impact of re-ordering, shuffling, or leaving the order of the segmentlist untouched. This is tested for the three realistic topologies. The performance is given in pathlength (number of hops) and this is tested for different lengths of segment lists. Here the VNFsare placed randomly in the network. This placement is generated 100 times. Each iteration istested with 50 unique source and destination pairs. The error bars show the average standarddeviation of each combination of VNFs.

The effects of segment list reordering traversing randomly placed VNFs is presented in figure6.3. The three realistic networks bear strong resemblance in their general shape. The benefit ofreordering appears to increase as the segment list grows.

There appears to be no discernible difference between shuffling of the segment list and leavingit untouched. This holds true for all three networks where in most cases the blue bar is not evenvisible at all.

The degree of improvement does appear to be topology-dependent. Smaller and better inter-connected networks appear to have a bigger benefit from reordering the segment list.

48


Figure 6.4: The performance impact of re-ordering, shuffling, or leaving the order of the segmentlist untouched. This is tested for the three realistic topologies. The performance is given in pathlength (number of hops) and this is tested for different lengths of segment lists. Here the VNFsare placed randomly in the network. This placement is generated 100 times. Each iteration istested with 50 unique source and destination pairs. The error bars show the average standarddeviation of each combination of VNFs.

The results when using topology-aware VNF placement strategy are presented in figure 6.4.Again the shape of the bars appears visually similar between the three networks. As the numberof VNFs in the segment list increases the performance gains relative to the immutable segmentlist seem to increase.

There still appears to be no difference in shuffling the segment list or leaving it untouched.

49

6.4 Discussion

The results indicate significant performance gains from reordering the segment list optimally.Both when using topology-aware or random VNF placement the benefit appears large. Thesmaller NORDUnet network seems to benefit more when combined with topology-aware VNFplacement. The other two real networks benefit slightly more when using random VNF place-ment. With a segment list containing five VNFs the performance increase is around 20%. Theincrease per additional segment in the segment list appears to be linear with roughly 5% perform-ance increase per segment – starting from two segments. Whether this holds after five segmentsin the segment list is outside of the scope of this research.

With both placement strategies NORDUnet benefits more from optimal reordering than theother networks. This can likely be attributed to the larger (for its size) relative performanceimpact of using segment routing. The apparent small difference between using topology-awareand random VNF placement in NORDUnet’s network is likely similar to the comparatively poorperformance increase from using topology-aware VNF placement found in chapter 5.

The other real networks show comparable performance improvement. This experiment how-ever can still have VNFs at opposite sides of the network. If the source and destination are closetogether and both VNFs are at opposite sides of the network the path traversing all of them willstill be long. This could be mitigated further by clustering the VNFs.

The abstract topologies show more discrepancy in their behaviour depending on their style.Most apparent the star graph shows no benefit whatsoever. This makes sense since all paths inthe network are of identical length since all nodes are connected to the centre node with one hoponly. Reordering them makes no difference – one hop remains one hop.

There is also a striking difference between the ladder graph and both the simple and treegraph. The ladder graph shows a decreased benefit when using topology-aware placement. Thisis likely due to the clustering of VNFs. Since they are all clustered their distance from eachother is relatively small. The benefit is thus not very large. As the size of the segment listgrows the benefit does appear to grow relatively sharply. This is likely because the VNFs canbe ordered such that they form a line on the shortest path through the centre. Using randomVNF placement however the ladder graph shows the greatest benefit, likely due to the reasonsdescribed in the experiment description. The ladder would have to be traversed fewer times ifthe order is better, and this is confirmed by the experiments.

The tree and simple graphs exhibit behaviour more in line with the real networks: an increasedbenefit from using topology-aware placement. This suggests that especially this performancemetric is indicative and characteristics of the underlying network topology. Interestingly enoughthe spread also appears to behave specific to the topology.

The experiments indicate a possibility for load-based reordering at the ingress node. Thoughshuffling the segment list to unload a certain VNF yields zero performance improvements it alsodoes not introduce any additional performance penalties. Partially reordering the list wouldlikely yield intermediate results. If the optimal order was taken but two VNFs were swapped tounload a certain VNF the new path would likely lie somewhere between the immutable case andthe optimal path. This looked at random shuffling of the segment list. Perchance there existsan ordering that does perform significantly worse in the same order of magnitude as the optimalorder performs better. This could be investigated by repeating the experiment for the longestVNF ordering.

6.4.1 Caveat

As mentioned the experiment assumes full knowledge of the network to analyse potential optimalperformance gains. This requires the ingress node to be aware of all distances in the networkhowever – not just the distance from itself to all other nodes in the network. In the latter casethe segment list could be reordered based on which nodes are closest to the ingress node.

This can introduce conflicting paths again however, as nodes can be at a certain distance fromthe ingress node at opposing sides. If one VNF is at the left of the ingress node and the otherat the right they could be ordered in a sub-optimal manner for the final path. Say in the laddergraph again for example the source node is said to be in the dead-centre between VNF clusters

50

placed at the ends of the ladder. The segment list could contain nodes that are negligibly smalldistances apart. The segment list could thus still include paths traversing the network multipletimes when only the distance is considered.

Calculating the shortest path is quite computationally intensive, especially in the way it isdone in this experiment. Even if a lookup table is used the complexity still falls in the order ofO(n!). The individual steps would be shorter with a lookup table however. Perhaps a simpler tocalculate but sub-optimal path based on the immediately closest node would be better for even-tual performance. Another alternative is the aforementioned off-line path calculation networkcards like the aforementioned NorthStar [26]. This is outside of the scope of this experiment.

6.4.2 Benefits

The experiments have shown that the large path length increase investigated in chapter 5 canbe somewhat mitigated by reordering the segment list optimally. At the ingress node it is thusimportant the network’s structure is known and the segment list constructed accordingly.

The experiments indicate that shuffling the segment list introduces no additional performanceimpact. The unaltered case performs similar to the shuffled segment list. This implies reorderingthe segment list based on congestion of VNFs is a feasible option to shift the load off of congestedVNFs. To use this the used functions have to be commutable. The experiment has shown thatthe order of the segments is significantly influential on the performance of a given service chainin segment routing and that using commutable functions is desirable for possible load balancingapplications.

51

CHAPTER 7

Anycast-Prefix Segments

This chapter presents an experiment and its results corresponding to the fourth research question:

• What is the effect of using anycast-prefix segments in segment routing?

7.1 Description

Segment routing allows multiple types of segments to be used in the segment list. One of theseis the anycast-prefix segment. In this case multiple VNFs respond to the same IPv6 address.If a segment list contains an anycast-prefix segments the closest VNF will be traversed. If thenetwork is particularly large or has multiple exceptionally busy nodes these could be used toavoid unnecessary long-distance traffic across the network.

7.1.1 Anycast-Prefix Segment

An anycast-segment group is a group of segments that all respond to the same IPv6 addressprefix which can be addressed at once [34] [11]. Any of the members of the group can performthe desired action on the segment routing packet.

Since the address is just a plain IPv6 address segment routing is unable to tell whether ananycast is used or not. Which node responds to the anycast group is determined by the underlyingrouting protocols such as Equal Cost Multi Path routing. From the perspective of the segmentshowever using anycasts is the same as any other address. Different nodes can respond to thesame address, but segment routing has no influence over which node is actually reached from theanycast-group.

7.1.2 Performance Improvement

As chapters 4, 5, and 6 confirmed segment routing can incur a significant performance penaltywhen implemented carelessly. Chapters 5 and 6 also confirmed placing VNFs in a topology-awaremanner reduces the path length increase when using segment routing. It seems likely that if theanycast segments would be placed on these locations they would have a bigger effect than if theywere randomly dispersed throughout the network.

Theoretical Improvement

As the number of VNFs belonging to the same anycast-group increases in a given network thepath from any given node to the closest VNF from the anycast-group will either shorten orremain similar. If a new VNF is added to the group after all it is either closer to a given source– in which case the distance is shorter – or farther is away – in which case the previous VNFsare at the same distance away.

53

Take for example the ladder graph. If the clusters of VNFs discussed before are placed atthe ends of the ladder again the distance to the VNF cluster from any given source will lie inbetween the maximum distance and one hop. The total distance is thus derived as follows whered is the distance from a node to the VNF cluster and l the length of the ladder:

1 ≤ d ≤ l

If there are two VNF clusters placed at opposite ends one half of the ladder will now have ashorter distance to this new VNF cluster. This implies the following:

1 ≤ d ≤ l

2

If a third VNF cluster is placed at the centre this is reduced even further to:

1 ≤ d ≤ l

4

This case shows that there is a potential for significant performance increase up to theoret-ically exponential improvement. In real networks this improvement is likely considerably lowerthan this theoretical maximum improvement. Of course this distance does not include distancefrom source to target nor if a VNF cluster is traversed that is in the opposite direction of thetarget from the source.

Saturation

At some point all nodes but the source and destination node will house a VNF. At that pointthe shortest path from source to destination will certainly contain one of the VNFs unless thesource and destination are neighbours. Though performance would be nearly identical – exceptfor the neighbour case – to destination-based routing paradigms it is hardly reasonable to placeVNFs at every node of the network.

The cost of spawning a new VNF might not be particularly high but it could be undesirableto increase complexity of certain nodes by making them house VNFs. As chapter 5 discussedcentral nodes deal with more data so burdening them with VNFs could have an averse effect onoverall throughput. Even making all non-central nodes house VNFs might not be reasonable asnot all nodes in the network necessarily belong to the operator wanting to implement a VNF.The exact cost of spawning more VNFs is difficult to quantify and depends heavily on the typeof function. In general however fewer VNFs can be seen as desirable over more VNFs whenadditional VNFs provide little additional performance benefit.

Tapering Gains

As the number of VNFs in the network increases the performance increase per additional VNFprobably decreases. If a network is highly connected not many nodes are needed to have allnodes a direct neighbour to one of these VNFs. Adding additional VNFs only shortens thepath if the chosen VNF happens to be in the direction of the destination. As this experimentassumes this information is not known at the source node one of the equally close VNFs is pickedarbitrarily. This is unlike the assumption made in chapter 6 where the absolute optimal pathwas investigated.

Networks with highly centralised nodes are also likely to benefit decreasingly little fromadditional VNFs. If the central nodes are covered most of the source and destination pair’spaths will run through them already. Having multiple VNFs along a path neither increases nordecreases performance as only one need be traversed.

It also seems possible additional VNFs can add little extra performance benefit. Given atopology, source, and destination combination there exist one or more shortest paths from sourceto target. If there exist a small number of VNFs at central locations in the network the path willroute to the closest central node. In chapter 4 and 5 it was shown that this is already reasonablylikely on the shortest path and has a smaller path length increase. When placing even more

54

VNFs in the network most neighbours of the source will now house a VNF, making the choicearbitrary. This could potentially even have a detrimental effect on the performance benefit.

This assumes topology-aware VNF placement however. Completely random VNF placementought to be sightly more spread out with its performance benefits, though highly connectedgraphs are still likely to quickly taper off in terms of performance gains.

7.1.3 Expectations

It seems reasonable the performance benefit will decrease as more VNFs are placed. Initiallyhowever the performance benefit is probably more apparent. After that the expected performancegains are expected to slowly approach just above the destination-based routing path length. Dueto the described arbitrary VNF selection once the network becomes saturated with VNFs therecould be severe fluctuations or even decreases in the performance increase.

The location of the VNFs is also expected to make a significant difference on this performancegains development. If the VNFs are placed in a topology-aware manner the performance increaseis expected to be much more severe initially but taper off much quicker. This is due to asignificant portion of the high-degree nodes having a high probability of lying on the shortestpath. Eventually though the network will become saturated with VNFs.

This experiment aims to investigate how many VNFs result in what performance benefit, andwhether their location makes a big difference.

Questions

From the above the following questions and sub-questions are derived:


– What is the effect of using anycast-prefix segments in real network topologies?

– What is the influence of the number of VNFs that respond to the anycast-prefixsegment?

– What is the influence of the placement strategy of the VNFs on said effect?

7.2 Specific Set-Up

In chapters 4 and 5 the abstract topologies showed little to no significant difference to theirbehaviour resulting from the network size. For computational simplicity this experiment is thusonly performed on the medium sized (30 nodes) abstract topologies. For both this abstract andthe real network topologies the experiment is performed twice. Firstly for randomly placed VNFsand secondly for the topology-aware placed VNFs.

In real segment routing the information used would be in lookup tables instead of havingto be calculated for every source and destination pair that is tested. Due to the nature of theexperimentation this is calculated on the fly instead. This significantly increases computationalcomplexity as the number of VNFs increases.

The network and VNFs therein are regenerated 100 times. Each of these generations is thencycled 50 times. This means that there must be 50 unique source and destination pairs. Like inchapter 6 this implies there must be at least 8 free nodes, since that allows for 56 unique sourceand destination pairs to be formed. The maximum amount of VNFs is thus equal to the numberof nodes in the network minus 8, or:

max #V NFs = num nodes− 8

In NORDUnet’s case this only allows for 24 − 8 = 16 VNFs at most.Each of these cycles then looks at the source node. From there the closest VNF is located. If

multiple VNFs are equally far apart the first one that Networkx returns is picked. The shortestpath from source to destination is then calculated over this closest VNF. This path length isaveraged over the cycles and the average standard deviation is taken. This is presented in a plotwhere the path length is a function of the anycast-group size.

55

7.3 Results

The results are presented for the abstract topologies first and then for the real topologies. Firstlythe results of the random VNF placement are presented. Secondly the same experiment ispresented for the topology-aware placed version.


The abstract topologies are presented first using random VNF placement and then using topology-aware VNF placement.


Figure 7.1: The performance in terms of average path length when traversing one singular VNFfrom a list of possible VNFs. The closest (in terms of hop-count) from the source is chosen as theoptimal path. From the VNF the final hop to the destination is made along the shortest path.The average path length is shown as a function of the number of randomly placed VNFs in thelist of possible VNFs. The list of VNFs is built 100 times, and each time is run with 50 uniquesource and destination pairs. The error bars are the average standard deviation per VNF list.

56

Figure 7.1 shows the random VNF placement strategy in the abstract network topologies. Thisclearly shows some topologies benefit significantly more strongly from a larger anycast-group.The networks exhibit substantial deviation. Networks like the star graph show negligible to noimprovement.


Figure 7.2: The performance in terms of average path length when traversing one singular VNFfrom a list of possible VNFs. The closest (in terms of hop-count) from the source is chosen as theoptimal path. From the VNF the final hop to the destination is made along the shortest path.The average path length is shown as a function of the number of topology-aware placed VNFsin the list of possible VNFs. The list of VNFs is built 100 times (though the list remains thesame this is done for consistency of the error bars), and each time is run with 50 unique sourceand destination pairs. The error bars are the average standard deviation per VNF list.

Abstract networks benefit less when the VNFs are placed in a topology-aware manner, as shownin figure 7.2. Though the overall path length is lower the benefit from a larger anycast-group issmaller. The standard deviations in the tree and ladder graph remain equally large.

57



Figure 7.3: The performance in terms of average path length when traversing one singular VNFfrom a list of possible VNFs. The closest (in terms of hop-count) from the source is chosen as theoptimal path. From the VNF the final hop to the destination is made along the shortest path.The average path length is shown as a function of the number of randomly placed VNFs in thelist of possible VNFs. The list of VNFs is built 100 times, and each time is run with 50 uniquesource and destination pairs. The error bars are the average standard deviation per VNF list.

The results with random VNF placement are presented in figure 7.3. Indeed a taper is visible.Initially going from one to a handful of VNFs has a reasonably significant performance improve-ment. As the number of VNFs passes a handful the performance keeps increasing though lessrapidly. From that point the performance increase appears almost linear or asymptotic.

58


Figure 7.4: The performance in terms of average path length when traversing one singular VNFfrom a list of possible VNFs. The closest (in terms of hop-count) from the source is chosen as theoptimal path. From the VNF the final hop to the destination is made along the shortest path.The average path length is shown as a function of the number of topology-aware placed VNFsin the list of possible VNFs. The list of VNFs is built 100 times (though the list remains thesame this is done for consistency of the error bars), and each time is run with 50 unique sourceand destination pairs. The error bars are the average standard deviation per VNF list.

The results when using topology-aware VNF placement are presented in figure 7.4. Again thereappears to be a somewhat large performance benefit when increasing from one to a handful ofVNFs. Above five however this performance benefit again seems to taper off significantly. Herehowever the performance benefit appears to level out almost completely relatively quickly.

59

7.4 Discussion

Using random VNF placement the curve is relatively smooth when increasing the size of theanycast-group. Initially the performance increase is more significant and tapers off as the numberof VNFs increases. This suggests that using a few VNFs is indeed a useful way to increase theperformance further. How large the anycast-group size should be depends on the topology. Inthe simulated topologies roughly five VNFs in the anycast-group are sufficient for a considerableperformance increase. Above this the benefit of adding more VNFs to the anycast-group seemto taper off enough to not warrant additional VNFs in the group.

The abstract topologies using random VNF placement clearly show some topologies lendthemselves very well to the use of anycast-prefixes. As theorised before especially ladder graphsbenefit from anycast-prefixes. Conversely when using topology-aware VNF placement this effectis significantly less pronounced. This is likely due to the low distribution of VNFs in the laddergraph as they are placed in a cluster.

Star graphs evidently show no improvement. Since the longest shortest path in the network isonly two hops there can be little improvement when placing more VNFs. The large and randominter-connectedness of the simple graph exhibits some improvement though not very significanton the overall path length. Tree graphs show potential similar to the ladder graph, likely due tothe same reasoning. When using topology-aware placement this tree graph holds a similar thoughless pronounced shape. The tree graph still benefits significantly from a handful of anycast-prefixsegments.

Apart from the simple and star topologies most graphs show a rather large spread. Thismargin does correspond with deviations seen in previous experiments. Interesting is that thespread seems larger here for using topology-aware placement than for random VNF placement.This is likely due to the order in which VNFs are placed. Since the degree order is used forplacement the most connected nodes in the network are added as VNFs first. In topologies likethe simple network this likely yields a relatively uniform distribution of nodes where the spreadis mostly dependent on the remaining non-VNF nodes.

In the ladder graph the VNFs are clustered in the centre. The path from any node to thecentre of the ladder can range between one hop and half the ladder’s length in hops. It thusseems logical a uniform distribution like in the experiments would have an average hop countof roughly a quarter of the ladder’s length. Given the experiment is performed on a 30 nodenetwork the expected average is around 7.5. The range in the results appear to be a bit higherthan the estimate between 8 and 9. The seen deviation seems to be around 6 hops, again closeto the estimation but not quite on it.

It must be noted that the overall path when using topology-aware placement is shorter. Whenusing random VNF placement the same performance can be achieved however by increasingthe anycast-group size. From around 4 to 5 anycast-prefix segments the ladder graph showscomparable performance to using topology-aware VNF placement. This suggests that if thereexists no way of placing the VNFs in a certain manner in a network the sustained path lengthincrease can be somewhat mitigated by using a large enough anycast-group. The results showthe number of VNFs needed would not be excessive.

Comparing the shape of the lines between topology-aware VNF placement and random VNFplacement makes it seem that using topology-aware placement yields less predictable results.This is likely due to the already relatively small path length increase when using topology-awareVNF placement. The best result can’t be shorter than shortest path from source to VNF, andfrom VNF to destination. The jaggedness of the topology-aware placement graphs suggests thisthreshold is already closely approached and little room is left for further improvement. When aVNF happens to be placed closer to a given source but “the wrong way” from the perspective ofthe destination this could lead to increases in path length. It seems there is no significant benefitfrom using many additional VNFs when using topology-aware VNF placement. An optimal pointis not really evident either. It would be interesting to rerun the experiment and link multipleanycast-groups after one another. Given the behaviour seen in chapter 6 employing a longersegment list might yield more interesting results for the topology-aware VNF placement. Thesecould potentially look a lot steeper and closer to the shape of the current random VNF placement.

60

7.4.1 Benefits

In the previous experiments topology-aware VNF placement has significantly outperformed ran-dom VNF placement. However, in the case of anycast-prefix segments it appears there is hardlyany difference. Though topology-aware VNF placement outperforms random VNF placement itappears to benefit less from using anycast-prefix segments. When using random VNF placementit is useful to use multiple VNFs in the anycast-group. How many depends heavily on the to-pology and size of the network. For the used topologies around five VNFs in the anycast-groupis sufficient for a considerable performance increase. From the above experiment is becomes ap-parent random VNF placement can perform similarly to topology-aware VNF placement. Thisallows for multiple solutions for increasing performance based on the situation.

61

CHAPTER 8

Overall Discussion

The experiments in the previous chapters and the overall discussion have shown that in orderto achieve guaranteed traversal usable for the effective and efficient traversing and chaining ofservices in a given topology, segment routing offers an efficient and effective way to achieve this.This chapter will reflect on this statement and discuss some of the limitations and considerationswith segment routing.

8.1 Experiments

The first experiment showed the desired behaviour is not very well achievable through destination-based paradigms. To achieve this behaviour segment routing is thus an effective tool. Though asthe second experiment showed using segment routing does not come without any additional cost.Using segment routing comes with a considerable but not huge performance impact. Within thecontext of these experiments the performance is measured in terms of hop count and it is shownthis increases significantly as segment routing is used with increasingly longer segment lists ofservice nodes. The following experiments showed that this performance impact can be negatedto a significant degree by ordering the segments in the segment list in an optimal manner. Theusage of anycast segments can also yield significant performance increases in terms of hop countsas the final experiment indicated.

All of the experiments showed that the location of the network functions is highly influentialon the performance impact of using segment routing, as well as the performance improvementmethods usable with segment routing. This showed that though segment routing offers the abilityto create a vast and programmable network placing the programmable segments throughout thenetwork without care and consideration can lead to significant performance impacts.

Even when placing the VNFs in a topology-aware manner is not an option the experimentsstill showed room for considerable performance improvement. Through the usage of anycastsegments with ample service nodes belonging to said anycast-group and ordering the segmentlist based on the network topology the performance impact can be reduced significantly even whenthe VNFs are dispersed randomly throughout the network. Doing so requires more knowledgeand control at the ingress node to the SR domain, though it offers the option of arbitrary VNFplacement while still minimising the performance impact. Doing so could also potentially bequite computationally complex. Calculating the absolute shortest path for a given segment listwould be in the order of O(n!) and could thus scale poorly. There are ways to mitigate thiscost and still calculate the optimal segment order efficiently through dedicated and off-line pathcreation hardware. One such example is Juniper’s NorthStar Controller card [26].

The experiments showed there is a cap to the performance improvement. The only way thereis no performance impact relative to destination-based routing paradigms is if all the VNFsare placed on the shortest path from source to destination. If more VNFs exist than nodes inthis shortest path, or if the VNFs are not all on this shortest path the traversal path length isunavoidably longer. Both the path through and the placement of the functions is influential on

63

the impact.The experiments also indicate that the performance impact depends heavily on the network

topology. The experiments on abstract networks indicate that this performance impact behaviourcan be characteristic of the underlying network structure in the real network topologies. Throughanalysing and comparing the performance impact it appears plausible to a degree to classifytopologies as more star-like or more ladder-like.

8.2 Hop Count and other Performance Metrics

The experiments mostly use hop count as a measure of performance. Hop count is a veryrudimentary way of determining performance in a network and can be a poor representation ofreality. In real networks the number of hops is not necessarily directly related to traversal time.Certain paths can have a lower latency than others. These paths can have a low enough latencyto counter the lower hop count of another path. Say two nodes are connected via two pathswhere the first consists of hops that take roughly 100ms per hop and the second path 200ms perhop. If the first path is twice as long the traversal time is still the same.

The same applies to connection throughput. Certain links can have a larger throughputcapacity than other links. When routing a significant amount of traffic through these connectionsit may be desirable to route via the longer path because there could be less congestion.

Since hop count still incurs latency in terms of store and forward penalties and other inherentslowdowns hop count is not necessarily a useless measure of performance either however. Thoughtime based performance would have yielded more realistic and possibly useful results hop countcan symbolise performance well enough for the purposes of this research.

Computational Cost

Using only hop count as a metric of performance also omits the computational cost of performingthe actual service functions. Since the experiments focus on the usage of segment routing for usingand chaining services this can be especially influential on the actual perceived performance. Anoperation like encryption or compression costs time. This cost is not included in the experimentshowever. The cost of computing and attaching the segment routing path is also not included inthe performance metrics.

The experiment analysing the performance impact of using segment routing only looks athop counts and assumes no additional cost of executing the network function nor path creation.Functions like a firewall could either let a packet through or not regardless of the data it carries.These functions are then likely to be a set performance penalty. When encrypting data howeverthe performance impact can be quite dependent on the amount of data to be encrypted. Thisperformance impact could greatly alter the results seen in the experiments. Since they are verydependent on the service however this is considered outside of the scope of this research.

8.3 Simulations

The experiments performed in the previous chapters are all performed using simulations. Thesesimulations used both abstract and real network topologies. Since the networks were simulatedas a simple NetworkX [16] graph some details have been omitted. Multiple connections betweenthe same nodes to compensate for congestion for example could make certain paths significantlymore attractive than the simple shortest path. Under link failure these multi-connected graphscould again behave differently. It would have thus been interesting to perform the experimentson physical hardware with realistic connections, throughputs, latencies, link failures, and linkspeeds and simulate light, moderate, and heavy traffic through them and perform the experimentsthereon. This was again outside of the scope of this research however.

64

Network Traffic

As mentioned the simulations do not include the simulation of traffic through the network.Instead the experiments perform measurements on a per-packets basis. Whenever a packet wassaid to be sent from any node the path was calculated to its destination and measurements weretaken. Then and only then did the simulation proceed to the next packet.

This form of experimentation is adequate for making observations regarding the paths takenthrough the network but traffic, congestion, and rerouting as a result of link failures are not takeninto account. Real networks can be subject to heavy congestion, link failures, or even DistributedDenial of Service (DDoS) attacks. Occurrences like these can alter the path packets take throughthe network as well as the latency. The real network topologies used in the experiments alsoincluded links of different throughput capabilities in real life but these capabilities are ignoredfor the purposes of the experiments. All links are assumed identical in the experiments. Theexperiments could potentially yield different results when rerun with heavy traffic flow andrerouting as a result of link failures. This was outside of the scope of this research.

Combined Simulations

All of the simulations are performed separately. The experiment with service order presentedin chapter 6 and the experiment with anycast segments presented in chapter 7 suggest that theusage of these techniques can compensate for the lack of the other or the lack of topology-awareVNF placement. Especially because the experiment on anycast segments from chapter 7 suggeststhere is a limit to the performance benefit it would be interesting to see whether this is true bycombining all of these optimisation techniques in one experiment. As they are all separatedcurrently the techniques also are unable to hinder one another. This, again, is outside of thescope of this research though.

Directly Attached Service Functions

As mentioned during some of the experiments the found optimal solutions might not be optimal inreal life applications. Centralised VNF placement turned out to be beneficial for performance butmight not be desirable due to the increased complexity of the central hub nodes – as mentionedin chapters 4 and 5. There the suggestion was also made to place the desired service functions asdirectly attached network functions to these central nodes. In this manner the optimal location– apart from two hops to and from the directly attached network – would be combined with thelack of complexity. It might however be even more beneficial to place VNFs on already existingnetwork paths. As the experiment is currently set up the effect of using directly attached networksis not investigated.

65

CHAPTER 9

Towards a Prediction Tool

This sections presents the outlines of a tool based on the observations and conclusions drawnfrom the previous chapters. The locations of network functions is important for the performanceof segment routing. Some constraints to the location of network functions were also presented.Ordering a segment list based on the optimal path has also been shown to offer significant per-formance increase. Anycast segments are also a feasible tool for gaining additional performance.All of these combined allow for a significant amount of performance to be gained depending onthe exact network topology. In the following section this conceptual tool is referred to as thetool.

9.1 IEEE Software Specification

Figure 9.1: A prototype Software Requirement Specification (SRS) as per the IEEE standard[24] [22].

The IEEE defines a standard for outlining the software requirements specification [24] [22]. Thisstandard is meant to give a structured way of defining the requirements and specifications of a

67

given software before it is built. It is thus used as a basis for the outline of the described tool inthis chapter.

A prototype of the IEEE standard for software requirements specifications is given in figure9.1. This figure shows a number of sections, not all of which are relevant to the tool theorisedin this chapter. The three main sections are maintained but only certain subsections from themare relevant to the theorised tool. The sections that are relevant are as follows:

• 1.1 Purpose: The purpose describes what and who the software is created for.

• 1.2 Scope: The scope defines what the software should and should not do.

• 2.1 Product Perspective: The product perspective puts the product into perspectivewith related products. In this case the relevant sub-sections are:

– User Interface: The logical characteristics and optimisations of the user interfacefor the end-user are described here.

– Software Interface: The interactions between the created software and requiredadditional software is described in this section.

• 2.5 Assumptions and Dependencies: This describes what the software is dependenton and what assumptions are made that affect the requirements posed in the requirementsspecification.

• 3 Specific Requirements (Functions): This section described the functions the soft-ware should perform. Functional requirements should define the fundamental actions thesoftware must take.

The following sections will describe the theoretical tool in detail through this standard.

9.2 Introduction

Purpose

The purpose of the tool is to offer a comprehensive and easy way to optimise a desired servicechain through segment routing in a given network topology. The tool would make suggestionsas to the optimal locations of services, the optimal order of the services, and the size of theanycast-groups. The user would be able to define parameters to alter the behaviour of the tool.These parameters would be included in the suggestion the tool makes.

As more research is done into segment routing this tool should be able to be extended fur-ther. If data is gathered about potential node failure resistance in a network the tool should beexpandable enough to allow for the inclusion of such parameters.

Alongside the solid suggestion the tool should visualise a range of values around the suggestedvalue. If the tool suggests a certain anycast group size it should show the predicted size as wellas a few sizes close to it to give the user a clearer idea how great the benefit is. These shouldbe shown through a GUI. A single conclusion and recommendation should be displayed and thevisualisations should support this conclusion.

The intended audience of the tool would be network programmers and engineers or otherinterested individuals. The tool would make suggestions on a hypothetical implementation beforephysical implementation to get an idea of the performance and optimal possible implementation.Hence the tool is aimed at people looking to implement a service chain with segment routing butwanting to get an idea first how segment routing would work in their particular situation.

Scope

The tool would consist of three main components: data input, data analysis, and data visualisa-tion. The scope section describes what these components will and will not do.

The input of data has the user supplying their network topology. In the context of thistool this could be as a NetworkX [16] specification or otherwise. It should include all relevant

68

parameters like nodes and links. Additionally parameters like link speeds, link costs, preferredlinks, double links, directional links, and more should be provided, though these details areoutside of the scope of the previously performed experiments.

The input component should also input the parameters such as function commutability andconstraints to anycast-group sizes. Other constraints could include nodes where service functionscan not be hosted. Any parameter used in the simulations for the suggestions should be adjustableby these parameters. The input component should not perform any interpretation of the inputdata other than transforming the data into internal representation.

The processing phase would take the above data and analyse it to create visualisations andpredictions. This should be done in a modular and extendable fashion so that this can beextended and controlled through the user-defined parameters. The processing phase should notinclude any hard-coded parameters. The processing phase should also not make decisions. Itshould only perform calculations, run simulations, and summarise results into suggestions. Theonly output of this phase should be logging output.

The data visualisation phase should be where the data is displayed back to the user. Prefer-ably an adjustable GUI should be used that adjusts itself to the user-defined parameters. Thevisualisation phase should also allow for adjustments to the parameters ideally and re-executionof the program while skipping the input step. The visualisation phase itself should not performany calculations.

Limitations

This tool would only make suggestions. It is limited in the ways it can predict traffic flow andactual use cases. The tool would suggest a good service function chain in the given topologybased on the supplied information. It would not simulate real traffic necessarily although thatcould be an extension. Still real-world use-cases are likely not identical to the simulations sothere exist some limitations there. The expected execution time of the services is trusted to besupplied by the user.

9.3 Overall Description

Product Perspective

The tool would be a completely standalone tool. It is not part of a larger system and is self-contained.

User Interfaces

The user interface would need to display multiple plots and suggestions. A very rough andrudimentary example is drafted in figure 9.2. This example shows a possible output for thetool when a user wants to create a service chain with two segments. The top shows an overallsuggestion. Beneath that are suggestions for the locations of the services. Beneath that arethe suggestions and effects for the order of the segments. Beneath that the performance andsuggestion of the size of the anycast-group is shown. Showing more than just the suggestionwould allow a user to find their personal “sweet spot”.

69

Suggestion for: Network service function locations, order of services (if commutable),

size of anycast-group size, and more if applicable

Suggested locations service 1Node 1: p% performance increase

Node y: q% performance increase

Node z: s% performance increase

Suggested locations service 2Node 1: p% performance increase

Node y: q% performance increase

Node z: s% performance increase

Suggested service order 1Order x: p% performance increase

Order y: q% performance increase

Suggested service order 2Order x: p% performance increase

Order y: q% performance increase

Effect of anycast-group 1 size Effect of anycast-group 2 size

Group size

Perfo

rman

ce

Perfo

rman

ce

Group size

Figure 9.2: A very rudimentary example of a simple user interface displaying different kinds ofdata to the end-user making suggestions to their specific requirements.

Software Interfaces

The software used to run the simulations could still be Python’s NetworkX [16] library. Poten-tially this could be extended with Numpy [30] and Scipy [25] as regular Python is not particularlyefficient. Since the tool is only a suggestive tool it would need to execute relatively quickly. Oth-erwise performing the simulations in the C or C++ programming language could be betterfor efficiency. A web-based implementation could also be possible using a simpler “drag-and-drop” style network creator where users could drag their network together like a typical drawingapplication.

Assumptions and Dependencies

The tool runs under the assumption real-life implementations behave similarly enough to thesimulations that reasonable suggestions can be made from the simulations. The experimentsperformed suggest this is plausible by experimenting on real topologies, though the experimentsperformed on those topologies were also simulations.

9.4 Specific Requirements

The user should be able to input a network topology as an abstract representation. It should bekept abstract to allow for things like multiple links and directed connections in future additions.Weights, latencies, and constraints should also be able to be put in arbitrarily. The executiontime of the services should also be supplied alongside how many unique services are desired,which locations are allowed and not allowed, how many anycast segments can be placed at most,and any further limitations.

70

Based on these the output should include more or less information. If information like weightswas included in the input they should be properly incorporated in the output and possibly displayadditional plots.

Functions

The main functions of the tool correspond to the earlier described three phases: data input, dataanalysis, and data visualisation.

Data Input

The main functions related to input should be roughly as shown in listing 9.1.

1 r e c e i v e i n pu t ( ) :2 get network ( )3 g e t s e r v i c e f u n c t i o n s ( )4 ge t cha in ( )5 g e t l im i t a t i o n s ( )6

7 f o r each func t i on :8 ge t max s e rv i c e s ( )9 f o r each s e r v i c e :

10 g e t r e s t r i c t e d l o c a t i o n s ( )11

12 f o r each parameter in s imu la t i on s :13 g e t u s e r i n p u t o r d e f a u l t ( )14 f o r each exper iment type :15 g e t u s e r i npu t ( )16 r e turn re l evant exper iment s , parameters

Listing 9.1: Example pseudocode for the data-input phase of the tool.

Data Analysis

Data analysis is based on the experiments performed earlier. The optimal locations would becalculated by looking at the traversal probability of every node in the network using destination-based routing paradigms. As was visible in the experiments from chapters 4 and 5 this probabilitywas directly correlated with the performance impact. The first experiment confirmed that higherdegree nodes had a higher traversal probability and yielded a lower performance impact. Rankingall nodes in the network based on their traversal probability or average performance impact whensimulating some traffic would return the best nodes to place functions on with the lowest impact.This should return simply the list of ranked nodes as the number of desired nodes is unknownat present since multiple anycast segments could be suggested. Of course this should take intoaccount off-limit nodes and limits as provided by the user.

The number of service nodes thus needs to be identified next. Each service could be takenseparately for this consideration initially. By simulating one to n services on the ordered andranked list of nodes and averaging some source and destination pair distances over them theperformance distribution similar to the experiment could be returned. Based on this graph– which could also be displayed – some criteria should be used to determine when increasingthe size of the anycast-group is no longer significantly beneficial. Since a clear flattening of thebenefit was visible in the performance a simple relative consideration could be made. For examplewhen the average path length doesn’t reduce by more than 10% relative to the previous numberof anycast-segments the additional anycast segment is unnecessary. This could be consideredfor all services in the desired service chain. Combining multiple services in this considerationwould imply running these simulations for all combinations of the services. For example, addingone extra segment to one node should be compared against adding the same node location toa different node to determine which has the highest benefit from it. The user should specifywhether these nodes can overlap and what the average expected execution time of the servicesare. Again this should observe limitations and execution times supplied by the end-user.

Lastly the order can be determined. Since the number of network functions is known as wellas their locations the tool could calculate all possible permutations of the service chain. Since

71

the anycast segments count as one service this should not be overly complex. Then a numberof unique and random source and destination pairs should be drawn. Each pair should calculatethe shortest possible path given the choice in anycast segments and their permutation. Theseshould be averaged and the best permutation would be suggested as the optimal order. If theuser noted the services as immutable this whole step can of course be omitted. If not the resultsfor the best performing orders can also be shown to show whether there is a large differencebetween the given orders or whether they’re relatively similar.

It should also be possible to flip these steps or omit steps based on the user’s preferences.If the end-user has no control over network function placement for example this step should beskippable and random or dedicated network function placement should be an option.

The main functions related to data analysis should be roughly as shown in listing 9.2.

1 c a l c u l a t e o p t ima l l o c a t i o n s ( ) :2 f o r each node in network :3 c a l c u l a t e t r a v e r s a l p r o b a b i l i t y ( )4 r a n k p r o b a b i l i t i e s ( )5 c a l c u l a t e p e n a l t i e s ( )6 r ank p ena l t i e s ( )7 c h e c k o f f l i m i t s ( )8 r e turn bes t nodes9

10 c a l c u l a t e op t ima l o r d e r ( ) :11 f o r each permutation o f s e r v i c e c h a i n :12 f o r n r andom sou r c e de s t i na t i on pa i r s :13 g e t a v e r a g e d i s t an c e s (n , s e r v i c e c h a i n )14 r a nk s e r v i c e c h a i n ( )15 r e turn be s t cha in16

17 c a l c u l a t e op t ima l any c a s t s ( ) :18 f o r each s e r v i c e :19 f o r 0 to max segments :20 c a l c u l a t e a v e r a g e d i s t a n c e s ( )21 r ank s e r v i c e ( )22 r e turn ranks

Listing 9.2: Example pseudocode for the data-analysis phase of the tool.

Data Visualisation

A rough description of how the data could be visualised is roughly as shown in listing 9.3.

1 d i s p l a y r e s u l t s ( ) :2 p r i n t g e n e r a l s u g g e s t i o n ( )3

4 f o r each input type :5 i f c a n v i s u a l i s e :6 v i s u a l i s e s u g g e s t i o n r a n g e ( )7 e l s e :8 p r i n t s u gg e s t i o n r ang e ( )

Listing 9.3: Example pseudocode for the data-visualisation phase of the tool.

9.5 Summary

Implementing the tool roughly as described above would yield an effective way to predict howwell a certain service chain would perform if implemented with segment routing, as well as yieldsuggestion on how to optimise its performance. The structure of the application is based on theexperiments performed in the previous experiments. The results there showed the importanceof certain aspects and these were thus included in the tool’s design. Such a tool would be usefulas a first investigation before actually implementing segment routing and could provide usefulinsight into how useful segment routing could be for a given situation.

72

CHAPTER 10

Conclusion

Segment routing is a way to guarantee a particular type of routing behaviour which guaranteesthe traversal of the specified segments. This can be used for – amongst others – a wide range oftraffic engineering applications and the usage and chaining of network services. By defining thesegments in the segment list in a specific manner a certain type of behaviour can be guaranteed.

Segment routing is a very new implementation still actively in development. This researchfocuses on analysing the characteristics and limitations of segment routing. This is done throughthe following research questions:


• What is the performance impact, if any, of segment routing?

• What is the effect of the order of segments in a segment list?


Each research question was investigated through an analytic experiment. The first experi-ments observed how regularly segment routing like behaviour occurs in destination-based routingparadigms by looking at the probabilities of traversing certain nodes in a given network. Theexperiment indicated this occurs around 40% of the time indicating segment routing offers beha-viour difficult to achieve through destination-based paradigms. The second experiment analysedthe cost of implementing service chains using segment routing by means of a rudimentary hopcount performance analysis and found a path length increase around 40% for just one segment.This increased proportional to the segment list. In both of these experiments these results wereonly obtained using optimal topology-based placement of the defined segments. Not doing soyielded significantly worse results.

The third and fourth experiments analysed whether this performance impact could be mit-igated. The third experiment specifically looked at the influence of the order of the segment listand noted a significant increase in performance when rearranging the segment list optimally forthe given topology, ingress, and egress combination. The performance could be improved up toaround 20% with a segment list containing five segments in most topologies. The fourth exper-iment analysed the usage of anycast segment where a number of services responds to the sameaddress. The optimal number for performance depended on the topology, though around fivewas sufficient for the topologies used in this research. This fourth experiment also showed thatcombining performance impact mitigation methods lead to a ceiling in potential performancebenefits. Once the optimal path has been reached there are no further improvements to make.The experiments have all shown that to achieve guaranteed traversal usable for the effective andefficient traversing and chaining of services in a given topology a good solution is indeed segmentrouting.

The experiments also showed segment routing comes with a performance impact that canbe significantly mitigated with some work. A tool was thus theorised for the optimisation ofimplementing a service chain in a theoretical segment routed network. This tool is meant to give

73

a network operator an idea of how well segment routing would work to implement a hypotheticalservice chain in their network and how to optimise said implementation. Based on the resultsand behaviours observed during the experiments this tool was theorised and outlined.

Future research could look at actually implementing this tool as it was specified and ana-lyse how well it behaves. Performing the experiments currently performed as simulations onactual segment routing hardware would also be an interesting continuation of this research. Asit currently stands however segment routing hardware is mostly experimental and the exact spe-cifications of segment routing are not yet finalised. Performing such experiments in hardware isthus currently out of the scope of this research. The considerations presented in the overall dis-cussion would also be interesting to consider but were also outside of the scope of this document.From the observations made in this research however segment routing appears to be a promisingtechnology with many potential use-cases.

74

Bibliography

[1] Ahmed Bashandy et al. Segment Routing with MPLS data plane. Internet-Draft draft-ietf-spring-segment-routing-mpls-13. Work in Progress. Internet Engineering Task Force, Apr. 2018. 24 pp.url: https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-mpls-13.

[2] Carlos Jsus Bernardos et al. Network Virtualization Research Challenges. Internet-Draft draft-irtf-nfvrg-gaps-network-virtualization-09. Work in Progress. Internet Engineering Task Force, Feb.2018. 40 pp. url: https://datatracker.ietf.org/doc/html/draft-irtf-nfvrg-gaps-network-virtualization-09.

[3] Robert T. Braden. Requirements for Internet Hosts - Communication Layers. RFC 1122. Oct.1989. doi: 10.17487/RFC1122. url: https://rfc-editor.org/rfc/rfc1122.txt.

[4] Cisco. 2018. url: http://www.segment-routing.net/.

[5] Francois Clad et al. Segment Routing for Service Chaining. Internet-Draft draft-xuclad-spring-sr-service-chaining-01. Work in Progress. Internet Engineering Task Force, Mar. 2018. 36 pp. url:https://datatracker.ietf.org/doc/html/draft-xuclad-spring-sr-service-chaining-01.

[6] Dr. Steve E. Deering and Robert M. Hinden. Internet Protocol, Version 6 (IPv6) Specification.RFC 1883. Dec. 1995. doi: 10.17487/RFC1883. url: https://rfc-editor.org/rfc/rfc1883.txt.

[7] Daniel Dib. 2015. url: https://www.networkcomputing.com/networking/segment-routing-potential-far-reaching-network-effects/516090694.

[8] FD.io. 2018. url: https://wiki.fd.io/view/VPP/Segment_Routing_for_IPv6.

[9] Dennis Ferguson, Acee Lindem and John Moy. OSPF for IPv6. RFC 5340. July 2008. doi: 10.17487/RFC5340. url: https://rfc-editor.org/rfc/rfc5340.txt.

[10] C. Filsfils, K. Michielsen and K. Talaulikar. Segment Routing. pt. 1. CreateSpace IndependentPublishing Platform, 2017. isbn: 9781542369121. url: https://books.google.nl/books?id=1zMyMQAACAAJ.

[11] Clarence Filsfils et al. Segment Routing Architecture. Internet-Draft draft-ietf-spring-segment-routing-15. Work in Progress. Internet Engineering Task Force, Jan. 2018. 31 pp. url: https:

//datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-15.

[12] Clarence Filsfils et al. SRv6 Network Programming. Internet-Draft draft-filsfils-spring-srv6-network-programming-04. Work in Progress. Internet Engineering Task Force, Mar. 2018. 57 pp. url:https://datatracker.ietf.org/doc/html/draft-filsfils-spring-srv6-network-programming-

04.

[13] Behrouz A Forouzan and Sophia Chung Fegan. TCP/IP protocol suite. McGraw-Hill Higher Edu-cation, 2002.

[14] GEANT. GEANT Research and Educational Network. url: https://www.geant.org/.

[15] William R George. High performance switch fabric element and switch systems. US Patent 7,408,927.Aug. 2008.

[16] Aric Hagberg, Pieter Swart and Daniel S Chult. Exploring network structure, dynamics, and func-tion using NetworkX. Tech. rep. Los Alamos National Lab.(LANL), Los Alamos, NM (UnitedStates), 2008.

[17] Joel M. Halpern and Carlos Pignataro. Service Function Chaining (SFC) Architecture. RFC 7665.Oct. 2015. doi: 10.17487/RFC7665. url: https://rfc-editor.org/rfc/rfc7665.txt.

75

https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-mpls-13

https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-mpls-13

https://datatracker.ietf.org/doc/html/draft-irtf-nfvrg-gaps-network-virtualization-09

https://datatracker.ietf.org/doc/html/draft-irtf-nfvrg-gaps-network-virtualization-09

https://doi.org/10.17487/RFC1122

https://rfc-editor.org/rfc/rfc1122.txt

http://www.segment-routing.net/

https://datatracker.ietf.org/doc/html/draft-xuclad-spring-sr-service-chaining-01



https://www.networkcomputing.com/networking/segment-routing-potential-far-reaching-network-effects/516090694

https://www.networkcomputing.com/networking/segment-routing-potential-far-reaching-network-effects/516090694

https://wiki.fd.io/view/VPP/Segment_Routing_for_IPv6




https://books.google.nl/books?id=1zMyMQAACAAJ

https://books.google.nl/books?id=1zMyMQAACAAJ

https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-15

https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-15

https://datatracker.ietf.org/doc/html/draft-filsfils-spring-srv6-network-programming-04

https://datatracker.ietf.org/doc/html/draft-filsfils-spring-srv6-network-programming-04

https://www.geant.org/



[18] Bo Han et al. ‘Network function virtualization: Challenges and opportunities for innovations’. In:IEEE Communications Magazine 53.2 (2015), pp. 90–97.

[19] Robert M. Hinden and Dr. Steve E. Deering. Internet Protocol, Version 6 (IPv6) Specification.RFC 2460. Dec. 1998. doi: 10.17487/RFC2460. url: https://rfc-editor.org/rfc/rfc2460.txt.

[20] Christian E Hopps. ‘Analysis of an equal-cost multi-path algorithm’. In: (2000).

[21] J. D. Hunter. ‘Matplotlib: A 2D graphics environment’. In: Computing In Science & Engineering9.3 (2007), pp. 90–95. doi: 10.1109/MCSE.2007.55.

[22] ‘IEEE Recommended Practice for Software Requirements Specifications’. In: IEEE Std 830-1998(Oct. 1998), pp. 1–40. doi: 10.1109/IEEESTD.1998.88286.

[23] Internet Protocol. RFC 791. Sept. 1981. doi: 10.17487/RFC0791. url: https://rfc-editor.org/rfc/rfc791.txt.

[24] ‘ISO/IEC/IEEE International Standard - Systems and software engineering – Life cycle processes–Requirements engineering’. In: ISO/IEC/IEEE 29148:2011(E) (Dec. 2011), pp. 1–94. doi: 10.1109/IEEESTD.2011.6146379.

[25] Eric Jones, Travis Oliphant, Pearu Peterson et al. SciPy: Open source scientific tools for Python.[Online; accessed ¡today¿]. 2001–. url: http://www.scipy.org/.

[26] Juniper. url: https://www.juniper.net/documentation/en_US/northstar3.1.0/information-products/pathway-pages/3.1.0/northstar-user-guide.html.

[27] Kbrose. 2008. url: https://en.wikipedia.org/wiki/File:IP_stack_connections.svg.

[28] John Moy. OSPF Version 2. RFC 2328. Apr. 1998. doi: 10.17487/RFC2328. url: https://rfc-editor.org/rfc/rfc2328.txt.

[29] NORDUnet. NORDUnet Research and Educational Network. url: https://www.NORDU.net/.

[30] Travis E Oliphant. A guide to NumPy. Vol. 1. Trelgol Publishing USA, 2006.

[31] Stefano Previdi et al. IPv6 Segment Routing Header (SRH). Internet-Draft draft-ietf-6man-segment-routing-header-12. Work in Progress. Internet Engineering Task Force, Apr. 2018. 28 pp. url:https://datatracker.ietf.org/doc/html/draft-ietf-6man-segment-routing-header-12.

[32] Stefano Previdi et al. Source Packet Routing in Networking (SPRING) Problem Statement andRequirements. RFC 7855. May 2016. doi: 10.17487/RFC7855. url: https://rfc-editor.org/rfc/rfc7855.txt.

[33] Paul Quinn, Uri Elzur and Carlos Pignataro. Network Service Header (NSH). RFC 8300. Jan.2018. doi: 10.17487/RFC8300. url: https://rfc-editor.org/rfc/rfc8300.txt.

[34] Pushpasis Sarkar et al. Anycast Segments in MPLS based Segment Routing. Internet-Draft draft-ietf-spring-mpls-anycast-segments-02. Work in Progress. Internet Engineering Task Force, Jan.2018. 19 pp. url: https://datatracker.ietf.org/doc/html/draft- ietf- spring- mpls-

anycast-segments-02.

[35] Martin L Shooman. Reliability of computer systems and networks: fault tolerance, analysis, anddesign. John Wiley & Sons, 2003.

[36] SURFnet. SURFnet National Research and Educational Network. url: https://www.SURFnet.nl/.

[37] Arun Viswanathan, Eric C. Rosen and Ross Callon. Multiprotocol Label Switching Architecture.RFC 3031. Jan. 2001. doi: 10.17487/RFC3031. url: https://rfc-editor.org/rfc/rfc3031.txt.

[38] Debbra Wetteroth. OSI reference model for telecommunications. Vol. 396. McGraw-Hill New York,2002.

76



https://doi.org/10.1109/MCSE.2007.55

https://doi.org/10.1109/IEEESTD.1998.88286






http://www.scipy.org/

https://www.juniper.net/documentation/en_US/northstar3.1.0/information-products/pathway-pages/3.1.0/northstar-user-guide.html

https://www.juniper.net/documentation/en_US/northstar3.1.0/information-products/pathway-pages/3.1.0/northstar-user-guide.html

https://en.wikipedia.org/wiki/File:IP_stack_connections.svg




https://www.NORDU.net/

https://datatracker.ietf.org/doc/html/draft-ietf-6man-segment-routing-header-12






https://datatracker.ietf.org/doc/html/draft-ietf-spring-mpls-anycast-segments-02

https://datatracker.ietf.org/doc/html/draft-ietf-spring-mpls-anycast-segments-02

https://www.SURFnet.nl/



On Service Chaining and Segment Routing · Segment routing is a very new technology and many elds...

Documents

Transcript of On Service Chaining and Segment Routing · Segment routing is a very new technology and many elds...