Cross-layer Optimization of Peer-to-Peer Video Streaming in OpenFlow-based ISP Networks

(1)

Cross-layer Optimization of

Peer-to-Peer Video Streaming in

OpenFlow-based ISP Networks

Diplomarbeit Jeremias Blendin PS-D-0003 Fachbereich Elektrotechnik und Informationstechnik Institut für Datentechnik Fachgebiet P2P Systems Engineering Prof. Dr. David Hausheer

(2)

Cross-layer Optimization of Peer-to-Peer Video Streaming in OpenFlow-based ISP Networks Diplomarbeit

PS-D-0003

Eingereicht von Jeremias Blendin Tag der Einreichung: 30. April 2013 Gutachter: Prof. Dr. David Hausheer

Zweitgutachter: Prof. Dr.-Ing. Ralf Steinmetz Betreuer: M.Sc. Julius Rückert

Technische Universität Darmstadt

Fachbereich Elektrotechnik und Informationstechnik Institut für Datentechnik

Fachgebiet P2P Systems Engineering Prof. Dr. David Hausheer

(3)

Ehrenwörtliche Erklärung

Hiermit versichere ich, die vorliegende Diplomarbeit ohne Hilfe Dritter und nur mit den angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus den Quellen entnommen wurden, sind als solche kenntlich gemacht worden. Diese Arbeit hat in dieser oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen. Die schriftliche Fassung stimmt mit der elektronischen Fassung überein.

Darmstadt, den 30. April 2013 Jeremias Blendin

(4)

(5)

List of Figures

2.1. A P2P LVS layer model (based on [67], p. 73). . . 5

2.2. Tree and mesh topologies for video stream distribution in P2P LVS. Blue boxes denote existing, white boxes missing parts of the video. . . 6

2.3. Hierarchical topology of the Internet [58, p. 78]. . . 8

2.4. ISP network topology by network types. . . 9

2.5. A traditional networking scheme and the OpenFlow networking scheme [see 72, p. 2]. . . 11

2.6. Operating schema of the OpenFlow version 1.0 flow table. . . 13

2.7. Operating schema of the OpenFlow version 1.1 packet-processing pipeline. . . 14

3.1. The forwarding scheme of REUNITE (adapted from [104, p. 1645]). . . 21

5.1. A simplified illustration of the operation of a P2P LVS system. . . 30

5.2. A simplified illustration of the operation of a P2P LVS system using the RASP service. . . . 31

5.3. OpenFlow network architecture (adapted from [82, p. 7]). . . 34

5.4. Architecture of the RASP service. . . 35

5.5. The names of entities involved with the RASP system. . . 37

5.6. OpenFlow rules for implementing a virtual peer for a connection initiated by peer P to super peer SP. . . 40

5.7. Comparison of an IP multicast and a SDM domain. . . 41

5.8. Schema of the SDM concept. . . 42

5.9. Schematic overview of an Explicit SDM domain and its subdomains. . . 46

6.1. The components of the RASP service that are part of the prototype. . . 49

6.2. Overview of the prototype implementation and the accompanying emulation system of RASP. . . 50

6.3. Throughput of the three OpenFlow software switches as measured byiperf. . . 53

6.4. The process schema of running an emulated network experiment. . . 54

6.5. An example network based on the topology database information used for creating emu-lated networks. . . 55

6.6. Simplified diagram of an OpenFlow LAN switch in the emulated network. . . 56

6.7. The architecture ofRyu[77]. . . 58

6.8. UML class diagram of a typical Ryu application skeleton. . . 59

6.9. Overview over the parts of the prototype whose implementations are described in Sec-tion 6.4. . . 60

6.10.Example of a super peer using the RASP API to set up a video stream and adding a member to it. . . 61

6.11.The structure of the RASP controller implementation. . . 62

6.12.The structure of the topology application implementation. . . 63

6.13.The structure of the Virtual Peer application implementation. . . 63

6.14.The structure of the SDM application implementation. . . 64

(10)

6.15.Multicast tree construction problem. . . 66

6.16.Schematic cutout of a SDM multicast tree with three different forwarding states. . . 67

7.1. Deutsche Telekom’s core network [26, p. 4]. . . 71

7.2. The network topology model used as basis for network topology with annotations on the scaling possibilities. . . 71

7.3. Access and aggregation networks: Ethernet application and PPP encapsulation. . . 72

7.4. Network model instance DT small. . . 74

7.5. Network model instance scaled by increasing the number of connected host per access switch (DT Hosts). . . 75

7.6. Network model instance scaled by adding core nodes (DT Core). . . 76

7.7. Network model instance scaled by increasing the trees depths (DT Depths). . . 77

7.8. Overlay network algorithm examples based on theDT Smalltopology. . . 79

7.9. The cumulative distribution functions of two characteristics of the three P2P video overlay tree algorithms. . . 80

7.10.The intra ISP data volume per peer for each topology and overlay network algorithm. . . . 84

7.11.The intra ISP data volume per peer for each topology and overlay network algorithm normalized by the mean of theRandomoverlay algorithm for each topology. . . 85

7.12.The cross-border data volume for each topology and overlay network algorithm. . . 85

7.13.The link stretch for each topology and overlay. . . 86

7.14.The RASP system architecture with annotations on system cost related parts. . . 87

7.15.Schema of the SDM distribution tree and the relevant parts for assessing the number of used OpenFlow rules. . . 88

7.16.The number of OpenFlow flow modification messages that install new rules during the network experiments. . . 90

(11)

List of Tables

2.1. The packet header match fields available in OpenFlow 1.0. . . 13

5.1. Comparison of multicast concepts (based on [46, p. 158]). . . 33

5.2. OpenFlow rule schema for marking packets addresses to a SDM multicast group on the group’s marking switches. . . 43

5.3. OpenFlow rule schema for writing a member’s socket information to packets of a SDM multicast group on the group’s member switches. . . 44

5.4. OpenFlow rule schema for switchS4. . . 46

5.5. OpenFlow rule schema for switchS9. . . 46

6.1. Throughput of the three OpenFlow software switches as measured byiperf. . . 53

6.2. OpenFlow 1.0 flowtables for a LAN switch in the emulated network. . . 56

6.3. RASP controller service API overview. . . 61

6.4. Topology application API overview. . . 62

6.5. Virtual Peer application API overview. . . 64

6.6. SDM application API overview. . . 65

6.7. OpenFlow matcherG_match for packets of SDM groupG. . . 67

6.8. OpenFlow rules during the three steps of the SDM tree forwarding example. . . 68

7.1. Overview of the methods and tools used for evaluation. . . 82

7.2. Average number of OpenFlow rules per device class for the scenario used for evaluation. . 89

(12)

(13)

1 Introduction

