Tel:
    703.860.1777
Email:
    mpls2005-info@isocore.com

 


Tutorials       |       Technical Sessions       |       Exhibits       |       Inter-Op Demo

Sunday, October 16
TUTORIALS

10:30 - 12:00 am

Tutorial 1: Scaling Considerations for MPLS Protocols and Applications - Ina Minei, Juniper Networks

Break

1:00 - 2:30 pm

Tutorial 2: Inter-Provider MPLS -Azhar Sayeed and Santiago Alvarez, Cisco Systems

Break

2:45 - 4:15 pm

Tutorial 3: Metro Ethernet - Andrew Missing, Alcatel

Break

4:30 - 6:00 pm

Tutorial 4: MPLS Network Operations and Management - Peter Busschbach, Lucent Technologies

Back to top

Monday Oct. 17         |         Tuesday Oct. 18         |         Wednesday Oct. 19

Monday, October 17
TECHNICAL SESSIONS

8:30 - 10:15 am
Opening Session
Chair: Bijan Jabbari

·     Introduction

·     Opening Speech

·     Keynote Speech

·     MPLS, GMPLS and Pseudowires: The Need for Cooperation Between Standards Bodies - Adrian Farrel, IETF

Break & Exhibits

10:45 am - 12:30 pm
Pseudowires: Extending the reach
Chair: Bert Wijnen, Lucent Technologies

Pseudowires are gaining support and are a reality in deployed networks, but to make them really valuable they need to span multiple networks and to cross multiple service providers' domains. Debate now rages over how the multi-hop pseudowire should be constructed and managed to achieve this goal.

·     Interprovider Pseudowires - Luca Martini, Cisco Systems

·     Multi-Hop PWs: "A small step for PWs , a giant step for Metro Convergence?" - David McDysan , MCI & Florin Balus , Nortel Networks

·     Multi segment Pseudo-Wires using RSVP-TE - Ron Bonica , Juniper Networks

·     OAM for Multihop Pseudowires - Thomas Nadeau, Cisco Systems

Lunch & Exhibits

2:00 - 3:30 pm

What do we want from multicast MPLS and Point-to-Multipoint Traffic Engineering?
Chair: George Swallow, Cisco Systems

Four service providers present their take on P2MP MPLS TE and multicast MPLS. What are the requirements to support multicast traffic in BGP/MPLS VPNs, and what benefits can be brought through extending MPLS TE to support point-to-multipoint LSPs?

·     MPLS P2MP: from the needs definition to the solutions description - Renaud Moignard, France Telecom

·     Design Considerations for Multicast MPLS/BGP VPNs - Maria Napierala, ATT Labs

·     Carrier-Grade Multicast Deployment in MPLS Backbones - Nicolai Leymann, T-Systems

·     Multicast VPN Deployment Scenarios and Service Requirements - Seisho Yasukawa, NTT

Break & Exhibits

4:00 - 5:00 pm
Ethernet in the Metro Network - What is the role for MPLS?
Chair: Steve Vogelsang, ECI

This session will cover the role of MPLS as Ethernet gains momentum in the metro network. Can we achieve it all with the existing MPLS techniques or do we need to develop new features?

·     Metro Ethernet and MPLS - Kireeti Kompella, Juniper Networks

·     MPLS, Ethernet and the Metro - David Allan, Nortel Networks

·     GMPLS Controlled Ethernet Networks - Loa Andersson, Acreo

5:00 - 6:00 pm
PANEL:
Advanced Services Based upon MPLS - A Service Provider Perspective
Chair: David McDysan, MCI

In this panel session, service providers will discuss the oppportunites and challenges involved with advanced services they either support or are considering supporting that are based upon MPLS. These services include backbone TE, BGP MPLS VPNs, GMPLS, Pseudowires, VPLS, inter-AS connection, and point-to-multipoing multicast support. The panel members will present their views, experience, and opinions regarding the commercial, technical and operational aspects of MPLS in support of these services.

6:00 - 7:30 pm

Reception & Exhibits
Reception Hosted by Avici Systems

Back to top

Tuesday, October 18
TECHNICAL SESSIONS

8:30 - 10:15 am
Broadband Services – Enabling the future
Chair: Tom Walsh, Lucent Technologies

Industry leaders will describe how broadband services will be the next major step forward for MPLS-based service providers and how MPLS will be used to achieve massive aggregation, protection features, and enable triple-play networks.

