Internet DRAFT - draft-hanif-rsvp-te-bfd-frr-backup-path
draft-hanif-rsvp-te-bfd-frr-backup-path
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]
