draft-ietf-rtgwg-igp-shortcut-01.txt   rfc3906.txt 
Network Working Group Naiming Shen Network Working Group N. Shen
INTERNET DRAFT Redback Networks Request for Comments: 3906 Redback Networks
Category: Informational Henk Smit Category: Informational H. Smit
Expiration Date: November 2004 October 2004
May 2004
Calculating IGP Routes Over Traffic Engineering Tunnels
draft-ietf-rtgwg-igp-shortcut-01.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with Calculating Interior Gateway Protocol (IGP) Routes
all provisions of Section 10 of RFC2026. Over Traffic Engineering Tunnels
Internet-Drafts are working documents of the Internet Engineering Status of this Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This memo provides information for the Internet community. It does
and may be updated, replaced, or obsoleted by other documents at any not specify an Internet standard of any kind. Distribution of this
time. It is inappropriate to use Internet-Drafts as reference memo is unlimited.
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2004).
http://www.ietf.org/shadow.html.
2. Abstract Abstract
This document describes how conventional hop-by-hop link-state This document describes how conventional hop-by-hop link-state
routing protocols interact with new Traffic Engineering capabilities routing protocols interact with new Traffic Engineering capabilities
to create IGP shortcuts. In particular this document describes how to create Interior Gateway Protocol (IGP) shortcuts. In particular,
Dijkstra's SPF algorithm can be adapted so that link-state IGPs this document describes how Dijkstra's Shortest Path First (SPF)
will calculate IP routes to forward traffic over tunnels that are algorithm can be adapted so that link-state IGPs will calculate IP
set up by Traffic Engineering. routes to forward traffic over tunnels that are set up by Traffic
Engineering.
3. Introduction 1. Introduction
Link-state protocols like integrated IS-IS [1] and OSPF [2] use Link-state protocols like integrated Intermediate System to
Dijkstra's SPF algorithm to compute a shortest path tree to all nodes Intermediate System (IS-IS) [1] and OSPF [2] use Dijkstra's SPF
in the network. Routing tables are derived from this shortest path algorithm to compute a shortest path tree to all nodes in the
tree. The routing tables contain tuples of destination and first-hop 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- information. If a router does normal hop-by-hop routing, the first-
hop will be a physical interface attached to the router. hop will be a physical interface attached to the router. New traffic
New traffic engineering algorithms calculate explicit routes to one engineering algorithms calculate explicit routes to one or more nodes
or more nodes in the network. At the router that originates explicit in the network. At the router that originates explicit routes, such
routes, such routes can be viewed as logical interfaces which supply routes can be viewed as logical interfaces which supply Label
Label Switched Paths through the network. In the context of this Switched Paths through the network. In the context of this document,
document we refer to these Label Switched Paths as Traffic we refer to these Label Switched Paths as Traffic Engineering tunnels
Engineering tunnels (TE-tunnels). Such capabilities are specified (TE-tunnels). Such capabilities are specified in [3] and [4].
in [3] and [4].
The existence of TE-tunnels in the network and how the traffic The existence of TE-tunnels in the network and how the traffic in the
in the network is switched over those tunnels are orthogonal network is switched over those tunnels are orthogonal issues. A node
issues. A node may define static routes pointing to the TE-tunnels; may define static routes pointing to the TE-tunnels, it may match the
it may match the recursive route next-hop with the TE-tunnel recursive route next-hop with the TE-tunnel end-point address, or it
end-point address; or it may define local policy such as affinity may define local policy such as affinity based tunnel selection for
based tunnel selection for switching certain traffic. This document switching certain traffic. This document describes a mechanism
describes a mechanism utilizing link-state IGPs to dynamically utilizing link-state IGPs to dynamically install IGP routes over
install IGP routes over those TE-tunnels. those TE-tunnels.
The tunnels under consideration are tunnels created explicitly by The tunnels under consideration are tunnels created explicitly by the
the node performing the calculation, and with an end-point address node performing the calculation, and with an end-point address known
known to this node. For use in algorithms such as the one described to this node. For use in algorithms such as the one described in
in this document, it does not matter whether the tunnel itself is this document, it does not matter whether the tunnel itself is
strictly or loosely routed. A simple constraint can ensure that the strictly or loosely routed. A simple constraint can ensure that the
mechanism being loop free. When a router chooses to inject a packet mechanism be loop free. When a router chooses to inject a packet
addressed to a destination D, the router may inject the packet into addressed to a destination D, the router may inject the packet into a
a tunnel where the end-point is closer, according to link-state tunnel where the end-point is closer (according to link-state IGP
IGP topology, to the destination D than the injecting router is. topology) to the destination D than is the injecting router. In
In other words, the tail-end of the tunnel has to be a downstream other words, the tail-end of the tunnel has to be a downstream IGP
IGP node for the destination D. The algorithms that follow are one node for the destination D. The algorithms that follow are one way
way that a router may obey this rule and dynamically make that a router may obey this rule and dynamically make intelligent
intelligent choices about when to use TE-tunnels for traffic. choices about when to use TE-tunnels for traffic. This algorithm may
This algorithm may be used in conjunction with other mechanisms be used in conjunction with other mechanisms such as statically
such as statically defined routes over TE-tunnels or traffic flow defined routes over TE-tunnels or traffic flow and QoS based TE-
and QoS based TE-tunnel selection. tunnel selection.
This IGP shortcut mechanism assumes the TE-tunnels have already This IGP shortcut mechanism assumes the TE-tunnels have already been
been setup. The TE-tunnels in the network may be used for setup. The TE-tunnels in the network may be used for QoS, bandwidth,
QoS, bandwidth, redundancy or fastreroute reasons. When IGP redundancy, or fastreroute reasons. When an IGP shortcut mechanism
shortcut mechanism is applied on those tunnels, or other is applied on those tunnels, or other mechanisms are used in
mechanisms are used in conjunction with IGP shortcut, the conjunction with an IGP shortcut, the physical traffic switching
physical traffic switching through those tunnels may not through those tunnels may not match the initial traffic engineering
match the initial traffic engineering setup goal. Also the setup goal. Also the traffic pattern in the network may change with
traffic pattern in network may change with time. Some forwarding time. Some forwarding plane measurement and feedback into the
plane measurement and feedback into the adjustment of TE-tunnel adjustment of TE-tunnel attributes need to be there to ensure that
attributes need to be there to ensure the network being the network is being traffic engineered efficiently [6].
traffic engineered efficiently [6].
4. Enhancement to the Shortest Path First computation 2. Enhancement to the Shortest Path First Computation
During each step of the SPF computation, a router discovers the path 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 to one node in the network. If that node is directly connected to
calculating router, the first-hop information is derived from the the calculating router, the first-hop information is derived from the
adjacency database. If a node is not directly connected to the adjacency database. If a node is not directly connected to the
calculating router, it inherits the first-hop information from the calculating router, it inherits the first-hop information from the
parent(s) of that node. Each node has one or more parents. Each node parent(s) of that node. Each node has one or more parents. Each
is the parent of zero or more down-stream nodes. node is the parent of zero or more down-stream nodes.
For traffic engineering purposes each router maintains a list of all For traffic engineering purposes, each router maintains a list of all
TE-tunnels that originate at this router. For each of those TE- TE-tunnels that originate at this router. For each of those TE-
tunnel, the router at the tail-end is known. tunnels, the router at the tail-end is known.
During SPF, when a router finds the path to a new node (in other During SPF, when a router finds the path to a new node (in other
words, this new node is moved from the TENTative list to the PATHS words, this new node is moved from the TENTative list to the PATHS
list), the router must determine the first-hop information. There list), the router must determine the first-hop information. There
are three possible ways to do this: are three possible ways to do this:
- Examine the list of tail-end routers directly reachable via a - Examine the list of tail-end routers directly reachable via a
TE-tunnel. If there is a TE-tunnel to this node, we use the TE-tunnel. If there is a TE-tunnel to this node, we use the
TE-tunnel as the first-hop. TE-tunnel as the first-hop.
- If there is no TE-tunnel, and the node is directly connected, we - If there is no TE-tunnel, and the node is directly connected,
will use the first-hop information from the adjacency database. we use the first-hop information from the adjacency database.
- If the node is not directly connected, and is not directly - If the node is not directly connected, and is not directly
reachable via a TE-tunnel, we will copy the first-hop reachable via a TE-tunnel, we copy the first-hop information
information from the parent node(s) to the new node. from the parent node(s) to the new node.
The result of this algorithm is that traffic to nodes that are the The result of this algorithm is that traffic to nodes that are the
tail-end of TE-tunnels, will flow over those TE-tunnels. Traffic to tail-end of TE-tunnels, will flow over those TE-tunnels. Traffic to
nodes that are downstream of the tail-end nodes will also flow over nodes that are downstream of the tail-end nodes will also flow over
those TE-tunnels. If there are multiple TE-tunnels to different those TE-tunnels. If there are multiple TE-tunnels to different
intermediate nodes on the path to destination node X, traffic will intermediate nodes on the path to destination node X, traffic will
flow over the TE-tunnel whose tail-end node is closest to node X. flow over the TE-tunnel whose tail-end node is closest to node X. In
In certain applications, there is a need to carry both the native certain applications, there is a need to carry both the native
adjacency and the TE-tunnel next-hop information for the TE-tunnel adjacency and the TE-tunnel next-hop information for the TE-tunnel
tail-end and its downstream nodes. The head-end node may tail-end and its downstream nodes. The head-end node may
conditionally switch the data traffic onto TE-tunnels based on conditionally switch the data traffic onto TE-tunnels based on user
user defined criteria or events; The head-end node may also split defined criteria or events; the head-end node may also split flow of
flow of traffic towards either types of the next-hops; The head-end traffic towards either types of the next-hops; the head-end node may
node may install the routes with two different types of next-hops install the routes with two different types of next-hops into two
into two separate RIBs. Multicast protocols running over physical separate RIBs. Multicast protocols running over physical links may
links may have to perform RPF checks using the native adjacency have to perform RPF checks using the native adjacency next-hops
next-hops rather than the TE-tunnel next-hops. rather than the TE-tunnel next-hops.
5. Special cases and exceptions 3. Special Cases and Exceptions
The Shortest Path First algorithm will find equal-cost parallel paths The Shortest Path First algorithm will find equal-cost parallel paths
to destinations. The enhancement described in this document does not to destinations. The enhancement described in this document does not
change this. Traffic can be forwarded over one or more native IP change this. Traffic can be forwarded over one or more native IP
paths, over one or more TE-tunnels, or over a combination of native paths, over one or more TE-tunnels, or over a combination of native
IP paths and TE-tunnels. IP paths and TE-tunnels.
A special situation occurs in the following topology: A special situation occurs in the following topology:
rtrA -- rtrB -- rtrC rtrA -- rtrB -- rtrC
skipping to change at page 4, line 10 skipping to change at page 4, line 4
to destinations. The enhancement described in this document does not to destinations. The enhancement described in this document does not
change this. Traffic can be forwarded over one or more native IP change this. Traffic can be forwarded over one or more native IP
paths, over one or more TE-tunnels, or over a combination of native paths, over one or more TE-tunnels, or over a combination of native
IP paths and TE-tunnels. IP paths and TE-tunnels.
A special situation occurs in the following topology: A special situation occurs in the following topology:
rtrA -- rtrB -- rtrC rtrA -- rtrB -- rtrC
| | | |
rtrD -- rtrE rtrD -- rtrE
Assume all links have the same cost. Assume a TE-tunnel is set up Assume all links have the same cost. Assume a TE-tunnel is set up
from rtrA to rtrD. When the SPF calculation puts rtrC on the from rtrA to rtrD. When the SPF calculation puts rtrC on the
TENTative list, it will realize that rtrC is not directly connected, TENTative list, it will realize that rtrC is not directly connected,
and thus it will use the first-hop information from the parent. Which and thus it will use the first-hop information from the parent, which
is rtrB. When the SPF calculation on rtrA moves rtrD from the is rtrB. When the SPF calculation on rtrA moves rtrD from the
TENTative list to the PATHS list, it realizes that rtrD is the TENTative list to the PATHS list, it realizes that rtrD is the tail-
tail-end of a TE-tunnel. Thus rtrA will install a route to rtrD via end of a TE-tunnel. Thus rtrA will install a route to rtrD via the
the TE-tunnel, and not via rtrB. TE-tunnel, and not via rtrB.
When rtrA puts rtrE on the TENTative list, it realizes that rtrE is When rtrA puts rtrE on the TENTative list, it realizes that rtrE is
not directly connected, and that rtrE is not the tail-end of a TE- not directly connected, and that rtrE is not the tail-end of a TE-
tunnel. Therefor rtrA will copy the first-hop information from the tunnel. Therefore, rtrA will copy the first-hop information from the
parents (rtrC and rtrD) to the first-hop information of rtrE. parents (rtrC and rtrD) to the first-hop information of rtrE.
Traffic to rtrE will now load-balance over the native IP path via Traffic to rtrE will now load-balance over the native IP path via
rtrA->rtrB->rtrC, and the TE-tunnel rtrA->rtrD. rtrA->rtrB->rtrC, and the TE-tunnel rtrA->rtrD.
In the case where both parallel native IP paths and paths over TE- In the case where both parallel native IP paths and paths over TE-
tunnels are available, implementations can allow the network tunnels are available, implementations can allow the network
administrator to force traffic to flow over only TE-tunnels (or only administrator to force traffic to flow over only TE-tunnels (or only
over native IP paths) or both to be used for load sharing. over native IP paths) or both to be used for load sharing.
6. Metric adjustment of IP routes over TE-tunnels 4. Metric Adjustment of IP Routes over TE-tunnels
When an IGP route is installed in the routing table with a TE-tunnel When an IGP route is installed in the routing table with a TE-tunnel
as next hop, an interesting question is what should be the cost or as the next hop, an interesting question is what should be the cost
metric of this route ? The most obvious answer is to assign a metric or metric of this route? The most obvious answer is to assign a
that is the same as the IGP metric of the native IP path as if the metric that is the same as the IGP metric of the native IP path as if
TE-tunnels did not exist. For example, rtrA can reach rtrC over a the TE-tunnels did not exist. For example, rtrA can reach rtrC over
path with a cost of 20. X is an IP prefix advertised by rtrC. We a path with a cost of 20. X is an IP prefix advertised by rtrC. We
install the route to X in rtrA's routing table with a cost of 20. install the route to X in rtrA's routing table with a cost of 20.
When a TE-tunnel from rtrA to rtrC comes up, by default the route is When a TE-tunnel from rtrA to rtrC comes up, by default the route is
still installed with metric of 20, only the next-hop information for still installed with metric of 20, only the next-hop information for
X is changed. X is changed.
While this scheme works well, in some networks it might be useful to While this scheme works well, in some networks it might be useful to
change the cost of the path over a TE-tunnel, to make the route over change the cost of the path over a TE-tunnel, to make the route over
the TE-tunnel less or more preferred than other routes. the TE-tunnel less or more preferred than other routes.
For instance when equal cost paths exist over a TE-tunnel and over a For instance, when equal cost paths exist over a TE-tunnel and over a
native IP path, by adjusting the cost of the path over the TE-tunnel, native IP path, by adjusting the cost of the path over the TE-tunnel,
we can force traffic to prefer the path via the TE-tunnel, to prefer we can force traffic to prefer the path via the TE-tunnel, to prefer
the native IP path, or to load-balance among them. Another example is the native IP path, or to load-balance among them. Another example
when multiple TE-tunnels go to the same or different destinations. is when multiple TE-tunnels go to the same or different destinations.
Adjusting TE-tunnel metrics can force the traffic to prefer some Adjusting TE-tunnel metrics can force the traffic to prefer some TE-
TE-tunnels over others regardless of underlining IGP cost to those tunnels over others regardless of underlining IGP cost to those
destinations. destinations.
Setting a manual metric on a TE-tunnel does not impact the SPF Setting a manual metric on a TE-tunnel does not impact the SPF
algorithm itself. It only affects comparison of the new route with algorithm itself. It only affects the comparison of the new route
existing routes in the routing table. Existing routes can be either with existing routes in the routing table. Existing routes can be
IP routes to another router that advertises the same IP prefix, or it either IP routes to another router that advertises the same IP
can be a path to the same router, but via a different outgoing prefix, or it can be a path to the same router, but via a different
interface or different TE-tunnel. All routes to IP prefixes outgoing interface or different TE-tunnel. All routes to IP prefixes
advertised by the tail-end router will be affected by the TE-tunnel advertised by the tail-end router will be affected by the TE-tunnel
metric. Also the metrics of paths to routers that are downstream of metric. Also, the metrics of paths to routers that are downstream of
the tail-end router will be influenced by the manual TE-tunnel the tail-end router will be influenced by the manual TE-tunnel
metric. metric.
This mechanism is loop free since the TE-tunnels are source-routed This mechanism is loop free since the TE-tunnels are source-routed
and the tunnel egress is a downstream node to reach the computed and the tunnel egress is a downstream node to reach the computed
destinations. The end result of TE-tunnel metric adjustment is destinations. The end result of TE-tunnel metric adjustment is more
more control over traffic loadsharing. If there is only one way control over traffic loadsharing. If there is only one way to reach
to reach a particular IP prefix through a single TE-tunnel, then no a particular IP prefix through a single TE-tunnel, then no matter
matter what metric is assigned, the traffic has only one path to go. what metric is assigned, the traffic has only one path to go.
The routing table described in this section can be viewed as the The routing table described in this section can be viewed as the
private RIB for the IGP. The metric is an important attribute to private RIB for the IGP. The metric is an important attribute to the
the routes in the routing table. A path or paths with lower metric routes in the routing table. A path or paths with lower metric will
will be selected over other paths for the same route in the be selected over other paths for the same route in the routing table.
routing table.
6.1. Absolute and relative metrics 4.1. Absolute and Relative Metrics
It is possible to represent the TE-tunnel metric in two different It is possible to represent the TE-tunnel metric in two different
ways: an absolute (or fixed) metric or a relative metric, which is ways: an absolute (or fixed) metric or a relative metric, which is
merely an adjustment of the dynamic IGP metric as calculate by the merely an adjustment of the dynamic IGP metric as calculated by the
SPF computation. When using an absolute metric on a TE-tunnel, the SPF computation. When using an absolute metric on a TE-tunnel, the
cost of the IP routes in the routing table does not depend on the cost of the IP routes in the routing table does not depend on the
topology of the network. Note that this fixed metric is not only used topology of the network. Note that this fixed metric is not only
to compute the cost of IP routes advertised by the router that is the used to compute the cost of IP routes advertised by the router that
tail-end of the TE-tunnel, but also for all the routes that are is the tail-end of the TE-tunnel, but also for all the routes that
downstream of this tail-end router. For example, if we have TE- are downstream of this tail-end router. For example, if we have TE-
tunnels to two core routers in a remote POP, and one of them is tunnels to two core routers in a remote POP, and one of them is
assigned with absolute metric of 1, then all the traffic going to assigned with an absolute metric of 1, then all the traffic going to
that POP will traverse this low-metric TE-tunnel. that POP will traverse this low-metric TE-tunnel.
By setting a relative metric, the cost of IP routes in the routing By setting a relative metric, the cost of IP routes in the routing
table is based on the IGP metric as calculated by the SPF table is based on the IGP metric as calculated by the SPF
computation. This relative metric can be a positive or a negative computation. This relative metric can be a positive or a negative
number. Not configuring a metric on a TE-tunnel is a special case of number. Not configuring a metric on a TE-tunnel is a special case of
the relative metric scheme. No metric is the same as a relative the relative metric scheme. No metric is the same as a relative
metric of 0. The relative metric is bounded by minimum and maximum metric of 0. The relative metric is bounded by minimum and maximum
allowed metric values while the positive metric disables the allowed metric values while the positive metric disables the TE-
TE-tunnel in the SPF calculation. tunnel in the SPF calculation.
6.2. Examples of metric adjustment 4.2. Examples of Metric Adjustment
Assume the following topology. X, Y and Z are IP prefixes advertised Assume the following topology. X, Y, and Z are IP prefixes
by rtrC, rtrD and rtrE respectively. T1 is a TE-tunnel from rtrA to advertised by rtrC, rtrD, and rtrE respectively. T1 is a TE-tunnel
rtrC. Each link in the network has an IGP metric of 10. from rtrA to rtrC. Each link in the network has an IGP metric of 10.
===== T1 =====> ===== T1 =====>
rtrA -- rtrB -- rtrC -- rtrD -- rtrE rtrA -- rtrB -- rtrC -- rtrD -- rtrE
10 10 | 10 | 10 | 10 10 | 10 | 10 |
X Y Z X Y Z
Without TE-tunnel T1, rtrA will install IP routes X, Y and Z in the Without TE-tunnel T1, rtrA will install IP routes X, Y, and Z in the
routing table with metrics 20, 30 and 40 respectively. When rtrA has routing table with metrics 20, 30, and 40 respectively. When rtrA
brought up TE-tunnel T1 to rtrC, and if rtrA is configured with the has brought up TE-tunnel T1 to rtrC, and if rtrA is configured with
relative metric of -5 on tunnel T1, then the routes X, Y, and Z will the relative metric of -5 on tunnel T1, then the routes X, Y, and Z
be installed in the routing table with metrics 15, 25, and 35. If an will be installed in the routing table with metrics 15, 25, and 35.
absolute metric of 5 is configured on tunnel T1, then rtrA will If an absolute metric of 5 is configured on tunnel T1, then rtrA will
install routes X, Y and Z all with metrics 5, 15 and 25 respectively. install routes X, Y, and Z all with metrics 5, 15, and 25
respectively.
7. Security Considerations 5. Security Considerations
This document does not change the security aspects of IS-IS or OSPF. This document does not change the security aspects of IS-IS or OSPF.
Security considerations specific to each protocol still apply. For Security considerations specific to each protocol still apply. For
more information see [5] and [2]. more information see [5] and [2].
8. Acknowledgments 6. Acknowledgments
The authors would like to thank Joel Halpern and Christian Hopps for The authors would like to thank Joel Halpern and Christian Hopps for
their comments to this document. their comments on this document.
9. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
10. References 7. Informative References
[1] ISO. Information Technology - Telecommunications and [1] ISO. Information Technology - Telecommunications and Information
Information Exchange between Systems - Intermediate System Exchange between Systems - Intermediate System to Intermediate
to Intermediate System Routing Exchange Protocol for System Routing Exchange Protocol for Use in Conjunction with the
Use in Conjunction with the Protocol for Providing the Protocol for Providing the Connectionless-Mode Network Service.
Connectionless-Mode Network Service. ISO, 1990. ISO, 1990.
[2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[3] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, [3] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
"Requirements for Traffic Engineering Over MPLS", RFC 2702, McManus, "Requirements for Traffic Engineering Over MPLS", RFC
September 1999. 2702, September 1999.
[4] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP [4] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G.
tunnels", RFC 3209, December 2001. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209,
December 2001.
[5] T. Li, R. Atkinson, "Intermediate System to Intermediate System [5] Li, T. and R. Atkinson, "Intermediate System to Intermediate
(IS-IS) Cryptographic Authentication", RFC 3567, July 2003. System (IS-IS) Cryptographic Authentication", RFC 3567, July
2003.
[6] D. Awduche, A. Chiu, A. Elwalid, I. Widjaja, X. Xiao, [6] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao,
"Overview and Principles of Internet Traffic Engineering," "Overview and Principles of Internet Traffic Engineering", RFC
RFC-3272, May 2002. 3272, May 2002.
11. Authors' Addresses 8. Authors' Addresses
Naiming Shen Naiming Shen
Redback Networks, Inc. Redback Networks, Inc.
300 Holger Way 300 Holger Way
San Jose, CA 95134 San Jose, CA 95134
Email: naiming@redback.com
EMail: naiming@redback.com
Henk Smit Henk Smit
Email: hhwsmit@xs4all.nl
EMail: hhwsmit@xs4all.nl
9. Full Copyright Statement
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/