12.3 MPLS Operation and Design Principles


MPLS offers functionality that works in unison with, rather than replacing, the existing infrastructure. MPLS can also be used for VPNs, intradomain routing, and interdomain routing. Before launching into a technical discussion of the intricacies of MPLS, it is necessary to explain the basic functionality of the protocol, as well as to introduce the reader to the terminology that will be used throughout the rest of this chapter. The following section offers a functional overview of MPLS and includes an introduction to common MPLS terminology.

12.3.1 Functional Overview

An MPLS-enabled network gives the network engineer precise control over how traffic flows from source to destination. To provide this control, MPLS allows packets to move independently of the IGP routing algorithms native to the network being crossed. To accomplish this, MPLS relies on predefined paths, known as LSPs.

LSPs are composed of connections between MPLS-enabled routers. A router that is running MPLS is known as a label-switching router (LSR). LSRs tag each packet passing through the LSP with a label. This label accomplishes several things, the most important of which is distinguishing the MPLS packet from a regular IP packet, thereby entitling the packet to continue crossing each LSR along the LSP without being subjected to Layer 3 scrutiny. The packet's label is changed by the LSR at every hop, hence the name label-switching router.

JUNOS uses MPLS as the foundation for two types of services: traffic engineering and RFC 2547bis (BGP/MPLS) VPNs. For a detailed explanation of VPNs, see Chapter 13.

12.3.1.1 Labels

Labels are a way of marking packets destined for a specific address. Packets are assigned labels by LSRs. Once they are assigned labels, they can be forwarded through the network to the next LSR along a preconfigured path . When the packet arrives at an LSR, the label distinguishes this packet from other IP traffic and allows it to be handled by the MPLS protocol. This form of packet distinction permits the MPLS protocol to function on the same interfaces as the native IGP without interfering with the IGP's routing calculations or processes.

Figure 12-6 illustrates the MPLS label format, as well as the location of the MPLS label with regard to the Layer 2 and Layer 3 headers. The following list defines the label fields shown in Figure 12-6.

  • 20-bit label field ”This is the actual label value itself. This is where the label value is inserted.

  • 3-bit experimental field ”These bits are used for CoS. They are defined as experimental because a concrete decision has not yet been reached as to which version of CoS they will support (IP Precedence or Differentiated Services).

  • 1-bit stacking field ”This field value is either 1 or 0. A value of 1 denotes the label is the bottom of a label stack. A value of 0 indicates that there are multiple labels stacked on this packet. Label stacking is discussed in Chapter 13.

  • 8-bit TTL field ”In some situations the value in this field is copied from the IP header TTL field. This is decremented as it passes through MPLS hops. When the label is popped, this value can overwrite the IP header TTL field.

Figure 12-6. MPLS Label Format

graphics/12fig06.gif

Figure 12-6 also shows the positioning of the MPLS label with regard to a typical IP packet. The diagram shows that the label resides between the Layer 2 frame and Layer 3 packet. Table 12-1 lists details about the label value ranges and use and introduces two previously unmentioned terms, penultimate hop popping (PHP) and ultimate hop popping (UHP). These terms are covered in Section 12.5 and Case Study 1 at the end of this chapter.

Table 12-1. JUNOS MPLS Label Values
Label Value Label Use
IPv4 Explicit NULL Label ”When receiving a label of level 0, the local system must pop the MPLS stack and route the packet by traditional IPv4 routing. This is known as ultimate hop popping (UHP).
1 Router Alert Label ”Similar use as the Router Alert Option in IP packets. This level would signal the local system to send the packet to a local software module for processing.
2 IPv6 Explicit NULL Label ”When receiving a label of level 2, the local system must pop the MPLS stack and route the packet by traditional IPv6 routing.
3 Implicit NULL Label ”This label is used to signal the penultimate LSR (the one before the egress LSR) to pop the MPLS stack. This is known as penultimate hop popping (PHP).
4 “15 This level is reserved by RFC standards.
16 “1,023 These labels are not used by JUNOS in the automated process of creating labels for an LSP. The administrator uses these labels when defining static LSPs. This eliminates the possibility of dual assignments by JUNOS when establishing labels for LSPs.
1,024 “99,999 This level is reserved in JUNOS for future support, but can currently be used by the administrator when defining static LSPs.
100,000 “799,999 These are per-box labels assigned by JUNOS when establishing labels for LSPs.
800,000 “1,048,575 JUNOS uses this level for per-interface labels.

