MPLS/BGP Virtual Private Networks Performance and Security over the Internet

White Paper

Multi-Protocol Label Switching (MPLS) is the future routing technology of the Internet. This emerging protocol furnishes service providers with a tool kit for optimizing their networks and offering incremental value-added services. MPLS simplifies the routing of packets and facilitates the selection of optimal paths through the Internet labyrinth. MPLS also supports Quality of Service (QoS) by allowing bandwidth reservations and traffic prioritization through the so-called “best effort” Internet. An additional key benefit of MPLS is its support for Virtual Private Networks (VPNs) – thus allowing service providers to sell Internet-based networking services to large corporate customers. MPLS is a natural evolutionary step for the Internet. It is based upon the existing Internet Protocol (IP) and can be easily integrated with the current routing protocols (BGP-4, IS-IS, and OSPF). Many existing core routers in the Internet can be upgraded to support MPLS simply by adding software. Newer routers already have optional MPLS capabilities included in their software. Large-scale router replacements are not necessary for a service provider to take advantage of the many benefits of MPLS. MPLS follows the contemporary Internet paradigm of moving most of the complexity of the network to the edge. This means that services (QoS, VPNs, encryption, authentication, etc.) will be applied to packets and users as they enter the Internet (the ingress to the proverbial “cloud”). This distributes the burden associated with supporting these complex functions among many edge routers. Therefore, individual routers are not required to support all of these services for all of the service providers' customers. This also means these additional processes do not encumber the core routers; instead they can remain focused on the task of rapidly forwarding packets across the backbone of the network. MPLS is a network layer (Layer 3) protocol. Routing decisions and reachability information are based upon IP addresses. Therefore, Layer 3 is also the foundation for any services offered by MPLS-based networks. Accordingly, VPN services are also based upon the underlying Layer 3 infrastructure. There are actually three types of Virtual Private Networks that can be supported by MPLS: I

Point-to-Point Tunnels: Virtual connections between remote sites over MPLS; emulates a Layer 2 point-to-point circuit

I

Layer 2 MPLS VPNs: Extends customers’ Layer 2 connectivity across an MPLS infrastructure; commonly called “Martini/Kompella VPNs,” after Luca Martini and Kireeti Kompella who helped develop this methodology

I

BGP/MPLS VPNs: Layer 3 VPNs; these use extensions to the existing routing protocol of the Internet (BGP-4) to interconnect remote locations; also called “RFC 2547”

Spirent White Paper: MPLS/BGP Virtual Private Networks

2

Two of the three methods manipulate MPLS’s Layer 3 services to emulate Layer 2 connections. The third option, and the focus of this paper, is based entirely upon Layer 3 – the most elegant VPN solution!

MPLS Overview MPLS is a protocol designed to streamline the Internet and other large networks. Typically, MPLS only resides in Service Provider and carrier networks; it does not have much use within enterprise, academic, government or other private networks. MPLS provides tools to simplify, optimize and add services to the current Internet infrastructure. Each of these three benefits is briefly discussed below. This brief overview of MPLS provides a baseline from which VPNs can be effectively discussed. For more detailed information about MPLS, please see the “References” section at the end of this white paper. Note: The primary focus of this paper will be MPLS VPNs; this is not an MPLS tutorial.

Network Simplification Conventional wisdom in the data communications industry suggests that “switching” is simple and “routing” is complex. MPLS allows IP packets to be “switched” through the Internet. To switch the packets, a short (4-byte) label is inserted in the packet header. This label is then used to forward the packet between routers throughout the Internet. This label is inserted at the ingress to the MPLS domain, and then removed at the egress. Hence, an IP packet is generated at the source (a workstation, for example) and an IP packet is delivered to the destination (i.e. a file server). The fact that an MPLS label temporarily exists between the source and destination is completely transparent to the users, the applications and even the customer’s networking equipment.

