1

SURPASS Carrier Ethernet

Best Practices in designing a Carrier Grade Metro Ethernet Network for Triple Play services

A white paper issued by: Siemens Communication – Fixed Networks Access

Overview The need to deliver IPTV as part of a triple-play bundle is no longer in question for service providers around the world. Increased competition from mobile service providers, internet telephony services and the entry of cable companies into the telecom market, all contribute to the continued attrition in ARPU and customer churn. The open question now is not whether to go into IPTV, but how fast, at what cost, and how to overcome the new challenges encountered by a business hitherto geared for selling voice telephony and high speed internet. Carrier Ethernet has established itself as the preferred basic technology in metropolitan networks designed to deliver IPTV and the entire triple-play package to residential customers. This is due to the low capital expense per bandwidth, high capacity platforms, and the low operating expenses resulting from the ubiquity of Ethernet. This paper deals with some of the main challenges encountered in the design of Carrier Ethernet networks in the IPTV context, and shows how these challenges can be effectively overcome with simple, innovative mechanisms and intelligent network planning.

2

Table of contents

1. Executive Summary 3

2. Addressing the scalability challenge 3 2.1. Bandwidth scalability 3 2.2. VLAN and MAC address scalability 6

2.2.1. VLAN scalability 6 2.2.2. MAC scalability 8 2.2.3. Hybrid Ethernet and MPLS topology 9

3. Efficient multicasting vs. quick zapping time 10

4. Guaranteeing a high level of user satisfaction 12

5. Addressing security threats 14

6. End-to-end solution or best of breed? 16

7. Alternative architectures 16

3

1. Executive Summary This paper addresses some of the main challenges encountered in the design of Carrier Ethernet networks in the IPTV context, and shows how these challenges can be effectively overcome with the SURPASS hiD 6600. Specifically it shows how: � The difficulties in significantly scaling up networks originally designed

for best-effort high-speed internet are overcome by the SURPASS hiD's Advanced Ethernet Package (AEP). AEP tools, such as advanced VLAN manipulation, VLAN Cross-Connect, QoS and multicasting techniques, combined with an intelligent and cost- efficient hybrid Ethernet-MPLS network design, do away with the scalability limitations inherent in Ethernet.

� Multicasting can be performed efficiently while reducing channel switching (zapping) time.

� Guaranteed and differentiated Quality of Service can be provided with the Advanced Ethernet Package, enhancing each specific customer's user experience, in accordance with the product bundle paid for by that customer.

� Security threats associated with IPTV delivery can be mitigated. � The Siemens tested end-to-end solution helps service providers

successfully introduce and expand triple play services. � A Layer 2-based architecture in the metro area performs better and is

less costly than alternates.

2. Addressing the scalability challenge

2.1. Bandwidth scalability The introduction of rich-media services, such as Broadcast TV (BTV), Video on Demand (VoD) and multiplayer games gives rise to unprecedented scalability requirements which may result in a need for a revitalization of network infrastructures and operations. Depending on the compression and coding technology, the following transmission rates per customer should be considered: � MPEG-2 coded Standard Definition (SD) VoD video streams or IP-TV

stream per TV channel: 3.5 – 5 Mb/s. At least 2 such channels should be made available per subscriber.

� H.264 (MPEG-4 part 10) coded SD VoD video streams or IP-TV stream per TV channel: up to 2 Mb/s

� HD signals will need 8-14Mb/s coded with H.264 The following table shows a possible service bundle for residential customers:

4

Downstream bandwidth per user

Number of instances per user

Total BW per user

Concurrent sessions in metro network

Overbook factor

Total BW per metro edge (50K subscribers)

BTV SDTV

3 Mb/s 2 6 Mb/s 160 1 0.48 Gb/s

BTV HDTV

9 Mb/s 1 9 Mb/s 40 1 0.36 Gb/s

VoD 3 M/ps 1 3 Mb/s 10% of subscribers

1 15 Gb/s

Gaming channel

256 kb/s 1 256 kb/s 10% of subscribers

1 1.28 Gb/s

