WO2015197484A1

WO2015197484A1 - Method and device for routing ip multicast packets in a network

Info

Publication number: WO2015197484A1
Application number: PCT/EP2015/063804
Authority: WO
Inventors: Stein HESELMANS
Original assignee: Thomson Licensing
Priority date: 2014-06-23
Filing date: 2015-06-19
Publication date: 2015-12-30

Abstract

A method for routing IP multicast packets in an access gateway and a respective access gateway are described. Multicast groups are kept in a table of the access gateway (30) and IP multicast packets are forwarded to a local area network port of the access gateway, which is linked with a device having joined one of the multicast groups (34), wherein join requests for link local multicast groups from the table are dropped and only the multicast groups are kept in the table (36).

Description

METHOD AND DEVICE FOR ROUTING IP MULTICAST PACKETS IN A

NETWORK

TECHNICAL FIELD

The present disclosure relates to the field of access gateways, in particular to residential gateways, being adapted to operate via a broadband connection with a service provider network.

BACKGROUND

Access gateways are widely used to connect devices in a local area network (LAN) to the Internet or to any other wide area network (WAN) . Access gateways use in particular digital subscriber line (DSL) technology that enables a high data rate transmission over copper lines or optical transmission lines for Internet services. Access gateways including wireless technology have a key role in today' s home and professional environments.

Multicast is a kind of group communication where

information is addressed to a group of destination clients, e.g. network computers, simultaneously. Multicast on

Internet Protocol version 4 (IPv4) works by using in particular the Internet Group Management Protocol (IGMP). On the Internet Protocol version 6 (Ipv6), the Multicast Listener Discovery (MLD) protocol is used. The following description explains the situation for IPv4, but it is similar for IPv6. A multicast server sends data on its interface (s) to a specific multicast group address. Clients that are interested in this data, can request the server and nodes (routers/modems/etc) to forward these data to its interface. In order to do so, the client sends an

IGMP join message to the multicast group address. All nodes (routers/modems) forward this join message and seek to receive the multicast data and forward it to the client.

An access gateway keeps a list of multicast groups that were joined by its attached clients. If the access gateway receives data destined for a multicast group, it looks in this table and forwards the multicast data only to the client that requested (joined) this multicast group. More details about multicast is provided by the recommendations RFC 1112 for IGMP version 1 , RFC 2236 for IGMP version 2 and RFC 337 6 for IGMP version 3 .

As described in RFC 1112 for the IGMP version 1 , IP

multicasting is the transmission of an IP datagram, for example a User Datagram Protocol (UDP) datagram, to a "host group", a set of zero or more hosts identified by a single IP destination address. A multicast datagram is delivered to all members of its destination host. The membership of a host 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. A host may be a member of more than one group at a time. A host need not be a member of a group to send datagrams to it. Internetwork forwarding of IP multicast datagrams is handled by multicast routers, which may be co-resident with, or separate from, Internet gateways. A host

transmits an IP multicast datagram as a local network multicast which reaches all immediately-neighboring members of the destination host group. If the datagram has an IP time-to-live (TTL) greater than 1 , the multicast router (s) attached to the local network takes responsibility for forwarding it towards all other networks that have members of the destination group. On those other member networks that are reachable within the IP time-to-live, an attached multicast router completes delivery by transmitting the datagram as a local multicast.

An exception to this is the link local multicast group, RFC 4541 section 2.1.2, which is a subset of the multicast address range in IPv4. Multicast data sent to this group need to be flooded to all interfaces by multicast routers, bridges and switches independent of the client requesting the data. So even if the client did not join the link local multicast group, the data need to be forwarded to this client .

Current implementation in present gateways implement flooding of these link local multicast data on bridge level. This solution is however incomplete: when the access gateway receives a join of a link local multicast group, it programs its switch to forward that group to only the client that joined the group. On bridge level the access gateway was still flooding the data, but not on switch level.