As indicated above, the MPLS Label (often called a “shim”) is placed between the Layer 2 (e.g. Ethernet) and Layer 3 (IP) headers in the packet. Packets are then switched based upon the label values. The labels only have local significance (similar to Frame Relay DLCIs or ATM VPI/VCIs) and will change from hop to hop as the packet traverses the Internet. In the diagram on the next page, four MPLS routers, also called Label Switching Routers (LSRs) are shown. These routers all reside in the Internet, or within the “cloud.” Therefore, the terms “ingress” and “egress” refer to the entry and exit points of the Internet. As a packet enters the Internet a label is inserted or “pushed” onto the packet header. This label is then exchanged or “swapped” at each intermediate router hop. This is accomplished by mapping the incoming label to an outgoing label based upon the entries in a table contained inside the router. For example, a packet might arrive via port six with a label value of 45. The router’s label table may indicate that such a packet then needs to be forwarded via port ten with a label of 61. In which case the appropriate Layer 2 header will be built for the outbound link layer protocol associated with port ten and the label value of 45 will be replaced with a label 61. The label is eventually removed or “popped” from the packet at the egress of the Internet and an IP packet is delivered to the customer’s destination network. This packet can then be forwarded to its final destination via standard IP routing procedures.

Spirent White Paper: MPLS/BGP Virtual Private Networks

3

The MPLS label field will support over one million unique labels. However, the creation of massive label tables will require considerable routing hardware resources. Therefore, it is highly recommended MPLS networks be designed with limited quantities of labels in the routers' tables. A label table can be as simple as having one entry per physical port on the router. Hence, if a packet is received with a label value of 22, the router will know to forward that particular packet to interface 22. The fundamental axiom for label tables is that small is better. This reduces latency, simplifies the routers’ lookup procedures, and also simplifies the overall network. Simplicity is further realized because MPLS is a connection-oriented service. This is the antithesis of the current connectionless Internet! Packets are routed through today’s Internet on a hop-by-hop basis. Each individual router reads a packet’s destination IP address and then searches its Internet routing table (which currently has approximately 120,000 entries) to determine the next router hop for that particular packet. This process is repeated at every intermediate router hop. Packets with the same destination address do not necessarily follow the same path since independent decisions are made at each router hop. MPLS, on the other hand, establishes a more efficient path for communications based upon the first packet of a stream. Once the path is established, all subsequent packets will follow the same route (called a Label Switch Path or LSP). Routers therefore will only need to switch the packets along a pre-defined LSP.

Network Optimization Another substantial benefit of MPLS is it truly optimizes a service provider’s network. This is accomplished by using policies to determine when and where to establish label switch paths (LSPs). These policies can be influenced by any subjective or objective criteria the service provider chooses. Some possible selection criteria are: I

Source or Destination IP Address

I

Source or Destination Port or Socket Number

I

IP Protocol ID

I

IP Differentiated Services Code Points or TOS bits

I

Layer 2 Values (VLAN tag, DLCI, VPI/VCI)

I

Available Network Resources

I

Cost or Price

Spirent White Paper: MPLS/BGP Virtual Private Networks

4

Policy engines within the routers can use these or other criteria to calculate a forwarding equivalency class (FEC) for a given traffic stream. An LSP is then established and a label is created that will be associated with this particular FEC. The entire stream will then flow through the network using that particular FEC and LSP. In early implementations of MPLS, the destination IP address was the only criterion for determining the forwarding equivalency class of a traffic stream. However, as the implementations mature, other criteria will be used to assign a traffic stream to the appropriate FEC depending on the available network resources or the desired class of service. Policy decisions can help carriers optimize their networks. Depending on the service provider’s business model, policy decisions can also provide preferential service to premium customers. And finally, policy decisions can logically segment traffic between customers.

Value Added Services Beleaguered service providers continue to need new and incremental sources of revenue. The MPLS network architecture supports additional services that lead to additional revenue opportunities for service providers. On the most fundamental level, traffic can be separated by different classes of service. This allows service providers to offer tiered services at tiered price structures. This service differentiation is implemented simply by assigning different traffic streams to the appropriate forwarding equivalency classes. The fundamental principles of label switch paths (LSPs) are based upon traffic separation and segmentation. By design, MPLS lends itself to the concept of virtual private networks, thus creating another significant revenue opportunity for service providers.