VOIP

64 kb/s 2 128 kb/s 30% of subscribers

1 1.92 Gb/s

High Speed Internet

3 Mb/s 1 3 Mb/s 100% of subscribers

50 3 Gb/s

Total 21 Mb/s 22.04 Gb/s

The above rather conservative bandwidth estimates lead to the following conclusions: � Traditional ADSL access may not be enough and higher capacity

ADSL2+ or VDSL2 may be required to address the 20Mbps or more of bandwidth per user. The short distances between DSLAM and subscriber associated with VDSL result in a large number of small DSLAMs, increasing the desirability of simplifying DSLAM functionality for the benefit of cost and provisioning simplicity.

� The costs of delivering such high bandwidth should be carefully considered. A linear scaling of existing ATM networks or liberal overprovisioning prove to be extremely inefficient in terms of costs. Ethernet turns out to be the most cost effective method to deliver such bandwidths, due to its lower capital and operating expenses per bit compared with alternative transport technologies.

� VoD traffic constitutes the largest component in the overall bandwidth due to its unicast nature and high bandwidth per stream. It is also the most unpredictable in terms of concurrency and total bandwidth requirements since it is dependent on subscriber behavior and is a relatively new service with which carriers have little experience. Moreover, VoD may be used as an umbrella term for a number of unicast services such as Network based Personal Video Recorder (NPVR). It is therefore likely that VoD services will grow significantly beyond the 10% concurrency rate assumed above.

� The above BW requirements may push carriers to challenge the traditional single-edge approach inherited from early broadband

Table 1: Bandwidth requirements in a triple-play network

5

aggregation networks built for the delivery of high speed Internet. In this single-edge approach, all services attributed to one regional aggregation network flow through a single BRAS, making it a potential bottleneck. This concern may be addressed by using new high-capacity systems, thus avoiding re-engineering of the network topology. Alternately, carriers may choose the multiple-edge approach, where the metro core aggregation node connects to service-specific edge routers, each dedicated to a different service, as depicted in Figure 1. Both approaches are valid. Nevertheless the following must be considered: in the single-edge approach, the BRAS performs centralized policy enforcement and QoS, centralized subscriber management, and centralized multicast. The multiple-edge method requires that policy enforcement, including QoS and Security, be distributed to the aggregation switches. Similarly, multicasting is distributed to the metro and access and not simplistically centralized in one BRAS. More details on how QoS, security and multicasting are dealt with in the aggregation switches are provided below.

Access & Metro AggregationCPE

ISP

Internet

VPN

VoIP

Metro Aggregation

IP DSLAM

IP DSLAM

Internet

RGIPTV

Internet

RGIPTV

VoIP

VoIP

Metro Core

BRAS

PE

Local VoD servers

VoIP

BTV; VoD

Core

Going forward, bandwidth is expected to grow even further, if only to reinforce the trends highlighted above. Figure 2 shows one such projection as viewed by Verizon Inc, according to which bandwidth requirements per household could soar to over 50 Mbps within two to three years.

Figure 2: Verizon's view of access network bandwidth requirements

Figure 1: Offloading the BRAS

6

2.2. VLAN and MAC address scalability A recurring concern in the deployment of Ethernet-based networks is how to avoid exhaustion of scarce Ethernet resources. If we need to cater to tens of thousands of subscribers per aggregation domain, and to provide each subscriber with a number of differentiated services, can we rely on the notoriously limited VLAN space (4K VLANs) or the capacity of MAC tables? This is particularly worrying since VLANs are no longer used merely for limiting the broadcast domain but have many more uses such as traffic forwarding, user isolation, user identification, etc. 2.2.1. VLAN scalability Addressing the limited VLAN space requires a degree of sophistication and flexibility in manipulating the VLAN scheme. The VLAN scheme comprises the mapping of the different subscribers and services to the VLAN tags used to represent them in different segments of the network. VLAN manipulation is the tool used to create the VLAN scheme and includes: � VLAN stacking (or "QinQ"): Addition of an outer VLAN to the inner