The combination of label number and inbound interface is cross-referenced against a table to determine the outbound interface and label. Once these have been determined, three common operations can be performed by LSRs on labels:

  1. Push ” The MPLS label is added to packets and the packets are forwarded along the LSP. This operation is performed as the packet enters the LSP.

  2. Swap ” The MPLS label is changed as the packet carrying it passes through an LSR. This process is performed at each transit hop along the LSP.

  3. Pop ” The MPLS label is removed from the packet and a normal IP packet is forwarded by the LSR. This process is performed by the penultimate (second-to-last) LSR.

12.3.1.2 LSPs

MPLS is based on the creation of LSPs. These LSPs are used to forward packets from a source to a destination. LSPs are engineered on top of an already existing IP-based core network. The LSPs themselves are created in a unidirectional manner. Traffic engineering controls data flows; thus, each given direction of a bidirectional flow may be engineered to meet specific requirements. This allows finer control of path engineering. Usually, the return path is engineered across the same set of hops, although this is not a necessity. MPLS does not, however, guarantee the delivery of the packet. This must still occur at higher layers , such as the transport layer or the application level.

MPLS LSPs can be formed either statically or dynamically. In static configuration, the network administrative team must define which label number to use and the next-hop information. In dynamic configuration, protocols like RSVP are used to signal label information between the ingress LSR and the egress LSR. This eliminates the need for administrators to define which label values and next-hops to use, however, there is the capability to use administrative constraints within JUNOS to further control LSP negotiation and setup. For a detailed description of constraints, see Sections 12.3.2.2 and 12.3.2.3.

The MPLS signaling protocol RSVP provides the ability to configure constraints (path requirements) along the LSP. By employing these constraints the engineer is able to define specific LSRs along the LSP as being either strict hops or loose hops. A strict hop is a requirement that the path be formed through a specific interface to an immediately connected LSR. A loose hop is a requirement that an LSP pass through a specific LSR. However, with loose hops there is no requirement that a specific interface be used.

To form the LSP, Constrained Shortest Path First (CSPF) relies on specific pieces of information that are stored in a traffic-engineering database (TED) created based on information carried by the IGP, be it IS-IS or OSPF.

Manually configuring and defining the swapping of labels at each hop creates static LSPs. Static LSP creation is useful when implementing MPLS across small networks, or in situations where there is simply not enough bandwidth to support a signaling protocol. See Section 12.5 for an example of creating a minimal configuration for static LSPs.

12.3.1.3 LSRs

An LSP is built across the following component LSRs:

  • Ingress ”This is the point of origin of the LSP. By definition, it is the first router in the LSP.

  • Transit ”This is any router in the LSP that does not provide ingress or egress functionality.

  • Penultimate ”This is the second-to-last transit router in an LSP. The penultimate router is capable of popping the MPLS label and sending a true IP packet to the egress router.

  • Egress ”This is the last router in an LSP.

A single router is capable of filling multiple roles for different LSPs. A transit router for one LSP could also be the ingress router for another LSP. The egress router for one LSP could be a transit router for another LSP. There are no mandatory hardware differences between ingress routers and transit or egress routers.

Figure 12-7 illustrates the flow of a packet through these router types. MPLS packets travel across an LSP and are assigned labels based on the configuration present in the LSR. In this case the packets travelling between Santiago and Rio are given a label value of 0. Label value 0 represents an explicit NULL label; therefore, this figure represents a network scenario that uses UHP.

Figure 12-7. LSP Router Types

graphics/12fig07.gif

An LSR possesses the following the major characteristics of MPLS forwarding:

  • No Layer 3 lookup by transit routers ”An LSR consults the traditional routing table only when functioning as an LSP ingress point or egress point. MPLS transit routers don't rely on the Layer 3 lookup algorithms for best-path/next-hop lookups.

  • Label swapping on transit routers ”Transit routers possess a table, known as mpls.0 , that maps an inbound interface and label to an outbound interface and label for each LSP. The LSR is capable of swapping labels and forwarding packets based on the contents of this table.

  • Coexistence of MPLS and Layer 3 technologies ”LSRs are normally capable of forwarding both traditional network layer packets and MPLS packets without interfering with the native routing algorithm.

Any given LSR must also be capable of performing several key functions for MPLS:

  • Ingress functionality

  • Transit functionality

  • Egress functionality

