WO2002065701A1

WO2002065701A1 - Method for multicast routing protocol interoperability

Info

Publication number: WO2002065701A1
Application number: PCT/EP2002/001493
Authority: WO
Inventors: Heino Hameleers; Frank Hundscheidt
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2001-02-13
Filing date: 2002-02-13
Publication date: 2002-08-22
Also published as: WO2002065701A8; AU2002253015A1

Abstract

The invention enables the use of network resources for providing a service to a plurality of users or clients. Therefore a system comprising the network resources is divided into sub-networks (AN1, AN2) served by a node (SI1, SI2). The nodes can receive a service according to a first multicast routing protocol and can provide the service by using a second different multicast routing protocol. By this, the invention enables to adapt the provision of the service according to the distribution of receivers for each part of the network.

Description

METHOD FOR MULTICAST ROUTING PROTOCOL INTEROPERABILITY

Technical field

The invention relates to a method for configuring a system for providing a service. It further relates to a method for providing a service, a system for providing a service, and a node of said system.

Related prior art

Multicast, for example according to an IP (internet protocol), efficiently supports real- time one-to-many and many-to-many transmission by enabling sources to send a single copy of a message to multiple recipients, who explicitly want to receive the information. The recipients can for example be indirectly identified by a single IP class-D multicast address.

Multicast is a receiver-based concept; receivers join a particular multicast session group by informing the multicast router on their network or sub-network, for example by using an IGMP (Internet Group Management Protocol) and traffic is delivered to all members of that group by the network infrastructure. With IP multicast receivers do not need to know who or where the senders are to receive traffic from them. Senders never need to know who the receivers are. Neither senders nor receivers need to care about the network topology as the network optimizes delivery.

The membership of a multicast session group is dynamic; that is, hosts may join and leave groups at any time. There is no restriction on the location or number of members in a host group. The RTCP (Real-time Transport Control Protocol) provides approximate membership information through periodic multicast of information of the recipient and the reception quality.

From the network perspective, multicast dramatically reduces overall bandwidth consumption, since the data is replicated in the network at appropriate points rather than in the end-systems. Scalability is achieved by distributing group membership information local to the routers near the relevant multicast group members.

The development of IP multicast has been supported by the MB ONE (Multicast Backbone), which used to be a virtual overlay network on top of the Internet to support routing of IP multicast packets. It is rapidly becoming integrated into the Internet itself and is still used by IETF (Internet Engineering Task Force) members for multicasting live audio and video via the Internet.

Several algorithms have been proposed for building multicast distribution trees, such as spanning trees, shared-trees, source-based trees, core-based trees, etc. Descriptions of the corresponding algorithms are known from IP Telephony; Packet-based multimedia communications systems, by Olivier Hersent, David Gurle and Jean-Pierre Petit, published December 1999 by Addison Wesley. IP multicast routing protocols are based on the algorithms mentioned above, and generally follow one of two basic approaches, depending on the expected or known distribution of multicast group members across the network, dense mode and sparse mode multicast routing protocols. High-level descriptions of these dense-mode and sparse-mode multicast routing protocols can be found in the above mentioned reference.

Dense-mode protocols are optimized for networks where most hosts of a network are members of active multicast groups. These are not necessarily small networks. Dense- mode routing protocols include DVMRP (Distance Vector Multicast Routing Protocol), MOSPF (Multicast Open Shortest Path First), PBVI-DM (Protocol-Independent Multicast - Dense Mode). However, dense mode protocols rely on periodic flooding, which is very inefficient for low-density populations.

Sparse-mode protocols are optimised for large networks where only a small portion of all connected hosts are members of each group. Since flooding would unnecessarily waste network bandwidth, these routing protocols rely on more selective techniques. Sparse- mode routing protocols include CBT (Core Based Trees), PIM-SM (Protocol- Independent Multicast - Sparse Mode). But sparse mode routing protocols are not applicable for streaming audio and video.

Today's multicast schemes support large multicast groups, which leads to problems when a network supports a very large number of small distinct groups of users.