one (e.g. in accordance with the port or inner VLAN). Stacking increases the VLAN range from 4K to 16M.

� VLAN translation: Changing the value of an outer and/or inner VLAN � VLAN swapping: Swapping between the outer and the inner VLAN � VLAN stripping: Removing a VLAN tag � Combinations of the above

The resulting VLAN scheme must allow the network to distinguish between the various services, to perform the forwarding task correctly, and to uniquely identify subscribers enabling proper subscriber management at the BRAS. The latter is particularly important when the IP address is assigned by an ISP and not the carrier, in which case identification of the subscriber based on an IP address is impossible. There are two approaches for connecting broadband users to the aggregation network. In general, these correspond to the DSL Forum's TR-101 1:1 and N:1 VLAN assignment paradigms. VLAN per subscriber This approach centers on the subscriber. An introduction of a new service would not require a new VLAN configuration. VLANs are stacked for scalability reasons, so that the inner VLAN identifies the subscriber’s port at the DSLAM and the outer VLAN identifies the DSLAM. Using this method, the BRAS can uniquely identify each subscriber, as the VLANs correspond to both the DSLAM and the port on the DSLAM to which the subscriber is connected. Besides the subscriber VLANs, a special multicast VLAN is used. The multicast VLAN is a service VLAN, which is single-tagged only. The MC-VLAN is used for distributing the multicast traffic (e.g. broadcast TV) from the IP edge to the DSLAMs and for transporting IGMP messages between the multicast router (BRAS or multicast edge router) and the multicast hosts (i.e. the Set-Top Boxes - STBs).

7

VLAN per service The second alternative is based on service-specific VLANs in the aggregation network. The basic goal is to optimize the delivery of different services through the access and aggregation networks. It now includes not only the MC-VLAN, but also specific VLANs for data services or voice services. It is the task of the residential gateway to forward the Ethernet frames on the appropriate service PVC or VLAN.

Combined alternative Figure 5 suggests a combined alternative which embodies the best of both worlds. In this, alternate services destined for the BRAS maintain the VLAN per subscriber approach in the metro to allow subscriber identification at the BRAS. Similarly, the multicast VLAN is used as before. However in this scheme, a VLAN per service approach is used at the access. This is done for the following reasons: � It allows an extremely simple configuration and pre-provisioning of the

residential gateway and the DSLAM, in a manner that needs no specific provisioning per access component. The RG always tags outgoing packets with a VLAN - identifying service , while the DSLAM adds a port identifying the outer VLAN. It is then the job of the first aggregation switch to perform the more sophisticated manipulation from the per-service mapping to the per-subscriber mapping. Since there are possibly tens of DSLAMs and thousands of RGs per each switch, there is much to be said for this simplification of the access components while leaving the complex tasks to the aggregation switch.

� This VLAN scheme allows the DSLAM to forward multicast traffic correctly without performing IGMP snooping or proxy but merely using

Figure 3: Reference architecture for VLAN per subscriber

Figure 4: Reference architecture for VLAN per service

8

the outer VLAN of incoming downstream packets. This again allows for a cost-reducing simplification of the DSLAM.

� This approach facilitates a targeted, per-subscriber and per- service QoS differentiation (as will be explained below) on the customer side of the first aggregation switch. Here, the outer VLAN identifies the DSLAM port (i.e. the subscriber) and the inner VLAN identifies the service.

� The hybrid approach enables per service VLAN mapping, allowing simple forwarding of those services circumventing the BRAS (e.g. wholesale VPN services).

