Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 35

Introducing MPLS Traffic Engineering

Components
MPLS Traffic Engineering

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-1
Objectives
• Describe basic Traffic Engineering concepts
• Describe Traffic Engineering with a Layer 2 Overlay Model
• Describe a Layer 3 routing model without Traffic Engineering
• Describe Traffic Engineering with a layer 3 routing model
• Describe Traffic Engineering with the MPLS TE Model
• Describe basic concept of MPLS TE traffic tunnels
• Describe MPLS TE traffic tunnels attributes
• Describe the link resource attributes
• Describe Constraint-Based Path Computation
• Describe the MPLS TE process
• Describe the Role of RSVP in Path Setup Procedures
• Describe the Path Setup Procedures using RSVP
• Describe the three methods to forward traffic to a tunnel
• Describe the Autoroute feature
© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-2
What Is Traffic Engineering?
• Traffic engineering is manipulating your traffic to fit your network.
• Network engineering is building your network to carry your predicted
traffic.
• TE is a process of measures, models, and controls of traffic to achieve
various goals.
• TE for data networks provides an integrated approach to managing
traffic at Layer 3.

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-3
Traffic Engineering Motivations
• Reduce the overall cost of operations by more efficient use of bandwidth
resources .
• Prevent a situation where some parts of a network are overutilized
(congested), while other parts remain underutilized.
• Implement traffic protection against failures.
• Enhance SLA in combination with QoS.

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-4
Business Drivers for Traffic Engineering
• Routers forward traffic along the least-cost route that is discovered by
routing protocols.
• Network bandwidth may not be efficiently utilized:
- The least-cost route may not be the only possible route.
- The least-cost route may not have enough resources to carry all the traffic.
- Alternate paths may be underutilized.

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-5
Business Drivers for Traffic Engineering (Cont.)
• Lack of resources results in congestion in two ways:
- When network resources themselves are insufficient to accommodate the
offered load
- When traffic streams are inefficiently mapped onto available resources
• Some resources are overutilized while others remain underutilized.

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-6
Congestion Avoidance and Traffic Engineering
Network congestion can be addressed in two ways:
• Expansion of capacity or classical congestion control techniques
(queuing, rate limiting, and so on)
• Traffic engineering, if the problems result from inefficient resource
allocation

The focus of TE is not on congestion that is created as a result


of a short-term burst, but on congestion problems that are
prolonged.

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-7
Traffic Engineering with a Layer 2 Overlay Model
• The use of the explicit Layer 2 transit layer allows very exact control of
the way that traffic uses the available bandwidth.
• PVCs or SVCs carry traffic across Layer 2.
• Layer 3 at the edge sees a complete mesh.

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-8
Traffic Engineering with a Layer 2 Overlay Model:
Example

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-9
Traffic Engineering with a Layer 2 Overlay Model
(Cont.)
Drawbacks of the Layer 2 overlay solution
• Extra network devices
• More complex network management:
- Two-level network without integrated network management
- Additional training, technical support, field engineering
• IGP routing scalability issue for meshes
• Additional bandwidth overhead (“cell tax”)
• No differential service (class of service)

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-10
Layer 3 Model with No Traffic Engineering

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-11
Traffic Engineering with a Layer 3 Model
The “destination-based” forwarding paradigm is clearly
inadequate:
• Path computation that is based only on an IGP metric is not enough.
• Support for “explicit” routing (source routing) is not available.
• The supported alternatives are static routes and policy routing.
• It does provide controlled backup and recovery.

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-12
Traffic Engineering with the MPLS TE Model
• A tunnel is assigned labels that represent the path (LSP) through the
system.
• Forwarding within the MPLS network is based on the labels
(no Layer 3 lookup).

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-13
Traffic Engineering with the MPLS TE Model
(Cont.)
• The MPLS TE LSPs are created by RSVP.
• The actual path can be specified:
- Explicitly, as defined by the system administrator
- Dynamically, as defined using the underlying IGP protocol

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-14
Traffic Tunnels: Concepts
The concept of MPLS TE traffic tunnels was introduced to
overcome the limitations of hop-by-hop IP routing:
• A tunnel is an aggregation of traffic flows that are placed inside a
common MPLS label-switched path.
• Flows are then forwarded along a common path within a network.

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-15
Traffic Tunnels: Concepts (Cont.)
• The unidirectional single class of service model encapsulates all of the
traffic between an ingress and an egress router.
• The different classes of service model assigns traffic into separate
tunnels with different characteristics.

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-16
Traffic Tunnels: Characteristics
• A traffic tunnel is distinct from the MPLS LSP through which it traverses:
- More than one TE tunnel can be defined between two points:
• Each tunnel may pick the same or different paths through the network.
• Each tunnel will use different MPLS labels.
- A traffic tunnel can be moved from one path onto another, based on resources
in the network.
• A traffic tunnel is configured by defining its required attributes and
characteristics.

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-17
Traffic Tunnels: Attributes
• Attributes are explicitly assigned through administrative action.
• A traffic tunnel has several characteristics:
- Its ingress (headend) and egress (tail end) label switch routers
- The forwarding equivalence class that is mapped onto it
- A set of attributes that determine its characteristics
PE1 PE3

