MPLS


In the traditional Layer 3 forwarding paradigm, as a packet travels from one router to the next , an independent forwarding decision is made at each hop. In an MPLS environment, the analysis of the packet header is performed just once, when a packet enters the MPLS cloud. The packet then is assigned to a stream, which is identified by a label , which is a short (20-bit), fixed-length value at the front of the packet. Labels are used as lookup indexes into the label forwarding table. For each label, this table stores forwarding information.

Traffic engineering allows you to control the path that data packets follow, bypassing the standard routing model, which uses routing tables. Traffic engineering moves flows from congested links to alternate links that would not be selected by the automatically computed destination-based shortest path. With traffic engineering, you can do the following:

  • Make more efficient use of expensive long-haul fibers.

  • Control how traffic is rerouted in the face of single or multiple failures.

  • Classify critical and regular traffic on a per-path basis.

The core of the traffic engineering design is based on building LSPs among routers. An LSP is connection-oriented, like a virtual circuit in Frame Relay or ATM. LSPs are not reliable: Packets entering an LSP do not have delivery guarantees , although preferential treatment is possible. LSPs also are similar to unidirectional tunnels in that packets entering a path are encapsulated in an envelope and switched across the entire path without being touched by intermediate nodes.

Table 11.1 lists the MPLS standards and protocol extensions supported by the JUNOS software.

Table 11.1. MPLS Standards and Protocol Extensions Supported by JUNOS Software
Standard Title
RFC 3031 Multiprotocol Label Switching Architecture
RFC 3032 MPLS Label Stack Encoding
RFC 2702 Requirements for Traffic Engineering over MPLS
IETF draft draft-ietf-isis-traffic-02.txt IS-IS Extensions for Traffic Engineering
IETF draft-katz-yeung-ospf-traffic-04.txt Traffic Engineering Extensions to OSPF
IETF draft-ietf-mpls-icmp-02.txt ICMP Extensions for Multiprotocol Label Switching
RFC 3031 Multiprotocol Label Switching Architecture

The JUNOS software supports a proprietary MIB for MPLS objects; see the JUNOS technical documentation: Network Management and MPLS.

MPLS supports the following link-layer protocols, which are all supported in the JUNOS MPLS implementation:

  • PPP ”Protocol ID 0x0281, NCP protocol ID 0x8281.

  • Ethernet/Cisco HDLC ”Ethernet type 0x8847.

  • ATM ”SNAP-encoded Ethernet type 0x8847. Support is included for both point-to-point mode or NBMA mode. Support is not included for encoding MPLS labels as part of ATM VPI/VCI.

  • Frame Relay ”SNAP-encoded, Ethernet type 0x8847. Support is not included for encoding MPLS labels as part of Frame Relay DLCI.

  • GRE Tunnel ”Ethernet type 0x8847.

Types of LSPs

There are three types of LSPs:

  • Static LSPs ”For static paths, you must manually assign labels on all routers involved (ingress, transit, and egress). No signaling protocol is needed. This procedure is similar to configuring static routes on individual routers. Like static routes, there is no error reporting, no liveliness detection, and no statistics reporting.

  • LDP-signaled LSPs.

  • RSVP-signaled LSPs ”For signaled paths, RSVP is used to set up the path and dynamically assign labels. (RSVP signaling messages are used to set up signaled paths.) You configure only the ingress router. The transit and egress routers accept signaling information from the ingress router, and they set up and maintain the LSP cooperatively. Any errors encountered while establishing an LSP are reported to the ingress router for diagnostics. For signaled LSPs to work, a version of RSVP that supports tunnel extensions must be enabled on all routers. There are two types of RSVP-signaled LSPs:

    • Explicit-path LSPs ”All intermediate hops of the LSP are manually configured. The intermediate hops can be strict, loose, or any combination of the two. Explicit path LSPs provide you with complete control over how the path is set up. They are similar to static LSPs but require much less configuration.

    • Constrained-path LSPs ”The intermediate hops of the LSP are automatically computed by the software. The computation takes into account information provided by the topology information from the IS-IS or OSPF link-state routing protocol, the current network resource utilization determined by RSVP, and the resource requirements and constraints of the LSP. For signaled constrained-path LSPs to work, either the IS-IS or OSPF protocol and the IS-IS or OSPF traffic engineering extensions must be enabled on all routers.