VPNs and VPNs Virtual private networks (VPNs) have existed for 20 years – an eternity by Internet standards! Yet, they were known by different names and acronyms. Although the term “VPN” is relatively new and fashionable, the underlying technology has gone through several evolutionary cycles in the past two decades. The term “VPN” is very loosely defined – many people choose to interpret this term differently. For the purposes of this paper, a virtual private network means a private multi-site network created by using shared resources within a public network. This is a generic definition that is open for interpretation (or misinterpretation as the case may be). As a result of the broad definition of VPN, many contemporary communications technologies can legitimately claim to support virtual private networks. There are no rules associated with VPNs. They can be implemented with the prevailing technology and with the users' objectives. VPNs are commonly established and terminated from workstations, using the Internet as a transport mechanism. Examples of this type of VPN include Layer 2 Tunneling Protocol (L2TP), Point-to-Point Tunneling Protocol (PPTP), and IPSEC. All of these protocols represent valid examples of VPNs in conjunction with the above definition. They interconnect private networks by using the shared resources of the Internet. Another popular type of VPN is a Provider Provisioned VPN (PPVPN). In these networks, the service provider supplies transparent connectivity (over shared carrier resources) to multiple customer sites. An early example of PPVPNs was X.25 – a wide area networking protocol designed specifically for interconnecting geographically distant locations. Frame Relay and ATM are contemporary instances of PPVPNs. So are MPLS VPNs.

Spirent White Paper: MPLS/BGP Virtual Private Networks

5

RFC-2547bis Layer 3 MPLS provider provisioned VPNs are truly outstanding solutions from the perspectives of service providers and end users. They are entirely transparent to customers, meaning no additional configuration, addressing, or provisioning of customers’ networking equipment is necessary. The methodology for implementing Layer 3 PPVPNs is codified in RFC 2547bis – this particular RFC is still in draft form, but is expected to be officially adopted in July, 2002. Layer 3 MPLS PPVPNs (truly a mouthful of acronyms!) are commonly called RFC 2547 VPNs, or just RFC 2547 implementations. These virtual private networks are contingent on MPLS LSPs, so they provide the user with all benefits associated with this technology. Hence the performance advantages, along with traffic classification and segmentation inherent to MPLS, provide a solid foundation on which virtual private networks can be constructed. An additional benefit provided by these VPNs is the preservation of the customer’s existing IP address scheme. Even if a service provider’s customers have overlapping IP address spaces (i.e. 10.x.x.x networks), these addresses will be effectively segmented so that data and control traffic will remain exclusively within the correct VPNs. All of these features are implemented by using the Layer 3 capabilities of the MPLS-enabled network.

MPLS VPN Components An architectural paradigm is described above in which services are implemented at the edge of the network. RFC 2547 VPNs follow this model. In fact, the VPNs only exist at the edge of the service provider’s network. The core routers do not participate in the actual VPNs, they just continue to forward packets over various LSPs. The customer’s routers also do not participate in the VPNs, since they simply continue to route IP packets in according to the customer’s established addressing and routing schemes. RFC 2547 VPN drafts define their own unique vocabulary terms to clearly identify each of the individual network elements. Each of the routers in the VPN has its own designation and acronym, as indicated in the diagram below.

Spirent White Paper: MPLS/BGP Virtual Private Networks

6

CE Routers These are the Customer Edge devices. These routers are customer owned routers. They run the routing protocol(s) of the customer’s choice, and they support the IP address scheme implemented by the customer. These routers are unaware of the existence of the MPLS protocol or the VPNs. However, the “next hop” router from the CE’s perspective is the PE router.

P Routers The P Routers are the Provider routers in the core of the network. These are the label switch routers (LSRs) referred to in the MPLS overview section above. These routers switch MPLS packets over established LSPs. These, too, are entirely unaware of the existence of RFC 2547 VPNs.