Internet video streaming causes the second largest transfer volume and is the second fastest growing application class in Internet traffic analysis [58, p. 82]. In the American broadband access market, streaming video is the source of 50% of the traffic volume and still expected to increase its volume share [101]. Many large video streaming services use CDNs or closed multicast systems. An approach that works without fixed infrastructure is Peer-to-Peer (P2P) video streaming. Using P2P systems enables Internet wide use of video streaming, but it is a burden for Internet Service Providers (ISPs) due to its hard to control, unpredictable, and unfavorable traffic patterns.

Software Defined Networking (SDN) and especially its OpenFlow variant is a network paradigm that gains traction in the network market [1] and which is already used in production environments [40]. OpenFlow enables network domains and, more importantly, the forwarding hardware network switches and routers to be controlled remotely by software. At the same time, it allows a logically centralized view on the network state. These features are of immediate relevance for efficient and centralized network management. Furthermore, new networking concepts can be applied that have been unfeasible before. This work investigates how OpenFlow can be used to improve Peer-to-Peer Live Video Streaming (P2P LVS) for users, operators and ISPs. The approach is based on cross-layer optimization, as OpenFlow is a network layer technology and P2P LVS an application layer technology. It focuses on the network domains of residential broadband access ISPs, whose customers are the main users of video streaming applications.

The concept presented in this work, Rent-a-Super Peer (RASP), is a service that enables users of P2P LVS systems to increase their network resources within a ISP network, thereby providing them super peer like capabilities. The service is offered by residential broadband ISPs for users outside their networks to distribute their video streams within the ISP’s network in an efficient way. This concept allows using the system on-demand. The generic cross-layer system enables P2P LVS to increase its number of super peers, which leads to improved system performance. At the same time, it improves the ISPs’ role in P2P LVS by increasing their control on P2P LVS traffic and making its transmission more efficient and, thus, reducing the generated traffic volume.

The approach of the service and its design is presented and discussed in this work. A prototypical implementation is described and its conceptual characteristics evaluated. OpenFlow is a new technology and its usage as well as its application to specific application domains is not extensively documented yet. Hence, this work should give an insight on how an OpenFlow application can be designed and evaluated. For designing the service, it is assumed that, in the future, OpenFlow will be adopted in most networking domains, including ISPs.

1.1 Goal and Contribution

The goals of the RASP service are threefold: improving P2P LVS systems as well as increasing the trans-mission efficiency and the control of P2P LVS traffic in ISP networks.

The service aims to improve P2P LVS systems by creating an on-demand service in ISP networks that provides super peer like network performance to normal peers. The services works for peers outside the ISP network by providing network resources for other peers inside the network. In addition to that, the

(14)

service provides them with a network layer proxy presence within the ISP network. The transmission efficiency is increased by using a network layer multicast mechanism for distributing the video stream. It uses unicast IP addresses and its usage is transparent for its users outside the ISP’s OpenFlow network. This approach in combination with the network layer proxy enables the ISP to have full control of the service and its network traffic.

The contribution of this work is the design of network layer service for enabling generic, on-demand ISP-owned Peers [89]. It is based OpenFlow and is aimed at exploiting the performance and efficiency of OpenFlow hardware. The RASP service provides the network resources, while the P2P LVS users provide the peer’s computing resources and operation. The respective applications providers add the integration of the service into P2P LVS systems. Due to its generic approach, the service can be integrated into a wide range of P2P LVS systems. This is possible because it does not require peers to support special network protocols such as IP multicast.

1.2 Outline

An overview of P2P LVS systems, ISPs, their relationship, and OpenFlow is given in Chapter 2. The state of the art on improvements of P2P LVS systems, their cooperation with ISPs, and approaches to integrate network layer multicast in P2P LVS systems is described in Chapter 3. The requirements for OpenFlow-based services offered by ISPs to P2P LVS systems are discussed in Chapter 4. The system design of RASP is described in Chapter 5, its implementation for evaluation in Chapter 6. The system is evaluated in Chapter 7. Its results are summed up in Chapter 8, finally and an outlook on the next steps in the research is given.

(15)

2 Background

In this section, the relevant background on the research areas of P2P LVS, ISPs and OpenFlow is given. The historical development of live video streaming on the Internet is described in Section 2.1, beginning from IP multicast to today’s P2P LVS systems. An introduction into the structure of the Internet and the role of ISPs is given in Section 2.2. Furthermore, their relationship with P2P LVS systems is described. Lastly, the SDN variant OpenFlow is introduced and relevant features described in Section 2.3.

2.1 Live Video Streaming

Live video streaming is only one of three forms of Internet video application types, the others are video file sharing, and video on demand. Video file sharing works similar to sharing of other files; the videos are downloaded and watched some time later. When using video on demand, the videos are played back while still being downloaded. In addition to that, live video streams are watched synchronously by all clients. The synchronicity of the playback of live video streaming is defined by application specific deadlines. If the deadlines are met the playback is considered synchronous [119, pp. 3548,3589]. The two major applications of live video streaming are video conferencing and Internet Protocol Television (IPTV). Typical differences in the usage characteristics between video conferencing and IPTV are the delay deadline and the number of users. In video conferencing, the number of participating users is small as is the delay deadline. For IPTV the delay deadline is higher, and the number of users is usually much larger [65, p. 14].

In live video streaming, a source sends a video stream to multiple of consumers. The natural way of handling this communication is multicast. The concept and application of multicast is described in Section 2.1.1, its application for streaming live video is described in Section 2.1.2

2.1.1 Multicast on the Internet

The different approaches on implementing multicast services are presented in this section. Multicast communication is a service for sending one message to multiple recipients. Without such a service, the sender has to send the message to each recipient separately. The sender and its recipients in multicast services constitute a multicast group; the recipients are also called members in this context. Computer systems connected to the network (hosts) can join and leave groups. Members of a group receive its messages and–depending on the system–can send messages to the group. However, in this work only multicast services with one sender per group are discussed. Components required by all types of multicast services are functionality for creating, joining and leaving groups. Further required functionalities are routing and signaling of the multicast group information as well as an addressing scheme for identifying multicast packets and their destinations.

A multicast service can be implemented on different levels of the ISO/OSI network layer reference model. In the next paragraphs, a short overview over the historical development of multicast services is given.

(16)

IP Multicast

The implementation of multicast services at the network layer is very efficient. This concept, IP multi-cast, has been a research topic since 1990 [22]. The goal of IP multicast is to create facilities for Internet wide multicast communications. The fundamental mechanism of all IP multicast services is the distri-bution tree. The members of a multicast group are connected by a tree spanning, which consists of IP multicast enabled routers. Multicast Packets are forwarded along the tree and duplicated at joints of the tree.

