Building Multicast Controller for Carrier-grade IPTV ...

Building Multicast Controller for Carrier-grade IPTV Service over Ethernet Passive Optical Network Juan Wu*(1), YaLing Nie(1), Hideya Yoshiuchi(1), Hiroki Ikeda(2) 1. Hitachi (China) Research & Development Corporation, Beijing, China 2. Hitachi Central Laboratory, Japan *[email protected]

Abstract Ethernet Passive Optical Network (EPON) is an emerging high-speed access network technology that can provide an ideal transmission platform for highbandwidth applications such as IPTV (Internet Protocol Television). To deploy the carrier-grade IPTV service, especially HDTV (High Definition TV), it is very essential to construct a controllable multicast architecture for IPTV service over EPON. In this paper, we present a multicast control solution over EPON system to satisfy the demand of the service management and control from the service providers. Furthermore, we successfully develop a multicast controller to perform the multicast control function including managing the eligibility of the subscribers and controlling the delivery of the multicast channels. The evaluation results demonstrate that the multicast controller can not only provide high processing performance but also improve the operation and management ability for the service providers greatly.

1. Introduction Recently, more and more high-bandwidth network services such as high-speed internet access, IPTV, HDTV and so on are emerging in people’s life. The traditional access network like ADSL can not offer sufficient bandwidth any more. Therefore, Fiber to the Home (FTTH) is being regarded as the ideal solution for broadband access network [1]. As one of the best choices to deploy FTTH, Ethernet Passive Optical Network (EPON) has been attracting more and more attentions due to its low cost and high bandwidth. The maximum upstream/ downstream rate for EPON is normally 1.25Gbps, which provides a good candidate for delivering high bandwidth applications. As a killer application in EPON, IPTV service is being discussed as the promising revenue increasing

point for the telecom operators. Presently, most of the global operators have launched the commercial trial or the practical deployment of the IPTV service. To deploy the carrier-grade IPTV service, IP multicast is another tempting possibility for the service providers in addition to the high speed access network EPON. Since IP multicast can deliver one video stream to multiple receivers simultaneously [2], which can improve bandwidth utilization efficiently, thus it is especially useful for IPTV. However, there still exist some issues for IP multicast such as user authentication, multicast channel management and so on [3]. As we all know, IP multicast is an open membership based protocol which means that anyone can join the multicast group and receive the multicast stream. Thus, the multicast traffic can not be controlled and managed over the network. The uncontrollability of multicast will be a severe weakness for the commercial deployment of IPTV service [4] [5]. Besides, the current EPON draft does not consider multicast support and management issues [6]. Moreover, since EPON is a shared network in the downstream, the multicast transmission will waste much bandwidth if it is not configured properly. Therefore, it is very essential to provide multicast control function over EPON for delivering multicast IPTV service efficiently. This paper presents a multicast control solution for IPTV service over EPON, which specifies different entities in the delivery network to perform multicast membership authentication, multicast channel management and control, and the multicast source check. Based on the proposed solution, we successfully implemented a multicast controller, which can not only manage and control the multicast request and downstream multicast channel, but also make the multicast control point as close as possible to the clients. The rest of the paper is organized as follows. Section 2 introduces the basic concepts behind the

work and some consideration from other researchers. Then section 3 describes the proposed multicast control solution over EPON in detail. Finally we present the result of the performance evaluation of the multicast controller.

2. Background and related work 2.1 System Architecture of Multicast IPTV Service over EPON

STB

Client 1

STB

Client 2

STB

Client m

2.3 Considerations on Multicast Control for IPTV service over EPON

STB

Client n

Multicast stream

ONU #1

splitter

。。。

OLT

Router

Core Network ONU #n Multicast replication point

2.2 IGMP Snooping/Proxy The IGMP (Internet Group Management Protocol) is a protocol to maintain the multicast membership between the routers in order to support multicast communication. While the EPON is layer 2 based devices, so it can not support IP multicast directly. Currently, most EPON systems adopt IGMP snooping/proxy [7] [8] to support IP multicast. The ONU can perform the IGMP snooping function, which is responsible for listening to the IGMP message from the users and setting up a multicast mapping table between the multicast address and the requesting port. While the OLT can perform the IGMP proxy function, which is responsible for capturing the IGMP message and setting up a multicast forwarding table between the multicast address and the ONUs. Thus the EPON can manage the multicast forwarding table for the layer2 multicast.

