AppNote MulticastVideothomson

Thomson Gateways and Multicast Video
Date: Version: July 2007 v3.0
Abstract:
This application note provides technical information about multicast video and how this relates to the various devices in the Thomson Gateway family. In addition to a brief background on multicast 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 a configuration (i.e. the description of the used CLI commands) are presented. This application note is relevant to all Thomson Gateway devices that support port-to-PVC mapping, Flexiport, IGMP proxying and IGMP snooping:
Applicability:
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 its existing products. For more information on THOMSON's latest technological innovations, documents and software releases, visit us at http://www.thomson-broadband.com
Contents
1 2
2.1 2.2 2.3 2.4 2.5
Introduction to Multicast Video ................................................. 4 Internet Group Management Protocol (IGMP) ......................... 7
Setting Up a Multicast Group ......................................................................... 8 IGMP Versions............................................................................................... 12 IGMP Signalling ............................................................................................ 14 IGMP Proxying .............................................................................................. 18 IGMP Snooping ............................................................................................. 20
3
3.1 3.2 3.3
The Thomson Gateway and Flexiport ..................................... 23

Life before Flexiport...................................................................................... 24 Advantages of Flexiport ................................................................................ 26 The Flexiport Concept ................................................................................... 27
4
4.1
Wi-Fi MultiMedia (WMM).......................................................... 28

WMM in the Thomson Gateway .................................................................... 28
5
5.1 5.2 5.3 5.4 5.5 5.6
Multiple Virtual Channels ......................................................... 30

Bridged Internet and Bridged Multicast ........................................................ 31 Routed Internet and Bridged Multicast, Single STB...................................... 35 Routed Internet and Bridged Multicast, Multiple STBs................................. 41 Routed Internet and Routed Multicast, Single STB....................................... 47 Routed Internet and Routed Multicast, Multiple STBs.................................. 54 Routed Internet and Routed Multicast, IGMP-based ..................................... 62
6
6.1 6.2 6.3 6.4
Single Virtual Channel .............................................................. 67

Routed Internet and Bridged Multicast, Single STB...................................... 68 Routed Internet and Bridged Multicast, Multiple STBs................................. 73 Routed Internet and Routed Multicast, Single STB....................................... 79 Routed Internet and Routed Multicast, Multiple STBs.................................. 85
E-NIT-CTC-20050927-0004 v3.0
Contents
6.5 Routed Internet and Routed Multicast, IGMP-based ..................................... 92
7
7.1 7.2 7.3
Ethernet WAN Port for Multicast Video .................................. 96

Ethernet WAN Port, Routed Internet and Routed Multicast, Flexiport ......... 97 Ethernet WAN Port, Routed Internet and Routed Multicast, IGMP-based .. 104 Ethernet WAN Port on the Bridge, Routed Internet and Routed Multicast, IGMP and VLANs .................................................................................................. 109 AutoWAN, Routed Internet and Bridged Multicast ..................................... 115
7.4
E-NIT-CTC-20050927-0004 v3.0
Chapter 1
Introduction to Multicast Video
Introduction
From an end users point of view, multicast video over IP is 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 be compared 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 the frequency of the channel you would like to watch for broadcast TV. While broadcast TV channels are broadcast at all times to all subscribers, a multicast video stream is only forwarded 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. While a unicast video stream is dedicated to a single client, a multicast video stream is shared by many clients. 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 large number of duplicated unicast video streams. While unicast video streams can use both TCP and UDP as transport protocol, multicast streams can only use 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.
Differences between multicast video over IP and broadcast TV exist in network and traffic features:
> > >
Differences between multicast video and unicast video are:
> >
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 group address. Routers: A multicast router receives the multicast streams. The router forwards each multicast stream to its multicast peers that are member of the corresponding multicast group. This requires that the multicast peers 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 the data to display them to the end users.
E-NIT-CTC-20050927-0004 v3.0
Chapter 1
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 through 239.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
Packets that have one of these addresses as IP destination address, are never forwarded by a router. As a result, these packets do not travel outside the subnet.
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 through 01: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 multicast address are placed into the lower 23 bits of the MAC multicast address. This is depicted in the following illustration:
32 bits 28 bits
IP Multicast Address
1110
10101
10101101011010110101101
4 bits 5 bits fixed dropped
23 bits
MAC Multicast Address
1010110101101011010110101
10101101011010110101101
25 bits fixed 48 bits
23 bits
E-NIT-CTC-20050927-0004 v3.0
Chapter 1
The following illustration gives an example:

IP Multicast Address
1110 11111 11111110000000000000001 239.255.0.1 (binary) (decimal)
MAC Multicast Address
0000000100000000010111100
11111110000000000000001 01:00:5E:7F:00:01
(binary) (hexadecimal)
The upper 5 bits of the IP multicast group ID are dropped in this mapping. As a consequence, the resulting MAC multicast address is not unique. 32 different IP multicast addresses all map to the same MAC address.
E-NIT-CTC-20050927-0004 v3.0
Chapter 2
Internet Group Management Protocol (IGMP)
Introduction
When 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 group memberships 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 in the IP packet header.
i
Overview
Multicast Listener Discovery (MLD) is used by IPv6 systems and is derived from IGMPv2.
In this chapter, the following aspects of IGMP and their support in the Thomson Gateway are discussed:
Topic
2.1 Setting Up a Multicast Group 2.2 IGMP Versions 2.3 IGMP Signalling 2.4 IGMP Proxying 2.5 IGMP Snooping
Page
8 12 14 18 20
E-NIT-CTC-20050927-0004 v3.0
Chapter 2
2.1
Setting Up a Multicast Group
Introduction
This section describes how to set up a multicast group. As an example, the different steps of a particular scenario are listed as follows: 1 2 3 4 Initially, the only members of the multicast group are the video server and its peer router. One of the clients initiates an IGMP membership report. More IGMP signalling takes place. 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 to router 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.
C1 R2 Video Server
C2
R1 R3
S1
255.0.0.1 C3
R4 C4
Clients
Routers
Figure 1 Initial situation.
E-NIT-CTC-20050927-0004 v3.0
Chapter 2
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 such message does not exist within IGMP.
IGMP join 255.0.0.1
C1 R2 Video Server
C2
R1 R3 255.0.0.1
S1
C3
R4 C4
Clients
Routers
Figure 2 First IGMP membership report.
E-NIT-CTC-20050927-0004 v3.0
Chapter 2
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 multicast group 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 and client C3 initiates a new IGMP membership report towards router R3.
IGMP join 255.0.0.1 C1 R2 Video Server
IGMP join 255.0.0.1 C2 R1 R3 255.0.0.1 S1
C3
IGMP join 255.0.0.1
R4 C4
Clients
Routers
Figure 3 Additional IGMP messages.
E-NIT-CTC-20050927-0004 v3.0
10
Chapter 2
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.
255.0.0.1
C1 R2
255.0.0.1
Video Server
255.0.0.1 R1 R3 255.0.0.1 S1
C2
255.0.0.1 C3 255.0.0.1
R4 C4
Clients
Routers
Figure 4 Completed multicast group.
11
E-NIT-CTC-20050927-0004 v3.0
Chapter 2
2.2
IGMP Versions
Introduction
IGMP 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 of the 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 have members on the attached local networks. These messages are sent with an IP destination address equal to 224.0.0.1. Membership report: a host responds to a query message with a report message, reporting each multicast 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 does not 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 the network.
A hosts membership in the all-hosts group 224.0.0.1 is never reported.
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 attached network. 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 which multicast 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 address equal 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 actively communicate to the local multicast router its intention to leave the group. The router then sends out a group-specific query. If there are no replies, the router times out the group and stops forwarding the traffic. The IP destination address of these messages is 224.0.0.2. Version 1 membership report
In order to be compatible with IGMPv1, IGMPv2 also supports:
>
E-NIT-CTC-20050927-0004 v3.0
12
Chapter 2
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 SourceSpecific 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 group address (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 of packets sent to a specified group address, from any of a specified list of sources (group address=group address of interest, source fields=source addresses of interest).
>
Version 3 membership report: These messages are sent with an IP destination address equal to 224.0.0.22. Version 1 membership report Version 2 membership report Version 2 leave group
In order to be compatible with IGMPv1 and IGMPv2, IGMPv3 also supports:
> > >
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 in IGMPv2 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 version of IGMP report message detected on that downstream IP interface. Which 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.
13
E-NIT-CTC-20050927-0004 v3.0
Chapter 2
2.3
IGMP Signalling
Introduction
In 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 wants to receive the stream associated with this multicast group. Router R1 drops packets from multicast group 225.0.0.1. As router R2 does not have a source stream for multicast group 225.0.0.1, it requests the stream by messages typical of the multicast routing protocol in use towards router R1. A source for multicast group 225.0.0.1 is available at router R1. Router R1 forwards the stream to router R2. Router R2 forwards the stream to client C1. Client C2 sends an IGMP join request for multicast group 225.0.0.1 to router R2. At this time a source for multicast group 225.0.0.1 is available at router R2. Router R2 forwards the stream to both client C1 and client C2.
2 3 4 5
Client C2
Client C1
Router R2
Router R1
Server S1
225.0.0.1 IGMP join 225.0.0.1 IGMP join 225.0.0.1 225.0.0.1 225.0.0.1 225.0.0.1 IGMP join 225.0.0.1 225.0.0.1 225.0.0.1 225.0.0.1 225.0.0.1
Figure 5 Join request.
E-NIT-CTC-20050927-0004 v3.0
14
Chapter 2
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 the multicast 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 2 3 4 5 Client C1 is member of multicast group 225.0.0.1. Client C2 is member of multicast group 225.0.0.2. Router R2 sends a query to client C1 and client C2. These queries can be general or specific. Client C1 sends a response to report its membership of multicast group 225.0.0.1. Client C2 sends a response to report its membership of multicast group 225.0.0.2. Router R1 and router R2 exchange information via messages typical of the multicast routing protocol.
Client C 2
Client C1
Router R2
Router R 1
Server S 1
225.0.0.1 225.0.0.1 225.0.0.1 225.0.0.2 225.0.0.2 IGMP Query IGMP Query IGMP Resp. 225.0.0.1 IGMP Resp. 225.0.0.2 225.0.0.2
IGMP Query IGMP Resp. 225.0.0.1 IGMP Resp. 225.0.0.2
Figure 6 IGMP query and response.
15
E-NIT-CTC-20050927-0004 v3.0
Chapter 2
Leave request
Different types of leave requests are explained by the message flow in Figure 7. 1 2 3 4 5 Initially, client C1 and client C2 are member of multicast group 225.0.0.1. Client C2 sends a leave request for multicast group 225.0.0.1 to indicate that it no longer wishes to receive the video stream. Router R2 forwards the stream only to client C1. Client C1 sends a leave request for multicast group 225.0.0.1. Router R2 no longer forwards the stream. Before sending a leave request to router R1, router R2 sends a query to make sure it serves no members of multicast group 225.0.0.1. Router R1 and router R2 exchange information via messages typical of the multicast routing protocol.
Client C 2
Client C1
Router R2
Router R 1
Server S 1
225.0.0.1 225.0.0.1 225.0.0.1 225.0.0.1 IGMP Leave 225.0.0.1 225.0.0.1 225.0.0.1 225.0.0.1 IGMP Leave 225.0.0.1 IGMP Query IGMP Query IGMP Leave 225.0.0.1 225.0.0.1 225.0.0.1 225.0.0.1
Figure 7 Leave request.
E-NIT-CTC-20050927-0004 v3.0
16
Chapter 2
Zapping
Figure 8 shows how client C1 zaps from multicast group 225.0.0.1 to multicast group 225.0.0.2. 1 2 3 Initially, client C1 is member of multicast group 225.0.0.1 and client C2 is member of multicast group 225.0.0.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. 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.
Client C 2
Client C1
Router R2
Router R 1
Server S 1
225.0.0.1 225.0.0.1 225.0.0.1 225.0.0.2 225.0.0.2 225.0.0.2 225.0.0.1 225.0.0.1
IGMP Leave 225.0.0.1 IGMP Join 225.0.0.2 225.0.0.2 225.0.0.2
225.0.0.2 225.0.0.2
Figure 8 IGMP zapping.
17
E-NIT-CTC-20050927-0004 v3.0
Chapter 2
2.4
IGMP Proxying
Introduction
IGMP 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 the upstream interface.
Membership database
The IGMP proxy acts as an IGMP router on each downstream interface. As a result, the proxy has a separate set 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 membership database changes. Thanks to those simplifications, the IGMP proxy does not have to support a 'real' multicast routing 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 not necessarily 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.
E-NIT-CTC-20050927-0004 v3.0
18
Chapter 2
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 it already has a subscription to this multicast group address. If it does not have a subscription present in its membership 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 its downstream 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, nor will 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's done via SDP or a web-based application which is not foreseen on the Thomson Gateway.
Multicast Router
Multicast Routing Database
IGMPv3 Server
IGMPv3 Host
Video Server
LAN
Subscription Database
IGMP Proxy
IGMP proxying is supported by the Thomson Gateway since Release 5.4.
19
E-NIT-CTC-20050927-0004 v3.0
Chapter 2
2.5
IGMP Snooping
No use of IGMP snooping

If 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 parts of the network where not a single host wants to receive the traffic. This results in an inefficient use of the network bandwidth.
Use of IGMP snooping

If IGMP snooping is used, a Layer 2 switch listens to the Layer 3 IGMP messages to determine which switch interfaces 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 the message 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 that hosts switch interface from the group.
A Layer 2 switch can make intelligent multicast forwarding decisions by examining the content of the Layer 3 IP header of each data frame. No traffic is sent on parts of the network where no host has expressed interest in receiving packets addressed to the group address. As a result, the amount of multicast traffic can be significantly reduced. IGMP snooping violates the strict separation of functionality between the different communication layers in the OSI (Open Systems Interconnection) model.
Layer 2 switches that support IGMP snooping use information of Layer 3 (IP) to make forwarding decisions at Layer 2 (Ethernet).
E-NIT-CTC-20050927-0004 v3.0
20
Chapter 2
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 multicast receivers 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 B
Host A
Host C
L2 Switch L3 Router
21
E-NIT-CTC-20050927-0004 v3.0
Chapter 2
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:
Host B
Host A
Host C
L2 Switch L3 Router
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 allow multicast 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 the reported 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 reported multicast stream is still allowed to that specific bridge port for a given amount of time (default value is 5 s). IGMP query messages: when an IGMP query message is received on a bridge port, IGMP report and leave messages are allowed to that specific bridge port for a given amount of time (default value is 180 s).
IGMP snooping is supported by the Thomson Gateway since Release 6.1.9.
E-NIT-CTC-20050927-0004 v3.0
22
Chapter 3
The Thomson Gateway and Flexiport
Introduction
This 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 were connected to the correct Ethernet ports. The chance of errors was big, resulting in helpdesk calls etc. With the use 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 on the Vendor Code Identifier (vci) or MAC address (mac) sent out with the DHCP request. A maximum of four devices can simultaneously make use of Flexiport on a Thomson Gateway. The MAC 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 MAC addresses.
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 video dynamic enabled" By default the option dynamic is disabled so the MAC address will be saved to the database.
Overview
In this chapter, the following aspects of Flexiport and their support in the Thomson Gateway are discussed:
Topic
3.1 Life before Flexiport 3.2 Advantages of Flexiport 3.3 The Flexiport Concept
Page
24 26 27
23
E-NIT-CTC-20050927-0004 v3.0
Chapter 3
3.1
Life before Flexiport
Port-to-PVC mapping
As 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)
192.168.1.64
192.168.1.65
192.168.1.66 PVC1 PVC2 PVC3 IP Phone xDSL Network
Set Top Box with Television
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.
Port-to-PVC mapping is supported by the Thomson Gateway since Release 5.3.0.
E-NIT-CTC-20050927-0004 v3.0
24
Chapter 3
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
1 2 1 ON/OFF Reset
4 3 4
xDSL Network
DSL
Ethernet
Data Traffic IP Phone Traffic Set Top Box Traffic
Figure 10 Port connection.
25
E-NIT-CTC-20050927-0004 v3.0
Chapter 3
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 be altered without having to restart the device. It was important that the correct devices were connected to the correct Ethernet ports. Another restriction was that, once a port-to-PVC map was created, forwarding was limited to bridging in all groups 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 be mapped to the PVC offering the services that are needed. For example, a certain type of STB can be recognized 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 proper PVC 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 to IGMP 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 larger distances 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. See 4 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 both MAC addresses and VCI. Both of them use different notations: MAC address:
:dhcp rule add name=STB type=mac mac=00:0f:1f:*:*:*
Here we use * as a wildcard, so any device with a MAC address starting with 00:0f:1f will be placed in the dynvlan membership database. VCI code:
:dhcp rule add name VOIP type vci vci ST20 match as_substring
Here, we only put part of the vci code in the rule and add the option match as_substring. This will put the 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.
E-NIT-CTC-20050927-0004 v3.0
26
Chapter 3
3.3
The Flexiport Concept
Figure 11 shows the concept of Flexiport.
Ethernet port1 Internet
Ethernet port 2 BRAS
Ethernet port 3
NATed data traffic Bridged video traffic
Ethernet port 4 DHCP Server Video Server
Video Network
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 2 3 4 5 6 7 The Thomson Gateway is up and running, PCs are surfing the Internet through one PVC. The STB is added to one of the ports of the Thomson Gateway and sends out a DHCP discover message. The DHCP relay will identify the STB by its Vendor Class ID (vci) or MAC address and will move the STBs MAC address into a second VLAN. The STB will re-send the DHCP discover message, but now as member of the second VLAN. The STB will now receive an IP address from the video DHCP server and can start receiving video. The STBs MAC address will be saved, and the next time the Thomson Gateway reboots, it will remember to which VLAN the STB belongs.
i i
When the STB reboots, it will send a DHCP request and restart the procedure from step 2. The Flexiport concept can also be used for wired and wireless IP phones. This way the data from the IP phone is bridged to the Voice PVC while other wireless devices can still surf the web over the ETHoA connection. Flexiport is supported by the Thomson Gateway since Release 5.3.2 for a single PVC and since Release 5.4 for multiple PVCs.
27
E-NIT-CTC-20050927-0004 v3.0
Chapter 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 is inadequate 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 have WMM 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 access categories correspond to the following Class Selectors when using DSCP:
> > > >
Voice - CS7 Video - CS5 Best Effort - CS0 Background - CS1
E-NIT-CTC-20050927-0004 v3.0
28
Chapter 4
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:
:wireless qos config mode=wmm
To disable WMM, proceed as follows:

:wireless qos config mode=disabled
By default, WMM is enabled. In fact, there is no reason to disable WMM.
29
E-NIT-CTC-20050927-0004 v3.0
Chapter 5
Multiple Virtual Channels
Introduction
In 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:
:system reset factory=yes proceed=yes
>
Set the value of the variable SESSIONTIMEOUT to zero. As a result, the TELNET session with the device never times out:
:env set var=SESSIONTIMEOUT value=0
>
Flush all factory default interfaces and settings so we can start from a clean situation:
:ppp relay flush :ppp flush :eth flush :atm flush :atm phonebook flush :ip ipdelete addr=10.0.0.138 :wireless ifconfig state disabled
Overview
In this chapter, the following use cases with multiple virtual channels are described:
Topic
5.1 Bridged Internet and Bridged Multicast 5.2 Routed Internet and Bridged Multicast, Single STB 5.3 Routed Internet and Bridged Multicast, Multiple STBs 5.4 Routed Internet and Routed Multicast, Single STB 5.5 Routed Internet and Routed Multicast, Multiple STBs 5.6 Routed Internet and Routed Multicast, IGMP-based
Page
31 35 41 47 54 62
E-NIT-CTC-20050927-0004 v3.0
30
Chapter 5
5.1 5.1.1
Bridged Internet and Bridged Multicast Use Case
Scenario
In this scenario, we configure the Thomson Gateway as bridge with multiple PVCs. We use one PVC for normal 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:
Internet Internet IP BRAS
Bridged Connection Bridged Connection
DSLAM
DHCP Server Video Network IP Video Server
Video Network
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.
31
E-NIT-CTC-20050927-0004 v3.0
Chapter 5
5.1.2
Configuration
In this section, we describe the configuration of the Thomson Gateway to set up this scenario. The configuration has been created using the CLI.
Data PVC and ATM interface

Proceed as follows:
>
Create a phonebook entry for the data PVC:

:atm phonebook add name=pvc_data addr=8.35
>
Create the data ATM interface:

:atm ifadd intf=atm_data :atm ifconfig intf=atm_data dest=pvc_data encaps=llc ulp=mac :atm ifattach intf=atm_data
Video PVC and ATM interface

Proceed as follows:
>
Create a phonebook entry for the video PVC:

:atm phonebook add name=pvc_video addr=0.38
>
Create the video ATM interface:

:atm ifadd intf=atm_video :atm ifconfig intf=atm_video dest=pvc_video encaps=llc ulp=mac :atm ifattach intf=atm_video
Video VLAN
Proceed as follows:
>
Enable the use of VLANs:

:eth bridge config vlan=enabled
>
Create a video VLAN:

:eth vlan add name=video vid=2
E-NIT-CTC-20050927-0004 v3.0
32
Chapter 5
Ethernet interfaces on the bridge