The question still remains whether the VLAN scheme proposed above is scalable in a metro network serving hundreds of thousands of subscribers. Let's assume the following VLAN space division in the aggregation network: Outer VLANs 0-3000 are used for BRAS-based services and these identify the DSLAM. Outer VLANs 3001-4000 are used for wholesale services and identify the 3rd party service provider. One VLAN is also reserved for multicast, and an additional one (typically VLAN 4001) is reserved for in-band management. This scheme supports up to 3000 DSLAMs per aggregation domain and 1000 wholesale service providers. Even assuming particularly small DSLAMs serving only 50 customers each, this translates into 150K subscribers per aggregation domain, which is reasonable. This can be scaled further by using VLAN Cross-Connect, as explained below. Note also that this VLAN scheme allows for a theoretical 4000 subscribers per DSLAM - well above the available capacity. Another rather delicate concept worth pointing out in the above scheme is the following: Only one VLAN is used in the aggregation network for multicast traffic. However, between the first aggregation and the DSLAM, a separate outer VLAN per subscriber may be used in order to allow the DSLAM to correctly replicate and forward multicast traffic without performing IGMP snooping or proxy. This means that the aggregation switch must be capable of performing IGMP snooping and replication between the single upstream multicast VLAN and the video VLAN on each downstream link. The SURPASS hiD 6600 supports this capability, known as inter-VLAN bridging (a very similar concept is sometimes referred to as Multicast VLAN Registration - MVR).

2.2.2. MAC scalability Siemens' SURPASS hiD 6600 supports connection-oriented Ethernet technology, called VLAN Cross-Connect, in order to fully serve any number of subscribers in the metropolitan network. This concept can be considered

Figure 5: Combined VLAN scheme

9

an extrapolation of the time slot switching concept of TDM, or VPI/VCI switching in ATM. Each connection is identified by its inner and outer VLAN tags and its port. MAC learning is disabled and thus the forwarding decision is based on the port and VLAN tags. Since both inner and outer VLAN tags are considered in the forwarding decision, and since they only have local significance as connection identifiers, the total number of VLANs that can be supported is 16 million (4096 X 4096) per port. Hence, not only is the limitation on the number of MAC addresses eliminated (since the MAC is no longer relevant to the forwarding decision), but there is practically no limit to the number of VLANs at the network level. Connection-oriented Ethernet is fully interoperable with connectionless Ethernet; the two schemes can be deployed over the same node and even on a single port. This type of cross connect is most appropriate for point-to-point services and may be used e.g. for High-Speed Internet (HSI) or point-to-point VPNs. Hence, the number of supportable subscribers in the example of Figure 5 may be increased further. 2.2.3. Hybrid Ethernet and MPLS topology As shown above, advanced mechanisms and wise network planning can enable operators to overcome scalability problems sometimes associated with Ethernet without resorting to more complex technologies. Nevertheless, MPLS is well entrenched in most core networks. Bringing MPLS closer to the customers provides an alternative solution to the VLAN and MAC scalability issues presented above. It also provides benefits in terms of resilience (by means of Fast ReRoute), bandwidth protection and offloading of edge routers. A naïve interpretation of this capability would be to extend MPLS all the way down to the access nodes. However, this is complex and unnecessary due to the very large number of nodes in the access and metro. A wiser approach would be to extend MPLS to the metro core nodes while maintaining the Ethernet simplicity closer to the customer, as shown in Figure 6.

IP DSLAM

Internet

RGIPTV

Internet

RGIPTV

VoIP

VoIP

IGMP router

MPLS CoreMPLS Metro Core

Ethernet MPLS Ethernet

In this approach, a VPLS instance is dedicated to IPTV distribution in the metro core. The MPLS PE nodes could either perform IGMP snooping, allowing dynamic multicasting over the MPLS cloud, or be preconfigured for static multicasting.

Figure 6: Hybrid Ethernet MPLS topology

10

Resilience within the metro core is achieved by means of MPLS Fast ReRoute, in case of link failure. IGMP router resilience can be realized by two redundant routers. The standby router kicks in after a timeout period in which no general queries are received from the primary router.

3. Efficient multicasting vs. quick zapping time Ethernet provides a simple and straightforward way of multicasting broadcast TV channels. There are two ways of providing multicast over Ethernet: static and dynamic In the static configuration model (illustrated in Figure 7): � All channels are distributed by static configuration of L2 multicast

groups in all switches toward the DSLAM. � The DSLAM supports IGMP snooping/proxy. � The total bandwidth for all channels should be available across the

