datatracker.ietf.org
Sign in
Version 5.4.0, 2014-04-22
Report a bug

Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels
RFC 3906

Document type: RFC - Informational (October 2004)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 3906 (Informational)
Responsible AD: Alex Zinin
Send notices to: fenner@research.att.com, zinin@psg.com

Network Working Group                                            N. Shen
Request for Comments: 3906                              Redback Networks
Category: Informational                                          H. Smit
                                                            October 2004

          Calculating Interior Gateway Protocol (IGP) Routes
                    Over Traffic Engineering Tunnels

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document describes how conventional hop-by-hop link-state
   routing protocols interact with new Traffic Engineering capabilities
   to create Interior Gateway Protocol (IGP) shortcuts.  In particular,
   this document describes how Dijkstra's Shortest Path First (SPF)
   algorithm can be adapted so that link-state IGPs will calculate IP
   routes to forward traffic over tunnels that are set up by Traffic
   Engineering.

1.  Introduction

   Link-state protocols like integrated Intermediate System to
   Intermediate System (IS-IS) [1] and OSPF [2] use Dijkstra's SPF
   algorithm to compute a shortest path tree to all nodes in the
   network.  Routing tables are derived from this shortest path tree.
   The routing tables contain tuples of destination and first-hop
   information.  If a router does normal hop-by-hop routing, the first-
   hop will be a physical interface attached to the router.  New traffic
   engineering algorithms calculate explicit routes to one or more nodes
   in the network.  At the router that originates explicit routes, such
   routes can be viewed as logical interfaces which supply Label
   Switched Paths through the network.  In the context of this document,
   we refer to these Label Switched Paths as Traffic Engineering tunnels
   (TE-tunnels).  Such capabilities are specified in [3] and [4].

   The existence of TE-tunnels in the network and how the traffic in the
   network is switched over those tunnels are orthogonal issues.  A node
   may define static routes pointing to the TE-tunnels, it may match the

Shen & Smit                  Informational                      [Page 1]
RFC 3906              IGP ShortCut Over MPLS LSPs           October 2004

   recursive route next-hop with the TE-tunnel end-point address, or it
   may define local policy such as affinity based tunnel selection for
   switching certain traffic.  This document describes a mechanism
   utilizing link-state IGPs to dynamically install IGP routes over
   those TE-tunnels.

   The tunnels under consideration are tunnels created explicitly by the
   node performing the calculation, and with an end-point address known
   to this node.  For use in algorithms such as the one described in
   this document, it does not matter whether the tunnel itself is
   strictly or loosely routed.  A simple constraint can ensure that the
   mechanism be loop free.  When a router chooses to inject a packet
   addressed to a destination D, the router may inject the packet into a
   tunnel where the end-point is closer (according to link-state IGP
   topology) to the destination D than is the injecting router.  In
   other words, the tail-end of the tunnel has to be a downstream IGP
   node for the destination D.  The algorithms that follow are one way
   that a router may obey this rule and dynamically make intelligent
   choices about when to use TE-tunnels for traffic.  This algorithm may
   be used in conjunction with other mechanisms such as statically
   defined routes over TE-tunnels or traffic flow and QoS based TE-
   tunnel selection.

   This IGP shortcut mechanism assumes the TE-tunnels have already been
   setup.  The TE-tunnels in the network may be used for QoS, bandwidth,
   redundancy, or fastreroute reasons.  When an IGP shortcut mechanism
   is applied on those tunnels, or other mechanisms are used in
   conjunction with an IGP shortcut, the physical traffic switching
   through those tunnels may not match the initial traffic engineering
   setup goal.  Also the traffic pattern in the network may change with
   time.  Some forwarding plane measurement and feedback into the
   adjustment of TE-tunnel attributes need to be there to ensure that
   the network is being traffic engineered efficiently [6].

2.  Enhancement to the Shortest Path First Computation

   During each step of the SPF computation, a router discovers the path
   to one node in the network.  If that node is directly connected to
   the calculating router, the first-hop information is derived from the
   adjacency database.  If a node is not directly connected to the
   calculating router, it inherits the first-hop information from the

[include full document text]