NETWORK CROSSROADS. Demarc Intelligence: More, But Where?
bcr.com
Volume 28, Number 8
August 1998, pp. 8-10
By Tom Nolle (tnolle@cimicorp.com), president of CIMI Corp., a
consulting firm that specializes in advanced computer and communications
networks. He is a member of the BCR Board of Contributors.
The following is the full text of the printed article:
For decades, leased-line customers have used DSU/CSUs to terminate digital
carrier service connections. These devices translate between a data
connection like V.35 and a digital line.
But once frame relay, SMDS and ATM services started to appear, vendors
like Digital Link and ADC/Kentrox began to augment their DSU/CSUs to deal
with "smarter" carrier services--i.e., services with their own low-level
protocols. Today even "smarter" service-based features are appearing,
including statistics-gathering to enforce Service Level Agreements,
packet-shaping to optimize transport performance and traffic prioritization.
Demarc devices, while still delivering classical DSU/CSU functions, have
considerably broader capabilities. The term "Customer-Located Equipment"
refers to a device located at the demarc but connected to ever-smarter
services--for example, to carrier-provided virtual private networks.
So a whole new series of questions has emerged. Whose purposes does the
box at the demarc really serve--the user's or the service provider's? Is the
demarc device an integral part of the service or an added feature that comes at
extra cost? Will familiar demarc devices like routers and FRADs (frame relay
access devices) be able to cope with the more complex virtual network
services expected over the next decade?
The Virtual Service Agent Concept
With most private networks, the carrier provides a low-level service and
customer's CPE converts it to an application network. Because the OSI model
mandates strict segregation of functions among protocol layers, a single
device can support leased lines, ATM, frame relay, SMDS and more. Each is
simply a different "port interface" option on a Layer 3 device like a router.
When network services are presented at Layer 3, however, things get more
complicated. Instead of "partnering" with similar products at other demarcs,
the demarc device partners with devices that the carrier supports and installs
inside the network. Users of the Internet, for example, must adhere to
addressing rules, and support the topology management protocols--e.g., RIP,
OSPF or BGP4--dictated by the internal nodes.
Everyone agrees that more VPN services will be offered at Layer 3, and that
more features will be added for security, quality of service, etc. The question
is how these new services will become available to applications, and how
networks that rely on old-fashioned leased lines or virtual circuits will migrate
to the services.
IP has clearly won the battle of the application interfaces; indeed, by 2010, all
the other types of applications will probably generate less than 20 percent of
the data traffic. As a result, one side of the demarc device of the future will
have to present an IP interface to the premises, while the other side will have
to adapt to every combination of Layer 2 and Layer 3 service options the
carrier marketplace makes available.
What is needed is a Virtual Service Point (VSP), a device that presents a
consistent IP interface to applications, and a set of service-specific carrier
interfaces--both low-level (leased-line, frame and cell) and high-level (Internet,
IP VPN, etc.).
A VSP can be viewed as an application-level interface, a carrier service
interface and a service mapper that connects those two interfaces. This simple
structure hides a problem of almost bewildering complexity when all the
service options are considered.
An IP VPN is a good example. The "private" IP addresses that many
companies use cannot be used on the Internet because multiple users would
adopt each, causing routing confusion and a loss of security. So if a company
has an IP service representing both Internet access and access to its VPN,
how are the VPN addresses to be firewalled from the Internet? And how will
Internet users be prevented from accessing company VPN data?
The answer depends in part on how the IP VPN gets created--by tunneling,
through independent virtual circuits or through the new Multi-Protocol Label
Switching (MPLS) architecture. That implementation strategy, however, could
change as fast as VPN services change.
Coping with QOS-specific services also is a challenge. If the IETF's concept of
"Differentiated Services" or DiffServ is used, applications needing a special
QOS will have to set Type-of-Service (TOS) bits in their IP header. If
QOS-specific services are built using a "tunnel" or virtual circuit, data will
have to be "steered"--almost like routing--into the service. In either case,
since today's applications don't specify QOS requirements, a set of policy
management rules will be needed to separate the applications by QOS.
Some of these problems have been recognized for years, and vendors like
Bay, Cisco and 3Com have produced product architectures or features that
enable IP and other services in a private network application. Most, however,
require special features throughout the network's devices, something that can
pose a major cost and service disruption problem to network users.
A better strategy would be to encapsulate all these features in the virtual
service point. If on-premises networks migrate to cheap LAN switching over
the next several years, congestion within the premises should be largely
eliminated. A single device could then exercise QOS policy control at the
point where congestion is still a problem--at the boundary between the LAN
and WAN. That same device could resolve address problems and insulate the
user from changes in the carrier service interface that will inevitably
accompany the expansion of IP VPNs.
The features that VSPs might be called on to provide range far beyond basic
connection--firewall capabilities, address translation, encryption, tunneling,
traffic shaping and even protocol conversion. It's clear, for example, that VSPs
will have to offer IP access and flexible service portals, and will be modular
devices that can easily integrate software/hardware add-ons into the basic
product. However it's too soon to say much more about the specific
architecture and features that the market will endorse.
Virtual Service Point Hardware
Today's integrated access devices (IADs), already being offered by numerous
vendors, including Cisco, 3Com and Lucent, could serve as a foundation for
the virtual service point. Most offer LAN and local data interfaces, as well as
voice connectivity, but their data features tend to be limited to traditional
LAN bridging and routing. They have no special facilities to support
QOS-specific services, policy management or IP VPNs.
ADC/Kentrox (www.kentrox.com) recently took a step to provide virtual
service point features in its "WANTop Box" product. It separates the
application and service interfaces, which is characteristic of a VSP
architecture, and also offers policy management control over the traffic
mapping between the two interfaces.
Some of the WANTop Box's features result from ADC/Kentrox partnering
with firms like Packeteer (www.packeteer.com) and IDI (www.idinet.com), but
details on critical features like MPLS capability are not yet available. In
addition, since Kentrox has not released pricing information about the
product, it's not clear whether a flexible, full-service device like this can be
made cheap and supportable enough to place at the estimated 8 million
business demarcs worldwide.
The support issue is major. Demarc devices are located on the customer's
premises, where access by carrier personnel is expensive, and accidental
manipulation by customer personnel is easy. Kentrox provides a
policy-controlled management interface to segregate carrier and enterprise
management functions and to ease the provisioning of new services, but
other vendors are looking for ways to centralize the more expensive VSP
functions inside the cloud, so their cost can be shared among multiple users
and their operation more easily supported by carrier craft personnel.
Ennovate Networks (www.ennovatenetworks.com) has announced an
architecture for providing IP VPN services that centralizes functions in this
way, even providing access to frame relay and IP VPNs on the same access
connection. The company will support a variety of edge devices but will add
most of the service intelligence features inside the cloud. Details on
Ennovate's products--and prices--are scheduled to become available this fall.
Another approach, not yet identified with any specific vendor or product but
making the rounds in the rumor mill, is to add VSP features to premises-based
core switches. The rationale is cost-based--since the cost of the switching
platforms is partially borne by LAN applications requirements, the incremental
cost to add new virtual service point features might become low enough to
attract customers.
Conclusion
We're likely to see vendors split into two camps. The traditional vendors of
access devices will add VSP features to their existing product lines, which will
probably be less radical than those offered by startups and new players.
But access devices really should change radically to deliver the full benefit of
VPN services. IP VPNs, in particular, differ from traditional carrier services in
that they are better suited to ad hoc applications with short project life cycles
and require less skill to adopt and administer. It makes no sense to
compromise these benefits by locking users into complex and expensive
access devices.
If, as most believe, integrated access is inevitable, it also follows that demarc
devices will become complex. In order to restore some semblance of order, an
architecture is needed to simplify the most complicated part of multi-service
networking--data.
ISPs; new carriers like Level 3, Qwest and Williams; and facilities-based
carriers like Sprint and Bell Atlantic seem to be taking slightly different paths
toward this multiservice infrastructure, We've talked to users who, while
aware of the issues of the virtual service point, are frustrated by the absence
of detail on how these issues will be resolved. That frustration won't be
alleviated any time soon, and until there are more specifics available on how
IP VPN features will be provisioned, and the core debate is settled, the demarc
is not going to be a very stable place.
c1995-1998 BCR Enterprises, Inc. All Rights Reserved
This page was last modified on 08/10/98 Please direct comments, suggestions and problems to webmaster@bcr.com.
|
