draft-ietf-pim-group-rp-mapping-07.txt   draft-ietf-pim-group-rp-mapping-08.txt 
PIM Working Group B. Joshi PIM Working Group B. Joshi
Internet-Draft Infosys Technologies Ltd. Internet-Draft Infosys Technologies Ltd.
Updates: 4601 (if approved) A. Kessler Updates: 4601 (if approved) A. Kessler
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: June 12, 2011 D. McWalter Expires: July 1, 2011 D. McWalter
December 9, 2010 December 28, 2010
PIM Group-to-RP Mapping PIM Group-to-RP Mapping
draft-ietf-pim-group-rp-mapping-07.txt draft-ietf-pim-group-rp-mapping-08.txt
Abstract Abstract
Each PIM-SM router in a Protocol Independent Multicast (PIM) Domain Each PIM-SM router in a Protocol Independent Multicast (PIM) Domain
which supports Any Source Multicast (ASM) maintains Group-to-RP which supports Any Source Multicast (ASM) maintains Group-to-RP
mappings which are used to identify a Rendezvous Point(RP) for a mappings which are used to identify a Rendezvous Point(RP) for a
specific multicast group. PIM-SM has defined an algorithm to choose specific multicast group. PIM-SM has defined an algorithm to choose
a RP from the Group-to-RP mappings learned using various mechanisms. a RP from the Group-to-RP mappings learned using various mechanisms.
This algorithm does not consider the PIM mode and the mechanism This algorithm does not consider the PIM mode and the mechanism
through which a Group-to-RP mapping was learned. through which a Group-to-RP mapping was learned.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on June 12, 2011. This Internet-Draft will expire on July 1, 2011.
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
skipping to change at page 5, line 20 skipping to change at page 5, line 20
o It does not consider the origin of a Group-to-RP mapping and o It does not consider the origin of a Group-to-RP mapping and
therefore will treat all of them equally. therefore will treat all of them equally.
o It does not provide the flexibility to give higher priority to a o It does not provide the flexibility to give higher priority to a
specific PIM mode. For example, an entry learned for PIM-BIDIR specific PIM mode. For example, an entry learned for PIM-BIDIR
mode is treated with same priority as an entry learned for PIM-SM. mode is treated with same priority as an entry learned for PIM-SM.
The algorithm defined in this document updates algorithm defined in The algorithm defined in this document updates algorithm defined in
PIM-SM ( Section 4.7.1 in [RFC4601]). The new algorithm is backward PIM-SM ( Section 4.7.1 in [RFC4601]). The new algorithm is backward
compatible and will produce the same result only if the Group-to-RP compatible and will produce the same result only if the Group-to-RP
mappings are learned from a single mapping source. mappings are learned from a single mapping source. The full benefits
of the new algorithm will not be realized until it is widely
deployed.
4. Assumptions 4. Assumptions
We have made following assumptions in defining this algorithm: We have made following assumptions in defining this algorithm:
o A Group-to-RP mapping can be learned from various mechanisms. We o A Group-to-RP mapping can be learned from various mechanisms. We
assume that following list is in the decreasing preferences of assume that following list is in the decreasing preferences of
these mechanism: these mechanism:
* Embedded Group-to-RP mappings * Embedded Group-to-RP mappings
skipping to change at page 7, line 22 skipping to change at page 7, line 22
statically configured Group-to-RP mappings for this range. In this statically configured Group-to-RP mappings for this range. In this
case, to support some specific applications, they might like to learn case, to support some specific applications, they might like to learn
Group-to-RP mappings dynamically using either BSR or Auto-RP Group-to-RP mappings dynamically using either BSR or Auto-RP
mechanism. In this case to select Group-to-RP mappings for these mechanism. In this case to select Group-to-RP mappings for these
specific applications, a longer prefix match should be given specific applications, a longer prefix match should be given
preference over statically configured Group-to-RP mappings. For preference over statically configured Group-to-RP mappings. For
example 239.100.0.0/16, an administratively scoped multicast address example 239.100.0.0/16, an administratively scoped multicast address
range, could be learned for a corporate communications application. range, could be learned for a corporate communications application.
Network operators may change the Group-to-RP mappings for these Network operators may change the Group-to-RP mappings for these
applications more often and would need to be learned dynamically. applications more often and would need to be learned dynamically.
This is not an issue for IPv6 Multicast address ranges.
o Migration situations o Migration situations
Network operators occasionally go through a migration due to an Network operators occasionally go through a migration due to an
acquisition or a change in their network design. In order to acquisition or a change in their network design. In order to
facilitate this migration there is a need to have a deterministic facilitate this migration there is a need to have a deterministic
behaviour of Group-to-RP mapping selection for entries learned using behaviour of Group-to-RP mapping selection for entries learned using
BSR and Auto-RP mechanism. This will help in avoiding any unforeseen BSR and Auto-RP mechanism. This will help in avoiding any unforeseen
interoperability issues between different vendor's network elements. interoperability issues between different vendor's network elements.
o Use by management systems o Use by management systems
A network management station can determine the RP for a specific A network management station can determine the RP for a specific
group in a specific router by running this algorithm on the group in a specific router by running this algorithm on the
Group-to-RP mapping table fetched using SNMP MIB objects. Group-to-RP mapping table fetched using SNMP MIB objects.
o More use cases
By no means, the above list is complete. Please drop a mail to
'authors' if you see any other use case for this.
6. Proposed algorithm 6. Proposed algorithm
The following algorithm addresses the above mentioned shortcomings in The following algorithm addresses the above mentioned shortcomings in
the existing mechanism: the existing mechanism:
1. If the Multicast Group Address being looked up contains an 1. If the Multicast Group Address being looked up contains an
embedded RP, RP address extracted from the Group address is embedded RP, RP address extracted from the Group address is
selected as Group-to-RP mapping. selected as Group-to-RP mapping.
2. If the Multicast Group Address being looked up is in the Source 2. If the Multicast Group Address being looked up is in the Source
skipping to change at page 11, line 7 skipping to change at page 11, line 7
the 'pimGroupMappingTable' table in the PIM-STD-MIB module [RFC5060] the 'pimGroupMappingTable' table in the PIM-STD-MIB module [RFC5060]
are not applicable to the new algorithm. The objects still retain are not applicable to the new algorithm. The objects still retain
their meaning for 'legacy' implementations, but since the algorithm their meaning for 'legacy' implementations, but since the algorithm
defined in this document is to be used in preference to that found in defined in this document is to be used in preference to that found in
PIM-SM [RFC4601] and PIM-STD-MIB [RFC5060], the usage of these fields PIM-SM [RFC4601] and PIM-STD-MIB [RFC5060], the usage of these fields
will decline as implementations are upgraded to support the new will decline as implementations are upgraded to support the new
algorithm. algorithm.
8. Clarification for MIB Objects 8. Clarification for MIB Objects
When a Group-to-RP mapping entry is created in the An implementation of this specification can continue to be managed
pimGroupMappingTable in the PIM-STD MIB[RFC5060], it would be using the PIM-STD-MIB [RFC5060]. When a Group-to-RP mapping entry is
acceptable to have an entry with an RP with address type 'unknown' created in the pimGroupMappingTable with RP address type in the
and a PimMode of Dense Mode or SSM. These entries would represent pimGroupMappingRPAddressType object is set to unknown(0), and the PIM
group ranges for Dense mode or SSM. Mode in the pimGroupMappingPimMode object is set to either ssm(2) or
dm(5) to represent group ranges for SSM or Dense mode.
Also all the entries which are already included in the SSM Range
table in the IP Mcast MIB would be copied over to
pimGroupMappingTable. They would have a type of configSSM and an RP
with address type 'unknown' as described above.
The advantage of keeping all the ranges in the table would be that Also, all the entries which are already included in the SSM Range
this table will contain all the known multicast group ranges. table in the IP Mcast MIB [RFC5132] are copied to the
pimGroupMappingTable. Such entries have their type in the
pimGroupMappingOrigin object set to configSsm(3), and the RP address
type in the pimGroupMappingRPAddressType object set to unknown(0) as
described above.
9. Use of dynamic group-to-rp mapping protocols 9. Use of dynamic group-to-rp mapping protocols
It is not usually necessary to run several dynamic Group-to-RP It is not usually necessary to run several dynamic Group-to-RP
mapping mechanisms in one administrative domain. Specifically, mapping mechanisms in one administrative domain. Specifically,
interoperation of BSR and Auto-RP is OPTIONAL. interoperation of BSR and Auto-RP is OPTIONAL.
However, if a router does receive two overlapping sets of Group-to-RP However, if a router does receive two overlapping sets of Group-to-RP
mappings, for example from Auto-RP and BSR, then some algorithm is mappings, for example from Auto-RP and BSR, then some algorithm is
needed to deterministically resolve the situation. The algorithm in needed to deterministically resolve the situation. The algorithm in
skipping to change at page 19, line 5 skipping to change at page 18, line 30
RFC 3956, November 2004. RFC 3956, November 2004.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR- "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007. 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.
[RFC5132] McWalter, D., Thaler, D., and A. Kessler, "IP Multicast
MIB", RFC 5132, December 2007.
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
India India
Email: bharat_joshi@infosys.com Email: bharat_joshi@infosys.com
URI: http://www.infosys.com/ URI: http://www.infosys.com/
 End of changes. 9 change blocks. 
22 lines changed or deleted 23 lines changed or added

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