AppNote_MulticastVideothomson

7/28/2019 AppNote_MulticastVideothomson

1/122

Thomson Gateways and Multicast Video

Date: July 2007

Version: v3.0

Abstract: This application note provides technical information about multicast video and how this relatesto the various devices in the Thomson Gateway family. In addition to a brief background onmulticast video, tested and proven use cases show how to integrate the Thomson Gateway in a

multicast network. For each use case, a scenario (i.e. the description of what happens) and aconfiguration (i.e. the description of the used CLI commands) are presented.

Applicability: This application note is relevant to all Thomson Gateway devices that support port-to-PVCmapping, Flexiport, IGMP proxying and IGMP snooping:

Port-to-PVC mapping is supported since R5.3.0

Flexiport with a single PVC is supported since R5.3.2

Flexiport with multiple PVCs is supported since R5.4

IGMP proxying is supported since R5.4

IGMP snooping is supported since R6.1.9

The use cases presented have been tested on:

The THOMSON ST780 (Wireless) R6.2.G

Updates: THOMSON continuously develops new solutions, but is also committed to improving itsexisting products.

For more information on THOMSON's latest technological innovations, documents andsoftware releases, visit us at http://www.thomson-broadband.com
http://www.thomson-broadband.com/http://www.thomson-broadband.com/http://www.thomson-broadband.com/


2/122

E-NIT-CTC-20050927-0004 v3.0 2

Contents

1 Introduction to Multicast Video.................................................4

2 Internet Group Management Protocol (IGMP) ......................... 7

2.1 Setting Up a Multicast Group ......................................................................... 8

2.2 IGMP Versions............................................................................................... 12

2.3 IGMP Signalling ............................................................................................ 14

2.4 IGMP Proxying .............................................................................................. 18

2.5 IGMP Snooping ............................................................................................. 20

3 The Thomson Gateway and Flexiport ..................................... 233.1 Life before Flexiport...................................................................................... 24

3.2 Advantages of Flexiport................................................................................ 26

3.3 The Flexiport Concept................................................................................... 27

4 Wi-Fi MultiMedia (WMM)..........................................................28

4.1 WMM in the Thomson Gateway .................................................................... 28

5 Multiple Virtual Channels .........................................................30

5.1 Bridged Internet and Bridged Multicast........................................................ 31

5.2 Routed Internet and Bridged Multicast, Single STB...................................... 35

5.3 Routed Internet and Bridged Multicast, Multiple STBs................................. 41

5.4 Routed Internet and Routed Multicast, Single STB....................................... 47

5.5 Routed Internet and Routed Multicast, Multiple STBs.................................. 54

5.6 Routed Internet and Routed Multicast, IGMP-based ..................................... 62

6 Single Virtual Channel ..............................................................67

6.1 Routed Internet and Bridged Multicast, Single STB...................................... 68

6.2 Routed Internet and Bridged Multicast, Multiple STBs................................. 73

6.3 Routed Internet and Routed Multicast, Single STB....................................... 79

6.4 Routed Internet and Routed Multicast, Multiple STBs.................................. 85


3/122

E-NIT-CTC-20050927-0004 v3.0

Contents

3

6.5 Routed Internet and Routed Multicast, IGMP-based ..................................... 92

7 Ethernet WAN Port for Multicast Video..................................96

7.1 Ethernet WAN Port, Routed Internet and Routed Multicast, Flexiport ......... 97

7.2 Ethernet WAN Port, Routed Internet and Routed Multicast, IGMP-based .. 104

7.3 Ethernet WAN Port on the Bridge, Routed Internet and Routed Multicast, IGMP

and VLANs .................................................................................................. 109

7.4 AutoWAN, Routed Internet and Bridged Multicast ..................................... 115


4/122

E-NIT-CTC-20050927-0004 v3.0

Chapter 1Introduction to Multicast Video

4

1 Introduction to Multicast Video

IntroductionFrom an end users point of view, multicast video over IPis similar to broadcast TV:

> The video server sends a number of continuous digitized and packetized video streams into the network.Each video stream has its own multicast group address. The various multicast group addresses can becompared to the channel frequencies for broadcast TV. A video display application can become a

member of a multicast group, and thus receives a particular video stream. This is just like tuning to thefrequency of the channel you would like to watch for broadcast TV.

Differences between multicast video over IP and broadcast TV exist in network and traffic features:

> While broadcast TV channels are broadcast at all times to all subscribers, a multicast video stream is onlyforwarded on the links that lead to the multicast group members.

> While broadcast TV sets tune in locally to a particular channel, a multicast client announces its

membership to a particular multicast group by means of IGMP signalling.Differences between multicast video and unicast video are:

> While a unicast video stream is dedicated to a single client, a multicast video stream is shared by manyclients. A multicast stream will only be put once on a logical link that leads to the multicast group

members. As a result, a multicast video stream will only use a fraction of the bandwidth used by a largenumber of duplicated unicast video streams.

> While unicast video streams can use both TCP and UDP as transport protocol, multicast streams can onlyuse UDP.

> While a unicast video stream starts on request of the video client, multicast video streams are always on.The multicast video clients join the group at a certain moment in time.

Multicast group

A multicast group consists of a number of devices that share a multicast group address for communication.The information is sent no more than once on each link.

The devices are:

> Server(s): A multicast server sends multicast streams, each with a pre-defined multicast groupaddress.

> Routers: A multicast router receives the multicast streams. The router forwards each multicast stream toits multicast peers that are member of the corresponding multicast group. This requires that the multicastpeers have announced to what multicast groups they belong by means of IGMP.

> Clients: Multicast clients receive multicast streams to which they subscribed themselves and decode thedata to display them to the end users.


5/122

E-NIT-CTC-20050927-0004 v3.0


5

IP multicast address

An IP multicast address specifies an arbitrary group of IP hosts. These IP hosts have joined the group and

want to receive traffic sent to this group.

IP multicast addresses are Class D IP addresses. These addresses range from 224.0.0.0 through239.255.255.255. The high-order four bits are always 1110, followed by the 28 bit multicast group ID.

The IANA (Internet Assigned Numbers Authority) has reserved the addresses in the range from 224.0.0.0

through 224.0.0.255 to be used on a subnet:

> 224.0.0.0: this address is guaranteed not to be assigned to any group

> 224.0.0.1: all hosts on this subnet

> 224.0.0.2: all routers on this subnet

> 224.0.0.22: IGMPv3 reports

MAC multicast address

The IANA owns an Ethernet address block that can be used for multicast address assignments or other

special purposes. The available MAC multicast addresses range from 01:00:5E:00:00:00 through01:00:5E:7F:FF:FF (hexadecimal notation).

Mapping between IP and MAC multicast addresses

In order to map an IP multicast address to a MAC multicast address, the lower 23 bits of the IP multicastaddress are placed into the lower 23 bits of the MAC multicast address. This is depicted in the following

illustration:

iPackets that have one of these addresses as IP destination address, are never forwarded by arouter. As a result, these packets do not travel outside the subnet.

IP Multicast Address 1110 10101 10101101011010110101101

101011010110101101011011010110101101011010110101

5 bits

dropped

4 bits

fixed

32 bits

28 bits

23 bits

48 bits

25 bits fixed

MAC Multicast Address

23 bits


6/122

E-NIT-CTC-20050927-0004 v3.0


6

The following illustration gives an example:

iThe upper 5 bits of the IP multicast group ID are dropped in this mapping. As a consequence, theresulting MAC multicast address is not unique. 32 different IP multicast addresses all map to the

same MAC address.

IP Multicast Address 1110 11111 11111110000000000000001

111111100000000000000010000000100000000010111100MAC Multicast Address

239.255.0.1

(binary)

(decimal)

(binary)

(hexadecimal)01:00:5E:7F:00:01


7/122

E-NIT-CTC-20050927-0004 v3.0

Chapter 2Internet Group Management Protocol (IGMP)

7

2 Internet Group Management Protocol (IGMP)

IntroductionWhen a host wants to receive a specific multicast stream, it must join the corresponding multicast group.

IGMP is the protocol used by IPv4 systems, i.e. hosts and routers, to report their IP multicast groupmemberships to neighbouring multicast routers.

