Network Working Group IJ. Wijnands, Ed.
Internet-Draft S. Venaas
Intended status: Standards Track Cisco Systems, Inc.
Expires: December 24, 2012 M. Brig
Aegis BMD Program Office
June 22, 2012
PIM source discovery via BSR
draft-wijnands-pim-source-discovery-bsr-01
Abstract
PIM Sparse-Mode use a Rendezvous Point (RP) and shared trees to
forward multicast packets to Last Hop Routers (LHR). After the first
packet is received by the LHR, the source of the multicast stream is
learned and the Shortest Path Tree (SPT) can be joined. This draft
proposes a solution to support PIM Sparse Mode (SM) without the need
for PIM registers, RPs or shared trees. Multicast source information
is distributed via Bootstrap Router [RFC5059] messages and flooded
throughout the Multicast domain. By removing the need for RPs and
shared trees, the PIM-SM procedures are simplified, improving router
operations, management and making the protocol more robust.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 24, 2012.
Copyright Notice
Copyright (c) 2012 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
Wijnands, et al. Expires December 24, 2012 [Page 1]
Internet-Draft PIM source discovery via BSR June 2012
(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 Simplified 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, et al. Expires December 24, 2012 [Page 2]
Internet-Draft PIM source discovery via BSR June 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions used in this document . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Source to Group Mappings via BSR . . . . . . . . . . . . . . . 5
2.1. Originating SG BSR messages . . . . . . . . . . . . . . . 5
2.2. Forwarding SG BSR messages . . . . . . . . . . . . . . . . 5
2.3. Processing SG BSR messages . . . . . . . . . . . . . . . . 5
3. The first packets and bursty sources . . . . . . . . . . . . . 5
4. Resiliency to network partitioning . . . . . . . . . . . . . . 6
5. Fragmentation of BSR messages . . . . . . . . . . . . . . . . 7
6. Bootstrap Source message format . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Wijnands, et al. Expires December 24, 2012 [Page 3]
Internet-Draft PIM source discovery via BSR June 2012
1. Introduction
PIM Sparse-Mode uses a Rendezvous Point (RP) and shared trees to
forward multicast packets to Last Hop Routers (LHR). After the first
packet is received by the LHR, the source of the multicast stream is
learned and the Shortest Path Tree (SPT) can be joined. This draft
proposes a solution to support PIM Sparse Mode (SM) without the need
for PIM registers, RPs or shared trees. Multicast source information
is distributed via Bootstrap Router [RFC5059] messages and flooded
throughout the Multicast domain. By removing the need for RPs and
shared trees, the PIM-SM procedures are simplified, improving router
operations, management and making the protocol more robust.
BSR provides an infrastructure to advertise 'RP mappings' to all the
routers in the Multicast network via Reverse Path Forwaring (RPF).
This document proposes to use BSR to advertise Source Group (SG)
mappings from the First Hop Router (FHR) to all the LHRs. BSR seems
like a good fit since its already designed to distribute 'mappings'
through out the multicast network. The requirements for distributing
SG mappings seems very close to RP mappings, for that reason there
seems no need to invent a new protocol.
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
RP: Rendezvous Point.
BSR: Bootstrap Router.
RPF: Reverse Path Forwarding
SPT: Shortest Path Tree.
FHR: First Hop Router, directly connected to the Source.
LHR: Last Hop Router, directly connected to the receiver.
SG Mapping: Multicast source to group mapping.
SG BSR message: A BSR message containing a source to group mapping.
Wijnands, et al. Expires December 24, 2012 [Page 4]
Internet-Draft PIM source discovery via BSR June 2012
2. Source to Group Mappings via BSR
A Candidate Bootstrap (C-BSR) router is typically a router which is
configured to be a BSR. Multiple C-BSR may be configured in the
network and an election procedure is applied to select the Elected
BSR (E-BSR) router. The E-BSR router is the router that is
responsible for distributing the Group to RP mappings. See [RFC5059]
section 3.1 for more details. In order to distribute Source to Group
(SG) mappings, there is no need to elect an E-BSR router.
2.1. Originating SG BSR messages
Each FHR that is directly connected to an active multicast source
becomes the E-BSR for that SG mapping. How a multicast router
discovers the source of the multicast packet and when it considers it
self the FHR follows the same procedures as the registering process
described in [RFC4601]. After it is decided that a register needs to
be sent, the SG is not registered via the PIM SM register procedures,
but the SG mapping is distributed via a BSR message. Note, only the
SG mapping is distributed in the BSR message, not the entire packet
as would have been done with a PIM register. The router originating
the BSR messages includes its own address in the BSR message. The
BSR messages are periodically sent for as long as the multicast
source is active, similar to how PIM registers are periodically sent.
The timer and timeout values described in [RFC5059] apply here as
well.
2.2. Forwarding SG BSR messages
The forwarding of BSR messages follows the same procedures as
documented in [RFC5059] section 3.4 and 3.5.
2.3. Processing SG BSR messages
A router that receives a SG BSR messages should parse the SG BSR
message and store the SG mappings with a holdtimer started with the
advertised holdtime for that group. If there are directly connected
receivers for that group this router should send PIM (S,G) joins for
all the SG mappings advertised in the BSR message. The SG BSR
mappings is kept alive for as long as the holdtimer for the source is
running. Once the holdtimer expired a PIM (S,G) prune must be sent
to remove itself from the tree.
3. The first packets and bursty sources
The PIM register procedure is designed to deliver Multicast packets
to the RP in the absence of a native SPT tree from the RP to the
Wijnands, et al. Expires December 24, 2012 [Page 5]
Internet-Draft PIM source discovery via BSR June 2012
source. The register packets received on the RP are decapsulated and
forwarded down the shared tree to the LHRs. As soon as an SPT tree
is built, multicast packets would flow natively over the SPT to the
RP or LHR and the register process would stop. The PIM register
process bridges the gap between how long it takes to build the SPT
tree to the FHR. If the packets would not be unicast encapsulated to
the RP they would be dropped by the FHR until the SPT is setup. This
functionality is important for applications where the first packet(s)
must be received for the application to work correctly. An other
reason would be for bursty sources. If the application sends out a
multicast packet every 4 minutes (or longer), the SPT is torn down
(typically after 3:30 minutes of inactivity) before the next packet
is forwarded down the tree. This will cause no multicast packet to
ever be forwarded. A well behaved application should really be able
to deal with packet loss since IP is a best effort based packet
delivery system. But in reality this is not always the case.
With the procedures proposed in this draft the packet(s) received by
the FHR will be dropped until the LHR has learned about the source
and the SPT tree is built. That means for bursty sources or
applications sensitive for the delivery of the first packet this
proposal would not be very applicable. This proposal is mostly
useful for applications that don't have strong dependency on the
first packet(s) and have a constant data rate, like video
distribution for example. For applications with strong dependency on
the first packet(s) we recommend using PIM Bidir [RFC5015] or SSM
[RFC4607]. The protocol operations are much simpler compared to PIM
SM, it will cause less churn in the network and both guarantee best
effort delivery for the first packet(s).
An other solution to address the problems described above is
documented in [I-D.ietf-magma-msnip]. This proposal allows for a
host to tell the FHR its willingness to act as Source for a certain
Group before sending the data packets. LHRs have time to join the
SPT tree before the host starts sending which would avoid packet
loss. The SG mappings announced by [I-D.ietf-magma-msnip] can be
advertised directly into BSR, allowing a very nice integration of
both proposals. The life time of the SPT is not driven by the
liveliness of Multicast data packets (which is the case with PIM SM),
but by the announcements driven via [I-D.ietf-magma-msnip]. This
will also prevent packet loss due to bursty sources.
4. Resiliency to network partitioning
In a PIM SM deployment where the network becomes partitioned, due to
link or node failure, it is possible that the RP becomes unreachable
to a certain part of the network. New sources that become active in
Wijnands, et al. Expires December 24, 2012 [Page 6]
Internet-Draft PIM source discovery via BSR June 2012
that partition will not be able to register to the RP and receivers
within that partition are not able to receive the traffic. Ideally
you would want to have a candidate RP in each partition, but you
never know in advance which routers will form a partitioned network.
In order to be fully resilient, each router in the network may end up
being a candidate RP. This would increase the operational complexity
of the network.
The solution described in this document does not suffer from that
problem. If a network becomes partitioned and new sources become
active, the receivers in that partitioned will receive the BSR SG
Mappings and join the source tree. Each partition works
independently of the other partition(s) and will continue to have
access to sources within that partition. As soon as the network
heals, the SG Mappings are re-flooded into the other partition(s) and
other receives can join to the newly learned sources.
5. Fragmentation of BSR messages
[RFC5059] defines procedures to fragment BSR messages if the number
of group to RP mappings is too large and the packet exceeds the MTU
size. Its important for PIM to have all the RP mappings before it
applies the selection process. Missing mappings may cause the wrong
RP to be selected. Using BSR to distribute SG mappings we don't have
this problem. There is no reason to have all the source before
joining the tree. There is no selection process applied to the SG
mappings, all the known SG mappings should be joined by PIM. For
that reason there is no special fragmentation support defined for SG
mappings.
6. Bootstrap Source message format
Wijnands, et al. Expires December 24, 2012 [Page 7]
Internet-Draft PIM source discovery via BSR June 2012
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type |N| Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FHR Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address 1 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Count | Src Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address 1 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address 2 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address m (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address 2 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Count | Src Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address 1 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address 2 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address m (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address n (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Count | Src Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address 1 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address 2 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address m (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Wijnands, et al. Expires December 24, 2012 [Page 8]
Internet-Draft PIM source discovery via BSR June 2012
PIM Version: Reserved, Checksum Described in [RFC4601].
Type: PIM Message Type. Value (pending IANA) for a Bootstrap
Source message
[N]o-Forward bit: When set, this bit means that the Bootstrap
message fragment is not to be forwarded.
FHR Address: The address of the FHR router for the domain. This
can be any address assigned to this router, but MUST be routable
in the domain to allow successful forwarding (just like BSR
address). The format for this address is given in the Encoded-
Unicast address in [RFC4601].
Group Address 1..n: The address of the bootstrap router for the
domain. The format for this address is given in the Encoded-
Unicast address in [RFC4601].
Src Count How many unicast encoded sources address encodings follow.
Src Holdtime: The Holdtime (in seconds) for the corresponding
source(s).
Src Address: The source address for the corresponding group range.
The format for these addresses is given in the Encoded-Unicast
address in [RFC4601].
7. Security Considerations
The security considerations are no different from what is documented
in [RFC5059].
8. IANA considerations
This document requires the assignment of a new code point from the
IANA managed registry "PIM Message Types" called "Bootstrap Source
Mapping".
Wijnands, et al. Expires December 24, 2012 [Page 9]
Internet-Draft PIM source discovery via BSR June 2012
9. Acknowledgments
The authors would like to thank Arjen Boers for contributing to the
initial idea and Yiqun Cai for his comments on the draft.
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.
[RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
"Bootstrap Router (BSR) Mechanism for Protocol Independent
Multicast (PIM)", RFC 5059, January 2008.
10.2. Informative References
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007.
[I-D.ietf-magma-msnip]
Fenner, B., Haberman, B., Holbrook, H., Kouvelas, I., and
S. Venaas, "Multicast Source Notification of Interest
Protocol (MSNIP)", draft-ietf-magma-msnip-06 (work in
progress), March 2011.
Authors' Addresses
IJsbrand Wijnands (editor)
Cisco Systems, Inc.
De kleetlaan 6a
Diegem 1831
Belgium
Email: ice@cisco.com
Wijnands, et al. Expires December 24, 2012 [Page 10]
Internet-Draft PIM source discovery via BSR June 2012
Stig Venaas
Cisco Systems, Inc.
Tasman Drive
San Jose CA 95134
USA
Email: stig@cisco.com
Michael Brig
Aegis BMD Program Office
17211 Avenue D, Suite 160
Dahlgren VA 22448-5148
USA
Email: michael.brig@mda.mil
Wijnands, et al. Expires December 24, 2012 [Page 11]