MPLS 入门

嗯，想学 MPLS 吗？ Cisco 并不是唯一的方法

1. Migration Strategies for IP Service Growth: Cell-switched MPLS or IP-routed MPLS

If you currently deliver IP services through an IP-over-ATM infrastructure, you will most likely continue to do so until performance and scalability problems begin to impact the ability of your network to deliver these services. The successful delivery of services can be measured in terms of network complexity and resulting operational costs, as well as the performance that is required to deliver a satisfactory experience to your customers.

When the well-known limitations of the IP-over-ATM model start to impact the operation of your network, you will begin to examine new solutions that can overcome the limitations of your existing IP-over-ATM infrastructure. There are two potential transition strategies that you are most likely to consider:

- A transition to a cell-switched MPLS infrastructure

- A transition to an IP-routed MPLS infrastructure

Juniper Networks, Inc. believes that you should stay with your existing IP-over-ATM infrastructure until operational problems, cost structures, or strategic investment decisions force you to make a transition. However, when you make this transition, we recommend that you move directly to IP-routed MPLS, not to cell-switched MPLS. We offer this guidance because a transition from IP over ATM to cell-switched MPLS will not significantly enhance the operation of your network, yet it still requires you to make a second transition to IP-routed MPLS if you want to reach your ultimate goal. We believe that cell-switched MPLS is a slight improvement over IP over ATM, but cell-switched MPLS cannot deliver all of the benefits of IP-routed MPLS if your primary intent is to support the delivery of frame-based services.

http://www.juniper.net/techcenter/techpapers/200026.html

2. Multiprotocol Label Switching:

Enhancing Routing in the New Public Network

Both large and small Internet Service Providers (ISPs) constantly face the challenges of adapting their networks to support rapid growth and customer demand for more reliable and differentiated services. In the mid-1990s, the IP-over-ATM model provided many ISPs a solution for delivering excellent performance and performing traffic engineering. Moreover, many carriers found it cost-effective to multiplex Internet traffic as one of many services carried over an ATM core.

Recently, the growth of Internet services and Wavelength Division Multiplexing (WDM) technology at the fiber level have provided a viable alternative to ATM for multiplexing multiple services over individual circuits. In addition, the once faster and higher bandwidth ATM switches are being out-performed by Internet backbone routers. Equally important, Multiprotocol Label Switching (MPLS) offers simpler mechanisms for packet-oriented traffic engineering and multiservice functionality with the added benefit of greater scalability.

MPLS emerged from the IETF's effort to standardize a number of proprietary multilayer switching solutions that were initially proposed in the mid-1990s. To help you appreciate the importance of MPLS and its impact on the Internet core, the first half of this paper describes the forces that motivated the development and evolution of these different solutions, focusing on the common features and design considerations shared by the different solutions--the complete separation of the control component from the forwarding component and the use of a label-swapping forwarding paradigm. This section also describes the natural technological evolution that took place and that eventually culminated in the IETF working group's definition of MPLS.

The second half of this paper builds on your understanding of multilayer switching, focusing on the specifics of MPLS. It describes the goals and objectives of the MPLS working group, the core MPLS components, some of the common misconceptions about MPLS, the benefits of MPLS for the core of the Internet, and the most popular applications for MPLS. This section describes how MPLS is the foundation for service differentiation because it permits ISPs to deliver new services that cannot be readily supported by conventional IP routing techniques.

http://www.juniper.net/techcenter/techpapers/200001.html

3. Resolving Routes for MPLS Traffic Engineering

Jeff Doyle

Multiprotocol Label Switching (MPLS) traffic engineering maps certain data flows to established label switched paths (LSPs) rather than to data links calculated by the IGP to be part of the best (shortest) path. Fundamental to this function is the determination of what traffic is to be mapped to an LSP.

Traffic is mapped to an LSP at the tunnel's ingress label switching router (LSR) by designating the egress LSR as the next-hop router for certain destination prefixes. It is important to understand that the LSP does not constitute an entire route to a destination. Rather, the LSP is a next-hop segment of the route. Therefore, packets can only be mapped to an LSP if the egress LSR is considered to be a feasible next-hop candidate during the route resolution process. This paper explains the various options available with Juniper Networks JUNOS Internet software for including LSPs in the route resolution process.

This paper assumes that you understand the basics of MPLS and the JUNOS command-line interface.

http://www.juniper.net/techcenter/techpapers/200008.html

4. RFC 2547bis: BGP/MPLS VPN Fundamentals/

Until recently, there has always been a clear distinction between public and private networks. A public network, like the plain old telephone service (POTS) or the Internet, is a collection of unrelated systems that are allowed to exchange information freely with each other. A private network is composed of computers that are owned and administered by a single organization that share information with each other. Different sites in a private network are interconnected using dedicated leased lines to ensure that inter-site connectivity is always private. An enterprise that deploys a private network is assured that it is the only organization using the network and its traffic is secure.

While deploying a single VPN service model would simplify network operations, this approach cannot satisfy diverse customer requirements because each subscriber is unique. Each customer has different security concerns, number of sites, number of users, routing complexity, mission-critical applications, traffic patterns, traffic volumes, staff networking expertise, and willingness to outsource network services. To satisfy a broad range of customer requirements, service providers must offer subscribers a portfolio that contains a number of different VPN service delivery models. Over the years, a number of diverse VPN models have been proposed.

- Traditional VPNs

--- Frame Relay (Layer 2)

--- ATM (Layer 2)

- CPE-based VPNs

--- L2TP and PPTP (Layer 2)

--- IPSec (Layer 3)

- Provider Provisioned VPNs (PP-VPNs)

--- MPLS-based Layer 2 VPNs

--- BGP/MPLS VPNs or RFC2547bis (Layer 3)

This paper focuses on developing a detailed understanding of the VPN service model proposed in RFC 2547bis, which is generating a tremendous amount of interest in the service provider community. It provides a mechanism that simplifies WAN operations for a diverse set of customers that have limited IP routing expertise. RFC 2547bis is a way to efficiently scale the network while delivering revenue-generating, value-added services.

http://www.juniper.net/techcenter/techpapers/200012.html