aggregation network. The static configuration provides a minimal channel change (a.k.a zapping) time.

When the first user requires a new channel in the dynamic configuration model (see Figure 8), an IGMP join request is sent across the aggregation network up to the IGMP termination point. When a second customer on that DSLAM requires the same channel, zapping time is faster, since the DSLAM switches the channel locally. In this case, no IGMP messages are sent upstream. Again, this requires the DSLAM to support IGMP snooping or proxy. Specifically in VDSL networks, where the short range of VDSL causes the number of subscribers per DSLAM to be very small, the last multicast replication point may also be the first aggregation switch instead of the DSLAM. Dynamic multicasting is clearly more optimized in terms of bandwidth utilization in the aggregation network, but zapping time is slower

Hybrid approach: The Siemens SURPASS hiD enables both static and dynamic configuration. The hybrid approach allows the carrier to enjoy the best of both worlds. The carrier can assign a subset of the TV channels, consisting of the most popular channels, over a static configuration. Hence, a reduced zapping time is achieved. Other channels, which are either intended for special interests, or more dynamic by nature (e.g. a pay-per-

Figure 7: Static multicasting

Figure 8: Dynamic multicasting

11

view program), can be provided over a dynamically assigned multicast stream in order to minimize bandwidth utilization. Clearly, there is a tradeoff between bandwidth efficiency and zapping time, which is an important element of user satisfaction. The challenge confronting the service provider is to deliver user satisfaction with minimal delay while not wasting network resources on unnecessary replications. Zapping delay, i.e. the time between remote control button pressing and the display of the first video frame on the viewing device, is mainly influenced by the following:

� processing of the remote control request � IGMP control processing (STB, RG, network) � Data plane protocol stack processing � STB jitter buffer delay � MPEG decoder delay for re-synchronizing with the new program

MPEG decoder delay usually comprises the biggest part of the overall delay budget. This is because of the nature of MPEG compression whereby the decoder must wait first for an "I-frame". This is sent only once every group of pictures (GOP) to start decoding. Decoder delay is also due to the fact that some frames ("B frames") are encoded using future frames. Since a high compression rate implies a large GOP with extensive use of B frames, there is a tradeoff between compression rate and the decoding delay. The required size of the jitter buffer depends on the jitter of the media stream received by the STB. The jitter generated by a well engineered high bandwidth IP network is less than 50 ms. The video source itself should also produce low jitter streams. The latency of IGMP processing in the network (e.g. the residential gateway, DSLAM and/or BRAS) also directly adds to the overall zapping delay. The sum of the last two network contributions to the latency is estimated to be less than 200 ms if an IGMP immediate leave option is in place. To reduce the IGMP processing component of the overall zapping time, the DSLAM or aggregation switch must perform IGMP snooping with fast leave processing, which is a modification of the normal IGMP Version 2 host state machine. In IGMPv2, when a router (IGMP server) receives an IGMP leave request from a host (IGMP client), it must first send an IGMP group-specific query to learn whether other hosts on the same access network are still requesting traffic reception. If after a specific time no host replies to the query, the router stops forwarding the traffic. This time-consuming query process is required because, in IGMP Versions 1 and 2, IGMP membership reports are suppressed if the same report has already been sent by another host in the network ("host suppression"). Therefore, it is impossible for the router to know reliably how many hosts are requesting that they receive traffic unless we can ascertain that there is only a single video STB per DSL line. Fast leave is the ability for a node that supports IGMP snooping to stop sending a multicast stream immediately upon the receipt of an IGMP leave request. The problem with fast leave combined with host suppression is that if two STBs attached to the same DSL line are tuned to the same channel, the first STB that tunes off causes the DSLAM or aggregation switch to stop sending the multicast stream for that channel, thereby interfering with the video continuity at the second STB.

12

IGMPv3 provides a solution whereby the snooping device keeps track of the IP source address associated with each IGMP join and leave request. Thus, it can stop sending a multicast stream to a particular DSL line when all IGMP hosts (as specified by the IP source address in each IGMP message) have issued IGMP leave requests. Another important advantage of IGMPv3 is the inherent protocol support for requesting the multicast stream for a specific group from a specific source server. As such, it is compatible with the PIM-SSM protocol, and together they are referred to as source-specific-multicast protocols.

