Multipath Video Streaming Based on Hierarchical Routing Management Thomas Volkert, Manuel Osdoba, Andreas Mitschele-Thiel Integrated Communication Systems Group Ilmenau University of Technology Ilmenau, Germany {thomas.volkert, manuel.osdoba, mitsch}@tu-ilmenau.de Abstract—In this paper, we propose a new approach to enhance today’s hop-by-hop routing. The main goal of our work is to improve the efficiency of network usage and to support transmission requirements (TR) provided by applications. In the paper, we focus on non-functional requirements such as a desired upper bound for the end-to-end delay and a required data rate. Both are encoded as meta data in each data packet. Furthermore, we describe how these embedded (in-band) TRs can be used for QoS-oriented routing, implemented on each intermediate router. This directs packets along routes, providing only the network resources actually needed. In order to support these routing decisions based on TRs, we utilize data from an additional control plane, which provides QoS-related topology data from the network. For this purpose, we apply our idea of “Hierarchical Routing Management” (HRM). It implements a signaling of QoSrelated route capabilities. In order to provide a scalable system, we apply hierarchical addressing and topology aggregation, resulting in fewer details in higher hierarchy levels. In detail, we describe how SCTP can be used to encode and transport the TRs for a multipath video-streaming scenario. Moreover, we explain the HRM internal signaling processes, which are required to create and use the HRM system. Compared to current IP routing, this allows for a better network efficiency and QoE at receiver side. Nevertheless, the HRM approach remains backward compatible to current application and router implementations. The paper shows that these benefits can be achieved at an acceptable overhead for packet processing. Keywords—Multipath; video streaming; hierarchical routing management; quality of service; transmission requirements
I.
INTRODUCTION
Today’s Internet serves numerous purposes. Multiple applications try to simultaneously acquire as much as possible of the available network resources. For example, online gamers desire a service, which is provided with a rather low per packet latency. If such a service also includes live videos from each participant, the transmission requirements (TR) are even harder to achieve. In contrast to this, a low and stable delay is of less importance for on-demand video streaming, a high data rate is sufficient. Video (pre-) buffering compensates delay deviation (jitter) and allows for a stable playback. In general, the requirements for the Internet have increased dramatically since its early days, especially for multimedia streaming. However, the Internet along with the used Internet Protocol (IP) ignores individual TRs. IP tries to provide best-effort forwarding and routing for all data independent from the application and its
Martin Becke Computer Networking Technology Group University of Duisburg-Essen Essen, Germany
[email protected] requirements. This works in a proper way but is not as flexible as it could be. There is a consensus in the research community that the limits of this approach are reached. A rethinking and a reworking of the currently used network protocols is needed and has already been started. In this context, multipath transfers were developed. They are built on the assumption that multiple routes from the source to the destination are available and can be simultaneously used. The approach shows promising results [1] when implementing redundant transmissions and load balancing. However, multipath transfers need a strong interaction between the application and the network in order to utilize the existing physical network in an efficient way for all involved network entities: the service costumer, the network provider and the service provider. In this work we describe a concept for combining existing infrastructures and protocols with new routing mechanisms [2] in the network. This also allows for a soft transition to a network architecture that supports high flexibility, as it is provided by Internet architectures such as “Forwarding on Gates” [3] and “Encapsulated Responsibility-Centric Architecture” [4]. We focus mainly on video streaming because we see this as a common and also challenging scenario for current as well as future networks. To provide this service, it acquires huge amounts of network resources, as we have shown in our previous work [5]. Moreover, it shows a high divergence of the actually demanded requirements for a transmission across the network. In this paper, we explain our view of multipath media transfers and how the desired TRs can be transmitted to the network in chapter II. In chapter III, an overview about our approach of “Hierarchical Routing Management” as background control plane is given. Furthermore, we explain how this improves the possibilities for packet processing in the data plane within IP based routers in order to provide a QoS-oriented routing for application data. After that, in chapter IV we analyze the computing complexity of the data plane. Finally, we conclude our work and present future steps. II.
MULTIPATH MEDIA TRANSFER
Video streaming is one of the best examples to apply and benefit from multipath transfers. Different views emerge as to how a network can be used in a more sophisticated way than it is implemented by standard IP based networks. In the following we use this scenario to raise up the addressed questions of this paper.
A. Logical Streams In general, a video stream processed in an application consists of separate video frames. They are fragmented and split into packets to transmit them across the network. However, such a video stream consists of important key frames, demanding for high data rates, and less important intermediate frames. They represent the differences between two key frames and demand lower data rates. The latter may also allow higher delays and may be dropped at receiver side if they are received too late. Therefore, a video stream can be split into different logical streams with different TRs. But such an approach has to multiplex the data streams over the same network interfaces. Current networks handle such data in a uniform way and data describing information (“meta data”) like the mentioned TRs is missing during packet processing. But based on such additional meta data, the resulting QoS could be improved and a more efficient usage of the network could be implemented. Packets could be routed along paths providing the network resources, which are actually needed for the corresponding application. B. Transmission Requirements In general, transmission requirements (TR) can be divided into two major categories. On the one hand, functional requirements can be demanded by the service for its data transmission. For example, ordered transfer, partially reliable transmission, mobility support or security features can be demanded by the service. On the other hand, non-functional requirements such as an upper bound for the resulting delay and a required data rate for an end-to-end transmission can be demanded from the network. In this paper, we mainly focus on the non-functional requirements. For example, sending voice data via a transit network, increasing the overall delay by two seconds, or transmitting video along links, physically limited to the half of the required data rate, is not acceptable for a live conferencing application. But based on the described TRs the network would be able to provide QoS-oriented routing and avoid non-feasible routes. C. Data Transport In the Internet of today, the data transport for a service is provided by the transport layer, representing layer 4 of the OSI reference model. The most well-known protocols for this layer are TCP and UDP. SCTP [6] belongs - compared to the previously mentioned protocols - to the more recent protocols. It supports connection and message oriented, reliable, unicast transport. An SCTP based end-to-end connection is denoted as an association according to this definition. In such an association, every communication endpoint can be bound on multiple interfaces providing multiple IP addresses. Various extensions for SCTP use this as base for enabling different mechanisms like partially reliable transmission, mobility support, and security or multipath [7] support. Moreover, SCTP allows the definition of new “Control Chunks”. They can be easily used to allow for an integration of new signaling elements. Because of this extensibility and the variety of supported functionality we selected SCTP as transport protocol. D. Meta Data Transport In order to allow QoS-oriented routing in the network a, method for transporting meta data, describing the TRs, towards
all network entities is needed. For this purpose, we suggest also utilizing SCTP. Other approaches like additional IPv4 options or IPv6 hop-by-hop extension headers are also possible. However, it is not clear if all routers forward this data or interpret it as a potential security risk [8] and drop the packets. In order to mediate the TRs from the sending application, we propose to use SCTP and extend its definition. An SCTP packet includes a “Common Header” as first bytes. Afterwards, data chunks of different types are allowed. The application data is transmitted as DATA chunks. Additionally, CONTROL chunks can be used within SCTP packets. They are intended to be used to exchange control information between communication endpoints. Our suggestion is to introduce an additional chunk type, denoted as NETWORK-CONTROL chunk. It represents an extension of the currently used CONTROL chunk and can be used in order to signal to all entities along a used route (not only to endpoints). In case an intermediate router supports NETWORK-CONTROL chunks and the current network policy supports the described TRs, it is enabled to react on the needs of the sending application instance by providing a more sophisticated routing than it is implemented by today’s networks. In order to allow for a fast parsing of such extended SCTP packets, we further propose an extension of the existing hierarchy of messages. The current definition [6] places control chunks after the SCTP common header and before any following chunk. We suggest placing the NETWORK-CONTROL chunk after the SCTP common header and before any following chunk, including a control chunk. As a result of this, an intermediate router receives the TRs as early as possible and can use this data to implement fast packet parsing, which can also be implemented by simple hardware modules. This also supports network entities like an open flow router to parse the important information in an easy and fast way. Figure 1 depicts the resulting proposed SCTP packet structure.
Figure 1: suggested SCTP packet structure E. Data Plane Based on the mediated TRs in each received packet, an intermediate router is enabled to react on such requirements by providing a more sophisticated routing than it is implemented by today’s networks. However, this needs additional data about available capabilities for each known route. For this purpose, the data within a router’s “Routing Information Base” (RIB) has to be extended by information about the capabilities of each route. For providing such RIB data, we propose using “Hierarchical Routing Management” (HRM) as background control plane for an enhancement of the currently applied hopby-hop routing. In this context, HRM is responsible for distributing topology data among the network routers. In addition to link state information, HRM provides QoS-related topology data, e.g., the expected additional delay and the physically possible data rate. The resulting data plane allows QoS-oriented routing in order to support an improvement of the “Quality of Experience” (QoE) of received multimedia streams. But such a data plane has also legacy support for packets without TRs.
III.
HIERARCHICAL ROUTING MANAGEMENT
In general, HRM utilizes a hierarchy in order to provide a scaling management infrastructure for the distribution of topology data among network routers. It splits management tasks into responsibility regions. However, existing hierarchical routing approaches like [9-11] use the created hierarchy for both the routing and forwarding of packets and therefore are limited by known bounds [12] regarding their resulting forwarding efficiency. Moreover, they are not focused on QoS aspects. The HRM system tries to avoid this limitation by using the hierarchy only for the management of topology data and tries to keep the data plane as simple and fast as possible. QoSoriented routing, provided by the HRM system, leads to an improved packet processing of competing multimedia streams through networks, which is not possible with today’s networks. In contrast to approaches from literature [13], HRM operates on packets instead of flows. This avoids additional out-of-band end-to-end QoS signaling and prevents state information per flow on intermediate routers. It is clear that strict reservations and state information on each intermediate router would be needed in order to provide hard QoS guarantees. In contrast to this, HRM supports an improvement of packet routing in order to enable QoS-oriented routing decisions. However, for such a routing additional data has to be stored within packets. This data has to include all TRs from sender side. As examples for non-functional requirements, this paper is focused on data rate and delay defined for an end-to-end transmission. But also functional requirements like reliable or ordered transmission are possible. They could be used to trigger function instantiation within the network depending on the capabilities of involved routers. The HRM system remains compatible to legacy routers. They as well as HRM–enabled routers implement a data plane, which executes a routing decision for each incoming packet based on the local “Routing Information Base” (RIB) [14]. A router directs packets to the next hop according to the matching entries in the local RIB. Legacy routes provide the known hop-by-hop best-effort based routing. They analyze only the content of the common IP header and use this information as input for the internal routing decision. HRM-enhanced routers can use TRs from the sender, which are stored as additional data in the NETWORK-CONTROL chunks of each packet in order to consume only those network resources which are actually needed for the application. A. Architecture Overview The HRM system implements a topology distribution system based on a tree of management instances, arranged in different hierarchy levels, as depicted at the bottom of Figure 2. Each level has its own network abstraction. The higher a management instance is located in the tree, the more abstract is its network view. This is implemented based on a topology aggregation. The resulting management system spans an overlay network on above the physical network and consists of logical control instances, denoted as “coordinators”. A physical node can provide coordinators on different hierarchy levels. In general, a coordinator of hierarchy level n periodically receives topology data from all inferior coordinators of level n – 1 and transmits them to all inferior coordinators excluding the initial sender. As a result of this, the topology distribution is a repeating two-step process, consisting of a “report” and a
“share” phase. Firstly, the topology is reported towards the top of the management hierarchy and becomes more and more abstract. Afterwards, topology data is shared downwards in the hierarchy and inferior coordinators receive “shared” topology data about foreign networks. As a result of this, the data plane at the bottom of the tree has additional routing knowledge about routes towards foreign networks. In contrast to existing hierarchical routing approaches [9-11], the HRM system uses its hierarchy only for management intelligence. The forwarding is implemented by the data plane at the lower end of the hierarchy. According to today’s hop-by-hop routing, the gateways between networks are again responsible for forwarding and routing decisionmaking. However, with HRM an enhanced routing based on additional topology information can be provided. This topology information describes the possible QoS levels for each route depending on the current transmission destination. Based on the added topology information in the RIB of each router, the HRM system allows for a flat QoS-oriented routing and forwarding according to the defined QoS requirements from the sender, e.g. for fast live video transmission which demands for an upper bound of the delay caused by the network. B. Management Hierarchy In order to support QoS-oriented routing in large-scale networks, a scaling routing management system is needed. The management workload has to be distributed among different network entities. For such a distributed system, the HRM concept applies a network clustering mechanism and uses different routing instances for internal routing management. Each of these clusters is managed by at least one routing instance denoted as “coordinator”. It is responsible for routing management within its assigned cluster. Each cluster can have one superior cluster but multiple inferior clusters. The placement of backup coordinator instances for compensating service failures, caused by hardware errors, is beyond the focus of this paper. From a global view, clustering is implemented as a tree. Clusters of the same hierarchy level in this tree represent a cluster layer. The cluster density in each layer towards the root cluster decreases due to the nature of tree structures. In general, the HRM system does not limit the amount of cluster layers. But HRM defines strict differences between the base layer on level 0 and all superior layers on level 1 and above, denoted as “level 1+”. In the following, we describe these differences for cluster creation and coordinator election. The structuring of “level 0” is based on the existing physical network structure and the ISO/OSI layer 2 broadcast domain affinity of each host. HRM clusters on level 0 consist of all hosts, which are connected to the same port of an ISO/OSI layer 3 router. The detection mechanism is based on a simple “hello” protocol, which operates on the MAC layer and enables the detection of direct neighbors according to the broadcast domain affinity. Each level 0 cluster selects its coordinator by using a distributed election algorithm. We suggest the Bully algorithm [15]. It implements the election process based on priorities per candidate. Such a priority can be derived from a candidate’s connectivity with other domains. As a result of the Bully algorithm, consensus in each cluster is established about the host acting as local coordinator.
Superior hierarchy levels (n > 0) are responsible for the routing of transmissions between clusters on level 0 and span an additional cluster hierarchy of coordinators. Each of these clusters on level n consists only of coordinators of the inferior level n-1. The structuring of “level 1+” (n > 0) is based on the logical hop distance [16, 17] between inferior coordinators. The allowed maximum distance has direct influence on the size of the resulting clusters and, therefore, also defines the hierarchy levels, which are actually needed to manage the entire network. The more level n – 1 clusters are managed by a level n coordinator, the less hierarchy levels are needed to coordinate all level 0 clusters. For the election of a coordinator of a superior cluster, the Bully algorithm is used again. Figure 2 shows a clustered example network, depicted for different abstraction views. The bottom part represents the global view and illustrates the physical network with the created logical management hierarchy above. The physical network consists of 10 hosts and links in-between. Furthermore, the network is clustered into four level 0 clusters, depicted as blue boxes around the grouped hosts. Above this part, the management hierarchy is depicted. It consists of three level 1 clusters and one root cluster on level 2. The dotted lines show the resulting management hierarchy. Moreover, the figure shows the desired network abstraction, which will be the focus of the following sections.
physical links between clusters and the logical links crossing a cluster. However, the applied aggregation has to abstract the cluster internal topology without losing the entire information, describing possible QoS levels per route. As a result of this, we aggregate a cluster’s internal topology to a fully-meshed gateway structure consisting of logical links. Furthermore, we assign each of these logical links the best value per QoS criterion, which is possible along all included physical links. The following Figure 3 illustrates this in an example and uses “(del, dr)” for describing the expected additional delay del [ms] and the physical maximum data rate dr [Mbit/s] per link. A more detailed aggregation, including unique best case values, e.g., 100 Mbit/s in Figure 3, is beyond the focus of this paper.
Figure 3: topology aggregation for cluster internal links In addition to the described QoS capabilities, each logical link between clusters and aggregated links within a cluster have a hop count of 1. Therefore, a route traversing such a cluster is described by an additional per hop cost of 1. E. Topology Data Distribution Based on the topology aggregation of section D, the HRM system internally communicates the topology data from the bottom up to the top of the hierarchy. Each coordinator reports to its superior coordinator: the aggregated cluster internal link topology, the possible QoS levels for the fully-meshed gateway structure, and the links to neighbor clusters with their possible QoS levels. Figure 4 shows the resulting process in detail. For reasons of simplicity, the corresponding QoS attributes per link are not depicted in the picture.
Figure 2: network views for different abstraction levels C. Addressing Scheme For addressing hosts, coordinators and clusters in an HRM based system; we suggest using a hierarchical addressing scheme. Figure 2 shows this scheme. For example, the cluster 1.1.2.0 is located on level 0 in the created management hierarchy. In Figure 2, this address is shortened by neglecting trailing zeros. The cluster consists of the nodes 1.1.2.1(G3) and 1.1.2.2(G4), which also represent the gateway nodes of this cluster. This scheme can be easily adapted to today’s IPv6 based addressing scheme. For each assigned prefix we suggest to split the host part of the resulting IPv6 addresses into different hierarchy levels according to the management hierarchy of HRM. D. Topology Aggregation Because of scalability concerns, we do not use detailed topology information but aggregated topology data [18] within the HRM system. Figure 2 depicts this fact based on different abstraction levels. Our topology aggregation is based on the
Figure 4: the “aggregate and report” phase As a result of the topology data reports, each coordinator has a limited overview about the global topology and available QoS levels. The granularity of this knowledge depends on the hierarchy level of the coordinator. The higher the coordinator is located in the hierarchy, the more aggregated is its topology data. Figure 2 illustrates the result of this process. Based on aggregated topology data, which was reported by inferior clusters, each coordinator instance is able to conclude
new routes by combining known routes (chaining of inferior cluster). For describing the resulting possible QoS levels for such a derived route, the new delay is the sum of the delays of all used route fragments and the new data rate is the minimum of the available data rates of the used route fragments (inferior clusters) along the resulting route, as depicted in Figure 5.
Figure 5: concluding new routes via route combination After accumulating the received topology reports and concluding new routes based on route combinations, each coordinator distributes its knowledge to inferior coordinators and gateways, as depicted in Figure 6. After all coordinators and gateways have received additional topology data from their superior coordinators, their local RIBs include additional routing entries. They describe routes towards clusters (destination addresses are also aggregated), which are no direct neighbors. The following Figure 7 shows a RIB before and after such an HRM update. The colors of the RIB entries on the right hand side indicate the origin of the corresponding RIB entry. For example, the entry “1.1.2 via G2” was received from G2, acting as level 0 coordinator of 1.1.1. This relation is also emphasized by the oval markings in Figure 6 and Figure 7.
data rate drroute along the route. These values represent the “available” values and are signaled by the HRM control plane. As a result of this, each router is able to determine a route’s best-effort based costs by the following formula: CBE = hcroute + (delroute + 1 / drroute ∙ W2) ∙ W1.
(1)
The used two weights W1 and W2 correspond to the maximum allowed hop count, e.g., 256, and the maximum expected end-to-end delay in milliseconds, e.g., 65535 ms for satellite links. For a QoS-oriented routing, the above formula can be extended to the following formula, calculating the QoS related costs for a route: CQoS = CBE + (delmatch + drmatch ∙ W2) ∙ W1.
(2)
delallowed = MAX{delE2E - delused, 0} delmatch = | delroute - delallowed | drmatch = | drroute - drE2E | In formula 2, delallowed represents the allowed delay along the remaining route towards the destination. Compared to section II D, the value is stored in the NETWORK-CONTROL chunk of each packet and is decreased by each intermediate router according to the actual link delay. Additionally, the value drE2E has to be stored in the NETWORK-CONTROL chunk of each packet. Based on these values, a router is enabled to compute the values delmatch and drmatch, which describe how good a route matches the actually desired QoS levels, and directs the packets according to these values. G. Packet Processing The resulting QoS-oriented routing process is depicted in Figure 8. In the figure, the value RMatch represents the set of possible routes towards the desired destination. The value RQoS corresponds to the set of found routes (from the local RIB), which fulfill the desired QoS values, and RBE consists of the remaining routes of RMatch, which are not included in RQoS .
Figure 6: the “combine and share” phase
Figure 8: QoS-oriented routing process Figure 7: RIB of G1 before and after the HRM update F. Routing Metric In this paper, we focus on two routing influencing TRs for HRM networks: the upper bound for the end-to-end delay delE2E and the minimum data rate drE2E, which have to be signaled by the sender according to section II D. They represent the “desired” values. In contrast to this, we use three criteria for judging the quality of existing routes when calculating their metric: the hop count hcroute, the expected additional transmission delay delroute and the possible physical
As a result of the proposed enhanced IP packet processing in each router, the routing is adapted for a desired upper bound of the end-to-end delay because the packets are directed along paths which are not reported to be in in conflict with such a delay limitation. If a sending application additionally demands for a data rate along the used path, the process of Figure 8 tries to do its best to also fulfill this requirement. For example, packets of 1280 bytes video data, demanding for 14 Mbit/s, are not routed along a link with an upper bound of 11 Mbit/s, e.g., a wireless link, as long as an alternative route, e.g., a wire link, is available, which can provide the desired data rate. In case such a QoS-oriented routing is not possible (anymore) because
all reported routes do not fulfill the desired QoS levels, a fallback to best-effort oriented routing behavior is possible. IV.
EVALUATION
In our evaluation, we focus on the analysis of the resulting routing decision process because it is executed per packet and represents the most critical part of the overall performance. The evaluation of the HRM internal control plane and its applied signaling protocol will be presented in our future work. Based on our software prototype, we are able to show that an implementation of an HRM system can provide QoSoriented routing decisions, as depicted Figure 8, with an upper computation complexity bound of O(log n) for n RIB entries, h hierarchy levels and 2 QoS criteria. For this result, we use an AVL tree [19] based storage for the RIB of each router. Based on binary search, the set RMatch in such a sorted data structure can be found with an upper bound of O(log n) for the computation. Additionally, we apply a two-dimensional sorted matrix per tree node in order to allow a fast search for a matching route according to the QoS criteria from the sender. The first dimension contains references to RIB entries, which are sorted by the data rate provided by the corresponding route. They can be used for a data rate based QoS-oriented routing. But in case a delay is also included in the TRs, the second dimension of the matrix is needed. It consists of RIB entry references, which are sorted according to the expected additional packet delay. This second dimension has a close relation to the first dimension because all its elements refer only to routes which provide at least the data rate of the corresponding entry in the first dimension. Hence, they already fulfill the desired data rate requirement. As a result of this, the search for the set RQoS can be implemented based on binary search with an upper complexity bound of 2∙O(log n) for the described two QoS criteria. V.
CONCLUSION AND FUTURE WORK
In this work, we have described how transmission requirements (TR) from a sending application and topology data, signaled by our “Hierarchical Routing Management” (HRM) system, can be used to implement QoS-oriented routing. Hence, we focused on non-functional TRs such as a desired upper bound for the end-to-end delay and a requested data rate. We applied these TRs to multipath video streaming and described how they can be integrated into the current protocol stack without losing the support for legacy routers. For this purpose, we presented details how SCTP can be used to transport the video data as well as the corresponding TRs through the network. As counterpart of these “desired” values, we proposed HRM as background control plane for signaling the “available” values among the network routers. These values describe the QoS capabilities per known route. In this context, we apply hierarchical clustering and topology aggregation in order to address scalability issues for large networks. In this paper, we explained how the HRM system is created and used. Finally, we showed that the resulting data plane provides QoSoriented routing decisions with a computation complexity of O(log n) for h management hierarchy levels, 2 QoS criteria and n RIB entries. In [2], the proof-of-concept implementation of such a data plane showed reasonable QoE improvements of transmitted video streams at receiver side.
As future work we plan to evaluate the performance of the HRM internal signaling and compare it with alternative approaches [20] for distributing QoS topology data among routers in the network. REFERENCES [1]
[2]
[3] [4]
[5]
[6] [7] [8] [9] [10]
[11] [12] [13] [14] [15] [16] [17] [18] [19] [20]
D. Wischik, C. Raiciu, A. Greenhalgh, M. Handley: “Design, implementation and evaluation of congestion control for multipath TCP”, 8th USENIX conference on Networked systems design and implementation, Boston/USA, 2011. T. Volkert, A.Mitschele-Thiel: “Hierarchical routing management for improving multimedia transmissions and QoE”, In Proceedings of IEEE International Symposium on a World of Wireless Mobile and Multimedia Networks (WoWMoM), San Francisco/USA, June 2012. F. Liers, T. Volkert, A. Mitschele-Thiel: “The Forwarding on Gates Architecture: Merging IntServ and DiffServ”, International Conference on Advances in Future Internet (AFIN), Rome/Italy, Aug. 2012. M. Becke, T. Dreibholz, H. Adhari, E. P. Rathgeb: „A Future Internet Architecture supporting Multipath Communication Networks”, 13th IEEE/IFIP Network Operations and Management Symposium (NOMS), Maui-Hawaii/USA, April 2012. T. Volkert, A. Mitschele-Thiel, M. Becke, E. P. Rathgeb: „Homer Conferencing – a Multimedia Test Bed for Various Experiments and Measurements“, 7th International Conference on Computer Sciences and Convergence Information Technology (ICCIT), Seoul/Korea, Dec. 2012. R. Stewart: “Stream Control Transmission Protocol”, IETF RFC 4960, Sept. 2007. M. Becke, T. Dreibholz, H. Adhari, E. P. Rathgeb: „ On the Fairness of Transport Protocols in a Multi-Path Environment”, IEEE International Conference on Communications (ICC) Ottawa/Canada, June 2012. R. Fonseca, G. Porter, R. H. Katz, S. Shenker, I. Stoica: „IP Options are not an option“, Technical Report, University of California at Berkeley/USA, Dec. 2005. A. Iwata, C.-C. Chiang, G. Pei, M. Gerla, T.-W. Chen: „Scalable Routing Strategies for Ad Hoc Wireless Networks“, IEEE Journal on Selected Areas in Communications, p. 1369—1379, August 1999. S. Murthy, J. J. G.-L.-Aceves: “Loop-free Internet Routing Using Hierarchical Routing Trees”, In Proceedings of IEEE International Conference on Computer Communications (INFOCOM), Kobe/Japan, 1997. G. Pei, M. Gerla, T.-W. Chen: „Fisheye State Routing in Mobile Ad Hoc Networks”, ICDCS Workshop on Wireless Networks and Mobile Computing, Taipei/Taiwan, 2000. D. Krioukov, K. Claffy: “On Compact Routing for the Internet”, ACM SIGCOMM Computer Communication Review, Volume 37, Number 3, July 2007. D. Vali, S. Paskalis, A. Kaloxylos, L. Merakos: “A Survey on Internet QoS Signaling”, IEEE Communications Surveys & Tutorials, 4th quarter 2004. D. Medhi, K. Ramasamy: Network Routing – Algorithms, Protocols, and Architectures, Elsevier Inc., ISBN 13: 978-0-12-088588-6, 2007. H. Garcia-Molina: “Elections in a Distributed Computing System”, IEEE Transactions on Computers, Vol. C-31, pages 48-59, Jan. 1982. A. Guénoche, P. Hansen, B. Jaumard: “Efficient algorithms for divisive hierarchical clustering with the diameter criterion”, Journal of Classifcation, Vol. 8(1), pages 5-30, Vol. 8, 1991. A. Das, C. Kenyon-Mathieu: “On Hierarchical Diameter-Clustering and the Supplier Problem”, Theory of Computing Systems, Vol. 45(3), pages 497-511, 2009. S. Uludag, K.-S. Lui, K. Nahrstedt, G. Brewster: “Analysis of Topology Aggregation Techniques for QoS Routing”, ACM Computing Surveys (CSUR) Surveys, Vol. 39(3), 2007. G. M. Adelson-Velskii,E. M. Landis: “An algorithm for the organization of information”, USSR Academy of Sciences, pages 263-266, 1962. L. Xiao, K.-S. Lui, J. Wang, K. Nahrstedt: „QoS Extension to BGP“, In Proceedings of 10th International Conference on Network Protocols, pages 100-109, Paris/France, Nov. 2002.