For constrained-path LSPs, the LSP computation is confined to one IGP area and cannot cross any AS boundary. This prevents an AS from extending its IGP into another AS. Explicit-path LSPs, however, can cross as many AS boundaries as necessary. Because intermediate hops are manually specified, the LSP has no dependency on the IGP topology or a local forwarding table.

Flexible LSP Calculation and Configuration

The JUNOS software supports a number of different ways to route and configure an LSP:

  • You can calculate the full path for the LSP offline and individually configure each router in the LSP with the necessary static forwarding state. This is analogous to how some ISPs currently configure their IP-over-ATM core networks.

  • You can calculate the full path for the LSP offline and statically configure the ingress router with the full path. The ingress router then uses RSVP as a dynamic signaling protocol to install a forwarding state in each router along the LSP.

  • You can rely on constraint-based routing to perform dynamic online LSP calculation. You configure the constraints for each LSP, and then the network itself determines the path that best meets those constraints. Specifically, the ingress router calculates the entire LSP based on the constraints and then initiates signaling across the network.

  • You can calculate a partial path for an LSP offline and statically configure the ingress router with a subset of the routers in the path and then permit online calculation to determine the complete path.

  • You can configure the ingress router with no constraints whatsoever. In this case, normal IGP shortest-path routing is used to determine the path of the LSP. This configuration does not provide any value in terms of traffic engineering. However, it is easy and might be useful in situations when services such as Virtual Private Networks (VPNs) are needed.

In all these cases, you can specify any number of LSPs as backups for the primary LSP, thus allowing you to combine more than one configuration approach.

MPLS provides a mechanism for engineering network traffic patterns that is independent of routing tables. MPLS assigns short labels to network packets that describe how to forward them through the network. MPLS is independent of any routing protocol and can be used for unicast packets.

Labels

Packets traveling along an LSP are identified by a label, a 20-bit, unsigned integer in the range 0 through 1,048,575. The labels are assigned as follows :

  • 0 through 15 ”Reserved and have special semantics.

  • 16 through 1,023 and 10,000 through 99,999 ”Unused and unassigned by the software, a feature that is specific to the JUNOS software. You can use labels to manually configure static LSPs and to ensure that there are no conflicts with labels that are dynamically assigned by the software.

  • 1,024 through 9,999 ”Reserved for future applications.

  • 100,000 through 1,048,575 ”Automatically negotiated, assigned, released, and reused by the software. Typically, per-router labels are assigned in the 100,000-799,999 range, and per-interface labels are assigned in the 800,000-1,048,575 range.

Some of the reserved labels in the 0 through 15 range have well-defined meanings:

For more details, see RFC 3032, MPLS Label Stack Encoding .

  • 0, IPv4 Explicit Null Label ”This value is valid only when it is the sole label entry (no label stacking). It indicates that the label must be popped on receipt. Forwarding continues based on the IPv4 packet.

  • 1, Router Alert Label ”When a packet is received with a top label value of 1, it is delivered to the local software module for processing.

  • 2, IPv6 Explicit Null Label ”This value is valid only when it is the sole label entry (no label stacking). It indicates that the label must be popped on receipt. Forwarding continues based on the IPv6 packet.

  • 3, Implicit Null Label ”This label is used in the control protocol (LDP, RSVP) only to request label popping by the downstream router. It never actually appears in the encapsulation. Labels with a value of 3 should not be used in the data packet as real labels. No payload type (IPv4 or IPv6) is implied with this label.

Special labels are commonly used between the egress and penultimate routers of an LSP. If the LSP is configured to carry IPv4 packets only, the egress router might signal the penultimate router to use 0 as a final hop label. If the LSP is configured to carry IPv6 packets only, the egress router might signal the penultimate router to use 2 as a final hop label.

Label values are allocated per router only. The display output shows only the label (for example, 01024 ).