A recent initiative within the IETF - SGM (Small Group Multicast) complements the existing multicast schemes in that it can support a very large number of small multicast groups.

The basic idea of SGM is to use a list of destination addresses in a new SGM header - additional payload - and eliminate the use of the multicast routing protocols and the storage of multicast routing information in routers.

Routers along the way partition the destinations based on the destination's next hop and forward appropriate SGM packets to the next hops.

However, even this solution proposed by the initiative does not lead to an optimized utilization of resources.

By this it is an object of the invention, to provide a system that enables a more efficient utilization of resources in case of inhomogeneous spreading of users of a service.

Summary of the invention

This is achieved by the method of claim 1 , the system of claim 10 and the node of claim 13.

The invention uses a combination of dense mode and sparse mode multicast routing protocols. Therefore a system that comprises a network that operates according to a protocol that supports multicast routing is configured for providing a service according to at least one multicast protocol. The network may operate according to an internet protocol. The system comprises a plurality of nodes and users. It is configured by defining a root node for providing the service, determining at least one further node for providing the service, defining a hierarchical structure of nodes, wherein each of the nodes provides a subnetwork with the service, determining for each of the nodes whether the provision of the service to the respective sub-network is to be performed according to a dense mode multicast routing protocol or according to a sparse mode multicast routing protocol.

A node in that system is for example one of a server, a router or a proxy. Such a node can act towards another node in upward direction, that is a node that is closer to the root node, as a client. Towards a sub-network the node provides with the service, it may act as a server. Furthermore, the node may filter messages sent towards the root and received from the sub-network in order to appear as a single client.

When a node is going to provide a service it performs the following steps, it receives a request for acting as a node for providing a service, determines or receives a position in the hierarchical structure of nodes, and determines whether a sub-network served by the node is to be served according a dense mode multicasting protocol or according to a sparse mode multicasting protocol.

In a preferred embodiment of the invention the node terminates data and messages received according to a dense mode protocol, transforms them into data and messages according to a sparse mode protocol and vice versa. The node terminates the protocols for example if it is served in a dense mode by another node and serves a sub-network in a sparse mode multicast routing protocol or vice versa.

The invented system for providing a service in a system according to at least one multicast protocol, that comprises a network adapted to operate according to an internet protocol comprises a plurality of nodes and users, a root node for providing the service, at least one further node for providing the service, a hierarchical structure among the nodes, wherein each of the nodes is to provide a sub-network with the service, at least one of the nodes is to provide a sub-network according to a dense mode multicast protocol, and at least one of the nodes is to provide a sub-network according to a sparse mode multicast protocol.

h a preferred embodiment the system, a node is adapted to acting towards a further node as a client and towards a sub-network as a server. Furthermore, the node is adapted to terminate data and messages received according to a dense mode protocol, to transform them into data and messages according to a sparse mode protocol and vice versa.

Brief description of the figures

Figure 1 depicts a system according to the invention, Figure 2 depicts a multicast inter-working according to the invention, Figure 3 depicts a sequence flow of a method according to the invention.

Detailed description of the invention

In the following, the invention is described by means of an embodiment and figures.

According to the invented method, a service is provided by more than one service instance. An embodiment of the invented method is depicted as a sequence flow in figure 3. A service instance is a node, for example a server, a proxy or a rooter. In a first step 101 a root node is defined. The root node is the source of the service, for example a streaming service, a news channel or alike. The root node provides further nodes with data packages including service related information. In a next step 102, further nodes are selected. After determining the further nodes, a hierarchical structure is defined in the system 103. According to this structure, each of the nodes, the root node and the further nodes, serves a domain of itself. This domain is called the sub-network of the node.

Depending on the density of clients, for each of the domains it is determined in a next step 104, whether the domain is provided with the service in a dense mode or a sparse mode. For example to apply the sparse-mode approach between the service instances and the dense-mode approach in domains with high-density population. An additional benefit of distribution is the reduced number of routers that require state information as defined by the dense-mode approach, since no router state information is required in the network between the service instances. After service distribution protocols like Small Group Multicast could provide valuable alternatives for local service provisioning.