IP multicast consists of a number of components that are implemented using different network proto-cols. Multicast groups are identified and addressed by IP addresses from a special range [21]. Group man-agement, joining and leaving is enabled by a network layer group management protocol (e.g. IGMPv3 [15]) that is used between hosts and routers. To join a group, a host sends an IGMP message which is forwarded through the network towards the multicast management router. The management router adds the hosts to the member list, and adjusts the multicast tree accordingly. The setup and maintenance of the routes that constitute the multicast tree is provided by IP multicast routing protocols, such as PIM-SM [28]. Forwarding of IP multicast packets is done by the normal method of packet forwarding but with special IP addresses. The protocols described up to this point are for usage within a network domain. Interconnecting multicast domains is enabled by inter-domain multicast routing protocols (e.g. MSDP [27]). A wide range of IP multicast protocols exists, the ones mentioned here are prominent examples.

Today, IP multicast is not deployed on a global basis. Only isolated IP multicast domains, called mul-ticast islands, exist. For example, some ISPs use IP mulmul-ticast to deliver services like IPTV within their networks as for example described in [66]. The reasons for the failure of IP multicast to be deployed globally on the Internet are discussed in [23]. Although the paper is more than 10 years old, many arguments still hold. From a technical perspective, the deployment, management, and operations of IP multicast are complex and thus expensive. One problem that hinders the global deployment of IP mul-ticast is the necessity to store the state of mulmul-ticast groups in the network. IP mulmul-ticast enabled routers have to store information on the multicast distribution tree on each group they are part of. This charac-teristic is the reason for the unfavorable scaling characcharac-teristics of IP multicast, which is a cause for the failure of Internet-wide IP multicast. Today the scalability aspect of IP multicast is still an active research topic [92]. Admission control and security features are not part of most IP multicast protocols. Hence, ISPs have no control over IP multicast communications, its users and usage, while its implementation is expensive. Hence, there are no incentives for the major network providers to deploy Internet wide IP multicast services for public consumption.

Overlay Multicast and Application Level Multicast

Application layer multicast and overlay multicast were developed in response to the slow adaption of IP Multicast. Both approaches construct a virtual application layer network. “The main differences among [...] IP multicast, application layer multicast, and overlay multicast, depend on whether the group management and data delivery control are implemented in network routers, and hosts, or intermediate proxy nodes.” [113, 526] In application layer multicast, hosts replicate the packets and manage the group features, which is approach similar to P2P. The approach of overlay multicast is to connect IP multicast domains using specialized hosts. They act as multicast proxies, connecting the multicast islands in a P2P fashion. IP multicast and overlay multicast rely on the IP multicast protocol, while application layer multicast uses IP unicast only and therefore does not rely specialized routers.

(17)

2.1.2 Peer-to-Peer Live Video Streaming

While IP multicast is the most efficient method to implement one to many communications, it is not widely deployed. Hence, alternatives such as application layer multicast are researched and used. One form of application layer multicast are P2P LVS systems. The concept of such systems is described in this paragraph. In the following paragraph, an insight into current research on P2P LVS is given.

Applications are called P2P systems because they do net rely on servers to communicate. Instead, the application is run by the participating clients, the peers. Their communication paths form a virtual network on top of the underlying one, called overlay network. The underlying network is called underlay network in this context.

P2P systems are distributed systems in which participating entities (peers) share resources with the goal of running applications mutually. Each peer acts as client and server, the application is consumed and provided by peers at the same time. Different P2P systems have been developed to offer a range of applications such as file sharing, content distribution, and application-level multicast [67, p. 72]. The topology of the overlay network can be arbitrary and is not bound to the topology of the underlay network. However, the overlay networks performance is bounded by the resources and qualities of the underlay network.

Underlay network Overlay network Live video streaming Service: Video distribution

Network communication

P2P LVS System

Figure 2.1.:A P2P LVS layer model (based on [67], p. 73).

P2P LVS is an application of P2P systems for distributing live video streams. A layer model for such applications is depicted in Figure 2.1. The system is built on the underlay network, which is used for cre-ating overlay network connections to other peers. The system uses them for management, maintenance, and message transport. A video distribution service is built on top of the overlay network. It defines the topology and the behavior of peers during video distribution. Finally, the live video streaming layer creates a video stream for the consumption of the user. The general approach to live video streaming in P2P systems is to split into small pieces, junks, and distribute them using the overlay network. The methods for distributing the video is either tree or mesh-based. In tree-based systems, the video distri-bution topology forms a tree as shown in Figure 2.2a. Tree-based systems are application layer multicast systems. For each stream an arborescence is created, in which each peer immediately forwards the video data it receives along the arcs. The root of the arborescence is the source of the video, denoted by node A in the figure. The video parts 1,2, and 3 are available, as depicted by the blue boxes. These parts are consecutively sent to the downstream nodes B and C. Node C itself has two downstream nodes, to which it sends each part immediately after it is received. Nodes B, D, and E are leaf nodes, they receive the video stream but do not take part in its distribution.

Mesh-based systems work similar to common file sharing systems. As shown in Figure 2.2b, each peer maintains a list of currently relevant parts of the video. Neighbors exchange information on the

(18)

parts they already received and on those they need. Based on this information the missing parts are exchanged, initiated by either the receiver or sender of a part. In contrast to the tree topology there is no predefined video dissemination path and no predefined sender and receiver roles. Neighbors are treated individually, while in tree systems all downstream neighbors of a node get the next part as soon as it is available [119, p. 3552,3553]. A B _C D E 1 1 2 2 3 1 2 3 1 2 3 1 2 3 1 2 3 1 2

(a)Tree topology

A B C D E 3 3 2 3 2 4 1 3 2 4 1 1 2 3 4 3 2 4 1 3 2 4 1 2 1 (b)Mesh topology

Figure 2.2.:Tree and mesh topologies for video stream distribution in P2P LVS. Blue boxes denote existing, white boxes missing parts of the video.

The topology of P2P LVS systems influences the performance characteristics of the system. Tree-based systems have the advantage of achieving much smaller playback delays than mesh-based systems [119, p. 3559]. Their transmission efficiency is higher, because the distribution tree is fixed. For mesh-based systems the distribution of the stream is negotiated between neighbors for every junk, hence the manage-ment overhead is higher. The disadvantage of tree-based systems is their susceptibility to peers leaving the system unexpectedly. If a node fails, its complete tree of downstream node loses its video stream source. If a node in a level near the video source fails, such an event affects a large number of nodes. Multiple trees are used in some systems to mitigate this characteristic of tree topologies. The video is split in several sub streams at the video source and each sub stream is distributed through a different tree. The sub streams are recombined to a complete video stream before playback. Mesh-based systems have the advantage of being more resilient to peers leaving and entering the system. Due to this tradeoff, hybrid systems are developed which include either both topology approaches for different parts of the system or allow the dynamic switching for adaptation to different situations [4, p. 183,184].

P2P LVS issues