Proceed as follows:
>
Create an Ethernet WAN interface on the bridge connected to the data ATM interface:
:eth bridge ifadd intf=br_data :eth bridge ifconfig intf=br_data dest=atm_data :eth bridge ifattach intf=br_data
>
Create an Ethernet WAN interface on the bridge connected to the video ATM interface:
:eth bridge ifadd intf=br_video :eth bridge ifconfig intf=br_video dest=atm_video :eth bridge ifattach intf=br_video
Port-to-PVC mapping
Proceed as follows:
>
Place the newly created br_video Ethernet WAN interface and Ethernet LAN interface four in the video VLAN:
:eth :eth :eth :eth :eth bridge bridge bridge bridge bridge vlan vlan vlan vlan vlan ifadd intf=br_video name=video ifdelete intf=br_video name=default ifadd intf=ethport4 name=video ifdelete intf=ethport4 name=default ifadd intf=OBC name=video
Save the configuration

Proceed as follows:
>
Save the configuration:

:saveall
33
E-NIT-CTC-20050927-0004 v3.0
Chapter 5
5.1.3
Result
The resulting configuration of the Thomson Gateway is depicted in the following illustration:
OBC default (vid=1) Bridge video (vid=2)
ethport
... br_video
br_data
ATM atm_data
ATM atm_video
PVC pvc_data
8.35
PVC pvc_video
0.38
PC
STB
E-NIT-CTC-20050927-0004 v3.0
34
Chapter 5
5.2 5.2.1
Routed Internet and Bridged Multicast, Single STB 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 traffic via 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). The scenario is depicted in the following illustration:
Internet Private IP BRAS PPPoE Connection Bridged Connection
NATed Internet IP
DSLAM
DHCP Server Video Network IP Video Server
Video Network
Figure 13 The Thomson Gateway with multiple PVCs, one routed and one bridged.
Mechanisms
> >
VLANs are used. Flexiport is used, so that the MAC address of the STB is automatically mapped to the video VLAN.
35
E-NIT-CTC-20050927-0004 v3.0
Chapter 5
5.2.2
Configuration

Proceed as follows:
>

>

Data Ethernet interface

Proceed as follows:
>
Create the data Ethernet interface connected to the data ATM interface:
:eth ifadd intf=eth_data :eth ifconfig intf=eth_data dest=atm_data :eth ifattach intf=eth_data
PPPoE interface
Proceed as follows:
>
Create the PPPoE interface connected to the data Ethernet interface:

:ppp ifadd intf=pppoe_data :ppp ifconfig intf=pppoe_data dest=eth_data user=user@inet password=pwdinet
>
Enable NAT on the PPPoE interface:

:nat ifconfig intf=pppoe_data translation=enabled
>
Add a default route for Internet traffic:

:ppp rtadd dst=0.0.0.0 dstmsk=0.0.0.0 intf=pppoe_data :ppp ifattach intf=pppoe_data
E-NIT-CTC-20050927-0004 v3.0
36
Chapter 5

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:
:eth bridge ifadd intf=eth_video :eth bridge ifconfig intf=eth_video dest=atm_video :eth bridge ifattach intf=eth_video
>
Place this Ethernet interface in the video VLAN:

:eth bridge vlan ifadd intf=eth_video name=video :eth bridge vlan ifdelete intf=eth_video name=default :eth bridge vlan ifadd intf=OBC name=video
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 :eth :eth :eth :eth bridge bridge bridge bridge bridge ifconfig intf=ethport1 dynvlan=enabled ifconfig intf=ethport2 dynvlan=enabled ifconfig intf=ethport3 dynvlan=enabled ifconfig intf=ethport4 dynvlan=enabled dynvlan config timeout=10000
37
E-NIT-CTC-20050927-0004 v3.0
Chapter 5
DHCP relay forwarding entry

Proceed as follows:
>
Create 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
!
DHCP rules
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 of LocalNetwork.
Proceed as follows:
>
Create a DHCP rule for the STB and a DHCP rule for the other LAN devices:
: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.
Assign the DHCP rules to the DHCP relay forwarding entries:

:dhcp relay ruleadd name=video_to_DHCP rulename=STB :dhcp relay ruleadd name=Localnetwork_to_127.0.0.1 rulename=notSTB
!
Flexiport script
Proceed as follows:
>
Create a Flexiport script to move the MAC address of the STB to the video VLAN:
:script add name=dhcr_video index=0 command="eth bridge dynvlan add hwaddr $1 vlan video dynamic disabled"
!
>
The script must start with dhcr_ in order to work.
Assign the script to a DHCP relay forwarding entry:

:dhcp relay modify name=video_to_DHCP script=video
Here, the name of the script must be entered without the dhcr_ prefix
E-NIT-CTC-20050927-0004 v3.0
38
Chapter 5

Proceed as follows:
>

:saveall
39
E-NIT-CTC-20050927-0004 v3.0
Chapter 5
5.2.3
Result
DHCP Server
LAN_private 192.168.1.[64-253]
DHCP Relay
Router
192.168.1.254
public IP address
IP LocalNetwork
PPP pppoe_data
ETH OBC default (vid=1) Bridge video (vid=2)
ETH eth_data
Flexiport 2 3 4
ethport
...
eth_video
ATM atm_video
ATM atm_data
PVC pvc_video
0.38
PVC pvc_data
8.35
PC
STB
This configuration has no STB-to-LAN connectivity.
E-NIT-CTC-20050927-0004 v3.0
40
Chapter 5
5.3 5.3.1
Routed Internet and Bridged Multicast, Multiple STBs 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 traffic via a routed PPPoE Internet connection. The other PVC is used for bridged multicast traffic. We consider the scenario with multiple Set Top Boxes (STBs). The scenario is depicted in the following illustration:
Internet Private IP BRAS PPPoE Connection Bridged Connection
NATed Internet IP
DSLAM
Video Network IP
DHCP Server Video Server
Video Network
Figure 14 The Thomson Gateway with multiple PVCs, one routed and one bridged.
Mechanisms
> > >
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.
41
E-NIT-CTC-20050927-0004 v3.0
Chapter 5
5.3.2
Configuration

Proceed as follows:
>

>


Proceed as follows:
>
PPPoE interface
Proceed as follows:
>

>

>

E-NIT-CTC-20050927-0004 v3.0
42
Chapter 5

Proceed as follows:
>

>

Video VLAN
Proceed as follows:
>

>


Proceed as follows:
>
Create an Ethernet interface on the bridge connected to the video ATM interface:
:eth bridge ifadd intf=eth_video :eth bridge ifconfig intf=eth_video dest=atm_video :eth bridge ifattach intf=eth_video
>
Place this Ethernet interface in the video VLAN:

:eth bridge vlan ifadd intf=eth_video name=video :eth bridge vlan ifdelete intf=eth_video name=default :eth bridge vlan ifadd intf=OBC name=video

Proceed as follows:
>

43
E-NIT-CTC-20050927-0004 v3.0
Chapter 5

Proceed as follows:
>

:dhcp relay add name=video_to_DHCP :dhcp relay modify name=video_to_DHCP addr=127.0.0.1 intf=LocalNetwork
!
DHCP rules
Proceed as follows:
>
Create a DHCP rule for each STB and DHCP rules for the other LAN devices:
:dhcp :dhcp :dhcp :dhcp rule rule rule rule add add add add name=STB1 type=mac mac=00:0f:1f:a5:5b:b9 name=STB2 type=mac mac=00:0f:1f:b5:5a:a9 name=notSTB1 type=mac mac=!00:0f:1f:a5:5b:b9 name=notSTB2 type=mac mac=!00:0f:1f:b5:5a:a9
i
>
:dhcp :dhcp :dhcp :dhcp
In this example, we use the MAC address of the STBs to trigger the Flexiport script.

relay relay relay relay ruleadd ruleadd ruleadd ruleadd name=video_to_DHCP rulename=STB1 name=video_to_DHCP key=or rulename=STB2 name=Localnetwork_to_127.0.0.1 rulename=notSTB1 name=Localnetwork_to_127.0.0.1 key=and rulename=notSTB2
!
Flexiport script
Proceed as follows:
>
Create a Flexiport script to move the MAC address of the STBs to the video VLAN:
!
>

:dhcp relay modify name=video_to_DHCP script=video
Here, the name of the script must be entered without the dhcr_ prefix
E-NIT-CTC-20050927-0004 v3.0
44
Chapter 5
IGMP snooping
Proceed as follows:
>
Enable IGMP snooping:

:eth :eth :eth :eth :eth bridge bridge bridge bridge bridge igmpsnooping config state=enabled ifconfig intf=ethport1 igmpsnooping=enabled ifconfig intf=ethport2 igmpsnooping=enabled ifconfig intf=ethport3 igmpsnooping=enabled ifconfig intf=ethport4 igmpsnooping=enabled
i
>
:eth :eth :eth :eth
By default, IGMP snooping is enabled on the bridge and also on each individual bridge interface.
It is recommended to enable Fast Immediate Leave and Explicit Host Tracking:

bridge bridge bridge bridge igmpsnooping igmpsnooping igmpsnooping igmpsnooping ifconfig ifconfig ifconfig ifconfig intf=ethport1 intf=ethport2 intf=ethport3 intf=ethport4 fastleave=enabled fastleave=enabled fastleave=enabled fastleave=enabled exptrack=enabled exptrack=enabled exptrack=enabled exptrack=enabled

Proceed as follows:
>

:saveall
45
E-NIT-CTC-20050927-0004 v3.0
Chapter 5
5.3.3
Result
DHCP Server
LAN_private 192.168.1.[64-253]
DHCP Relay
Router
192.168.1.254
public IP address
IP LocalNetwork
PPP pppoe_data
ETH OBC default (vid=1) Bridge video (vid=2) IGMP snooping
ETH eth_data
Flexiport 2 3 4
ethport
...
eth_video
ATM atm_video
ATM atm_data
PVC pvc_video
0.38
PVC pvc_data
8.35
PC
STB1
STB2
E-NIT-CTC-20050927-0004 v3.0
46
Chapter 5
5.4 5.4.1
Routed Internet and Routed Multicast, Single STB 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 traffic via 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). The scenario is depicted in the following illustration:
Internet Private IP from DHCP Pool BRAS PPPoE Connection Video Connection
NATed IP NATed IP
DSLAM
Private IP from DHCP Pool Video Network
Video Server
Figure 15 The Thomson Gateway with multiple PVCs, all routed.
Mechanisms
> > >
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.
47
E-NIT-CTC-20050927-0004 v3.0
Chapter 5
5.4.2
Configuration

Proceed as follows:
>

>


Proceed as follows:
>
PPPoE interface
Proceed as follows:
>

>

>

