Specifications

Page 104 /148
3.3 MPLS for Traffic Engineering
Juniper’s architecture for traffic engineering is centered around MPLS. This is an
area where Juniper has been proactive through its work with the MPLS and
RSVP Working Groups of the IETF as well as with major carriers and ISPs.
Juniper’s MPLS support can be viewed as something close to a drop-in
replacement for many carriers current static ATM PVCs. Specifically, hop-by-hop
paths can be computed off-line based on inputs such as physical topology and a
traffic matrix. Once the paths are computed, the head ends of the MPLS Label-
Switched Paths (LSPs) can be configured with the exact hop-by-hop path for the
LSP. That head-end node will then initiate signaling with RSVP to establish the
label forwarding state in the Label-Switching Routers (LSRs).
§ In addition to supporting the explicit hop-by-hop configuration described
above, other types of configuration are supported. Some examples are:
§ Identifying the other end of the LSP, with IP shortest-path routing used to
find the hop-by-hop path
§ Specifying some number of intermediate nodes as loose hops
§ Specifying some number of intermediate nodes, mixing loose and strict hop
between each of those nodes
§ Specifying each hop in the path as a strict source route
In addition to the features discussed above, Juniper has extended the MPLS
system to allow the network itself to participate in the traffic engineering. The key
feature needed to extend MPLS in this way is bandwidth reservation. Assume
the nodes of the network had the ability to request bandwidth, respond to such
requests and advertise the state of the allocation of their bandwidth. In a network
with such features, establishment of LSPs could be done by negotiating with the
network itself and could take into account bandwidth on a given trunk already
committed to flows between a given set of ingress and egress points. The
advertisement of circuit bandwidths, as well as the amount of that bandwidth
already committed to flows, is added to IS-IS (or OSPF) with new Type-Length-
Value attributes. Note well that in this architecture, the bandwidth being reserved
corresponds to a flow between an ingress router and an egress router; this
architecture does not resemble the original RSVP assumption of a flow
corresponding to, for example, a TCP connection between two hosts.
JUNOS supports MPLS with RSVP signaling including both IS-IS and OSPF
traffic engineering extensions. There are four major components to the Juniper
Traffic Engineering implementation. (Note that MPLS and RSVP are open
standards within the IETF. Standards for IGP extensions are in process.)
§ The first component pertains to the distribution of traffic engineering related
link information collected from administrative input (e.g. available bandwidth,
administrative class, etc.). This information is distributed between routers in
an administrative routing domain via extensions to link state flooding
mechanisms of Interior Gateway Protocols such as IS-IS, and OSPF. The
information is stored in the Traffic Engineering Database within the router
and is separate from the main routing table (inet.0).
§ The MPLS protocol provides the traffic forwarding component, which is used
to direct traffic along a particular path in the network (I.e. label switching.)
§ There is also a component that uses information in the Traffic Engineering
Database, as well as other information provided by IGP link state packets, to
compute the appropriate path through the netw ork. This process of path
computation is done by a Constrained Shortest Path First (CSPF) algorithm,
which is similar to the SPF algorithm used in an IGP, but incorporates
constraints set forth in the configuration of LSPs.
§ Finally, RSVP is used as a signaling mechanism to establish the LSP.
RSVP messages are exchanged between all nodes along the path first to set
up the path and then to monitor the LSP for failures.
In JUNOS, LSPs can be configured statically or dynamically. Because it is labor
intensive, static configuration is recommended only for troubleshooting purposes.
Dynamic configuration is accomplished by enabling MPLS and establishing a tail
end IP address. If no other information is given, then the path is determined by
the SPF algorithm of the routing protocol (i.e. normal IP routing). However, traffic
engineering can be implemented by defining a required intermediate hop(s) to
direct traffic though explicit strict or loose source routes. Dynamic paths can be