·     Broadband, the Next Revolution - What it Means to an MPLS Network - Sangeeta Anand, Cisco Systems

·     Realizing services across regions utilizing dissimilar convergence layers - Andy Malis and Jonathan Sadler, Tellabs

·     Broadband Services using MPLS - Kurt Melden, Juniper

·     Enhanced architecture model that deploys MPLS-enabled Ethernet-based Aggregation in DSL networks for Triple Play services - Sunil Khandekar, Alcatel

·     Subscriber Aware MPLS for Broadband Services - Arpit Joshipura, Redback Networks

Break & Exhibits

10:45 - 12:30 am
Building blocks for Advanced Services in MPLS Networks
Chair: Daniel Awduche, MCI

In order to facilitate the next generation of advanced services, MPLS networks must make full use of existing techniques within an extended architectural model to ensure solutions providing guaranteed QoS,end -to-end network convergence, and significant scalability.

·     Combining RSVP and MPLS for Scalable Admission Control - Bruce Davie, Cisco Systems

·     Assuring QoS: Delivering Real Time Services with MPLS Networks - Sridhar Ramachandran, Nextone

·     LSP Hierarchy in MPLS networks - Arthi Ayyangar, Juniper Networks

·     VPN Route Reflector Architectures and Operational Impacts - Eric Brendel, Chiaro Networks

·     Secure MPLS Backbone Design to Support IMS - Scott Poretsky , Reef Point Systems

Lunch & Exhibits 12:30 – 2:00 pm

2:00 - 3:30 pm
Interworking MPLS and GMPLS
Chair: Kireeti Kompella, Juniper Networks

This session looks at the issues of migrating from MPLS to GMPLS within packet networks and the problems of interworking between MPLS and GMPLS networks.

·     Applicability of GMPLS to Packet LSPs and MPLS to GMPLS Migration Methods - Dimitri Papadimitriou, Alcatel

·     Investigation of deployment scenarios for a GMPLS network migrating into an existing IP/MPLS network - Tomohiro Otani, Kenichi Ogaki, Hideaki Tanaka (KDDI), Mallik Tatipamula & Zafar Ali (Cisco)

·     MPLS and GMPLS interworking - Kohei Shiomoto, NTT

·     Operational, Deployment and Interworking Considerations for GMPLS Technology - Zafar Ali, Cisco Systems

Break & Exhibits

4:00 - 5:00 pm
MPLS in Enterprise Networks - Experiences from Deployment
Chair: Tove Madsen, Acreo

While some people debate the value of utilizing MPLS in Enterprise Networks, other have gone ahead and deployed. This session gathers observations based on experience and points out the benefits and pitfalls.

·     Deploying, interworking and operating L2 and L3 MPLS VPNs - MPLS deployment experience: scaling, performance and security - Peter Himmelberger, CSC

·     Enterprise Customer Deployment - Tom McKinney, Cisco Systems

·     An All Encompassing MPLS-Enabled VPN - Lee Jalali, Sprint

5:00 - 6:00 pm
Vendor’s Panel Session: Services Based on MPLS
Chair: Loa Andersson, Acreo

In this session, panelists from the vendor community will discuss technical development of MPLS and GMPLS to provide advanced services. Issues to be discussed include multicast and Inter-domain traffic engineering. Also, the protocol options will be highlighted with a view towards potential new service offerings and how they meet the MPLS and GMPLS requirements.

6:00 - 7:30 pm

Exhibits

Back to top

Wednesday, October 19
TECHNICAL SESSIONS

8:30 - 10:15 am
Generalized MPLS in the Optical Network
Chair: Naoaki Yamanaka, KEIO Univ.

GMPLS has been away from the headlines for some time, but it has been successfully deployed in many optical networks. This session gathers experiences from several service providers and points the way for next steps in dynamic control of optical networks.

·     Overview of GMPLS interworking test in Japan and NICT Keihana GMPLS E-NNI trials - Naoaki Yamanaka

·     Next Generation IP/Optical Integrated Network in KDDI - Masatoshi Suzuki and Tomohiro Otani, KDDI

·     Extending GMPLS for Pure Photonic Networks - Don Fedyk & Vik Saxena Nortel Networks & Comcast

·     Dynamic optical link preemption based on GMPLS traffic engineering - Shinya Tanaka , Japan Telecom