E-NIT-CTC-20050927-0004 v3.0
48
Chapter 5

Proceed as follows:
>

>

Video Ethernet interface

Proceed as follows:
>
Create the video Ethernet interface connected to the video ATM interface:
:eth ifadd intf=eth_video :eth ifconfig intf=eth_video dest=atm_video :eth ifattach intf=eth_video
IP interface
Proceed as follows:
>
Create the IP interface connected to the video Ethernet interface:

:ip ifadd intf=ip_video dest=eth_video :ip ifattach intf=ip_video
>
Enable NAT on the IP interface:

:nat ifconfig intf=ip_video translation=enabled
Video VLAN
Proceed as follows:
>

:eth bridge config vlan=enabled filter=none
i
>
We 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, while broadcasts from the LAN to the WAN are passed through.

49
E-NIT-CTC-20050927-0004 v3.0
Chapter 5
Video Ethernet LAN interface

Proceed as follows:
>
Create the video Ethernet LAN interface and place it in the video VLAN:
:eth :eth :eth :eth ifadd intf=ethvideo ifconfig intf=ethvideo dest=bridge vlan=video ifattach intf=ethvideo bridge vlan ifadd intf=OBC name=video
IP LAN interface
Proceed as follows:
>
Create the IP LAN interface connected to the video Ethernet LAN interface:
:ip ifadd intf=videonetwork dest=ethvideo :ip ifconfig intf=videonetwork group=lan linksensing=enabled :ip ifattach intf=videonetwork
>
Assign an IP address to the IP LAN interface:

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

Proceed as follows:
>

DHCP pools
Proceed as follows:
>
Create a DHCP server pool for the video network:

:dhcp server pool add name=video index=0 :dhcp server pool config name=video intf=videonetwork poolstart=192.168.2.64 poolend=192.168.2.253 netmask=24 gateway=192.168.2.254 server=192.168.2.254 primdns=192.168.2.254 leasetime=7200
E-NIT-CTC-20050927-0004 v3.0
50
Chapter 5
DHCP relay forwarding entries

Proceed as follows:
>
Enable configuration of the DHCP relay interface for the video network:
:dhcp relay ifconfig intf=videonetwork relay=enabled
>
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 and move 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 the Thomson Gateway.
:dhcp relay add name=LocalNetwork_to_script :dhcp relay modify name=LocalNetwork_to_script addr=127.0.0.1 giaddr=192.168.1.254 intf=LocalNetwork
The second forwarding entry will forward a new DHCP request towards the internal video DHCP server.
:dhcp relay add name=video_to_dhcp :dhcp relay modify name=video_to_dhcp addr=127.0.0.1 giaddr=192.168.2.254 intf=videonetwork
!
DHCP rules
These CLI commands apply to a residential device (500 or 700 series). In case you have a business device (600 series), use lan1 instead of LocalNetwork.
Proceed as follows:
>
: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
51
E-NIT-CTC-20050927-0004 v3.0
Chapter 5
Flexiport script
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
Here, the name of the script must be entered without the dhcr_ prefix 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 of LocalNetwork.
Proceed as follows:
>
Enable the IGMP proxy to forward all multicast traffic from the WAN to the video VLAN:
:igmp proxy config state=enabled
>
Configure each IP interface as an upstream or a downstream IP interface:

:igmp proxy ifconfig intf=pppoe_data state=upstream :igmp proxy ifconfig intf=ip_video state=upstream :igmp proxy ifconfig intf=videonetwork state=downstream

Proceed as follows:
>

:saveall
E-NIT-CTC-20050927-0004 v3.0
52
Chapter 5
5.4.3
Result
DHCP Server
video 192.168.2.[64-253]
DHCP Server
LAN_private 192.168.1.[64-253]
DHCP Relay
Router IGMP Proxy DOWN

192.168.1.254
DOWN
192.168.2.254
UP
public IP address
UP
public IP address
IP LocalNetwork
IP videonetwork
IP ip_video
PPP pppoe_data
ETH OBC default (vid=1) Bridge
ETH ethvideo
ETH eth_video
ETH eth_data
video (vid=2)
Flexiport 2 3 4
ethport
...
ATM atm_video
ATM atm_data
PVC pvc_video
0.38
PVC pvc_data
8.35
PC
STB
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.
53
E-NIT-CTC-20050927-0004 v3.0
Chapter 5
5.5 5.5.1
Routed Internet and Routed Multicast, Multiple STBs 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 traffic via a routed PPPoE Internet connection. The other PVC is used for routed multicast traffic. We consider the scenario with multiple Set Top Boxes (STBs). The scenario is depicted in the following illustration:
Internet Private IP from DHCP Pool 1 BRAS PPPoE Connection Video Connection
NATed IP NATed IP
DSLAM
Video Server Private IP from DHCP Pool 2 Video Network
Mechanisms
> > > >
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.
E-NIT-CTC-20050927-0004 v3.0
54
Chapter 5
5.5.2
Configuration

Proceed as follows:
>

>


Proceed as follows:
>
PPPoE interface
Proceed as follows:
>

>

>

55
E-NIT-CTC-20050927-0004 v3.0
Chapter 5

Proceed as follows:
>

>


Proceed as follows:
>
IP interface
Proceed as follows:
>

>

E-NIT-CTC-20050927-0004 v3.0
56
Chapter 5
Video VLAN
Proceed as follows:
>

i
>


Proceed as follows:
>
:eth :eth :eth :eth ifadd intf=ethvideo ifconfig intf=ethvideo dest=bridge vlan=video ifattach intf=ethvideo bridge vlan ifadd intf=OBC name=video
IP LAN interface
Proceed as follows:
>
Create the IP LAN interface connected to the video Ethernet LAN interface:
:ip ifadd intf=videonetwork dest=ethvideo :ip ifconfig intf=videonetwork group=lan linksensing=enabled :ip ifattach intf=videonetwork
>
Assign an IP address to the IP LAN interface:


Proceed as follows:
>

57
E-NIT-CTC-20050927-0004 v3.0
Chapter 5
DHCP pools
Proceed as follows:
>


Proceed as follows:
>
>
E-NIT-CTC-20050927-0004 v3.0
58
Chapter 5
DHCP rules
Proceed as follows:
>
:dhcp :dhcp :dhcp :dhcp rule rule rule rule add add add add name=STB1 type=mac mac=00:0f:1f:a5:5b:b9 name=STB2 type=mac mac=00:0f:1f:b5:5a:a9 name=notSTB1 type=mac mac=!00:0f:1f:a5:5b:b9 name=notSTB2 type=mac mac=!00:0f:1f:b5:5a:a9
i
>
:dhcp :dhcp :dhcp :dhcp :dhcp :dhcp
In this scenario, we use the MAC address of the STBs to trigger the Flexiport script.

relay relay relay relay relay relay ruleadd ruleadd ruleadd ruleadd ruleadd ruleadd name=video_to_dhcp rulename=STB1 name=video_to_dhcp key=or rulename=STB2 name=LocalNetwork_to_127.0.0.1 rulename=notSTB1 name=LocalNetwork_to_127.0.0.1 key=and rulename=notSTB2 name=LocalNetwork_to_script rulename=STB1 name=LocalNetwork_to_script key=or rulename=STB2
!
Flexiport script
Proceed as follows:
>
!
>

! !
Here, the name of the script must be entered without the dhcr_ prefix 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 of LocalNetwork.
59
E-NIT-CTC-20050927-0004 v3.0
Chapter 5
IGMP proxy
Proceed as follows:
>
>

:igmp proxy ifconfig intf=pppoe_data state=upstream :igmp proxy ifconfig intf=ip_video state=upstream :igmp proxy ifconfig intf=videonetwork state=downstream
IGMP snooping
Proceed as follows:
>

i
>
:eth :eth :eth :eth


Proceed as follows:
>

:saveall
E-NIT-CTC-20050927-0004 v3.0
60
Chapter 5
5.5.3
Result
DHCP Server
video 192.168.2.[64-253]
DHCP Server
LAN_private 192.168.1.[64-253]
DHCP Relay

192.168.1.254
DOWN
192.168.2.254
UP
public IP address
UP
public IP address
IP LocalNetwork
IP videonetwork
IP ip_video
PPP pppoe_data
ETH ethvideo
ETH eth_video
ETH eth_data
video (vid=2) IGMP snooping
Flexiport 2 3 4
ethport
...
ATM atm_video
ATM atm_data
PVC pvc_video
0.38
PVC pvc_data
8.35
PC
STB1
STB2
61
E-NIT-CTC-20050927-0004 v3.0
Chapter 5
5.6 5.6.1
Routed Internet and Routed Multicast, IGMP-based 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 traffic via a routed PPPoE Internet connection. The other PVC is used for routed multicast traffic. The scenario is depicted in the following illustration:
Internet Private IP from DHCP Pool BRAS PPPoE Connection Video Connection
NATed IP NATed IP
DSLAM
Private IP from DHCP Pool Video Network
Video Server
i
Mechanisms
In this scenario, the number of STBs is not important. The configuration of the Thomson Gateway is the same for the scenario with a single STB and the scenario with multiple STBs.
> >
IGMP proxying is used. IGMP snooping is used to avoid flooding of multicast streams on other ports of the bridge.
E-NIT-CTC-20050927-0004 v3.0
62
Chapter 5
5.6.2
Configuration

Proceed as follows:
>

>


Proceed as follows:
>
PPPoE interface
Proceed as follows:
>

>

>

63
E-NIT-CTC-20050927-0004 v3.0
Chapter 5

Proceed as follows:
>

>


Proceed as follows:
>
IP interface
Proceed as follows:
>

>

IGMP proxy
Proceed as follows:
>
Enable the IGMP proxy to forward all multicast traffic from the WAN to the default VLAN:
>

:igmp proxy ifconfig intf=pppoe_data state=upstream :igmp proxy ifconfig intf=ip_video state=upstream
E-NIT-CTC-20050927-0004 v3.0
64
Chapter 5
IGMP snooping
Proceed as follows:
>

i
>
:eth :eth :eth :eth


Proceed as follows:
>

:saveall
65
E-NIT-CTC-20050927-0004 v3.0
Chapter 5
5.6.3
Result
DHCP Server
LAN_private 192.168.1.[64-253]
DHCP Relay

