- Introduction
- Creating an MPLS Network
- Faults
- Configuration
- Accounting
- Performance
- Security
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Creating an MPLS Network
Let's take a look at some of the very basic elements of managing MPLS networks—specifically in the areas of FCAPS. We define a highly simplified MPLS-based network service as the basis for a management model. The management of this service is the goal of this article. Figure 1 illustrates a simple MPLS network that consists of five nodes: R1, R2, R3, R4, and R5. Router R5 is attached to a network segment that contains a subnet with specific destination hosts.
)
Figure
1 A simple MPLS network.
A real MPLS network could include many thousands of nodes. We choose a tiny network just to illustrate the principles.
R1 and R5 are referred to as label-edge routers (LERs) and R2, R3, and R4 are label-switching routers (LSRs). Some authors refer to all MPLS nodes as LSRs; we distinguish between the two types because the LERs are typically more powerful than the core LSRs. This is because the LERs receive raw incoming traffic (IP, Ethernet, ATM, frame relay, etc.) and must push this traffic into special-purpose LSPs created to span the network or some part of the network.
Figure 1 illustrates two such LSPs: LSP1 and LSP2. LSP1 has been created to carry real-time traffic through the network. This consists of traffic with characteristics of low latency, high jitter, and delay sensitivity; for example, voice over IP (VoIP). Another example would be video over IP. LSP2 has been created to carry non–real-time traffic, such as email.
LSP1 is created as an MPLS tunnel using an NMS. An MPLS tunnel is basically an LSP with some type of associated set of constraints, such as the following:
Specified path
Resource reservation across the path
Other QoS-related capabilities, such as DiffServ/IntServ service classes
The specified path is illustrated in Figure 1 as R1-R2-R3-R5. This demonstrates the connection-oriented nature of MPLS; the operator can select the required path before any traffic lands on R1.
NOTE
This process is known as traffic engineering—directing the incoming traffic to those network locations where the appropriate bandwidth has been deployed.
Next, we have the resource reservation along the path—often referred to as quality of service (QoS). This consists of the required bandwidth and other traffic characteristics, such as maximum burst size, mean burst size, and so on. These characteristics are used when signaling the LSP as part of the underlying router resource reservations; technically, this amounts to reserving port buffer space, hardware queues, fabric capacity, etc. The magic of the signaling protocols (RSVP-TE, for example) takes care of a lot of the underlying complexity.
Finally, the operator can impose additional QoS requirements on LSP1 in the form of DiffServ and IntServ classes. These classes provide a greater degree of control over how the incoming traffic is managed as it passes across the MPLS network.
LSP2 is created using the LDP protocol. This LSP has no reserved bandwidth and its path is created by R1 in conjunction with its internal routing protocols.
We now have our MPLS network in place.
A Note on MPLS Forwarding
An important point to note about the MPLS domain in Figure 1 is that LSPs are unidirectional; that is, traffic is forwarded in one direction only. In Figure 1, IP traffic landing at LER1 is forwarded along one of these paths:
LSP1
LSP2
Standard IP forwarding
Suppose a VoIP packet arrives at LER1 with a destination address of 10.81.1.23. What does LER1 do with this packet? It has a choice of paths, as listed above. The default handling for MPLS is to begin by using traffic-engineered tunnels such as LSP1. If LSP1 cannot service the destination address, the next port of call is an LDP-based LSP (such as LSP2). If this route doesn't get the packet to its destination, LER1 uses best-effort IP forwarding. This is the default (user-configurable) forwarding model used by MPLS LERs from vendors such as Cisco, Juniper, and Marconi. This scheme uses just the IP destination address as the basis for MPLS forwarding. Other parameters can also be used for forwarding: source IP address, source/destination port, IP type of service field (now called the Differentiated Services field, as defined in RFC 3260). The provision of an MPLS QoS capability can be arbitrarily complex.
With our super-simple MPLS network ready, let's consider the FCAPS areas.