PE Routers The Provider Edge routers are the workhorses for RFC 2547 VPNs. All of the functions associated with establishing, maintaining and operating MPLS VPNs take place in the PE routers. A PE router is directly connected to the customer edge (CE) routers. Typically, a PE device will be connected to multiple CE devices supporting different customers. The PE router will communicate with the CE router via the routing protocol selected by the customer (RIP, OSPF, BGP, static routes, etc.). Thus, the PE router will participate in the customers' Layer 3 networks; it will learn all of the customers’ routes and will deliver packets derived from that information. This means that if a PE router is connected to a dozen different customers, it will need to participate in a dozen different networks, each of which will have unique addressing plans and routing protocols. The PE router also must communicate with other PE routers to exchange reachability information. If a customer in Los Angeles has a branch office in Dallas, the PE router in L.A. will need to communicate with the router in Dallas to establish the appropriate VPN tunnel. To accomplish this task, PE routers run Multi-Protocol BGP on their wide area links. The PE routers will also need to initiate and terminate LSPs for MPLS traffic to be routed across the backbone (via the P routers). This means PE routers must also implement the MPLS protocol as edge LSRs (ELSRs). All of the functions outlined above are resource intensive. Combined (which is necessary to implement RFC 2547 VPNs), these functions can quickly exhaust a PE router’s CPU and memory resources. Hence, any scalability or performance challenges associated with RFC 2547 VPNs will be focused directly on the provider edge (PE) routers.

VRFs The PE routers will participate in the routing and IP numbering plans of each and every directly connected customer. Many of these numbering plans may overlap (such as the commonly used 10.x.x.x address space). The PE routers must ensure that traffic destined for Company A’s 10.x.x.x network will not be delivered inadvertently to Company B’s 10.x.x.x IP network. To achieve this, PE routers have to maintain separate opaque routing and forwarding tables for each and every directly connected customer. These routing instances are called VPN Routing and Forwarding tables (VRFs). The methods for implementing VRFs vary from vendor to vendor. This is a highly critical component of RFC 2547 VPNs because this implementation ensures the appropriate segmentation of data and control plane traffic.

Routing VPN routing and forwarding tables must be populated with the correct routing information for the appropriate VPNs. This routing topology data must be isolated for individual VRFs and cannot be allowed to leak into other VRFs. This is accomplished by adding an identifier known as a route distinguisher to traditional IP router advertisements.

Spirent White Paper: MPLS/BGP Virtual Private Networks

7

Route distinguishers are 8-byte blocks placed before an IPv4 network route to identify the VRF that the route belongs to. All VRFs must have unique route distinguishers. A route distinguisher contains three fields. The first two-byte field indicates the type of route distinguisher that follows. The second field identifies the autonomous system number (ASN) of the ISP from which the VRF originated. And the next field is an assigned number for the VPN within that ISP. Therefore, a route distinguisher may be represented as 200:50. In this example, 200 is the ASN of the ISP and 50 is the number assigned to that particular VRF. This numbering system ensures all VRFs have universally unique identifiers, even as they cross multiple ISPs. The route distinguisher is the mechanism facilitating overlapping customer IP address spaces; it associates each of these addresses with the correct VRF. Note: This identifier is exclusively for routing updates, or control traffic, and it does not concern data traffic at all.

Routing updates are accomplished via a derivative of the Border Gateway Protocol (BGP). All PE routers communicate with each other via Interior BGP (IBPG) with Multi-Protocol extensions. The route distinguisher becomes part of the Network Layer Reachability Information (NLRI) field of a Multi-Protocol BGP (MBGP) routing update. BGP updates are always based on the import and export routing policies of each individual router. For a VRF to be established within a PE router, an explicit policy must be in place to accept (import) and propagate (export) the particular route distinguisher associated with that VRF.