Fig.1 shows the general system architecture of multicast IPTV service over EPON. Basically, it consists of four parts: the IPTV server, the multicast router, the EPON system and the IPTV client. The IPTV server is used to generate the multicast IPTV streams to the network. Each multicast group represents an IPTV channel. When the user changes to another IPTV channel, he just leaves the current multicast group and joins a new one. The multicast router is used to deliver the multicast stream from the IPTV server to the access network by setting up a multicast routing. IPTV server

The procedure of the multicast IPTV over EPON is like this: firstly the IPTV client sends an IGMP join request to the ONU and ONU will forward it to the OLT. When the OLT receives the IGMP request, it will forward the IGMP request to the multicast router. Then the multicast router will set up a multicast routing, based on which the router can forward the replicated multicast stream to the requesting client.

IGMP request Multicast stream

Figure 1. System architecture of multicast IPTV service over EPON The EPON system represents the access network. In the EPON system, multiple ONUs (Optical Network Unit) are installed on client side such as home or office, and an OLT (Optical Line Terminal) is installed on central office side and connected to ONUs through an ODN (Optical Distribution Network) such as splitter. The downstream multicast traffic is transmitted from the OLT to the ONUs in a broadcast manner. Besides, in order to make the multicast replication point as close as possible to the client side, the OLT can play the role of multicast router to perform the multicast replication function. The IPTV client can be a set of box with a normal TV, which is used to receive the multicast stream and play them.

To deploy the carrier-grade IPTV successfully, the multicast control function is needed to achieve the trust and controllability that the service providers want. More recently, the IETF and ITU-T FG IPTV are discussing the multicast control requirement issues. For example, IETF has been already considering this issue into some drafts such as ANCP (Access Node Control Protocol) [9] and MCOP (Multicast Control Protocol) [10]. ITU-T FG IPTV also has contributed some drafts on the multicast control requirement for IPTV service in [11] [12]. Here combining the feature of EPON system, we summarize the multicast control requirement for IPTV service as the following: 1) Multicast membership authentication; 2) Multicast membership control; 3) Multicast channel management; 4) Multicast source check.

3. IPTV multicast control solution over EPON Our main goal is to design a controllable and manageable IPTV multicast solution over EPON for

the service providers by satisfying the requirements mentioned above.

3.1 Framework of IPTV Multicast Control Solution over EPON The framework of IPTV multicast control solution over EPON is shown as Fig.2. Comparing with Fig.1, it includes three more components: the management portal, the Radius, and the CH manager. Furthermore, the function of the OLT and the ONU has been enhanced greatly so as to support the multicast control ability. Next we will describe the function of each component in detail. MCA/CH MCA assignment

User/ Ch list

accounting profile

User/ password

Ch management

accounting

auth

register

Management Portal

Radius

CH manager IP TV server

IGMP proxy

Router

Multicast source check

Multicast source access table

MCA-ONU mapping table

MLLID assignment

MCA- MLLID mapping table

subscription

web portal

Fiber splitter

MCA-usr mapping table

CH access table

IGMP snooping

CH access control

IGMP filter

Multicast-unicast conversion

IPTV client

MLLID management table

Multicast controller

OLT

ONU

Figure 2. IPTV multicast control solution over EPON 1) Management Portal is the centric based access portal for the IPTV clients. When users want to register the system to receive multicast stream or subscribe/unsubscribe some IPTV channel, they have to access the portal firstly. This management portal consists of two interface modules: one is the registration module, which is used to communicate with the Radius to authenticate the users; the other is the subscription module, which is used to communicate with CH manager to maintain the channel list of each user. 2) Radius is used to perform the authentication and counting ability. It can be configured according to the different authentication and counting mechanisms that are wanted by the service providers. 3) CH manager is used to maintain the channel list of each user and globally assign the multicast address for a new IPTV channel. It is responsible for assigning a multicast address for a newly emerging IPTV channel on the IPTV server and maintaining a global