192.168.1.254
UP
public IP address
UP
public IP address
IP LocalNetwork
IP ip_video
PPP pppoe_data
ETH OBC default (vid=1) IGMP snooping Bridge
ETH eth_video
ETH eth_data
ethport
...
ATM atm_video
ATM atm_data
PVC pvc_video
0.38
PVC pvc_data
8.35
PC
STB
This configuration has full LAN-to-LAN connectivity. This configuration cannot cope with a NAT unfriendly STB.
E-NIT-CTC-20050927-0004 v3.0
66
Chapter 6
Single Virtual Channel
Introduction
In this chapter, we describe several use cases with a single virtual channel. This PVC will be used for both Internet traffic and multicast video. For every use case, we present:
> > >
Before we start
>
Reset the Thomson Gateway to the factory defaults and restart the device:
>
>
Overview
In this chapter, the following use cases with a single virtual channel are described:
Topic
6.1 Routed Internet and Bridged Multicast, Single STB 6.2 Routed Internet and Bridged Multicast, Multiple STBs 6.3 Routed Internet and Routed Multicast, Single STB 6.4 Routed Internet and Routed Multicast, Multiple STBs 6.5 Routed Internet and Routed Multicast, IGMP-based
Page
68 73 79 85 92
67
E-NIT-CTC-20050927-0004 v3.0
Chapter 6
6.1 6.1.1
Routed Internet and Bridged Multicast, Single STB Use Case
Scenario
In this scenario we configure the Thomson Gateway with a single PVC. We make use of one PVC for data traffic and multicast traffic. This connection uses a routed PPPoE connection for the Internet traffic and a bridged connection for multicast traffic. We consider the scenario with a single Set Top Box (STB). The scenario is depicted in the following illustration:
Internet Private IP
NATed Internet IP
PPPoE Connection
Bridged Connection
BRAS
Video Network IP DHCP Server Video Server Video Network
Figure 18 The Thomson Gateway with one PVC for routed Internet and bridged multicast.
Mechanisms
> >
VLANs are used. Flexiport is used, so that the MAC address of the STB is automatically mapped to the video VLAN.
E-NIT-CTC-20050927-0004 v3.0
68
Chapter 6
6.1.2
Configuration
PVC and ATM interface

Proceed as follows:
>
Create a phonebook entry for the PVC:

:atm phonebook add name=pvc1 addr=8.35
>
Create the ATM interface:

:atm ifadd intf=atm1 :atm ifconfig intf=atm1 dest=pvc1 encaps=llc ulp=mac :atm ifattach intf=atm1
Video VLAN
Proceed as follows:
>

i
>


Proceed as follows:
>
Create an Ethernet WAN interface on the bridge connected to the ATM interface:
:eth bridge ifadd intf=eth_br :eth bridge ifconfig intf=eth_br dest=atm1 :eth bridge ifattach intf=eth_br
>
Place this Ethernet WAN interface in the video VLAN:

:eth bridge vlan ifadd intf=eth_br name=video :eth bridge vlan ifdelete intf=eth_br name=default :eth bridge vlan ifadd intf=OBC name=video
69
E-NIT-CTC-20050927-0004 v3.0
Chapter 6
Ethernet interface
Proceed as follows:
>
Create the Ethernet interface and place it in the video VLAN:

:eth ifadd intf=eth_rt :eth ifconfig intf=eth_rt dest=bridge vlan=video :eth ifattach intf=eth_rt
PPPoE interface
Proceed as follows:
>
Create the PPPoE interface connected to the Ethernet interface and disable multicast traffic on this connection:
:ppp ifadd intf=pppoe :ppp ifconfig intf=pppoe dest=eth_rt user=user@inet password=pwdinet
>

:nat ifconfig intf=pppoe translation=enabled
>

:ppp rtadd intf=pppoe dst=0.0.0.0/0 :ppp ifattach intf=pppoe

Proceed as follows:
>


Proceed as follows:
>

:dhcp relay add name=video_to_dhcp :dhcp relay modify name=video_to_dhcp addr=127.0.0.1 intf=LocalNetwork
E-NIT-CTC-20050927-0004 v3.0
70
Chapter 6
DHCP rules
Proceed as follows:
>
: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
!
Flexiport script
Proceed as follows:
>
!
>

:dhcp relay modify name=video_to_dhcp script=video
Here the name of the script must be entered without the dhcr_ prefix.

Proceed as follows:
>

:saveall
71
E-NIT-CTC-20050927-0004 v3.0
Chapter 6
6.1.3
Result
DHCP Server
LAN_private 192.168.1.[64-253]
DHCP Relay
Router
192.168.1.254
IP Local Network
PPP pppoe
ETH OBC default (vid=1) Bridge video (vid=2)
ETH eth_rt
Flexiport 2 3 4
ethport
...
eth_br
ATM atm1
PVC pvc1
8.35
PC
STB
E-NIT-CTC-20050927-0004 v3.0
72
Chapter 6
6.2 6.2.1
Routed Internet and Bridged Multicast, Multiple STBs Use Case
Scenario
In this scenario we configure the Thomson Gateway with a single PVC. We make use of one PVC for data traffic and multicast traffic. This connection uses a routed PPPoE connection for the Internet traffic and a bridged connection for multicast traffic. We consider the scenario with multiple Set Top Boxes (STBs). The scenario is depicted in the following illustration:
Internet Private IP
NATed Internet IP
PPPoE Connection
Bridged Connection
BRAS
Video Network IP DHCP Server Video Server Video Network
Figure 19 The Thomson Gateway with one PVC for routed Internet and bridged multicast.
Mechanisms
To realize 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. IGMP snooping is used to avoid flooding of video streams on other ports of the bridge.
73
E-NIT-CTC-20050927-0004 v3.0
Chapter 6
6.2.2
Configuration

Proceed as follows:
>

>

Video VLAN
Proceed as follows:
>

i
>


Proceed as follows:
>
Create an Ethernet WAN interface on the bridge connected to the ATM interface:
:eth bridge ifadd intf=eth_br :eth bridge ifconfig intf=eth_br dest=atm1 :eth bridge ifattach intf=eth_br
>
Place this Ethernet WAN interface in the video VLAN:

:eth bridge vlan ifadd intf=eth_br name=video :eth bridge vlan ifdelete intf=eth_br name=default :eth bridge vlan ifadd intf=OBC name=video
E-NIT-CTC-20050927-0004 v3.0
74
Chapter 6
Ethernet interface
Proceed as follows:
>
Create the Ethernet interface and place it in the video VLAN:

:eth ifadd intf=eth_rt :eth ifconfig intf=eth_rt dest=bridge vlan=video :eth ifattach intf=eth_rt
PPPoE interface
Proceed as follows:
>
Create the PPPoE interface connected to the Ethernet interface and disable multicast traffic on this connection:
:ppp ifadd intf=pppoe :ppp ifconfig intf=pppoe dest=eth_rt user=user@inet password=pwdinet
>

>

:ppp rtadd intf=pppoe dst=0.0.0.0/0 :ppp ifattach intf=pppoe

Proceed as follows:
>


Proceed as follows:
>

:dhcp relay add name=video_to_dhcp :dhcp relay modify name=video_to_dhcp addr=127.0.0.1 intf=LocalNetwork
75
E-NIT-CTC-20050927-0004 v3.0
Chapter 6
DHCP rules
Proceed as follows:
>
Create a rule for each STB and rules for the other LAN devices:
:dhcp :dhcp :dhcp :dhcp rule rule rule rule add add add add name=STB1 type=mac mac=00:0f:1f:a5:5b:b9 name=STB2 type=mac mac=00:0f:1f:b5:5a:a9 name=notSTB1 type=mac mac=!00:0f:1f:a5:5b:b9 name notSTB2 type=mac mac=!00:0f:1f:b5:5a:a9
i
>
:dhcp :dhcp :dhcp :dhcp
In this example, we use the MAC address of the STBs to trigger the Flexiport script.

relay relay relay relay ruleadd ruleadd ruleadd ruleadd name=video_to_dhcp rulename=STB1 name=video_to_dhcp key=or rulename=STB2 name=Localnetwork_to_127.0.0.1 rulename=notSTB1 name=Localnetwork_to_127.0.0.1 key=and rulename=notSTB2
!
Flexiport script
Proceed as follows:
>
Create a Flexiport script to move the MAC addresses of the STBs to the video VLAN:
!
>

:dhcp relay modify name=video_to_dhcp script=video
Here the name of the script must be entered without the dhcr_ prefix.
E-NIT-CTC-20050927-0004 v3.0
76
Chapter 6
IGMP snooping
Proceed as follows:
>

i
>
:eth :eth :eth :eth


Proceed as follows:
>

:saveall
77
E-NIT-CTC-20050927-0004 v3.0
Chapter 6
6.2.3
Result
DHCP Server
LAN_private 192.168.1.[64-253]
DHCP Relay
Router
192.168.1.254
IP Local Network
PPP pppoe
ETH OBC default (vid=1) Bridge video (vid=2) IGMP snooping
ETH eth_rt
Flexiport 2 3 4
ethport
...
eth_br
ATM atm1
PVC pvc1
8.35
PC
STB1
STB2
E-NIT-CTC-20050927-0004 v3.0
78
Chapter 6
6.3 6.3.1
Routed Internet and Routed Multicast, Single STB Use Case
Scenario
In this scenario, we configure the Thomson Gateway with a single PVC. We configure this PVC with a routed PPPoE connection for routed normal Internet traffic as well as for routed multicast traffic. We consider the scenario with a single Set Top Box (STB). The scenario is depicted in the following illustration:
Internet Private IP from DHCP Pool 1
PPPoE Connection NATed Public IP BRAS
Private IP from DHCP Pool 2 Video Network
Video Server
Figure 20 The Thomson Gateway with one PVC for routed Internet and routed multicast.
Mechanisms
> > >
79
E-NIT-CTC-20050927-0004 v3.0
Chapter 6
6.3.2
Configuration

Proceed as follows:
>

>

Video VLAN
Proceed as follows:
>

i
>

Ethernet interfaces
Proceed as follows:
>
Create the Internet Ethernet interface:

:eth ifadd intf=eth_internet :eth ifconfig intf=eth_internet dest=atm1 vlan=default :eth ifattach intf=eth_internet
>
:eth :eth :eth :eth ifadd intf=eth_video ifconfig intf=eth_video dest=bridge vlan=video ifattach intf=eth_video bridge vlan ifadd intf=OBC name=video
E-NIT-CTC-20050927-0004 v3.0
80
Chapter 6
PPPoE interface
Proceed as follows:
>
Create the PPPoE interface connected to the Internet Ethernet interface:

:ppp ifadd intf=pppoe :ppp ifconfig intf=pppoe dest=eth_internet user=user@inet password=pwdinet
>

>

:ppp rtadd intf=pppoe dst=0.0.0.0 dstmsk=0.0.0.0 :ppp ifattach intf=pppoe

Proceed as follows:
>