The ingress router, also known as the head-end router, marks the entry point of an LSP. The ingress router will take an incoming packet and look at the destination IP address. If an LSP exists to that address, it will assign the packet a label and forward it to the next LSR ”either a transit LSR or the egress point ”along the LSP. If an LSP to the destination address does not exist, then the router will use other routing table entries to resolve the next-hop.

When a transit router receives a packet with an MPLS label, it will then treat the packet as an MPLS packet, and no Layer 3 decisions will be applied. This router will compare the incoming interface and label of the packet to an MPLS table to determine the outbound interface and label. If this router is the penultimate router, then it will either tell the egress router what to do with the packet or pop the label and forward the unlabelled packet to the ultimate router (PHP).

The egress router will typically receive a label value of 0, unless PHP has been configured. In that case the egress router receives from the penultimate router an IP packet with no MPLS encapsulation. If, however, PHP has not been configured, and the egress router receives a packet with a label, it will pop the label and forward the packet based upon its original characteristics. There is a case where the label received by the egress router is different from those listed here. If this is the case, it is usually on a statically defined LSP, and specific configuration statements are included to tell the router to pop the label and forward accordingly .

12.3.2 Establishing an LSP

As was mentioned previously in Section 12.3.1.2, there are several ways of creating an LSP. These methods include LDP, RSVP, and CSPF and are explored in detail in the following sections.

12.3.2.1 LDP

LDP is used to create dynamic LSPs in an MPLS network. Defined in RFC 3037, LDP is typically used in nonexplicit and non-traffic-engineered scenarios. LDP typically establishes LSPs based upon the already running IGP's routes. In addition to typical hop-by-hop LSP establishment, LDP can tunnel through RSVP-created LSPs. This one of several methods used for construction of MPLS-based VPNs. More details on VPNs can be found in Chapter 13.

LDP operations are quite simple and based on a set of four different messages. The bibliography at the end of this chapter lists additional documentation to refer to for detailed explanations of LDP, as well as MPLS and RSVP.

LDP works on a peer-to-neighbor relationship. As with all LSPs, an LDP LSP can be a single hop from one router to another or across the entire network. The four message types outlined by RFC 3036 used in LDP are as follows :

  1. Discovery messages

  2. Session messages

  3. Advertisement messages

  4. Notification messages

These messages each play a specific role in the creation of LDP-based LSPs.

Discovery messages are used to create a neighbor or peer adjacency. LDP will send hello messages out an LDP-enabled interface. Hello messages are sent on UDP port 646. When a neighbor answers this hello message, an adjacency is formed. Further communication is then sent via a TCP session.

Session messages are used to maintain each LDP session with each LDP peer. Session messages are responsible for handling the following:

  • Peer establishment ”This session message is used for building a relationship with a neighboring LSR running LDP.

  • Peer adjacency ”This session message is used for maintaining a relationship with a neighboring LSR running LDP.

  • Peer termination ”This session message is used for ending a relationship with a neighboring LSR running LDP.

Advertisement messages are responsible for the following functions relating to the FEC table in each LSR:

  • Label creation ”This message is responsible for the assignment of labels to an LSP.

  • Label deletion ”This message is responsible for the removal of labels from an LSP, essentially tearing down the LSP.

  • Label modification ”This message is responsible for making changes to the labels assigned to an LSP.

When a label is created in the local system, it will send an advertisement message to the associated peer advising of the creation. If the IGP path for the LDP-based LSP goes away, then advertisement messages are used to delete the label associated for the path between the two peers.

Notification messages come in two forms:

  • Advisory notifications ”These are typically used when sending information about the LDP session.

  • Error notifications ”These are used when there is an adverse condition where the LDP session needs to be terminated . When this occurs each side of the peering will remove all labels associated with the session.

12.3.2.2 RSVP

RSVP was designed to signal bandwidth requirements on a per-flow basis. Juniper Networks has implemented an extended version of RSVP [RSVP with traffic-engineering extensions (RSVP-TE)]. RSVP within the JUNOS implementations is for use in support of MPLS LSPs. The Juniper Networks implementation of RSVP will continue to be referred to as RSVP in this text as this is how it is referenced in the JUNOS software. RSVP is used to reserve resources in a given path for either multicast or unicast traffic. It uses its own messaging system within the protocol to make these reservations . RSVP also allows a given path to be established (reserved) with specific QoS parameters.

Juniper Networks' implementation of traffic engineering takes advantage of the characteristics of RSVP and uses the protocol to establish dynamic LSPs. These LSPs can contain strict or loose hops in their definition.