mapping table between the multicast address and the channel number. 4) OLT is enhanced by adding the IGMP proxy module, multicast source check module and the MLLID (Multicast Logical Link ID) assignment module [13]. As mentioned in the last section, the IGMP proxy module can maintain a mapping table between the multicast address and ONUs, which can be used to tell the OLT which ONUs the multicast stream should be forwarded to. For the incoming downstream multicast stream, the OLT firstly checks the multicast source to judge if this multicast source is legal or not. If the multicast source is illegal, it will drop the corresponding multicast stream directly. Since EPON is a shared network in the downstream direction, here we will adopt MLLID for the multicast stream delivery so as to save bandwidth resources. 5) ONU is enhanced by adding a multicast controller, with which ONU can accept/reject the channel request from users according to the permitted channel list, filter the requested multicast stream and unicast the IPTV stream to each user. The detailed information on the multicast controller will be described in the next part.

3.2 Design of the Multicast Controller In order to make the multicast control point as close as possible to the client side, we design and implement a multicast controller at ONU side, which will act as the main performer of the IPTV multicast control. MAC/port

CH

MAC/port

CH list

02:01:E9..EF/port1

CH5

02:01:E9..EF/port1

CH1, CH2…CH20

Ch request

OLT

Multicast stream

MCA-usr mapping table

CH access table

IGMP snooping

CH access control

IGMP filter

Multicast-unicast conversion

Subscribers can not access unsubscribed channel!

Ch request unicast stream

IPTV Client

MLLID management table Multicast controller

Saved bandwidth: Only forward the requested multicast streams!

MLLID

MAC/port

CH

#12

02:01:E9..EF/port1

CH5

#12

11:1A:BF..08/port2

CH5

Avoid non-subscribers receive multicast streams!

Figure 3. Design of the Multicast Controller Fig.3 shows the detailed design of the multicast controller. It consists of four modules: 1) the channel access control module is responsible for accepting/rejecting the IGMP request from the user according to the channel access table which maintains the channel list corresponding to each MAC address of the user; 2) the IGMP snooping module is responsible for listening to the IGMP request and recording the

requesting port of each channel request; 3) the IGMP filter module is responsible for setting the MLLID filter list in the MLLD management table and filtering the multicast stream to the user according to this table; 4) the multicast-unicast conversion module is responsible for converting the filtered multicast stream to unicast streams with respective destination address indicated by the MLLID management table and unicasting them to each destination user who has requested this channel. With the multicast controller, ONU can enhance the multicast control function by rejecting the IGMP request if users request an unsubscribed channel, saving bandwidth resources through filtering the requested channel and improving the membership control function through avoiding non-subscribers receiving the multicast stream.

3.3 Multicast Control Procedure The multicast control may occur in the following procedure: user registration procedure which also means user authentication, the channel subscription procedure, the IPTV channel join procedure, and the IPTV channel leave procedure. In addition, the multicast controller will act as a very important role, which can be easily seen from the following description. 1) Registration/subscription procedure The user needs to perform the registration procedure when he selects the IPTV service and needs to perform subscription procedure when he subscribes a new channel. During the registration procedure, firstly the user sends the service registration request to the management portal. Then after the user passes the authentication, the CH manager will send the channel access list of this user to the ONU and the ONU will update the channel access table. After registration, when user wants to subscribe a new IPTV channel, the subscription procedure is as the following: firstly the user sends the subscription request to the CH manager through the management portal; after the CH manager confirms that this request can be accepted, it will update the corresponding channel list and send the updated channel list to ONU; thereafter, the ONU will update the channel access list accordingly. Similarly, the unsubscription procedure can be known. The sequence diagram of registration/ subscription procedure is as shown in Fig.4.

IPTV server

Management Portal

Radius

CH manager

Multicast controller(ONU)

OLT

Client

IPTV Multicast stream Service registration request

Authentication response

Registrat ion

Update CH access table

CH access list request CH access list OK

New CH Subscription request

Subscrip tion

New CH Subscription request updated CH access list OK

