Networking Working Group M. Hanif Internet Draft L. Nguyen Brocade Communications Systems, Inc. Intended status: Standards Track July 6, 2009 Expires: January 2010 Signaling BFD configuration for a backup path in an FRR environment draft-hanif-rsvp-te-bfd-frr-backup-path-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 6, 2009. Expires January 6, 2010 [Page 1] Internet-Draft draft-hanif-rsvp-te-bfd-frr-backup-path-00.txt Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Today there is no support in the RSVP protocol to dynamically signal the enabling and configuring of the BFD (Bi-directional Forwarding Detection) on a backup path. This document introduces a new RSVP object called "FRR backup BFD object". The procedures described in this document are only applicable to Fast Reroute LSPs [RFC4090]. Table of Contents 1. Introduction...................................................2 2. FRR Backup BFD Object..........................................3 3. RSVP-TE Protocol Operation.....................................4 4. Conventions used in this document..............................4 5. Security Considerations........................................5 6. IANA Considerations............................................5 7. References.....................................................5 7.1. Normative References......................................5 7.2. Informative References....................................5 8. Acknowledgments................................................6 1. Introduction This document proposes a new RSVP object called "FRR backup BFD object". This object is carried in the RSVP PATH message [RFC2205] to establish an MPLS LSP tunnel. This new object carries information to enable and configure the BFD for Fast Reroute (FRR) backup tunnels on the transit LSRs, which are also called Point of Local Repair (PLR). The procedures described in this document are only applicable to Fast Reroute LSPs [RFC4090]. When a Fast Reroute LSP is signaled using RSVP, its associated backup path configuration information is carried in the Fast Reroute object [RFC4090]. Each Transit PLR uses this information to establish the backup path that protects the protected path. The Fast Reroute Expires January 6, 2010 [Page 2] Internet-Draft draft-hanif-rsvp-te-bfd-frr-backup-path-00.txt object does not carry any configuration information to establish the BFD for MPLS LSPs [BFDMPLS] for backup path LSPs. In order to signal the BFD configuration information for the Fast Reroute backup LSPs, a new RSVP object called FRR backup BFD object has been suggested. 2. FRR Backup BFD Object The new RSVP FRR_BACKUP_BFD object will have the following form: 0 1 2 3 +-------------+-------------+-------------+-------------+ | Length (bytes) | Class-Num | C-Type | +-------------+-------------+-------------+-------------+ | BFD Detection Time Multiplier | +-------------+-------------+-------------+-------------+ | BFD Desired Min TX interval (usec) | +-------------+-------------+-------------+-------------+ | BFD Desired Min RX Interval (usec ) | +-------------+-------------+-------------+-------------+ An optional Authentication Section may be present: +-------------+-------------+-------------+-------------+ |Auth Type | Auth Len | Authentication Data ... | +-------------+-------------+-------------+-------------+ Length Length of the TLV in bytes. Class-Num To be assigned by IANA (Internet Assigned Numbers Authority) [ENT]. C-Type 1 Detection Time Multiplier Number of consecutive BFD control packets to be missed before declaring the BFD session down on a backup path. Desired Min TX interval: Minimum transmit interval (in microseconds) for BFD control packets on a backup path. Desired Min RX Interval: Expires January 6, 2010 [Page 3] Internet-Draft draft-hanif-rsvp-te-bfd-frr-backup-path-00.txt Minimum receive interval (in microseconds) for BFD control packets on a backup path. Authentication Type, Authentication Len, and Authentication Data are as described in draft-ietf-bfd-base-09.txt [BFD]. 3. RSVP-TE Protocol Operation When the BFD configuration is desired on a backup path of the Fast Reroute LSP, the ingress LSR MUST include the FRR BACKUP BFD object in the RSVP PATH message. The following lists the suggested operation an LSR should implement when processing the FRR BACKUP BFD object. 1. The presence of a FRR_BACKUP BFD object in a PATH message allows enabling and configuring BFD dynamically on a backup path on any PLR. A PLR is either ingress or a transit node in an FRR protected path. 2. A PLR should enable the BFD on a backup path when it first detects the FRR backup BFD object in the PATH message. 3. The changes in the FRR_BACKUP_BFD object in subsequent PATH messages will be reflected to the configuration accordingly. 4. The absence of the FRR_BACKUP_BFD object (after it had been detected once) will indicate disabling of the BFD on an FRR backup path. The receiving LSR MUST then disable the BFD on its respective backup path. 5. The FRR_BACKUP_BFD object MUST be ignored if local protection is not enabled on an RSVP LSP. 6. The local protection can be of any form (either one-to-one or facility backup) The FRR_BACKUP_BFD object facilitates the BFD configuration on a dynamically established backup path. 7. FRR_BACKUP_BFD object should be ignored by the receiving LSR if it does not support it. However, the LSR MUST forward this object unchanged to the next downstream LSR. 4. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. Expires January 6, 2010 [Page 4] Internet-Draft draft-hanif-rsvp-te-bfd-frr-backup-path-00.txt The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. 5. Security Considerations This document does not introduce any new security issues above those identified in [RFC3209] and [RFC4090]. 6. IANA Considerations This document introduces a new RSVP object to be carried in an RSVP PATH message. The object class number "Class-Num" needs to assigned by IANA. 7. References 7.1. Normative References [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", draft-ietf-bfd-base-09.txt, February, 2009. [BFDMPLS] Aggarwal, R., Kompella, K., Nadeau, T., Swallow, G., "BFD For MPLS LSPs", draft-ietf-bfd-mpls-07.txt, June 2008. [ENT] IANA PRIVATE ENTERPRISE NUMBERS, http://www.iana.org/assignments/enterprise-numbers. Expires January 6, 2010 [Page 5] Internet-Draft draft-hanif-rsvp-te-bfd-frr-backup-path-00.txt 8. Acknowledgments The authors would like to thank Norival Figueira for his help in reviewing this draft. This document was prepared using 2-Word-v2.0.template.dot. Expires January 6, 2010 [Page 6] Internet-Draft draft-hanif-rsvp-te-bfd-frr-backup-path-00.txt Authors' Addresses Mohammad Hanif Brocade Communications Systems, Inc. 4980 Great America Parkway Santa Clara, CA 95054 Email: mhanif@brocade.com Lisa Nguyen Brocade Communications Systems, Inc. 4980 Great America Parkway Santa Clara, CA 95054 Email: lisan@brocade.com Expires January 6, 2010 [Page 7]