:eth :eth :eth :eth bridge bridge bridge bridge ifconfig ifconfig ifconfig ifconfig intf=ethport1 intf=ethport2 intf=ethport3 intf=ethport4 dynvlan=enabled dynvlan=enabled dynvlan=enabled dynvlan=enabled
IP interface
Proceed as follows:
>
Create the IP interface connected to the video Ethernet LAN interface to prevent multicast flooding on the LAN Internet interfaces:
:ip ifadd intf=videonetwork dest=eth_video :ip ifconfig intf=videonetwork group=lan linksensing=enabled :ip ifattach intf=videonetwork
>
Assign an IP address to the IP interface:

DHCP pools
Proceed as follows:
>

81
E-NIT-CTC-20050927-0004 v3.0
Chapter 6

Proceed as follows:
>
>
!
DHCP rules
Proceed as follows:
>
Create a rule for the STB and a rule for the other LAN devices:
:dhcp rule add name=STB type=mac mac=00:0f:1f:*:*:* :dhcp rule add name=notSTB type=mac mac=!00:0f:1f:*:*:*
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
E-NIT-CTC-20050927-0004 v3.0
82
Chapter 6
Flexiport script
Proceed as follows:
>
!
>

! !
IGMP proxy
Here the name of the script must be entered without the dhcr_ prefix. 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 of LocalNetwork.
Proceed as follows:
>
>

:igmp proxy ifconfig intf=pppoe state=upstream :igmp proxy ifconfig intf=videonetwork state=downstream

Proceed as follows:
>

:saveall
83
E-NIT-CTC-20050927-0004 v3.0
Chapter 6
6.3.3
Result
DHCP Server
video 192.168.2.[64-253]
DHCP Server
LAN_private 192.168.1.[64-253]
DHCP Relay

192.168.1.254
DOWN
192.168.2.254
UP
public IP address
IP LocalNetwork
IP videonetwork
PPP pppoe
ETH eth_video
ETH eth_internet
video (vid=2)
Flexiport 2 3 4
ethport
...
ATM atm1
PVC pvc1
8.35
PC
STB
E-NIT-CTC-20050927-0004 v3.0
84
Chapter 6
6.4 6.4.1
Routed Internet and Routed Multicast, Multiple STBs Use Case
Scenario
In this scenario we configure the Thomson Gateway with a single PVC. We make use of one PVC with a routed PPPoE connection for routed normal Internet traffic as well as for routed multicast traffic. We consider the scenario with multiple Set Top Boxes (STBs). The scenario is depicted in the following illustration.
Video Server Private IP from DHCP Pool 2
Video Network
Mechanisms
> > > >
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.
85
E-NIT-CTC-20050927-0004 v3.0
Chapter 6
6.4.2
Configuration

Proceed as follows:
>

>

Video VLAN
Proceed as follows:
>

i
>

Ethernet interfaces
Proceed as follows:
>

>
:eth :eth :eth :eth ifadd intf=eth_video ifconfig intf=eth_video dest=bridge vlan=video ifattach intf=eth_video bridge vlan ifadd intf=OBC name=video
E-NIT-CTC-20050927-0004 v3.0
86
Chapter 6
PPPoE interface
Proceed as follows:
>

>

>


Proceed as follows:
>

:eth :eth :eth :eth bridge bridge bridge bridge ifconfig ifconfig ifconfig ifconfig intf=ethport1 intf=ethport2 intf=ethport3 intf=ethport4 dynvlan=enabled dynvlan=enabled dynvlan=enabled dynvlan=enabled
IP interface
Proceed as follows:
>
Create the IP interface connected to the video Ethernet LAN interface to prevent multicast flooding on the LAN Internet interfaces:
:ip ifadd intf=videonetwork dest=eth_video :ip ifconfig intf=videonetwork group=lan linksensing=enabled :ip ifattach intf=videonetwork
>

DHCP pools
Proceed as follows:
>

87
E-NIT-CTC-20050927-0004 v3.0
Chapter 6

Proceed as follows:
>
>
The first forwarding entry checks the MAC address of the device in its first DHCP request. If the MAC address 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 MAC address in the rule the DHCP request will be forwarded to the default internal DHCP server of the Thomson Gateway.
!
DHCP rules
Proceed as follows:
>
:dhcp :dhcp :dhcp :dhcp rule rule rule rule add add add add name=STB1 type=mac mac=00:0f:1f:a5:5b:b9 name=STB2 type=mac mac=00:0f:1f:b5:5a:a9 name=notSTB1 type=mac mac=!00:0f:1f:a5:5b:b9 name notSTB2 type=mac mac=!00:0f:1f:b5:5a:a9
i
>
:dhcp :dhcp :dhcp :dhcp :dhcp :dhcp
In this scenario, we use the MAC address of the STBs to trigger the Flexiport script.

relay relay relay relay relay relay ruleadd ruleadd ruleadd ruleadd ruleadd ruleadd name=video_to_dhcp rulename=STB1 name=video_to_dhcp key=or rulename=STB2 name=Localnetwork_to_127.0.0.1 rulename=notSTB1 name=Localnetwork_to_127.0.0.1 key=and rulename=notSTB2 name=LocalNetwork_to_script rulename=STB1 name=LocalNetwork_to_script key=or rulename=STB1
E-NIT-CTC-20050927-0004 v3.0
88
Chapter 6
Flexiport script
Proceed as follows:
>
!
>

! !
IGMP proxy
Here the name of the script must be entered without the dhcr_ prefix. 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 of LocalNetwork.
Proceed as follows:
>
>

:igmp proxy ifconfig intf=pppoe state=upstream :igmp proxy ifconfig intf=videonetwork state=downstream
IGMP snooping
Proceed as follows:
>

i
>
:eth :eth :eth :eth

89
E-NIT-CTC-20050927-0004 v3.0
Chapter 6

Proceed as follows:
>

:saveall
E-NIT-CTC-20050927-0004 v3.0
90
Chapter 6
6.4.3
Result
DHCP Server
video 192.168.2.[64-253]
DHCP Server
LAN_private 192.168.1.[64-253]
DHCP Relay

192.168.1.254
DOWN
192.168.2.254
UP
public IP address
IP LocalNetwork
IP videonetwork
PPP pppoe
ETH eth_video
ETH eth_internet
video (vid=2) IGMP snooping
Flexiport 2 3 4
ethport
...
ATM atm1
PVC pvc1
8.35
PC
STB1
STB2
91
E-NIT-CTC-20050927-0004 v3.0
Chapter 6
6.5 6.5.1
Routed Internet and Routed Multicast, IGMP-based Use Case
Scenario
In this scenario we configure the Thomson Gateway with a single PVC. We make use of one PVC with a routed PPPoE connection for routed normal Internet traffic as well as for routed multicast traffic. The scenario is depicted in the following illustration.
Private IP from DHCP Pool 2 Video Network
Video Server
i
Mechanisms
In this scenario, the number of STBs is not important. The configuration of the Thomson Gateway is the same for the scenario with a single STB and the scenario with multiple STBs.
> >
E-NIT-CTC-20050927-0004 v3.0
92
Chapter 6
6.5.2
Configuration

Proceed as follows:
>

>

Internet Ethernet interface

Proceed as follows:
>

PPPoE interface
Proceed as follows:
>

>

>

93
E-NIT-CTC-20050927-0004 v3.0
Chapter 6
IGMP proxy
Proceed as follows:
>
>
Configure the PPPoE interface as an upstream interface:

:igmp proxy ifconfig intf=pppoe state=upstream
IGMP snooping
Proceed as follows:
>

i
>
:eth :eth :eth :eth


Proceed as follows:
>

:saveall
E-NIT-CTC-20050927-0004 v3.0
94
Chapter 6
6.5.3
Result
DHCP Server
LAN_private 192.168.1.[64-253]
DHCP Relay

192.168.1.254
UP
public IP address
IP LocalNetwork
PPP pppoe
ETH OBC default (vid=1) IGMP snooping Bridge
ETH eth_internet
ethport
...
ATM atm1
PVC pvc1
8.35
PC
STB
This configuration has full LAN-to-LAN connectivity. This configuration cannot cope with a NAT unfriendly STB.
95
E-NIT-CTC-20050927-0004 v3.0
Chapter 7
Ethernet WAN Port for Multicast Video
Introduction
In this chapter, we describe several use cases with a single PVC. This PVC will be used for Internet traffic. In addition, one of the Ethernet ports will be used as Ethernet WAN port for multicast video. For every use case, we present:
> > >
Before we start
>
Reset the Thomson Gateway to the factory defaults and restart the device:
>
>
Overview
In this chapter, the following use cases with a WAN Ethernet port for multicast video are described:
Topic
7.1 Ethernet WAN Port, Routed Internet and Routed Multicast, Flexiport 7.2 Ethernet WAN Port, Routed Internet and Routed Multicast, IGMP-based 7.3 Ethernet WAN Port on the Bridge, Routed Internet and Routed Multicast, IGMP and VLANs 7.4 AutoWAN, Routed Internet and Bridged Multicast
Page
97 104 109 115
E-NIT-CTC-20050927-0004 v3.0
96
Chapter 7
7.1
Ethernet WAN Port, Routed Internet and Routed Multicast, Flexiport Use Case
7.1.1
Scenario
In this scenario, we configure the Thomson Gateway with a single PVC and an Ethernet WAN port. The PVC is used for Internet traffic via a routed PPPoE Internet connection. The Ethernet WAN port is used for routed multicast video. The scenario is depicted in the following illustration:
Internet Private IP from DHCP Pool 1 BRAS PPPoE Connection Routed Ethernet Connection
NATed IP NATed IP
DSLAM
Private IP from DHCP Pool 2 Video Server
Video Network
Mechanisms
> > >
97
E-NIT-CTC-20050927-0004 v3.0
Chapter 7
7.1.2
Configuration
In this section, we describe the configuration of the Thomson Gateway to set up the scenario. The configuration has been created using the CLI.

Proceed as follows:
>

>


Proceed as follows:
>
Data PPPoE interface

Proceed as follows:
>

>

>
Create a default route to this PPPoE interface:

E-NIT-CTC-20050927-0004 v3.0
98
Chapter 7
Video Ethernet WAN port

Proceed as follows:
>
Detach and delete an Ethernet interface from the bridge so we can use the corresponding Ethernet port as an Ethernet WAN port for multicast video:
:eth bridge ifdetach intf ethport4 :eth bridge ifdelete intf ethport4
Video WAN VLAN

Proceed as follows:
>

>
Create a video WAN VLAN:

:eth vlan add name=video_wan vid=9
The video WAN VLAN must only be created if the video server is directly connected to the Ethernet WAN port and uses VLAN tags. In this case, the VID of the created video WAN VLAN must be the same as the VID of the multicast video streams.
Video Ethernet WAN interfaces

Proceed as follows:
>
Create a video Ethernet interface connected to the WAN Ethernet port:

:eth ifadd intf=eth_wan :eth ifconfig intf=eth_wan dest=ethif4 :eth ifattach intf=eth_wan
>
Create another video Ethernet interface connected to the first one and place it in the video WAN VLAN:
:eth ifadd intf=eth_video :eth ifconfig intf=eth_video dest=eth_wan vlan=video_wan :eth ifattach intf=eth_video
Video IP WAN interface

Proceed as follows:
>
Create the video IP interface connected to the video Ethernet interface:

>
Enable NAT on the video IP interface:

99
E-NIT-CTC-20050927-0004 v3.0
Chapter 7
DHCP client
Proceed as follows:
>
Configure the DHCP client for the video IP WAN interface:

:dhcp client ifadd intf=ip_video :dhcp client ifconfig intf=ip_video metric=10 dnsmetric=10 :dhcp client ifattach intf=ip_video
Video VLAN
Proceed as follows:
>


Proceed as follows:
>
:eth ifadd intf=ethVideoLan :eth ifconfig intf=ethVideoLan dest=bridge vlan=video :eth ifattach intf=ethVideoLan
Video IP LAN interface

Proceed as follows:
>
Create the video IP LAN interface connected to the video Ethernet LAN interface:
:ip ifadd intf=ipVideoLan dest=ethVideoLan :ip ifconfig intf=ipVideoLan group=lan :ip ifattach intf=ipVideoLan
>

:ip ipadd intf=ipVideoLan addr=192.168.2.254
DHCP pool
Proceed as follows:
>

:dhcp server pool add name=LAN_video :dhcp server pool config name=LAN_video intf=ipVideoLan poolstart=192.168.2.64 poolend=192.168.2.253 netmask=24 gateway=192.168.2.254 server=192.168.2.254 primdns=192.168.2.254 leasetime=7200
E-NIT-CTC-20050927-0004 v3.0
100
Chapter 7

Proceed as follows:
>
Place the OBC in the video VLAN. This way, the DHCP relay can handle incoming DHCP requests.
:eth bridge vlan ifadd intf=OBC name=video
>
Enable configuration of the DHCP relay interfaces:

:dhcp relay ifconfig intf=ipVideoLan relay=enabled
>
Create a first DHCP relay forwarding entry that 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, the Flexiport script will be triggered. 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:
:dhcp relay add name=LocalNetwork_to_video :dhcp relay modify name=LocalNetwork_to_video addr=127.0.0.1 intf=LocalNetwork
>
Create a second DHCP relay forwarding entry that will forward a new DHCP request towards the internal video DHCP server:
:dhcp relay add name=video_to_127.0.0.1 :dhcp relay modify name=video_to_127.0.0.1 addr=127.0.0.1 intf=ipVideoLan giaddr=192.168.2.254
DHCP rules
Proceed as follows:
>
:dhcp rule add name=STB type=mac mac=00:0f:1f:83:d7:5b :dhcp rule add name=notSTB type=mac mac=!00:0f:1f:83:d7:5b
>
Assign these DHCP rules to the correct DHCP relay forwarding entries:
:dhcp relay ruleadd name=LocalNetwork_to_video rulename=STB :dhcp relay ruleadd name=LocalNetwork_to_127.0.0.1 rulename=notSTB :dhcp relay ruleadd name=video_to_127.0.0.1 rulename=STB

Proceed as follows:
>

:eth bridge ifconfig intf=ethport1 dynvlan=enabled :eth bridge ifconfig intf=ethport2 dynvlan=enabled :eth bridge ifconfig intf=ethport3 dynvlan=enabled
101
E-NIT-CTC-20050927-0004 v3.0
Chapter 7
Flexiport script
Proceed as follows:
>
:script add name=dhcr_video index=0 command="eth bridge dynvlan add hwaddr $1 vlan video"
>

:dhcp relay modify name=LocalNetwork_to_video script=video
IGMP proxy
Proceed as follows:
>
>

:igmp proxy ifconfig intf=ipVideoLan state=downstream :igmp proxy ifconfig intf=ip_video state=upstream :igmp proxy ifconfig intf=LocalNetwork state=inactive

Proceed as follows:
>

:saveall
E-NIT-CTC-20050927-0004 v3.0
102
Chapter 7
7.1.3
Result
DHCP Server
LAN_video 192.168.2.[64-253]
DHCP Server
LAN_private 192.168.1.[64-253]
DHCP Relay

192.168.1.254
UP DHCP Client
IP LocalNetwork
192.168.2.254
public IP address
public IP address
IP ipVideoLan ETH OBC default (vid=1) Bridge video (vid=2) ETH ethVideoLan
IP ip_video ETH eth_video
PPP pppoe_data ETH eth_data
Flexiport 1 2 3 ethport
...
ETH eth_wan
ATM atm_data
PHY ethif4
PVC pvc_data
8.35
PC
STB
103
E-NIT-CTC-20050927-0004 v3.0
Chapter 7
7.2
Ethernet WAN Port, Routed Internet and Routed Multicast, IGMP-based Use Case
7.2.1
Scenario
Internet Private IP from DHCP Pool BRAS PPPoE Connection Routed Ethernet Connection
NATed IP NATed IP
DSLAM
Private IP from DHCP Pool Video Server
Video Network
Mechanisms
> >
E-NIT-CTC-20050927-0004 v3.0
104
Chapter 7
7.2.2
Configuration

Proceed as follows:
>

>


Proceed as follows:
>

Proceed as follows:
>

>

>

105
E-NIT-CTC-20050927-0004 v3.0
Chapter 7
Video Ethernet WAN port

Proceed as follows:
>
Detach and delete an Ethernet interface from the bridge so we can use the corresponding Ethernet port as a WAN Ethernet port for multicast video:
:eth bridge ifdetach intf ethport4 :eth bridge ifdelete intf ethport4
Video WAN VLAN

Proceed as follows:
>

>
Create a video WAN VLAN:

:eth vlan add name=video_wan vid=9
The video WAN VLAN must only be created if the video server is directly connected to the Ethernet WAN port and uses VLAN tags. In this case, the VID of the created video WAN VLAN must be the same as the VID of the multicast video streams.
Video Ethernet WAN interfaces

Proceed as follows:
>
Create a video Ethernet interface connected to the WAN Ethernet port:

:eth ifadd intf=eth_wan :eth ifconfig intf=eth_wan dest=ethif4 :eth ifattach intf=eth_wan
>
Create another video Ethernet interface connected to the first one and place it in the video WAN VLAN:
:eth ifadd intf=eth_video :eth ifconfig intf=eth_video dest=eth_wan vlan=video_wan :eth ifattach intf=eth_video
Video IP WAN interface

Proceed as follows:
>
Create the video IP interface connected to the video Ethernet interface:

>
Enable NAT on the video IP interface:

E-NIT-CTC-20050927-0004 v3.0
106
Chapter 7
DHCP client
Proceed as follows:
>
Configure the DHCP client for the video IP WAN interface:

IGMP proxy
Proceed as follows:
>
>

:igmp proxy ifconfig intf=LocalNetwork state=downstream :igmp proxy ifconfig intf=ip_video state=upstream
IGMP snooping
Proceed as follows:
>

:eth :eth :eth :eth bridge bridge bridge bridge igmpsnooping config state=enabled ifconfig intf=ethport1 igmpsnooping=enabled ifconfig intf=ethport2 igmpsnooping=enabled ifconfig intf=ethport3 igmpsnooping=enabled
i
>

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

Proceed as follows:
>

:saveall
107
E-NIT-CTC-20050927-0004 v3.0
Chapter 7
7.2.3
Result
DHCP Server
LAN_private 192.168.1.[64-253]
DHCP Relay Router IGMP Proxy DOWN

192.168.1.254
UP DHCP Client
public IP address public IP address
IP LocalNetwork
IP ip_video ETH OBC default (vid=1) IGMP snooping Bridge ETH eth_video
3 ethport
...
ETH eth_wan
ATM atm_data
PHY ethif4
PVC pvc_data
8.35
PC
STB
E-NIT-CTC-20050927-0004 v3.0
108
Chapter 7
7.3
Ethernet WAN Port on the Bridge, Routed Internet and Routed Multicast, IGMP and VLANs Use Case
7.3.1
Scenario
Internet Private IP from DHCP Pool BRAS PPPoE Connection Routed Ethernet Connection
NATed IP NATed IP
DSLAM
Private IP from DHCP Pool Video Server
Video Network
Mechanisms
> > >
VLANs are used. IGMP proxying is used. IGMP snooping is used to avoid flooding of multicast streams on other ports of the bridge.
109
E-NIT-CTC-20050927-0004 v3.0
Chapter 7
7.3.2
Configuration

Proceed as follows:
>

>


Proceed as follows:
>

Proceed as follows:
>

>

>

E-NIT-CTC-20050927-0004 v3.0
110
Chapter 7
Public VLAN
Proceed as follows:
>

>
Create a public VLAN and a dummy VLAN:

:eth vlan add name=public vid=9 :eth vlan add name=test vid=2
The VID of the created public VLAN must be the same as the VID of the (tagged) multicast video streams.
Ethernet WAN interface on the bridge

Proceed as follows:
>
Place one of the Ethernet interfaces on the bridge in both the dummy VLAN and the public VLAN:
:eth bridge vlan ifadd name=public intf=ethport4 :eth bridge vlan ifadd name=test intf=ethport4
>
Remove this Ethernet interface from the default VLAN:

:eth bridge vlan ifdelete name=default intf=ethport4
>
Disable this Ethernet interface as untagged for the public VLAN:

:eth bridge vlan ifconfig intf=ethport4 untagged=disabled
Ethernet WAN interface

Proceed as follows:
>
Create the Ethernet WAN interface and place this interface in the public VLAN:
:eth ifadd intf=ethVideoWan :eth ifconfig intf=ethVideoWan dest=bridge vlan=public :eth ifattach intf=ethVideoWan
111
E-NIT-CTC-20050927-0004 v3.0
Chapter 7
IP WAN interface
Proceed as follows:
>
Create the IP WAN interface connected to the Ethernet WAN interface:

:ip ifadd intf=ipVideoWan dest=ethVideoWan :ip ifattach intf=ipVideoWan
>
Enable NAT on the IP WAN interface:

:nat ifconfig intf=ipVideoWan translation=enabled
DHCP client
Proceed as follows:
>
Place the OBC in the public VLAN:

:eth bridge vlan ifadd intf=OBC name=public
>
Configure the DHCP client for the IP WAN interface:

:dhcp client ifadd intf=ipVideoWan :dhcp client ifconfig intf=ipVideoWan metric=10 dnsmetric=10 :dhcp client ifattach intf=ipVideoWan
IGMP proxy
Proceed as follows:
>
Enable the IGMP proxy to forward all multicast traffic from the WAN to the LAN:
>

