draft-katz-ward-bfd-multipoint-01.txt   draft-katz-ward-bfd-multipoint-02.txt 
Network Working Group D. Katz Network Working Group D. Katz
Internet Draft Juniper Networks Internet Draft Juniper Networks
D. Ward Intended status: Proposed Standard D. Ward
Cisco Systems Cisco Systems
Expires: July, 2008 January, 2008 Expires: August, 2009 February 5, 2009
BFD for Multipoint Networks BFD for Multipoint Networks
draft-katz-ward-bfd-multipoint-01.txt draft-katz-ward-bfd-multipoint-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
This document describes extensions to the Bidirectional Forwarding This document describes extensions to the Bidirectional Forwarding
Detection (BFD) protocol for its use in multipoint and multicast Detection (BFD) protocol for its use in multipoint and multicast
networks. Comments on this draft should be directed to rtg- networks. Comments on this draft should be directed to rtg-
bfd@ietf.org. bfd@ietf.org.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [KEYWORDS]. document are to be interpreted as described in RFC-2119 [KEYWORDS].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 Multipoint BFD Control Packets . . . . . . . . . . . . . . 6
4.2 Session Model . . . . . . . . . . . . . . . . . . . . . . 6
4.3 Session Failure Semantics . . . . . . . . . . . . . . . . 7
4.4 State Variables . . . . . . . . . . . . . . . . . . . . . 7
4.4.1 New State Variables . . . . . . . . . . . . . . . . . 7
4.4.2 State Variable Initialization and Maintenance . . . . 9
4.5 Controlling Multipoint BFD Options . . . . . . . . . . . 10
4.6 State Machine . . . . . . . . . . . . . . . . .. . . . . 10
4.7 Session Establishment . . . . . . . . . . . . . . . . . 11
4.8 Discriminators and Packet Demultiplexing . . . . . . . . 12
4.9 Controlling Tail Packet Transmission . . . . . . . . . . 12
4.10 Bringing Up and Shutting Down Multipoint BFD Service . 13
4.11 Soliciting the Tails . . . . . . . . . . . . . . . . . 14
4.12 Verifying Connectivity to Specific Tails . . . . . . . 14
4.13 Timer Manipulation . . . . . . . . . . . . . . . . . . 15
4.14 Detection Times . . . . . . . . . . . . . . . . . . . . 15
4.15 State Maintenance for Down/AdminDown Sessions . . . . . 16
4.15.1 MultipointHead Sessions . . . . . . . . . . . . . 16
4.15.2 MultipointTail Sessions . . . . . . . . . . . . . 16
4.15.3 MultipointClient Sessions . . . . . . . . . . . . 17
4.16 Base Specification Text Replacement . . . . . . . . . . 17
4.16.1 Reception of BFD Control Packets . . . . . . . . 17
4.16.2 Demultiplexing of BFD Control Packets . . . . . . 20
4.16.3 Transmitting BFD Control Packets . . . . . . . . 21
5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 25
6. Operational Scenarios . . . . . . . . . . . . . . . . . . . 25
6.1 No Head Notification . . . . . . . . . . . . . . . . . . 26
6.2 Unreliable Head Notification . . . . . . . . . . . . . . 26
6.3 Semi-reliable Head Notification and Tail Solicitation . 26
6.4 Reliable Head Notification . . . . . . . . . . . . . . . 27
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . 28
9. Normative References . . . . . . . . . . . . . . . . . . . . 28
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28
Changes from the previous draft . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
The Bidirectional Forwarding Detection protocol [BFD] specifies a The Bidirectional Forwarding Detection protocol [BFD] specifies a
method for verifying unicast connectivity between a pair of systems. method for verifying unicast connectivity between a pair of systems.
This document defines a method for using BFD to provide verification This document defines a method for using BFD to provide verification
of multipoint or multicast connectivity between a multipoint sender of multipoint or multicast connectivity between a multipoint sender
(the "head") and a set of multipoint receivers (the "tails"). (the "head") and a set of multipoint receivers (the "tails").
As multipoint transmissions are inherently unidirectional, this As multipoint transmissions are inherently unidirectional, this
mechanism purports only to verify this unidirectional connectivity. mechanism purports only to verify this unidirectional connectivity.
skipping to change at page 18, line 46 skipping to change at page 19, line 46
Else if bfd.SessionState is Init Else if bfd.SessionState is Init
If received State is Init or Up If received State is Init or Up
Set bfd.SessionState to Up Set bfd.SessionState to Up
Else (bfd.SessionState is Up) Else (bfd.SessionState is Up)
If received State is Down If received State is Down
Set bfd.LocalDiag to 3 (Neighbor signaled session down) Set bfd.LocalDiag to 3 (Neighbor signaled session down)
Set bfd.SessionState to Down Set bfd.SessionState to Down
Check to see if Demand mode should become active or not Check to see if Demand mode should become active or not (see [BFD]
(see [BFD] section 6.6). section 6.6).
If bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and If bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and
bfd.RemoteSessionState is Up, Demand mode is active on the bfd.RemoteSessionState is Up, Demand mode is active on the remote
remote system and the local system MUST cease the periodic system and the local system MUST cease the periodic transmission
transmission of BFD Control packets (see section 4.16.3.) of BFD Control packets (see section 4.16.3.)
If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or
bfd.RemoteSessionState is not Up, Demand mode is not active on the bfd.RemoteSessionState is not Up, Demand mode is not active on the
remote system and the local system MUST send periodic BFD Control remote system and the local system MUST send periodic BFD Control
packets (see section 4.16.3.) packets (see section 4.16.3.)
If the Poll (P) bit is set, and bfd.SilentTail is zero, send a BFD Control packet to the If the Poll (P) bit is set, and bfd.SilentTail is zero, send a BFD
remote system with the Poll (P) bit clear, and the Final (F) bit Control packet to the remote system with the Poll (P) bit clear,
set (see section 4.16.3.) and the Final (F) bit set (see section 4.16.3.)
If the packet was not discarded, it has been received for purposes If the packet was not discarded, it has been received for purposes
of the Detection Time expiration rules in [BFD] section 6.8.4. of the Detection Time expiration rules in [BFD] section 6.8.4.
4.16.2. Demultiplexing BFD Control Packets 4.16.2. Demultiplexing BFD Control Packets
This section is part of the replacement for [BFD] section 6.8.6, This section is part of the replacement for [BFD] section 6.8.6,
separated for clarity. separated for clarity.
If the Multipoint (M) bit is set If the Multipoint (M) bit is set
skipping to change at page 27, line 5 skipping to change at page 28, line 5
Sequence, but the state of the multipoint path will be unknown to the Sequence, but the state of the multipoint path will be unknown to the
head. The tail will continue to receive multipoint data traffic. head. The tail will continue to receive multipoint data traffic.
If the multipoint path and the reverse unicast path both stay up but If the multipoint path and the reverse unicast path both stay up but
the forward unicast path fails, neither side will notice so long as a the forward unicast path fails, neither side will notice so long as a
unicast Poll Sequence is never sent by the head. If the head sends a unicast Poll Sequence is never sent by the head. If the head sends a
unicast Poll Sequence, the head will see the BFD session fail, but unicast Poll Sequence, the head will see the BFD session fail, but
the state of the multipoint path will be unknown to the head. The the state of the multipoint path will be unknown to the head. The
tail will continue to receive multipoint data traffic. tail will continue to receive multipoint data traffic.
Contributors 7. IANA Considerations
Rahul Aggarwal of Juniper Networks and George Swallow of Cisco
Systems provided the initial idea for this specification and
contributed to its development.
Normative References
[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", This document has no actions for IANA.
draft-ietf-bfd-base-07.txt, January, 2008.
Security Considerations 8. Security Considerations
This specification does not raise any additional security issues This specification does not raise any additional security issues
beyond those of the specifications referred to in the list of beyond those of the specifications referred to in the list of
normative references. normative references.
IANA Considerations 9. Normative References
This document has no actions for IANA. [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection",
draft-ietf-bfd-base-09.txt, February, 2009.
Contributors
Rahul Aggarwal of Juniper Networks and George Swallow of Cisco
Systems provided the initial idea for this specification and
contributed to its development.
Authors' Addresses Authors' Addresses
Dave Katz Dave Katz
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, California 94089-1206 USA Sunnyvale, California 94089-1206 USA
Phone: +1-408-745-2000 Phone: +1-408-745-2000
Email: dkatz@juniper.net Email: dkatz@juniper.net
skipping to change at page 28, line 10 skipping to change at page 29, line 10
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 USA San Jose, CA 95134 USA
Phone: +1-408-526-4000 Phone: +1-408-526-4000
Email: dward@cisco.com Email: dward@cisco.com
Changes from the previous draft Changes from the previous draft
This is a reissue of the previous version. There are only minor This is a reissue of the previous version. There are only minor
editorial changes. editorial changes.
IPR Disclaimer This document expires in August, 2009.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Full Copyright Notice
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
This document expires in July, 2008.
 End of changes. 15 change blocks. 
27 lines changed or deleted 80 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/