Figure 4. Sequence diagram of the registration/subscription procedure 2) IPTV channel join procedure The user needs to perform the IPTV channel join procedure when he switches to a new channel. Given the assumption that the requested channel already exists, the IPTV channel join procedure is as follows: firstly the user sends the IGMP request to the ONU; the multicast controller will check the channel access table and decide to accept or reject this IGMP request; if the requested channel is in the channel access list, it snoops the IGMP message and set the filter by adding the record in the MLLD management table; since the requested channel already exists and has arrived at the ONU, the ONU will directly convert the requested multicast stream to unicast stream with the destination address of the requesting user and deliver the unicast stream to the requesting user; at the same time, the ONU forwards the IGMP request to the OLT and the OLT will start up IGMP proxy to judge whether to forward the request to the multicast router or not. If the requested channel already exists, it will drop the IGMP request; otherwise, it will forward the IGMP request to the uplink router and the router will deliver the requested multicast stream to the OLT; when the OLT receives a new channel, it will assign MLLID to the channel and deliver it to the ONUs; then after the ONU receives the multicast stream, it will forward them to the destination user. The sequence diagram is as shown in Fig. 5. Obviously, during this procedure, the channel switching time can be shortened if the requested channel already exists in the access network.

IPTV server

Router

Multicast controller(ONU)

OLT

Client

IPTV multicast stream IGMP Join

① Check CH access table ② Judge if accepting/ rejecting the request

③ Snoop IGMP msg ④ Set the filter

⑤ Filter multicast stream ⑥ convert to unicast stream IGMP Join

① IGMP proxy ② Judge if forwarding

Unicast stream

IGMP request or not

③ Check multicast source ④ Assign/add MLLID

IGMP Join

Playing

multicast stream(MLLID)

Figure 5. Sequence diagram of the IPTV channel join procedure 3) IPTV channel leave procedure When the user chooses to leave the present channel, for example, switch channel or turn off TV, he needs to perform the IPTV channel leave procedure as shown in Fig.6. With the multicast controller, the ONU can stop forwarding the exited channel immediately when it receives the IGMP leave request. While in normal leave procedure, the user has to wait until the IGMP leave request is forwarded to the multicast router and the multicast router decides to stop forwarding the stream. Thus the bandwidth utilization between the OLT and ONU can be improved greatly. IPTV server

Router

Table 1. System configuration of multicast controller CPU Frequency

3.60GHZ

Memory

2G

Network connection

Upstream Eth0: 1Gbps Downstream Eth1: 100Mbps

OS

Federo Core 4

Channel bandwidth

20M HDTV

CH manager Eth1

Multicast controller(ONU)

OLT

Based on the design of the multicast controller described in the previous sections, we implemented this multicast controller over Linux platform. In order to validate the feasibility and efficiency of the multicast controller, we evaluate this software through a real system demonstration. Fig.7 shows the network architecture of the test scenario. The multicast controller is installed in a desktop PC, which has direct connects with the ONU and the IPTV client. The system configuration of the desktop PC is as shown in Table 1. The evaluation results show that the multicast controller can not only implement the basic control functions such as the IGMP snooping, channel control and multicast stream filtering and so on but also provide high processing performance.

Multicast Router

IPTV Server

Eth0

Client

IPTV Client 1

IPTV multicast stream

Multicast Controller

ONU1

IGMP Lea ve

① Check MLLID management table ② Delete the user record ③ Stop forwarding if no other receiver Stop forwarding the exited multicast stream

① Delete the ONU in the

ONU2 OLT

IPTV Client 2

ONU5

No Play

IGMP Leave

IPTV Client 5

MCA-ONU mapping table

② Stop forwarding to the ONU if no receiver Stop forwarding to ONU IGMP Leave

③ Judge if forwarding IGMP leave to router ④ Forward if no ONU receiving this stream

Figure 6. Sequence diagram of the IPTV channel leave procedure

4. Performance evaluation

Figure 7. Test scenario architecture Table 2 and Table 3 list the variety of the CPU usage and memory usage with the increase of the processing capacity. From table 2, we can see that the system resource consumption can retain a very low level even when the receiving bandwidth rises up to 200Mbps. The result shown in table 3 also seems very exciting, which indicates that the system performance still keeps stable even when the forwarding channel number is 4 that is very close to the maximum channel number 5 (for the bandwidth provided by eth1 interface is 100Mbps).

