draft-ietf-pim-group-rp-mapping-03.txt   draft-ietf-pim-group-rp-mapping-04.txt 
PIM Working Group B. Joshi PIM Working Group B. Joshi
Internet-Draft Infosys Technologies Ltd. Internet-Draft Infosys Technologies Ltd.
Expires: August 14, 2010 A. Kessler Expires: October 28, 2010 A. Kessler
Cisco Systems, Inc. Cisco Systems, Inc.
D. McWalter D. McWalter
Metaswitch Networks Metaswitch Networks
February 10, 2010 April 26, 2010
PIM Group-to-RP Mapping PIM Group-to-RP Mapping
draft-ietf-pim-group-rp-mapping-03.txt draft-ietf-pim-group-rp-mapping-04.txt
Abstract
Each PIM-SM router in a PIM Domain which supports ASM maintains
Group-to-RP mappings which are used to identify a RP for a specific
multicast group. PIM-SM has defined an algorithm to choose a RP from
the Group-to-RP mappings learned using various mechanisms. This
algorithm does not consider the PIM mode and the mechanism through
which a Group-to-RP mapping was learned.
This document defines a standard algorithm to deterministically
choose between several group-to-rp mappings for a specific group.
This document first explains the requirements to extend the
Group-to-RP mapping algorithm and then proposes the new algorithm.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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 Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
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 This Internet-Draft will expire on October 28, 2010.
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 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract
Each PIM-SM router in a PIM Domain which supports ASM maintains
Group-to-RP mappings which are used to identify a RP for a specific
multicast group. PIM-SM has defined an algorithm to choose a RP from
the Group-to-RP mappings learned using various mechanisms. This
algorithm does not consider the PIM mode and the mechanism through
which a Group-to-RP mapping was learned.
This document defines a standard algorithm to deterministically
choose between several group-to-rp mappings for a specific group.
This document first explains the requirements to extend the
Group-to-RP mapping algorithm and then proposes the new algorithm.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Existing algorithm . . . . . . . . . . . . . . . . . . . . . . 5 3. Existing algorithm . . . . . . . . . . . . . . . . . . . . . . 5
4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Common use cases . . . . . . . . . . . . . . . . . . . . . . . 7 5. Common use cases . . . . . . . . . . . . . . . . . . . . . . . 7
6. Proposed algorithm . . . . . . . . . . . . . . . . . . . . . . 8 6. Proposed algorithm . . . . . . . . . . . . . . . . . . . . . . 8
7. Deprecation of MIB Objects . . . . . . . . . . . . . . . . . . 10 7. Deprecation of MIB Objects . . . . . . . . . . . . . . . . . . 10
8. Clarification for MIB Objects . . . . . . . . . . . . . . . . 11 8. Clarification for MIB Objects . . . . . . . . . . . . . . . . 11
9. Use of dynamic group-to-rp mapping protocols . . . . . . . . . 12 9. Use of dynamic group-to-rp mapping protocols . . . . . . . . . 12
10. Filtering Group-to-RP mappings at domain boundaries . . . . . 13 10. Consideration for Bidirectional-PIM and BSR hash . . . . . . . 13
11. Security Consideration . . . . . . . . . . . . . . . . . . . . 14 11. Filtering Group-to-RP mappings at domain boundaries . . . . . 14
12. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 15 12. Security Consideration . . . . . . . . . . . . . . . . . . . . 15
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 13. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 16
14. Normative References . . . . . . . . . . . . . . . . . . . . . 17 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 15. Normative References . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Multiple mechanisms exist today to create and distribute Group-to-RP Multiple mechanisms exist today to create and distribute Group-to-RP
mappings. Each PIM-SM router may learn Group-to-RP mappings through mappings. Each PIM-SM router may learn Group-to-RP mappings through
various mechanisms. various mechanisms.
It is critical that each router select the same 'RP' for a specific It is critical that each router select the same 'RP' for a specific
multicast group address. This is even true in the case of Anycast RP multicast group address. This is even true in the case of Anycast RP
for redundancy. This RP address may correspond to a different for redundancy. This RP address may correspond to a different
physical router but it is one logical RP address and must be physical router but it is one logical RP address and must be
consistent across the PIM domain. This is usually achieved by using consistent across the PIM domain. This is usually achieved by using
the same algorithm to select the RP in all the PIM routers in a the same algorithm to select the RP in all the PIM routers in a
domain. domain.
PIM-SM[RFC4601] has defined an algorithm to select a 'RP' for a given PIM-SM [RFC4601] has defined an algorithm to select a 'RP' for a
multicast group address but it is not flexible enough for an given multicast group address but it is not flexible enough for an
administrator to apply various policies. Please refer to section 3 administrator to apply various policies. Please refer to section 3
for more details. for more details.
PIM-STD-MIB [RFC5060] has defined an algorithm that allows PIM-STD-MIB [RFC5060] has defined an algorithm that allows
administrators to override Group-to-RP mappings with static administrators to override Group-to-RP mappings with static
configuration. But this algorithm is not completely deterministic, configuration. But this algorithm is not completely deterministic,
because it includes an implementation-specific 'precedence' value. because it includes an implementation-specific 'precedence' value.
Embedded-RP as defined in section-7.1 of Embedded-RP address in IPv6 Embedded-RP as defined in section-7.1 of Embedded-RP address in IPv6
Multicast address [RFC3956], mentions that to avoid loops and Multicast address [RFC3956], mentions that to avoid loops and
skipping to change at page 13, line 5 skipping to change at page 13, line 5
needed to deterministically resolve the situation. The algorithm in needed to deterministically resolve the situation. The algorithm in
this document MUST be used. This can be important at domain border this document MUST be used. This can be important at domain border
routers, and is likely to improve stability under misconfiguration routers, and is likely to improve stability under misconfiguration
and when configuration is changing. and when configuration is changing.
An implementation of PIM that supports only one mechanism for An implementation of PIM that supports only one mechanism for
learning Group-to-RP mappings SHOULD also use this algorithm. The learning Group-to-RP mappings SHOULD also use this algorithm. The
algorithm has been chosen so that existing standard implementations algorithm has been chosen so that existing standard implementations
are already compliant. are already compliant.
10. Filtering Group-to-RP mappings at domain boundaries 10. Consideration for Bidirectional-PIM and BSR hash
Bidir-PIM [RFC5015] is designed to avoid any data driven events.
This is especially true in the case of a source only branch. The RP
mapping is determined based on a group mask when the mapping is
received through a dynamic mapping protocol or statically configured.
Therefore the hash in BSR is ignored for PIM-Bidir RP mappings based
on the algorithm defined in this document. It is RECOMMENDED that
network operators configure only one PIM-Bidir RP for each RP
Priority.
11. Filtering Group-to-RP mappings at domain boundaries
An implementation of PIM SHOULD support configuration to block An implementation of PIM SHOULD support configuration to block
specific dynamic mechanism for a valid group prefix range. For specific dynamic mechanism for a valid group prefix range. For
example, it should be possible to allow 239/8 range for Auto-RP example, it should be possible to allow 239/8 range for Auto-RP
protocol but block the BSR advertisement for the same range. protocol but block the BSR advertisement for the same range.
Similarly it should be possible to filter out all Group-to-RP Similarly it should be possible to filter out all Group-to-RP
mappings learned from BSR or Auto-RP protocol. mappings learned from BSR or Auto-RP protocol.
11. Security Consideration 12. Security Consideration
This document does not suggest any protocol specific functionality so This document does not suggest any protocol specific functionality so
there is no security related consideration. there is no security related consideration.
12. IANA Consideration 13. IANA Consideration
This draft does not create any namespace for IANA to manage. This draft does not create any namespace for IANA to manage.
13. Acknowledgements 14. Acknowledgements
This draft is created based on the discussion occurred during the This draft is created based on the discussion occurred during the
PIM-STD-MIB [RFC5060] work. Many thanks to Stig Vennas and Toerless PIM-STD-MIB [RFC5060] work. Many thanks to Stig Vennas, Yiqun Cai
Eckert for providing useful comments during that discussion. and Toerless Eckert for providing useful comments.
14. Normative References 15. Normative References
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC5060] Sivaramu, R., Lingard, J., McWalter, D., Joshi, B., and A. [RFC5060] Sivaramu, R., Lingard, J., McWalter, D., Joshi, B., and A.
Kessler, "Protocol Independent Multicast MIB", RFC 5060, Kessler, "Protocol Independent Multicast MIB", RFC 5060,
January 2008. January 2008.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address", Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, November 2004. RFC 3956, November 2004.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007.
[RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
"Bootstrap Router (BSR) Mechanism for Protocol Independent "Bootstrap Router (BSR) Mechanism for Protocol Independent
Multicast (PIM)", RFC 5059, January 2008. Multicast (PIM)", RFC 5059, January 2008.
Authors' Addresses Authors' Addresses
Bharat Joshi Bharat Joshi
Infosys Technologies Ltd. Infosys Technologies Ltd.
44 Electronics City, Hosur Road 44 Electronics City, Hosur Road
Bangalore 560 100 Bangalore 560 100
 End of changes. 18 change blocks. 
45 lines changed or deleted 56 lines changed or added

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