 Email this Article
 Printer-Friendly
 Reader Comments
[Direct Feature]
Developing Broadband Remote Access Servers On Standards-Based Platforms
John Fryer explains how standards allow manufacturers to concentrate on product differentiation and gain a competitive advantage in the tough telecoms market.
John Fryer
ED Online ID #9461
September 2004
As a new wave of requirements are emerging in the telecommunications industry, equipment manufacturers are seeking ways to accelerate time to market and reduce development and production costs. They also need to preserve technology investments through successive generations of products. Hardware and software standards are increasingly seen as a way to achieve these objectives so that resources can be focused on product differentiation while deriving maximum business benefit and competitive advantage.
Application-enabling platforms harness the latest hardware and software standards and are an increasingly popular mechanism to achieve these business objectives. Broadband Remote Access Servers (BRAS) are one area where this new approach to development can be applied.
BRAS ATTRIBUTES
BRAS requirements are outlined in the DSL Forum architecture specification TR59 to support quality of service (QoS)-enabled IP services. BRAS provides more flexible service provisioning because subscriber services can be handled within a single managed network, rather than being provisioned on a one-to-one basis through to the NSP or ASP. See Figure 1.
On the access side, the BRAS provides an aggregation point for a variety of services. These include traditional ATM-based offerings and newer, more native IP-based services, such as support for Point-to-Point Protocol over ATM (PPPoA), PPP over Ethernet (PPPoE) and direct IP services encapsulated over an appropriate Layer 2 transport.
The NSP and ASP connections can support an assortment of high bandwidth connections. At the physical layer this could be: traditional DS1/E1 through to DS3/E3; SONET or SDH capabilities; OC3c/STM1 through to OC48c/STM16; and 10/100/1000 Ethernet (physical layer), for hosting and colocation for example.
Numerous options, including ATM, must be supported at the data link level, Layer 2, to maintain compatibility with existing systems, Ethernet, Packet Over SONET (POS) and Frame Relay.
AGGREGATION AND IP TRANSPORT
The key aggregation functions are performed 'to' the IP transport layer. These can involve simple forwarding of IP traffic, including directing traffic on to IP and network-based Virtual Private Networks (VPNs). They often require termination of PPP sessions, traffic aggregation, multicasting capabilities, Network Address Translation (NAT)-type functionality and authentication and encryption, depending on the subscribed services.
A key aspect for all these functions is provisioning QoS that can be provided through the Internet Engineering Task Force (IETF) Differentiated Services (DiffServ) specifications and the use of the Differentiated Services Code Point (DSCP). This does not dictate an absolute measure of QoS, but rather a relative priority mechanism for traffic. On the access side, particularly on individual subscriber loops, this is almost equivalent to QoS capabilities. These capabilities will initially be supported over IPv4, but must allow for IPv6 support in the future.
As these services are predominantly IP-based, the BRAS must perform basic IP-routed network functions, very similar to those of an edge router. This includes support for Open Shortest Path First (OSPF) and Border Gateway Protocol Type 4 (BGP4), along with traffic engineering functions. As traffic is increasingly aggregated into high speed uplink connections to NSPs and ASPs, Multi-Protocol Label Switching (MPLS) can provide traffic engineering characteristics, and, in conjunction with BGP4, Provider Provisioned VPNS (PP-VPNs).
It should be noted that aggregation can also be done at the PPP layer through the use of a routable Layer 2 protocol such as Layer 2 Tunneling Protocol (L2TP). In this case, the device operates as a L2TP Access Concentrator (LAC).
ADVANCEDTCA AT THE CORE OF BRAS
There are a number of standards-based technologies that can be used to develop a BRAS, to accommodate the range of functionality described above. At the core of these standards-based technologies is the Advanced Telecom Computing Architecture (AdvancedTCA), developed by the PCI Industry Computer Manufacturers Group (PICMG). The PICMG 3.X AdvancedTCA specifications provide a flexible hardware platform definition designed to meet the requirements of the telecommunications industry. Other alternatives include the CompactTCA specification, based in the switched Ethernet PICMG 2.16 CompactPCI specifications.
The base PICMG 3.0 specification takes account of the required power and mechanical specifications, such as multiple -48V power supplies with host swappable fans. These capabilities are managed at a fundamental hardware level by the Intelligent Platform Management Interface (IPMI). The 8U board form factor provides 140 sq/in of space with 200W of power.
When combined with a range of fabric inter-connection parameters, AdvancedTCA provides a powerful framework for a broad range of next-generation telecommunications equipment. Packaging this functionality into 14 slot, 19in and 16 slot 23in 12U/13U form factors with regulatory compliance to NEBS and international equivalent specifications completes the requirements.
From a fabric perspective, AdvancedTCA specifies a number of options. In addition to the low level blade management functions of IPMI, PICMG 3.0 specifies a base fabric dual star interconnection mechanism using Gigabit Ethernet. This assumes that two blades will operate as a traditional redundant pair, performing fabric switching and core shelf control functions.
PICMG DATA FABRIC
While 1Gb/s of bandwidth per slot is more than adequate for control plane and shelf management functions, it is clearly insufficient for a BRAS device requiring multiple OC48 uplinks, and possibly OC192 or 10GE (Gigabit Ethernet) in the future.
To address this requirement, PICMG has defined a data fabric to support a variety of payload capabilities. Like the base fabric, the data fabric can support a dual star configuration, but also has the option of a mesh interconnection, with every blade directly connected to every other blade.
This may be appealing from a bandwidth and throughput perspective, but it complicates control functions and increases cost as every card is now essentially a switch blade. For these reasons, the dual star (base and data) fabric model is generally preferred. The data fabric options range from PICMG 3.1 supporting Gigabit Ethernet and Fibre Channel to Infiniband (PICMG 3.2), to StarFabric (PICMG 3.3), PCI Express/Advanced Switching (PICMG3.4) and RAPID IO (PICMG 3.5). Some of these specifications are capable of delivering 10Gb/s per slot, offering a shelf capable of 240/280 Gb/s of switching capacity.
The fabric specifications are still undergoing standardisation and development because, in addition to raw throughput capabilities, other requirements include internal traffic management, queuing and Head Of Line (HOL) blocking type functionality.
In a packet-based environment, delivering 10Gb/s uplink capabilities at line rates generally requires 2X over-speeding, or 20Gb/s per slot, to maximise the use of statistical multiplexing. However, the developers of the AdvancedTCA specifications had the foresight to provide unused backplane pins to provide support for additional capabilities. This allows developers who wish to use AdvancedTCA capabilities to implement off-the-shelf, or proprietary chipsets, that will support some, or all, of the capabilities outlined above.
MORE POWER
The AdvancedTCA specifications provide for both front and rear access connectivity. Rear access is supported via a Rear Transition Module (RTM), which can be removed if not required. Layer 1 interface requirements may be supported on this type of module. Where necessary, specific interface functions can be supported through traditional PCI Mezzanine Cards (PMC), which minimise the development of carrier cards and mezzanines. PICMG is also developing the Advanced Mezzanine Card (AMC) specification which will have 30% more component space and over a 100% more power than existing capabilities. Additionally, AMCs are hot swappable modules and up to eight can be specified per AdvancedTCA blade.
BRAS requires a high degree of flexibility in its I/O capabilities, making it an ideal candidate for network processor technology. Economies of scale can be achieved by using the same card design with appropriate programming.
The major challenges for BRAS are handling functionality at Layer 2 and above, where the traffic management of IP flows becomes critical. Aside from the basic cell and packet handling functions, traffic policing and shaping with appropriate queue management and discard functions are critical. The access side requires traffic management at both the Customer Premise Equipment (CPE) and the BRAS, and, it is assumed, on the BRAS downstream connections to the NSPs and ASPs. See Figure 2.
On the access side, the DSL layers are based on PPPoA today and in future will use PPPoE encapsulation. The ATM VCCs are AAL5 PVCs supporting unspecified Bit Rate (UBR), UBR+ and Variable Bit Rate (VBR-rt) classes of service. In current applications, traffic management is performed purely at ATM layers. As the application layer is predominantly IP, all services receive the same treatment, unless multiple ATM VCs are created and flows mapped accordingly. Each physical connection at the BRAS can contain tens of thousands of subscriber flows.
<-- prev. page
[1]
2
next page -->
|
)
)