A number of issues existing for P2P LVS systems. An overview over current research topics is given in [4]. The issues can be categorized in three groups: underlay issues, overlay issues and application layer issues. Underlay issues comprise quality issues of network connections such as packet loss, high latency or failing links. Also, insufficient network resources influence the systems’ performance. One example are peers that are connected to the Internet by residential broadband Internet connections. These connections often exhibit asymmetric transmission capacities for upload and download, which restrict the number of downstream nodes a peer can forward the video stream to. In addition, the costs of the data volume might be an issue, for examples for broadband users with data volume limits in their contract.

(19)

The upload capacity of peers plays an important role in both topologies. In trees it constraints out degree of the participating nodes, which in turn influences the trees depths and the playback delay [4, p. 181]. In mesh systems, uplink capacities of a peers neighbor influences the number of them needed to receive all parts in time. In sum, the upload capacity determines how many neighbors a peer can distribute a video stream to. Also, studies show that the ratio of peers with low uplink capacities to peers with high uplink capacities influences the performance of the whole P2P LVS system [57],[64, p. 349].

Overlay issues concern the P2P network itself. Problems include bad overlay connections, unresponsive peers or improper overlay topologies. The unpredictable joining and leaving of peers in the system is called churn. It is of relevance in P2P systems, as the peers are part of the overlay networks infrastructure. Peer churn can cause instability in the system or be the reason for packet loss in the video stream in case of P2P LVS systems. Another problem is a high rate of new peers, which can overwhelm the system’s ability to integrate new peers; this phenomenon is also called flash crowd. Similar problems arise during high rates of peers leaving the system.

Lastly application layer problems could arise, especially if the ISP of the user tries to mitigate the negative influence of P2P systems on the network. This could lead to throttling or blocking of P2P overlay connections, obstructing the user to use the overlay network.

Approaches for mitigating these issues are an active research topic. Besides optimizing the P2P LVS sys-tems, mechanisms for the cooperation of different layers, called cross-layer optimization, are researched. One is underlay awareness, which is the concept of considering the characteristics of the underlay net-work and adapting the overlay netnet-work accordingly.

2.2 Internet Service Providers

ISPs play an important role in the Internet architecture. This work focuses on residential broadband Internet access. Other means of connecting to the Internet like cellular networks are not discussed, as P2P systems are discussed in the context of fixed Internet connections only.

In Section 2.2.1 an overview is given over the entities involved in the Internet architecture and the role and classification of ISPs. The network characteristics of broadband access ISPs are described in Section 2.2.2. The issue of P2P systems and their relation to ISPs is discussed in Section 2.2.3.

2.2.1 Classification

The Internet is made up of autonomous systems, administrative domains that are operated by entities that take the role of network operators. This section gives an overview of different types of network operators with a special focus on ISPs. ISPs are network operators whose purpose is to provide network connectivity to other entities. The networks differ in geographical extent, network degree, data volume, and place in the topology of the Internet. As shown in Figure 2.3, the networks can be classified into a hierarchy. On the bottom of the hierarchy are networks that are completely managed by a single entity and do net sell their connectivity (customer networks). They are geographically small, placed at the edge of the Internet topology, exchange small data volumes and are mostly connected to only on other network, their ISP. Examples for this class are home, company, and educational networks as well as small hosting companies. The next class are regional or tier2 ISPs, that offer transit connectivity for other networks, and large hosting and content companies. They might span a larger area, and are connected to a larger number of other networks, and exchange larger data volumes. Examples for this class are small ISPs and midsized hosting companies. The top class of the hierarchy is called the global Internet core.

(20)

It consists of worldwide operating transit ISPs (tier1), large content and hosting companies, and large consumer access providers. They have a high network degree and high transit data volumes. Examples for this class are tier1 ISPs like Verizon and Deutsche Telekom, large hosting and content companies like Google and content distribution companies like Akamai [58, pp. 78-80]. Internet eXchange Points (IXPs) are located between the top class and the middle class in the hierarchy. They are small networks (consisting only of a few hundred nodes), span a small area but their transit traffic volume and network degree [7] are huge.

Global Internet Core Regional/Tier 2 ISPs Customer IP Networks

Global Transit & National Backbone ISPs

"Hyper Giants"

Large Content Provider Networks, Consumer Access Provider , Content Distribution Networks

IXP

ISP 1 ISP 2

IXP IXP

Figure 2.3.:Hierarchical topology of the Internet [58, p. 78].

2.2.2 Network Topology and Characteristics

Most entities from the global Internet core have no direct business contacts with end customers. Large content and transit providers sell their services to other ISPs. The same is true for IXPs, content providers like Google and content distribution providers like Akamai. Often, IXPs operate at layer 2 only [7, p. 165] and are not involved with the Internet protocol or services provided by upper layers of the ISO/OSI reference model because of that. The only exceptions are large consumer access providers, for example Comcast. The approach described in this work is applicable for ISP with end costumers, because they are the ones interested in P2P LVS services. Only a few consumer access providers are “Hyper Giants”, hence can be seen as a special case.

Providing a service for P2P LVS systems and users implies a business relationship with residential broadband access users. P2P LVS are alternatives to Content Delivery Networks (CDNs), hence the content providers are not the target group. This leaves tier2 ISPs as the main audience for P2P LVS optimization services. Consumer ISPs share certain network characteristics. A typical structure of a resi-dential customer ISP is shown in Figure 2.4.

It consists of three types of networks: access networks, aggregation networks and one core network. Access networks consist of devices needed for the network links to the customers. Aggregation networks aggregate the customer connections and connect them to the backbone. Both access and aggregation networks are either local or regional networks of which a number exists. There is one core network, which enables connectivity between the aggregation networks, the Internet and other parts of the ISP [33, p. 1][36, p. 1284]. The system is hierarchical; a tree is formed with the core network as root node, the access networks as leaves and aggregation networks as inner nodes.

(21)

ISP Internet Core Aggregation Access ISP C ISP B ISP Aggregation Access Access Access Access Access Internet

Broadband Customer Networks

Figure 2.4.:ISP network topology by network types.

Global routing on the Internet is provided by network connections to neighboring networks. The con-nectivity is redundant for resilience and performance. Each network operator applies its own policies for routing, with which the forwarding of its own and transit traffic can be influenced. This is not true for incoming traffic however; it can enter the ISP network on any link that is connected to another network. Predictions on where traffic from other networks enters the ISP network are hence not possible. Applying special treatment for traffic from certain networks is only possible when it is enabled on all incoming links.