Labels for multicast packets are independent of those for unicast packets. Currently, the JUNOS software does not support multicast labels.

Labels are assigned by downstream routers relative to the flow of packets. A router receiving labeled packets (the next-hop router) is responsible for assigning incoming labels. A received packet containing a label that is unrecognized (unassigned) is dropped. For unrecognized labels, the router does not attempt to unwrap the label to analyze the network layer header, nor does it generate an ICMP destination unreachable message.

A packet can carry a number of labels, organized as a last-in, first-out stack. This is referred to as a label stack. At a particular router, the decision as to how to forward a labeled packet is based exclusively on the label at the top of the stack.

Figure 11.1 shows the encoding of a single label. The encoding appears after data link layer headers, but before any network layer header.

Figure 11.1. Label Encoding

graphics/11fig01.gif

The router supports the following label operations:

  • Push ”Add a new label to the top of the packet. For IPv4 packets, the new label is the first label. The TTL, S, and CoS fields are derived from the IP packet header. If a push operation is performed on an existing MPLS packet, the packet has two or more labels. This is called label stacking. The top label must have its S field set to 0 and might derive CoS and TTL from lower levels. The new top label in a label stack always initializes its TTL to 255, regardless of the TTL value of lower labels.

  • Pop ”Remove the label from the beginning of the packet. When the label is removed, the TTL is copied from the label into the IP packet header, and the underlying IP packet is forwarded as a native IP packet. In the case of multiple labels in a packet (label stacking), removing the top label yields another MPLS packet. The new top label might derive CoS and TTL from a previous top label. The popped TTL value from the previous top label is not written back to the new top label.

  • Swap ”Replaces the label at the top of the label stack with a new label. The S and CoS bits are copied from the previous label, and the TTL value is copied and decremented (unless the no-decrement-ttl or no-propagate-ttl statements are configured). A transit router supports a label stack of any depth.

  • Multiple push ”Add multiple labels (up to three) on top of existing packets. This is equivalent to doing a push operation multiple times.

  • Swap and push ”Replace the existing top of the label stack with a new label, followed by pushing another new label on top.

Routers in an LSP

Each router in an LSP performs one of the following functions:

  • Ingress router ”At the beginning of an LSP, this router encapsulates IP packets with an MPLS Layer 2 frame and forwards it to the next router in the path. Each LSP can have only one ingress router.

  • Egress router ”At the end of an LSP, this router removes the MPLS encapsulation, thus transforming it from an MPLS packet to an IP packet, and forwards the packet to its final destination using information in the IP forwarding table. Each LSP can have only one egress router. The ingress and egress routers in an LSP cannot be the same router.

  • Transit router ”Any intermediate router in the LSP between the ingress and egress routers. A transit router forwards received MPLS packets to the next router in the MPLS path. An LSP can contain zero or more transit routers, up to a maximum of 253 transit routers in a single LSP.

A single router can be part of multiple LSPs. It can be the ingress or egress router for one or more LSPs, and it also can be a transit router in one or more LSPs. The functions that each router supports depend on your network design.

How a Packet Travels along an LSP

When an IP packet enters an LSP, the ingress router examines the packet and assigns it a label based on its destination, placing the label in the packet's header. The label transforms the packet from one that is forwarded based on its IP routing information to one that is forwarded based on information associated with the label.

The packet then is forwarded to the next router in the LSP. This router and all subsequent routers in the LSP do not examine any of the IP routing information in the labeled packet. Rather, they use the label to look up information in their label forwarding table. Then, they replace the old label with a new label and forward the packet to the next router in the path.

When the packet reaches the egress router, the label is removed, and the packet again becomes a native IP packet and is again forwarded based on its IP routing information.

Constrained-Path LSP Computation

The Constrained Shortest-Path First (CSPF) algorithm is an advanced form of the Shortest-Path First (SPF) algorithm used in OSPF and IS-IS route computations . CSPF is used in computing paths for LSPs that are subject to multiple constraints. When computing paths, CSPF considers not only the topology of the network, but also the attributes of the LSP and the links, and it attempts to minimize congestion by intelligently balancing the network load.