Data Traffic RFC 2547 VPNs transfer data between the endpoints of the VPNs via MPLS. IP packets are simply labeled by the ingress PE router (according to the appropriate forwarding equivalency class) and forwarded to the proper LSP. Note: Multiple LSPs and FECs could exist between any two VPN endpoints in order to facilitate different qualities of service for different users and/or applications. The only difference between a RFC 2547 VPN packet and any other MPLS packet is that the VPN packet will carry two labels. The basic rules of MPLS permit multiple labels (also called label stacks) to be added to an IP datagram. All traffic forwarding decisions are made depending on the top label of the stack– also called the outer label. This label is swapped as the packet is routed/switched through the Internet in accordance with standard MPLS rules and procedures. In RFC 2547 VPNs, this label is used to forward the packet to the egress PE router. Upon arriving at the egress router, the MPLS label will be removed and the packet will be forwarded to its end destination based upon its IP address. However, as stated previously, in an MPLS VPN implementation, customers’ IP addresses can and often will overlap. Therefore, the PE router requires additional information to correctly identify the packet and forward it to the appropriate customer. The inner label provides this information. In short, the outer label is used to route the packet through the MPLS domain to the egress router. Then the inner label is used to deliver the packet to the correct customer.

Spirent White Paper: MPLS/BGP Virtual Private Networks

8

To further illustrate the necessity of an inner label, consider the case of a so-called “smart building” in a downtown metropolitan location. A service provider might deliver a single Gigabit Ethernet pipe to a multi-tenant office building. From the service provider’s perspective, all tenants in that building (attorneys, architects, travel agents, etc.) share the same single physical port on their network. Furthermore, assume that all of these tenants have overlapping IP addresses. In this scenario, terminating MPLS at the PE router and delivering an IP packet to the building’s shared gigabit Ethernet is not sufficient. Instead, the inner label is necessary to correctly identify and deliver the packet, for example, to the architects’ office instead of the travel agency. Once the packet has been identified (via the inner label) as a packet destined for the architects’ office, it can then be forwarded via MAC address directly to their router, or it can be assigned to the appropriate 802.1q VLAN.

Security VPNs do not guarantee security. Instead, they imply security. That is, users expect to receive a secure connection, and the service providers do nothing to refute or discourage this expectation. Therefore, it is very important VPNs users understand the networking technology upon which secure connections exist. They can then judge for themselves whether or not that particular technology provides an acceptable level of security and risk. RFC 2547 VPNs address security by supporting traffic separation and segmentation. When properly implemented, and when the service provider’s routers are all correctly provisioned, each individual customer is represented by a unique VRF. Traffic destined for each VRF will carry its own inner label value. Therefore, Company A’s data traffic will be logically and physically separated from Company B’s information. This method is directly analogous to the security offered by a Frame Relay network. Additional measures can be implemented to supplement the basic security features associated with RFC 2547 VPNs. Encryption is probably the most desirable method for ensuring data security; most IP encryption mechanisms can reside seamlessly on top of an MPLS infrastructure.

Testing MPLS VPNs MPLS is a relatively new protocol. MPLS VPNs are even newer. Standards and technology continue to evolve. Vendors interpret these standards from their own experiences, requirements, and capabilities. Service providers also interpret these changing standards depending on their needs. This creates many distinct nuances of disparity between the various MPLS implementations. In short, the only way to truly verify MPLS VPN capabilities is to test, test, and test! The provider edge (PE) routers must handle many concurrent complex tasks to support RFC 2547 VPNs. Each of these tasks utilizes significant processing and memory resources. As the network grows, resource requirements increase even further and not necessarily in a predictable manner. Scalability constraints will exist in all types of equipment and all networks. Understanding these limits is essential prior to deploying or using MPLS VPN services. All RFC 2547 testing should focus on the PE routers. This testing has three components: conformance testing, functional testing and performance testing.

Spirent White Paper: MPLS/BGP Virtual Private Networks

9

Conformance Testing Conformance testing confirms a vendor adheres to the prevailing standards. This tests for strict compliance with the latest revisions of the RFCs. Since PE routers have many functions, there are several separate conformance test suites that must be conducted. These include: I