In the core network, IP and often MPLS are used for forwarding. It is optimized for high throughput and efficient forwarding, not for service delivery or its implementation. In the aggregation and access networks, the network protocol used for forwarding depends on the access technology. When offering In-ternet connectivity to consumers, the network access technology used has a big influence on the network. Network access technology groups are Digital Subscriber Line (DSL), cable and Fiber-to-the-x (FTTX). DSL uses existing telephone wires as medium, cable works on existing TV cables while FTTX relies on fiber cables to or near the access location. The currently prevalent residential network access technology is DSL both worldwide and in Western Europe. The worldwide and western European market share of DSL is about 60%. The market shares of cable are similar for both areas at about 20%. The market share of FTTX shows a difference, it is globally at about 20% and in western Europe below 10%. The remaining market share represents other connection technologies that are not listed separately [105, 93].

(22)

2.2.3 ISPs and Peer-to-Peer Systems

P2P traffic makes up a considerable part of the traffic volumes [69, p. 90][58, p. 82]. Hence, it affects the ISPs and their networks, and here especially residential broadband access providers. This is because the users of P2P systems are predominantly residential broadband users. Most of the data volume is caused by P2P file sharing.

The effects of P2P systems on ISPs are an active research topic. While many issues arise from the usage of P2P file sharing system, many aspects are valid for P2P LVS systems too, even when they are used at a smaller scale. A good overview of the research is given in [25] and [20]. P2P systems cause considerable network traffic, while bringing no additional profit for the ISPs. Many overlay systems are unaware of the underlying network topology leading to inefficient network usage. This could result in increased usage of expensive links. The amount of data volume leaving the network could also increase. This is an issue, because of the billing structure between network operators on the Internet. While transit and tier1 providers and large networks often have different approaches for settling their peering, smaller tier2 providers have to pay for the data volume transferred. In addition, controlling P2P traffic is difficult, as it is often encrypted. Unpredictable usage pattern and traffic flows in the overlay network make it more difficult for ISPs to manage their networks and to ensure service quality for all users.

A large body of approaches on how to improve this situation have been developed, good overviews are given in [20] or [25]. Unilateral remedies deployed today by ISP are throttling and blocking of P2P network traffic. However, due to the market competition, and legal issues such as net neutrality, research suggests other solutions. One approach that can be used by P2P systems is implementing underlay aware-ness as described in Section 2.1.2. Even greater improvements are expected from cooperation between ISPs and P2P systems. Examples are topology information services provided by ISPs that are used by P2P systems to improve their underlay awareness.

2.3 Openflow

OpenFlow is a variant of the SDN approach. Unlike earlier variants, it is supported by hardware vendors and dedicated high performance OpenFlow hardware is available. The technology is already deployed in the industry [40], and is popular in the research community.

In traditional networks, the forwarding elements, such as switches or routers, consist of specialized hardware for packet forwarding, the datapath, and a general purpose CPU that runs management soft-ware. The management software configures the datapath; both, the software and the hardware are vendor specific and not standardized. The forwarding elements exchange relevant information using feature specific, standards based network protocols as shown in Figure 2.5a. The management software of such a network represents a distributed system. This has the advantage of high robustness against failures of single forwarding elements. However, as no central entity exists, it is managed by changing settings in the configuration of the management software of single forwarding elements. Due to the dis-tributed network state, configuration or network changes take time to disseminate through the network [90, p. 8]. It is generally not possible for researchers or users to change the behavior of forwarding elements as the vendors do not disclose details of their implementation. Hence, often routers based on PCs are used, for which free open source routing software exists. However, low performance makes soft-ware routers unsuitable for large experiments or production deployments. To change the behavior of the network, the modification of the network protocols used is necessary. This is difficult, since for changed network protocols the forwarding element’s software needs to be changed. Hence, standards need to be

(23)

changed, which might in turn be implemented by the vendors. This situation slows down the research of networks as well as the introduction of new networking features [71, p. 12].

Flow Table Secure Channel OpenFlow Flow Table Secure Channel OpenFlow Flow Table Secure Channel OpenFlow Normal Datapath Normal Software Normal Datapath Normal Software Normal Datapath Normal Software Feature Specific, Standards Based Network Protocols

(a)Traditional networking scheme.

Flow Table Secure Channel OpenFlow Switch Flow Table Secure Channel OpenFlow Switch Flow Table Secure Channel OpenFlow Switch OpenFlow Controller OpenFlow Protocol Secure Channel Flow Table Secure Channel Flow Table Secure Channel Flow Table

(b)OpenFlow networking scheme.

Figure 2.5.:A traditional networking scheme and the OpenFlow networking scheme [see 72, p. 2].

OpenFlow [72] introduces a concept for managing computer networks that aims to change this situ-ation. OpenFlow is a standard that defines the configuration of datapaths and a protocol for the remote configuration of them: the OpenFlow protocol. This allows moving the management of the forwarding device to a central software system, the OpenFlow controller, as shown in Figure 2.5b. An OpenFlow network is still a distributed system, but centralized management is possible. OpenFlow forwarding ele-ments are called OpenFlow switches, the datapath of an OpenFlow switch is called flow table. OpenFlow datapaths can be implemented in hardware, which allows the configuration of high performance for-warding hardware with an open standard protocol. The scopes of OpenFlow are Ethernet and TCP/IP based networks, specifically the OSI/ISO network layers 2-4. The OpenFlow controller is software that runs on a standard PC. It is connected to the OpenFlow switches, handles incoming information from them and sends configuration messages.

The general packet-forwarding scheme of OpenFlow is based on rules stored in the flow table. Each rule consists of a matcher and actions. The matcher consists of values for packet header fields of Layers 2-4 of the TCP/IP network stack, that are matched against the values of arriving packets. If all values match, the list of associated actions is applied. Actions include the changing of header field values,

(24)

ing packets out a network interface, dropping packets and sending incoming packets to the OpenFlow controller.

In Section 2.3.1 an overview is given on OpenFlow, its implementations and the versions of the Open-Flow standard. The latter are described in more detail in Section 2.3.1.

2.3.1 The OpenFlow Standard

The OpenFlow standards, named “OpenFlow Switch Specification”, define a network protocol and asso-ciated roles for communication between an OpenFlow controller and an OpenFlow switch. The purpose of the OpenFlow protocol is to enable the remote operation of the OpenFlow switch from the OpenFlow controller. The main responsibilities are the configuration of the flow table on OpenFlow switches and handling associated events. These include packets that are forwarded from the OpenFlow switch to the controller for inspection and flow table related events like rules that are remove due to timeouts. The protocol also enables the controller to configure and gather statistical data on the flow table. Finally, OpenFlow switches send events on their status to the controller; examples are a change of a network interface status. The configuration of the switch hardware is not part of the standard, however an ac-companying standard, the “OpenFlow Management and configuration protocol” (OF-Config) [83]. Its responsibility includes the configuration of the network ports and accompanying queues as well as con-figuring the switches flow tables and their controller connections. The OF-Config protocol is beyond the scope of this work.

