draft-ietf-mpls-ldp-ft-05.txt   draft-ietf-mpls-ldp-ft-06.txt 
MPLS Working Group Editor MPLS Working Group Editor
Internet Draft Adrian Farrel Internet Draft Adrian Farrel
Document: draft-ietf-mpls-ldp-ft-05.txt Movaz Networks, Inc. Document: draft-ietf-mpls-ldp-ft-06.txt Movaz Networks, Inc.
Expiration Date: March 2003 September 2002 Expiration Date: March 2003 September 2002
Fault Tolerance for the Label Distribution Protocol (LDP) Fault Tolerance for the Label Distribution Protocol (LDP)
draft-ietf-mpls-ldp-ft-05.txt draft-ietf-mpls-ldp-ft-06.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC2026 conformance with all provisions of Section 10 of RFC2026
[RFC2026]. [RFC2026].
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute groups. Note that other groups may also distribute
skipping to change at page 2, line 57 skipping to change at page 2, line 57
8.4. FT ACK TLV 31 8.4. FT ACK TLV 31
8.5. FT Cork TLV 33 8.5. FT Cork TLV 33
9. Example Use 34 9. Example Use 34
9.1. Session Failure and Recovery - FT Procedures 35 9.1. Session Failure and Recovery - FT Procedures 35
9.2. Use of Check-Pointing With FT Procedures 37 9.2. Use of Check-Pointing With FT Procedures 37
9.3. Temporary Shutdown With FT Procedures 39 9.3. Temporary Shutdown With FT Procedures 39
9.4. Temporary Shutdown With FT Procedures and Check-Pointing 41 9.4. Temporary Shutdown With FT Procedures and Check-Pointing 41
9.5. Checkpointing Without FT Procedures 43 9.5. Checkpointing Without FT Procedures 43
9.6. Graceful Shutdown With Checkpointing But No FT Procedures 45 9.6. Graceful Shutdown With Checkpointing But No FT Procedures 45
10. Security Considerations 46 10. Security Considerations 46
11. Implementation Notes 47 11. Implementation Notes 48
11.1. FT Recovery Support on Non-FT LSRs 47 11.1. FT Recovery Support on Non-FT LSRs 48
11.2. ACK generation logic 48 11.2. ACK generation logic 48
11.2.1 Ack Generation Logic When Using Check-Pointing 48 11.2.1 Ack Generation Logic When Using Check-Pointing 48
11.3 Interactions With Other Label Distribution Mechanisms 49
12. Acknowledgments 49 12. Acknowledgments 49
13. Intellectual Property Consideration 49 13. Intellectual Property Consideration 50
14. Full Copyright Statement 49 14. Full Copyright Statement 50
15. IANA Considerations 50 15. IANA Considerations 50
15.1. New TLVs 50 15.1. New TLVs 51
15.2. New Status Codes 51 15.2. New Status Codes 51
16. Authors' Addresses 51 16. Authors' Addresses 52
17. References 52 17. References 52
17.1. Normative References 52 17.1. Normative References 52
17.2. Informative References 52 17.2. Informative References 53
1. Conventions and Terminology used in this document 1. Conventions and Terminology used in this document
Definitions of key words and terms applicable to LDP and Definitions of key words and terms applicable to LDP and
CR-LDP are inherited from [RFC3212] and [RFC3036]. CR-LDP are inherited from [RFC3212] and [RFC3036].
The term "FT Label" is introduced in this document to The term "FT Label" is introduced in this document to
indicated a label for which some fault tolerant operation indicated a label for which some fault tolerant operation
is used. A "non-FT Label" is not fault tolerant and is is used. A "non-FT Label" is not fault tolerant and is
handled as specified in [RFC3036]. handled as specified in [RFC3036].
skipping to change at page 47, line 16 skipping to change at page 47, line 16
outside the scope of this draft, but could be deployed to outside the scope of this draft, but could be deployed to
provide enhanced security to implementations of LDP and provide enhanced security to implementations of LDP and
the LDP FT enhancements. the LDP FT enhancements.
As with LDP, a security issue may exist if an LDP As with LDP, a security issue may exist if an LDP
implementation continues to use labels after expiration implementation continues to use labels after expiration
of the session that first caused them to be used. This of the session that first caused them to be used. This
may arise if the upstream LSR detects the session failure may arise if the upstream LSR detects the session failure
after the downstream LSR has released and re-used the after the downstream LSR has released and re-used the
label. The problem is most obvious with the platform- label. The problem is most obvious with the platform-
wide label space and could result in mis-routing of data wide label space and could result in mis-forwarding of data
to other than intended destinations and it is conceivable to other than intended destinations and it is conceivable
that these behaviors may be deliberately exploited to that these behaviors may be deliberately exploited to
either obtain services without authorization or to deny either obtain services without authorization or to deny
services to others. services to others.
In this draft, the validity of the session may be In this draft, the validity of the session may be
extended by the FT Reconnection Timeout, and the session extended by the FT Reconnection Timeout, and the session
may be re-established in this period. After the expiry may be re-established in this period. After the expiry
of the Reconnection Timeout the session must be of the Reconnection Timeout the session must be
considered to have failed and the same security issue considered to have failed and the same security issue
skipping to change at page 47, line 42 skipping to change at page 47, line 42
might reallocate the label while the upstream LSR might reallocate the label while the upstream LSR
continues to transmit data using the old usage of the continues to transmit data using the old usage of the
label. To reduce this issue, this draft requires that label. To reduce this issue, this draft requires that
labels are not re-used until the Reconnection Timeout has labels are not re-used until the Reconnection Timeout has
expired. expired.
A further issue might apply if labels were re-used prior A further issue might apply if labels were re-used prior
to the expiration of the FT Reconnection Timeout, but to the expiration of the FT Reconnection Timeout, but
this is forbidden by this draft. this is forbidden by this draft.
The issue of re-use of labels extends to labels managed through
other mechanisms including direct configuration through management
applications and distribution through other label distribution
protocols. Avoiding this problem may be contrued as an
implementation issue (see below) but failure to acknowledge it could
result in mis-forwarding of data between LSPs established using
some other mechanism and those recovered using the methods
described in this document.
11. Implementation Notes 11. Implementation Notes
11.1. FT Recovery Support on Non-FT LSRs 11.1. FT Recovery Support on Non-FT LSRs
In order to take full advantage of the FT capabilities of In order to take full advantage of the FT capabilities of
LSRs in the network, it may be that an LSR that does not LSRs in the network, it may be that an LSR that does not
itself contain the ability to recover from local hardware itself contain the ability to recover from local hardware
or software faults still needs to support the LDP FT or software faults still needs to support the LDP FT
enhancements described in this draft. enhancements described in this draft.
skipping to change at page 49, line 5 skipping to change at page 49, line 21
This approach may be considered optimal in systems that This approach may be considered optimal in systems that
do not show a high degree of change over time (such as do not show a high degree of change over time (such as
targeted LDP sessions) and that are prepared to risk loss targeted LDP sessions) and that are prepared to risk loss
of state for the most recent LDP exchanges. More dynamic of state for the most recent LDP exchanges. More dynamic
systems (such as LDP discovery sessions) are more likely systems (such as LDP discovery sessions) are more likely
to want to acknowledge state changes more frequently so to want to acknowledge state changes more frequently so
that the maximum amount of state can be preserved over a that the maximum amount of state can be preserved over a
failure. failure.
11.3 Interactions With Other Label Distribution Mechanisms
Many LDP LSRs also run other label distribution mechanisms. These
include management interfaces for configuration of static label
mappings, other distinct instances of LDP, and other label
distribution protocols. The last example includes traffic engineering
label distribution protocol that are used to construct tunnels
through which LDP LSPs are established.
As with re-use of individual labels by LDP within a restarting LDP
system, care must be taken to prevent labels that need to be retained
by a restarting LDP session or protocol component from being used by
another label distribution mechanism since that might compromise
data security amongst other things.
It is a matter for implementations to avoid this issue through the
use of techniques such as a common label management component or
segmented label spaces.
12. Acknowledgments 12. Acknowledgments
The work in this draft is based on the LDP ideas The work in this draft is based on the LDP ideas
expressed by the authors of [RFC3036]. expressed by the authors of [RFC3036].
The ACK scheme used in this draft was inspired by the The ACK scheme used in this draft was inspired by the
proposal by David Ward and John Scudder for restarting proposal by David Ward and John Scudder for restarting
BGP sessions now included in [BGP-RESTART]. BGP sessions now included in [BGP-RESTART].
The authors would also like to acknowledge the careful The authors would also like to acknowledge the careful
skipping to change at page 50, line 39 skipping to change at page 51, line 25
the 0x05xx range for TLVs that is used in [RFC3036] by the 0x05xx range for TLVs that is used in [RFC3036] by
other TLVs carrying session-wide attributes. The next other TLVs carrying session-wide attributes. The next
available value in this range is 0x0503. available value in this range is 0x0503.
The FT Protection TLV may ACK many label operations at The FT Protection TLV may ACK many label operations at
once if cumulative ACKS are used. It is taken from the once if cumulative ACKS are used. It is taken from the
0x05xx range for TLVs that is used in [RFC3036] by other 0x05xx range for TLVs that is used in [RFC3036] by other
TLVs carrying session-wide attributes. The next TLVs carrying session-wide attributes. The next
available value in this range is 0x0504. available value in this range is 0x0504.
The FT Cork TLV carries attributes that apply to all The FT Cork TLV carries attributes that apply to all labels
labels exchanged between LDP peers. It is taken from the exchanged between LDP peers. It is taken from the 0x05xx range
0x05xx range for TLVs that is used in [RFC3036] by other for TLVs that is used in [RFC3036] by other TLVs carrying label
TLVs carrying label attributes. The next available value attributes. The next available value in this range is 0x0505.
in this range is 0x0505.
In summary: In summary:
FT Protection TLV 0x0203 FT Protection TLV 0x0203
FT Session TLV 0x0503 FT Session TLV 0x0503
FT Ack TLV 0x0504 FT Ack TLV 0x0504
FT Cork TLV 0x0505 FT Cork TLV 0x0505
15.2. New Status Codes 15.2. New Status Codes
LDP status codes are not sub-divided into specific ranges LDP status codes are not sub-divided into specific ranges
for different types of error. Hence, the numeric status for different types of error. Hence, the numeric status
code values are selected as the next available. code values are selected as the next available.
Section 7.1 lists the new status codes required by this Section 7.1 lists the new status codes required by this document and
draft and gives interpretative information. The new gives interpretative information. The new codes are as follows.
codes are as follows.
Status Code E Status Data Status Code E Status Data
No LDP Session 0 0x0000001A No LDP Session 0 0x0000001A
Zero FT seqnum 1 0x0000001B Zero FT seqnum 1 0x0000001B
Unexpected TLV / 1 0x0000001C Unexpected TLV / 1 0x0000001C
Session Not FT Session Not FT
Unexpected TLV / 1 0x0000001D Unexpected TLV / 1 0x0000001D
Label Not FT Label Not FT
Missing FT Protection TLV 1 0x0000001E Missing FT Protection TLV 1 0x0000001E
skipping to change at page 52, line 19 skipping to change at page 52, line 51
[RFC2026] Bradner, S., "The Internet Standards Process -- [RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996. Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3036] Andersson, L., et. al., LDP Specification, RFC 3036, [RFC3036] Andersson, L., et. al., LDP Specification, RFC 3036,
January 2001. January 2001.
[LDP-RESTART] Leelanivas, M., et al., Graceful Restart Mechanism for [LDP-RESTART] Leelanivas, M., et al., Graceful Restart Mechanism for
LDP, draft-ietf-ldp-restart-02.txt, June 2002, work in LDP, draft-ietf-ldp-restart-05.txt, September 2002,
progress. work in progress.
17.2. Informative References 17.2. Informative References
[RFC2205] Braden, R., et al., Resource ReSerVation Protocol [RFC2205] Braden, R., et al., Resource ReSerVation Protocol
(RSVP) -- Version 1, Functional Specification, RFC (RSVP) -- Version 1, Functional Specification, RFC
2205, September 1997. 2205, September 1997.
[RFC2961] Berger, L., et al., RSVP Refresh Reduction Extensions, [RFC2961] Berger, L., et al., RSVP Refresh Reduction Extensions,
RFC 2961, April 2001. RFC 2961, April 2001.
 End of changes. 

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