IGMP is an integral part of IP and the IGMP messages are encapsulated in IP packets. All IGMP messages are

sent with an IP protocol number equal to 2, an IP TTL (Time To Live) equal to 1 and the IP router alert option inthe IP packet header.

OverviewIn this chapter, the following aspects of IGMP and their support in the Thomson Gateway are discussed:

i Multicast Listener Discovery (MLD) is used by IPv6 systems and is derived from IGMPv2.

Topic Page

2.1 Setting Up a Multicast Group 8

2.2 IGMP Versions 12

2.3 IGMP Signalling 14

2.4 IGMP Proxying 18

2.5 IGMP Snooping 20


8/122

E-NIT-CTC-20050927-0004 v3.0


8

2.1 Setting Up a Multicast Group

IntroductionThis section describes how to set up a multicast group. As an example, the different steps of a particular

scenario are listed as follows:

1 Initially, the only members of the multicast group are the video server and its peer router.

2 One of the clients initiates an IGMP membership report.

3 More IGMP signalling takes place.

4 All clients of the multicast group receive the multicast stream.

Initial situation

As shown in Figure 1, initially the video stream of multicast group 225.0.0.1 is sent from server S1 torouter R1. As router R1 is not aware that clients C1, C2 and C3 will announce their membership of the

multicast group 225.0.0.1, it will not forward the packets of the video stream.

Figure 1 Initial situation.

Clients

R4

Routers

R3

R2

R1

Video

Server

C1

C2

C3

C4

255.0.0.1

S1
http://-/?-http://-/?-


9/122

E-NIT-CTC-20050927-0004 v3.0


9

First IGMP membership report

Client C1 announces its membership of multicast group 225.0.0.1 by means of an IGMP membership report

sent to router R2 (see Figure 2). This first IGMP message is also known as an IGMP join although suchmessage does not exist within IGMP.

Figure 2 First IGMP membership report.

Clients

R4

Routers

R3

R2

R1

Video

Server

C1

C2

C3

C4

255.0.0.1

IGMP join

255.0.0.1

S1
http://-/?-http://-/?-


10/122

E-NIT-CTC-20050927-0004 v3.0


10

Additional IGMP messages

Figure 3 shows more IGMP signalling to set up multicast group 225.0.0.1. Router R2 registers client C1 as a

member of multicast group 225.0.0.1. As router R2 does not have a video stream for multicastgroup 225.0.0.1, it requests the stream by messages typical of the multicast routing protocol in use towards

router R1. At the same time, client C2 initiates a new IGMP membership report towards router R2 andclient C3 initiates a new IGMP membership report towards router R3.

Figure 3 Additional IGMP messages.

Clients

R4

Routers

R3

R2

R1

Video

Server

C1

C2

C3

C4

255.0.0.1

IGMP join255.0.0.1

IGMP join

255.0.0.1

IGMP join

255.0.0.1

S1
http://-/?-http://-/?-


11/122

E-NIT-CTC-20050927-0004 v3.0


11

Completed multicast group

All members of multicast group 225.0.0.1 establish a path along which the server can send the video stream

that is assigned to multicast group 225.0.0.1 (see Figure 4).

> Router R1 receives the video stream from server S1 and forwards it to router R2 and router R3.> Router R2 receives the video stream from router R1 and forwards it to client C1 and client C2.

> Router R3 receives the video stream from router R1 and forwards it to client C3.

> Client C4 and router R4 are no members of multicast group 225.0.0.1.

Figure 4 Completed multicast group.

Clients

R4

Routers

R3

R2

R1

VideoServer

C1

C2

C3

C4

255.0.0.1

255.0.0.1

255.0.0.1

255.0.0.1

255.0.0.1

255.0.0.1

S1
http://-/?-http://-/?-


12/122

E-NIT-CTC-20050927-0004 v3.0


12

2.2 IGMP Versions

IntroductionIGMP is the protocol used by IPv4 systems, i.e. hosts and routers, to report their IP multicast group

memberships to neighbouring multicast routers. In this section, we shortly describe the different versions ofthe IGMP protocol and their support in the Thomson Gateway.

IGMP version 1

IGMPv1 defines only two types of IGMP messages:

> Membership query: a multicast router sends query messages to discover which multicast groups havemembers on the attached local networks. These messages are sent with an IP destination address equalto 224.0.0.1.

> Membership report: a host responds to a query message with a report message, reporting eachmulticast group to which they belong on the network interface from which the query was received. These

messages are sent with an IP destination address equal to the multicast group address.

To join a multicast group that is not accessible yet on its network segment, a host sends a report message to

that multicast group. This first IGMP message is also known as an IGMP join although such message doesnot exist within IGMP. When a host joins a new group, it should immediately transmit a report message for

that group, rather than waiting for a query message, in case it is the first member of that group on thenetwork.

IGMP version 2

IGMPv2 adds support for Low Leave Latency or Fast Immediate Leave. This reduces the time it takes for

a multicast router to learn that there are no longer any members of a particular group present on an attachednetwork. IGMPv2 allows group membership termination to be quickly reported to the routing protocol, which

is important for high-bandwidth multicast groups and/or subnets with highly volatile group membership.

IGMPv2 defines three types of IGMP messages:

> Membership query: two types of query messages are defined:

A general query is used to learn which groups have members on an attached network (Of whichmulticast groups are you a member?). These messages are sent with an IP destination address equal

to 224.0.0.1 and a group address equal to 0.

A group-specific query is used to learn if a particular group has any members on an attached network

(Are you a member of this multicast group?). These messages are sent with an IP destination addressequal to 224.0.0.1 and a group address equal to the group address of interest.

> Version 2 membership report

> Leave group: a leave group message is sent when a host leaves a group. This way, a host can activelycommunicate to the local multicast router its intention to leave the group. The router then sends out agroup-specific query. If there are no replies, the router times out the group and stops forwarding thetraffic. The IP destination address of these messages is 224.0.0.2.

In order to be compatible with IGMPv1, IGMPv2 also supports:


i A hosts membership in the all-hosts group 224.0.0.1 is never reported.


13/122

E-NIT-CTC-20050927-0004 v3.0


13

IGMP version 3

IGMPv3 adds support for Source Filtering or Explicit Host Tracking, that is, the ability for a system to

report interest in receiving packets only from specific source addresses, as required to support Source-Specific Multicast (SSM), or from all but specific source addresses, sent to a particular multicast group

address.

IGMPv3 defines two types of IGMP messages:

> Membership query: three types of query messages are defined:

A general query is used to learn the complete multicast reception state of the neighbouring interfaces(group address=0, number of sources=0).

A group-specific query is used to learn the reception state with respect to a specific multicast groupaddress (group address=group address of interest, number of sources=0).

A group-and-source-specific query is used to learn if any neighbouring interface desires reception ofpackets sent to a specified group address, from any of a specified list of sources (groupaddress=group address of interest, source fields=source addresses of interest).

> Version 3 membership report: These messages are sent with an IP destination address equal to224.0.0.22.

In order to be compatible with IGMPv1 and IGMPv2, IGMPv3 also supports:



> Version 2 leave group

IGMP support in the Thomson Gateway

The Thomson Gateway supports IGMPv3. By default, the Thomson Gateway runs in IGMPv3 compatibility

mode on all its upstream and downstream interfaces.

If the Thomson Gateway discovers an IGMPv2 or IGMPv1 router on one of its upstream interfaces, it enters inIGMPv2 or IGMPv1 compatibility mode.

If the Thomson Gateway discovers at least one host on a downstream interface that sends an IGMPv2 or

IGMPv1 report message, it enters in IGMPv2 or IGMPv1 compatibility mode for this specific multicast group.A compatibility mode is kept per group. The groups compatibility mode is determined by the lowest versionof IGMP report message detected on that downstream IP interface.

iWhich IGMP version is supported by the host mainly depends on the operating system:IGMPv1 is supported by hosts running Windows 95.IGMPv2 is supported by hosts running Windows 98 or 2000.IGMPv3 is supported by hosts running Windows XP.


14/122

E-NIT-CTC-20050927-0004 v3.0