MPLS – RSVP/TE

I

MPLS – LDP

I

BGP-4 and MPBGP

I

OSPF

I

IS-IS

I

RIP/RIP2

Conformance testing will also help determine (or debug) interoperability issues between different router vendors.

Functional Testing Functional testing verifies that the various component parts of MPLS VPNs can correctly work in unison. Some suggested functional tests are: I

Maintenance of Separate VRFs

I

Properly Forward Routes to Other PEs

I

Handle Multiple Customer Router Protocols Simultaneously

I

Properly Assign and Distribute Labels

I

Properly Handle Multiple Customers per Physical Port

I

Continue to Forward Data While Processing Routing Updates

Negative testing should also be included in this category. This involves sending the PE invalid routing updates and incorrect packets. In this case, the PE should continue to process correct information while disposing of bad packets.

Performance Testing Performance testing typically means testing the raw throughput of a router, as measured in packets per second. While this certainly is a valid test, there are many other aspects of performance testing that should be considered in an RFC 2547 implementation. Most notably, scalability should be tested. Some questions that should be addressed by performance testing are: I

How many VRFs can a PE router handle?

I

How many routes are supported per VRF?

I

How many LSPs can the PE router support?

I

How many IBGP peers can the router maintain?

I

What is the end-to-end network performance?

I

What is the forwarding rate of the PE when IP and MPLS traffic are mixed?

I

What is the latency and jitter of the PE router?

I

How many customers are supported per physical port?

Spirent White Paper: MPLS/BGP Virtual Private Networks

10

Summary MPLS is a winning solution for service providers. Its standards can optimize and simplify their networks and increase their revenue streams for a minimal investment in equipment. Overall, MPLS represents an extremely attractive business and technical opportunity for service providers. MPLS virtual private networks provide another appealing business opportunity. Service providers are anxious to offer these lucrative services to their corporate customers. However, VPNs create a high degree of complexity that offsets some of the simplicity of a raw MPLS network. If this complexity is understood and controlled, VPNs can be a powerful and profitable tool for service providers. Network and router testing will help service providers tame this complexity. MPLS standards currently represent a moving target. Equipment manufacturers and service providers are trying to build products and networks out of their own interpretations of these dynamic standards. Many MPLS VPN implementations result from this situation. Again, the best advice for anyone considering implementing MPLS VPNs is simple: test, test, and test. The time invested while testing in advance of any deployment will yield many long-term dividends.

References 1. Davie, Bruce and Y. Rekhter MPLS Technology and Applications Morgan Kaufmann Publishers 2000. 2. Guichard, Jim and I. Pepelnjak MPLS and VPN Architectures: A Practical Guide to Understanding, Designing and Deploying MPLS and MPLS-Enabled VPNs Cisco Press 2000 3. Tomsu, Peter and G. Weiser MPLS-Based VPNs Prentice Hall 2001

Internet Standards and Drafts I

RFC 1771 – A Border Gateway Protocol, March 1995

I

RFC 2205 – Resource Reservation Protocol (RSVP), September 1997

I

RFC 2207 – RSVP Extensions for IPSEC Dataflows, September 1997

I

RFC 2210 – The Use of RSVP with IETF Integrated Services, September 1997

I

RFC 2328 – OSPF Version 2, April 1998

I

RFC 2547 – BGP/MPLS VPNs, March 1999

I

RFC 2702 – Requirements for Traffic Engineering over MPLS, September 1999

I

RFC 2858 – Multi-Protocol Extensions for BGP, June 2000

I

RFC 3031 – Multi-Protocol Label Switching Architecture, January 2001

I

RFC 3033 – Use of Label Switching on Frame Relay Networks, January 2001

I

RFC 3036 – LDP Specification, January 2001

I

RFC 3038 – VCID Notification over ATM Link for LDP, January 2001

I

RFC 3107 – Carrying Label Information in BGP-4, May 2001

I

RFC 3209 – RSVP-TE, December 2001

I