The constraints that CSPF considers include the following:

  • LSP attributes

    • Bandwidth requirements

    • Hop limitations

    • Administrative groups (that is, link color requirements)

    • Priority (setup and hold)

    • Explicit route (strict or loose)

  • Link attributes

    • Reservable bandwidth of the links (static bandwidth minus the currently reserved bandwidth)

    • Administrative groups (that is, link colors assigned to the link)

The data that CSPF considers comes from the following:

  • Traffic Engineering Database (TED) ”Provides CSPF with up-to-date topology information, the current reservable bandwidth of links, and the link colors. For the CSPF algorithm to perform its computations, a link-state IGP (such as OSPF or IS-IS) with special extensions is needed. For CSPF to be effective, the link-state IGP on all routers must support the special extensions. While building the topology database, the extended IGP must take into consideration the current LSPs and must flood the route information everywhere. Because changes in the reserved link bandwidth and link color cause database updates, an extended IGP tends to flood more frequently than a normal IGP. See Figure 11.2 for a diagram of the relationships between these components .

    Figure 11.2. CSPF Computation Process

    graphics/11fig02.gif

  • Currently active LSPs ”Includes all the LSPs that should originate from the router and their current operational status (up, down, or timeout).

Fate Sharing

Fate sharing allows you to create a database of information that CSPF uses to compute one or more backup paths to use in case the primary path becomes unstable. The database describes the relationships between elements of the network, such as routers and links. You can specify one or more elements within a group .

For more information about fate sharing, see the JUNOS technical documentation: Routing and Routing Protocols.

Through fate sharing, you can configure backup paths that minimize the number of shared links and fiber paths with the primary paths as much as possible, to ensure that, if a fiber is cut, the minimum amount of data is lost and that a path still exists to the destination.

For a backup path to work optimally, it must not share links or physical fiber paths with the primary path. This ensures that a single point of failure will not affect the primary and backup paths at the same time.

IGP Shortcuts

Link-state protocols, such as OSPF and IS-IS, use the SPF algorithm to compute the shortest-path tree to all nodes in the network. The results of such computations can be represented by the destination node, next-hop address, and output interface, where the output interface is a physical interface. LSPs can be used to augment the SPF algorithm. On the node performing the calculations, LSPs appear to be logical interfaces directly connected to remote nodes in the network. If you configure the IGP to treat LSPs the same as a physical interface and to use the LSPs as a potential output interface, the SPF computation results are represented by the destination node and output LSP, effectively using the LSP as a shortcut through the network to the destination.

As an illustration, begin with a typical SPF tree as shown in Figure 11.3. If an LSP connects Router A to Router D and if IGP shortcuts are enabled on Router A, you might have the SPF tree shown in Figure 11.4.

Figure 11.3. Typical SPF Tree, Sourced from Router A

graphics/11fig03.gif

Figure 11.4. Modified SPF Tree, Using LSP A “D as a Shortcut

graphics/11fig04.gif

Router D is now reachable through LSP A “D. When computing the shortest path to reach Router D, Router A has two choices:

  • Use IGP path A “B “D

  • Use LSP A “D

To decide between the two choices, Router A compares the IGP metrics for path A “B “D with the LSP metrics for LSP A “D. If the IGP metric is lower, path A “B “D is chosen (see Figure 11.3). If the LSP metric is lower, LSP A “D is used (see Figure 11.4). If both metrics are equal, Router A might share the load between the two paths.

Routers E and F are also reachable through LSP A “D because they are downstream from Router D in the SPF tree.

Assuming that another LSP connects Router A to Router E, you might have the SPF tree shown in Figure 11.5.

Figure 11.5. Modified SPF Tree, Using Both LSP A “D and LSP A “E as Shortcuts

graphics/11fig05.gif

For information about enabling IGP shortcuts for IS-IS and OSPF, see Chapter 9, "Routing and Routing Protocols," on page 373.