14

2.3 IGMP Signalling

IntroductionIn this section, the following examples are used to explain the most common IGMP signalling scenarios:

> Join request or first membership report

> Query and response

> Leave request

> Zapping

Join request

Different types of join requests are explained by the message flow in Figure 5.

1 Client C1 sends an IGMP join request for multicast group 225.0.0.1 to router R2 to announce that it wantsto receive the stream associated with this multicast group. Router R1 drops packets from multicastgroup 225.0.0.1.

2 As router R2 does not have a source stream for multicast group 225.0.0.1, it requests the stream bymessages typical of the multicast routing protocol in use towards router R1.

3 A source for multicast group 225.0.0.1 is available at router R1. Router R1 forwards the stream torouter R2. Router R2 forwards the stream to client C1.

4 Client C2 sends an IGMP join request for multicast group 225.0.0.1 to router R2.

5 At this time a source for multicast group 225.0.0.1 is available at router R2. Router R2 forwards the streamto both client C1 and client C2.

Figure 5 Join request.

Client C2 Client C1 Router R2 Router R1 Server S1

IGMP join

225.0.0.1 IGMP join225.0.0.1

IGMP join225.0.0.1

225.0.0.1

225.0.0.1

225.0.0.1

225.0.0.1

225.0.0.1

225.0.0.1

225.0.0.1

225.0.0.1
http://-/?-http://-/?-


15/122

E-NIT-CTC-20050927-0004 v3.0


15

Query and response messages

At regular intervals, a multicast router sends a query to probe for members of multicast groups. Based on the

responses received from peers, the router can decide whether it needs to maintain membership of themulticast groups. If a specific multicast stream is no longer requested by any peer of the router, it is no longer

necessary for the router to receive this stream.

Figure 6 shows a message flow with some queries and responses:

1 Client C1 is member of multicast group 225.0.0.1. Client C2 is member of multicast group 225.0.0.2.

2 Router R2 sends a query to client C1 and client C2. These queries can be general or specific.

3 Client C1 sends a response to report its membership of multicast group 225.0.0.1.

4 Client C2 sends a response to report its membership of multicast group 225.0.0.2.

5 Router R1 and router R2 exchange information via messages typical of the multicast routing protocol.

Figure 6 IGMP query and response.


225.0.0.1

225.0.0.2

225.0.0.1

225.0.0.2

225.0.0.1

225.0.0.2

IGMP Query

IGMP Query

IGMP Query

IGMP Resp.

225.0.0.1

IGMP Resp.225.0.0.2 IGMP Resp.

225.0.0.1

IGMP Resp.

225.0.0.2
http://-/?-http://-/?-


16/122

E-NIT-CTC-20050927-0004 v3.0


16

Leave request

Different types of leave requests are explained by the message flow in Figure 7.

1 Initially, client C1 and client C2 are member of multicast group 225.0.0.1.

2 Client C2 sends a leave request for multicast group 225.0.0.1 to indicate that it no longer wishes toreceive the video stream. Router R2 forwards the stream only to client C1.

3 Client C1 sends a leave request for multicast group 225.0.0.1. Router R2 no longer forwards the stream.

4 Before sending a leave request to router R1, router R2 sends a query to make sure it serves no membersof multicast group 225.0.0.1.

5 Router R1 and router R2 exchange information via messages typical of the multicast routing protocol.

Figure 7 Leave request.


225.0.0.1

225.0.0.1225.0.0.1

225.0.0.1

225.0.0.1

225.0.0.1

225.0.0.1

225.0.0.1

225.0.0.1

225.0.0.1

IGMP Leave

225.0.0.1

IGMP Leave

225.0.0.1

IGMP Leave

225.0.0.1

IGMP Query

IGMP Query
http://-/?-http://-/?-


17/122

E-NIT-CTC-20050927-0004 v3.0


17

Zapping

Figure 8 shows how client C1 zaps from multicast group 225.0.0.1 to multicast group 225.0.0.2.

1 Initially, client C1 is member of multicast group 225.0.0.1 and client C2 is member of multicast

group 225.0.0.2.2 Client C1 sends a leave request to indicate that it no longer wishes to receive multicast group 225.0.0.1.

Router R2 no longer forwards the stream to client C1.

3 After a short period, client C1 sends a join request to announce it wishes to receive multicast

group 225.0.0.2. Router R2 forwards the stream to both client C1 and client C2.

Figure 8 IGMP zapping.


225.0.0.1

225.0.0.1225.0.0.1

225.0.0.2

225.0.0.2225.0.0.2

225.0.0.1

225.0.0.2

225.0.0.2

225.0.0.2

225.0.0.2

225.0.0.1IGMP Leave

225.0.0.1

IGMP Join

225.0.0.2
http://-/?-http://-/?-


18/122

E-NIT-CTC-20050927-0004 v3.0


18

2.4 IGMP Proxying

IntroductionIGMP proxying can be seen as a lightweight multicast routing mechanism. A device that supports IGMP

proxying is called an IGMP proxy. The IGMP proxy will learn and proxy group membership information.

IP interfaces

The direction (upstream or downstream) of each IP interface of the IGMP proxy must be explicitly specified.

The IGMP proxy acts as an IGMP router on each downstream interface and acts as an IGMP host on theupstream interface.

Membership database

The IGMP proxy acts as an IGMP router on each downstream interface. As a result, the proxy has a separateset of subscriptions for each of these downstream interfaces. All these subscriptions are also merged into a

membership database.

IGMP traffic

The IGMP proxy acts as an IGMP host on its upstream interface. It sends membership report messages on the

upstream interface when queried. It also sends membership report or leave messages when the membershipdatabase changes. Thanks to those simplifications, the IGMP proxy does not have to support a 'real' multicastrouting protocol and it can communicate with the upstream multicast router, simply via IGMP.

An IGMP report arriving on a downstream interface will not necessarily lead to the transmission of an IGMP

report on an upstream interface.

In case the IGMP proxy detects that the last member of a particular group on a downstream interface has left,

traffic belonging to that group will no longer be forwarded to that downstream interface. It does notnecessarily mean that a 'leave' report will be transmitted over the upstream interface. That would only be the

case when the last member of a particular group considering all downstream interfaces leaves.

Data traffic

An IGMP proxy forwards multicast data packets as follows:

> If a data packet is received on its upstream interface, then this data packet is forwarded to each

downstream interface, based on the set of subscriptions of each downstream interface.> If a data packet is received on a downstream interface, then the data packet is forwarded to the upstream

interface. The data packet is also forwarded to the downstream interfaces (except the receiving interface),based on the set of subscriptions of each downstream interface.


19/122

E-NIT-CTC-20050927-0004 v3.0


19

IGMP proxying in the Thomson Gateway

In order to use IGMP proxying in the Thomson Gateway, you must specify an upstream IP interface (typically

this is the WAN interface) and a downstream IP interface (typically this is a LAN interface).

When the Thomson Gateway receives an IGMP report message on its downstream IP interface, it checks if italready has a subscription to this multicast group address. If it does not have a subscription present in itsmembership database, it replicates this report and forwards it on the upstream IP interface. Once the stream

is received, the Thomson Gateway forwards and/or replicates the stream to the appropriate device on itsdownstream IP interface.

However, the Thomson Gateway implementation is not fully compliant with the IETF specifications for an

IGMP proxy. It deviates from those IETF specifications on the following points:

> The Thomson Gateway supports multiple upstream interfaces.

> The Thomson Gateway implementation never forwards a multicast packet to an upstream interface, norwill it forward a multicast packet from one downstream interface to another downstream interface.

This results in the restriction that the Thomson Gateway does not support group-based applications that

have traffic sources on downstream interfaces and of which the users (members) span multiple interfaces,

like videoconferencing applications.The IGMP proxy does not learn which streams are made available by the video provider. Typically, that'sdone via SDP or a web-based application which is not foreseen on the Thomson Gateway.

i IGMP proxying is supported by the Thomson Gateway since Release 5.4.

IGMPv3

Server

IGMPv3

Host

Multicast Routing

Database

Multicast Router

IGMP Proxy

LAN

Subscription

Database

Video Server