·     The Unified Optical Control Plane: The Time is Now - Vijay Pandian, Sycamore Networks

Break & Exhibits

10:45 - 12:30 am
Experiences from the Front Line - Building MPLS Networks for Advanced and Triple-play Services
Chair: Eric Gray, Marconi

Building MPLS networks to provide a wide range of services such as voice, broadcast video, and VPNs is non-trivial, and we are lucky to have operators who are willing to share the lessons they have learned and let us benefit from their experience.

·     IPv6 and MPLS - Daniel Awduche, MCI

·     Case Study: Building A Successful Full Packet Voice Network and IP Network - Hamid Laamouri & Cristina Gentili , WANDL & Telecom Italia

·     IP/MPLS for Live Broadcast Video Applications, Ryan Korte, WilTel Communications

·     Telenor's pan- nordic NG multiservice network - Lei Wang, Telenor

·     Some Considerations in the SLA Delivery for MPLS Enabled Networks - Roman Krzanowski , Verizon

Lunch & Exhibits 12:30 – 2:00 pm

2:00 - 3:00 pm
Supporting multicast traffic in MPLS networks
Chair: Jean-Louis Le Roux, France Telecom R&RD

Multicast support is currently very hot - it is an enabler for many triple-play services but in particular for broadcast video. This session will look at the latest developments in MPLS to support multicast within VPLS, VPN and LDP.

·     Multicast LDP - IJsbrand Wijnands, Cisco Systems

·     Next-Generation Solutions for Multicast in 2547 VPNs and VPLS - Rahul Aggarwal, Juniper Networks

·     VPLS Multicast challenges and options, Marc Lasserre, Riverstone

Break

3:15 - 4:45 pm
Multi-domain MPLS - Now we can all talk together
Chair: Adrian Farrel, Old Dog Consulting

MPLS is established within routing areas and autonomous systems, and now it is time to examine how it can be applied across area, AS or network layer boundaries. This session examines evolving solutions to the problems of traffic engineering, security and VPN construction when the service end-points lie in different administrative of routing domains, and where the (G)MPLS connectivity may utilize different technology types.

·     PCE (Path Computation Element) models: architecture and applications - JP Vasseur, Cisco Systems

·     Advanced MPLS L3 VPN deployment and challenges - Inter-provider VPNs, VoIP support, and MVPNs - Luyuan Fang, AT&T Labs

·     Inter-AS Security Factors and Best Practice Guidelines, Monique Morrow, Cisco Systems

·     Multi-layer traffic engineering with PCE in MPLS/GMPLS networks - Eiji Oki, NTT

Back to top

Thursday, October 20
6th PUBLIC INTEROPERABILITY DEMONSTRATION

The 6th Public Interoperability Demonstration will take place at the Isocore Internetworking Lab in RESTON, VIRGINIA. Live 3Play and IPTV - Channel Zapping demonstration will be presented for the first time in the industry. Highlights will include QoE across an IP-Optical Multi-vendor network, Multicast applications across an IP-Optical Core. In addition to the advanced next generation applications, we plan to showcase OAM functionalities for advanced MPLS-based Services including Layer 3 VPNs (with IPv6 Integration), Layer 2 PWEs and Hierarchical VPLS Services. This demonstration will also attempt to showcase Point-to-Multipoint MPLS Traffic engineering tunnels in the core and Multicast Layer 3 VPNs on the edge in parallel to advanced Ethernet aggregation services across Inter-AS VPLS services and integration of Layer 3 and Layer 2 services showcasing a true multi-service capability of the edge platforms. The demo will also focus on multiple resiliency mechanisms including state-full and stateless recovery mechanism (Graceful Restart and IP FRR). Using LSP- and Service-Ping MPLS devices will showcase their ability to perform diagnostic tasks on the control and data plane for detecting/handling failures in the MPLS/IP-enabled networks.

This year's optical layer focus will be to demonstrate compliance with standardized GMPLS addressing. For the first time, an attempt will be made to evaluate the IETF GMPLS UNI proposals for Layer 1 VPN realization. The focus of the demonstration is on MPLS to GMPLS migration strategies by demonstrating the advanced MPLS-based Layer 2 (VPLS/PWs) and Layer 3 (supporting IPv6 customers) services that can be enabled seamlessly across the GMPLS-enabled optical core networks.

