Network Working Group T. Morin
Internet-Draft France Telecom - Orange Labs
Intended status: Standards Track November 3, 2008
Expires: May 7, 2009
Fast Hello exchange procedures for Protocol Independent Multicast
draft-morin-pim-fast-hello-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
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
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 May 7, 2009.
Abstract
This document is proposed as an update of RFC4601 and describes
procedures allowing exchanges of PIM Hellos to complete earlier when
a new link comes up, to mitigate the multicast traffic blackholing
issues that result from inconsistencies between links advertised by
unicast routing and the links on which PIM adjacencies are fully set
up.
Requirements Language
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 [RFC2119].
Morin Expires May 7, 2009 [Page 1]
Internet-Draft PIM Fast Hello exchange November 2008
1. Introduction
PIM-SM specifications [RFC4601] section 4.3.1 implies that :
o when a link comes up, a Hello message is sent by a router after a
random delay in the [0,Triggered_Hello_Delay] range
(Triggered_Hello_Delay being 5s by default), or at once if there
are Join messages that need to be send on this link ;
o and that on reception of a Hello from a new neighbor a router will
send a Hello after a random delay in the same range.
With these procedures, there is a risk of having a link be considered
up by unicast routing before PIM Join/Prune messages can be exchanged
on this link. In this case, the nodes that are downstream to such a
link may update their RPF and send Join messages in the direction of
the new link, before the node adjacent to the new link is ready to
send the Join on that link. The result is a temporary blackholing of
multicast traffic which can persist for at least up to
Triggered_Hello_Delay.
The procedures and timers defined in [RFC4601] are conservative and
meant to avoid storms of Hello messages on multiaccess links. This
document propose more aggressive timers for point-to-point links, new
procedures for fast hello exchanges on multiaccess links, and propose
corresponding adjustments related to when Join messages are sent
after a link comes up.
2. Hello exchange on a point-to-point link
If a link is known to be a point-to-point link (e.g. based on the
underlying link layer in use, or based on local configuration), then
a router SHOULD set the Triggered_hello_delay to zero on this link.
The result is that, on a point-to-point link:
o on reception of a Hello from a new neighbor, a router will send a
Hello at once
o even in the absence of any Join/Prune/Assert message that would
need to be sent, a router will send a Hello at once
3. Hello exchange on a multiaccess link
The goal is to allow a faster exchange of Hello messages, while
preserving the behavior of REF in that the risk of overloading the
Morin Expires May 7, 2009 [Page 2]
Internet-Draft PIM Fast Hello exchange November 2008
router control plane with processing of a large amount of Hello
message in a short period. Without introducing random delays before
Hello are sent, when a multiaccess link comes up there would be a
possibility to have all routers send a Hello at the same time, then
resulting all routers replying at the same time (2*n messages in a
very short time).
The proposed modifications to RFC4601 are that:
o implementations SHOULD provide a tuning knob to change the value
of Triggered_Hello_Delay on an interface -- this allows the
operator to choose a timer value lower than the current default,
when the number of routers on the link is such that the effects of
a surge of PIM Hello messages are considered reasonable
o implementations SHOULD implement the following "unicast Hello"
procedures:
* when a Join/Prune/Assert message needs to be sent to a router
that is not already a PIM neighbor, the router MAY send a Hello
message at once, using unicast toward the neighbor ; the timer
for sending a normal PIM Hello based on RFC164601 procedures is
preserved
* when a unicast Hello is received from a router that is not
already a PIM neighbor , the router MUST send at once a Hello,
using unicast to the sender of the Hello ; the timer for
sending a normal PIM Hello based on RFC164601 procedures is
preserved
4. Sending Joins
Current PIM specifications [RFC4601] indicate that a router that need
to send a Join, Prune or Assert message to a neighbor will send a
Hello message at once, but it is not indicated if it should wait for
reception of a Hello from that router before sending the said Join
messages. It is also indicated that Join messages should not be sent
to a router from which no PIM Hello has been received yet, so
implicitly the interpretation is that the router should wait.
Current PIM specifications [RFC4601] also indicate that "[a router]
will not accept Join/Prune or Assert messages from a router unless
they have first heard a Hello message from that router".
However, widespread implementations do not enforce these
verifications and allow sending Join/Prune/Assert to (and process
Join/Prune/Assert to) router from which no Hello has been received
Morin Expires May 7, 2009 [Page 3]
Internet-Draft PIM Fast Hello exchange November 2008
yet, providing as a result a form of mitigation of blackholing
issues.
The following rules are proposed to make explicit the rules on how
messages are sent right after a link comes up.
When Prune/Join/Assert messages need to be sent on a point-to-point
link to a router from which a Hello message has not been sent yet
(call it router A):
o a Hello message is sent at once, and a timer T is set to a low
value (e.g. 100ms, the same value as the Prune override delay can
be used)
o the messages are queued, and sent on the link when the first of
these two events occur:
* a Hello is received from A
* T expires
o if messages were sent because T expired, the timers associated to
the states corresponding to the messages should be set so that
these messages will be repeated at once when, eventually, a Hello
message is received from A
5. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
6. Security Considerations
7. Acknowledgements
Acknowledgments goes to Bill Fenner, Mark Handley and Dino Farinacci,
with whom these proposals were extensively discussed and who
suggested some key ideas.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Morin Expires May 7, 2009 [Page 4]
Internet-Draft PIM Fast Hello exchange November 2008
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
Author's Address
Thomas Morin
France Telecom - Orange Labs
2, avenue Pierre Marzin
Lannion 22307
France
Email: thomas.morin@orange-ftgroup.com
Morin Expires May 7, 2009 [Page 5]
Internet-Draft PIM Fast Hello exchange November 2008
Full Copyright Statement
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.
Intellectual Property
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.
Morin Expires May 7, 2009 [Page 6]