In a preferred embodiment of the invention, after a service is distributed, or after a proxy has been determined for inter-working and adaptations, an algorithm is used to determine whether and where sparse and/or dense mode multicast routing is to be applied.

Furthermore, in case of a combination of a sparse and dense mode routing mechanism, the service instance or the proxy will take care of the corresponding inter-working.

Figure 1 depicts a system according to the invention. It shows the system after a service distribution or the allocation of proxies. The system comprises an IP (Internet Protocol) backbone network IP1, two access networks AN1, AN2 a root node RN1 and two further nodes SI1, SI2. By this, the system is subdivided into the areas as depicted in the figure. The root node serves the further nodes SI1, SI2 via the backbone network IP1. The first further node SI1 serves the first access network AN1 with a plurality of users. The second further node SI2 serves the second access network AN2. By this, the provision of the services to the network is divided into the provision to the further nodes SI1, SI2 by the root node RN1, and the provision to clients via the access networks AN1, AN2, by the further nodes SI1, SI2. The provision of the service to the further nodes is performed according to a sparse mode multicast routing protocol on the backbone network. In the second access network AN2, the service is provided to the users/clients according to a sparse mode multicast protocol as well. In the first access network AN1, the provision is performed according to a dense mode multicast routing protocol. As the first node receives the service according to a different protocol than it provides it to the access network, it has to perform as described in further detail by means of figure 2. One way to determine whether a dense and/or a sparse mode multicast routing mechanism should be applied, is to take the following steps:

1. Distribute the service or allocate a proxy.

2. From the service distribution, i.e. the number of service instances, or the number of proxies allocated, the root, i.e. the service provider, knows whether it faces a dense or a sparse client population. The clients are the service instances and/or proxies in this case and in the figure above the DP backbone contains a sparse client population. 3. Each service instance or proxy must determine whether the corresponding, subnetwork contains a dense or sparse client population. This can be based on configuration data, e.g. always the same client population for a specific multicast group, or by counting the actual number of clients that registered for a specific session. The counting is described in detail below. 4. Use the corresponding dense or sparse mode multicast protocol and provide the inter- working when necessary. An inter-working is necessary if a node is served by a first mode and serves by another mode.

For a node this means that it firstly receives a request to take part in the provision of a service. In a further step it receives or determines information about its place in a hierarchical structure of the network. After knowing its position, the node distinguishes whether the sub-network its provides with the service is to be served according to a dense-mode or a sparse mode multicast routing protocol.

The service instances and the proxies are clients from a server point of view, but they are also service providers (sources/roots) from a client point of view. Therefore, towards the server a service instance and proxy must pretend to be a client. This basically means that those are not part of the multicast delivery tree, but are leafs from a server point of view and roots from a client point of view. This is explained in more detail by means of figure 2, which depicts a multicast inter-working according to the invention. A node N21 is served by a server S21 and serves a client C21. The node N21 acts and appears towards the server S21 as a client. It acts and appears towards the client C21 as a server or a root.

Multicast inter-working means that two different multicast routing protocols must be used and the inter-working between these must be taken care off. Furthermore, messages towards the root (i.e. the server) must be filtered to be able to pretend to be just one client.

For the determination of the appropriate multicast routing protocol the number of clients per sub-network is counted if the number is not already available via some other means, e.g. administration.

After one single or several clients have registered to a multicast router, that router informs the next multicast router on the way to the root multicast router about the number of hosts connected. In order to have the mechanism to take a corresponding metric into account, not only the number of hosts, but also the metrics will be sent. Any of the existing multicasting routing messages may be extended by this information. The additional information will be sent by the corresponding multicast routers. It should be noted that non-multicast routers forward the information transparently. The collection and processing of the information leads for example to the following table:

From / To Router Hosts Distance

R3 / R1 2 1 R6 / R1 2 1 R8 / R7 1 1 R7 / R1 1 2