For attending the demo, please contact anusha@isocore.com

DateTime: Oct. 20, 2005 11:00AM
Location: Isocore Internetworking Lab,
12359 Sunrise Valley Drive, Suite 100, Reston, VA 20191
Directions: Please visit http://www.isocore.com/directions.htm

Back to top


















Tutorial 1: Scaling considerations in MPLS networks
Ina Minei - Juniper 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.

Back to top

Tutorial 2: Inter-Provider MPLS
Azhar Sayeed, Santiago Alvarez - Cisco Systems

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
- New MPLS VPN Inter-AS/Carrier Supporting Carrier load balancing and transport configuration capabilities
- New Inter-AS Traffic Engineering capabilities (including path computation, re-optimization and protection across AS boundaries) and how these capabilities can be used by service providers to traffic engineer between networks and regions to deliver more robust, resilient and scalable networks
- Services and applications that are enabled by inter-provider MPLS configurations

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.

Back to top

Tutorial 3: Metro Ethernet Tutorial & The Evolution of Ethernet
Andrew Missing, Alcatel


Today everybody has heard of Ethernet, as every PC has an Ethernet network adapter and Ethernet-based home networking is becoming more common. However, Ethernet as a technology has been with us for more than two decades and has progressed from its’ initial use by Enterprises to becoming the preferred L2 technology for Carriers. This session provides an insight into the development of Ethernet services, the use of Ethernet over MPLS and how these are shaping the emergence of Carrier Ethernet. The session will offer a high level review of the requirements of Carrier Ethernet and the current status of the associated standards and will finish with a look at some real world Carrier Ethernet deployments.

Back to top

Tutorial 4: MPLS Network Operations & Management
Peter Busschbach - Lucent Technologies

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.

Back to top

MPLS, GMPLS and Psuedowires: The Need for Cooperation Between Standards Bodies
Adrian Farrel, Old Dog Consulting

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.

Back to top

Interprovider Pseudowires
Luca Martini, Cisco Systems

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.

Back to top

Multi-Hop PWs: "A small step for PWs, a giant step for Metro Convergence?"
David McDysan [MCI] & Florin Balus [Nortel]

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?
How can I segregate my access and core networks?
How can I scale a PW deployment in general?
How can I offer PW between administrative domains, including Inter-provider scenarios?

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.

Back to top

Multi segment Pseudo-Wires using RSVP-TE
Ron Bonica, Juniper Networks

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.

Back to top

OAM for Multihop Pseudowires
Thomas Nadeau, Cisco Systems

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.

Back to top

MPLS P2MP: from the needs definition to the solutions description
Renaud Moignard, France Telecom R&D

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.

Back to top

Design Considerations for Multicast MPLS/BGP VPNs
Maria Napierala, AT&T Labs

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.

Back to top

Carrier-Grade Multicast Deployment in MPLS Backbones
Nicolai Leymann, T-Systems

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.

Back to top

Multicast VPN Deployment Scenarios and Service Requirements
Seisho Yasukawa, NTT

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.

Back to top

Metro Ethernet and MPLS
Kireeti Kompella, Juniper Networks

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.

Back to top

MPLS, Ethernet and the Metro
Dave Allan, Nortel Networks

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.

Back to top

Next Generation Networks (NGN) Broadband Evolution: What it Means to MPLS Networks
Sangeeta Anand, Cisco Systems

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.

Back to top

Realizing services across regions utilizing dissimilar convergence layers
Andy Malis, Jonathan Sadler - Tellabs

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.

Back to top

Managing Profitable Broadband Services with MPLS
Kurt Melden, Juniper Networks

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
- MPLS Advantages for Cable Networks
- The role MPLS has in enabling new services ie. MPLS VPNs
- The future of MPLS over the next five years ie. MPLS VPNs & gMPLS

Back to top

Enhanced architecture model that deploys MPLS-enabled Ethernet-based Aggregation in DSL networks for Triple Play services
Sunil Khandekar, Alcatel

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.

Back to top

Subscriber Aware MPLS for Broadband Services
Arpit Joshipura, Redback Networks

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.

Back to top

Combining RSVP and MPLS for Scalable Admission Control
Bruce Davie, Cisco Systems

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.

Back to top

