Network Working Group IJ. Wijnands, Ed.
Internet-Draft Y. Cai
Intended status: Standards Track Cisco Systems, Inc.
Expires: August 12, 2011 February 8, 2011
PIM neighbor reduction for transit LAN's.
draft-wijnands-pim-neighbor-reduction-02
Abstract
PIM establishes a neighbor relationship with other routers directly
connected to it on startup. Networks that are LANs or behave like a
LAN, potentially create many PIM neighbors depending on how many
routers are attached to it. If such a LAN is also a transit network
(no directly connected source or receiver), many of the PIM
procedures don't apply. This proposal describes a procedure to
reduce the amount of neighbors established over a transit LAN.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 August 12, 2011.
Copyright Notice
Copyright (c) 2011 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
Wijnands & Cai Expires August 12, 2011 [Page 1]
Internet-Draft PIM neighbor reduction for transit LAN's February 2011
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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
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.
Wijnands & Cai Expires August 12, 2011 [Page 2]
Internet-Draft PIM neighbor reduction for transit LAN's February 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Reducing the number of PIM neighbors . . . . . . . . . . . . . 3
3. Bidir support . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Generation ID Hello option . . . . . . . . . . . . . . . . . . 4
5. Hello suppression and options . . . . . . . . . . . . . . . . . 5
5.1. PIM suppress Hello option . . . . . . . . . . . . . . . . . 5
5.2. Backwards compatibility . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Contributing authors . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Wijnands & Cai Expires August 12, 2011 [Page 3]
Internet-Draft PIM neighbor reduction for transit LAN's February 2011
1. Introduction
PIM sends hello messages to discover other PIM enabled routers that
are directly connected on a particular interface and form a PIM
neighbor relationship with them. Various PIM procedures depend on
having a PIM neighbor elected as Designated Router (DR), like for PIM
register messages [RFC4601] and processing IGMP reports [RFC4604].
Most of these procedures are specific to either directly connected
receivers or senders and do not apply to transit networks. Networks
that are LANs or behave like a LAN (Mi-PMSI)
[I-D.ietf-l3vpn-2547bis-mcast] create as many PIM neighbors as there
are PIM enabled routers directly connected to that LAN. For networks
where the sources and/or RPs are only in few locations, which is a
very typical deployment, it's very likely that many of these PIM
neighbors are never used as a target in any PIM J/P message.
Combined with the fact that on transit networks there are no directly
connected receivers or senders, having a PIM neighbor relationship
with all the PIM routers over a transit LAN network seems
unnecessary. It is however still useful to have a PIM neighbor
relationship with PIM routers that are used as target in the PIM Join
or Prune (J/P) messages. We'll discuss these later in this draft.
The proposal is to not form unessesary PIM neighbor relations by
creating PIM neighbors dynamically on demand. Only PIM routers
forwarding multicast data or on the path to the RP will be seen as a
PIM neighbor. Other PIM routers on that LAN that act as receivers
will stay passive and not form neighbor relationships. This will
significantly reduce the number of PIM neighbors established over a
LAN network where there are more passive receivers than there are
senders. Networks that have directly connected senders and/or
receivers are outside the scope of this draft.
1.1. Conventions used in this document
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].
1.2. Terminology
2. Reducing the number of PIM neighbors
PIM uses a unicast RIB to lookup the path to an upstream router for a
particular Source or Rendezvous-Point (RP) [RFC4601]. The result of
that lookup provides a directly connected next-hop that is used as
the target in a PIM J/P message. [RFC4601] currently states that
this next-hop also needs to be a PIM neighbor in order to send a PIM
Wijnands & Cai Expires August 12, 2011 [Page 4]
Internet-Draft PIM neighbor reduction for transit LAN's February 2011
J/P to it. However, whether you're not sending a PIM message because
it is not a PIM neighbor or this upstream router is unable to parse
the join, functionally does not make a big difference. The multicast
tree can't be formed and traffic is interrupted. This draft proposes
to send a PIM J/P to a target upstream router even if it is not a PIM
neighbor. We also propose that a router accepts the PIM J/P and
processes it as if it was received from a PIM neighbor. In most
multicast deployments it is very likely that a next-hop for a source
and an RP is also a PIM enabled router, so this is not considered to
be a big issue. However, we do want to form a one-way PIM neighbor
relationship with the target upstream router.
If a PIM router has a desire to send a PIM J/P to a non-PIM neighbor
U, we propose to take one bit out of the PIM Join/Prune header
'Reserved' range and set it to 1 before we send the J/P packet. We
call this bit the 'Hello Request' bit. A router that receives a PIM
J/P with the 'Hello Request' bit on, sends a PIM hello out over the
interface the PIM J/P was received on. The other routers on the LAN
will receive the PIM hello and MAY form a one-way PIM neighbor
relationship with U. A router that receives the Hello from U and has
no interest in it MAY ignore the Hello to limit the amount of
neighbor state. In the next PIM J/P the 'Hello Request' bit will be
off because the PIM neighbor is known by the router sending the Join.
Router U will continue to send periodic PIM Hello's out the interface
as long as there is at least one downstream router joined over that
interface for either a (*,G) or (S,G) state.
3. Bidir support
The support for PIM Bidir [RFC5015] on a LAN depends on the election
of the Designated Forwarder (DF). The DF election mechanism has a
few dependencies on PIM neighbors. [RFC5015] section 3.5.5 also
describes a PIM Hello dependency on the DF election. For that reason
routers that are bidir capable and a Candidate DF will send out a PIM
Hello over that LAN. A PIM neighbor relationship will be established
among the candidate DF routers. Note that a candidate DF router on a
LAN is a router that has an RPF interface towards the RPA that is NOT
on that same LAN. Please see [RFC5015] section 2.1 and 3.5.2 for
details. It is expected that there are few Candidate DF routers and
it's very likely these routers are already on the path to the RPA for
the Sparse-Mode groups. We don't expect this procedure to add to the
number of PIM neighbors that is etablished over that LAN.
4. Generation ID Hello option
PIM routers may use the generation ID in a PIM hello to make
Wijnands & Cai Expires August 12, 2011 [Page 5]
Internet-Draft PIM neighbor reduction for transit LAN's February 2011
downstream router trigger PIM J/P's to it. This feature is used for
upstream router High Avalability (HA) and when a router or interface
becomes active. Using this feature there is no need to wait for the
next periodic PIM J/P interval to (re)populate the forwarding state
on the upstream router. If a Router or LAN becomes active, it is
allowed to send a PIM hello on that LAN interface to speed up
convergence, but it SHOULD not continue to send hello's periodically.
Note, it's up to the downstream router(s) to either respond to this
PIM Hello or ignore it if there is no interest in this PIM neighbor.
5. Hello suppression and options
PIM includes options in its Hello packets. We can group these
options in two categories, options that are significant per neighbor
or per LAN. For example, the GenID option is significant to the
neighbor originating it, the Bidir option is significant to the LAN.
Options that are significant per neighbor are learned as soon as a
node has any interest that the neighbor. For these we don't need any
special procedures. However, options relevant to the LAN, like Bidir
capable or DR priority may not be learned because nodes on the LAN
may suppress their Hello's using the procedures described in this
draft. Its not important to know which nodes on the LAN support it
or not, is good enough to know that at least one node does not
support it. In order to discover the LAN specific options without
creating PIM hello neighbor relationship between all the nodes we
introduce the procedure below.
5.1. PIM suppress Hello option
We introduce a new PIM hello option called the PIM suppress option
that is included in Hello's sent on the LAN. A PIM node on the LAN
that receives this option in the PIM Hello (and supports it) will
suppress its Hello if the set of included options match the options
of this node. If this node has no interest in the sender of the
Hello, no PIM neighbor relationship is created. The option set that
this PIM neighbor advertised will be stored with an expire timer set
to the advertised PIM hello holdtime. If this option set did already
exist, only the option set expire timer is updated. The PIM hello
periodic interval timer is started at the PIM hello interval time
plus a random delay between 0 and 3 seconds. After the timer expires
a PIM Hello is originated, unless a PIM Hello with the same set of
options was received before the timer expired. This is similar to
how PIM Join suppression works. With these procedures we are
suppressing PIM hello's that share the same option set. Its likely
that the PIM nodes on the LAN have the same option set, or at least
have a limited set of option combinations. Below is the proposed PIM
Hello suppress option encoding;
Wijnands & Cai Expires August 12, 2011 [Page 6]
Internet-Draft PIM neighbor reduction for transit LAN's February 2011
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TDB | Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type indicates PIM Hello suppression is supported.
5.2. Backwards compatibility
PIM nodes on the LAN that don't understand the suppress capability
will obviously not suppress their Hello. They will just ignore the
capability and create a PIM neighbor relation with the sender. This
node does not expect other nodes to suppress their Hello so will
assume that an upstream neighbor is not enabled with PIM. This may
prevent PIM from sending PIM Join/Prunes. How this situation should
be handled depends on the PIM implementation. Some implementations
deployed in the field already ignore PIM neighbors for sending PIM
Join/Prunes. For these implementations no special procedures are
needed. Implementations that depend on PIM neighbors may only apply
Hello suppression if all the PIM nodes on that LAN support the PIM
suppress option. We propose the following two options to be
supported;
As soon as one PIM node on the LAN does not support the suppress
option all routers on the LAN will default back to sending
periodic PIM hello's. Routers on the LAN continue to include the
suppress option. As soon as all the routers on the LAN support
the suppress option, PIM Hello suppression will be activated.
PIM hello suppression is always one and will not fall back to
sending periodic PIM hello's.
6. Security Considerations
For securing PIM J/P messages please see the security section in
[RFC4601].
7. IANA considerations
This document requests the reservation of a bit from the PIM Join/
Prune header reserved field. This bit field is called 'Hello
Request' bit.
Wijnands & Cai Expires August 12, 2011 [Page 7]
Internet-Draft PIM neighbor reduction for transit LAN's February 2011
8. Acknowledgments
Thanks to Stig Venaas, Eric Rosen and Maria Napierala for their
comments on the draft.
9. Contributing authors
Below is a list of the contributing authors in alphabetical order:
Yiqun Cai
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA, 95134
USA
E-mail: ycai@cisco.com
IJsbrand Wijnands
Cisco Systems, Inc.
De kleetlaan 6a
1831 Diegem
Belgium
E-mail: ice@cisco.com
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, August 2006.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007.
[RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol
Independent Multicast (PIM) Join Attribute Format",
Wijnands & Cai Expires August 12, 2011 [Page 8]
Internet-Draft PIM neighbor reduction for transit LAN's February 2011
RFC 5384, November 2008.
10.2. Informative References
[I-D.ietf-l3vpn-2547bis-mcast]
Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y.,
Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in
MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work
in progress), January 2010.
Authors' Addresses
IJsbrand Wijnands (editor)
Cisco Systems, Inc.
De kleetlaan 6a
Diegem 1831
Belgium
Email: ice@cisco.com
Yiqun Cai
Cisco Systems, Inc.
170 Tasman Drive
San Jose CA, 95134
USA
Email: ycai@cisco.com
Wijnands & Cai Expires August 12, 2011 [Page 9]