4. Guaranteeing a high level of user satisfaction

Let us say that a customer decides to buy a triple-play package from the same service provider who previously only offered best-effort internet access. This customer will not tolerate degradation in quality compared with the satellite cable TV service they have become accustomed to. It is therefore of paramount importance to meet the stringent delay and jitter requirements of video and voice services, as would be expected from each specific service. Moreover, since different customers may pay for different product packages, a separate QoS profile must be maintained and assured for each. Traditionally, Ethernet is perceived as problematic in providing a differentiated and guaranteed QoS. Ethernet was designed as a connectionless technology. The difficulty in predicting the path taken by a given packet stream makes traffic engineering, aimed at guaranteeing QoS parameters such as bandwidth, delay, and jitter, challenging. This is specially so when it has to be done at a per-service and per-subscriber level. There are two principal methods to provide QoS over packet networks: � Per hop service differentiation: Traffic is prioritized at the ingress based

on certain rules (e.g. CE-VLAN, IP source and destination, etc.). The traffic is treated in each node along the path according to its priority. High priority traffic will always be served before that of low priority; It will therefore endure shorter delays and less packet loss than low priority traffic. The fact that no resources are reserved in the network provides an efficient "per usage bandwidth utilization". But this method cannot guarantee an end-to end bandwidth and QoS.

� ATM or TDM-like bandwidth allocation: According to this scheme, bandwidth is reserved along the path of the service, thus assuring end-to-end bandwidth and QoS at the expense of preserving specific resources for services. This method functions better in a connection-oriented model, where both the primary and the protection (secondary) path can be determined.

SURPASS hiD provides both schemes and allows carriers to enjoy the best of both worlds by mapping different services to different traffic classes. SURPASS hiD's QoS mechanisms include: policing, shaping, congestion avoidance, priority queuing, and Connection Admission Control (CAC). CAC is critical in regulating service provisioning to avoid a situation where the desired service quality cannot be guaranteed. Using the SURPASS hiD 6600's "enhanced QoS mode", the operator can take advantage of more than just the standard Diffserv capabilities. In conjunction with the CAC mechanism, the enhanced mode includes a rich set of both guaranteed and differential classes of service, six for unicast traffic and three for multicast. Thus, more delay and jitter-sensitive services like voice and video can be mapped into guaranteed bandwidth classes with different priorities, while

13

High Speed Internet traffic can still rely on Diffserv queues. Figure 9 depicts the enhanced QoS queuing mechanism, as well as one example of a service package mapping to the relevant queues.

The classification of traffic into the different traffic classes can be based on the VLAN tag, the priority bits as specified in 802.1p, or the TOS/DSCP field. Hierarchical QoS As stated above, triple-play service providers are likely to offer their subscribers a variety of service packages to choose from. This means that different subscribers may be delivered different service packages, which in turn require a different scheduling regime per subscriber. In addition, it is possible that the actual available bandwidth may differ from one subscriber to the next, depending e.g. on the physical condition of the DSL line. There are therefore two levels of scheduling among the different traffic queues: � Port level scheduling – Performed on the aggregate traffic according to

Traffic Class as described above. � Subscriber level scheduling – Performed in addition to port level

scheduling. Prioritization is performed separately for each subscriber, based on the subscriber profile (i.e. the allocation of bandwidth among the services bought by that subscriber), as well as on the actual bandwidth available for that subscriber.

The hierarchical QoS model supports both port and subscriber level scheduling. In addition it allows shaping on a per-port, per-subscriber and per-service level. In some cases this may be the responsibility of the BRAS, but in scenarios where the BRAS is offloaded, as described above, it is up to the aggregation switch to provide this per-subscriber hierarchical QoS on the ports facing the subscribers, as depicted in Figure 10.

Figure 9: Enhanced QoS with guaranteed bandwidth

