Navigating the protocols
While parallel networks, tunneling and NAT have been largely discarded as viable options for multiple ISP deployments over cable lines, even the more popular approaches have their own set of pros and consDespite cable operators' early technical trials and commercial deployments of multiple ISP (MISP) services, the protocols and methods employed to deliver them aren't necessarily as solid as concrete.
Offering MISP via a cable network presents two specific challenges: provisioning and routing. While provisioning represents an extremely difficult issue for cable operators (see related story on p. 20) to grapple with, the routing piece is just as important.
Figure 1: MPLS/VPN at the CMTS is
designed to boost scalability.
An operator "usually had one or two uplinks to the Internet via that single ISP," he says. Additionally, in a MISP environment, the router must also take note of a packet's final destination, and whether it's an Internet packet or a server packet.
"Once you figure that out, you have to figure out if the packet is from a Road Runner or EarthLink customer," which is found in the source IP address, Legault adds. "You have to identify where the packet needs to go and from which customer, so you can route it through the appropriate upstream," Legault says.
MSOs can't use the MAC source address in lieu of the source IP address for MISP, not just because it boosts operational costs, but because the address gets stripped from the packet after it goes through the first router. The cable modem termination system, Legault adds, is the only box with vision into the MAC source address, so operators must inspect the IP information to route packets from different ISPs properly.
In the downstream, packets fly in with their own destination IP addresses or ranges of destination IP addresses, which are, in turn, "advertised" by each ISP. If a packet doesn't have an address assigned by EarthLink, for example, then it can't return via the EarthLink uplink.
That means a cable operator's CMTS must be able to handle all of those ranges in order to tether EarthLink IP addresses to EarthLink customers, Road Runner IP addresses to Road Runner customers, and so on.
ISP advertising is also where approaches like Border Gateway Protocol come into play and help discover "who's reachable and where," Lagault says. Each ISP typically sends BGP updates, and each update contains "advertisements" pertaining to peering points to the Internet.
Still, the difficulties for cable operators are in the task of managing myriad IP addresses, and that's linked to the routing piece of the network.
Today, there are a variety of protocols and methods to handle those challenges, including parallel networks, network address translation (NAT), tunneling and policy-based routing (via native IP). Some are much more effective and viable than others.PARALLEL NETWORKS
Although some operators use parallel networks to segment data and voice traffic today, it doesn't represent a very efficient method for offering multiple ISPs.
For example, an operator would have to duplicate its routing functions, which soaks up rack space and doesn't use channels efficiently. "It's expensive and adds a lot more devices to manage," says Arris System Architect Rick Arnold.
Though the use of a parallel network would provide a quick solution for a MISP deployment, financially, most cable operators and their ISP partners aren't willing to fork over the money to build it after they view the frightening return on investment potentials.
In addition to the expense, parallel networks don't scale. "You might be able to justify [parallel networks] with a few large ISPs, but if you're trying to support some smaller ISPs...then it becomes very difficult," says Jeffrey Walker, senior director of marketing for Motorola Broadband.
That approach also requires a close-knit relationship between the ISP and the operator. "There's a certain amount of trust involved [because] the ISP is relying on the MSO for access and for them to accurately report usage," says Camahort, who is slated to present a paper on the open access subject at this month's SCTE Cable-Tec Expo in San Antonio, Texas.NETWORK ADDRESS TRANSLATION
Internet customers typically receive an address that doesn't belong to their particular ISPs, but their packets will flow through a translation device, which provides an address that belongs to their service provider. While an operator can route packets with NAT addresses across the cable network, they can't be routed over the Internet. Instead, a NAT server translates packets to a private IP address.
NAT functionality can reside in several pieces of equipment on the network, including the CMTS, edge router or core network router.
Legault says NAT's biggest advantage for operators is that it can be implemented almost overnight. "This is [technology] that's been around for years, specifically for the enterprise networks," he says. NAT is also efficient in at least one respect: it can reuse IP addresses.
The downside is that NAT doesn't scale very well, because a server will have to sit between every customer and the Internet. "When you build a network that uses NAT, and you're talking about big broadband networks, you'll need a lot of servers. That gets very expensive," Legault says.
NAT, he adds, also isn't very effective with peer-to-peer applications tied to applications such as gaming, for instance, because subscribers won't be able to play against customers who also happen to subscribe to a different ISP.TUNNELING
By establishing a link between the cable modem customer and the subscriber management system, tunneling protocols create virtual "tubes" on a cable network that feed packets to the correct ISP.
Tunneling is comprised of three main protocols: PPTP (Point-to-Point Tunneling Protocol), L2TP (Layer 2 Tunneling Protocol) and PPPoE (Point-to-Point Protocol over Ethernet).
PPTP, proprietary to Microsoft Corp., is embedded into the variety of Windows-flavored operating systems and is "locked in" with Microsoft for the back office systems. In turn, PPTP is not well supported by popular systems such as UNIX, Legault says.
L2TP, a standard tunneling protocol, melds PPTP and Cisco's L2F (Layer 2 Forwarding) protocol, but requires that ISP routers support it, and clients are not freely available.
PPPoE isn't routable, and would require MSOs to revamp their router transport networks into bridged infrastructures.
If tunneling is employed for MISP, Legault suggests a combination of L2TP and PPPoE, whereby L2TP would aggregate and route PPPoE sessions. The CMTS, he adds, could handle the conversion of the protocol on the cable modem side of the network, and act as the local access concentrator for the conversions.
Overall, tunneling's advantage is that it works today (AOL's dial-up service uses it, for example). The problems, however, begin with the fact that routers can't tell whether packets traveling through the tunnel are for IP voice, video or data. That would prohibit cable operators from offering QoS-sensitive applications and services. MSOs would also lose their always-on advantage over dial-up because tunneling requires users to log on in order to create the tunnel, Legault says.NATIVE IP AND POLICY-BASED ROUTING
Figure 2: Tunneling protocol.
Figure 3: Policy-based routing.
In its most basic form, policy-based routing, or source-based routing packets are routed solely based on the IP destination address. Unlike tunneling, PBR can leverage QoS for differentiated services, allowing video and voice packets to coexist.
But, its scalability is questionable because it can put a big strain on the policy routers and clog the system. The use of ISP peering routers would help, but that method would require a "very big box with lots of CPU and lots of memory," Legault predicts. "You'll never find a box to handle customers two years from now."
Still, the approach would work well for small deployments. For larger ones, Multiprotocol Label Switching (MPLS) might soon factor in.A TOUCH OF MPLS
Figure 4: Distributed policy-based routing.
Closely mirroring VPN functionality, MPLS builds connections between two points on a network via label switch paths, and the adjoining label edge routers paint the packets with their proper routing table information. That also provides similar levels of security provided by virtual circuit platforms such as ATM.
MPLS enables cable operators to create distributed policy routing infrastructures, says Gerry White, senior director of engineering for Motorola Broadband. "Once you push your policy routers to the edge of your network, which are making these routing decisions at the edge of my network (via the CMTS and a policy router)."
Using MPLS also adds diversity to those paths on the network and quality of service capabilities–whether it's for data, voice or for a spate of different ISPs. In concert, the policy router would direct the traffic to the correct label switch path. Under that scenario, "I can segregate my traffic across my metropolitan network without having to build parallel physical networks," White says.
MPLS also cleans up the packet handling process, because each packet doesn't require deep inspection, adds Walker. "It's a lot more efficient." That's because the presence of MPLS, unlike a pure IP-routed network, doesn't require a policy routing decision to be made at every hop across the network.
MPLS is also designed to work in tandem with the rest of the network, so it works with other Layer 2 and Layer 3 protocols.
MPLS "is the one that has grabbed the hearts and minds of the operators; it has a lot of appeal," Camahort says.
Beyond the typical protocols, Terayon is touting a proprietary method called Virtual ISP Private Routing (VIPR). Similar to an MPLS overlay, VIPR can employ MPLS VPNs or policy-based routing, Camahort says. Terayon has implemented VIPR in its home-grown line of CMTSs, enabling a routing interface as well as tracking and monitoring features. "It's a value-added element," Camahort adds. "For now, we think it's a differentiator."
Although there are several protocols and methods from which to choose, any decisions will be based on the cable operator's legacy network infrastructure.
"Everybody's network is different at some level," Arnold says. "They're not all cut from the same model, so they need a flexible set of protocols that allow them to configure around their own set of problems."
|Parallel networks||Can be deployed immediately||Expensive|
|Can leverage DOCSIS 1.0 gear if service level agreements aren't supported||Underutilizes network resources|
|Added equipment absorbs limited available space on the network|
|Network address translation (NAT)||Easy to implement||Peer-to-peer applications such as gaming might not work|
|Less usage of public IP addresses can turn into cost savings|
|Tunneling||Little or no maintenance required by the cable operator||Scaling issues,significant overhead|
|Doesn't require operator to handle ISP addressing and routing||Hides packet content,which can impact QoS-sensitive applications|
|Maps traffic between tunnels and ISP networks based on subscriber database||Logon required, so operators lose "always on" advantage|
|Policy-based routing||An extension of existing routing mechanisms||Potential bottlenecking|
|Sets rules to govern QoS levels||No overriding standard|
|Network is protected from IP spoofing||Questionable scalability|
|Limited caching options|
|No policy selection for paths in the metro network|
|MPLS with VPNs||Standards-based approach||Complex|
|Supports QoS and multicasting||Part of a suite of protocols, which may not be widely deployed yet|
|Relatively easy to configure||Implementation requires specialized skills|
|Extensive traffic management features|
|Operates over myriad infrastructures (Gigabit Ethernet, ATM, Sonet)|
|Source: SCTE, ADC, Terayon|