IGP shortcuts are supported for both IS-IS and OSPF. A link-state protocol is required for IGP shortcuts. Shortcuts are disabled by default. You can enable IGP shortcuts on a per-router basis; you do not need to enable shortcuts globally. A router's shortcut computation does not depend on another router performing similar computations, and shortcuts performed by other routers are irrelevant.

Advertising LSPs into IGPs

IGP shortcuts allow an ingress router of an LSP to use the LSP in its SPF computation. However, other routers on the network do not know of the existence of that LSP, so they cannot use it. This can lead to less than optimal traffic engineering. As an example, consider the network shown in Figure 11.6.

Figure 11.6. SPF Computations with Advertised LSPs

graphics/11fig06.gif

Assume that Router A is computing a path to Router D. The link between Router E and Router F has metric 20; all other links have metric 10. Here, the path chosen by Router A is A “B “C “D, which has a metric of 30, instead of A “E “F “D, which has a metric of 40.

If Router E has an LSP to Router D with a metric of 15, you want traffic from Router A to Router D to use the path A “E “D, which has a metric of 25, instead of the path A “B “C “D. However, because Router A does not know about the LSP between Router E and Router D, it cannot route traffic through this path.

For all routers on the network to know about the LSP between Router E and Router D, you need to advertise it. This advertisement an-nounces the LSP as a unidirectional, point-to-point link in the link-state database, and all routers can compute paths using the LSP. The link-state database maintains information about the AS topology and contains information about the router's local state (for example, the router's usable interfaces and reachable neighbors). In Figure 11.6, Router A sees the link from Router E to Router D and routes traffic along this lower-metric path.

Because an LSP is announced as a unidirectional link, you might need to configure a reverse LSP (one that starts at the egress router and ends at the ingress router) so that the SPF bidirectional check succeeds. As a step in the SPF computation, IS-IS considers a link from Router E to Router D. Before IS-IS uses any link, it verifies that there is a link from Router D to Router E (there is bidirectional connectivity between router E and D). Otherwise, the SPF computation does not use an announced LSP.

IP and MPLS Packets on Aggregated Interfaces

You can send IP and MPLS packets over aggregated interfaces. To the IP or MPLS session, there is a single LSP composed of the aggregated interfaces. Packets sent to an LSP that is part of an aggregated interface are redistributed over the aggregated member interfaces.

To configure aggregated Ethernet and aggregated SONET interfaces, see Chapter 6, "Interfaces and Class of Service," on page 185.

Sending IP and MPLS packets over aggregated interfaces has the following benefits:

  • Bandwidth aggregation ”You can increase the number of MPLS packet flows sent over each connection. In MPLS, a set of packets sharing the same label is considered a part of the same flow.

  • Link redundancy ”If a link or a line card failure affects an aggregate member link, the traffic flowing across that link is immediately forwarded across one of the remaining links.

MPLS Applications for Traffic Engineering

In the JUNOS implementation of MPLS, establishing an LSP installs on the ingress router a host route (a 32-bit mask) toward the egress router. The address of the host route is the destination address of the LSP. By default, the route has a preference value of 7, a value that is higher than all routes except direct interface and static routes. The 32-bit mask ensures that the route is more specific (that is, a longer match) than all other subnet routes. The host routes can be used to traffic-engineer BGP destinations only, or both IGP and BGP destinations.

You can configure MPLS to control the paths that traffic takes to destinations outside an AS. Both IBGP and EBGP take advantage of the LSP host routes without requiring extra configuration. BGP compares the BGP next-hop address with the LSP host route. If a match is found, the packets for the BGP route are label-switched over the LSP. If multiple BGP routes share the same next-hop address, all the BGP routes are mapped to the same LSP route, regardless of which BGP peer the routes are learned from. If the BGP next-hop address does not match an LSP host route, BGP routes continue to be forwarded based on the IGP routes within the routing domain. In general, when both an LSP route and an IGP route exist for the same BGP next-hop address, the one with the highest preference is chosen.