The OpenFlow standard describes a network protocol and by defining the semantics of the flow table configuration messages, the behavior of an OpenFlow switch. An overview over the versions of the OpenFlow standard and their port prominent features is given, then relevant versions are described in detail in the remainder of this section. The first OpenFlow standard for public use, version 1.0, was released in 2009 [78]. It contains a simple flow table model, which also illustrates basic OpenFlow concepts. A number of updates of the OpenFlow were released. Version 1.1 was published in 2011 [80] and includes, among other changes, a fundamental change of the flow table behavior. All OpenFlow versions release after 1.1 introduces incremental changes, but no major change as from version 1.0 to 1.1. OpenFlow version 1.2 [79] – published in 2011 – introduces a new approach for packet matching. Two versions of the standard were released in 2012, version 1.3 [81] and 1.3.1 [84]. OpenFlow version 1.3 adds a number of supported network protocols, improves the connection to the controller and introduces interoperability to the OF-Config protocol. The latest version of the standard, version 1.3.1, contains predominantly corrections and small improvements. The last two standards will not be discussed in details, as currently no complete implementations are available, neither for the controller nor for the switch.

OpenFlow 1.0

The process of packet handling in OpenFlow version 1.0 [78] starts with an incoming packet. It is matched against the rules in the flow table; the action list associated with the first matching rule is applied to the packet. The rules in the flow table are ordered by their priority value. Figure 2.6 shows the operating schema of the flow table in OpenFlow version 1.0.

For matching, a set of packet header fields and the ingress port of the packets can be used as shown in Table 2.1. Matching rules consist of values for one or more of the fields, which are matched against the values of incoming packets. Fields that should not be matched can be marked as wildcard value, in this case all values match. For all fields except the IP addresses, matching means that all bits of the given value and the packet data are equal. In case of IP addresses, a subnet mask may be set, in which case

(25)

Matcher Action List

.

Incoming packet

Find matching rule

Apply actions Matcher Action List

Matcher Action List

Flow Table

Figure 2.6.:Operating schema of the OpenFlow version 1.0 flow table.

only a part of the IP addresses bits are used for matching. The matching of IP address subnet masks is an optional feature, not every OpenFlow is required to support it. The same is true for a number of actions. Due to the conceptual and explorative nature of this work, from here on, no distinction will be made between required and optional features. Instead, it is assumed that all features they are described in the standards are available for use.

Packet Match Field Ingress Port

Ethernet source address Ethernet destination address Ether type VLAN id VLAN priority IP source address IP destination address IP transport protocol ID IP ToS bits

TCP/UDP source port or ICMP type TCP/UDP destination port or ICMP code

Table 2.1.:The packet header match fields available in OpenFlow 1.0.

If a rule matches, the associated actions are applied. Available actions include the changing of the values of the packet header fields that can be used for matching, except for ICMP code and type. In addition to that, a packet can be forwarded to a single port or all ports, to the controller or it can be dropped. The actions given in the list are applied in the order specified. An action list may include the repeated writing of header fields and multiple forward actions. If no rules match the packet, it is send to the controller for further inspection. For all ports, rules and tables, counters are kept to keep statistics on the packets processed.

An important aspect of the OpenFlow standard is the interaction of OpenFlow switches with the con-troller. As described, incoming packets are sent to the controller in case no rules match or the matching rules include a corresponding forwarding action. There is no required behavior for the controller

(26)

ware in this case defined in the standard. For certain applications however, the controller can use the packet information as basis for installing new rules in the flow table. In addition to that, the controller may also send packets to an OpenFlow switch. They are associated with an action list that is applied on the switch. This list may include all actions described above and it is possible to handle the packet by the flow table. This facility enables a controller to send packets through connected OpenFlow switches.

The main responsibility of the OpenFlow controller is the management of the flow table rules. Methods for adding, modifying and deleting rules are available. For management, flow table rules are identified either by their exact matcher or by the notion of matching equivalency. In the first case, a rule man-agement command applies to the rule that exactly matches the manman-agement commands matcher. In the latter case, all rules that are matched by the commands matcher are affected. Hence, a delete command whose matcher contains wildcards for all fields would remove all rules from the flow table.

Rules installed can be given timeout values, a soft and a hard time. A rule with a hard timeout value is removed after the given time. A rule with a soft timeout value is removed if there is no matching packet for the given time. In both cases, a message is send to the controller containing information about which rule was removed due to what reason.

OpenFlow 1.1

OpenFlow version 1.1 introduces a new packet-processing scheme. Instead of the single matcher that causes the application of an action list, a pipelined more flexible model is used. The packet processing consists of multiple tables, each with a different set of rules. Packets traversing the table pipeline are associated with a metadata field and an action set, which is executed at the end of the processing and which can be changed by each rule. The action set is kept for each packet during the processing pipeline. Each available action can be included in the set once; the execution order of the set is predefined by the action types. The packet-processing model of OpenFlow 1.1 is shown in Figure 2.7.

Incoming packets are processed in flow table 0, similar to the method used in OpenFlow 1.0. However, each rule has an associated instruction set instead of an action list. The instruction set may contain one rule of each instruction type. Instructions exist for modification of the action set. In addition, an instruction allows the immediate application of an action list, similar to the OpenFlow 1.0 flow table operation. As shown in Figure 2.7, at the end of the processing pipeline each packets action set is applied.

Incoming packet

Flow

Table 0 Table 1Flow

P P action set Flow Table n Apply action set P action set Apply instruction

set Apply instructionset

...

_P _{action set}

Figure 2.7.:Operating schema of the OpenFlow version 1.1 packet-processing pipeline.

The pipelined packet processing allows the reuse and combination of rules. In OpenFlow 1.0 each packet is matched by exactly one matcher, which is associated with exactly one predefined action list. Pipelined processing changes this situation, as each packet can be matched by a number of rules. For ex-ample, a firewall implementation in OpenFlow is considered. First, each packet is checked if the security policy allows it to be forwarded. If this is the case, the output port is set and the packet is forwarded.

(27)

With OpenFlow 1.0, for each combination of msecurity policy entries and nnext hops a rule has to be created. With OpenFlow 1.1, the security policies and forwarding rules can be implemented using two different tables. Using OpenFlow 1.0n∗m rules need to be created; OpenFlow 1.1 only requiresn+m

rules.

The table layout can be defined by the controller. For each rule, the next table id to continue processing can be set using a corresponding instruction. Furthermore, for each table, the behavior in case no rules matches can be defined. This includes the possibility to continue the processing at another table. One restriction is that the next table id for processing has to be larger than the old one.

In addition to pipelined processing, OpenFlow version 1.1 introduces groups. Groups are associated with a type and a list of actions buckets, which in turn contain action sets. The group typeallreplicates the packet for each of the action buckets. After application, pipelined processing is continued for all packets. Groups are referenced by their id and can be utilized by applying a corresponding action to packets. An application example for the group type all is multicast. For each multicast group a group entry is created, for each next hop of a group an action bucket is added. Each action bucket then contains an output action for the corresponding interface where the next hop is connected.