20/122

E-NIT-CTC-20050927-0004 v3.0


20

2.5 IGMP Snooping

No use of IGMP snoopingIf IGMP snooping is not used, a Layer 2 switch deals with multicast traffic in the same way as broadcast

traffic:

> The switch receives a data frame on interface X.

> The switch detects that the MAC destination address is a multicast address.

> The data frame is forwarded on all interfaces, except interface X.

While broadcast traffic must be received by all hosts, multicast traffic is intended for only a (small) group of

hosts. As a result, a lot of hosts that are not interested will receive the traffic. The traffic is also sent on partsof the network where not a single host wants to receive the traffic. This results in an inefficient use of thenetwork bandwidth.

Use of IGMP snooping

If IGMP snooping is used, a Layer 2 switch listens to the Layer 3 IGMP messages to determine which switchinterfaces are interested in receiving certain multicast traffic. The switch listens for IGMP query, report and

leave messages.

> When the switch hears a group join message from a host, it notes which switch interface it heard themessage on, and adds that interface to the group.

> When the switch hears a group leave message or a response timer expires, the switch will remove thathosts switch interface from the group.

A Layer 2 switch can make intelligent multicast forwarding decisions by examining the content of the Layer 3IP header of each data frame.

No traffic is sent on parts of the network where no host has expressed interest in receiving packets addressedto the group address. As a result, the amount of multicast traffic can be significantly reduced.

iIGMP snooping violates the strict separation of functionality between the different communicationlayers in the OSI (Open Systems Interconnection) model.

Layer 2 switches that support IGMP snooping use information of Layer 3 (IP) to make forwardingdecisions at Layer 2 (Ethernet).


21/122

E-NIT-CTC-20050927-0004 v3.0


21

Example

Consider the following simple network. Eight hosts connect to four Layer 2 switches. These switches connect

to one Layer 3 router in the middle. Host A is an IP multicast transmitter and hosts B and C are multicastreceivers in the same group as host A. The router will correctly forward IP multicast traffic only to those

segments with registered receivers (hosts B and C).

If IGMP snooping is not used by the Layer 2 switches, then the multicast traffic is received by all hosts on the

segments with registered receivers. This is depicted in the following illustration:

Host A

Host B

Host C

L2 Switch

L3 Router


22/122

E-NIT-CTC-20050927-0004 v3.0


22

If the Layer 2 switches use IGMP snooping, then only the hosts that are registered receivers receive multicast

traffic. This situation is depicted in the following illustration:

IGMP snooping in the Thomson Gateway

The Thomson Gateway supports IGMP snooping for IGMPv1, IGMPv2 and IGMPv3.

When IGMP snooping is implemented, the Thomson Gateway allows only multicast traffic towards the OBC.The IGMP snooping module in the Thomson Gateway is responsible of managing the bridge in order to allowmulticast traffic towards other ports of the bridge.

The IGMP snooping module listens on:

> IGMP report messages: when an IGMP report message is received on a bridge port, traffic for thereported multicast stream is allowed to that specific bridge port. Traffic is allowed on the specific bridge

port for a given amount of time (default value is 180 s).

> IGMP leave messages: when an IGMP leave message is received on a bridge port, traffic for the reportedmulticast stream is still allowed to that specific bridge port for a given amount of time (default value is5 s).

> IGMP query messages: when an IGMP query message is received on a bridge port, IGMP report andleave messages are allowed to that specific bridge port for a given amount of time (default value is 180 s).

Host A

Host B

Host C

L2 Switch

L3 Router

i IGMP snooping is supported by the Thomson Gateway since Release 6.1.9.


23/122

E-NIT-CTC-20050927-0004 v3.0

Chapter 3The Thomson Gateway and Flexiport

23

3 The Thomson Gateway and Flexiport

IntroductionThis chapter introduces the use of the Flexiport concept. Before the introduction of Flexiport, port-to-PVC

mapping was the solution for triple play configurations. It was important that the correct devices wereconnected to the correct Ethernet ports. The chance of errors was big, resulting in helpdesk calls etc. With theuse of Flexiport, pre-defined LAN devices can be recognized on-the-fly and mapped to a PVC, while other

not-recognized devices will be routed over the same PVC. This is done by identifying the device based onthe Vendor Code Identifier (vci) or MAC address (mac) sent out with the DHCP request.

Overview

In this chapter, the following aspects of Flexiport and their support in the Thomson Gateway are discussed:

!A maximum of four devices can simultaneously make use of Flexiport on a Thomson Gateway. TheMAC addresses of the devices connected are saved in the dynvlan membership database. If a fifth

device need to be connected the dynvlan membership database should not store the MACaddresses.

Since release R6.1 there is an option in the flexiport script to enable dynamic MAC addresses. If this

option is enabled the MAC addresses will not be stored in the dynvlan membership database.:script add name dhcr_video index 0 command "eth bridge dynvlan add hwaddr $1 vlan videodynamic enabled"

By default the option dynamic is disabled so the MAC address will be saved to the database.

Topic Page

3.1 Life before Flexiport 24

3.2 Advantages of Flexiport 26

3.3 The Flexiport Concept 27


24/122

E-NIT-CTC-20050927-0004 v3.0


24

3.1 Life before Flexiport

Port-to-PVC mappingAs mentioned before, port-to-PVC mapping was the solution for the classic triple play scenario. As illustrated

in Figure 9, three PVCs were needed:

> 1 data PVC for surfing

> 1 voice PVC for VoIP (Voice over IP)

> 1 video PVC for the STB (Set Top Box)

Figure 9 Classic Triple Play Scenario.

The setup above uses:

> Port-to-PVC mapping: map n ports to m PVCs.

> Real DMZ: uses 1 or more interfaces as isolated IP interfaces.

i Port-to-PVC mapping is supported by the Thomson Gateway since Release 5.3.0.

192.168.1.64

192.168.1.65

192.168.1.66

IP Phone

Set Top Box

with Television

xDSL

Network

PVC1

PVC2

PVC3
http://-/?-http://-/?-


25/122

E-NIT-CTC-20050927-0004 v3.0


25

Example

An example of a possible switch configuration is shown in Figure 10:

> Port 1: IP Phone

> Port 2: Data> Port 3: Data

> Port 4: STB

> WiFi: Data

Figure 10 Port connection.

Ethernet

1 432

DSLReset

1

2

4

3

ON/OFF

Data Traffic

IP Phone Traffic

Set Top Box Traffic

xDSL

Network


26/122

E-NIT-CTC-20050927-0004 v3.0


26

3.2 Advantages of Flexiport

What was missing?In the classic triple play scenario, all Ethernet ports were grouped together with one or more PVCs in a static

way. They were all grouped together in separate VLANs. This implied that the configuration could not bealtered without having to restart the device. It was important that the correct devices were connected to thecorrect Ethernet ports.

Another restriction was that, once a port-to-PVC map was created, forwarding was limited to bridging in allgroups except the default group. Routing and bridging in the default group is not feasible since routing with

NAPT requires multiple physical interfaces.

Whats new with Flexiport?

The most important advantage of Flexiport is the fact that devices can be recognized on-the-fly and bemapped to the PVC offering the services that are needed. For example, a certain type of STB can berecognized and automatically linked with the PVC towards the video network - no matter which Ethernet port

they are plugged in to. This is done by placing the MAC address of the device in a VLAN which has the properPVC mapped to it. Other devices that are not recognized will still be routed over the default PVC.

Another advantage of Flexiport is that multicast traffic will be sent to the STB port only, which is similar toIGMP snooping. When connecting another device to the STB port, it will be routed again.

Wireless ports and WDS ports can also be configured as Flexiport. This can be used to overcome largerdistances without the hassle of cables. When running voice or video services over wireless it is

