• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
010.doc
 

010.doc

on

  • 434 views

 

Statistics

Views

Total Views
434
Views on SlideShare
434
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    010.doc 010.doc Document Transcript

    • Multicast traffic coordinator framework for real-time multimedia over residential networks Chin Hooi Tang and Tat Chee Wan Network Research Group School of Computer Sciences University of Science Malaysia 11800 Penang, Malaysia hooiye@network2.cs.usm.my Abstract: The use of multicast applications such as remote education, video conferencing and Voice over IP (VoIP) within organizations is increasing. Simultaneously, such applications are beginning to penetrate the home environment due to the advent of telecommuting, where they facilitate discussions, virtual meetings, and multiparty chats among home and business users. The widespread deployment of such multicast applications posts a significant challenge for shared residential broadband networks such as Hybrid Fiber Coaxial (HFC), where multicast traffic may overload available network bandwidth and trigger network congestion. The objective of this paper is to discuss issues related to deploying RSVP and DiffServ for multicast control on such networks, and to propose the Multicast Traffic Coordinator Framework as an alternative approach to handle multicast traffic by implementing multicast bandwidth management control on residential networks. Keywords: Bandwidth Management, Traffic Manager (TM), Multicast Firewall (MF) WAN Network Upstream Center MF Hosts and/or Residential Gateways Downstream with TM installed MTCF components : Residential Subnetwork 1 Traffic Manager (TM) Multicast Firewall (MF) Residential Subnetwork 2 Residential Subnetwork 3 Figure 1: Residential Network incorporating Multicast Traffic Controller Framework Introduction Multicast capable applications are becoming for residential networks, since multicast traffic more prevalent in recent years, because may overload available network bandwidths and traditional unicast applications do not support trigger the network congestion. In this interactive multiparty applications such as remote circumstance, Quality of Service (QoS) education, video conferencing, voice over IP mechanisms can potentially be used to smoothen (VoIP) and multimedia streaming efficiently. This and regulate the network traffic. trend coincides with the development of Gigabit networking, ATM, DSL and other high-speed Nonetheless, traditional QoS mechanisms such as network technologies. Bandwidths for residential Resource Reservation Protocol (RSVP) and users are increasing beyond PSTN speeds, via the Differentiated Services (DiffServ) have inherent development of shared residential networks such complexities or configuration issues, with limited as Hybrid Fiber Coaxial (HFC) technology . support in most shared networking environments. However, the widespread deployment of In addition, these mechanisms have not been multicast applications posts a significant problem proven for multicast traffic control. 194
    • Resource Reservation Protocol (RSVP) network resources to the extent that non-multicast and Differentiated Services (DiffServ) applications are unable to function. MTCF can be implemented at HFC network centers connected The Resource Reservation Protocol (RSVP) has to several residential subnetworks in order to been proposed by IETF to enforce network QoS smoothen the flow of unicast and multicast by allowing resource reservation for specific data packets among these neighborhood subnetworks, flows. Resource reservations can be setup along where home users are connected via cable the transmission path between the sender and modems. This scenario is shown in Figure 1. receiver. Nonetheless, there are several problems such as scaling and policy control that prevents it The architecture of MTCF is simple and it from being widely deployed . comprises two components, namely Traffic Managers (TMs) and a Multicast Firewall (MF). RSVP possesses poor scaling ability because it The MF operates in parallel with normal routers was not possible to support large number of to interconnect two or more residential reservations within each router along the subnetworks within a network domain. The router reservation path. Another issue is the current handles unicast traffic while the MF handles RSVP specifications only defines a mechanism multicast traffic . Effectively, there are no for transporting policy information along with additional functions needed in routers to support reservations, but does not define policy itself. multicast traffic, since the MF addresses the lack of multicast support in most routers. TMs can be Differentiated Services (DiffServ) was designed incrementally deployed to residential gateways or to address the scalability limitation of RSVP by hosts to enable full MTCF functionality. The excluding the need for per-flow state and focus of this framework is to address multicast signaling at every hop . This approach makes use bandwidth management issues only, since unicast of the TOS octet in IPv4 or the Traffic Class octet bandwidth management can be handled by the in IPv6 to perform the service classifications router using DiffServ or other QoS mechanisms. (labeled as DS field). The routers forward those packets to receivers according to this DS field. In a MTCF-compliant network, a TM is installed Nonetheless, in the context of multicasting, there in the residential gateway or host nodes. The are still very few routers that support multicast . Shaper within TM shapes the multicast data Boundary DiffServ routers are also expected to source from the sender to a consistent traffic perform additional functions such as packet profile. Before packets are transmitted from the classification, marking, shaping and policing . multicast data source, the traffic condition of This makes the installation and setup of DiffServ destination subnetworks is used to select an enabled networks very complex and expensive. appropriate traffic shaping profile. Transmitted packets are delivered to the network center for With respect to Service Level Agreements (SLA) forwarding to receiving hosts. Multicast packets between service providers and users, both RSVP would be processed by MF before arriving at the and DiffServ require comprehensive and detailed various destination subnetworks. The function of SLAs in order to deploy specific QoS for users. the MF is to enforce preset bandwidth This procedure normally takes time and may vary management policies, where a percentage of the among different ISPs. In contrast, MTCF can be network bandwidth is allocated for unicast traffic deployed independently of SLAs since it only and the loading of multicast traffic can be requires real-time traffic feedback from adjusted dynamically to not exceed a certain destination subnetworks to adapt the offered threshold. The details of MTCF are shown in multicast traffic to available bandwidths via Figure 2. Bandwidth Management Controls. Traffic Manager (TM) Components of the Multicast Traffic Coordinator Framework (MTCF) The TM is installed in residential gateways or host nodes, as part of the network stack within the The Multicast Traffic Coordinator Framework Data Link Layer. Although the availability of the (MTCF) is designed to implement Multicast TM is not critical to the operation of the Multicast Bandwidth Management in place of guaranteed Firewall, its function is to condition multicast multicast QoS over shared residential networks. traffic to optimize throughput and performance Multicast Bandwidth Management aims to within the MTCF. prevent multicast traffic from overwhelming 195
    • Unicast Data Multicast Data Traffic Bandwidth Sampling Mechanism Traffic Network Stack (TCP/IP) Bandwidth Bandwidth Filter Multicast Feedback Usage Policy Unicast Bandwidth Filter Multicast Prioritization Traffic Priority Filter Shaping Traffic Policy Manager Shaper Multicast Firewall Host To Receivers Subnet Traffic LAN DiffServ Intranet Router Figure 2: Details of MTCF Components MDT: Multicast Data Traffic NET: Network Stack Subnet 2 TM: Traffic Manager Subnet 1 Feedback Multicast Data Unicast Data MDT MDT NET NET Multicast Firewall TM TM DS Router Subnet 3 Network Center Figure 3: Interaction of Traffic Manager, Multicast Firewall, and Router The multicast data source from the sender is overloading the destination subnetworks with shaped to a consistent traffic profile by the multicast traffic. Further aggregate bandwidth Shaper. Traffic is shaped based on the traffic control is performed at the MF to prevent rogue condition of the destination subnetworks for a hosts or hosts that do not implement TM from given multicast group. Before packets are overwhelming the respective destination transmitted from the multicast data source, the subnetworks. This is illustrated in Figure 3. traffic condition of destination subnetworks is used to determine the Transmission Rate of the Multicast Firewall (MF) source. Thus the MTCF is dynamic and adjusts its performance in accordance to current network The Multicast Firewall is defined in . Its role is to conditions within the destination subnetworks. enforce preset bandwidth usage policies Multicast data from the sending host will then be determined by the network administrator, where a received by the Multicast Firewall and forwarded percentage of the subnetwork bandwidth is to the respective destination subnetworks. In HFC allocated for unicast traffic and the loading of networks, downstream transmission by the multicast traffic can be adjusted dynamically to headend into the source subnet is treated as not exceed a certain threshold. This ensures that transmission into a separate destination subnet. both unicast and multicast applications can coexist within the same subnetwork without the The TM receives feedback regarding the current need for extensive QoS controls. It is assumed traffic condition of the destination subnetworks that the MF interconnects all subnetworks within for its multicast group via Feedback the residential network; so multicast packets announcements from the MF. Based on the encounter only two hops from source to feedback, multicast traffic is shaped to avoid destination nodes (via the MF). 196
    • Bandwidth Management Control Feedback Figure 2 illustrates the Bandwidth Management The TM utilizes information regarding the traffic Control function in the MTCF. Since most condition of each destination subnetwork and multicast applications are based on UDP and lack bandwidth usage policy to shape the multicast the congestion avoidance windowing feature of data. Feedback of given data is transmitted as TCP , bandwidth management control is periodic Feedback announcements from the MF necessary to prevent such applications from via well know multicast group addresses on all overloading destination subnetworks. Lower subnetworks with active source nodes. It is Subnetwork Bandwidth Threshold (LSBT) and assumed that Feedback traffic consumes a Upper Subnetwork Bandwidth Threshold (USBT) negligible portion of the total bandwidth, by are defined to enable both the TM and MF to careful control of the frequency of updates. perform its bandwidth management function. Upstream traffic condition of the source subnetwork is also included in the Feedback to Multicast traffic is shaped by the TM and MF assist the TM in implementing the bandwidth before being forwarded to receivers in the filtering and shaping policy. Feedback data respective subnetworks, whereas unicast traffic is consist of Available Source Bandwidth (ASBW) forwarded as is to the respective receivers via the and Available Destination Bandwidth (ADBW) router. For HFC networks, the MF forwards for each destination subnet (including multicast traffic to the head-end for downstream downstream bandwidth of the source subnet) as transmission to nodes in its source subnet based measured by the MF. on the bandwidth utilization. Thus overloading of the source subnet is prevented as well. ASBW = Source USBT – Current Source Subnet Bandwidth Utilization Bandwidth Management Control in MTCF is performed via the following modules: ADBW = Destination USBT – Current Destination Subnet Bandwidth Utilization (Shaping Policy Dependent) A Bandwidth Sampling Mechanism in the MF to gather statistics on subnetwork traffic in Consequently, all multicast streams compete for real time and provide Feedback to the TM in available subnet bandwidth, and is arbitrated by active source nodes the MF based on their priorities. A Bandwidth Filter and Shaper that shapes Bandwidth Filter multicast traffic based on a given Shaping Policy within the TM Unicast packets are transmitted without modification, while multicast packets are sent to A Shaping Policy that defines shaping criteria the Bandwidth Filter and Shaper. LSBT and of multicast traffic in the TM USBT are used for bandwidth filtering and shaping. Fundamental traffic control is achieved A Bandwidth Filter and multicast using the Bandwidth Filter based on Feedback Prioritization Filter to control forwarding messages. Multicast traffic is automatically behavior of multicast packets within the MF forwarded if utilization is less than LSBT. A Bandwidth Usage Policy and Multicast Offered traffic exceeding USBT will be Traffic Priority that denotes multicast selectively dropped. prioritization in the MF Shaper Operation of the Traffic Manager The Shaper ensures that the packet transmission In order to implement end-to-end multicast rate into the current subnetwork does not exceed bandwidth management support, each residential the capability of destination subnetworks to gateway or source node is equipped with a TM. receive those packets. The Shaper shapes the The TM manages multicast data transmission traffic according to the Shaping Policy. The from the hosts, while unicast data is handled by offered outbound multicast traffic priority, the network stack without modification. bandwidth and delay requirements are constrained within the chosen profile. 197
    • Shaping Policy Optimal Quality Service seeks to specify an average bandwidth requirement that can be Three classes of service are specified with carried on most destination subnetworks, so that a different bandwidth allocation. They are majority of receivers can receive reasonable Maximized Quality Service, Optimal Quality quality multicast transmission from the source. Service and Equal Quality Service. yavg = gavg(ADBWi) = Avg{ADBW1, ADBW2, …} Each service class profile has a different Target Transmission Rate f(x,y,z) for bandwidth control Equal Quality Service uses the minimum from sender node to the destination nodes. f(x,y,z) available subnetwork bandwidth to specify a is defined as the minimum value of: x = traffic profile that could be carried on all Application Required Bandwidth; y = ASBW and destination subnetworks. This is a minimal z = g(ADBWi) (based on given service profile). performance profile intended to provide all users with some common level of service. Target Transmission Rate f(x,y,z) = Min(App. Required Bandwidth, ASBW, g(ADBWi)) ymin = gmin(ADBWi) = Min{ADBW1, ADBW2, …} The determination of Network Service Policy is Bandwidth Management not within the scope of this paper, it is assumed to be allocated by the ISP. The Shaping Policy is When Feedback messages are received by the summarized in Table 1. Traffic Manager, the Target Transmission Rate (TTR) acquired from the service profile f(x,y,z) is Service Forwarding Traffic Condition compared with the Current Transmission Rate Class Behavior (CTR) of the source to determine the actual Maximized Multicast Sender subnet traffic transmission rate to destination nodes. Quality Receivers is within shaping performance profile, offered Adjustment to the CTR uses a parameter m as a depends on multicast traffic rate-increasing/decreasing factor . From , it is respective bandwidth is based shown that the given rate increase and decrease subnetwork on least congested traffic dest subnet mechanisms are effective in controlling the Optimal Multicast Sender subnet traffic source traffic to the desired rate. ε denotes Quality Receivers within shaping convergence of CTR to TTR. performance profile, offered depends on multicast traffic If (| CTR – TTR | < ε): CTRi = CTRi -1 majority bandwidth is based subnetwork on average of dest Else if (CTR < TTR): CTRi = CTRi -1 traffic subnet traffic ×m Equal Multicast Sender subnet traffic Else if (CTR > TTR): CTRi = CTRi -1 Quality Receivers within shaping ÷m performance profile, offered depends on multicast traffic Operation of the Multicast Firewall worst case bandwidth is based subnetwork on most congested The Multicast Firewall acts both as a multicast traffic dest subnet forwarder and a Bandwidth Manager to regulate Table 1: Shaping Policy for Traffic Manager the transmission of multicast data among Shaping Profile interconnected subnetworks. Multicast packets received from one subnetwork is forwarded to Maximized Quality Service is intended to give receivers on other subnetworks belonging to the each destination receiver the best possible service same multicast group. Since all subnetworks are within the constraints of its available subnetwork interconnected through the ISP network center, bandwidth. In a lightly used subnetwork, no additional tunneling traffic is generated as a receivers will receive the highest possible quality result of multicast data transmission . multicast transmission, while receivers in a heavily loaded subnetwork can potentially have Bandwidth Usage Policy and Multicast low or no service depending on the available Traffic Priority bandwidth due to packet dropping at the MF. It is important to note that the Bandwidth Usage ymax = gmax(ADBWi) = Max{ADBW1, ADBW2, …} Policy and Multicast Traffic Priority allow the 198
    • network administrator control over the LSBT and subnetworks without affecting other unicast USBT. Prioritization is implemented based on the applications. The Bandwidth Sampling group multicast address to arbitrate among Mechanism of the Multicast Firewall tracks competing streams. This mechanism improves traffic condition of each subnetwork in real time. multicast performance by considering traffic This provides the Traffic Manager with suitable loading on destination subnets. Priorities can be Feedback to control transmission behavior of set using SLAs or dynamically (e.g. First Come multicast data streams. The specification of the First Server). Once the policy and priorities are Bandwidth Usage Policy and Multicast Traffic set, the MF operates without user involvement. Priority within the Multicast Firewall enables automated priority configuration without the need Bandwidth Sampling Mechanism for user intervention. This avoids the issue of Service Level Agreement (SLA) negotiation and The MF Bandwidth Sampling Mechanism is dependencies on other routers in order for the unique to MTCF and measures traffic on each Multicast Firewall to perform its function. subnet. HFC upstream and downstream statistics are calculated separately. Statistics such as total References packets, type of packets, and percentage bandwidth utilization of the subnet are calculated [1] Chatschik Bisdikian, Kiyoshi Maruyama, in real time, and transmitted as Feedback David I. Seidman, Dimitrios N. Serpanos, messages to the respective subnet. Bandwidth and “Cable Access Beyond the Hype: On Prioritization filters utilize these statistics to Residential Broadband Data Services over perform per-hop drop/forward decision and HFC Networks,” IEEE Communications optimize the bandwidth utilization within the Magazine, Vol 34, November 1996. shared media subnet. This approach provides better control since it matches the forwarded [2] A Mankin, ED., et. al., “Resource traffic with the carrying capacity of shared media ReSerVation Protocol (RSVP) – Version 1 subnets, in contrast with DiffServ which bases its Applicability Statement: Some Guidelines on forwarding decisions on internal router queue Deployment” RFC 2208, IETF, Sep. 1997, lengths. On the other hand, a RSVP enabled http://www.ietf.org/rfc/rfc2208.txt network checks for bandwidth availability at each node along the delivery path before any flows are [3] K.Nichols, S. Blake, F. Baker, D. Black, established, which consumes time and does not “Definition of the Differentiated Services guarantee capacity on shared media subnets. Field (DS Field) in the IPv4 and IPv6 Headers,” RFC2474, IETF, Dec. 1998, http:// Bandwidth and Prioritization Filters www.ietf.org/rfc/rfc2474.txt Basic multicast traffic control is performed using [4] P.Ferguson, G.Huston, “Quality of Service on the Bandwidth Filter. The Bandwidth Filter will the Internet: Fact, Fiction or Compromise?” forward multicast traffic if the destination subnet Proceedings INET ’98, bandwidth utilization is lower than LSBT and http://www.telstra.net/gih/inet98/index.html drops packets if the utilization is above USBT. [5] X. Xiao, Lionel M. Ni, “Internet QoS: the Big If the bandwidth utilization of the destination Picture,” IEEE Network Magazine, Vol. 13, subnetwork is between the two thresholds, the March 1999. Prioritization Filter classifies packet and only forwards those packets with priority threshold [6] T. C. Wan, C. H. Leong, R. C. W. Thum, above the current bandwidth utilization. This per- “Multicast Firewall for Intranet Multimedia hop mechanism in MTCF provides scalability in a Applications,” Proceedings WEC '99, manner similar to DiffServ. Subang, Kuala Lumpur, Malaysia, Jul. 19-22, 1999. Conclusion [7] Cisco white paper, “Overview of IP The implementation of the Multicast Traffic Multicast,” Cisco Systems Inc., Sep. 1999, Coordinator Framework resolves the multicast http://www.cisco.com/warp/public/cc/cisco/m deployment issue by supporting incremental kt/ios/mcastip/tech/ipmc_wp.htm deployment. Therefore real-time multimedia applications may be adopted within residential [8] M. Yamamoto, Y. Sawa, S. Fukatsu, H. Ikeda, “NAK-based Flow Control Scheme for 199
    • Reliable Multicast Communications,” Proc. TENCON 2000, Kuala Lumpur, Malaysia, Sep. 24-27, 2000. 200