Assuring QoS: Delivering Real Time Services with MPLS Networks
Sridhar Ramachandran, NexTone Communications

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:
- How to deliver new and enhanced services with PSTN-like performance
- How to assure QoS for IP networks
- How to overcome limited resources on increasingly converged networks

Back to top

LSP Hierarchy in MPLS networks
Arthi Ayyangar, Juniper 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.

Back to top

VPN Route Reflector Architectures and Operational Impacts
Eric Brendel, Chiaro Networks

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

Back to top

Secure MPLS Backbone Design to Support IMS
Scott Poretsky, Quarry Technologies

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.

Back to top

Applicability of GMPLS to Packet LSPs and MPLS to GMPLS Migration Methods
Dimitri Papadimitriou, Alcatel Bell

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.

Back to top

Investigation of deployment scenarios for a GMPLS network migrating into an existing IP/MPLS network
Tomohiro Otani, Kenichi Ogaki and Hideaki Tanaka - KDDI R&D Laboratories
Mallik Tatipamula and Zafar Ali - Cisco Systems

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.

Back to top

MPLS and GMPLS interworking
Kohei Shiomoto, NTT

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 (work in progress), February 2005.

Back to top

Operational, Deployment and Interworking Considerations for GMPLS Technology
Zafar Ali, George Swallow, Mallik Tatipamula - Cisco Systems

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 for details.

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.
- Architecture Options for Deploying GMPLS technology.
- Qualitative analysis of these options from Operational and Deployment view point.
- How border Model renders itself for initial deployment of GMPLS technology.
- GMPLS signaling interworking issues.
- Priority Management in MPLS + GMPLS networks.
- Design consideration for Priority Management in MPLS + GMPLS networks
- Dynamic Vs. Static FA-LSP
- Tradeoff associated with the static vs. dynamic FA-LSPs.
- Conclusions

Back to top

Deploying, interworking and operating L2 and L3 MPLS VPNs// MPLS deployment experience: scaling, performance and security
Peter Himmelberger, CSC

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.

Back to top

MPLS Enterprise Customer Deployment
Tom McKinney, Cisco Systems

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.

Back to top

An All-encompassing MPLS Enabled Private IP Network
Lee Jalali, Sprint

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.

Back to top

Next Generation IP/Optical Integrated Network in KDDI
Masatoshi Suzuki and Tomohiro Otani - KDDI R&D Laboratories

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.

Back to top

Extending GMPLS for Pure Photonic Networks
Don Fedyk [Nortel Networks] & Vik Saxena [Comcast]

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.

Back to top

Dynamic optical link preemption based on GMPLS traffic engineering
Shinya Tanaka, Japan Telecom

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.

Back to top

The Unified Optical Control Plane: The Time is Now
Vijay Pandian, Sycamore Networks

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:
- Challenges of IP/Optical interoperability, and updates on progress and testing for major standards initiatives
- Key optical control plane business drivers - short term and long term
- Quantifying unified control plane business opportunities and operational benefits
- Case study: Early adopter strategies
- Practical implementation strategies, focusing on pragmatic introduction of a unified optical control plane
- The role of unified control plane in evolving service portfolios targeted at IP/MPLS applications

Back to top

IPv6&MPLS
Daniel Awduche, MCI

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.

Back to top

Case Study: Building A Successful Full Packet Voice Network and IP Network
Hamid Laamouri [Wandl] & Cristina Gentili [Telecom Italia]

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:
1- The Optical Packet Backbone Architecture
2- MPLS Functionalities on OPB
3- MPLS TE and DiffServ CoS Design
4- Migration of VoIP Traffic to OPB Network
5- FRR Engineering
6- Conclusion

Back to top

IP/MPLS for Live Broadcast Video Applications
Ryan Korte, WilTel Communications

Brief Historical Overview of the use of IP/MPLS in Live Video Applications
- Perception of the historical quality of "the Internet" has taken time to overcome
- Broadcasters initially hesitant to migrate from traditional switched video platforms to IP/MPLS
- Limitations of hardware development to support encapsulation to IP

MPLS Has Mechanisms to Deliver on Broadcasters' Demanding Needs
- Traffic Engineering capabilities provide a basis for scheduling and guaranteeing bandwidth availability and consistent performance.
    - Numerous technologies (LDP, RSVP-TE, E-LSP, L-LSP, DS-Proto, ties to queuing and scheduling)