1 1 From all the information received and taking into account the corresponding distances between the multicast routers themselves, Rl will e.g. setup the following table:

Via Hosts Distance directly (via IGMP) 1 1

R2 2 3

R4 2 4

R7 1 2

1 3

Total number of hosts: 7

Each multicast router now knows the total number of recipients in its corresponding sub- branch, including the related distances. This implies that the root (i.e. Rl in this topology) knows the total number of recipients.

Based on this information, it is decided whether to use a dense-mode multicast routing protocol or a sparse-mode multicast routing protocol in the respective domain or sub- network.

Each node then provides the service according to the selected mode to its domain or subnetwork.

Claims

1. Method for configuring a system SIl for providing a service according to at least one multicast protocol, wherein the system comprises a network IPl that operates according to a protocol that supports multicast routing and the system comprises a plurality of nodes (SIl, SI2) and users, and wherein the method comprises the steps of:

- defining (101) a root node (RNl) for providing the service,

- determining (102) at least one further node (SIl , SI2) for providing the service,

- defining (103) a hierarchical structure of nodes, wherein each of the nodes provides a sub-network (IPl, AN1, AN2) with the service,

- determining (104) for each of the nodes (RNl , SIl , SI2) whether the provision of the service to the respective sub-network is to be performed according to a dense mode multicast routing protocol or according to a sparse mode multicast routing protocol.

2. Method according to claim 1, wherein the network (IPl) operates according to an internet protocol.

3. Method according to claim 1 , wherein a node (RNl , SIl , SI2) is one of a server, a router or a proxy.

4. Method according to claim 1 or 2, wherein a node (SIl, SI2) acts towards another node (RNl ) that is closer to the root node (RNl) as a client.

5. Method according to claim 3, wherein a node (SIl, N21) filters messages sent towards the root and received from the sub-network in order to appear as a single client.

6. Method according to any of the preceding claims, wherein a node (SIl, SI2, N21) acts as a server towards the sub-network (AN1, AN2, C21).

7. Method for providing a service for a node (RNl, SIl, SI2, N21) in a system (SIl) according to any of the preceding claims, wherein the method comprises the steps of:

- receiving a request for acting as a node for providing a service,

- determining or receiving a position in the hierarchical structure of nodes, and

- determining whether a sub-network served by the node is to be served ■ according a dense mode multicasting protocol or according to a sparse mode multicasting protocol.

8. Method according to claim 6, wherein the node (N21, SIl, SI2) acts as a client towards a node (S21 , RNl) that is closer to the root and as a server towards the sub-network (AN1 , AN2, C21).

9. Method according to claim 6 or 7, wherein the node (SIl) terminates data and messages received according to a dense mode protocol, transforms them into data and messages according to a sparse mode protocol and vice versa.

10. System (SIl) for providing a service in a system according to at least one multicast protocol, wherein the system comprises a network (IPl) adapted to operate according to an internet protocol and that comprises a plurality of nodes (RNl, SIl, SI2) and users, characterized by - a root node (RNl) for providing the service,

- at least one further node (SIl , SI2) for providing the service,

- a hierarchical structure among the nodes, wherein each of the nodes is to provide a sub-network (AN1, AN2) with the service, at least one of the nodes (SIl) is to provide a sub-network (AN1) according to a dense mode multicast protocol, and - at least one of the nodes (SI2) is to provide a sub-network (AN2) according to a sparse mode multicast protocol.

11. System according to claim 9, wherein anode (SIl, SI2, N21) is adapted to acting towards a further node as a client and towards a sub-network as a server.

12. System according to claim 9 or 10, wherein a node (SIl) is adapted to terminate data and messages received according to a dense mode protocol, to transform them into data and messages according to a sparse mode protocol and vice versa.

13. Node (N21, SIl, SI2) for providing services in a system (SIl) according to any of the claims 9, 10 or 11, wherein the node is adapted to perform a method according to any of the claims 6, 7, or 8.