recommended to use WMM (WiFi MultiMedia. This feature ensures some kind of Quality of Service. See4 Wi-Fi MultiMedia (WMM) on page 28 for more information.

Partial string match

Since Release 6.1 it is possible to use a partial string match in the Flexiport rules. This can be done for bothMAC addresses and VCI. Both of them use different notations:

MAC address:

Here we use * as a wildcard, so any device with a MAC address starting with 00:0f:1f will be placed in thedynvlan membership database.

VCI code:

Here, we only put part of the vci code in the rule and add the optionmatch as_substring. This will putthe MAC address of any device with ST20 in the vci in the dynvlan membership database.E.g. devices with vci ST2030 or ST2020 will be place in the dynvlan membership database.

:dhcp rule add name=STB type=mac mac=00:0f:1f:*:*:*

:dhcp rule add name VOIP type vci vci ST20 match as_substring


27/122

E-NIT-CTC-20050927-0004 v3.0


27

3.3 The Flexiport Concept

Figure 11 shows the concept of Flexiport.

Figure 11 The Flexiport concept.

The concept

The STB is recognized as soon as it is plugged into the Thomson Gateway. This is done in seven steps:

1 The Thomson Gateway is up and running, PCs are surfing the Internet through one PVC.

2 The STB is added to one of the ports of the Thomson Gateway and sends out a DHCP discover message.

3 The DHCP relay will identify the STB by its Vendor Class ID (vci) or MAC address and will move the STBsMAC address into a second VLAN.

4 The STB will re-send the DHCP discover message, but now as member of the second VLAN.

5 The STB will now receive an IP address from the video DHCP server and can start receiving video.

6 The STBs MAC address will be saved, and the next time the Thomson Gateway reboots, it will rememberto which VLAN the STB belongs.

7 When the STB reboots, it will send a DHCP request and restart the procedure from step 2.

Ethernet port1

Ethernet port 2

Ethernet port 3

Ethernet port 4

Internet

BRAS

DHCP Server

Video Server

Video Network

NATed data traffic

Bridged video traffic

iThe Flexiport concept can also be used for wired and wireless IP phones. This way the data fromthe IP phone is bridged to the Voice PVC while other wireless devices can still surf the web over the

ETHoA connection.

iFlexiport is supported by the Thomson Gateway since Release 5.3.2 for a single PVC and sinceRelease 5.4 for multiple PVCs.
http://-/?-http://-/?-


28/122

E-NIT-CTC-20050927-0004 v3.0

Chapter 4Wi-Fi MultiMedia (WMM)

28

4 Wi-Fi MultiMedia (WMM)

Why WMM?The support of multimedia applications in a Wi-Fi network requires Quality of Service (QoS) functionality.

Without QoS, all applications running on different devices have equal opportunity to transmit data frames.That works well for data traffic from applications such as web browsers, file transfer or e-mail. However, it isinadequate for multimedia applications such as Voice over Internet Protocol (VoIP), video streaming and

interactive gaming. These applications are highly sensitive to latency increases and throughput reductions.These applications require QoS.

WMM

WMM offers QoS functionality. It enables Wi-Fi access points to prioritize traffic and optimizes the way shared

network resources are allocated among different applications.

WMM extends Wi-Fis high quality end-user experience from data connectivity to voice, music, and video

applications under a wide variety of environment and traffic conditions.

WMM defines four access categories that are used to prioritize traffic. As a result, voice, music and video

applications have access to the necessary network resources. These access categories are:

> Voice

> Video

> Best effort

> Background

Additionally, WMM-enabled wireless networks simultaneously support legacy devices that do not haveWMM functionality. Legacy devices that do not have WMM functionality have the same priority as WMM

enabled devices that use best effort.

4.1 WMM in the Thomson Gateway

DSCP Class Selector

WMM assigns a particular priority to packets according to their DSCP Class Selector (CS). See the IP QoS

configuration guide for more information about Quality of Service.

As seen above, there are four access categories: voice, video, best effort and background. These accesscategories correspond to the following Class Selectors when using DSCP:

> Voice - CS7

> Video - CS5

> Best Effort - CS0

> Background - CS1


29/122

E-NIT-CTC-20050927-0004 v3.0

Chapter 4Wi-Fi MultiMedia (WMM)

29

Graphical User Interface (GUI)

In the GUI, the WMM functionality cannot be turned on or off. We can only see whether WMM is enabled or

not.

To do so, go to:

Home Network > Interfaces > WLAN: SpeedTouchXYZ > Details

CLI commands

WMM functionality can only be turned on or off via the CLI command line.

To do so, proceed as follows to turn WMM on:

To disable WMM, proceed as follows:

:wireless qos config mode=wmm

:wireless qos config mode=disabled

i By default, WMM is enabled. In fact, there is no reason to disable WMM.


30/122

E-NIT-CTC-20050927-0004 v3.0

Chapter 5Multiple Virtual Channels

30

5 Multiple Virtual Channels

IntroductionIn this chapter, we describe several use cases with multiple virtual channels. A first PVC will be used for

Internet traffic and a second PVC will be used for multicast video.

For every use case, we present:

> The intended scenario and the mechanisms that are used to set up this scenario

> The configuration of the Thomson Gateway using the CLI commands

> An illustration of the resulting configuration of the Thomson Gateway

Before we start

Before we start to configure the Thomson Gateway, we make the following preparations:

> Reset the Thomson Gateway to the factory defaults and reboot the device:

> Set the value of the variable SESSIONTIMEOUT to zero. As a result, the TELNET session with the devicenever times out:

> Flush all factory default interfaces and settings so we can start from a clean situation:

Overview

In this chapter, the following use cases with multiple virtual channels are described:

:system reset factory=yes proceed=yes

:env set var=SESSIONTIMEOUT value=0

:ppp relay flush:ppp flush

:eth flush

:atm flush

:atm phonebook flush

:ip ipdelete addr=10.0.0.138

:wireless ifconfig state disabled

Topic Page

5.1 Bridged Internet and Bridged Multicast 31

5.2 Routed Internet and Bridged Multicast, Single STB 35

5.3 Routed Internet and Bridged Multicast, Multiple STBs 41

5.4 Routed Internet and Routed Multicast, Single STB 47

5.5 Routed Internet and Routed Multicast, Multiple STBs 54

5.6 Routed Internet and Routed Multicast, IGMP-based 62


31/122

E-NIT-CTC-20050927-0004 v3.0


31

5.1 Bridged Internet and Bridged Multicast

5.1.1 Use Case

Scenario

In this scenario, we configure the Thomson Gateway as bridge with multiple PVCs. We use one PVC fornormal Internet traffic and a second PVC for multicast traffic.

This implies that all computers that want to surf the Internet have to set up a PPP connection from the

computer using the software PPPoE client.

The Set Top Box (STB) connected to Ethernet port four receives an IP address from a DHCP server in the video

network segment, located at the ISP.

The scenario is depicted in the following illustration:

Figure 12 The Thomson Gateway with multiple bridge connections.

Mechanisms

To set up this scenario, we use the following mechanisms:

> Dedicated multicast port: Ethernet port four on the Thomson Gateway is used as multicast port.

> VLANs: two VLANs are used:

The default VLAN contains the data PVC, wireless interfaces and Ethernet ports one to three.

The video VLAN contains the multicast PVC and Ethernet port four.

Internet IP

Video Network IP

Internet

BRAS

DHCP Server

Video Server

Video Network

DSLAM

Bridged Connection

Bridged Connection


32/122

E-NIT-CTC-20050927-0004 v3.0


32

5.1.2 Configuration

In this section, we describe the configuration of the Thomson Gateway to set up this scenario. Theconfiguration has been created using the CLI.

Data PVC and ATM interface

Proceed as follows:

> Create a phonebook entry for the data PVC:

> Create the data ATM interface:

Video PVC and ATM interface

Proceed as follows:

> Create a phonebook entry for the video PVC:

> Create the video ATM interface:

Video VLAN

Proceed as follows:

> Enable the use of VLANs:

> Create a video VLAN:

:atm phonebook add name=pvc_data addr=8.35

:atm ifadd intf=atm_data

:atm ifconfig intf=atm_data dest=pvc_data encaps=llc ulp=mac

:atm ifattach intf=atm_data

:atm phonebook add name=pvc_video addr=0.38

:atm ifadd intf=atm_video

:atm ifconfig intf=atm_video dest=pvc_video encaps=llc ulp=mac

:atm ifattach intf=atm_video

:eth bridge config vlan=enabled

:eth vlan add name=video vid=2


33/122

E-NIT-CTC-20050927-0004 v3.0


33

Ethernet interfaces on the bridge

Proceed as follows:

> Create an Ethernet WAN interface on the bridge connected to the data ATM interface:

> Create an Ethernet WAN interface on the bridge connected to the video ATM interface:

Port-to-PVC mappingProceed as follows:

> Place the newly created br_video Ethernet WAN interface and Ethernet LAN interface four in the videoVLAN:

Save the configurationProceed as follows:

> Save the configuration:

:eth bridge ifadd intf=br_data

:eth bridge ifconfig intf=br_data dest=atm_data

:eth bridge ifattach intf=br_data

:eth bridge ifadd intf=br_video

:eth bridge ifconfig intf=br_video dest=atm_video

:eth bridge ifattach intf=br_video

:eth bridge vlan ifadd intf=br_video name=video

:eth bridge vlan ifdelete intf=br_video name=default

:eth bridge vlan ifadd intf=ethport4 name=video

:eth bridge vlan ifdelete intf=ethport4 name=default

:eth bridge vlan ifadd intf=OBC name=video

:saveall


34/122

E-NIT-CTC-20050927-0004 v3.0


34

5.1.3 Result

The resulting configuration of the Thomson Gateway is depicted in the following illustration:

...

OBC

video (vid=2)

3 42

default (vid=1)

ethport

PC STB

Bridge

1

ATMatm_data

PVCpvc_data8.35

ATMatm_video

PVCpvc_video0.38

br

_data

br

_video


35/122

E-NIT-CTC-20050927-0004 v3.0


35

5.2 Routed Internet and Bridged Multicast, Single STB

5.2.1 Use Case

Scenario

In this scenario we configure the Thomson Gateway with multiple PVCs.

We make use of two PVCs to differentiate data traffic from multicast traffic. One PVC is used for data trafficvia a routed PPPoE Internet connection. The other PVC is used for bridged multicast traffic.

We consider the scenario with a single Set Top Box (STB).


Figure 13 The Thomson Gateway with multiple PVCs, one routed and one bridged.

MechanismsTo set up this scenario, we use the following mechanisms:

> VLANs are used.

> Flexiport is used, so that the MAC address of the STB is automatically mapped to the video VLAN.

Video Network IP

Internet

BRAS

DHCP Server

Video Server

Video Network

DSLAM

PPPoE

Connection

Bridged

Connection

NATed Internet IP

Private IP


36/122

E-NIT-CTC-20050927-0004 v3.0


36

5.2.2 Configuration



Proceed as follows:



Data Ethernet interface

Proceed as follows:

> Create the data Ethernet interface connected to the data ATM interface:

PPPoE interface

Proceed as follows:

> Create the PPPoE interface connected to the data Ethernet interface:

> Enable NAT on the PPPoE interface:

> Add a default route for Internet traffic:





:eth ifadd intf=eth_data

:eth ifconfig intf=eth_data dest=atm_data

:eth ifattach intf=eth_data

:ppp ifadd intf=pppoe_data

:ppp ifconfig intf=pppoe_data dest=eth_data user=user@inet password=pwdinet

:nat ifconfig intf=pppoe_data translation=enabled

:ppp rtadd dst=0.0.0.0 dstmsk=0.0.0.0 intf=pppoe_data

:ppp ifattach intf=pppoe_data


37/122

E-NIT-CTC-20050927-0004 v3.0


37


Proceed as follows:



Video VLAN

Proceed as follows:



Ethernet interface on the bridge

Proceed as follows:> Create an Ethernet interface on the bridge connected to the video ATM interface:

> Place this Ethernet interface in the video VLAN:

Enable dynamic Ethernet grouping on the bridge for Flexiport

Proceed as follows:

> Enable dynamic Ethernet grouping on the 4 Ethernet interfaces on the bridge:







:eth bridge ifadd intf=eth_video

:eth bridge ifconfig intf=eth_video dest=atm_video

:eth bridge ifattach intf=eth_video

:eth bridge vlan ifadd intf=eth_video name=video

:eth bridge vlan ifdelete intf=eth_video name=default


:eth bridge ifconfig intf=ethport1 dynvlan=enabled




:eth bridge dynvlan config timeout=10000


38/122

E-NIT-CTC-20050927-0004 v3.0


38

DHCP relay forwarding entry

Proceed as follows:

> Create a DHCP relay forwarding entry:

DHCP rules

Proceed as follows:

> Create a DHCP rule for the STB and a DHCP rule for the other LAN devices:

> Assign the DHCP rules to the DHCP relay forwarding entries:

Flexiport script

Proceed as follows:

> Create a Flexiport script to move the MAC address of the STB to the video VLAN:

> Assign the script to a DHCP relay forwarding entry:

:dhcp relay add name=video_to_DHCP

:dhcp relay modify name=video_to_DHCP addr=127.0.0.1 intf=LocalNetwork

!These CLI commands apply to a residential device (500 or 700 series). In the case you have a

business device (600 series), use lan1 instead ofLocalNetwork.

:dhcp rule add name=STB type=mac mac=00:0f:1f:a5:5b:b9

:dhcp rule add name=notSTB type=mac mac=!00:0f:1f:a5:5b:b9

i In this example, we use the MAC address of the STB to trigger the Flexiport script.

:dhcp relay ruleadd name=video_to_DHCP rulename=STB

:dhcp relay ruleadd name=Localnetwork_to_127.0.0.1 rulename=notSTB

!

These CLI commands apply to a residential device (500 or 700 series). In the case you have a


:script add name=dhcr_video index=0 command="eth bridge dynvlan add hwaddr $1 vlan video dynamic disabled"

! The script muststart with dhcr_ in order to work.

:dhcp relay modify name=video_to_DHCP script=video

! Here, the name of the script mustbe entered without the dhcr_ prefix


39/122

E-NIT-CTC-20050927-0004 v3.0


39

Save the configuration

Proceed as follows:


:saveall


40/122

E-NIT-CTC-20050927-0004 v3.0


40

5.2.3 Result


i This configuration has no STB-to-LAN connectivity.

eth_video...

DHCP ServerLAN_private

192.168.1.[64-253]

DHCP Relay

ETH

PPPpppoe_data

ATMatm_video

PVCpvc_video0.38

OBC

video (vid=2)

3 42

Router

IPLocalNetwork

default (vid=1)

ethport

Flexiport

PC STB

ETHeth_data

Bridge

1

192.168.1.254

ATMatm_data

PVCpvc_data8.35

public IP address


41/122

E-NIT-CTC-20050927-0004 v3.0


41

5.3 Routed Internet and Bridged Multicast, Multiple STBs

5.3.1 Use Case

Scenario


We make use of two PVCs to differentiate data traffic from multicast traffic. One PVC is used for data trafficvia a routed PPPoE Internet connection. The other PVC is used for bridged multicast traffic.

We consider the scenario with multiple Set Top Boxes (STBs).


Figure 14 The Thomson Gateway with multiple PVCs, one routed and one bridged.


> VLANs are used.

> Flexiport is used, so that the MAC address of each STB is automatically mapped to the video VLAN.

> IGMP snooping is used to avoid flooding of video streams on other ports of the bridge.

Video Network IP

Internet

BRAS

DHCP Server

Video Server

Video Network

DSLAM

PPPoE

Connection

Bridged

Connection

NATed Internet IP

Private IP


42/122

E-NIT-CTC-20050927-0004 v3.0


42

5.3.2 Configuration



Proceed as follows:




Proceed as follows:


PPPoE interface

Proceed as follows:

















43/122

E-NIT-CTC-20050927-0004 v3.0


43


Proceed as follows:



Video VLAN

Proceed as follows:



Ethernet interface on the bridge

Proceed as follows:> Create an Ethernet interface on the bridge connected to the video ATM interface:

> Place this Ethernet interface in the video VLAN:


Proceed as follows:








:eth bridge ifadd intf=eth_video

:eth bridge ifconfig intf=eth_video dest=atm_video

:eth bridge ifattach intf=eth_video

:eth bridge vlan ifadd intf=eth_video name=video

:eth bridge vlan ifdelete intf=eth_video name=default








44/122

E-NIT-CTC-20050927-0004 v3.0


44

DHCP relay forwarding entry

Proceed as follows:

> Create a DHCP relay forwarding entry:

DHCP rules

Proceed as follows:

> Create a DHCP rule for each STB and DHCP rules for the other LAN devices:


Flexiport script

Proceed as follows:

> Create a Flexiport script to move the MAC address of the STBs to the video VLAN:


:dhcp relay add name=video_to_DHCP

:dhcp relay modify name=video_to_DHCP addr=127.0.0.1 intf=LocalNetwork



:dhcp rule add name=STB1 type=mac mac=00:0f:1f:a5:5b:b9

:dhcp rule add name=STB2 type=mac mac=00:0f:1f:b5:5a:a9

:dhcp rule add name=notSTB1 type=mac mac=!00:0f:1f:a5:5b:b9

:dhcp rule add name=notSTB2 type=mac mac=!00:0f:1f:b5:5a:a9

i In this example, we use the MAC address of the STBs to trigger the Flexiport script.

:dhcp relay ruleadd name=video_to_DHCP rulename=STB1

:dhcp relay ruleadd name=video_to_DHCP key=or rulename=STB2

:dhcp relay ruleadd name=Localnetwork_to_127.0.0.1 rulename=notSTB1

:dhcp relay ruleadd name=Localnetwork_to_127.0.0.1 key=and rulename=notSTB2

!These CLI commands apply to a residential device (500 or 700 series). In the case you have abusiness device (600 series), use lan1 instead ofLocalNetwork.

:script add name=dhcr_video index=0 command="eth bridge dynvlan add hwaddr $1 vlan video dynamic disabled"


:dhcp relay modify name=video_to_DHCP script=video



45/122

E-NIT-CTC-20050927-0004 v3.0


45

IGMP snooping

Proceed as follows:

> Enable IGMP snooping:

> It is recommended to enable Fast Immediate Leave and Explicit Host Tracking:


Proceed as follows:


:eth bridge igmpsnooping config state=enabled

:eth bridge ifconfig intf=ethport1 igmpsnooping=enabled




iBy default, IGMP snooping is enabled on the bridge and also on each individual bridge

interface.

:eth bridge igmpsnooping ifconfig intf=ethport1 fastleave=enabled exptrack=enabled




:saveall


46/122

E-NIT-CTC-20050927-0004 v3.0


46

5.3.3 Result


i This configuration has no STB-to-LAN connectivity.

eth_video...


192.168.1.[64-253]

DHCP Relay

ETH

PPPpppoe_data

ATMatm_video

PVCpvc_video0.38

OBC

video (vid=2)

3 42

Router

IPLocalNetwork

default (vid=1)

ethport

PC

ETHeth_data

Bridge

1

192.168.1.254

STB2

ATMatm_data

PVCpvc_data8.35

public IP address

STB1

Flexiport

IGMP snooping


47/122

E-NIT-CTC-20050927-0004 v3.0


47

5.4 Routed Internet and Routed Multicast, Single STB

5.4.1 Use Case

Scenario


We make use of two PVCs to differentiate data traffic from multicast traffic. One PVC is used for data trafficvia a routed PPPoE Internet connection. The other PVC is used for routed multicast traffic.

We consider the scenario with a single Set Top Box (STB).


Figure 15 The Thomson Gateway with multiple PVCs, all routed.


> VLANs are used, resulting in a Layer 2 isolation of the STB and the other LAN devices.

> Flexiport is used, so that the MAC address of the STB is automatically mapped to the video VLAN.

> IGMP proxying is used.

Private IP

from DHCP Pool

Internet

BRAS

Video Server

Video Network

DSLAM

PPPoE

Connection

Video

Connection

Private IP

from DHCP Pool

NATed IP

NATed IP


48/122

E-NIT-CTC-20050927-0004 v3.0


48

5.4.2 Configuration



Proceed as follows:




Proceed as follows:


PPPoE interface

Proceed as follows:

















49/122

E-NIT-CTC-20050927-0004 v3.0


49


Proceed as follows:



Video Ethernet interface

Proceed as follows:

> Create the video Ethernet interface connected to the video ATM interface:

IP interface

Proceed as follows:

> Create the IP interface connected to the video Ethernet interface:

> Enable NAT on the IP interface:

Video VLAN

Proceed as follows:







:eth ifadd intf=eth_video

:eth ifconfig intf=eth_video dest=atm_video

:eth ifattach intf=eth_video

:ip ifadd intf=ip_video dest=eth_video

:ip ifattach intf=ip_video

:nat ifconfig intf=ip_video translation=enabled

:eth bridge config vlan=enabled filter=none

iWe use filter=none to allow all broadcasts (like DHCP requests) to the WAN interface. Bydefault, broadcasts from the Thomson Gateway itself to the WAN are filtered out, while

broadcasts from the LAN to the WAN are passed through.



50/122

E-NIT-CTC-20050927-0004 v3.0


50

Video Ethernet LAN interface

Proceed as follows:

> Create the video Ethernet LAN interface and place it in the video VLAN:

IP LAN interface

Proceed as follows:

> Create the IP LAN interface connected to the video Ethernet LAN interface:

> Assign an IP address to the IP LAN interface:


Proceed as follows:


DHCP pools

Proceed as follows:

> Create a DHCP server pool for the video network:

:eth ifadd intf=ethvideo

:eth ifconfig intf=ethvideo dest=bridge vlan=video

:eth ifattach intf=ethvideo


:ip ifadd intf=videonetwork dest=ethvideo

:ip ifconfig intf=videonetwork group=lan linksensing=enabled

:ip ifattach intf=videonetwork

:ip ipadd intf=videonetwork addr=192.168.2.254 netmask=24 addroute=enabled






:dhcp server pool add name=video index=0

:dhcp server pool config name=video intf=videonetwork poolstart=192.168.2.64poolend=192.168.2.253 netmask=24 gateway=192.168.2.254 server=192.168.2.254primdns=192.168.2.254 leasetime=7200


51/122

E-NIT-CTC-20050927-0004 v3.0


51

DHCP relay forwarding entries

Proceed as follows:

> Enable configuration of the DHCP relay interface for the video network:

> Create DHCP relay forwarding entries. We need to create two forwarding entries:

The first forwarding entry will check the MAC address of the device in the DHCP request. If the MAC

address of the device matches the MAC address in the rule, it will trigger the Flexiport script andmove the MAC address of the device to the video VLAN. If the MAC address does not match the MAC

address in the rule the DHCP request will be forwarded to the default internal DHCP server of theThomson Gateway.

The second forwarding entry will forward a new DHCP request towards the internal video DHCPserver.

DHCP rules

Proceed as follows:

> Create a DHCP rule for the STB and a DHCP rule for the other LAN devices:


:dhcp relay ifconfig intf=videonetwork relay=enabled

:dhcp relay add name=LocalNetwork_to_script

:dhcp relay modify name=LocalNetwork_to_script addr=127.0.0.1 giaddr=192.168.1.254intf=LocalNetwork

:dhcp relay add name=video_to_dhcp

:dhcp relay modify name=video_to_dhcp addr=127.0.0.1 giaddr=192.168.2.254intf=videonetwork

!These CLI commands apply to a residential device (500 or 700 series). In case you have abusiness device (600 series), use lan1 instead ofLocalNetwork.

:dhcp rule add name=STB type=mac mac=00:19:b9:2d:0f:c1

:dhcp rule add name=notSTB type=mac mac=!00:19:b9:2d:0f:c1

i In this scenario, we use the MAC address of the STB to trigger the Flexiport script.

:dhcp relay ruleadd name=video_to_dhcp rulename=STB

:dhcp relay ruleadd name=LocalNetwork_to_127.0.0.1 rulename=notSTB

:dhcp relay ruleadd name=LocalNetwork_to_script rulename=STB



52/122

E-NIT-CTC-20050927-0004 v3.0


52

Flexiport script

Proceed as follows:



IGMP proxy

Proceed as follows:

> Enable the IGMP proxy to forward all multicast traffic from the WAN to the video VLAN:

> Configure each IP interface as an upstream or a downstream IP interface:


Proceed as follows:


:script add name=dhcr_video index=0 command="eth bridge dynvlan add hwaddr $1 vlan video dynamic enabled"


:dhcp relay modify name=LocalNetwork_to_script script=video



:igmp proxy config state=enabled

:igmp proxy ifconfig intf=pppoe_data state=upstream

:igmp proxy ifconfig intf=ip_video state=upstream

:igmp proxy ifconfig intf=videonetwork state=downstream

:saveall


53/122

E-NIT-CTC-20050927-0004 v3.0


53

5.4.3 Result


i

This configuration has a unicast STB-to-LAN connectivity.

This configuration has no multicast (UPnP) STB-to-LAN connectivity.

This configuration cannot cope with a NAT unfriendly STB.

...


192.168.1.[64-253]

DHCP Servervideo

192.168.2.[64-253]

DHCP Relay

ETHethvideo

IPvideonetwork

ETH

ATMatm_data

PVCpvc_data8.35

DOWN

OBC

video (vid=2)

3 42

Router

IPLocalNetwork

DOWN

default (vid=1)

ethport

PC STB

IGMP Proxy

Bridge

1

192.168.1.254 192.168.2.254

PPPpppoe_data

UP

ETHeth_data

public IP address

Flexiport

ATMatm_video

PVCpvc_video0.38

IPip_video

UP

ETHeth_video

public IP address


54/122

E-NIT-CTC-20050927-0004 v3.0


54

5.5 Routed Internet and Routed Multicast, Multiple STBs

5.5.1 Use Case

Scenario


We make use of two PVCs to differentiate data traffic from multicast traffic. One PVC is used for data trafficvia a routed PPPoE Internet connection. The other PVC is used for routed multicast traffic.

We consider the scenario with multiple Set Top Boxes (STBs).


Figure 16 The Thomson Gateway with multiple PVCs, all routed.


> VLANs are used, resulting in a Layer 2 isolation of the STBs and the other LAN devices.

> Flexiport is used, so that the MAC address of each STB is automatically mapped to the video VLAN.

> IGMP proxying is used.

> IGMP snooping is used to avoid flooding of multicast streams on other ports of the bridge.

Private IP

from DHCP Pool 2

Internet

BRAS

Video Server

Video Network

DSLAM

PPPoE

Connection

Video

Connection

Private IP

from DHCP Pool 1

NATed IP

NATed IP


55/122

E-NIT-CTC-20050927-0004 v3.0


55

5.5.2 Configuration



Proceed as follows:




Proceed as follows:


PPPoE interface

Proceed as follows:

















56/122

E-NIT-CTC-20050927-0004 v3.0


56


Proceed as follows:



Video Ethernet interface

Proceed as follows:

> Create the video Ethernet interface connected to the video ATM interface:

IP interface

Proceed as follows:

> Create the IP interface connected to the video Ethernet interface:

> Enable NAT on the IP interface:





:eth ifadd intf=eth_video

:eth ifconfig intf=eth_video dest=atm_video

:eth ifattach intf=eth_video

:ip ifadd intf=ip_video dest=eth_video

:ip ifattach intf=ip_video

:nat ifconfig intf=ip_video translation=enabled


57/122

E-NIT-CTC-20050927-0004 v3.0


57

Video VLAN

Proceed as follows:



Video Ethernet LAN interface

Proceed as follows:

> Create the video Ethernet LAN interface and place it in the video VLAN:

IP LAN interface

Proceed as follows:

> Create the IP LAN interface connected to the video Ethernet LAN interface:

> Assign an IP address to the IP LAN interface:

Enable dynamic Ethernet grouping on the bridge for FlexiportProceed as follows:


:eth bridge config vlan=enabled filter=none

iWe use filter=none to allow all broadcasts (like DHCP requests) to the WAN interface. By

default, broadcasts from the Thomson Gateway itself to the WAN are filtered out, whilebroadcasts from the LAN to the WAN are passed through.


:eth ifadd intf=ethvideo

:eth ifconfig intf=ethvideo dest=bridge vlan=video

:eth ifattach intf=ethvideo


:ip ifadd intf=videonetwork dest=ethvideo

:ip ifconfig intf=videonetwork group=lan linksensing=enabled

:ip ifattach intf=videonetwork

:ip ipadd intf=videonetwork addr=192.168.2.254 netmask=24 addroute=enabled







58/122

E-NIT-CTC-20050927-0004 v3.0


58

DHCP pools

Proceed as follows:

> Create a DHCP server pool for the video network:

DHCP relay forwarding entries

Proceed as follows:

> Enable configuration of the DHCP relay interface for the video network:

> Create DHCP relay forwarding entries. We need to create two forwarding entries:

The first forwarding entry will check the MAC address of the device in the DHCP request. If the MACaddress of the device matches the MAC address in the rule, it will trigger the Flexiport script and

move the MAC address of the device to the video VLAN. If the MAC address does not match the MACaddress in the rule the DHCP request will be forwarded to the default internal DHCP server of the

Thomson Gateway.

The second forwarding entry will forward a new DHCP request towards the internal video DHCPserver.

:dhcp server pool add name=video index=0

:dhcp server pool config name=video intf=videonetwork poolstart=192.168.2.64poolend=192.168.2.253 netmask=24 gateway=192.168.2.254 server=192.168.2.254primdns=192.168.2.254 leasetime=7200

:dhcp relay ifconfig intf=videonetwork relay=enabled

:dhcp relay add name=LocalNetwork_to_script

:dhcp relay modify name=LocalNetwork_to_script addr=127.0.0.1 giaddr=192.168.1.254intf=LocalNetwork

:dhcp relay add name=video_to_dhcp

:dhcp relay modify name=video_to_dhcp addr=127.0.0.1 giaddr=192.168.2.254intf=videonetwork

!These CLI commands apply to a residential device (500 or 700 series). In case you have abusiness device (600 series), use lan1 instead ofLocalNetwork.


59/122

E-NIT-CTC-20050927-0004 v3.0


59

DHCP rules

Proceed as follows:

> Create a DHCP rule for each STB and DHCP rules for the other LAN devices:


Flexiport script

Proceed as follows:



:dhcp rule add name=STB1 type=mac mac=00:0f:1f:a5:5b:b9

:dhcp rule add name=STB2 type=mac mac=00:0f:1f:b5:5a:a9

:dhcp rule add name=notSTB1 type=mac mac=!00:0f:1f:a5:5b:b9

:dhcp rule add name=notSTB2 type=mac mac=!00:0f:1f:b5:5a:a9

i In this scenario, we use the MAC address of the STBs to trigger the Flexiport script.

:dhcp relay ruleadd name=video_to_dhcp rulename=STB1

:dhcp relay ruleadd name=video_to_dhcp key=or rulename=STB2

:dhcp relay ruleadd name=LocalNetwork_to_127.0.0.1 rulename=notSTB1

:dhcp relay ruleadd name=LocalNetwork_to_127.0.0.1 key=and rulename=notSTB2

:dhcp relay ruleadd name=LocalNetwork_to_script rulename=STB1

:dhcp relay ruleadd name=LocalNetwork_to_script key=or rulename=STB2


:script add name=dhcr_video index=0 command="eth bridge dynvlan add hwaddr $1 vlan video dynamic enabled"


:dhcp relay modify name=LocalNetwork_to_script script=video





60/122

E-NIT-CTC-20050927-0004 v3.0


60

IGMP proxy

Proceed as follows:

> Enable the IGMP proxy to forward all multicast traffic from the WAN to the video VLAN:

> Configure each IP interface as an upstream or a downstream IP interface:

IGMP snooping

Proceed as follows:

> Enable IGMP snooping:

> It is recommended to enable Fast Immediate Leave and Explicit Host Tracking:


Proceed as follows:


:igmp proxy config state=enabled

:igmp proxy ifconfig intf=pppoe_data state=upstream

:igmp proxy ifconfig intf=ip_video state=upstream

:igmp proxy ifconfig intf=videonetwork state=downstream

:eth bridge igmpsnooping config state=enabled




Documents

AppNote_MulticastVideothomson