US 2013/0182707 describes a method to manage a global forwarding table in a distributed switch. The distributed switch may include a plurality of switch forwarding units. The method may start a timer for an entry in the global forwarding table, and the entry may include a multicast destination address and corresponding multicast membership information . SUMMARY

The present principles relate to an approach for routing IP multicast packets in an access gateway. According to an aspect of the present principles, a method for routing IP multicast packets in an access gateway comprises :

- keeping multicast groups in a table of the access

gateway,

- forwarding the IP multicast packets to a local area network port of the access gateway, which is linked with a device having joined one of the multicast groups, and

- dropping join requests for link local multicast groups from the table, wherein the multicast groups are kept in the table.

In a preferred embodiment, an Internet Group Management Protocol (IGMP) snooper keeps a list of the multicast groups and of devices having joined these groups in the table in accordance with an Internet Protocol version 4 IPv4) . And, or alternatively, an MLD snooper keeps a list of multicast groups and of devices having joined these groups in the table in accordance with an Internet Protocol version 6 (IPv6) .

In another aspect of the invention, IP addresses 224.0.0.x are dropped from the table and IP addresses 224.0.1.0 to 239.255.255.255 are kept.

In a another aspect of the invention, multicast groups are filtered on an IP address level in the access gateway.

In another aspect of the invention, the IP multicast packets are mapped to MAC layer multicast packets in the access gateway.

Accordingly, a computer readable non-transitory storage medium includes program code instructions being executable by a processor, to perform a method. Accordingly, a computer program comprises program code instructions being executable by a processor, to perform the method. In a further aspect of the invention, an access gateway for routing IP multicast packets of a multicast group comprises a processor being adapted

- to keep the local multicast group in a table of the access gateway,

- to forward the IP multicast packets to a local area network (LAN) port of the access gateway according to a join request of a device being linked with the LAN port, and

- to drop join requests for link local multicast groups from the table, and keep other local multicast groups in the table.

In another aspect of the invention, the access gateway includes a software bridge with an Internet Group

Management Protocol (IGMP) snooper, to keep a list of multicast groups and of devices having joined these groups in the table in accordance with IPv4. And, or

alternatively, an MLD snooper of the software bridge keeps a list of multicast groups and of devices having joined these groups in the table in accordance with IPv6.

The access gateway is in particular a residential gateway of a home network. BRIEF DESCRIPTION OF THE DRAWINGS

Exemplary embodiments of the present disclosure are

explained in more detail below by way of example with reference to schematic drawings, which show: Fig. 1 an arrangement for routing IP multicast packets in an access gateway,

Fig. 2 an arrangement illustrating normal multicast

forwarding in an access gateway,

Fig. 3 an arrangement illustrating link local multicast group forwarding in an access gateway, and

Fig. 4 a chart illustrating a method for routing IP

multicast packets in an access gateway.

It should be understood that the drawings are for purposes of illustrating the concepts of the disclosure and is not necessarily the only possible configuration for

illustrating the present disclosure.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

In the following description, a method and an access gateway for routing IP multicast packets are described. For purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments. It will be evident, however, to one skilled in the art that the present disclosure may be practiced without these specific details. It should be understood that the elements shown in the figures may be implemented in various forms of hardware, software or combinations thereof. Preferably, these

elements are implemented in a combination of hardware and software on one or more appropriately programmed general- purpose devices, which may include a processor, memory and input/output interfaces. Herein, the phrase "coupled" is defined to mean directly connected to or indirectly

connected with through one or more intermediate components. Such intermediate components may include both hardware and software based components. Devices connected to LAN ports LAI - LA4 of an access gateway GW, figure 1, send joins to the access gateway in order to retrieve data for certain multicast groups. A software bridge 1 of the access gateway captures these joins and a submodule 4 called IGMP snooper included in the software bridge 1 keeps a list of multicast groups and devices (not shown) being connected to the LAN ports LAI - LA4, that joined these groups, in a table. The IGMP snooper 4 programs the hardware switch 2 to forward multicast data for a certain multicast group to the respective LAN ports LAI - LA4.