TT1

Headend Tail End

PE2 PE4

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-18
Traffic Tunnels: Attributes (Cont.)
The administrator enters the relevant information (attributes) at
the headend of the traffic tunnel:
• Traffic parameter: Resources required for tunnel (for example, required
bandwidth)
• Generic path selection and management: Path can be
administratively specified or computed by the IGP
• Resource class affinity: Can include or exclude certain links for certain
traffic tunnels
• Adaptability: Traffic tunnel to be reoptimized?
• Priority and preemption: Importance of a traffic tunnel and possibility
for a preemption of another tunnel
• Resilience: Desired behavior under fault conditions

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-19
Network Links and Link Attributes
Resource attributes (link availability) are configured locally on
the router interfaces:
• Maximum bandwidth
- The amount of bandwidth available
• Link affinity string
- Allows the operator to administratively include or exclude links in path
calculations
• Constraint-based specific metric
- The TE default metric

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-20
Constraint-Based Path Computation
• Constraint-based routing is demand-driven.
• Resource-reservation-aware routing paradigm:
- Based on criteria including, but not limited to, network topology
- Calculated at the edge of a network:
• Modified Dijkstra algorithm at tunnel headend (CSPF [constraint-based
SPF] or PCALC [path calculation])
• Output is a sequence of IP interface addresses (next-hop routers) between
tunnel endpoints

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-21
Constraint-Based Path Computation (Cont.)
• Constraint-based routing takes into account these three elements :
- Policy constraints associated with the tunnel and physical links
- Physical resource availability
- Network topology state
• Two types of tunnels can be established across those links with
matching attributes:
- Dynamic—Using the least-cost path computed by OSPF or IS-IS
- Explicit—Using a path that is defined with Cisco IOS configuration commands

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-22
Constraint-Based Path Computation (Cont.)

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-23
Constraint-Based Path Computation (Cont.)

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-24
Traffic Engineering Processes
• Information distribution
• Path selection and calculation
• Path setup
• Tunnel admission control
• Forwarding of traffic on to tunnel
• Path maintenance

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-25
Role of RSVP in Path Setup Procedures
• When the path has been determined, a signaling protocol is needed:
- To establish and maintain label-switched paths (LSPs) for traffic tunnels
- For creating and maintaining resource reservation states across a network
(bandwidth allocation)
• Resource Reservation Protocol (RSVP) was adopted by the MPLS
workgroup of the IETF.

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-26
Path Setup with RSVP
• When the path has been calculated, it must be signaled across the
network.
- Reserve any bandwidth to avoid “double booking” from other TE reservations.
- Priority can be used to preempt low priority existing tunnels.
• RSVP is used to set up TE LSP.
- PATH message (from head to tail) carries LABEL_REQUEST.
- RESV message (from tail to head) carries LABEL.
• When the RESV message reaches the headend, the tunnel interface is
up.
• RSVP messages exist for LSP teardown and error signaling.

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-27
RSVP and Tunnel Admission Control
• On receipt of PATH message:
- Router checks whether there is bandwidth available to honor the reservation.
- If bandwidth is available, then RSVP is accepted.
• On receipt of a RESV message:
- Router actually reserves the bandwidth for the TE LSP.
- If preemption is required, lower priority LSPs are torn down.
• OSPF or IS-IS updates are triggered.

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-28
Forwarding Traffic to a Tunnel
• IP routing is separate from LSP routing and does not see internal details
of the LSP.
• The traffic must be mapped to the tunnel:
- Static routing: The static route in the IP routing table points to an LSP tunnel
interface.
- Policy routing: The next-hop interface is an LSP tunnel.
- Autoroute: SPF enhancement
• The headend sees the tunnel as a directly connected interface (for modified
SPF only).
• The default cost of a tunnel is equal to the shortest IGP metric, regardless
of the path used.

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-29
IP Forwarding Database Modification with
Autoroute
• The autoroute feature enables the headend to see the LSP as a directly
connected interface:
- This feature is used only for the SPF route determination, not for the
constraint-based path computation.
- All traffic that is directed to prefixes topologically behind the tunnel endpoint
(tail end) is forwarded onto the tunnel.
• Autoroute affects the headend only; other routers on the LSP path do
not see the tunnel.
• The tunnel is treated as a directly connected link to the tail end.

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-30
Autoroute Topology (OSPF and IS-IS)