OpenFlow 1.2

The main change in OpenFlow 1.2 is extensible match support. Instead of using a predefined set of matchers, extensible matchers introduce a data structure for describing match fields. For selecting which fields should match, the notion of wildcards – as used in OpenFlow 1.0 – is abandoned. Instead, for each field its extensible match description and comparison value is included. The description includes the field that should be matched and a bitmask that is applied for matching. This approach enables the application of arbitrary bitmasks for matching of most fields. This approach enables e.g. the matching of a single bit of a packets IP address.

In addition, OpenFlow version 1.2 introduces support for IPv6 and MPLS and the VLAN support is improved.

2.3.2 OpenFlow Switches

OpenFlow has attracted a large number of companies and organizations [1]. A wide variety of OpenFlow controller software, OpenFlow switch software and hardware is available, both by commercial vendors and by open source projects. While OpenFlow software switches are convenient for testing and some usage scenarios, the main advantage of OpenFlow are hardware switches. The most prominent feature of OpenFlow hardware is the matching hardware, of which the most efficient implementation is based on Content-addressable Memory (CAM). CAM allows the lookup of bit field matches in one clock cycle [88, p. 712]. Two types of CAM exists, one that implements exact bit matches and one that allows wildcard bits. CAM is already used in today’s network hardware, the OpenFlow protocol enables its usage based on an open standard. However, CAM has a high power consumption, its size is restricted [88, p. 1] and is expensive [68, p. 81].

As each OpenFlow matcher requires a certain amount of CAM, the amount of CAM becomes a re-striction. Therefore, one restriction of OpenFlow hardware switches is the number of rules the devices can host. The maximum number of supported flow entries for hardware switches could not be found in literature, however a vendor claims for a contemporary OpenFlow switch to support up to 160,000 flows [74]. Information on older hardware shows much smaller numbers, for example between 512 and 1024 entries in [75, p. 30]. Like most controllers and switches available at the time of writing, it

(28)

supports OpenFlow 1.0 only. Information on the numbers of supported OpenFlow 1.1 rules is not avail-able yet. The OpenFlow features that are implemented in hardware vary between devices. Furthermore, the number of supported rules is different for each feature [86]. Hence, the hardware restrictions of contemporary OpenFlow switch hardware are not obvious; they require an analysis for each device.

The sizes and prices of available CAM are analyzed in [68]. Commercial available devices include CAM chips with 512,000 40-bit entries for matching. Given that each OpenFlow 1.1 match field can be implemented in one entry and consumes at maximum 128bit for an IPv6 address, devices with 100,000 flow entries seem feasible. This number is supported by the vendor reference mentioned earlier in this section on devices with a 160,000 OpenFlow rule capacity.

(29)

3 Related Work

No relevant approaches exist that aim to provide a similar service that is local to an ISP. The goal of most works is to improve and analyze P2P LVS system at a global level. However, due to its cross-layer approach, which aims to be useful for ISPs and P2P LVS system operators as well as users, the RASP service is related to a wide range of research topics.

Research on ISP and P2P cooperation is presented in Section 3.1. Improvements for P2P systems by integrating IP multicast islands and using super peers are described in Section 3.3 and Section 3.2. Ap-proaches on improving IP multicast are introduced in Section 3.4, OpenFlow-based multicast apAp-proaches in Section 3.5.

3.1 ISP and Peer-to-Peer Cooperation

The approach in this work is using cross-layer optimization for P2P systems and ISPs. Specifically, both stakeholders should cooperate with the goal of improving their situations. An overview of the topic is given in Section 2.2.3. Here, works that a relevant for this thesis are presented and discussed.

3.1.1 ISP Network Information Services

A number of approaches exist that propose that ISPs offer information on their network topology to their customers. Peers of P2P systems can use this information to optimize the overlay network topology. The ISPs benefits through P2P locality, the P2P users benefit from a higher Quality of Service (QoS) due to increased traffic efficiency. In addition to that, ISPs can use the systems to influence the behavior of P2P users. This can be achieved by adapting the offered information to their cost structure or their traffic engineering approach.

Older approaches are the network Oracle [8] and P4P [115]. For using the Oracle, peers send network addresses on prospective neighbors to the Oracle system. The system orders the address according to its preferences and sends them back to the peer. A more recent approach is Application-Layer Traffic Optimization (ALTO) [102], which is developed based on the P4P concept. An Internet Engineering Task Force (IETF) standard for the ALTO protocol exists, and it is already used in real networks [61]. The ALTO service specifies different request methods. Request similar to the ones use by the Oracle approach are supported, but the system also supports the distribution of network cost maps, which can be used by clients without sending a request every time.

The IETF ALTO standard service [11] aims to enable a mechanism for applications to gather informa-tion on the network the applicainforma-tion is running in. ALTO servers are discovered by clients that can send queries. Offered information are peer-to-peer cost paths and network cost maps for specific peers.

The approaches described in this section aim at improving the influence of ISPs on the traffic of P2P LVS, which is one of the goals of the RASP service. While it uses a different approach, the approaches described are complementary to the RASP service, hence could be used alongside for further improve-ments.

(30)

3.1.2 ISP-Owned Peers

The concept of using ISP-owned peers to enable the ISP to influence P2P networks is presented in [89]. An ISP-owned peer participates in a P2P system while being controlled or influenced by the ISP it is operated in. It could either be operated by the ISP or by a different entity, that agrees to implement the goals of the ISP in exchange e.g. for network resources. The approach is used in P2P file sharing networks to reduce the traffic volume crossing the network boundaries. The evaluation shows that the approach works and increases the control of the ISP on the P2P traffic.

However, ISP-owned peers contain P2P application specific parts. They have to be updated and man-aged along the P2P software [20, p. 224]. There are a number of different P2P applications used today. Hence, it is not clear how the approach can be efficiently implemented and operated on a larger scale. Also, participating in an P2P overlay network can have juridical consequences, for example if illegal content is distributed and stored on the ISP-owned peer.

ISP-owned peers join a P2P system with the goal of influencing it in the interest of the network opera-tor. This idea is the basis for approach used with RASP. However, the RASP service improves the concept by introducing a generic on-demand network layer service. This approach shifts the burden of operating and integrating the service into different P2P LVS systems from the ISP to P2P LVS users and applications providers.

3.2 Peer-to-Peer Live Video Streaming and Super Peers

The super peer concept for P2P systems is widely used and researched. Super peers are peers that fulfill special tasks that could not be achieved by normal peers. This might be due to their stability, their trust relationship or their available resources for computing or bandwidth. While this hierarchy for peers is somewhat contradictory to the concept that all peers are equal, a number of works have shown that using them has an advantage. These concepts are relevant to this thesis, as applying cross-layer optimizations in technological islands leads to natural clusters and to the question if the empowerment of single peers can improve the whole P2P LVS system performance. The idea of empowering single peers by providing them network resources is the RASP systems benefit for P2P LVS systems. Hence, it is interesting to see how this empowerment can be used to not only improve P2P LVS, but how its effects can be further increase by specifically exploiting them. Super Peers are specific to their P2P LVS system and set up by the P2P LVS system operator or its users.