draft-ietf-ppvpn-rfc2547bis-01 – BGP/MPLS VPNs, January 2002

I

draft-ieft-mpls-multicast-07 – Framework for IP Multicast in MPLS, January 2002

I

draft-ietf-mpls-rsvp-lsp-fastreroute-00 – Fast Reroute Extensions to RSVP-TE for LSP Tunnels, January 2002

I

draft-martini-l2circuit-trans-mpls-09.txt – Transport of Layer 2 Frames Over MPLS, April 2002

Spirent White Paper: MPLS/BGP Virtual Private Networks

11

Glossary (Autonomous System) A part of a network under a single administrative domain. Usually running a single internal routing protocol. (Border Gateway Protocol) The exterior gateway protocol used for distributing routes over the Internet. Currently, version 4 (BGP-4) is used. The process of associating a label with a Forwarding Equivalence Class (FEC). (Customer Edge Device) Router or switch in the customer’s network that is connected to a service provider’s provider edge (PE) router and participates in a Layer 3 VPN. Using Control Messages (such as the Label Distribution Protocol) or specific predetermined commands and parameters to bind a label to an FEC. This is a static form of binding. See CE device. (Classless Inter-Domain Routing) IP routing which uses the subnet masks to determine the size of each individual subnet. Supports variable subnet lengths. Obsoletes the concept of “Class A, B, C” networks. In BGP route reflection, a member of a cluster that is not the route reflector. See also nonclient peer. In BGP, a set of routers that have been grouped together. A cluster consists of one system that acts as a route reflector, along with any number of client peers. The client peers receive their route information only from the route reflector system. Routers in a cluster do not need to be fully meshed. (Constraint-Based Routed Label Distribution Protocol) Extensions of the Label Distribution Protocol (LDP) to support traffic engineering. (Customer Premises Equipment) Telephones, routers or other service provider equipment located at a customer site. In traffic engineering, a path determined using RSVP-TE or CR-LDP signaling and constrained using CSPF. The ERO carried in the packets contains the constrained path information. (Constrained Shortest Path First) A Shortest Path First (SPF) IGP algorithm that has been modified to take into account specific restrictions when calculating the shortest path across the network. Dynamically binding a label to an FEC based upon the data stream. (Data Link Circuit Identifier) Frame Relay circuit Ids. These convert directly to MPLS labels. (Downstream on Demand) A method for assigning labels via a label distribution protocol. The ingress router requests a label from the remote end. (Downstream Unsolicited) A method for assigning labels via the Label Distribution Protocol. The egress router assigns labels without being requested to do so from the ingress router. (Exterior Gateway Protocol) Any routing protocol used for distributing routes between autonomous systems. BGP-4 is now the most commonly used Exterior Gateway Protocol. The location at which a datagram exits the MPLS network. (Edge Label Switch Router) A router at the ingress and/or egress of the MPLS network. This router assigns and/or removes the datagram’s label. (Explicit Route) A route specified at the point of origination. Does not require routing decisions at each hop of the network. (Explicit Route Object) Extension to RSVP or LDP that allows an RSVP-TE PATH message or CR-LDP Label Request to traverse an explicit sequence of routers that is independent of conventional shortest-path IP routing

Spirent White Paper: MPLS/BGP Virtual Private Networks

12

Mechanism for effecting local repair by automatically rerouting traffic from an LSP if a node or link in the LSP fails, thus reducing the loss of packets traveling over the LSP. (Forwarding Equivalence Class) A group of IP packets forwarded in the same manner – that is, over the same path, with the same priority and the same label. (Interior Gateway Protocol) A routing protocol for distributing routes within a single Autonomous System. RIP and OSPF are the most commonly used IGPs. The point at which a datagram enters the MPLS network. A short fixed-length identifier associated with a Forwarding Equivalence Class. (In MPLS, 20-bit unsigned integer in the range 0 through 1048575 used to identify a packet traveling along an LSP) The replacement of multiple incoming labels for an FEC with a single outgoing

label.