Tunnel 1: R1-R2-R3-R4-R5
Tunnel 2: R1-R6-R7-R4

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-31
Autoroute Topology (OSPF and IS-IS) (Cont.)

From the perspective of R1:


Next hop to R5 is Tunnel 1.
Next hop to R4 and R8 is Tunnel 2.
All nodes behind the tunnel are routed via the tunnel.

© 2012 Cisco and/or its affiliates. All rights reserved.


32
SPCORE v1.01—2-32
Summary
• Traffic engineering is manipulating your traffic to fit your network.
• In TE with a Layer 2 overlay model, PVCs are carefully engineered
across the network, normally using an offline management system.
• If TE is not used in a Layer 3 model, some links may be overutilized and
other may be underutilized.
• The destination-based forwarding that is currently used in Layer 3
networks cannot resolve the problem of overutilization of one path while
an alternate path is underutilized.
• The aim of MPLS TE is to control the path of traffic flow using MPLS
labels and LSP.
• A traffic tunnel is a collection of data flows that share some common
attribute.
• A traffic tunnel must include attributes that define the commonality
between the data flows making up the tunnel.

© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-33
Summary (Cont.)
• A headend router must be provided with network link attributes in order to
calculate a path through a network.
• Constraint-Based Path Computation finds a path for a traffic flow as the
shortest path that meets the resource requirements (constraints) of the
traffic flow.
• Tunnel admission control manages the situation when a router along a
computed path has insufficient bandwidth to honor the resource that is
requested in the RSVP PATH message.
• RSVP is used to confirm and reserve the path and apply the labels that
identify the tunnel.
• The RSVP PATH message carries the explicit route (the output of the path
selection process) computed for this traffic tunnel, consisting of a
sequence of label switching routers.
• The IP routing process does not see the traffic tunnel, so the traffic tunnel
is generally not included in any SPF calculations.
• The autoroute feature enables the headend router to see the MPLS TE
tunnel as a directly connected interface.
© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-34
© 2012 Cisco and/or its affiliates. All rights reserved. SPCORE v1.01—2-35

You might also like