:igmp proxy ifconfig intf=LocalNetwork state=downstream :igmp proxy ifconfig intf=ipVideoWan state=upstream
E-NIT-CTC-20050927-0004 v3.0
112
Chapter 7
IGMP snooping
Proceed as follows:
>

:eth :eth :eth :eth bridge bridge bridge bridge igmpsnooping config state=enabled ifconfig intf=ethport1 igmpsnooping=enabled ifconfig intf=ethport2 igmpsnooping=enabled ifconfig intf=ethport3 igmpsnooping=enabled
i
>

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

Proceed as follows:
>

:saveall
113
E-NIT-CTC-20050927-0004 v3.0
Chapter 7
7.3.3
Result
DHCP Server
LAN_private 192.168.1.[64-253]
DHCP Relay

192.168.1.254
UP DHCP Client
public IP address public IP address
IP LocalNetwork
IP ipVideoWan ETH OBC default (vid=1) IGMP snooping Bridge public (vid=9) ETH ethVideoWan
3 ethport
...
4 ethport
ATM atm_data
PVC pvc_data
8.35
PC
STB
E-NIT-CTC-20050927-0004 v3.0
114
Chapter 7
7.4 7.4.1
AutoWAN, Routed Internet and Bridged Multicast Use Case
Scenario
Internet Private IP from DHCP Pool BRAS Routed Connection Bridged Ethernet Connection
NATed IP
DSLAM
Video Network IP
DHCP Server Video Server
Video Network
Mechanisms
>
VLANs are used, resulting in a Layer 2 isolation of the STB and the other LAN devices. We will use two VLANs:
Video: This VLAN contains all WAN interfaces and all STBs. By default, all devices are a member of this VLAN. Routed: This VLAN contains all non-STB devices. By default, only OBC is a member of this VLAN. All non-STB devices are switched from the default VLAN to the routed VLAN.
>
Flexiport is used, so that the MAC addresses of non-STB devices are automatically mapped to the routed VLAN.
115
E-NIT-CTC-20050927-0004 v3.0
Chapter 7
7.4.2
Configuration

Proceed as follows:
>

>


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

:eth bridge ifadd intf=br038 :eth bridge ifconfig intf=br038 dest=atm038 :eth bridge ifattach intf=br038
VLANs
Proceed as follows:
>

>
Create a video VLANs and a routed VLAN:

:eth vlan add name=routed vid=2 :eth vlan add name=video vid=9
i
>
The VID of the created video VLAN must be the same as the VID of the (tagged) multicast video streams.
Place the OBC in both the video VLAN and the routed VLAN:
:eth bridge vlan ifadd intf=OBC name=routed :eth bridge vlan ifadd intf=OBC name=video
E-NIT-CTC-20050927-0004 v3.0
116
Chapter 7
>
Place all the Ethernet interfaces on the bridge in the video VLAN:
:eth :eth :eth :eth :eth bridge bridge bridge bridge bridge vlan vlan vlan vlan vlan ifadd ifadd ifadd ifadd ifadd intf=ethport1 name=video intf=ethport2 name=video intf=ethport3 name=video intf=ethport4 name=video untagged=disabled intf=br038 name=video
>
Remove all Ethernet interfaces except the WAN Ethernet interface from the default VLAN:
:eth :eth :eth :eth bridge bridge bridge bridge vlan vlan vlan vlan ifdelete ifdelete ifdelete ifdelete intf=ethport1 name=default intf=ethport2 name=default intf=ethport3 name=default intf=br038 name=default

Proceed as follows:
>

:eth bridge ifconfig intf=ethport1 dynvlan=enabled :eth bridge ifconfig intf=ethport2 dynvlan=enabled :eth bridge ifconfig intf=ethport3 dynvlan=enabled
Ethernet interfaces
Proceed as follows:
>
Create the routed Ethernet interface connected to the routed VLAN on the bridge:
:eth ifadd intf=eth_routed :eth ifconfig intf=eth_routed dest=bridge vlan=routed :eth ifattach intf=eth_routed
>
Create the video Ethernet interface connected to the video VLAN on the bridge:
:eth ifadd intf=eth_video :eth ifconfig intf=eth_video dest=bridge vlan=video :eth ifattach intf=eth_video
IP LAN interface
Proceed as follows:
>
Create the routed IP interface as an IP LAN interface connected to the routed Ethernet interface:
:ip ifadd intf=ip_routed dest=eth_routed :ip ifconfig intf=ip_routed group=lan linksensing=enabled :ip ifattach intf=ip_routed
>

:ip ipdelete addr 192.168.1.254 :ip ipadd intf=ip_routed addr=192.168.1.254/24 addroute=enabled
117
E-NIT-CTC-20050927-0004 v3.0
Chapter 7
IP WAN interface > Create the video IP interface as an IP WAN interface connected to the video Ethernet interface:
:ip ifadd intf=ip_video dest=eth_video :ip ifconfig intf=ip_video group=wan linksensing=enabled :ip ifattach intf=ip_video
>

:ip ipadd intf=ip_video addr=10.0.0.138/24 addroute=enabled
>
Enable NAT on the video PPPoE interface:

DHCP client
Proceed as follows:
>
Configure the DHCP client for the IP WAN interface:

DHCP pools
Proceed as follows:
>
Create a DHCP server pool for the routed network:

:dhcp server pool flush :dhcp server pool add name=LAN_private index=0 :dhcp server pool config name=LAN_private intf=ip_routed poolstart=192.168.1.64 poolend=192.168.1.253 netmask=24 gateway=192.168.1.254 server=192.168.1.254 primdns=192.168.1.254 leasetime=7200

Proceed as follows:
>
Enable configuration of the DHCP relay interfaces:

:dhcp relay ifconfig intf=ip_routed relay=enabled :dhcp relay ifconfig intf=ip_video relay=enabled :dhcp relay ifconfig intf=LocalNetwork relay=disabled
>
Create a first DHCP relay forwarding entry that 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, the Flexiport script is triggered:
:dhcp relay add name=switch_routed :dhcp relay modify name=switch_routed addr=127.0.0.1 intf=ip_video
E-NIT-CTC-20050927-0004 v3.0
118
Chapter 7
>
Create a second DHCP relay forwarding entry that will forward a new DHCP request towards the internal DHCP server:
:dhcp relay add name=routed :dhcp relay modify name=routed addr=127.0.0.1 intf=ip_routed giaddr=192.168.1.254
DHCP rules
Proceed as follows:
>
Create a DHCP rule for the STB:

:dhcp rule add name ROUTED type mac mac=!00:0f:1f:83:d7:5b
>
Assign this DHCP rule to the correct DHCP relay forwarding entry:
:dhcp relay ruleadd name=switch_routed rulename=ROUTED :dhcp relay ruleadd name=routed rulename=ROUTED
Flexiport script
Proceed as follows:
>
Create a flexiport script to move the MAC address of every device that is not a STB to the routed VLAN and remove it from the video VLAN:
:script add name=dhcr_routed index=0 command="eth bridge dynvlan add hwaddr $1 vlan routed remvlan video"
>

:dhcp relay modify name=switch_routed script=routed
Disable IGMP snooping

Proceed as follows:
>
Disable IGMP snooping:

:eth bridge igmpsnooping config state=disabled

Proceed as follows:
>

:saveall
119
E-NIT-CTC-20050927-0004 v3.0
Chapter 7
7.4.3
Result
DHCP Server
LAN_private 192.168.1.[64-253]
DHCP Relay
Router
DHCP Client
192.168.1.254
IP ip_routed
public IP address 10.0.0.138
IP ip_video ETH eth_routed OBC routed (vid=2) Bridge video (vid=9) ETH eth_video
Flexiport 2 3 4
ethport
...
br038
ATM atm038
PVC pvc038
0.38
PC
STB
Video Server
E-NIT-CTC-20050927-0004 v3.0
120
Visit us at:
www.thomson-broadband.com
Coordinates
THOMSON Telecom Prins Boudewijnlaan 47 B-2650 Edegem Belgium E-mail: documentation.speedtouch@thomson.net
Copyright
2007 THOMSON. All rights reserved. The content of this document is furnished for informational use only, may be subject to change without notice, and should not be construed as a commitment by THOMSON. THOMSON assumes no responsibility or liability for any errors or inaccuracies that may appear in this document. The information contained in this document represents the current view of THOMSON on the issues discussed as of the date of publication. Because THOMSON must respond to changing market conditions, it should not be interpreted to be a commitment on the part of THOMSON, and THOMSON cannot guarantee the accuracy of any information presented after the date of publication. This document is for informational purposes only. THOMSON MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

AppNote MulticastVideothomson

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

AppNote MulticastVideothomson

Transféré par

Droits d'auteur :

Formats disponibles

Thomson Gateways and Multicast Video

Date: Version: July 2007 v3.0

 The THOMSON ST780 (Wireless) R6.2.G

The Thomson Gateway and Flexiport ..................................... 23

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

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

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

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

Introduction to Multicast Video

> > >

Differences between multicast video and unicast video are:

> > >

> > > >

MAC multicast address

Mapping between IP and MAC multicast addresses

4 bits 5 bits fixed dropped

MAC Multicast Address

25 bits fixed 48 bits

The following illustration gives an example:

MAC Multicast Address

Internet Group Management Protocol (IGMP)

Setting Up a Multicast Group

Figure 1 Initial situation.

First IGMP membership report

Figure 2 First IGMP membership report.

Additional IGMP messages

IGMP join 255.0.0.1 C1 R2 Video Server

IGMP join 255.0.0.1 C2 R1 R3 255.0.0.1 S1

IGMP join 255.0.0.1

Figure 3 Additional IGMP messages.

Completed multicast group

> > > >

Figure 4 Completed multicast group.

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

Membership query: two types of query messages are defined:

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

Membership query: three types of query messages are defined:

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

> > >

IGMP support in the Thomson Gateway

> > > >

Figure 5 Join request.

Query and response messages

IGMP Query IGMP Resp. 225.0.0.1 IGMP Resp. 225.0.0.2

Figure 6 IGMP query and response.

Figure 7 Leave request.

225.0.0.1 225.0.0.1 225.0.0.1 225.0.0.2 225.0.0.2 225.0.0.2 225.0.0.1 225.0.0.1

IGMP Leave 225.0.0.1 IGMP Join 225.0.0.2 225.0.0.2 225.0.0.2

Figure 8 IGMP zapping.

IGMP proxying in the Thomson Gateway

Multicast Routing Database

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

No use of IGMP snooping

> > >

Use of IGMP snooping

IGMP snooping in the Thomson Gateway

> > >

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

The Thomson Gateway and Flexiport

Life before Flexiport

> > >

192.168.1.66 PVC1 PVC2 PVC3 IP Phone xDSL Network

The THOMSON ST780 (Wireless) R6.2.G