PDF of this tutorial
EPS Reliability
EPS technology enhances Ethernet's reliability. EPS protects the access network against link and node failures. Like SONET's protection scheme, EPS designates primary and alternate paths for network traffic, with failure detection and switchover to alternate facilities occurring in less than 50 msec.
In standard operation mode, EPS supports "load balancing," enabling traffic to be carried over both primary and alternate paths. Although telcos still need to traffic engineer their networks to ensure that primary paths have sufficient bandwidth to meet all service-level agreements (SLAs) in the event of a failure, this EPS feature increases customer satisfaction by providing more available bandwidth during normal network operation. EPS, combined with standard Ethernet and IP reliability features, ensures that the BLC architecture is telco-ready, i.e., capable of "five-nines" operation.
Service-Quality Management
In its BLC implementation, Occam Networks leverages several other standard Ethernet features, including virtual LAN (VLAN) and QoS capabilities, as defined by the Institute of Electrical and Electronics Engineers (IEEE) in the 802.1q and 802.1p specifications. VLANs enable telcos to segregate network traffic; that is, traffic within a given VLAN, including broadcasts and multicasts, is restricted to that VLAN. Traffic is allocated to a particular VLAN based on a tag that Ethernet switching devices insert into Ethernet frames.
Within the VLAN tag is a field for priority information. The 802.1p specification allows network operators to specify eight levels, or classes, of priority. This QoS mechanism enables network operators to control network latency and throughput without the complexity of ATM.
Video Play: From Subscriber to RT
In terms of video, the technologies relevant today are ADSL, ADSL2 Plus, and VDSL. (Ethernet can be supported over VDSL links.) Each has its advantages and disadvantages. Today, residential customers will need 9 to 10 Mbps of bandwidth downstream to support triple-play services, including plain old telephone service (POTS), data service at between 384 kbps, and 1.5 Mbps; at least two MPEG-2 video streams; and network overhead. In the near future, improved video compression techniques, such as better MPEG-2 and the newer MPEG-4 standards, promise to reduce the bandwidth required for each residence to below 7 Mbps.
ADSL: Asymmetric DSL (ADSL) has the advantage of being well understood, broadly supported in customer premises equipment (CPE), and widely deployed. However, as a transport for video, it has limitations. The key drawback is that ADSL doesn't offer sufficient downstream bandwidth over long enough distances to be able to reach all customers. Specifically, ADSL cannot deliver 8 Mbps beyond 6,000 feet to 8,000 feet. Many telco customers are 12,000 feet to 18,000 feet from the nearest RT.
ADSL S=1/2: Covered in the current ADSL standard, S=1/2 encoding provides an important improvement to ADSL—pushing the rate and reach to 9 or 10 Mbps out to 10,000 feet and thus making ADSL S=1/2 a viable service offering for many telcos.
VDSL: Reliable up to 13 Mbps, very-high-data-rate DSL (VDSL) provides a lot of bandwidth but over very short distances-3,000 feet to 5,000 feet. Some telcos are interested in VDSL because it is available today, and they want to offer customers at least three concurrent video streams. A few are redesigning their serving areas to approximately 4,000 feet between subscribers and RTs so they can use VDSL.
ADSL2 Plus: The technology is solidifying for ADSL2 Plus, which will increase ADSL bandwidth for shorter distances. It provides the approximately 13.5 Mbps needed today to deliver a triple-play service with three video streams out to 6,000 feet or 7,000 feet.
Clearly, no standard xDSL technology provides the ideal "10 Mbps at 12,000 feet" solution today. Telcos must make trade-offs between bandwidth and distance. However, the industry is improving compression technology, which will enable MPEG-2 to run at lower encoding rates (2.8 to 3 Mbps, for example). Implementation and uptake of MPEG-4, which requires less than 2 Mbps per video stream, will also increase. Technology and pricing trends are converging to enable telcos to offer profitable video services.
By investing in a BLC access network today, telcos can immediately increase revenue by offering POTS and high-speed data services while at the same time positioning themselves to move quickly into the video market. Whichever DSL technology (or fiber, for that matter) a telco opts to use, the most important issue is to architect the RT to CO feeder delivery network to economically support the total bandwidth needed for all offered services.
Figure 5
From BLC RT to CO and Beyond
Between the RT and the CO, the BLC architecture transports all triple-play services as IP-based traffic over Ethernet. The architecture leverages key IP and Ethernet capabilities to support video transmission. IP is unicast by nature; to support multicasting, the Internet Engineering Task Force (IETF) has defined a number of multicast protocols.
Multicasting is based on the concept of a host group, which is a set of network hosts (in this case, the set-top boxes used by subscribers) that share a common multicast address. The originator of a multicast session, such as a video server, selects the multicast address to be used for a given transmission. Network hosts join and leave a multicast group using the Internet Group Management Protocol (IGMP). IGMP is also responsible for forwarding multicast traffic from a router to members of the multicast group. The BLC architechture supports IGMP in its BLC RT in the form of an IGMP proxy; that is, the BLC RT appears as a multicast router to the downstream set-top boxes and as a host to the upstream router or video server. By functioning as an IGMP proxy, the BLC RT streamlines multicast transmissions.
For example, when a set-top box requests to join a multicast group, the BLC RT intercepts the join request and checks whether it is already receiving that multicast session and whether the subscriber has access rights to the session. If so, then the BLC RT forwards that multicast channel to the subscriber line that requested it. If the BLC RT is not receiving a particular multicast channel, it forwards the join request upstream, where it is processed by the next BLC RT in the network, the BLC COT, or the head end, which then begins forwarding the requested multicast channel to the requesting BLC RT.
There are several advantages to having the BLC RT act as an IGMP proxy. Because the BLC RT handles multicasting, subscribers see a quick response to channel changes. For telcos, bandwidth is conserved throughout because individual video channels are only forwarded to those BLC RTs that need to distribute them downstream to subscribers. By conserving bandwidth, a BLC architecture allows more video streams to be carried over a given access network.
Figure 5 summarizes the transport and video-related protocols supported at each leg of traffic flow through BLC triple-play architecture. To ensure that video traffic gets the handling it needs for high-quality service, the architecture leverages both IP and Ethernet QoS mechanisms. BLC RTs and COTs perform fine-grained traffic classification, looking at source and destination address fields, IP source and destination ports, DiffServ code point (DSCP) markings, and other fields within a packet's header. Once the BLC RT orCOT determines what type of traffic is coming in on a given port—voice, data, or video—it marks each packet with a priority, using Ethernet 802.1p structures.
The BLC architecture has also mapped priority levels into service levels, creating strict priority profiles. For example, circuit emulation service is priority 7, VoIP is priority 6, and video is priority 5, with lower priorities allocated to data services. The BLC RT and COT queue and forward packets based on their priority marking, ensuring that each traffic type gets the level of handling it needs. At each priority level, each traffic source is policed per its SLA and the traffic shaped per network engineering parameters. In addition, the architecture uses VLANs to provide virtual separation and security between services. For example, broadcast video is carried in one VLAN, while data services destined to a given Internet service provider (ISP) is carried in another VLAN.
This QoS implementation is more flexible and less costly to manage than ATM QoS. For example, because ATM handles QoS on a virtual-circuit (VC) basis, ATM-based DSLAMs can only look at the VCI/VPI in determining QoS handling. VC-based QoS entails more management overhead than Ethernet-based QoS, resulting in higher management costs.
