Tel: |
Tutorials | Technical Sessions | Exhibits | Inter-Op Demo
Back to top Monday Oct. 17 | Tuesday Oct. 18 | Wednesday Oct. 19
Back to top
Back to top
Back to top
Back to top
Tutorial 1: Scaling considerations in MPLS networks
As MPLS networks grow both in size and in the complexity of the features deployed, it becomes important to understand the resource consumption associated with this growth, both at the individual LSR level and at the network level. This tutorial looks at some of the scaling aspects of MPLS protocols and applications, both in the control and data planes. The goals are to examine the amount of state that gets created and understand the tradeoffs between the cost of maintaining extra state and the benefits of doing so. Some of the topics covered include: - how the amount of control plane state (for example LSPs) and forwarding state plane (for example forwarding resources) is affected by different MPLS signaling protocols, features deployed, and network design choices. - how to evaluate the cost of the state created in terms of both platform resources and operations/management complexity. For example, when is it necessary to upgrade a platform or add a new device in the network, how difficult is it to configure and troubleshoot a particular deployment or how much protocol activity is generated by a particular design choice. - how the amount of state can be reduced, and why it doesn't always make sense to do so. The material presented is vendor-independent. The tutorial is targeted at network engineers and service providers who want to gain a deeper understanding of MPLS networks.
Tutorial 2: Inter-Provider MPLS
Enterprises around the world want seamless connectivity for end-to-end services across network boundaries. To accomplish this they don't want to use multiple providers. They want a single point-of-contact. That's why carriers are enthusiastic about interprovider MPLS. With interprovider MPLS, service providers can work with each other to combine the capabilities of their individual networks, so they can improve their reach and revenue. The ability for service provider networks to interoperate helps meet enterprise customer demands for increased voice, video and data services at all their remote locations, whatever the geographic area. Interprovider MPLS also enables simplified network management capabilities and effective service-level agreements (SLAs). This tutorial will present a detailed overview of MPLS technology in an interprovider environment. Attendees will gain an understanding of:
- How interprovider Layer 3 VPN and Layer 2 VPN work together in a peering Inter-autonomous (Inter-AS) system This session is for any carrier that wishes to provide customers with a transparent, globally interconnected interprovider network infrastructure, which reduces capital and operational expenditures with minimal investment. Attendees should be familiar with the basics of MPLS and how L3VPN, L2VPN and Traffic Engineering work in a single autonomous system environment.
Tutorial 3: Metro Ethernet Tutorial & The Evolution of Ethernet
Tutorial 4: MPLS Network Operations & Management
Everybody has heard about Ping as a way to verify IP connectivity. Many people may have heard that there is a form of Ping (LSP Ping) that has been designed for MPLS networks. But, what exactly can you do with LSP Ping? What can't you do? Are there other OAM tools? And, how can these tools be combined to create a full-fledged toolbox? This tutorial provides an overview of MPLS OAM. It explains how individual tools (like BFD, Y.1711, Y.1713, LSP Ping and LSR Self Test) work. It explains how the existing tools fit together and gives a sense of the relative completeness of the MPLS OAM toolbox. This tutorial has been created by the MFA Forum. The MFA Forum was founded in April of 2005 by merging the MPLS Forum, ATM Forum and Frame Relay Alliance.
MPLS, GMPLS and Psuedowires: The Need for Cooperation Between Standards Bodies The convergence of network technologies and applications manifests itself in buzz words like "triple play" and "NGN", and puts increasing pressure on standards organizations to work together towards a common end. There is certainly no convergence if each body produces its own techniques for building a converged network. The industry needs clear leadership and simple, interoperable solutions. This presentation will look at the ways in which standards bodies could work together to arrive at common solutions while preserving their areas of core expertise, their identities, and their roles within the telecommunications community. The need to build bridges as well as fences will be examined. As an illustrative example, the speaker will draw on the interactions between the IETF and the ITU-T in the areas of MPLS, GMPLS and Pseudowires, and will point out ways that the process could be improved as well as highlighting some of the pitfalls.
Interprovider Pseudowires
A growing number of service providers are converging their voice, video and data networks to improve operational and capital expenses. In fact, according to recent Yankee Group interviews with service providers based in North America, South America, Europe, and Asia, 85 percent of the top 20 revenue-generating service providers have initiated IP/MPLS consolidation plans. (Service Providers Define Requirements for Next-Generation IP/MPLS Core Routers, 30 MAY 2004, Mark Bieberich) And the interprovider technology of choice seems to be the IETF's Pseudo Wire (PW) technology. The next natural step is to look at expanding the reach of PW-based networks by connecting different service provider's administrative domains together and interconnecting separate service providers using PWs. In this session, we will explore the problem and solution spaces for interprovider Pseudo Wires. (For example, building a model that can be successfully deployed requires the solution to be layered starting from a static provisioned model, adding dynamic reachability information, policy enforcement tools, and finally more complex QoS policy tools.) Attendees will gain insight into the requirements for interprovider and inter-domain Pseudo Wires. And two possible solution models will be considered: Static Pseudo Wire placement and dynamic Pseudo Wire placement. Finally, we will explore solutions to the auto-discovery of Pseudo Wire end points, and the Pseudo Wire signaling problem.
Multi-Hop PWs: "A small step for PWs, a giant step for Metro
Convergence?"
Pseudowire End to End Emulation (PWE3/PW) is gaining momentum. WAN deployments of PWE3 are currently enabling new Ethernet services and the opportunity to converge ATM, Frame Relay and other legacy services over a common MPLS core. The multi-service attributes of PWs and adaptability to different types of PSN tunnels are giving the technology strong consideration as a candidate to deliver convergence in metro access networks, either as an end to end service or as an aggregation for "new age" solutions: e.g. next generation optical transport, triple play, wireless backhaul. As PW technology moves from leading edge to mainstream and into the Metropolitan Area Network (MAN) a number of considerations are coming to the forefront:
How can I keep my access network simple while deploying PWs? These requirements drive a need for a new breed of PWs that concatenates several PW segments together to form a Multi-Segment PW (MS-PW). This presentation starts by discussing the new requirements and motivations behind them with a particular focus on the need to provision and connect segments of a MS-PW in an operationally efficient manner. The presentation then discusses the mechanisms that provide solutions to the problem considering the latest IETF work and it concludes with an analysis of possible applications for these building blocks.
Multi segment Pseudo-Wires using RSVP-TE
Pseudo-wires (PWs) are currently used in MPLS networks for transporting L2 customer traffic by providing a point-to-point L2 connection between customer edge (CE) devices. The PWs today are signaled using LDP and are tunneled over a PSN tunnel in the MPLS network. The PW may have QoS requirements, in which case, the PSN tunnel is setup using RSVP-TE which provides the needed traffic engineering, fast reroute and class of service features. But if the two CEs are connected to two different PSN domains, then current mechanisms need to be extended so that a PW can be signaled to span multiple domains. Furthermore, if such a PW has stringent end-to-end QoS and resiliency requirements, then additional work needs to be done. We will look at some of these requirements for multi-segment PWs which make a good case to examine RSVP-TE for signaling such PWs. We will also discuss the various building blocks of the RSVP-TE based PW solution and look at scenarios where such a solution would be attractive.
OAM for Multihop Pseudowires Pseudowires or "Martini" circuits have been deployed for a number of years in real networks. These represent a point-to-point transport "tunnel" across a network to carry a layer-2 service. This tunnel is however, limited between two PE routers. Recently a journey has begun to deploy multi-hop pseudowires (MH-PWs) which entail splicing or stitching two pseudowires together at a switch point have gotten underway both from device vendors as well as within the standards bodies such as the IETF. This presentation will detail the efforts to augment and extend the existing OAM tools and protocols to support these new and useful configurations.
MPLS P2MP: from the needs definition to the solutions description France Telecom and its affiliates Equant and Wanadoo offer a wide range of IP/MPLS based services for residential and business customers. In these two markets, multicast based services such as digital TV, videoconferencing, gaming and grid computing are becoming more and more important. The support of such services brings up new challenges which are linked to the multicast characteristics of the traffic to be transported but also the quality of service which is needed (high availability, guaranteed bandwidth, low delay, low packet loss, low jitter, etc.). In the business domain, service providers face another issue: the support of multicast within BGP/MPLS VPNs which is not natively performed. All these needs push vendors and providers to study MPLS as a P2MP protocol and to specify and define extension of RSVP-TE or LDP to support P2MP tunnels. Indeed, for RSVP-TE, one of the driving ideas is to inherit the "good" properties of MPLS TE such as FRR and bandwidth reservation. In the presentation, we discuss the particular needs of France Telecom while dealing with two important services: MaLigneTV (MLTV, digital TV broadcasting over IP) for residential market and MPLS VPN services for business market. We present possible architectures for supporting these services and we discuss how the current specification of MPLS signalling protocols fit our needs.
Design Considerations for Multicast MPLS/BGP VPNs
There is a lot of interest among customers of MPLS VPN services in multicast being natively supported by the service providers (SPs), without requiring the customer to configure unscalable tunneling techniques. The fundamental consideration facing an SP when deploying multicast service is that of optimizing multicast traffic distribution and delays while minimizing the amount of state information that needs to be retained in the SP's core network. The current implementations of multicast in MPLS/BGP VPNs are based on draft-rosen-vpn-mcast. The focus of this draft is on optimizing SP bandwidth usage at the expense of additional state within the SP network. In this proposal we explore the challenges of Multicast VPN deployment based on draft-rosen-vpn-mcast and propose enhancements to address major design issues in a short-term. The three major design areas to consider when designing multicast VPNs are: (1) provider edge router (PE) and core router (P) stability and scalability, (2) the assurance of low latency for multicast data traffic, and (3) bandwidth optimization. We will explore those three areas, their inter-dependence, and proposed solutions. We observe that the optimal delay and optimal bandwidth for multicast VPN traffic seems to be orthogonal to the scalability requirement. The optimal delay is easily achievable with a single SP tree per MVPN per PE. Such trees are naturally built with PIM Source Specific Multicast (PIM SSM). Unfortunately, the use of PIM SSM does not accomplish the state minimization goal unless the restriction is imposed on end customers to constrain the location of their multicast sources (and, hence, PEs that attach to the customer's sites). The restriction on source location is unrealistic due to its complex implementation. Even if PIM-SM with shared trees is used, the amount of multicast states on some of the core routers is of the same magnitude as that when using PIM SSM. The scalability concern could be addressed by bi-directional (BIDIR) extensions to PIM-SM. With BIDIR, scalability is no longer a function of the number of PE devices but only of the number of MVPNs. Unfortunately this benefit comes at the cost of less efficient multicast distribution and longer delays since all traffic will flow towards the Rendezvous Point (RP) irrespective of whether there are any interested receivers. A way to address latency requirement when only shared trees are used for forwarding multicast data traffic could be to assign the optimal (with respect to end customer source) RP location for each VPN. In general MVPN deployments it is not feasible to gather source location information from end customers. BIDIR trees provide a scalable solution when they carry only MVPN control traffic. The bandwidth optimization is important since the customer interest in multicast indicates that the volume of multicast traffic is not going to be negligible. Draft-rosen proposes using per-flow specific trees (Data-MDTs) to gain bandwidth optimality. Data-MDTs by nature are source specific and should be built with PIM SSM. Data-MDTs resolve two out of three design issues: optimality of bandwidth and of delay. Yet, they increase the amount of multicast states in SP network, and, therefore, the scalability issue remains. A way to address scalability while preserving "optimality" of multicast traffic delivery is to trigger source specific trees on an aggregated rather than single source basis. If any of end customer's multicast flows behind a PE (say behind PEs) becomes active (a threshold indicating traffic other than control is crossed), a new MDT is triggered and it spans all PEs that have interested receivers in at least one group behind PEs. This MDT (let's call it "Super" Data-MDT) rooted at the PEs will exists until there is at least one active multicast flow behind PEs and there is at least one interested receiver for that flow. When the overlap in the receivers of different (s,g)'s that are aggregated on the same SP tree reduces, the optimality of bandwidth reduces. We explore heuristics and other methods when to trigger additional MDTs to improve optimality of bandwidth. For example, new MDT could be triggered when an aggregated mVRF bandwidth of active sources crosses specified cumulative bandwidth threshold. Another method for addressing scalability would be to trigger only one SP tree per mVRF with active multicast flow(s). This could be achieved by using PIM-SM with a switchover to shortest path trees (SPTs). Currently, the SPT-switchover might be triggered by MVPN control traffic since a PE as a receiver in a global multicast context does not distinguish between MVPN control traffic and data traffic. An enhancement could be made to PIM such that the switchover to SPTs is driven by data traffic only. We explore advantages and disadvantages of this solution in terms of complexity, reliability, degree of bandwidth optimization, and MVPN stability.
Carrier-Grade Multicast Deployment in MPLS Backbones
IP-Multicast is one of the enabling technologies for the large scale deployment of streaming services in triple play scenarios. In addition many VPN customers are starting to deploy IP-Multicast in their VPNs. Depending on the scenario different requirements arise. In some cases requirements from different scenarios are contradictory. Therefore it is necessary to build a platform which takes the different requirements into account. One of the major challenges is to integrate IP-Multicast in MPLS based networks without loosing the benefits of MPLS like the traffic engineering capabilities. It is also vital to choose the right technologies. This presentation gives an overview about current IP-Multicast deployment scenarios and applications as well as the requirements of ISPs regarding the integration of Multicast into their existing MPLS backbones. The design of a Multicast enabled MPLS network including mVPN will be presented. Based on the experiences gained during the implementation the following topics will be addressed: - L2 vs. L3 transport of Multicast: The pros and cons of the different solutions for Multicast in MPLS cores are discussed. VPLS, P2MP and L3 approaches are compared concerning their fit for the deployment scenarios (Multicast VPN, Multicast streaming services, etc.). The presentations discusses why it could be necessary to run more than one solution at a time. - Scalability: Existing solutions are only providing a limited scalability resulting in limited deployment as well. In mid and long term scenarios a platform has to be provided which scales with the needs of the customer. Where are the current limits and what is needed for the future (number of PE devices, routing protocols, bandwidth requirements, etc.)? - Migration: Customers are demanding the seamless migration of their existing multicast enabled infrastructure spanning the providers backbone. What kind of mechanisms have to be implemented to support the migration process? - Interoperability and Interworking: This is one of the major concerns while implementing large scale networks. What is needed to build a multi-vendor platform and which requirements have to be fulfilled to enable multi-area interworking between different ISPs? - Inter VPN and Internet Multicast connectivity: In some cases support for Multicast connectivity spanning different (customer) domains is required.
Multicast VPN Deployment Scenarios and Service Requirements Work is currently under way in the IETF to develop protocol extensions to support multicast traffic within Layer 3 VPNs. In order to fully understand the differences between the proposed solutions and to choose suitable options it is important to understand the possible deployment scenarios for Multicast VPNs, and the service-level functions that they are trying to deliver. This presentation will introduce the objectives of a Layer 3 Multicast VPN and will present the functional requirements both from the point of view of the service user and from the perspective of the Service Provider. It will be seen that these requirements are often completely distinct and occasionally contradictory. Only by careful analysis of all of the requirements can be sure to develop protocol solutions that will meet the needs of the network users as well as be satisfactory for the operators of the core networks.
Metro Ethernet and MPLS
This talk addresses the trend du jour: to build Metro Networks with Ethernet. First, we take a brief look at the drivers and advantages of using Ethernet as a *medium*. Next, we examine issues with using Ethernet *switching* as the Metro architecture. Then, we look at how MPLS is effective both in overcoming these issues and in providing a clean migration path from a TDM access infrastructure to one with Ethernet. Finally, we look at what is needed to make MPLS viable as an enabler in a Metro environment.
MPLS, Ethernet and the Metro
Carriers increasingly are seeking to migrate their metro infrastructure to packet to meet the simultaneous challenges of radically increasing bandwidth while reducing both equipment and operational costs. The metro offers specific challenges as the number of devices goes up orders of magnitude when compared to the WAN. Carriers face challenges in both scaling and engineering the metro that must be addressed in order to converge on a common infrastructure. Carriers are increasingly looking to Ethernet to meet that challenge, but Ethernet has specific hurdles to overcome in order to fit into this role. This talk will explore how to assemble and deploy a metro network from the currently available toolbox that combines MPLS and Ethernet components to address both residential and business services and to faciliate migration from the existing SONET/SDH base. Discussed will be control plane issues, OAM, and strategies for minimizing edge box functionality and overall cost of network build.
Next Generation Networks (NGN) Broadband Evolution: What it Means to MPLS
Networks
NGN Broadband applications and services convergence can benefit from the carrier-grade capabilities of IP/MPLS network architectures, and the flexibility and price points of Ethernet. As service provider networks evolve to converge business and residential triple-play services over a common infrastructure, converged IP/MPLS/Ethernet networks need to integrate application-aware service exchange capabilities. The new network ecosystem must satisfy stringent performance, scalability, availability, and manageability requirements for multi-layer converged services and applications, including VoIP, IPTV, VoD, and gaming. This presentation will provide business, architectural, and technical perspective on the evolution of IP/MPLS/Ethernet networks to accommodate NGN broadband requirements.
Realizing services across regions utilizing
dissimilar convergence layers
Convergence of the network naturally occurs to avoid the need for service specific infrastructures. However, as convergence occurs, the technology selected for the convergence layer (i.e. WDM, SDH, ATM, MPLS, IP) is influenced by the service mix that a carrier expects to carry in that particular portion of the network. This leads to different convergence technologies being chosen in different parts of the network. The selection of different convergence technologies doesn't change the fact that customers are still going to request services that traverse the entire network. Consequently, control plane mechanisms must support the routing of service requests through a series of regions using dissimilar convergence layers. To facilitate this, the control plane needs to understand the multi-layer structure of the network, and how services requested are accommodated. This presentation shows how multi-layer routing methods meet this requirement, and includes a discussion of the information necessary to represent the relationship between the resources in different layer networks.
Managing Profitable Broadband Services with MPLS
The scarcity of bandwidth that characterized the data networks of the 20th century is-in a large and growing segment of the market-no longer the all-consuming concern of network architects. Advances in transmission systems and enormous physical buildout are largely responsible for this, despite continued growth in traffic amounts. The most cost-effective gains, however, are those made by providers using tools for more efficient utilization and management of their existing bandwidth, while simultaneously enabling the development and deployment of value-added service offerings. Over the last five years, Multiprotocol Label Switching (MPLS) has emerged as the protocol tool of choice for enabling services over efficient network infrastructures, bringing the best qualities of ATM to IP networking. While its genesis was in speeding the flow of data over legacy router networks, MPLS has evolved during the development of high-speed router platforms to become a flexible tool enabling traffic engineering, virtual private networking, advanced service differentiation, and a variety of other advantages to the cable operator. This presentation introduces MPLS concepts and technology, with a specific focus on how the deployment of MPLS can contribute to the reliability, manageability, and profitability of advanced broadband services. Specifics include:
- Introduction and evolution of MPLS at a technical level, FECs, LSPs
Enhanced architecture model that deploys MPLS-enabled Ethernet-based Aggregation in DSL networks for Triple Play services
This presentation expands on the current DSL Forum concepts of pure Ethernet-based aggregation network for DSL networks and describes an enhanced architecture model that deploys MPLS-enabled Ethernet Aggregation in these networks. This MPLS-enabled Ethernet aggregation architecture makes use of Virtual Private LAN Service (VPLS) technologies to achieve the DSL Aggregation Network requirements and to improve the scalability, OAM, and resiliency and restoration of large scale Triple Play networks.
Subscriber Aware MPLS for Broadband Services
VPLS, as its defined today, implies a layer 2 connectivity service from the point of view of the service provider. This model makes it very difficult for the service provider to offer revenue generating broadband services beyond connectivity that typically require subscriber awareness and control. This presentation proposes a subscriber aware VPLS technology that will enable the service provider to deploy subscriber based services leveraging VPLS based connectivity. The approach leverages existing service provider infrastructure and allows broadband services to be deployed using VPLS.
Combining RSVP and MPLS for Scalable Admission Control
When a large portion of a network's traffic is voice or video, merely relying on over-provisioning or simple Diff-Serv prioritization may not be enough to ensure QoS in peak periods. Such environments demand that admission control be applied on Voice and Video traffic so that in case of excessive demand, some sessions (or calls) are rejected in order to protect established sessions from QoS degradation. Admission control can also enable policy-based admission control, allowing the pre-emption of less critical traffic to enable critical sessions to be established. The most serious challenge in admission control is scalability. This session will describe an architecture for achieving scalable admission control over large, MPLS-based networks. This architecture combines reservation signaling based on RSVP with aggregation of RSVP reservations in a hierarchical manner, and the use of MPLS TE tunnels as "fat pipes" to provide scalable QoS guarantees in the core. The main scaling issues can be addressed through the use of hierarchical reservation aggregation combined with established techniques for large-scale MPLS-TE deployments. The presentation will also illustrate deployment scenarios in carrier scale environments such as 3G Mobile Telephony and PSTN Trunking.
Assuring QoS: Delivering Real Time Services with MPLS Networks
Carriers deploying IP networks have invested billions of dollars in router technologies to create a framework from which new applications and services can be reliably delivered. MPLS enables service providers to utilize IP transport while providing some level of QoS. In an effort to provide differentiation from competitors and increase service revenue, carriers are looking to deploy technologies that can convert existing voice and video services to IP. By deploying session border controllers, carriers have been able to facilitate the transport of voice traffic over their IP infrastructures by creating service overlay networks. Until now, there has been no direct interaction between the service layer and the MPLS network and as a result, carriers have experienced difficulties in scaling their networks to support additional services and applications. Today's MPLS networks must evolve from decoupled service overlays to tightly integrated IP/MPLS networks that deliver deterministic "PSTN-like" performance. In order to achieve network integration, carriers require a real-time session management layer that evolves beyond existing bulk layer traffic management capabilities and provides granular traffic management on a call-by-call basis. The real-time session management layer must be network-aware and have the ability to manage feature servers, media gateways, and other elements throughout the network to guarantee QoS for critical revenue-generating IP services. This session will present:
LSP Hierarchy in MPLS networks
MPLS networks are widely deployed today primarily for Layer 3 or Layer 2 VPN applications. Most MPLS deployments use LDP; when RSVP-TE is used, it is typically limited to full-meshing core routers for Traffic Engineering, QoS (Diffserv-TE) and primarily for fast re-route. There are often good reasons to move the RSVP-TE LSPs edge-to-edge, but the sheer number of these LSPs when fully meshed can be a nightmare. Some of RSVP-TE's scaling problems have been addressed with features such as Refresh Reduction, and LSP auto-mesh. But what about the amount of control plane and data plane state in the network? LSP hierarchy offers a nice solution, whereby core routers carry minimal state associated with the edge LSPs, by introducing the notions of "Forwarding Adjacency" (FA) and "Targeted RSVP session". We will discuss the details of this solution in this presentation. Although LSP hierarchy is a work resulting from the MPLS WG in the IETF, there is a common misconception in the community that this solution does not belong to packet-based MPLS networks. Some of this can be attributed to the fact that the scheme described in the LSP hierarchy specification for MPLS packet networks is based on a hierarchy of "switching capabilities" (PSC-1..4), which is a foreign concept to MPLS networks. This scheme would require MPLS networks to be fully upgraded to run GMPLS-based signaling and routing extensions. This is usually difficult for existing MPLS networks. We will see how an LSP hierarchy solution can be incrementally deployed in an MPLS network without the need for complete network upgrade. We will also look at how various features such as local and path protection, Graceful Restart; etc would work when a TE LSP is tunneled over an FA. We will also look at some of the challenges due to information naturally hidden by hierarchy and possible solutions for this. Finally we will look at some of the emerging applications, which make a good case for using LSP Hierarchy in MPLS networks. Inter-domain Traffic Engineering is one such application. Using LSP hierarchy in the transit domains for inter-domain TE LSPs not only provides scaling benefits, but also makes manageability and debugging easier by not carrying external domain state inside the domain. LSP hierarchy also lends itself well to applications such as Call-admission control (CAC) of VOIP flows into Diffserv TE tunnels in the MPLS core.
VPN Route Reflector Architectures and Operational Impacts Many service providers are seeking to reduce the complexity and cost of operating multiple networks by integrating their networks on a single IP/MPLS core and deploying technologies such as VPLS, VPWS, and BGP VPNs (RFC2547bis.) However, this convergence will not be able to take place unless the converged IP/MPLS control plane (signaling and routing) is capable of supporting the requirements of the services of the various networks/services. Routing architectures for the converged network need to be improved to support the scalability, stability and reliability required. This presentation focuses on two topics. The first is the techniques and guidelines to building a route reflection architecture that is scalable, simple and performs well. The second is the use of routing information contained in route reflectors that can be used for the sanity checking, management, and traffic engineering purposes. Routing scalability is being threatened by new technologies (BGP VPNs, VPLS, VPWS, etc) that require significantly greater capacity in the number of routes and BGP sessions supported. Route reflectors can become the bottleneck in scaling the routing architecture. Various techniques exist that can alleviate the scalability concerns, but at what cost and what complexity? An analysis of routing tables and potential scalability problems are proposed as well as the pro?s and cons of the application of various scalability techniques (multiple route reflectors, multiple bgp sessions, etc?). The benefits, necessity and feasibility of building such routing architectures are explored as well as the requirements of stand-alone route reflector/servers. The routing information contained in vpn route reflectors can also be of benefit to network service providers for operational and management applications. For example, routing information contained in the route reflector can be analyzed for sanity checking, routes can be injected for security and traffic engineering purposes. The presentation describes how route reflectors can be deployed and integrated
Secure MPLS Backbone Design to Support IMS
The multi-service characteristics of Multiprotocol Label Switching (MPLS) have made it the preferred network technology for service provider backbones. The IP Multimedia Subsystem (IMS) architecture takes advantage of MPLS capabilities such as Virtual Private Network (VPN)s, Traffic Engineering (TE), and Quality of Service (QoS). Security threats to the MPLS core are many and varied including Internet worms and viruses. These threats become magnified with IMS as it permits large volumes of users to dynamically access the MPLS network. In order to minimize these vulnerabilities Service Providers must embed security in their MPLS backbone to protect users of converged services from the backbone and protect the backbone from the users. This presentation will identify the security threats to the MPLS backbone and the vulnerabilities to IMS and provide security solutions to minimize attacks. Security technologies covered include Authentication, Firewall, IPsec, IDS, and per-flow QoS. Advantages of an MPLS backbone for IMS will be briefly discussed.
Applicability of GMPLS to Packet LSPs and MPLS to GMPLS Migration Methods Operators are currently faced with the operation and maintenance of two control planes when interconnecting second tier IP/MPLS networks across their GMPLS packet-optical backbone. Indeed, the GMPLS protocol suite subtly extends the MPLS control capabilities for Packet LSPs by bringing in new features such as bi-directional LSPs, explicit label control, graceful restart, logical control channels and forwarding adjacencies. Also, several features are provided using distinct mechanisms, for instance, local LSP recovery is implemented using the Fast Re-route techniques in MPLS whereas GMPLS makes use of the generic Segment recovery technique. This presentation first reviews the routing and signaling differences between the MPLS and GMPLS protocol suites and then discusses the issues caused by these discrepancies. Next, it details the set of routing and signaling mechanisms required to bridge the differences between MPLS and GMPLS protocols with respect to several inter-connection scenarios. For this purpose, two methods are considered 1) the upgrade of the MPLS control capabilities combined with the profiling of the GMPLS protocol suite when applied to Packet LSPs and 2) the introduction of customized interworking capabilites to adequately support the various inter-connection models between these networks. This presentation concludes by illustrating by means of representative networks the applicability and the suitability of these methods with respect to criteria such as the evolution of protocol standards and operators' strategies.
Investigation of deployment scenarios for a GMPLS network migrating
into an existing IP/MPLS network
In order to smoothly introduce GMPLS technology to the actual operation environment, migration of a GMPLS network into an IP/MPLS network was quite significant, although early field trials have been so far demonstrated. In this presentation, the migration scenarios of the GMPLS network was experimentally investigated in the case of overlay, peer and augmented models, by using IP/MPLS routers, GMPLS-controlled routers and photonics cross-connects (PXC). From the point of the optical core network, the peer-model is more suitable in order to improve the efficiency of internal operation as well as resource utilization, however, the support of the overlay-model at the same time is desirable to provide an external customer service over the optical core network. Here, we propose the simultaneous support of both GMPLS overlay and peer models by controlling routing information advertisement to routing adjacencies and recalculating the route at the edge of the optical core network in the case of the overlay model, and successfully confirmed such operation by using GMPLS-controlled routers as well as PXCs. In terms of the migration of IP/MPLS and GMPLS networks, the peer-model is quite advanced architecture as IP/Optical integration, because one network can have a visibility on each other, leading to effective operation as well as resource utilization. However, considering existing (operating) IP/MPLS network migration, the existing network is preferably kept as it is in terms of addressing and routing instance and operating software may not be conventionally upgraded. To fit the migration to the ISP's currently operating environment, we propose to utilize the augmented model between peer and overlay models, making GMPLS controlled routers the border of IP/MPLS and GMPLS domains. This means that GMPLS controlled routers can have the visibility of both domains while separating each routing domains by the border function. By using this method, we could successfully demonstrate the migration of GMPLS network without sacrificing the existing IP/MPLS network's routing instance and addressing. It is concluded that the GMPLS deployment scenario must be adaptively and carefully chosen based on each ISP's operational and service environment, since each models indeed have pros and cons in various aspects. However, the investigation is expected to help to promptly introduce the GMPLS network into existing IP/MPLS network as well as newly provide GMPLS-based customer services.
MPLS and GMPLS interworking
In this presentation, we discuss the issues on MPLS and GMPLS interworking. MPLS networks are being widely deployed for converged service infrastructure network. In order to expand the network capacity, GMPLS-based optical networks are likely to be deployed underneath the already-deployed MPLS-based networks. We need interworking mechanisms between MPLS and GMPLS networks because the LSRs in the already-deployed MPLS-based networks may not be GMPLS-capable. Even if the already-deployed MPLS-based networks will being migrating to the GMPLS-based one, such interworking mechanisms are also required during the migration process because GMPLS-incapable LSRs and GMPLS-capable LSRs coexist until all the LSRs become GMPLS-capable. There are several migration scenarios as described in the internet-draft [GMPLS-mig]. In this presentation we focus on the MPLS-GMPLS-MPLS migration scenario and present the requirements, the network architecture, and the mechanism in this scenario. The network architecture consists of MPLS and GMPLS domains, each of which runs either separate or monolithic protocol instance. We present the mechanisms for interworking the signaling/routing protocols and visualize the GMPLS-domain resource into MPLS-domain. Protocol overhead is minimized by controlling protocol messages between MPLS and GMPLS domains. Efficient traffic engineering mechanism is provided by controlling visualization of GMPLS-domain resource according to the traffic demand and the residual resource in GMPLS-domain. [GMPLS-mig] IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration 
Operational, Deployment and Interworking Considerations for GMPLS
Technology
One of the biggest concerns in today's network is "how to deploy GMPLS
technology to realize the benefits and at the same respecting the
administrative boundaries between IP and Optical domains". There are
several architectural alternatives including Overlay, Peer and Border
models are being discussed for next generation IP+Optical networks. The
key difference among these models is how much and what kind of network
information can be shared between IP and Optical layers. Peer model is
suitable, where optical transport and Internet Service networks are
operated by single entity. Currently, many service providers have
traditionally built their networks, where Optical transport and service
networks belong to different management/ownership. Border model is
suitable in this scenario, where Optical transport and IP service
networks administrated by different entities and would like to maintain
a separation between IP and Optical layers, at the same, get the
benefits of Peer model approach. The purpose of this presentation is to
present an architecture solution known as border model, which is
tailored to address deployment concerns associated with GMPLS technology
to the existing networks. This presentation also details on how border
model can be used for seamless migration to GMPLS. Please refer to
http://www.ietf.org/internet-drafts/draft-ali-ccamp-gmpls-deployment-aug
mented-model-00.txt
The presentation also discusses MPLS/ GMPLS signaling interworking aspects and role of a border node for this purpose. It also discusses tradeoff between static FA-LSP and signaling FA-LSPs dynamically with respect to bandwidth fragmentation vs. configuration burden. The presentation also highlights aspects tradeoff associated with the priority management in MPLS+GMPLS networks and possible approaches to simplify network design. The outline of this presentation is as follows:
- GMPLS migration issues and scenarios for migrating existing
services over GMPLS networks.
Deploying, interworking and operating L2 and L3 MPLS VPNs//
MPLS deployment experience: scaling, performance and security
Two years ago, CSC implemented perhaps the first US nationwide secure MPLS-based Layer 2 network for a Government client based upon the Martini protocol. This network provides the national backbone for the Agency to operate all of their national services supporting environmental protection initiatives from the HQ in Washington, DC to the National Computing Center in North Carolina. Promises of better performance, quality of service and cost savings from convergence were all reasons to move in this direction. This presentation will provide the results of how the actual performance compared to the "promise" and discuss issues, challenges and innovative successes we have had with our EPA customer. This network replaced a national Point-to-Point network deployed in 1994 with a unified L2 MPLS network with North Carolina as its hub for Internet access and security. We are now in the process of acquiring a 2547-based overlay network for VoIP and video to complement the L2 network for data. We will discuss the methodology for choosing the Martini approach as the basis for our design including issues related to jumbo packets, IPSEC and legacy protocols. Transition strategies from the old to the new network will be discussed as lessons learned, as will the backup and disaster recovery strategies that the network now performs. This network is fully encrypted using FIPS 140-2, as required by the US Government, and implements several unique strategies for cost savings including aggregate bandwidth. The network is fully deployed and has been in operation for over a year now with documented performance and costs. The EPA is now using it to sell to other Government Agencies as a Center of Excellence. This network was a finalist in the Grace Hopper award for Technical Innovation in Government.
MPLS Enterprise Customer Deployment
Worldwide, almost every service provider has now deployed one or more MPLS applications. Over 85% have deployed Layer 3 VPN, two-thirds have deployed 3-5 QoS levels, and many carriers have deployed Traffic Engineering (TE), TE Fast Reroute, and Layer 2 VPN capabilities. Following in the footsteps of service providers, many enterprises are also deploying MPLS. These enterprises, which include everything from financial companies to airports and governments, have also deployed the L3VPN service, often adding QoS to differentiate service levels. In this session, we will present case studies of enterprises that have successfully deployed MPLS. These case studies will include companies in a wide range of vertical industries. We'll even take an in-depth look at Cisco's own IT MPLS deployment providing insight into some of the many MPLS best practices for enabling high availability, smooth migration, and more. By looking at different enterprise deployments in different industries, we'll demonstrate the many different ways MPLS improves IP in enterprise networks today. We'll also give an overview of important MPLS capabilities such as in-service software upgrades, ping, Traceroute, VC connectivity verification, etc. These capabilities increase availability and complement existing capabilities (such as stateful switchover). The session will conclude with a quick look into future MPLS enhancements that will provide increased capabilities for voice, video conferencing and video multicast performance.
An All-encompassing MPLS Enabled Private IP Network
To meet the requirements for network security and backbone reliability, Sprint has built a private IP network using the same design standards and components as its time tested SprintLinkTM global IP network. However, the private IP network is totally separate from the public Internet or any other network, thus reducing the risk inherent in being interconnected with the public networks. The Sprint private IP network supports RFC 2547 standard for VPN over MPLS and all traffic on the network are encapsulated in VPN tunnels. The addition of RFC 2547 MPLS Network-based VPN to the private IP network provides complete segmentation of a customer's VPN within the private IP network (i.e., no customer's VPN will be visible by any other customers on the network). Each customer will be logically separated using Virtual Routing and Forwarding (VRF) technologies. To provide additional safeguards for network privacy, Sprint's private IP network uses private IP address (RFC 1918) space to address the backbone network elements and links. The private IP network supports native IP multicasting and provides Quality of Service (QoS) and Class of Service (CoS) enabling real-time interactive voice and video over IP. To support these services, the traffic is prioritized begining at the CPE router that classifies packets based on the Type of Service (ToS) byte in the IP header. The "classification" mechanisms are then used to place specific application traffic types into their proper queues. As for the backbone QoS/CoS, all backbone links are engineered for a low utilization and redundant links are used as live back up, resulting in a congestion-free backbone network. Finally, the private IP network is an integrated platform that supports private line and Layer 2 services including ATM and FR, offering an alternative to traditional TDM-based private line and Layer 2 solutions while leveraging the high-end security, performance, and reliability of the private IP network. For these services, the customer's traffic is encapsulated into IP, transmitted across the network core as an IP packet and is returned back to its original form at the egress point of the network. This encapsulation/decapsulation is performed by Layer 2 Tunneling Protocol version 3 (L2TPv3). L2TPv3 technology is an emerging industry standard and supports IP encapsulation of numerous Layer 2 protocols and provides authenticated tunneling to allow Layer 2 traffic to securely traverse a native IP core. Sprint has implemented L2TPv3 across its entire private IP network without having to re-engineer the network or change its architecture.
Next Generation IP/Optical Integrated Network in KDDI
Next generation IP/Optical network is the fundamental infrastructure for providing such the triple play services with high QoS. In this presentation, GMPLS-controlled network technology to establish a low-cost, flexible and reliable IP/Optical network is introduced from service provider's deployment and operation point of view. The benefits of GMPLS networking technology, which enables the integrated operation of IP/MPLS router, optical cross-connect and WDM equipment, are reduction in network maintenance and operation costs and swifter service provisioning. The early field trial demonstration results of the GMPLS-controlled network is presented, which have been recently conducted using our actual network environment, to validate our IP/Optical integrating network architectural model. The efforts and challenges of GMPLS interoperability operation will be also covered.
Extending GMPLS for Pure Photonic Networks
This talk is about proposed extensions to GMPLS when interfacing Generalized MPLS a pure photonic network with a router based network using GMPLS peer model. The optical network consists of photonic GMPLS network sub-domains in which the computation of a viable path may require the head end GMPLS-based Label Switch Router (GLSR) or GMPLS-based Label Edge Router (GLER) to consider numerous physical properties of the fiber, amplifiers, lasers etc. The presentation describes how a pure photonic sub-domain may be abstracted by GMPLS as a single GLSR and how this avoids advertising all the physical properties of the underlying hardware. Once abstracted, the GLSR now only needs to advertise, via its link state protocol, constraints on the input to output link viability to capture the full range of physical interconnection possibilities of the photonic domain. This allows the vendors of pure photonic devices to keep the complexity and non-linear physics of their individual and composite photonic components out of the GMPLS network domain while still permitting GLERS and GMPLS capable routers to compute viable photonic paths, backup paths, diverse paths etc. While the extensions are motivated by pure photonic domains, the ability to constrain certain input link to output link pairs as viable cross connections is useful in other GMPLS domains such as a TDM ring which presents challenges to a CSPF style path computation. The proposed extensions can also be used in the context where a GLSR is deployed as Layer 1 VPN-based photonic abstract node. The link to link viability constraint can be used by client edge nodes and client internal nodes to compute only viable L1VPN paths that cross the GLSR abstract node.
Dynamic optical link preemption based on GMPLS
traffic engineering Dynamic optical link preemption based on the latency of IP traffic flows has been demonstrated using GMPLS traffic engineering. It was confirmed that total delay of prioritized traffic has been drastically reduced by preemptive operation.
The Unified Optical Control Plane: The Time is Now
The Unified Optical Control Plane has significantly matured over the last several years, to the point that early adopters are conducting field evaluations and mainstream interest is gaining credible momentum. As networks evolve to accommodate changing service types and unpredictable bandwidth requirements, unified optical control plane initiatives such as GMPLS and G.ASON promise to deliver the flexibility necessary for a truly dynamic optical transport network. This flexibility translates into tangible benefits for network operators in multiple functional areas. Multi-vendor and multi-layer interoperability demonstrations and proof of concept testing have increased in both frequency and complexity as the standards have matured and evolved. But while this progress has been widely recognized in the carrier and vendor communities at a general level, many are now asking - Where do we go from here? And what does it mean to my network and my services? As the inevitable real-world deployment of optical control plane standards draw closer, it becomes necessary to look beyond the technical issues associated with standardization and testing and begin to look at the practical implementation challenges associated with actual deployment. This talk will highlight of development and validation of the Unified Control Plane to date, while providing a specific emphasis on practical service provider strategies for leveraging the technology in real-world networks and real service strategies. Specific topics will include:
IPv6&MPLS This presentation lays out the major economic and technological issues in transforming a global IP network to enable IPv6 services while continuing to support IPv4. The first part of the presentation consists of a comprehensive survey of different transition strategies for IPv4 to IPv6 migration. Thereafter, we move on to examine the role of MPLS in the IPv4/IPv6 transformational process. Lastly, we highlight some important economic considerations that confront network service providers as they embark on forceful positive action to augment their infrastructure with IPv6 capability.
Case Study: Building A Successful Full Packet Voice Network and IP Network Multiple network operators are embarking upon large scale network convergence programmes to re-architect their networks for the 21st century. This presentation will focus on the Migration strategy for replacing an IP network with a converged multi-service MPLS network. Key considerations in this replacement include scale (32 PoPs Core MPLS Network), Fast Reroute Engineering, Capacity Planning, network management, and DiffServ CoS Design. In this presentation, we will describe an architecture for achieving such network transformation and detail the ins and outs of migrating to a single network infrastructure to carry multiple IP applications. The audience will learn how Telecom Italia and Wandl, Inc. have combined their efforts to plan, engineer, simulate, configure and deploy such network. It will be complemented by Cristina's presentation to introduce the key elements and challenges in migrating to a converged MPLS architecture. New efficiencies, Cost reduction and management simplification using the Wandl IP/MPLSView Suite of Traffic Engineering Tools will be highlighted. Agenda:
IP/MPLS for Live Broadcast Video Applications
Brief Historical Overview of the use of IP/MPLS in Live Video Applications
MPLS Has Mechanisms to Deliver on Broadcasters' Demanding Needs
Case Study in IP/MPLS used for high-end live video application
Telenor's pan-nordic NG multiservice network
A year ago Telenor started the process of building its pan-nordic NG multiservice network. Today we have gone through the initial design, RFP process, design revision based on selected equipments, comprehensive tests of overall design and migration plan. This presentation is about: 1. the high level design of the network, including major design choices we have made about DSLAM backhaul; routing and MPLS switching, QoS etc. 2. an analysis of challenge areas of delievering end-to-end services in our multi-AS environment: InterAS-TE and interAS-QoS 3. lessons that we have learned and experience to share
Some Considerations in the SLA Delivery for MPLS Enabled Networks This presentation discusses the high level technical issues related to the delivery of the performance based SLAs in the MPLS networks. Topics included are: The presentation will focus on design issues not specific to the particular network architecture, vendor software or equipment and will not discuss specifics of implementation. However, the selection of discussed problems will be based on the deployment and operational experience.
Multicast LDP
In networks where multicast receivers are highly dynamic, a receiver driven protocol is more scalable. Early in the development of MPLS, efforts were made to add labels to Protocol Independent Multicast (PIM). To simplify network operations, work is now underway to incorporate procedures into LDP to build multipoint LSP's. Multicast LDP (MLDP) is a receiver driven approach for building Point-to-Multipoint and Multipoint-to-Multipoint LSP's The talk will describe MLDP, how it can support IP multicast traffic and conclude with a comparison to P2MP RSVP-TE.
Topics covered in the presentation
Next-Generation Solutions for Multicast in 2547 VPNs and VPLS
This talk describes Next-Generation Solutions for Multicast in 2547 VPNs and VPLS. Tradeoffs and challenges in delivering multicast in 2547 VPNs and VPLS requires solutions to take a "toolbox" approach. Various architectural elements of such a toolbox for Multicast VPNs [MVPNs] and VPLS multicast are described. The common building blocks between solutions for MVPNs and VPLS multicast are outlined. The talk will also describe the recent IETF work in this area:
VPLS Multicast challenges and options Faster and cheaper broadband access technologies make triple play application delivery a reality. In particular, broadcast video delivery over packet based networks is gaining significant attention. In this presentation, we will discuss the various options available to make broadcast/multicast delivery over MPLS/VPLS more efficient. Several possible enhancements are being discussed within the IETF, ranging from optimizing the amount of multicast state in the core to optimizing the bandwidth usage in the core. Pros & cons of each approach will be presented, along with the respective problems that they are trying to solve.
PCE (Path Computation Element) models:
architecture and applications MPLS Traffic Engineering has been widely deployed during the last few
years and was motivated by need for bandwidth optimization, fast
recovery (MPLS TE Fast Reroute) and strict QoS guarantees to carry
sensitive traffic over multi-service packet networks. Recently, new
requirements arose leading to the emergence of new Traffic Engineering
path computation models (in addition to the existing ones) so as to
address various challenging problems:
This led to the specification of new MPLS TE LSP path computation architectures (also referred to as PCE-based path computation models). The standardization aspects of such architectures are addressed by the IETF in the context of a recently formed new Working Group (PCE) within the Routing area. This presentation will first provide an overview of the architecture
building blocks, followed by a description of the elements of such
architectures:
(1) PCE discovery Finally, several applications of PCE-based architectures will be discussed: computation of shortest inter-domain path using a distributed PCE-based path computation (VSPT algorithm), application to GMPLS border model, use of PCE for multi-layer traffic engineering. The standardization aspects (IETF specifications) will also be covered.
Advanced MPLS L3 VPN deployment and challenges - Inter-provider VPNs, VoIP support, and MVPNs
- In order to meet customers' needs, more advanced MPLS L3 VPN services have been studied, deployed, or being deployed in providers' networks. The presentation will first give a brief overview of the characteristics of L3 VPNs deployment, including features, VPN routes distribution, PE-CE connections, QoS, and convergence requirements. The presentation then focus on the design, deployment, and challenges particularly in the following areas: - MPLS L3 VPN supporting VoIP applications: requirements, implementation scenarios, and deployment experiences. - Inter-provider VPN: design options, operation support, QoS consideration, end-to-end feature consistency, and inter-provider QoS challenges. - Multicast VPN: customer requirements, network solutions, design trade-offs from using different protocols/approaches, and the scalability challenges.
Inter-AS Security Factors and Best Practice Guidelines
As organizations deploy MPLS, there are security concerns when extending VPNv4 capabilities across multiple administrative domains and multiple providers. The presenter will explain security risks for RFC2547bis deployment scenarios for Inter-AS deployments and provide recommendations in order to mitigate against potential attacks when implementing RFC2547bis models, e.g, A, B or C. The presenter will conclude with best practice tips for the operator.
Multi-layer traffic engineering with PCE in MPLS/GMPLS networks
This presentation addresses the applicability of path computation element (PCE) to multi-layer traffic engineering (TE) in MPLS/GMPLS networks. PCE applications are being discussed in IETF PCE Working Group. Multi-layer TE is one of the key PCE applications in the same way as inter-area and inter-AS TE. Multi-layer TE in GMPLS networks increases network resource efficiency, because all the network resources are taken into account at the same time. Multi-layer TE includes label switched paths (LSPs) route calculation and optimal virtual network topology (VNT) calculation. Multi-layer TE also includes dynamic LSP control and VNT control, which are triggered by traffic demand change, by topology change, and by network failure, as shown in Figure 1. 
This presentation describes multi-layer TE using PCE in MPLS/GMPLS networks. For dynamic LSP control, let us consider hierarchical LSPs, where a higher-layer LSP uses a lower-layer LSP as a TE-link. When the higher-layer LSP is setup, it is necessary to judge whether new lower-layer LSPs should be established for forwarding adjacency LSPs (FA-LSPs), or whether existing lower-layer LSPs should be used for FA-LSPs. The judgement such as whether new LSPs should be established or existing LSPs should be used depends on the network providers' traffic-engineering policy. In VNT control, for example, when the traffic demand changes drastically, the current VNT is no longer optimal. VNT reconfiguration allows network resources to be utilized in an efficient manner. A basic PCE communications protocol is proposed in IETF, where the first author in this paper is a co-author of the proposed draft. Protocol requirements for multi-layer TE and impact on the protocol extensions to the basic PCE communications protocol are presented. Finally, we present our PCE prototype system that demonstrates multi-layer TE in GMPLS networks. |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| © 2005 ISOCORE CORP. ALL RIGHTS RESERVED | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Tutorials