![]() |
|
||
|
| |||||||||
| |||||||||
|
|
By Kevin Sparks May 26, 2005 12:51 PM
For the past five years, one word has dominated nearly every conversation in the telecommunications industry: “convergence.” But what convergence means depends on whom you’re talking to. For end users, convergence may mean an ability to use one account to access every one of their services. For prosumers it may mean access to both work and personnel applications whenever they need them, from wherever they are, using whatever device they have at hand. In short, convergence means users can focus on the content of their communications--not the logistics of communicating it. For carriers, convergence can mean combining voice, data and video portfolios in new ways to deliver higher-value services. Or it may involve consolidation of separate networks, such as data or voice, onto a common core, such as a multiprotocol label switching (MPLS) network. In the end, however, whether the discussion involves end users or service providers, both view convergence as a way to deliver a communication experience that is more convenient and more relevant to end users’ lifestyles. The question is, can today’s data transport and access networks support the blended service that creates this communications lifestyle? Changing the service equation
Until now, carriers created and implemented network services as monolithic vertical stacks that tied each application to a particular device and network. This architecture represents a significant barrier to both interactions between different applications, and the ability to seamlessly apply the same application to different devices and networks. A blended lifestyle communications environment requires an architecture that facilitates both. To deliver always-on, access-agnostic and device-independent communications that the end users of today are demanding, service providers need a new service-centric architecture. A network built on this new architecture must be flexible enough to easily enable fast and efficient introduction of new services to address continuously evolving market needs. The 3G Partnership Project (3GPP), leveraging the Internet Engineering Task Force (IETF) protocols, is defining this new architecture, the IP multimedia subsystem (IMS). IMS architecture implements standard interfaces between applications, network layers and back-office systems. IMS architecture enables service providers to deploy each network application once and make those services available to any end user regardless of their location or access device. IMS architecture focuses on the higher layer control, signaling and service applications elements. However, IMS framework relies and is fully dependent on an access, aggregation, and transport network infrastructure to support expanded scalability, quality of service (QoS) and reliability required by converged services. The technology that has proven to be instrumental for the implementation of a core IMS architecture is multiprotocol label switching (MPLS). MPLS is a core data transport technology that supports scalable IP services and point-to-point Layer 2 connections, such as trunking for ATM and Frame Relay services. While ATM provides robust QoS and resiliency for IMS-based services and will continue to play an important role in the network, newer technologies are promising greater scalability at a lower cost. MPLS, enhanced with multipoint virtual private LAN service (VPLS) capabilities, will increasingly extend into metro core and aggregation networks, forming an essential foundation for converged IMS-based services. As this article explains, MPLS provides the cost-effective scalability, QoS, traffic engineering, and reliability features that carriers need to aggregate and transport traffic from high-volume converged voice, video, and data services while ensuring a seamless communications experience for their subscribers. Scaling with MPLS and VPLS
To capitalize on the service potential of the IMS architecture, service providers must be able to deliver a large quantity of high-quality multimedia voice, video and data streams (“triple-play traffic”) over their metro area networks. Many service providers use metro Ethernet networks for delivery of Layer 2 virtual private network (VPN) services and for efficient Layer 2 access to IP services. Service providers are also beginning to deploy much larger scale Ethernet networks to cost effectively switch triple-play traffic to and from broadband Digital Subscriber Line (DSL) and passive optical network (PON) access systems. As demand increases for all Ethernet services and as Ethernet services extend beyond the metropolitan area, service providers are faced with even more compelling reasons to scale their metro Ethernet networks. Unfortunately, conventional Ethernet networks offer only limited scalability: restrictive virtual LAN (VLAN) ID address space and rapid spanning tree protocol (R-STP) diameter and convergence performance effectively restrict both network size and the total number of customers that a given metro Ethernet network can support. This limitation is acceptable for small-to-medium metro VPN service offerings, but poses a problem for providers that want to support triple-play services and Layer 2 VPN services beyond the metropolitan area. As Figure 1 shows, these providers can use a VPLS-capable MPLS network based on carrier Ethernet switches, routers or multiservice provisioning platforms (MSPPs) to dramatically scale their metro Ethernet networks and integrate them across an existing IP/MPLS core into a regional or nationwide service. VPLS builds on MPLS to provide Layer 2 point-to-point and multipoint VPNs, while retaining all the convergence-enabling virtues of MPLS. VPLS is the ideal technology to interconnect existing metro Ethernet sub-networks in a flexible and scalable fashion that preserves existing customer connections while retaining the inherent multipoint characteristics of Ethernet services. Inserting a VPLS core between individual metro Ethernet sub-networks and broadband access systems effectively allows each access sub-network to scale independently--and be replicated as necessary--to support that area’s service demand. As a result, these VPLS-enabled carrier Ethernet networks can dramatically increase scalability. Controlling the quality of the user experience Increasing scalability is only part of the service provider’s challenge. To successfully deliver blended lifestyle services, service providers must be able to control the quality of the end-to-end connection. MPLS provides the quality-of-service (QoS) mechanisms to implement the packet classification, traffic policing and traffic shaping policies that service providers need to define and manage service classes. It is also unique in its extensive traffic engineering capabilities that are needed to control bandwidth across the network. QoS mechanisms, paired with traffic engineering capabilities, give service providers the flexibility they need to support applications ranging from best-effort Internet access to premium services with stringent service level guarantees. SLAs enabled by MPLS include among others delay, jitter, and packet loss for voice-over-IP (VoIP), video conferencing, and other IMS-based services. Core MPLS routers and metro VPLS/Ethernet switches can use a variety of these mechanisms to treat each service flow with an appropriate level of QoS based on that application’s tolerance for delay, jitter, and packet loss. Looking ahead, the International Telecommunication Union (ITU) and the European Telecommunication Standards Institute (ETSI) are working to define Resource and Admission Control (RACF/RACS) functions, which standardizes IMS-compatible QoS control for both IMS and non-IMS wireline services. Building on these standards, IP/MPLS routers, VPLS/Ethernet switches, and other elements can incorporate specialized control functions capable of supporting closed-loop admission, bandwidth and QoS control of high priority traffic according to subscriber profiles, network policies, and available network bandwidth. Protecting services against network outages
Providing seamless always-on communications requires superior network resiliency--the ability to quickly restore services if failures occur. MPLS-based networks can use MPLS Fast Reroute and backup path protection capabilities to quickly restore services when a failure occurs anywhere across the MPLS core. Resilient handoff to Ethernet sub-networks and broadband access systems at the edge of the MPLS/VPLS network can utilize link aggregation (LAG) or spanning tree protocol (STP) mechanisms. Network availability also depends on the hardware redundancy and software resiliency of the individual routers and switches. Most carrier-class MPLS-enabled routers and switches provide extensive hardware (including control) redundancy options and increasingly offer robust modular software architectures and graceful protocol restart mechanisms. Graceful restart enables MPLS routers to maintain the routes and the allocated labels installed by resource reservation protocol (RSVP) or label distribution protocol (LDP), so that they can continue forwarding traffic without disruption while the failed node comes back into service. These capabilities can significantly increase network availability by minimizing the extent and duration of, or even eliminating the impact of, an occasional hard or soft failure within the network. Conclusion
To deliver converged services, service providers must be able to transport high-volume traffic from high quality voice, video and data services over a mix of wireless and wireline access networks while ensuring a seamless communications experience for their end users. MPLS and VPLS can provide the robust scalability, QoS, traffic engineering and reliability that service providers need to deliver the always-on, access-agnostic and device-independent blended lifestyle communications environment their customers want. Kevin Sparks is Director for Lucent Technologies’ Chief Technology Office. Visit Lucent Technologies online. |
| BROWSE ISSUES |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
|
||||||||