- Restoration - fast re-route enables ability to transmit live video with minimal disruption
    - MPLS Fast Reroute vs. IGP Fast Convergence

    - How fast is fast, and how "fast" does it really need to be
- Unmatched flexibility
    - Point-to-multipoint configurations enables ubiquitous coverage
- Multicast & Types of Multicast
- MPLS's inability to natively handle multicast
    - Customized bandwidth (from high-end to low-end)
- Reservation vs. reality
    - IP integration
- Converged control and data-plane issues
    - Ubiquitous Interfaces to network infrastructure

    - Ability to support increasing demand for file-based asset delivery over the same transport infrastructure.

Case Study in IP/MPLS used for high-end live video application
- Brief overview and background on WilTel's Vyvx subsidiary
- Fox Sports' use of MPLS for primary HDTV feed of Super Bowl XXXVIII
- The Importance of Traditional Video Booking System and its interaction with the network.

Back to top

Telenor's pan-nordic NG multiservice network
Lei Wang, Telenor

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

Back to top

Some Considerations in the SLA Delivery for MPLS Enabled Networks
Dr. Roman Krzanowski

This presentation discusses the high level technical issues related to the delivery of the performance based SLAs in the MPLS networks. Topics included are:
- Instrumentation for performance monitoring
- Selection and definition of metrics
- Strategies for scalability
- Design issues- routing, configuration
- SLTs vs SLAs
- Setting performance targets: Benchmarking
- Inter-provider SLAs
- OSS support
- Aggregation and segmentation
- Extending SLAs to the edge
- Tying it all up

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.

Back to top

Multicast LDP
IJsbrand Wijnands, Cisco Systems

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
- Mapping multicast trees to P2MP and MP2MP LSP's.
This section will discuss how PIM build multicast trees can be mapped to MPLS build P2MP and MP2MP LSP's. This is important to understand how the different PIM mode like SSM, Bidir and Sparse-mode can be supported. - In-band vs. Out-of-band signaling.
When a multipoint LSP is build between an Ingress and multiple egress routers it's the ingress router that forwards multicast packets on the LSP. For the ingress router to know which specific multicast stream (can be multiple) has to be forwarded some sort of signaling has to happen between the egress and ingress routers. We identify 2 different types of signaling, in-band using the LDP message or out-of-band using an external protocol. - Extensions to LDP to build P2MP LSP's
What modifications to LDP do we need to support P2MP LSP's. - Extensions to LDP to build MP2MP LSP's
To support MP2MP LSP's there needs to be some sort of bidirectional forwarding. Labeled packets do not only go down the tree but also travel upstream. This proposal uses a combination of P2MP LSP's and merged labels to build a MP2MP LSP. - RSVP-TE vs and MLDP
This section will cover a brief comparison between MLDP and RSVP-TE and contrast the problems each solves..

Back to top

Next-Generation Solutions for Multicast in 2547 VPNs and VPLS
Rahul Aggarwal, Juniper Networks

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:
draft-ietf-l3vpn-2547bis-mcast-00.txt
draft-raggarwa-l2vpn-vpls-mcast-00.txt
draft-raggarwa-mpls-upstream-label-00.txt
draft-rosen-mpls-multicast-encaps-00.txt

Back to top

VPLS Multicast challenges and options
Marc Lasserre, Riverstone

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.

Back to top

PCE (Path Computation Element) models: architecture and applications
JP Vasseur - System Architect, Cisco Systems and co-chair of the IETF PCE Working Group

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:
- Computation of shortest paths across multiple domains (IGP area/Autonomous System),
- Computation of a set of diversely routed path spanning multiple domains,
- CPU-intensive path computations (multi-constraints objective functions)
- Multi-layers optimization (for primary traffic and network recovery optimization)

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
(2) PCE selection process and resiliency techniques
(3) PCE communication protocol
(4) Confidentiality and security

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.

Back to top

Advanced MPLS L3 VPN deployment and challenges - Inter-provider VPNs, VoIP support, and MVPNs
Luyuan Fang, AT&T Labs

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

Back to top

Inter-AS Security Factors and Best Practice Guidelines
Monique Morrow, Cisco Systems

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.

Back to top

Multi-layer traffic engineering with PCE in MPLS/GMPLS networks
Eiji Oki, NTT

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.

Back to top

 

© 2005 ISOCORE CORP. ALL RIGHTS RESERVED