Table 2. The receiving processing ability evaluation Receiving BW on eth0(Mbps)

CPU usage (%)

Mem usage (%)

20 (1ch)

0.3~2

0.1

40 (2ch)

0.7~5

0.1

80(4ch)

0.7~5

0.2

160 (8ch)

1.0~13

0.2

200(10ch)

2.7~15

0.2

Table 3. The forwarding processing ability evaluation Forwarding BW on eth1(Mbps)

CPU usage (%)

Mem usage (%)

20 (1ch)

2.7~15

0.2

40 (2ch)

3.7~15

0.2

60 (3ch)

2.0~20

0.2

80(4ch)

3.7~20

0.2

Table 4. The comparison of the channel zapping time With/without multicast controller

Channel zapping time (msec)

Without

7.975935

With

2.012695

Table 4 lists the comparison result of the channel zapping time with/without the multicast controller existing. Here, for the convenience of measurement, the channel zapping time is defined as the latency between the IGMP join request sent and the receipt of the first frame of the new channel. From table 4, it is easily can be seen that the channel zapping time with multicast controller decrease from about 8ms to 2ms, which further demonstrates that the multicast controller can manage and control the multicast session effectively.

5. Conclusions In this paper, we have presented an IPTV multicast control solution over EPON to improve the management and control ability of the IPTV multicast service for the service providers. Based on the solution architecture, we successfully developed the core component multicast controller. The evaluation results demonstrated that the multicast controller not only can achieve high processing performance but also can manage and control the multicast traffic effectively. Our future work will develop the IPTV multicast control function with respect to measurement factor. In addition, we will also pay attention the IPTV multicast

control issue on the convergence network of PON and wireless network.

6. References [1] J. Wu, H.Ikeda, O.Takada, and H.Yoshiuchi, “Automatic VLAN Translation Service over Ethernet Passive Optical Network”, Proc of SPIE, Vol. 6354-75, Sep 2006 [2] S. Deering, “Host Extension for IP Multicasting”, RFC 1112. [3] Palin Yang, “Multicast control function for the IPTV service in NACF”, Contributions of ITU-T FG IPTV WG4, 2nd FG IPTV meeting, Oct 2006. [4] R. Lehtonen, J. Harju, “ Controlled multicast framework”, Proc of Local Computer Networks 2002, Nov 2002, pp.565-571 [5] O.Karppinen, O.Alanen, T. Hamalainen, “Multicast access control concept for xDSL-customers”, Proc of Consumer Communications and Networking Conference 2006 (CCNC2006), Vol.1, Jan 2006, pp.448-452 [6] J. Song, and J. Kim, “Multicasting in EPON”, Presentation on IEEE802.3ah EFM, Sep 2002. [7] Jun Wang, Limin Sun, Xiu Jiang, Zhimei Wu, “IGMP snooping: a VLAN-based multicast protocol,” Proc. of High Speed Networks and Multimedia Communications 5th IEEE International Conference, pp335-340, July 2002. [8] W. Park, C. Choi, Y. Jeong, and I. Han, “An Implementation of the Broadband Home Gateway supporting Multi-Channel IPTV Service”, Proc of 2006 IEEE Tenth International Symposium on Consumer Electronics (ISCE’06), Jun 2006, pp.1-5 [9] S. Wadhwa, J. Moisand, S. Subramanian, T. Haag, N. Voigt, “Protocol for Access Node Control Mechanism in Broadband Networks ”, draft-ietf-ancp-protocol-00.txt, Feb 2007 [10] M. Tammi, “Implementation and Performance Evaluation of Multicast Control Protocol”, Master of Science Thesis, Dept. of Information Technology, Tampere University of Technology, May 2004. [11] Yong-il, Seo, “IPTV multicast frameworks”, Output of ITU-T FG IPTV WG4, 3rd FG IPTV meeting, Jan 2007 [12] Linli Lu, “IPTV Network Control Aspects”, Output of ITU-T FG IPTV WG4, 2nd FG IPTV meeting, Oct 2006. [13] M. Takizawa, T. Yokomoto, “Multicast Logical Link for 10G-EPON”, Presentation on 10 Gb/s PHY for EPON Study Group, IEEE802.3 Interim meeting, May 2006.