draft-ietf-mpls-te-feed-05.txt   draft-ietf-mpls-te-feed-06.txt 
MPLS Working Group Peter Ashwood-Smith MPLS Working Group Peter Ashwood-Smith
Internet Draft Bilel Jamoussi Internet Draft Bilel Jamoussi
Expiration Date: MAY 2003 Don Fedyk Expiration Date: November 2003 Don Fedyk
Standards Track Darek Skalecki Standards Track Darek Skalecki
Nortel Networks Nortel Networks
Nov 2002 June 2003
Improving Topology Data Base Accuracy with Label Switched Path Improving Topology Data Base Accuracy with Label Switched Path
Feedback in Constraint Based Label Distribution Protocol Feedback in Constraint Based Label Distribution Protocol
draft-ietf-mpls-te-feed-05.txt draft-ietf-mpls-te-feed-06.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 52 skipping to change at page 2, line 4
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 scenario's attempting. This information is most valuable in failure scenarios
but is beneficial 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.
Table of Contents Table of Contents
1.0 Introduction and Description . . . . . . . . . . . . . . . 2 1.0 Introduction and Description . . . . . . . . . . . . . . . 2
2.0 Adding feedback TLVs to CR-LDP . . . . . . . . . . . . . . 6 2.0 Adding feedback TLVs to CR-LDP . . . . . . . . . . . . . . 6
2.1 Bandwidth directionality considerations. . . . . . . . 6 2.1 Bandwidth directionality considerations. . . . . . . . 6
3.0 Link Feedback TLV. . . . . . . . . . . . . . . . . . . . . 7 3.0 Link Feedback TLV. . . . . . . . . . . . . . . . . . . . . 7
3.1 Link feedback TLV Description . . . . . . . . . . . . . 7 3.1 Link feedback TLV Description . . . . . . . . . . . . . 7
3.2 Local Interface IP Address Subtypes . . . . . . . . . . 8 3.2 Local Interface IP Address Subtypes . . . . . . . . . . 8
3.3 Remote Interface IP Address Subtypes . . . . . . . . .. 8 3.3 Remote Interface IP Address Subtypes . . . . . . . . .. 8
3.4 Unreserved Bandwidth Sub Type. . . . . . . . . . . . . 8 3.4 Unreserved Bandwidth Sub Type. . . . . . . . . . . . . 8
4.0 Detailed Procedures. . . . . . . . . . . . . . . . . . . . 9 4.0 Detailed Procedures. . . . . . . . . . . . . . . . . . . . 9
5.0 IGP Considerations . . . . . . . . . . . . . . . . . . . .10 5.0 IGP Considerations . . . . . . . . . . . . . . . . . . . .10
6.0 Future Considerations . . . . . . . . . . . . . . . . . .10 6.0 Future Considerations . . . . . . . . . . . . . . . . . .11
7.0 RSVP-TE Considerations . . . . . . . . . . . . . . . . . .11 7.0 RSVP-TE Considerations . . . . . . . . . . . . . . . . . .11
8.0 Intellectual Property Considerations . . . . . . . . . . .11 8.0 Intellectual Property Considerations . . . . . . . . . . .11
9.0 Security Considerations. . . . . . . . . . . . . . . . . .11 9.0 Security Considerations. . . . . . . . . . . . . . . . . .11
10.0 IANA Considerations . . . . . . . . . . . . . . . . . . .11 10.0 IANA Considerations . . . . . . . . . . . . . . . . . . .11
11.0 Acknowledgements . . . . . . . . . . .. . . . . . . . . .11 11.0 Acknowledgements . . . . . . . . . . .. . . . . . . . . .11
12.0 Normative References. . . . . . . . . . . . . . . . . . .11 12.0 Normative References. . . . . . . . . . . . . . . . . . .12
13.0 Informative References. . . . . . . . . . . . . . . . . .12 13.0 Informative References. . . . . . . . . . . . . . . . . .12
14.0 Authors Addresses . . . . . . . . . . . . . . . . . . . .12 14.0 Authors Addresses . . . . . . . . . . . . . . . . . . . .12
1.0 Introduction and Description 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
skipping to change at page 6, line 34 skipping to change at page 6, line 38
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 Note: the feedback TLVs may also optionally be included in query or
query-reply messages in response to bandwidth update queries from an query-reply messages in response to bandwidth update queries from an
LER. Details of this mechanism are provided in [QUERY]. 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 local address is A and the remote 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.
skipping to change at page 8, line 7 skipping to change at page 8, line 13
receipt of an unknown TLV, if U is if U is set (=1), the unknown TLV 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 is silently ignored and the rest of the message is processed as if
the unknown TLV did not exist. the unknown TLV did not exist.
F bit F bit
Forward unknown TLV bit must be set to 1. This bit applies only 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 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 TLV is to be forwarded. If F is set (=1), the unknown TLV is
forwarded with the containing message. forwarded with the containing message.
The following sub tlvs for the Feedback TLV are defined: The following sub TLVs for the Feedback TLV are defined:
1 - Local interface IP address (IPv4) 1 - Local interface IP address (IPv4)
2 - Remote interface IP address (IPv4) 2 - Remote interface IP address (IPv4)
3 - Local interface IP address (IPv6) 3 - Local interface IP address (IPv6)
4 - Remote interface IP address (IPv6) 4 - Remote interface IP address (IPv6)
5 - Unreserved bandwidth 5 - Unreserved bandwidth
This document defines the sub types. The code points are to be This document defines the sub types. The code points are to be
assigned by IANA. assigned by IANA.
skipping to change at page 9, line 39 skipping to change at page 9, line 47
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
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. Where LDP FT procedures [LDP-FT] are in use, LSPs that addresses. Where LDP FT procedures [RFC3479] are in use, LSPs that
are protected by FT procedures should not be torn down until after are protected by FT procedures should not be torn down until after
session reestablishment has failed. During LDP re-establishment session reestablishment has failed. During LDP re-establishment
time new connections may be queued and delayed for the re- time new connections may be queued and delayed for the re-
establishment time. If signaling delay is undesirable feedback may establishment time. If signaling delay is undesirable feedback may
be used to report zero bandwidth. In this case, if LDP is be used to report zero bandwidth. In this case, if LDP is
successfully re-established a Link LSA should be triggered if successfully re-established a Link LSA should be triggered if
sufficient amount bandwidth is available. sufficient amount bandwidth is available.
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
skipping to change at page 11, line 26 skipping to change at page 11, line 37
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.
9.0 Security Considerations 9.0 Security Considerations
This document covers an additional data structure, a TLV to an This document covers an additional data structure, a TLV to an
existing LDP message. Therefore the security aspects of this are the existing LDP message. Therefore the security aspects of this are the
same as a LDP. CR-LDP inherits the same security mechanism described same as a LDP. CR-LDP inherits the same security mechanism described
in Section 4.0 of [LDP] to protect against the introduction of in Section 4.0 of [RFC3032] to protect against the introduction of
spoofed TCP segments into LDP session connection streams. spoofed TCP segments into LDP session connection streams.
10.0 IANA Considerations 10.0 IANA Considerations
The Feedback TLV as well as Types for sub-TLVs in a Feedback TLV are The Feedback TLV as well as Types for sub-TLVs in a Feedback TLV are
to be registered with IANA. to be registered with IANA.
[RFC3212] defines the CR-LDP TLV name space. This memo requires [RFC3212] defines the CR-LDP TLV name space. This memo requires
assignment of one TLV Type from that range. assignment of one TLV Type from that range.
skipping to change at page 12, line 5 skipping to change at page 12, line 14
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. The authors' would like to acknowledge Dave Allan for his to life. The authors' would like to acknowledge Dave Allan for his
comments and suggestions. comments and suggestions.
12.0 Normative References 12.0 Normative References
[RFC3212] 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 [RCF3032] Andersson, L. et al., "LDP Specification", RFC 3032,
2001. January 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,
2001. December 2001.
[OSPF] Katz,D., Yeung, D., Kompella, K., " Traffic Engineering [OSPF] Katz,D., Yeung, D., Kompella, K., " Traffic Engineering
Extensions to OSPF Version 2," draft-katz-yeung-ospf-traffic-08.txt, Extensions to OSPF Version 2," draft-katz-yeung-ospf-traffic-08.txt,
September 2002. September 2002.
13.0 Informative References 13.0 Informative References
[QUERY] Ashwood-Smith, P., Paraschiv, A., " Multi Protocol Label [QUERY] Ashwood-Smith, P., Paraschiv, A., " Multi Protocol Label
Switching Label Distribution Protocol Query Message Description Switching Label Distribution Protocol Query Message Description
", Internet Draft, draft-anto-ldp-query-04.txt, May 2002. ", Internet Draft, draft-anto-ldp-query-08.txt, June 2003.
[LDP-FT] Farrel, A et al., " Fault Tolerance for the Label [RFC3479] Farrel, A et al., " Fault Tolerance for the Label
Distribution Protocol (LDP)", Internet Draft, draft-ietf-mpls-ldp- Distribution Protocol (LDP)", RFC 3479, February 2003
ft-06.txt, September 2002
14.0 Author's Addresses 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
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-765-2252 Phone: +1 978-228-3041 Phone: +1 613-765-2252 Phone: +1 978-288-3041
dareks@nortelnetworks.com dwfedyk@nortelnetworks.com dareks@nortelnetworks.com dwfedyk@nortelnetworks.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society 2002. All Rights Reserved. This Copyright (C) The Internet Society 2003. All Rights Reserved. This
document and translations of it may be copied and furnished to document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
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
 End of changes. 

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