draft-ietf-mpls-te-feed-00.txt   draft-ietf-mpls-te-feed-01.txt 
MPLS Working Group Peter Ashwood-Smith MPLS Working Group Peter Ashwood-Smith
Internet Draft Bilel Jamoussi Internet Draft Bilel Jamoussi
Expiration Date: September 2000 Don Fedyk Expiration Date: December 2000 Don Fedyk
Darek Skalecki Darek Skalecki
Nortel Networks Nortel Networks
February 2000 July 2000
IMPROVING TOPOLOGY DATA BASE ACCURACY WITH LSP FEEDBACK VIA CR-LDP Improving Topology Data Base Accuracy with LSP Feedback
draft-ietf-mpls-te-feed-00.txt draft-ietf-mpls-te-feed-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at line 44 skipping to change at page 1, line 45
Abstract Abstract
One key component of traffic engineering is a concept known as One key component of traffic engineering is a concept known as
constraint based routing. In constraint based routing a topology constraint based routing. In constraint based routing a topology
database is maintained on all participating nodes. This database database is maintained on all participating nodes. This database
contains a complete list of all the links in the network that contains a complete list of all the links in the network that
participate in traffic engineering and for each of these links a set participate in traffic engineering and for each of these links a set
of constraints which those links can meet. Bandwidth, for example, of constraints which those links can meet. Bandwidth, for example,
is one essential constraint. Since the bandwidth available changes is one essential constraint. Since the bandwidth available changes
Ashwood-Smith, et. al. [Page 1] Internet Draft LSP Feedback with CR-LDP January, 2000
as new LSPs are established and terminated the topology database as new LSPs are established and terminated the topology database
will develop inconsistencies with respect to the real network. It is will develop inconsistencies with respect to the real network. It is
not possible to increase the flooding rates arbitrarily to keep the not possible to increase the flooding rates arbitrarily to keep the
database discrepancies from growing. We propose a new mechanism database discrepancies from growing. We propose a new mechanism
whereby a source node can learn about the successes or failures of whereby a source node can learn about the successes or failures of
its path selections by receiving feedback from the paths it is its path selections by receiving feedback from the paths it is
attempting. This fed-back information can be incorporated into attempting. This fed-back information can be incorporated into
subsequent route computations, which greatly improves the accuracy subsequent route computations, which greatly improves the accuracy
of the overall routing solution by significantly reducing the of the overall routing solution by significantly reducing the
database discrepancies. database discrepancies.
skipping to change at line 98 skipping to change at page 2, line 47
The basic proposal is to add to the signaling protocol the ability The basic proposal is to add to the signaling protocol the ability
to piggyback actual link bandwidth availability information at every to piggyback actual link bandwidth availability information at every
link that the signaling traverses. This is done as part of the link that the signaling traverses. This is done as part of the
reverse messaging on success or failure (mapping, release, withdraw reverse messaging on success or failure (mapping, release, withdraw
or notification). What this means is that every time signaling or notification). What this means is that every time signaling
messages flow backwards toward a source to tell it of the success, messages flow backwards toward a source to tell it of the success,
failure or termination of a request, that message contains a failure or termination of a request, that message contains a
detailed slice of bandwidth availability information for the exact detailed slice of bandwidth availability information for the exact
path that the message has followed. This slice of reservation path that the message has followed. This slice of reservation
information, which is very up to date, is received by the source information, which is very up to date, is received by the source
node and attached to the source node's topology database prior to
Ashwood-Smith, et. al. January 2000 [Page 2] Internet Draft LSP Feedback with CR-LDP January, 2000
node and inserted into the source node's topology database prior to
making any further source route computations. The result is that the making any further source route computations. The result is that the
source node's topology database will tend to stay synchronized with source node's topology database will tend to stay synchronized with
the slices of the network through which it is establishing paths. the slices of the network through which it is establishing paths.
This is nothing more than learning from successes and failures and This is nothing more than learning from successes and failures and
represents an intelligent alternative to either waiting for floods represents an intelligent alternative to either waiting for floods
or introducing non-determinism (guessing) into the source or introducing non-determinism (guessing) into the source
algorithms. algorithms. It is important to note that the fed-back data is never
re-flooded. It simply overrides flooded information for the purpose
of route computation until a superceding flood or fed-back value
arrives. As such, it is not actually inserted into a topology
database, most likely it simply is linked to that database as an
override used only by source route computations.
Operating a constraint based routing system without such feedback is Operating a constraint based routing system without such feedback is
inefficient at best since a source node will continue to give out inefficient at best since a source node will continue to give out
incorrect route over and over again until it gets an IGP update. incorrect route over and over again until it gets an IGP update.
This could be minutes away and as a result the worst case blocking This could be minutes away and as a result the worst case blocking
time for a new route is the minimum repeatable flooding interval time for a new route is the minimum repeatable flooding interval
(often several minutes in big networks). Alternatives to feedback (often several minutes in big networks). Alternatives to feedback
mechanisms involve adding some non-determinism (randomness) to the mechanisms involve adding some non-determinism (randomness) to the
routing algorithm in the hopes that it will stumble onto a path that routing algorithm in the hopes that it will stumble onto a path that
works. These sorts of approaches are seen in ATM dynamic routing works. These sorts of approaches are seen in ATM dynamic routing
skipping to change at line 143 skipping to change at page 3, line 43
bandwidth. Therefore, the path is only established up to the link bandwidth. Therefore, the path is only established up to the link
that does not have sufficient bandwidth. A notification message is that does not have sufficient bandwidth. A notification message is
formatted that contains the actual unreserved bandwidth for this formatted that contains the actual unreserved bandwidth for this
blocking link which flows back toward the source, collapsing the blocking link which flows back toward the source, collapsing the
partially created path as it goes. In addition, at every link that partially created path as it goes. In addition, at every link that
this notification traverses, the current unreserved bandwidth this notification traverses, the current unreserved bandwidth
information for each corresponding link is appended to the vector of information for each corresponding link is appended to the vector of
unreserved bandwidth along the path. In this manner, an accurate unreserved bandwidth along the path. In this manner, an accurate
view of the slice through the network we are traversing is view of the slice through the network we are traversing is
constructed. Eventually this message arrives back at the source constructed. Eventually this message arrives back at the source
node, where the vector is taken and inserted into the topology node, where the vector is taken and used to temporarily override the
database. This node has just learned from its mistake and is now topology database for route computations. This node has just learned
slightly less optimistic with respect to the real network from its mistake and is now slightly less optimistic with respect to
conditions. the real network conditions.
Path selection can be attempted again but this time the node will Path selection can be attempted again but this time the node will
not make the same mistake it made the previous time. The link in not make the same mistake it made the previous time. The link in
question, at which rejection occurred the first time, will not even question, at which rejection occurred the first time, will not even
be eligible this time around, so a source route computation is be eligible this time around, so a source route computation is
guaranteed to produce a different path (or none). The same procedure guaranteed to produce a different path (or none). The same procedure
Ashwood-Smith, et. al. January 2000 [Page 3] Internet Draft LSP Feedback with CR-LDP January, 2000
may be repeated as many times as is necessary, each time learning may be repeated as many times as is necessary, each time learning
from its mistakes, until eventually no paths remain in the source from its mistakes, until eventually no paths remain in the source
topology to the destination, or we actually find a path that works. topology to the destination, or we actually find a path that works.
This tendency to converge either to a solution or determine that This tendency to converge either to a solution or determine that
there is no solution is an important property of a routing system there is no solution is an important property of a routing system
(it actually behaves a lot like a depth first search). This property (it actually behaves a lot like a depth first search). This property
is not present with flooding mechanisms alone since the source node is not present with flooding mechanisms alone since the source node
must randomly hunt, or continually make the same mistakes, or abort must randomly hunt, or continually make the same mistakes, or abort
until the next flood arrives. until the next flood arrives.
In addition to feeding back bandwidth on failure, we also recommend In addition to feeding back bandwidth on failure, we also recommend
feedback on success. This has important consequences on our ability feedback on success. This has important consequences on our ability
to spread load or to spill over to new links as existing links fill. to spread load or to spill over to new links as existing links fill.
skipping to change at line 174 skipping to change at page 4, line 20
until the next flood arrives. until the next flood arrives.
In addition to feeding back bandwidth on failure, we also recommend In addition to feeding back bandwidth on failure, we also recommend
feedback on success. This has important consequences on our ability feedback on success. This has important consequences on our ability
to spread load or to spill over to new links as existing links fill. to spread load or to spill over to new links as existing links fill.
It is true that spilling over to new links does not require feedback It is true that spilling over to new links does not require feedback
on success since we could simply wait for a feedback on failure, but on success since we could simply wait for a feedback on failure, but
we can achieve better load spreading earlier. we can achieve better load spreading earlier.
Finally, when a path is torn down the release/withdraw messages also Finally, when a path is torn down the release/withdraw messages also
contain bandwidth information that can be fed back into the source contain bandwidth information that can be fed back to override the
topology database. This is very important during failure scenarios source topology database. This is very important during failure
where the links we need to use to reroute the path share common sub- scenarios where the links we need to use to reroute the path share
segments with the failed path. Without the feedback, the common sub- common sub-segments with the failed path. Without the feedback, the
segments may not indicate sufficient available bandwidth until we common sub-segments may not indicate sufficient available bandwidth
get a flood that may mean many seconds without a connection. With until we get a flood that may mean many seconds without a
feedback at least we will be up to date with respect to available connection. With feedback at least we will be up to date with
bandwidth up to the point of failure in the path. Also since failure respect to available bandwidth up to the point of failure in the
involves many paths tearing down and re-establishing this is the path. Also since failure involves many paths tearing down and re-
time that it is most critical to have an accurate view. establishing this is the time that it is most critical to have an
accurate view.
When preemption is being employed it is also extremely important When preemption is being employed it is also extremely important
that the topology database inconsistencies be small. If not, high that the topology database inconsistencies be small. If not, high
setup priority LSPs may unnecessarily preempt lower holding priority setup priority LSPs may unnecessarily preempt lower holding priority
LSPs to obtain bandwidth that, had they had a more up to date view LSPs to obtain bandwidth that, had they had a more up to date view
of unreserved bandwidth, they would have been able to find of unreserved bandwidth, they would have been able to find
elsewhere. Since preempted LSPs may in turn preempt other LSPs in a elsewhere. Since preempted LSPs may in turn preempt other LSPs in a
domino like effect, the results of such database inconsistencies can domino like effect, the results of such database inconsistencies can
have wide reaching ripple like impacts. These feedback mechanisms have wide reaching ripple like impacts. These feedback mechanisms
help reduce these occurrences significantly. help reduce these occurrences significantly.
skipping to change at line 208 skipping to change at page 4, line 55
rate of arriving reservations exceeds the rate of departing rate of arriving reservations exceeds the rate of departing
reservations. The second is called steady-state, this is when the reservations. The second is called steady-state, this is when the
rate of arriving reservations is about the same as the rate of rate of arriving reservations is about the same as the rate of
departing reservations. Finally, the ramp-down condition is that departing reservations. Finally, the ramp-down condition is that
which has a greater rate of departing reservations than arriving which has a greater rate of departing reservations than arriving
reservations. reservations.
These three network conditions show distinctly different types of These three network conditions show distinctly different types of
error in the topology databases. In particular an optimistic view of error in the topology databases. In particular an optimistic view of
available bandwidth by a source node is characteristic of the ramp- available bandwidth by a source node is characteristic of the ramp-
Ashwood-Smith, et. al. January 2000 [Page 4] Internet Draft LSP Feedback with CR-LDP January, 2000
up condition of a network. A pessimistic view of available bandwidth up condition of a network. A pessimistic view of available bandwidth
by a source node is characteristic of the ramp-down condition of a by a source node is characteristic of the ramp-down condition of a
network. If one plots the average error in the topology databases network. If one plots the average error in the topology databases
with respect to the real network for the three different network with respect to the real network for the three different network
conditions, one will see the error slowly go positive during ramp conditions, one will see the error slowly go positive during ramp
up, slowly go negative during ramp down, and drift slowly around 0 up, slowly go negative during ramp down, and drift slowly around 0
for the steady condition. The effect of flooding on this plot is to for the steady condition. The effect of flooding on this plot is to
periodically snap the error back to 0 at flooding intervals. The periodically snap the error back to 0 at flooding intervals. The
effect of the feedback algorithm is to bring an optimistic error effect of the feedback algorithm is to bring an optimistic error
back to zero without having to wait for the flood interval. On back to zero without having to wait for the flood interval. On
skipping to change at line 264 skipping to change at page 6, line 5
We have also explored through simulation and implementation a We have also explored through simulation and implementation a
variety of mechanisms to deal with the pessimistic error in the variety of mechanisms to deal with the pessimistic error in the
database. One simple proposal is to use selective forgetting. In database. One simple proposal is to use selective forgetting. In
this algorithm, a reserved bandwidth value slowly drops back to zero this algorithm, a reserved bandwidth value slowly drops back to zero
over a relatively short time interval. The theory being that you over a relatively short time interval. The theory being that you
shift the network back to an optimistic state (by forgetting your shift the network back to an optimistic state (by forgetting your
pessimism) where the feedback algorithm will again correctly pessimism) where the feedback algorithm will again correctly
operate. These algorithms have not shown any great advantage and are operate. These algorithms have not shown any great advantage and are
actually non-optimal when the error is purely optimistic. actually non-optimal when the error is purely optimistic.
Ashwood-Smith, et. al. January 2000 [Page 5] Internet Draft LSP Feedback with CR-LDP January, 2000
Other algorithmic permutations we have explored include such Other algorithmic permutations we have explored include such
variations as: variations as:
Feeding-back to all intermediate nodes, information learned from Feeding-back to all intermediate nodes, information learned from
control messages upstream of that intermediate node. control messages upstream of that intermediate node.
Feeding back in both directions so that both the source and Feeding back in both directions so that both the source and
destination node's databases stay synchronized. destination node's databases stay synchronized.
Allowing a request to continue to its destination despite there Allowing a request to continue to its destination despite there
skipping to change at line 293 skipping to change at page 6, line 32
algorithms and their impacts on blocking times so we do not want to algorithms and their impacts on blocking times so we do not want to
discourage the interested reader from exploring these concepts more discourage the interested reader from exploring these concepts more
fully. fully.
2. Adding feedback TLVs to CR-LDP 2. Adding feedback TLVs to CR-LDP
Two new TLVs are optionally added to the CR-LDP mapping, Two new TLVs are optionally added to the CR-LDP mapping,
notification, and withdraw messages. There may be an arbitrary notification, and withdraw messages. There may be an arbitrary
number of these TLV in any order or position in the message. It is number of these TLV in any order or position in the message. It is
recommended that they be placed such that they can be read and recommended that they be placed such that they can be read and
applied to a topology database by scanning the message forwards and applied to override the topology database by scanning the message
walking the topology database from the point where the last link forwards and walking the topology database from the point where the
feedback TLV left off. last link feedback TLV left off.
Each TLV consists of the 8 unreserved bandwidth values for each Each TLV consists of the 8 unreserved bandwidth values for each
holding priority 0 through 7 as IEEE floating point numbers (the holding priority 0 through 7 as IEEE floating point numbers (the
units are unidirectional bytes per second). Following this are the units are unidirectional bytes per second). Following this are the
IP addresses of the two ends of the interface. Two TLVs are IP addresses of the two ends of the interface. Two TLVs are
possible, one for IPV4 and one for IPV6 addressing of the link. possible, one for IPV4 and one for IPV6 addressing of the link.
Note: the feedback TLVs may also optionally be included in query or
query-reply messages in response to bandwidth update queries from an
LER. Details of this mechanism are provided in [QUERY].
2.1 Bandwidth directionality considerations 2.1 Bandwidth directionality considerations
The order of the two addresses in the feedback TLV implies the The order of the two addresses in the feedback TLV implies the
direction in which the bandwidth is available. For example if the direction in which the bandwidth is available. For example if the
first address is A and the second address is B the bandwidth is first address is A and the second address is B the bandwidth is
unreserved in the A to B direction. unreserved in the A to B direction.
It is possible for an implementation to provide both the A to B It is possible for an implementation to provide both the A to B
direction and the B to A direction as part of the same feedback direction and the B to A direction as part of the same feedback
message. This is done by simply including a TLV with A,B as the message. This is done by simply including a TLV with A,B as the
addresses of the link and a different TLV with B,A as the addresses addresses of the link and a different TLV with B,A as the addresses
of the link. Should CR-LDP evolve to be able to support bi- of the link. Should CR-LDP evolve to be able to support bi-
directional traffic flow and reservations it is expected that bi- directional traffic flow and reservations it is expected that bi-
directional feedback would also be implemented via this mechanism. directional feedback would also be implemented via this mechanism.
Ashwood-Smith, et. al. January 2000 [Page 6] Internet Draft LSP Feedback with CR-LDP January, 2000
3. IPV4 specified link feedback TLV 3. IPV4 specified link feedback TLV
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| 0x830 | Length | |U|F| 0x830 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE float) | | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE float) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . . . . . . . . . . . . . .
skipping to change at line 352 skipping to change at page 8, line 37
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| 0x831 | Length | |U|F| 0x831 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE float) | | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE float) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . . . . . . . . . . . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BANDWIDTH UNRESERVED AT HOLDING PRIORITY 7 (IEEE float) | | BANDWIDTH UNRESERVED AT HOLDING PRIORITY 7 (IEEE float) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV6 address of interface (near end) | | IPV6 address of interface (near end) |
| _____ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV6 address of interface (far end) | | IPV6 address of interface (far end) |
| _____ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. Detailed Procedures 5. Detailed Procedures
On receipt of a withdraw, notification, or mapping message On receipt of a withdraw, notification, query-reply, or mapping
pertaining to a request made by CR-LDP (as opposed to LDP), a message pertaining to a request made by CR-LDP (as opposed to LDP),
feedback TLV of the appropriate format for the interface over which a feedback TLV of the appropriate format for the interface over
the message was received is inserted into the message before which the message was received is inserted into the message before
forwarding it back to the source of the request. The 8 bandwidth forwarding it back to the source of the request. The 8 bandwidth
values are filled in with the outgoing bandwidth available on this values are filled in with the outgoing bandwidth available on this
interface for each of the 8 holding priorities in bytes per second. interface for each of the 8 holding priorities in bytes per second.
Finally the interface's address and far end address are placed in Finally the interface's address and far end address are placed in
the TLV. the TLV.
On receipt of a CR-LDP request message which cannot be satisfied. A On receipt of a CR-LDP request message which cannot be satisfied. A
notification message is formatted normally. The 8-bandwidth values notification message is formatted normally. The 8-bandwidth values
Ashwood-Smith, et. al. January 2000 [Page 7] Internet Draft LSP Feedback with CR-LDP January, 2000
are filled in with the outgoing bandwidth available on this are filled in with the outgoing bandwidth available on this
interface for each of the 8 holding priorities in bytes per second. interface for each of the 8 holding priorities in bytes per second.
Finally, the interface's address and far end address are placed in Finally, the interface's address and far end address are placed in
the TLV. the TLV.
On receipt of a CR-LDP request message which has been satisfied and On receipt of a CR-LDP request message which has been satisfied and
which results in a mapping being generated. No feedback TLV is added which results in a mapping being generated. No feedback TLV is added
since the previous node will insert the proper TLV when it receives since the previous node will insert the proper TLV when it receives
the reverse flowing mapping. the reverse flowing mapping.
skipping to change at line 395 skipping to change at page 9, line 29
sessions in the module must generate either notification, withdraw sessions in the module must generate either notification, withdraw
or release messages for LSPs that traversed the LDP in question. In or release messages for LSPs that traversed the LDP in question. In
the case that the LSP was created by CR-LDP and that a withdraw or the case that the LSP was created by CR-LDP and that a withdraw or
notification is about to be generated, LDP will insert a feedback notification is about to be generated, LDP will insert a feedback
TLV for the interface which just went down that contains 0's for all TLV for the interface which just went down that contains 0's for all
the bandwidth values and attach to it the proper interface the bandwidth values and attach to it the proper interface
addresses. addresses.
When the LDP session that originated a CR-LDP label request receives When the LDP session that originated a CR-LDP label request receives
a mapping that contains feedback TLV's it is recommended that these a mapping that contains feedback TLV's it is recommended that these
bandwidth values overwrite the corresponding values in the node's bandwidth values supersede the corresponding values in the node's
topology database. Doing so permits this node to immediately topology database for source route computations. Doing so permits
synchronize its topology with respect to the real bandwidth this node to immediately synchronize its topology with respect to
reservations along the path that was just established. the real bandwidth reservations along the path that was just
established.
When the LDP session that originated a CR-LDP label request receives When the LDP session that originated a CR-LDP label request receives
a notification that contains feedback TLV's it is recommended that a notification that contains feedback TLV's it is recommended that
these bandwidth values overwrite the corresponding values in the these bandwidth values supersede the corresponding values in the
nodes topology database. Doing so permits this node to immediately node's topology database for source route computations. Doing so
synchronize its topology with respect to the real bandwidth permits this node to immediately synchronize its topology with
reservations along the path that just failed to establish. The respect to the real bandwidth reservations along the path that just
source node may then re-compute a path knowing that the computation failed to establish. The source node may then re-compute a path
will take into account the failure if it was caused by the topology knowing that the computation will take into account the failure if
database being in error with respect to the real network state. it was caused by the topology database being in error with respect
to the real network state.
6. IGP considerations 6. IGP considerations
Implementations MUST NOT permit bandwidth information learned by Implementations MUST NOT permit bandwidth information learned by
this feedback mechanism to be re-flooded via IS-IS, OSPF or any this feedback mechanism to be re-flooded via IS-IS, OSPF or any
other IGP. The bandwidth information learned via these feedback other IGP. The bandwidth information learned via these feedback
mechanisms is to be used ONLY for source route computations on the mechanisms is to be used ONLY for source route computations on the
nodes that are directly on the path that fed back the bandwidth. nodes that are directly on the path that fed back the bandwidth.
Normally only the source node of the LSP, or perhaps intermediate Normally only the source node of the LSP, or perhaps intermediate
gateway nodes will use this information. It is however permitted for gateway nodes will use this information. It is however permitted for
intermediate nodes that are forwarding this feedback information to intermediate nodes that are forwarding this feedback information to
store it for their own local source route computations. store it for their own local source route computations.
There is a possibility of a race condition between the bandwidth There is a possibility of a race condition between the bandwidth
information that is received via feedback and that which is received information that is received via feedback and that which is received
via a normal IGP flood. While there may be a discrepancy between the via a normal IGP flood. While there may be a discrepancy between the
Ashwood-Smith, et. al. January 2000 [Page 8] Internet Draft LSP Feedback with CR-LDP January, 2000
two, both are within a few 100 milliseconds of being correct. two, both are within a few 100 milliseconds of being correct.
Solutions to allow us to determine which information is most up to Solutions to allow us to determine which information is most up to
date (say by adding a sequence number) do not add any significant date (say by adding a sequence number) do not add any significant
benefit. Constraint based, source routed systems will always have benefit. Constraint based, source routed systems will always have
errors in the local topology database with respect to the real errors in the local topology database with respect to the real
network. We can reduce these errors through reduced flooding network. We can reduce these errors through reduced flooding
intervals, path following feedback and selective flooding but we intervals, path following feedback and selective flooding but we
cannot realistically reduce the errors below the second or so range. cannot realistically reduce the errors below the second or so range.
As a result propagation delay order race conditions are noise with As a result propagation delay order race conditions are noise with
respect to the average expected errors. An implementation SHOULD respect to the average expected errors. An implementation SHOULD
skipping to change at line 455 skipping to change at page 10, line 35
Actual utilization levels, current congestion levels, number of Actual utilization levels, current congestion levels, number of
discrete channels/wavelengths available etc. are all possible discrete channels/wavelengths available etc. are all possible
constraints that change rapidly and which must be taken into constraints that change rapidly and which must be taken into
consideration when computing a route. It is expected that this consideration when computing a route. It is expected that this
mechanism will be used to feedback these and other new forms of link mechanism will be used to feedback these and other new forms of link
constraining data. constraining data.
8. RSVP consideration 8. RSVP consideration
Nothing precludes the use of such feedback mechanisms with a similar Nothing precludes the use of such feedback mechanisms with a similar
TLV structure in the RSVP Resv and other reverse flowing message TLV structure in the RSVP Resv and other reverse flowing messages
although repeatedly applying a fed-back update into a local topology although repeatedly applying a fed-back should be avoided since it
database is wasteful and probably should be damped. increases the race condition window with flooded LSPs. This could be
accomplished by a simple rule that only permits fed-back information
on the original RESV, not on subsequent refreshes.
9. Intellectual Property Consideration 9. Intellectual Property Consideration
The IETF has been notified of intellectual property rights claimed The IETF has been notified of intellectual property rights claimed
in regard to some or all of the specification contained in this in regard to some or all of the specification contained in this
document. For more information consult the online list of claimed document. For more information consult the online list of claimed
rights. rights.
10. Security Considerations 10. Security Considerations
skipping to change at line 472 skipping to change at page 11, line 4
in regard to some or all of the specification contained in this in regard to some or all of the specification contained in this
document. For more information consult the online list of claimed document. For more information consult the online list of claimed
rights. rights.
10. Security Considerations 10. Security Considerations
This document raises no new security considerations for CR-LDP, RSVP This document raises no new security considerations for CR-LDP, RSVP
or MPLS in general. or MPLS in general.
11. Acknowledgments 11. Acknowledgments
The authors would like to thank Keith Dysart for his guidance, and The authors would like to thank Keith Dysart for his guidance, and
Jerzy Miernik for helping implement these concepts and bringing them Jerzy Miernik for helping implement these concepts and bringing them
to life. to life.
12. References 12. References
Ashwood-Smith, et. al. January 2000 [Page 9] Internet Draft LSP Feedback with CR-LDP January, 2000
[CR-LDP] Constraint-Based LSP Setup using LDP, draft-ietf-mpls-cr- [CR-LDP] Constraint-Based LSP Setup using LDP, draft-ietf-mpls-cr-
ldp-04.txt ldp-04.txt
[LDP] LDP Specification, draft-ietf-mpls-ldp-05.txt [LDP] LDP Specification, draft-ietf-mpls-ldp-05.txt
[IS-IS] Extensions to IS-IS for traffic engineering, draft-ietf- [IS-IS] Extensions to IS-IS for traffic engineering, draft-ietf-
isis-traffic-01.txt isis-traffic-01.txt
[QUERY] MPLS LDP Query Message Description, draft-paraschiv-mpls-
lsp-query-00.txt.
13. Author's Addresses 13. Author's Addresses
Peter Ashwood-Smith Bilel Jamoussi Peter Ashwood-Smith Bilel Jamoussi
Nortel Networks Corp. Nortel Networks Corp. Nortel Networks Corp. Nortel Networks Corp.
P.O. Box 3511 Station C, 600 Technology Park Drive P.O. Box 3511 Station C, 600 Technology Park Drive
Ottawa, ON K1Y 4H7 Billerica, MA 01821 Ottawa, ON K1Y 4H7 Billerica, MA 01821
Canada USA Canada USA
Phone: +1 613-763-4534 phone: +1 978-288-4506 Phone: +1 613-763-4534 phone: +1 978-288-4506
petera@nortelnetworks.com jamoussi@nortelnetworks.com petera@nortelnetworks.com jamoussi@nortelnetworks.com
skipping to change at line 526 skipping to change at line 521
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
Ashwood-Smith, et. al. January 2000 [Page 10]
 End of changes. 

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