Adding multiple MPLS Labels to a single datagram. This can be used when multiple MPLS networks are traversed and is also used for MPLS VPNs. Using the incoming label to determine the outgoing label, encapsulation and port. Then replacing the incoming label with the outgoing label. Extensions to RSVP to set up traffic engineering LSPs. (Label Distribution Protocol) A protocol used for distributing MPLS labels within MPLS. There are multiple types of label distribution protocols of which “LDP” is only one possible choice. Protocol.

Two routers that exchange information with each other via the Label Distribution

(Label Switched Path) A data-forwarding path through one or more LSRs determined and based upon the labels attached to each data packet. A traffic engineering LSP capable of carrying multiple data flows. (Label Switch Router) An MPLS-capable router. In the context of traffic engineering, a path that can use any route or any number of other intermediate (transit) points to reach the next address in the path. (Definition from RFC 791, modified to fit LSPs.) (Multi-Protocol BGP) An extension to BGP that allows advertisement of IPv6, multicast, and other non-IPv4 topologies within and between BGP autonomous systems. forwarding based on simple labels.

A set of protocols for the Internet, which facilitate packet

A contiguous set of nodes that operate MPLS routing and forwarding, and are found in one Routing or Administrative Domain. (Maximum Transfer Unit) Limit on segment size for a network. (Open Shortest Path First) A commonly used interior gateway protocol. The process of running MPLS (Label Switching) over an ATM (cell switching) network. The LSR in a traffic flow immediately prior to the egress router. This LSR can also remove the Label from the packet prior to forwarding the datagram to the egress router. This is used to simplify the egress router’s job. (Provider Edge Router) A router in the service provider’s network connected to a customer edge (CE) device and that participates in a Virtual Private Network (VPN). (or P Router) Router in the service provider’s network that does not attach to a customer edge (CE) device. (Provider Provisioned Virtual Private Network)

Spirent White Paper: MPLS/BGP Virtual Private Networks

13

(Routing Information Protocol) Another commonly used interior gateway protocol. Typically used for smaller or simpler networks, while OSPF supports large complex infrastructures. Identifier attached to a routing update that distinguishes which VPN it belongs to. Each routing instance must have a unique distinguisher associated with it. Each route distinguisher is a 6-byte value. (Resource Reservation Protocol) A signaling protocol that reserves resources throughout an IP network. Supports IP QoS. (Resource Reservation Protocol with Traffic Engineering) extensions. One of the two commonly used signaling protocols for the establishment, maintenance and removal of LSPs. (Stacking Bit) A single bit in the MPLS Header that indicates the existence of stacked labels. Another term for an MPLS label inserted between the layer-2 and layer-3 headers of a packet. (Service Level Agreement) An agreement (usually a contract) between a service provider and users. Guarantees a certain quantitative and/or qualitative level of service. In the context of traffic engineering, a static route that requires hop-by-hop manual configuration. No signaling is used to create or maintain the path. Also called a static LSP. In the context of traffic engineering, a route that must go directly to the next address in the path. (Definition from RFC 791, modified to fit LSPs.) (Type-Length-Value) The encoding method for LDP messages. Process of selecting the paths chosen by data traffic to balance the traffic load on the various links, routers, and switches in the network. (Definition from http://www.ietf.org/internet-drafts/draft-ietf-mpls-framework-04.txt.) See also MPLS. egress router.

In MPLS, any intermediate router in the LSP between the ingress router and the

Private, secure path through an otherwise public network. (Voice over MPLS) A method for carrying voice traffic over an MPLS network. (Virtual Path Identifier/Virtual Channel Identifier) ATM addresses. These map directly to MPLS labels. (Virtual Private Network) A private network created by utilizing shared resources within a public network. The forwarding table contained within an LSR for VPN support.

Copyright © 2002 Spirent Communications. All rights reserved. Spirent and the Spirent logo are trademarks of Spirent plc. All other names are trademarks or registered trademarks of their respective owners and are hereby acknowledged. Specifications subject to change without notice. W5103-A01 0602