3.2.1 mTreebone

mTreebone [110] is a P2P LVS approach, which introduces a hybrid tree and mesh topology for improved resilience. To combine the advantages of tree and mesh topologies, a tree topology for video distribution is created for video stream delivery. A mesh topology overlay exists to handle packet loss in the tree topology. To increase the resilience of the tree topology, the system relies on a backbone, called treebone, which consists of super peers. These super peers are elected because of their stability. They make up the upper levels of the distribution tree. Other, normal peers are connected to the super peers. The mesh overlay network is created over all nodes and is only used in case the tree delivery fails.

The authors show that their approach works and increases the resilience and quality of the system. This result stresses the relevance and usefulness of super peers. Hence, mTreebone would be well suited to use the RASP service.

(31)

3.2.2 SALSA

In [51], a Super-Peer Assisted Live Streaming Architecture (SALSA) is presented. The basic idea is to auction video streaming quality in exchange for video distribution. The proposed P2P LVS system consists of three kinds of nodes, the single video source, super peers, and leaf peers. Super peers get the video stream from the source and distribute it to leaf peers, which do not distribute the video stream further. The system uses a multi tree approach, where the video stream is split into sub streams, which can be recombined arbitrarily. Each additional sub stream increases the quality. The number of sub streams the super peers get varies, while leaf peers always get the lowest quality. The goal of the video source is to service as much leaf nodes as possible. The video source auctions full quality videos streams to super peers. The payment in the auction is video streaming time to leaf peers. A super peer offers streaming time to a number of leaf peers; the highest bidder gets the full quality video stream. This incentive motivates super peers to use as much of their upstream bandwidth as possible for distributing the video stream. Due to this mechanism, the tree construction is influenced by the auctions. The authors show by simulation that their approach works and that is has the desired property of motivating upstream bandwidth contribution.

SALSA is based on the contributions of super peers, which makes it interesting for the RASP service. The work shows that to account for super peers during P2P LVS system design is beneficial. Furthermore, an approach is described on how to motivate users to increase their upstream bandwidth. Hence, it could be adopted for motivating users to use the RASP service.

3.3 Overlay Networks and Multicast

The approaches on combining IP multicast and P2P systems can be distinguished in two groups: one aims to support and improve IP multicast with P2P systems and one that aims to improve P2P systems with IP Multicast. In this thesis, we are interested in the latter approach. A P2P system should be opti-mized by integrating network multicast services where available. However, much of the literature tries to connect multicast islands to enable global multicast. While these approaches have not the same goal, it is interesting to investigate the approaches used and how they are related to RASP.

There are a number of approaches on this topic. One is the Scalable Adaptive Multicast (SAM) re-search group of the Internet Rere-search Task Force that investigates multicast protocols including hybrid techniques that combine application layer multicast with IP multicast [49]. The group proposes to an existing generic P2P overlay for connecting multicast islands.

Another approach is called island multicast. Its goal is to improve application layer multicast by in-tegrating IP multicast islands into the overlay network where available. A number of island multicast approaches exists [45, 113, 62].

In [46] an overview is given on the research on island multicast until the year 2009, hence, [113, 62] are not discussed there. The fundamental concept is similar with all approaches. Most systems exhibit a global tree-based overlay network, and an IP multicast control group local to the corresponding island. Peers first detect if they are located within an IP multicast island by contacting the local control overlay. If there is no IP multicast support, the peer forms its own island and uses the application layer multicast overlay network for operations. If the peer is located within an island, it connects to the other peers of the island. Some of them are connected to the global control overlay to peers of other islands. Thereby all islands with its peers are connected into an Internet wide multicast network.

(32)

The focus of the research is the efficient and resilient interconnection of the IP multicast islands. Island multicast systems can be classified by the implementation of their functional elements: island management, overlay joining, ingress and egress peer election, and connecting multicast islands [46, p. 159]. Some approaches designate a local peer (leader) for island management. If there is no leader, all local peers join the global overlay network.

Island multicast approaches combine the global connectivity and robustness of application layer multi-cast with the efficiency of IP multimulti-cast. Efficient and reliable ways of interconnecting the multimulti-cast island exist. Open research questions are error correction within multicast islands and the integration of these approaches with mesh-based overlay networks. However, the application scenario of these approaches is not clearly defined. They aim to overcome the limitations of IP multicast islands without considering the reasons for the failure of global multicast as described e.g. in [23] (see Section 2.1.1). Most of the island multicast systems require globally unique multicast IP addresses for operations, which is an unsolved problem. IP multicast authentication, authorization, encryption and data integrity are still open issues, which might cause ISPs to refraining from opening their IP multicast platform to third parties. The busi-ness case is not discussed; still it could be assumed that an operator of an application layer multicast system is required to contract for IP island operations. Most approaches assume in their evaluations that a significant number of IP multicast islands are available. For efficient operations, large deployments are needed which improve the situation of operators using the service. In addition, the system is based on IP multicast, all routers and the end device have to support IP multicast for operations.

The island multicast approaches share a goal with the RASP service: to exploit locally available net-work layer multicast mechanisms for global communication systems. However, the approaches are very different. Many island multicast approaches aim at connecting IP multicast island for their global use. This approach has its disadvantages, as described in the last paragraph. Hence, for RASP a local ap-proach is chosen, that allows single multicast islands to be integrated into existing P2P LVS systems. This approach has the advantage that it is useful even with a small number of deployments. Furthermore, its deployment does not require new application layer multicast systems as the island multicast approaches do.

3.4 Improvements to IP Multicast

While IP multicast is deployed, it is not globally connected. Nevertheless, improvements on multicast are researched. Some of these approaches are interesting to consider when implementing multicast with OpenFlow.

IP multicast is a research topic for already more than 20 years. A large number of concepts has been proposed and analyzed. In this section, a number of approaches are introduced, that propose concepts that are be helpful for integrating P2P with OpenFlow based multicast.

The flexibility and performance of OpenFlow allows the implementation of concepts that have hitherto been impractical to implement. This concerns especially addressing schemes and concepts for addressing the multicast scaling problem.

3.4.1 Recursive Unicast

In [104] the network layer multicast scheme REUNITE is presented, where unicast IP addresses are used for forwarding and delivery to implement a multicast-forwarding scheme. The main goal of the approach is to increase the scalability of network layer multicast by reducing the amount of multicast

Cross-layer Optimization of Peer-to-Peer Video Streaming in OpenFlow-based ISP Networks