Figure 11.7 shows an MPLS topology that illustrates how MPLS and LSPs work. This topology consists of a single domain with four routers. The two routers at the edges of the domain, Router 1 and Router 4, are running EBGP to communicate with peers outside the domain and IBGP to communicate between themselves . For intradomain communication, all four routers are running an IGP. Finally, an LSP tunnel exists from Router 1 to Router 4.

Figure 11.7. MPLS Application Topology

graphics/11fig07.gif

When BGP on Router 1 receives prefixes from Router 4, it must determine how to reach a BGP next-hop address. Typically, when traffic engineering is not enabled, BGP uses IGP routes to determine how to reach next-hop addresses. (See the left side of Figure 11.8.) However, when traffic engineering is enabled, if the BGP next hop matches the LSP tunnel end point (that is, the MPLS egress router), those prefixes enter the LSP tunnel. If the BGP next hop does not match an LSP tunnel end point, those prefixes are sent following the IGP's shortest path (see Figure 11.8).

Figure 11.8. How BGP Determines How to Reach Next-Hop Addresses

graphics/11fig08.gif

You can configure MPLS to control the paths that traffic takes to destinations within an AS. When traffic engineering is for IGP destinations only, the MPLS host routes are installed in the inet.3 routing table (see Figure 11.9 on page 541), separate from the routes learned from other routing protocols. Not all inet.3 routes are downloaded into the forwarding table. Packets directly addressed to the egress router do not follow the LSP, which prevents routes learned from LSPs from overriding routes learned from IGPs or other sources.

Figure 11.9. MPLS Routing and Forwarding Tables When Traffic-Engineering BGP Is Configured

graphics/11fig09.gif

Traffic within a domain, including BGP control traffic between BGP peers, is not affected by LSPs. MPLS affects interdomain transit traf-fic only; that is, it affects only those BGP prefixes that are learned from an external domain. MPLS does not disrupt intradomain traffic, so IS-IS or OSPF routes remain undisturbed. If you issue a ping or traceroute command to any destination within the domain, the ping or traceroute packets follow the IGP path. However, if you issue a ping or traceroute command from Router 1 in Figure 11.8 (the LSP ingress router) to a destination outside the domain, the packets use the LSP tunnel.

When traffic engineering for IGP and BGP destinations is enabled, the MPLS host routes are installed in the inet.0 table (see Figure 11.9) and downloaded into the forwarding table. Any traffic destined to the egress router could enter the LSP. In effect, it moves all the routes in inet.3 into inet.0 , thus emptying the inet.3 table.

RSVP packets automatically avoid all MPLS LSPs, including those established by RSVP or LDP. This prevents placing one RSVP session into another LSP, or in other words, nesting one LSP into another.

If more than one LSP tunnel to a BGP next hop exists, the prefixes learned from the BGP next hop are randomly divided among the LSP tunnels. To control which LSP BGP uses to forward data for a given prefix, use the install-nexthop statement in the export policy applied to the forwarding table.

MPLS and Routing Tables

The IGPs and BGP store their routing information in the inet.0 routing table, which is the primary IP routing table. If traffic-engineering bgp is configured, thereby allowing only BGP to use MPLS paths for forwarding traffic, MPLS path information is stored in a separate routing table, inet.3 . Only BGP accesses the inet.3 routing table. BGP uses both inet.0 and inet.3 to resolve next-hop addresses. If traffic-engineering bgp-igp is configured, thereby allowing the IGPs to use MPLS paths for forwarding traffic, MPLS path information is stored in the inet.0 routing table. (Figure 11.9 and Figure 11.10 illustrate the routing tables in the two traffic engineering configurations.)

Figure 11.10. MPLS Routing and Forwarding Tables When Traffic-Engineering BGP-IGP Is Configured

graphics/11fig10.gif

The inet.3 routing table contains the host address of each LSP's egress router. This routing table is used on ingress routers to route packets to the destination egress router. BGP uses the inet.3 routing table on the ingress router to help in resolving next-hop addresses.

MPLS also maintains an MPLS path routing table ( mpls.0 ), which contains a list of the next label-switched router in each LSP. This routing table is used on transit routers to route packets to the next router along an LSP.