RSVP uses a messaging system to create LSPs. The message types are as follows:

  • Path Message ” sent periodically towards the downstream router; used to allow the routers to learn previous-hop and next-hop for a given session

  • Resv Message ” sent from the downstream receiver of a flow towards the upstream originator; tells each router along the path to make the reservation for the flow

  • PathTear Message ” signals the routers to tear down the path created by the Resv Message; flows from the upstream router towards the downstream router

  • ResvTear Message ” signals each router in the flow to remove the reservation states that were set up by the Resv Message; flows form the downstream router towards the upstream router

  • PathErr Message ” sent when a problem along the path occurs; advisory only; do not affect the state of the path

  • ResvErr Message ” used primarily when a reservation request fails; if allowed to flow through, each router involved should receive this message

The JUNOS implementation of RSVP also contains extensions that provide traffic-engineering enhancements. These enhancements include the following:

  • Explicit route object (ERO) ”carries the strict and loose hop configuration elements; tells downstream routers how to set up the LSP to the destination based on these constraints

  • Label request object ”used to request a label on a segment from the downstream router

  • Label object ”passes the label value chosen by the downstream LSR in the Resv Message sent to the upstream LSR

  • Record route object ”used to track the sequence of IP addresses that the LSP crosses to reach the destination

  • Session attribute object ”carries the name of the LSP

There are many configurable attributes within the RSVP structure, including timers for path reservations and bandwidth settings per interface, session, and traffic flow. These are all configurable with the RSVP/MPLS configuration parameters. See Case Study 2 at the end of this chapter for a look at some of the options available when configuring RSVP.

12.3.2.3 CSPF

CSPF, or Constrained Shortest Path First, is used in JUNOS to compute LSPs with constraints. CSPF is used to add variables to the TED. These variables are then used in conjunction with the TED and the SPF algorithm to create the most efficient LSP for the network.

In CSPF, several attributes must be considered . These are classified in two distinct families: LSP attributes and link attributes. The LSP attributes consist of the following:

  • Bandwidth requirements for the LSP ”the minimum bandwidth requirement for each hop along the LSP

  • Hop limitations ”the maximum number of LSR hops permitted along the LSP

  • Administrative groups ”a method of specifying that an LSP only be created over links within a certain administratively defined group

  • Priority ”a configurable value that allows one LSP's creation to take precedence over the creation of other LSPs

  • Explicit route criteria ”the explicitly defined strict or loose hops that the LSP must cross on route to the destination

The link attributes consist of the following:

  • Reservable bandwidth ”calculated by taking the link bandwidth and subtracting the currently provisioned or reserved bandwidth

  • Administrative groups ”a method of grouping links by administratively defined characteristics, most commonly bandwidth

12.3.3 Prefix Mapping and Routing Table Integration

This section looks at two interrelated topics: prefix mapping and routing table integration. Prefix mapping refers to the ability to set up the equivalent of a static route to force packets destined for a prefix to use a specific, pre-established LSP. This feature is useful when establishing a connection to a distant network that is not advertised through BGP or IGP. With MPLS enabled, the local system is told to use a specific LSP to forward traffic to a given prefix. This can be beneficial when it becomes necessary to provide connectivity to a group of networks that may be open , but not reachable by the rest of the network resources.

Routing table integration describes the concept of relying on multiple tables when resolving the next-hop. Each of the different routing tables is populated by specific protocols. However, depending on the configuration of the LSR, it is possible to have information from one routing table carried over into other tables. Chapter 8 describes routing tables used within JUNOS. Each of these routing tables has a specific function. When referring to MPLS and traffic engineering, the following routing tables are relevant:

  • inet.0 ”the default unicast routing table where typical IGP routes are stored

  • inet.3 ”where entries created by RSVP are stored; maps a specific LSP to a destination address

  • mpls.0 ”where entries created by MPLS are stored; maps inbound interface and label combinations to outbound interface and label combinations

The following example shows the output of the show route table inet.3 command. Here there is a route to address 192.168.24.1 . This is because the RSVP LSP configuration points to the loopback address of the remote router.

 lab@Chicago> show route table inet.3  inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both  192.168.24.1/32  *[RSVP/7] 00:12:04, metric 30, metric2 0                     > to 10.0.15.1 via ge-3/0/0.0,  label-switched-path 1  