The software bridge 1 keeps the table based on IP multicast groups, which can have the IP addresses 224.0.0.0 till 239.0.0.0. When it programs the hardware switch 2, each IP multicast group is translated into a MAC address having a format 01-00-5E-xx-xx-xx . Through the mapping from IP address to MAC address, a certain number of bits in the address is lost. This means that a MAC address cannot be calculated back to a unique IP address. It also means that when the switch is programmed, by using a MAC address, not only the given IP group is forwarded to that LAN port, but also all other IP groups that map to this MAC address. A multicast address includes a multicast group. Nodes join a multicast group. When the software bridge 1 receives multicast packet data for a certain multicast group, for example multicast data is coming from a WAN side 5 via a DSL broadband connection, and is routed through an IP router 3 of the gateway, or the multicast data is coming from another local bridge port, the IGMP snooper 4 looks into the snooper table for clients that joined the group. If no client has joined the group, the bridge will drop the packets, otherwise, it will forward the data to the devices that are in the list, via the LAN ports LAI - LA4. Since the hardware switch 2 is programmed with the same information, only the relevant LAN ports receive the data for the multicast group.

The access gateway includes further_a controller, for example a microprocessor, and a memory, in which an

operating system is stored for the operation of the access gateway. The access gateway may further include a wireless node for a wireless communication and a circuit for a broadband connection, e.g. an xDSL connection. An access gateway of this kind is for example a residential gateway, as used in home networks .

Figure 2 illustrates an embodiment , in which multicast packets 16 are sent from a video server 10 via Internet, e.g. DSL, to a residential gateway 11 of a home network, to which a set-top box 12, a laptop 13 and a PC 14 are linked. Because only the set-top box 12 has joined to this

multicast group, join request 15, only the set-top box 12 receives the multicast packets 16 via the respective LAN port, but not the other devices 13 and 14.

Exception to this are link local multicast groups

224.0.0.x/24, x = 0 - 255, as described in RFC 4541. These multicast groups have to be forwarded to all bridge ports at all times. The software bridge 1 has an implementation to flood data for a link local multicast group to all bridge ports, e.g. ports LAI - LA4. However, upon receiving a join for one of these groups, the IGMP snooper 4 still programs the hardware switch 2 to forward data for that group to only the specific LAN port that received the join. This is a problem, as it violates the standard in RFC 4541 section 2.1.2.

As depicted in figure 3, multicast packets 20 according to a link local multicast group address are forwarded via the residential gateway 11 to all devices 12-14 being connected to the respective LAN ports of the gateway 11, independent of any join request of one of the devices 12-14. But when the device 12 sends a join request 21 for that link local multicast group to the residential gateway 11, this join request: to send multicast packets for that link local multicast group to device 12, will be stored in the table of the IGMP snooper 4. Subsequent link local multicast packets sent from the video server 10 to that link local multicast group address would be sent therefore after the join request 21 only to the device 12.

To solve the problem, the join requests from the devices 12 - 14 for link local multicast groups are dropped, e.g. not stored or registered, from the table of the IGMP snooper 4, and only the other multicast groups are kept in the table. In detail, the IGMP snooper drops all join requests for IP addresses 224.0.0.x, x being in a range of 0 to 255, when receiving a join for one of these IP addresses 224.0.0.x, but stores and keeps all join requests for the IP addresses 224.0.1.0 to 239.255.255.255 in the table, when receiving a respective join message from one of its clients, e.g.

devices 12 - 14.

By rejecting the join requests for a link local multicast group, the access gateway will not program therefore its hardware switch 2 to forward data for the link local multicast group only to the device that joined, but to flood data for this link local multicast group to all LAN interfaces, like its software bridge 1 does.