Typically, the egress router in an LSP does not consult the mpls.0 routing table. (This router does not need to consult mpls.0 because the penultimate router in the LSP either changes the packet's label to a value of 0 or pops the label.) In either case, the egress router forwards it as an IPv4 packet, consulting the IP routing table, inet.0 , to determine how to forward the packet.

When a transit or egress router receives an MPLS packet, information in the MPLS forwarding table is used to determine the next transit router in the LSP or to determine that this router is the egress router.

When BGP resolves a next-hop prefix, it examines both the inet.0 and inet.3 routing tables, seeking the next hop with the highest preference. If it finds a next-hop entry with an equal preference in both routing tables, BGP prefers the entry in the inet.3 routing table.

Generally, BGP selects next-hop entries in the inet.3 routing table, because their preferences are always lower than OSPF and IS-IS next-hop preferences. When you configure LSPs, you can override the default preference for MPLS LSPs, which might alter the next-hop selection process.

When BGP selects a next-hop entry from the inet.3 routing table, it installs that LSP into the forwarding table in the Packet Forwarding Engine, which causes packets destined for that next hop to enter and travel along the LSP. If the LSP is removed or fails, the path is removed from the inet.3 routing table and from the forwarding table, and BGP reverts to using a next hop from the inet.0 routing table.

MPLS and Traffic Protection

Typically, when an LSP fails, the router immediately upstream from the failure signals the outage to the ingress router. The ingress router calculates a new path to the egress router, establishes the new LSP, and then directs the traffic from the failed path to the new path. This rerouting process can be time consuming and prone to failure. For example, the outage signals to the ingress router might get lost, or the new path might take too long to come up, resulting in significant packet drops . The JUNOS software provides two complementary mechanisms for protecting against LSP failures:

  • Standby secondary paths ”You can configure primary and secondary paths. You configure secondary paths with the standby statement. To activate traffic protection, you need to configure these standby paths only on the ingress router. If the primary path fails, the ingress router immediately reroutes traffic from the failed path to the standby path, thereby eliminating the need to calculate a new route and signal a new path.

  • Fast reroute ”You configure fast reroute on an LSP to minimize the effect of a failure in the LSP. Fast reroute enables a router upstream from the failure to route around the failure quickly to the router downstream of the failure. The upstream router then signals the outage to the ingress router, thereby maintaining connectivity before a new LSP is established.

When standby secondary path and fast reroute are both configured on the LSP, full traffic protection is enabled. When a failure occurs in an LSP, the router upstream of the failure routes traffic around the failure and notifies the ingress router of the failure. This rerouting keeps the traffic flowing while waiting for the notification to be processed at the ingress router. After receiving the failure notification, the ingress router immediately reroutes the traffic from the patched primary path to the more optimal standby path.

Per-Prefix Load Balancing

When there are multiple equal cost tunnels to a destination, load balancing can be controlled for each path. Load balancing is proportional to the configured bandwidth per LSP. If an LSP has a larger bandwidth associated with it, that LSP carries a larger number of prefixes. If you configure the bandwidth, the prefixes automatically adjust themselves.

Automatic Bandwidth Allocation

An MPLS tunnel can automatically adjust its bandwidth allocation based on the volume of traffic flowing through the tunnel. You can configure an LSP with minimal bandwidth, and the LSP's bandwidth allocation is dynamically adjusted based on current traffic patterns. The bandwidth adjustments do not interrupt traffic flow through the tunnel.

You set a sampling interval on an LSP configured with automatic bandwidth allocation. The average bandwidth, is monitored during this interval. At the end of the interval, an attempt is made to signal a new path for the LSP with the bandwidth allocation set to the maximum average value for the preceding sampling interval. If the new path is successfully established and the original path is removed, the LSP is switched over to the new path. If a new path is not created, the LSP continues to use its current path until the end of the next sampling interval, when another attempt is made to establish a new path. You can set both the minimum and maximum bandwidth values for the LSP.



Juniper Networks Field Guide and Reference
Juniper Networks Field Guide and Reference
ISBN: 0321122445
EAN: 2147483647
Year: 2002
Pages: 185

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