The next example shows the mpls.0 table from a router running RSVP. Notice the label number 251042 . This is the label used in the router for the LSP created by RSVP.

 lab@Chicago> show route table mpls.0  mpls.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0                  *[MPLS/0] 6d 05:43:22, metric 1                      Receive 1                  *[MPLS/0] 6d 05:43:22, metric 1                      Receive  251042  *[RSVP/7] 00:15:16, metric 1                     > to 10.0.13.2 via ge-1/1/1.0,  label-switched-path 1  

Recall from Chapter 9 that BGP will prefer routes in inet.3 over routes in inet.0 . The example below shows this. The show route protocol bgp command has been issued. The route for the 192.168.24.0 network is not the typical route that was there before. This route exists because it was chosen from the inet.3 table.

 lab@Chicago> show route protocol bgp  inet.0: 26 destinations, 26 routes (25 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both  192.168.24.0/24  *[BGP/170] 5d 23:02:50, MED 0, localpref 100, from 192.168.24.1                       AS path: I                     > to 10.0.15.1 via ge-3/0/0.0,  label-switched-path 1  

These commands are invaluable when troubleshooting MPLS- related issues. For more troubleshooting tactics, see Chapter 15. This section illustrated the contents of the routing tables that can be involved in MPLS traffic engineering. Further examples of routing table contents can be found in the case studies at the end of this chapter.

12.3.4 Traffic Protection

Traffic protection typically refers to a network's resiliency against outage . This section shows how Juniper Networks routers provide this capability in a traffic-engineered network.

In a typical IGP scenario, when a link goes down, the IGP will recalculate the best path to the destination address so long as it is still reachable. In MPLS, traffic protection occurs in a similar manner. Keepalive messages are periodically sent between LSRs by way of the signaling protocol (RSVP). When there is an outage, the LSR upstream of the outage uses RSVP to signal the ingress LSR that there is a failure. The ingress LSR then recalculates a new path to the destination and builds a new LSP. A potential problem is the time required to recalculate a new route for the LSP. RSVP relies on the native underlying network IGP; therefore, the underlying IGP must reconverge following link failure before the RSVP protocol is capable of starting the process of establishing a new LSP.

To combat this issue, JUNOS implements two key features: secondary paths and fast reroute . With secondary paths, JUNOS can define a secondary LSP to use in the event there is a failure of the primary LSP. Caution should be used when engineering the secondary path. For the sake of true redundancy and the elimination of single points of failure, it is best to create a secondary path that uses different routers and circuits than the primary.

Fast reroute is a method employed to patch a link failure prior to creating a new LSP. Figure 12-8 illustrates this. There are six routers involved in this network. Chicago is the ingress router, and London is the egress router. The active LSP from Chicago to London traverses through routers San Francisco and New York.

Figure 12-8. MPLS ”Traffic Protection Fast Reroute

graphics/12fig08.gif

Let's assume there is a failure of the link between San Francisco and New York. In Figure 12-8, San Francisco, having fast reroute enabled, would attempt to rebuild the LSP from its point of failure. In this case, San Francisco would signal the repaired portion of the path from San Francisco to Brussels to Amsterdam to New York. This gets the LSP up in the least amount of time.

In addition to this repairing of the LSP, San Francisco would then signal to Chicago to establish a new end-to-end LSP with London. In a scenario where maximum protection is necessary, it is possible to employ both standby secondary path and fast reroute. In this scenario the LSP failure due to link failure could immediately be repaired with fast reroute, while at the same time, the upstream router from the failure would signal the ingress router of the failure and request use of the secondary path. With both methods being deployed, the ingress router would switch to the pre-engineered secondary path.

When using standby secondary path or fast reroute, it is important to understand potential bottlenecks in the physical topology. If the physical infrastructure is not completely understood , then the potential exists to have configured and assumed operability of traffic protection without actually having the protection. Testing such scenarios is suggested to set a minimal level of expectation.

This section covered the operational theory behind the methods of establishing an LSP. This included the signaling protocols RSVP and LDP and the use of CSPF and the TED. This section also described routing table integration issues and the theory behind configuring secondary LSPs and fast rerouting as methods of protecting traffic. The following sections demonstrate how to build functional configurations that employ MPLS, RSVP, and LDP.



Juniper Networks Reference Guide. JUNOS Routing, Configuration, and Architecture
Juniper Networks Reference Guide: JUNOS Routing, Configuration, and Architecture: JUNOS Routing, Configuration, and Architecture
ISBN: 0201775921
EAN: 2147483647
Year: 2002
Pages: 176

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net