A method of routing IP multicast packets in an access gateway according to the embodiments as shown in figures 2 and 3 is illustrated in figure 4. Multicast groups are kept in a table of the access gateway, e.g. a forwarding table or a membership table, 30. IP multicast packets received in the access gateway from e.g. a WAN, 32, are forwarded to a LAN port of the access gateway, which is linked with a device having joined one of the multicast groups, 34. Any join requests for a link local multicast group is dropped from registering within the table, only join requests for the multicast groups are registered and kept in the table, 36.

The present principles are valid for both IPv4, IGMP, and IPv6, MLD (Multicast Listener Discovery) , as both

implementations are very similar in multicast data. The IP groups and the mapping to MAC addresses is different for IPv6, but only in details. The protocol and the terminology is similar: there is also a MLD snooper sub-module in the software bridge 1 for IPv6.

Also other embodiments of the present disclosure may be utilized by one skilled in the art without departing from the scope of the present disclosure. The table is for example a forwarding table, and the entries in the table include a multicast destination address and corresponding multicast membership information. The present disclosure resides therefore in the claims herein after appended.

Claims

1. Method for routing IP multicast packets in an access gateway (11), comprising

keeping multicast groups in a table of the access gateway (30) ,

forwarding the IP multicast packets to a local area network (LAN) port of the access gateway, which is linked with a device having joined one of the multicast groups (34), and

dropping join requests for link local multicast groups from the table, wherein the multicast groups are kept in the table (36) .

2. The method of claim 1, wherein the access gateway receives the IP multicast packets (32) from a wide area network (WAN) .

3. The method of claim 1 or 2, wherein an Internet Group Management Protocol (IGMP) snooper keeps a list of the multicast groups and of devices having joined these groups in the table in accordance with an Internet Protocol version 4 IPv4) and/or wherein an MLD snooper keeps a list of multicast groups and of devices having joined these groups in the table in accordance with an Internet Protocol version 6 (IPv6) .

4. The method of claim 1, 2 or 3, wherein IP addresses 224.0.0.x are dropped from the table and IP addresses

224.0.1.0 to 239.255.255.255 are kept.

5. The method of one of the preceding claims, comprising: of filtering for multicast groups on an IP address level in the access gateway.

6. The method of one of the preceding claims, wherein the IP multicast packets are translated to MAC layer multicast packets in the access gateway.

7. The method of one of the preceding claims, wherein the access gateway is a residential gateway of a home network.

8. Computer readable non-transitory storage medium

including program code instructions executable by a

processor for performing a method according to one of the preceding claims.

9. Computer program, comprising program code instructions executable by a processor for performing a method according one of the preceding claims 1-7.

10. Device including an IGMP snooper for performing a method according to one of the claims 1 - 7.

11. Access gateway (11) for routing IP multicast packets of a multicast group, comprising a processor being adapted

to keep the local multicast group in a table of the access gateway,

to forward the IP multicast packets to a local area network (LAN) port of the access gateway according to a join request of a device being linked with the LAN port, and

to drop join requests for link local multicast groups from the table, and keep other local multicast groups in the table.

12. The access gateway of claim 11, wherein the IP

multicast packets are provided by a service provider of the WAN network.

13. The access gateway of claim 11 or 12, wherein the access gateway includes a software bridge (1) with an

Internet Group Management Protocol (IGMP) snooper (4) being adapted to keep a list of multicast groups and of devices having joined these groups in the table in accordance with IPv4, and/or wherein an MLD snooper keeps a list of

multicast groups and of devices having joined these groups in the table in accordance with IPv6.

14. The access gateway of claim 13, wherein the access gateway is adapted to filter for multicast groups on IP address level.

15. The method of one of the preceding claims 11-14, wherein the access gateway includes a hardware switch (2) to translate the IP multicast packets to MAC layer

multicast packets in the access gateway.

16. The access gateway of one of the preceding claims 11- 15, wherein the IGMP snooper is adapted to drop IP

addresses 224.0.0.x from the table and to keep IP addresses 224.0.1.0 to 239.255.255.255 in the table.

17. The access gateway of one of the preceding claims 11- 16, wherein the access gateway is a residential gateway of a home network.