Building Multicast Controller for Carrier-grade IPTV Service over Ethernet Passive Optical Network

Transcription

1 Building Controller for Carrier-grade 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 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 (Internet Protocol Television). To deploy the carrier-grade service, especially HDTV (High Definition TV), it is very essential to construct a controllable multicast architecture for 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,, 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, 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 service. To deploy the carrier-grade 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. 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 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 service efficiently. This paper presents a multicast control solution for 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

2 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 Service over EPON Fig.1 shows the general system architecture of multicast service over EPON. Basically, it consists of four parts: the, the multicast router, the EPON system and the client. The is used to generate the multicast streams to the network. Each multicast group represents an channel. When the user changes to another 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 to the access network by setting up a multicast routing. Core Network replication point splitter stream STB Client 1 ONU #1 STB Client 2 STB Client m ONU #n STB Client n IGMP request stream Figure 1. System architecture of multicast 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 (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 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 can play the role of multicast router to perform the multicast replication function. The client can be a set of box with a normal TV, which is used to receive the multicast stream and play them. The procedure of the multicast over EPON is like this: firstly the client sends an IGMP join request to the ONU and ONU will forward it to the. When the 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. 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 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. 2.3 Considerations on Control for service over EPON To deploy the carrier-grade 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 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 ( Control Protocol) [10]. ITU-T FG also has contributed some drafts on the multicast control requirement for service in [11] [12]. Here combining the feature of EPON system, we summarize the multicast control requirement for service as the following: 1) membership authentication; 2) membership control; 3) channel management; 4) source check. 3. multicast control solution over EPON Our main goal is to design a controllable and manageable multicast solution over EPON for

3 the service providers by satisfying the requirements mentioned above. 3.1 Framework of Control Solution over EPON The framework of 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 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. IP TV MCA/CH MCA assignment CH manager User/ Ch list Ch management IGMP proxy source check Multicas t source access table accounting MCA-ONU mapping table MLLID assignment accounting profile MC A- MLLID mapping table Radius User/ password Fiber splitter register MC A-usr mapping table IGMP snooping IGMP filter web portal Management Portal controller Figure 2. multicast control solution over EPON IP TV client 1) Management Portal is the centric based access portal for the clients. When users want to register the system to receive multicast stream or subscribe/unsubscribe some 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 channel. It is responsible for assigning a multicast address for a newly emerging channel on the and maintaining a global auth ONU subscription table control -unicast conversion MLLID management table mapping table between the multicast address and the channel number. 4) is enhanced by adding the IGMP proxy module, multicast source check module and the MLLID ( 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 which ONUs the multicast stream should be forwarded to. For the incoming downstream multicast stream, the 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 stream to each user. The detailed information on the multicast controller will be described in the next part. 3.2 Design of the 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 multicast control. MAC/port 02:01:E9..EF/port1 Ch request stream Saved bandwidth: Only forward the requested multicast streams! CH CH5 02:01:E9..EF/port1 MCA-usr mapping table IGMP snooping MLLID IGMP filter #12 #12 MAC/port controller table control -unicast conversion MLLID management table MAC/port CH list CH1, CH2 CH20 02:01:E9..EF/port1 CH5 11:1A:BF..08/port2 CH5 Ch request Figure 3. Design of the 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 CH Subscribers can not access unsubscribed channel! unicast stream Client Avoid non-subscribers receive multicast streams!

4 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 Control Procedure The multicast control may occur in the following procedure: user registration procedure which also means user authentication, the channel subscription procedure, the channel join procedure, and the 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 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 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. Management Portal stream Registrat ion Subscrip tion Authentication response Radius CH manager controller(onu) Client list request New CH Subscription request list updated list Service registration request New CH Subscription request Figure 4. Sequence diagram of the registration/subscription procedure 2) channel join procedure The user needs to perform the channel join procedure when he switches to a new channel. Given the assumption that the requested channel already exists, the 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 and the 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 ; when the 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. OK Update CH access table OK

5 multicast stream 1 IGMP proxy 2 Judge if forwarding IGMP request or not IGMP Join 1 Check table 2 Judge if accepting/ rejecting the request 3 Snoop IGMP msg 4 Set the filter IGMP Join controller(onu) 3 Check multicast source 4 Assign/add MLLID multicast stream(mllid) IGMP Join Unicast stream Client 5 Filter multicast stream 6 convert to unicast stream Playing Figure 5. Sequence diagram of the channel join procedure 3) 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 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 and ONU can be improved greatly. multicast stream 1 Check MLLID management table 2 Delete the user record 3 Stop forwarding if no other receiver Stop forwarding the exited multicast stream 1 Delete the ONU in the MCA-ONU mapping table 2 Stop forwarding to the ONU if no receiver Stop forwarding to ONU IGMP Leave IGMP Leave Figure 6. Sequence diagram of the channel leave procedure 4. Performance evaluation controller(onu) 3 Judge if forwarding IGMP leave to router 4 Forward if no ONU receiving this stream IGMP Leave Client No Play 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 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. Table 1. System configuration of multicast controller Client 1 Client 2 Client 5 CPU Frequency Memory Network connection OS Channel bandwidth Eth1 Controller CH manager Eth0 ONU1 ONU2 ONU5 3.60GHZ 2G Upstream Eth0: 1Gbps Downstream Eth1: 100Mbps Federo Core 4 20M HDTV 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). Server

6 Table 2. The receiving processing ability evaluation Receiving BW on eth0(mbps) 20 (1ch) 40 (2ch) 80(4ch) 160 (8ch) 200(10ch) Table 3. The forwarding processing ability evaluation Forwarding BW on eth1(mbps) 20 (1ch) 40 (2ch) 60 (3ch) 80(4ch) Table 4. The comparison of the channel zapping time With/without multicast controller Without With 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 CPU usage (%) 0.3~2 0.7~5 0.7~5 1.0~13 2.7~15 CPU usage (%) 2.7~15 3.7~15 2.0~20 3.7~20 Mem usage (%) Mem usage (%) Channel zapping time (msec) In this paper, we have presented an multicast control solution over EPON to improve the management and control ability of the 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 multicast control function with respect to measurement factor. In addition, we will also pay attention the 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 , Sep 2006 [2] S. Deering, Host Extension for IP ing, RFC [3] Palin Yang, control function for the service in NACF, Contributions of ITU-T FG WG4, 2nd FG meeting, Oct [4] R. Lehtonen, J. Harju, Controlled multicast framework, Proc of Local Computer Networks 2002, Nov 2002, pp [5] O.Karppinen, O.Alanen, T. Hamalainen, access control concept for xdsl-customers, Proc of Consumer Communications and Networking Conference 2006 (CCNC2006), Vol.1, Jan 2006, pp [6] J. Song, and J. Kim, ing in EPON, Presentation on IEEE802.3ah EFM, Sep [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, pp , July [8] W. Park, C. Choi, Y. Jeong, and I. Han, An Implementation of the Broadband Home Gateway supporting Multi-Channel 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 Control Protocol, Master of Science Thesis, Dept. of Information Technology, Tampere University of Technology, May [11] Yong-il, Seo, multicast frameworks, Output of ITU-T FG WG4, 3rd FG meeting, Jan 2007 [12] Linli Lu, Network Control Aspects, Output of ITU-T FG WG4, 2nd FG meeting, Oct [13] M. Takizawa, T. Yokomoto, Logical Link for 10G-EPON, Presentation on 10 Gb/s PHY for EPON Study Group, IEEE802.3 Interim meeting, May 2006.