draft-ietf-mpls-te-feed-04.txt   draft-ietf-mpls-te-feed-05.txt 
MPLS Working Group Peter Ashwood-Smith MPLS Working Group Peter Ashwood-Smith
Internet Draft Bilel Jamoussi Internet Draft Bilel Jamoussi
Expiration Date: Nov 2002 Don Fedyk Expiration Date: MAY 2003 Don Fedyk
Darek Skalecki Standards Track Darek Skalecki
Nortel Networks Nortel Networks
May 2002 Nov 2002
Improving Topology Data Base Accuracy with LSP Feedback in CR-LDP Improving Topology Data Base Accuracy with Label Switched Path
Feedback in Constraint Based Label Distribution Protocol
draft-ietf-mpls-te-feed-04.txt draft-ietf-mpls-te-feed-05.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 page 1, line 51 skipping to change at page 1, line 52
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
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. A new mechanism is proposed database discrepancies from growing. A new mechanism is proposed
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 information is most valuable in failure scenarious attempting. This information is most valuable in failure scenario's
but is benificial during other path setup functions as well. This but is beneficial during other path setup functions as well. This
fed-back information can be incorporated into subsequent route fed back information can be incorporated into subsequent route
computations, which greatly improves the accuracy of the overall computations, which greatly improves the accuracy of the overall
routing solution by significantly reducing the database routing solution by significantly reducing the database
discrepancies. discrepancies.
1. Introduction Table of Contents
1.0 Introduction and Description . . . . . . . . . . . . . . . 2
2.0 Adding feedback TLVs to CR-LDP . . . . . . . . . . . . . . 6
2.1 Bandwidth directionality considerations. . . . . . . . 6
3.0 Link Feedback TLV. . . . . . . . . . . . . . . . . . . . . 7
3.1 Link feedback TLV Description . . . . . . . . . . . . . 7
3.2 Local Interface IP Address Subtypes . . . . . . . . . . 8
3.3 Remote Interface IP Address Subtypes . . . . . . . . .. 8
3.4 Unreserved Bandwidth Sub Type. . . . . . . . . . . . . 8
4.0 Detailed Procedures. . . . . . . . . . . . . . . . . . . . 9
5.0 IGP Considerations . . . . . . . . . . . . . . . . . . . .10
6.0 Future Considerations . . . . . . . . . . . . . . . . . .10
7.0 RSVP-TE Considerations . . . . . . . . . . . . . . . . . .11
8.0 Intellectual Property Considerations . . . . . . . . . . .11
9.0 Security Considerations. . . . . . . . . . . . . . . . . .11
10.0 IANA Considerations . . . . . . . . . . . . . . . . . . .11
11.0 Acknowledgements . . . . . . . . . . .. . . . . . . . . .11
12.0 Normative References. . . . . . . . . . . . . . . . . . .11
13.0 Informative References. . . . . . . . . . . . . . . . . .12
14.0 Authors Addresses . . . . . . . . . . . . . . . . . . . .12
1.0 Introduction and Description
Because the network is a distributed system, it is necessary to have Because the network is a distributed system, it is necessary to have
a mechanism to advertise information about links to all nodes in the a mechanism to advertise information about links to all nodes in the
network [IS-IS], [OSPF]. A node can then build a topology map of network [IS-IS], [OSPF]. A node can then build a topology map of
the network. This information is required to be as up-to-date as the network. This information is required to be as up-to-date as
possible for accurate traffic engineered paths. Information about possible for accurate traffic engineered paths. Information about
link or node failures must be rapidly propagated through the network link or node failures must be rapidly propagated through the network
so that recovery can be initiated. Other information about links so that recovery can be initiated. Other information about links
that may be useful for reasons of quality of service includes that may be useful for reasons of quality of service includes
parameters such as available bandwidth, and delay. The information parameters such as available bandwidth, and delay. The information
in this topology database is often out of date with respect to the in this topology database is often out of date with respect to the
real network. Available bandwidth is the most critical of these real network. Available bandwidth is the most critical of these
attributes and it can drift substantially with respect to reality attributes and it can drift substantially with respect to reality
due to the low frequency of link state updates that can be sustained due to the low frequency of link state updates that can be sustained
in a very large topology. The deviation in the topology database in a very large topology. The deviation in the topology database
available bandwidth is refered to as being optimistic if the available bandwidth is referred to as being optimistic if the
database shows more available bandwidth than there really is, or database shows more available bandwidth than there really is, or
pessimistic if the topology database shows less bandwidth than there pessimistic if the topology database shows less bandwidth than there
really is. This distinction is important to enable an efficient really is. This distinction is important to enable an efficient
algorithm to deal with optimistic databases without resorting to algorithm to deal with optimistic databases without resorting to
shorter flooding intervals. shorter flooding intervals.
One of the major problems for a constraint based routing system is One of the major problems for a constraint based routing system is
dealing with changing constraints. Obviously, since bandwidth is one dealing with changing constraints. Obviously, since bandwidth is one
of the essential constraints, dealing with the rapid changes in of the essential constraints, dealing with the rapid changes in
reserved bandwidth poses some interesting challenges. In smaller reserved bandwidth poses some interesting challenges. In smaller
networks, one can resort to higher frequency flooding but this networks, one can resort to higher frequency flooding but this
obviously does not scale. The feedback mechanism is particularily obviously does not scale. The feedback mechanism is particularly
useful in the case of link or node failures where the rapid change useful in the case of link or node failures where the rapid change
and notification of resource change is crutuail to the restoration and notification of resource change is crucial to the restoration
time. Feedback is work conserving in this case since the time. Feedback is work conserving in this case since the
availability of feedback information minimizes the extra burden of availability of feedback information minimizes the extra burden of
dealing with out of date topology and resource information. dealing with out of date topology and resource information.
The basic proposal is to add to the signaling protocol the ability The basic approach 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 node and attached to the source node's topology database prior to
skipping to change at page 5, line 36 skipping to change at page 6, line 10
since a routing system will never give paths to links that it thinks since a routing system will never give paths to links that it thinks
do not have resources and as a result its pessimistic view of the do not have resources and as a result its pessimistic view of the
world stays that way until it gets a flood. This relieves the IGP world stays that way until it gets a flood. This relieves the IGP
updates of the most urgent requirement of flooding when bandwidth is updates of the most urgent requirement of flooding when bandwidth is
consumed. Availability of new bandwidth occurs when paths are consumed. Availability of new bandwidth occurs when paths are
released or new links become available. Floods already accompany released or new links become available. Floods already accompany
new links. Significant releases of bandwidth can be broadcast at new links. Significant releases of bandwidth can be broadcast at
relatively low frequencies in the order of several minutes with relatively low frequencies in the order of several minutes with
little operational impact. little operational impact.
Extensive operational experience with this feedback protocol in 2.0 Adding feedback TLVs to CR-LDP
proprietary Nortel Networks (pre-standard CR-LDP) products has shown
it to work very well for networks up to 1000 nodes with significant
flooding intervals damped to several minutes. Without this protocol,
these networks would block setups for up to several minutes. With
this protocol, the blocking in most cases is reduced to a small
number of retry attempts which is usually sub-second depending
mostly on the propagation delays in the network.
These feedback algorithms have been particularly beneficial in cases
of failure recovery during which the network is in a sudden
condition of ramp-up. Since a large number of reservations must be
remade, it is highly likely that the bandwidth reservation limits of
certain key links in the network will be exceeded. Without feedback,
the rerouting must block until a flood arrives telling us of the
situation at those key links at which time rerouting can continue.
With feedback, the rerouting simply continues until a feedback
indicates that a link is full. In addition since reservation-
balancing algorithms are also often used, feedback allows the
balancing algorithms to make better distribution decisions based on
immediate feedback.
We have also explored through simulation and implementation a
variety of mechanisms to deal with the pessimistic error in the
database. One simple proposal is to use selective forgetting. In
this algorithm, a reserved bandwidth value slowly drops back to zero
over a relatively short time interval. The theory being that you
shift the network back to an optimistic state (by forgetting your
pessimism) where the feedback algorithm will again correctly
operate. These algorithms have not shown any great advantage and are
actually non-optimal when the error is purely optimistic.
Other algorithmic permutations explored include such variations as:
Feeding-back to all intermediate nodes, information learned from
control messages upstream of that intermediate node.
Feeding back in both directions so that both the source and
destination node's databases stay synchronized.
Allowing a request to continue to its destination despite there
being insufficient bandwidth at some intermediate hop. Then,
rejecting the request with a full bandwidth vector slice all the way
to the destination instead of just to the point of rejection.
Our simulations have not show significant benefits relative to the
simpler algorithm proposed here. However, it is an interesting
research topic to explore and quantify the different feedback
algorithms and their impacts on blocking times so we do not want to
discourage the interested reader from exploring these concepts more
fully.
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 override the topology database by scanning the message applied to override the topology database by scanning the message
forwards and walking the topology database from the point where the forwards and walking the topology database from the point where the
last link feedback TLV left off. last link feedback TLV left off.
Each TLV consists of the eightunreserved bandwidth values for each Each TLV consists of the eightunreserved bandwidth values for each
skipping to change at page 7, line 17 skipping to change at page 6, line 42
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.
3. IPV4 specified link feedback TLV 3.0 Link Feedback TLV
The Feedback payload consists of one or more nested
Type/Length/Value (TLV) triplets for extensibility. The format of
each TLV is:
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| TBD IANA | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE float) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . . . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BANDWIDTH UNRESERVED AT HOLDING PRIORITY 7 (IEEE float) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV4 address of interface (near end) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV4 address of interface (far end) | | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. IPV6 specified link feedback TLV The Length field defines the length of the value portion in octets
(thus a TLV with no value portion would have a length of zero). The
TLV is padded to four-octet alignment; padding is not included in
the length field (so a three octet value would have a length of
three, but the total size of the TLV would be eight octets). Nested
TLVs are also 32-bit aligned. Unrecognized types are ignored.
3.1 Link feedback TLV Description
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| TBD IANA | Length | |U|F| TBD IANA | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BANDWIDTH UNRESERVED AT HOLDING PRIORITY 0 (IEEE float) | | Sub TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . . . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BANDWIDTH UNRESERVED AT HOLDING PRIORITY 7 (IEEE float) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV6 address of interface (near end) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPV6 address of interface (far end) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. Detailed Procedures
This document introduces essentially one Feedback TLV. There may be
multiple instances of the Feedback TLV in a CR-LDP message, one for
each different links along the path. Due to the current format that
TE extension documents organize TE information the feedback TLV has
sub TLVs. This allows the information to conform to the current TE
conventions and allows options for additional future feedback
elements. The formats are derived from the TE extensions TLVs for
IS-IS [IS-IS] and OSPF [OSPF].
U bit
Unknown TLV bit must be set to 1. As with all CR-LDP messages, upon
receipt of an unknown TLV, if U is if U is set (=1), the unknown TLV
is silently ignored and the rest of the message is processed as if
the unknown TLV did not exist.
F bit
Forward unknown TLV bit must be set to 1. This bit applies only
when the U bit is set and the CR-LDP message containing the unknown
TLV is to be forwarded. If F is set (=1), the unknown TLV is
forwarded with the containing message.
The following sub tlvs for the Feedback TLV are defined:
1 - Local interface IP address (IPv4)
2 - Remote interface IP address (IPv4)
3 - Local interface IP address (IPv6)
4 - Remote interface IP address (IPv6)
5 - Unreserved bandwidth
This document defines the sub types. The code points are to be
assigned by IANA.
3.2 Local Interface IP Address Sub Types
The Local Interface IP Address sub-TLV specifies the IP address(es)
of the interface corresponding to this link. Normally there will
only be one address. If there are multiple
local addresses on the link, they are all listed in this sub-TLV.
The Local Interface IPv4 Address sub-TLV is TLV type 1, and is 4N
octets in length, where N is the number of local addresses.
The Local Interface IPv6 Address sub-TLV is TLV type 3, and is 16N
octets in length, where N is the number of local addresses.
3.3 Remote Interface IP Address Sub Types
The Remote Interface IP Address sub-TLV specifies the IP address(es)
of the neighbor's interface corresponding to this link. This and
the local address are used to discern multiple parallel links
between systems.
The Remote Interface IPv4 Address sub-TLV is TLV type 2, and is 4N
octets in length, where N is the number of neighbor addresses.
The Remote Interface IPv6 Address sub-TLV is TLV type 4, and is 16N
octets in length, where N is the number of neighbor addresses.
3.4 Unreserved Bandwidth Sub Type
The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth
not yet reserved at each of the eight priority levels, in IEEE
floating point format. The values correspond to the bandwidth that
can be reserved with a setup priority of 0 through 7, arranged in
increasing order with priority 0 occurring at the start of the sub-
TLV, and priority 7 at the end of the sub-TLV. The units are bytes
per second.
The Unreserved Bandwidth sub-TLV is TLV type 5, and is 32 octets in
length.
4.0 Detailed Procedures
On receipt of a withdraw, notification, query-reply, or mapping On receipt of a withdraw, notification, query-reply, or mapping
message pertaining to a request made by CR-LDP (as opposed to LDP), message pertaining to a request made by CR-LDP (as opposed to LDP),
a feedback TLV of the appropriate format for the interface over a feedback TLV of the appropriate format for the interface over
which 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 eight bandwidth forwarding it back to the source of the request. The interface's
values are filled in with the outgoing bandwidth available on this local and remote interface address in the appropriate format are
interface for each of the eightholding priorities in bytes per
second. Finally the interface's address and far end address are
placed in the TLV. placed in the TLV.
The eight bandwidth values are filled in with the outgoing bandwidth
available on this interface for each of the eight holding priorities
in bytes per second.
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 eight bandwidth notification message is formatted normally. The Feedback TLV with
values are filled in with the outgoing bandwidth available on this the local and remote interface address in the appropriate format and
interface for each of the eight holding priorities in bytes per the eight bandwidth values are filled in with the outgoing bandwidth
second. Finally, the interface's address and far end address are available on this interface for each of the eight holding priorities
placed in the TLV. in bytes per second.
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.
When an LDP session goes down either because of a link failure, When an LDP session goes down either because of a link failure,
TCP/IP timeout, keep alive timeout, adjacency timeout etc. Other LDP TCP/IP timeout, keep alive timeout, adjacency timeout etc. Other LDP
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
skipping to change at page 9, line 53 skipping to change at page 10, line 19
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 supersede the corresponding values in the these bandwidth values supersede the corresponding values in the
node's topology database for source route computations. Doing so node's topology database for source route computations. Doing so
permits this node to immediately synchronize its topology with permits this node to immediately synchronize its topology with
respect to the real bandwidth reservations along the path that just respect to the real bandwidth reservations along the path that just
failed to establish. The source node may then re-compute a path failed to establish. The source node may then re-compute a path
knowing that the computation will take into account the failure if knowing that the computation will take into account the failure if
it was caused by the topology database being in error with respect it was caused by the topology database being in error with respect
to the real network state. to the real network state.
6. IGP considerations 5.0 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
skipping to change at page 10, line 29 skipping to change at page 10, line 46
significant benefit. Constraint based, source routed systems will significant benefit. Constraint based, source routed systems will
always have errors in the local topology database with respect to always have errors in the local topology database with respect to
the real network. These errors can be reduced through reduced the real network. These errors can be reduced through reduced
flooding intervals, path following feedback and selective flooding flooding intervals, path following feedback and selective flooding
but realistically the errors cannot be reduced below the second or but realistically the errors cannot be reduced below the second or
so range. As a result propagation delay order race conditions are so range. As a result propagation delay order race conditions are
noise with respect to the average expected errors. An implementation noise with respect to the average expected errors. An implementation
SHOULD therefore consider the most recently received update (IGP or SHOULD therefore consider the most recently received update (IGP or
feedback) as being the most up to date. feedback) as being the most up to date.
7. Future considerations 6.0 Future considerations
Constraint based routing systems such as CR-LDP will in the future Constraint based routing systems such as CR-LDP will in the future
offer other forms of constraint than simply reserved bandwidth. offer other forms of constraint than simply reserved bandwidth.
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-TE consideration 7.0 RSVP-TE 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-TE Resv and other reverse flowing messages TLV structure in the RSVP-TE Resv and other reverse flowing messages
although repeatedly applying unchanged feedback should be avoided. although repeatedly applying unchanged feedback should be avoided.
This could be accomplished by a simple rule that only permits This could be accomplished by a simple rule that only permits
feedback information on the original RESV, not on subsequent feedback information on the original RESV, not on subsequent
refreshes. This document only covers the CR-LDP protocol. refreshes. This document only covers the CR-LDP protocol.
9. Intellectual Property Consideration 8.0 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 9.0 Security Considerations
This document raises no new security considerations for CR-LDP, This document covers an additional data structure, a TLV to an
RSVP-TE or MPLS in general. existing LDP message. Therefore the security aspects of this are the
same as a LDP. CR-LDP inherits the same security mechanism described
in Section 4.0 of [LDP] to protect against the introduction of
spoofed TCP segments into LDP session connection streams.
11. Acknowledgments 10.0 IANA Considerations
The authors would like to thank Keith Dysart for his guidance, and The Feedback TLV as well as Types for sub-TLVs in a Feedback TLV are
to be registered with IANA.
[RFC3212] defines the CR-LDP TLV name space. This memo requires
assignment of one TLV Type from that range.
Also, sub-Types of a Feedback TLV need to be assigned by IANA. The
types from 6 to 32767 are by expert review controlled by IANA. The
types 32768 to 65535 are reserved for private use.
11.0 Acknowledgments
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. The authors' would like to aknowledge Dave Allan for his to life. The authors' would like to acknowledge Dave Allan for his
comments and suggestions. comments and suggestions.
12. References 12.0 Normative References
[CR-LDP] Jamoussi, B. et al., "Constraint-Based LSP Setup using [RFC3212] Jamoussi, B. et al., "Constraint-Based LSP Setup using
LDP", RFC 3212, January 2002. LDP", RFC 3212, January 2002.
[LDP] Andersson, L. et al., "LDP Specification", RFC 3032, January [LDP] Andersson, L. et al., "LDP Specification", RFC 3032, January
2001. 2001.
[IS-IS] Li, T., Smit, H., "Extensions to IS-IS for traffic [IS-IS] Li, T., Smit, H., "Extensions to IS-IS for traffic
engineering", Internet Draft, draft-ietf-isis-traffic-04.txt, August engineering", Internet Draft, draft-ietf-isis-traffic-04.txt, August
2001. 2001.
[OSPF] Katz,D., Yeung, D., Kompella, K., "Traffic Engineering [OSPF] Katz,D., Yeung, D., Kompella, K., "Traffic Engineering
Extensions to OSPF," draft-katz-yeung-ospf-traffic-06.txt, February Extensions to OSPF Version 2," draft-katz-yeung-ospf-traffic-08.txt,
2001. September 2002.
[QUERY] Ashwood-Smith, P., Paraschiv, A., "MPLS LDP Query Message 13.0 Informative References
Description", Internet Draft, draft-anto-ldp-query-04.txt, May 2002.
[LDP-FT] Farrel, A et al., "Fault Tolerance for LDP and CR-LDP", [QUERY] Ashwood-Smith, P., Paraschiv, A., " Multi Protocol Label
Switching Label Distribution Protocol Query Message Description
", Internet Draft, draft-anto-ldp-query-04.txt, May 2002.
13. Author's Addresses [LDP-FT] Farrel, A et al., " Fault Tolerance for the Label
Distribution Protocol (LDP)", Internet Draft, draft-ietf-mpls-ldp-
ft-06.txt, September 2002
14.0 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
Darek Skalecki Don Fedyk Darek Skalecki Don Fedyk
 End of changes. 

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