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 cons

Despite 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.

For starters, the challenges on the routing side touch both the upstream and downstream sides of the traffic flow. Before MISP environments started to take shape, routing traffic via the upstream was a simple routing decision, notes Benoit Legault, director, technical consulting group for ADC's IP cable business unit.

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.

Camahort

Because the use of parallel networks for MISP is rather unwieldy, deployments are rare. Still, Terayon Communication Systems, for one, is working with an undisclosed MSO in Korea on such a project. In that case, the operator is leasing access to a number of ISPs to help cover the expenses, says Elisa Camahort, director of product marketing for Terayon's digital cable solutions unit. "It's a rather unique approach that wouldn't gain much traction in the U.S," she concedes.

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.

By employing native IP for MISP, an operator can provide cable modem customers with an IP address for their selected ISP, and ensure that the router can make the proper decision based on that information.

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.

MPLS, at its core, is designed to improve the efficiency of packet distribution, and divert traffic around failures and bottlenecks. Embedded QoS capabilities also make MPLS an effective choice for packet prioritization and service level agreements.

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."

Not all multiple ISP options are created equal
Depending on the protocol or method employed, each option has its own set of pros and cons.

Protocol/method	Pros	Cons
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