Figure 10: Subscriber and port level scheduling

14

ANCP Access Node Control Protocol (ANCP), also known as Layer 2 Control Protocol implements a control plane between a service-oriented edge device (e.g. BRAS) and access nodes (e.g. DSLAM), which enables a set of QoS-related, service-related and customer-related operations. By using ANCP, the DSLAM notifies the BRAS or the aggregation switch of DSL link parameters. Among other messages, a Rate Adaptive Mode (RAM) message containing information on actual DSL link bandwidth is sent to the BRAS and aggregation switch. The SURPASS hiD terminates the ANCP messages, thereby retrieving relevant information about the actual available BW for each user, and adjusting scheduling parameters accordingly. Table 2 describes how scheduling decisions are made according to the changes in the available bandwidth and the product bundle the subscriber is paying for. Let's assume that a subscriber has purchased product bundle no.2. If the actual bandwidth is 21 Mbps, it will be divided as follows: 15 Mbps for BTV, 4 Mbps for HSI and 2 Mbps for VPN. If the bandwidth drops to 16 Mbps, the allocation between the services will be altered accordingly: 14 Mbps for BTV, 2 Mbps for VPN, and no bandwidth will be reserved for HSI. Product Bundle

Actual bandwidth

[Mbps]

Broadcast TV [Mbps]

High Speed Internet

(HSI) [Mbps]

VPN [Mbps]

25 20 5 0 21 19 2 0

1

18 17 1 0 21 15 4 2 20 15 3 2

2

16 14 0 2

5. Addressing security threats A triple play network is liable to be subjected to a variety of malicious attacks or unplanned events which may lead to a serious degradation in service. These events may include network theft or denial of service (DoS) attacks. The SURPASS hiD 6600 supports a set of security features including: � Ingress VLAN filtering: a port discards frames tagged with a VLAN of

which the port is not a member. � Maximum number of MAC addresses per port: To protect the bridge

from malicious attacks that could fill the forwarding database (FDB) with “dummy” MAC entries.

� Port locking for specific source MAC addresses: Only frames matching those source addresses are allowed to enter the bridge; all other frames are discarded.

� Access Control List (ACL): Ensures that unwarranted attempts to access specific resources are blocked.

� Broadcast Storm Control: Avoids broadcast storms by limiting the amount of broadcasts forwarded by the switch to a predefined threshold.

In addition to the general security measures described above, the delivery of IPTV requires specific measures to plug security gaps typical to dynamic multicasting. The SURPASS hiD 6600 tackles these threats with the following tools:

Table 2: Adjusting the scheduling according to customer profile and available bandwidth

15

� IGMP access profile: Access profiles contain lists of allowed/blocked

multicast groups associated with relevant interfaces defined by the network operator via the management tools. Thus, IGMP requests for groups that cannot be delivered on the relevant interfaces can be blocked to avoid unnecessary IGMP traffic to the network.

� IGMP group-limiter: Designed to eliminate DOS attacked, this feature limits the number of IGMP states allowed per port. Thus, the SURPASS hiD 6600 can avoid an unlimited and wasteful IGMP state table size. Since the number of IPTV channels is usually well known, the maximum size of the table is predictable.

� Block/force IGMP router port: The SURPASS hiD 6600 allows the operator to block some ports from becoming IGMP router ports by discarding general query messages received on these ports. In this way, false IGMP router traffic can be filtered. Similarly, the operator can specify the router port where IGMP reports can be forwarded, eliminating host-to-host traffic.

� IGMP rate-limit: Another means of eliminating DOS attacks is by limiting the rate of allowed IGMP reports per port or per VLAN.

� Port/VLAN isolation: This mechanism is designed to prevent unauthorized direct connection between subscribers, both for security reasons and to avoid direct unbilled communication. In cases where all subscribers share the same VLAN (as is often the case in broadcast TV), undesired communication between two subscriber ports may be established. The SURPASS hiD supports two methods of preventing this:

o Port isolation: blocks traffic between two user side ports, as

shown in Figure 11.

o VLAN isolation: In some configurations, port isolation may not be

enough. Consider Figure 12 as an example. Customer A requires a connection to service platform B (path 3) and customer B to service platform A (path 2). Thus, in aggregator A ports 1 and 2 can not be isolated, nor can ports 3 and 4 in aggregator B. Consequently, path 4 cannot be avoided, meaning that customers A and B are not isolated.

Figure 11: Port isolation

16

VLAN isolation uses two types of VLAN. Isolated VLAN (Vi) is used for the upstream data (i.e. data generated by the subscriber), and Primary VLAN (Vp) is used for the downstream data (i.e. data generated by the service platform). A subscriber-facing port can only be a member of Vp, while network-facing ports can be members of both Vp and Vi. This guarantees subscriber separation since data generated by one subscriber (tagged with Vi) cannot be transmitted to another subscriber as the subscriber-facing port is not a member of Vi.

6. End-to-end solution or best of breed?

The SURPASS hiD 6600 is designed to provide the best Layer 2-based Carrier Ethernet switching for triple-play delivery. Triple-play networks comprise an impressive array of platforms and solutions for different functions, such as access, edge and core routing, content delivery, user interfaces etc. Building such a network is a complex task. This is especially true for those carriers with experience in telephony and high speed internet looking to expand into video and TV delivery and compete head on with cable operators whose bread and butter this. It is therefore sensible to consider tested, integrated end-to-end solutions where the challenges in putting together the pieces of the puzzle have already been tackled and solved. Siemens and Juniper Networks have combined to develop complete solutions to help service providers successfully introduce and expand triple-play services. Expertise from both companies joins in the RESIP Lab to validate, optimize and certify IP solutions. Service providers can use these solutions to deliver triple-play services with an assurance of satisfaction. RESIP certification of IPTV solutions is based on mechanisms drawn from the Siemens SURPASS Home Entertainment solution, the Siemens SURPASS Carrier Ethernet, the Juniper Networks M- and T-series routing platform, and the Juniper Networks E-series broadband services routers.

7. Alternative architectures Contrary to the architecture described above, where the boundary between IGMP and PIM multicasting occurs at the IPTV edge router, an alternate way of delivering IPTV services may be based on an IP-multicast protocol,

Figure 12: The need for VLAN isolation

17

such as PIM-SM. Service delivery may start at the first DSLAM aggregation level and extend throughout the metro network. IGMP is used for channel zapping between the STB and the first aggregator which is also the PE. The PE device maps IGMP join messages to PIM join messages. An appropriate multicast tree is created from the BTV source to the PE and from there to the appropriate subscriber. One such multicast tree is created for each BTV channel. This is a feasible approach, but suffers from several drawbacks: � The creation and teardown of the necessary multicast trees by PIM can

take a significant amount of time, depending on the subscriber’s location in the network and whether other subscribers are watching the same channel. In cases where a subscriber is the first to request a specific channel, the zapping process may extend to several seconds, since the multicast tree must be constructed all the way back to the BTV source. This results in an unacceptable deterioration of user experience.

� Because of its per-hop behavior, a routed network does not offer mechanisms for guaranteed QoS similar to the ones offered by the Siemens Advanced Ethernet Package described above or those inherent in MPLS.

� Network resilience takes a serious hit. A failure in the network requires reconvergence of the underlying IGP network, followed by the rebuilding of the affected multicast trees. This may result in tens of seconds of service outage until reconvergence terminates.

� Both operating and capital expenses increase as a result of running PIM in the aggregation network. The complexity associated with managing IGP in the aggregation network, combined with dedicating system resources to operating the routing functionality for multicast tree construction, results in an increase in the total cost of ownership.

18

www.siemens.com/carrier-ethernet © Siemens AG 2006

Siemens AG Communications Hofmannstraße 51 D-81359 München Siemens and logo are registered trademarks of Siemens AG, Germany. All trademarks are property of their respective holders. Information contained herein is subject to change without notice. © Copyright 2006, Siemens AG. All rights reserved.