< draft-savola-mboned-mcast-rpaddr-01.txt   draft-savola-mboned-mcast-rpaddr-02.txt >
Internet Engineering Task Force P. Savola Internet Engineering Task Force P. Savola
Internet Draft CSC/FUNET Internet Draft CSC/FUNET
Expiration Date: August 2003 Expiration Date: September 2003
B. Haberman B. Haberman
Caspian Networks Caspian Networks
February 2003 March 2003
Embedding the Address of RP in IPv6 Multicast Address Embedding the Address of RP in IPv6 Multicast Address
draft-savola-mboned-mcast-rpaddr-01.txt draft-savola-mboned-mcast-rpaddr-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
As has been noticed, there is exists a huge deployment problem with As has been noticed, there is exists a huge deployment problem with
global, interdomain IPv6 multicast: PIM RPs have no way of global, interdomain IPv6 multicast: PIM Renzesvous Points (RPs) have
communicating the information about multicast sources to other no way of communicating the information about multicast sources to
multicast domains, as there is no MSDP, and the whole interdomain Any other multicast domains, as there is no MSDP, and the whole
Source Multicast model is rendered unusable; SSM avoids these interdomain Any Source Multicast model is rendered unusable; SSM
problems. This memo outlines a way to embed the address of the RP in avoids these problems. This memo outlines a way to embed the address
the multicast address, solving the interdomain multicast problem. The of the RP in the multicast address, solving the interdomain multicast
problem is three-fold: specify an address format, adjust the problem. The problem is three-fold: specify an address format, adjust
operational procedures and configuration if necessary, and modify PIM the operational procedures and configuration if necessary, and modify
implementations of those who want to join a group (DR's) or create PIM implementations of those who want to join or send to a group
one (RP's). In consequence, there would be no need for interdomain (Designated Routers) or provide one (Rendezvous Points). In
MSDP. consequence, there would be no need for interdomain MSDP.
Table of Contents Table of Contents
1. Introduction ............................................... 2 1. Introduction ............................................... 2
2. Unicast-Prefix-based Address Format ........................ 3 2. Unicast-Prefix-based Address Format ........................ 3
3. Modified Unicast-Prefix-based Address Format ............... 3 3. Modified Unicast-Prefix-based Address Format ............... 3
4. Embedding the Address of the RP in the Multicast Address ... 4 4. Embedding the Address of the RP in the Multicast Address ... 4
5. Examples ................................................... 5 5. Examples ................................................... 5
5.1. Example 1 .............................................. 5 5.1. Example 1 .............................................. 5
5.2. Example 2 .............................................. 5 5.2. Example 2 .............................................. 5
5.3. Example 3 .............................................. 6 5.3. Example 3 .............................................. 6
5.4. Example 4 .............................................. 6 5.4. Example 4 .............................................. 6
6. Operational Requirements ................................... 6 6. Operational Requirements ................................... 6
6.1. Anycast-RP ............................................. 6 6.1. Anycast-RP ............................................. 6
6.2. Guidelines for Assigning IPv6 Addresses to RPs ......... 6 6.2. Guidelines for Assigning IPv6 Addresses to RPs ......... 6
7. Required PIM Modifications ................................. 7 7. Required PIM Modifications ................................. 7
7.1. Overview of the Model .................................. 8 7.1. Overview of the Model .................................. 8
8. Scalability/Usability Analysis ............................. 8 8. Scalability/Usability Analysis ............................. 8
9. Acknowledgements ........................................... 9 9. Acknowledgements ........................................... 9
10. Security Considerations ................................... 9 10. Security Considerations ................................... 10
11. References ................................................ 10 11. References ................................................ 11
11.1. Normative References .................................. 10 11.1. Normative References .................................. 11
11.2. Informative References ................................ 10 11.2. Informative References ................................ 11
Authors' Addresses ............................................. 11 Authors' Addresses ............................................. 11
A. Open Issues/Discussion ..................................... 11 A. Open Issues/Discussion ..................................... 12
1. Introduction 1. Introduction
As has been noticed [V6MISSUES], there is exists a huge deployment As has been noticed [V6MISSUES], there is exists a huge deployment
problem with global, interdomain IPv6 multicast: PIM [PIM] RPs have problem with global, interdomain IPv6 multicast: PIM [PIM] RPs have
no way of communicating the information about multicast sources to no way of communicating the information about multicast sources to
other multicast domains, as there is no MSDP [MSDP], and the whole other multicast domains, as there is no MSDP [MSDP], and the whole
interdomain Any Source Multicast model is rendered unusable; SSM interdomain Any Source Multicast model is rendered unusable; SSM
[SSM] avoids there problems. [SSM] avoids there problems.
This memo outlines a way to embed the address of the RP in the This memo outlines a way to embed the address of the RP in the
multicast address, solving the interdomain multicast problem. The multicast address, solving the interdomain multicast problem. The
problem is three-fold: specify an address format, adjust the problem is three-fold: specify an address format, adjust the
operational procedures and configuration if necessary, and modify operational procedures and configuration if necessary, and modify PIM
receiver-side PIM implementations. In consequence, there would be no implementations of DR's where receivers/senders are expected use the
need for interdomain MSDP. multicast addressing as described in this memo. In consequence,
there would be no need for interdomain MSDP.
The solution is founded upon unicast-prefix-based IPv6 multicast The solution is founded upon unicast-prefix-based IPv6 multicast
addressing [UNIPRFXM] and making some assumptions about IPv6 address addressing [UNIPRFXM] and making some assumptions about IPv6 address
assignment for the RPs in the PIM domain. assignment for the RPs in the PIM domain.
Further, a change in how interdomain PIM operates with these Further, a change in how interdomain PIM operates with these
addresses is presented: multicast receivers' DR's join the RP addresses is presented: multicast receivers' and senders' DR's join
embedded in the address -- not their locally configured RP. or send to (respectively) the RP embedded in the address -- not their
locally configured RP.
It is self-evident that one can't embed, in the general case, two It is self-evident that one can't embed, in the general case, two
128-bit addresses in one 128-bit address. In this memo, some 128-bit addresses in one 128-bit address. In this memo, some
assumptions on how this could be done are made. If these assumptions assumptions on how this could be done are made. If these assumptions
can't be followed, either operational procedures and configuration can't be followed, either operational procedures and configuration
must be slightly changed or this mechanism not be used. must be slightly changed or this mechanism not be used.
The assignment of multicast addresses is outside the scope of this The assignment of multicast addresses is outside the scope of this
document. document; however, the mechanisms are very probably similar to ones
used with [UNIPRFXM].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Unicast-Prefix-based Address Format 2. Unicast-Prefix-based Address Format
As described in [UNIPRFXM], the multicast address format is as As described in [UNIPRFXM], the multicast address format is as
follows: follows:
skipping to change at page 7, line 14 skipping to change at page 7, line 14
7. Required PIM Modifications 7. Required PIM Modifications
The use of multicast addresses with embedded RP addresses requires The use of multicast addresses with embedded RP addresses requires
additional PIM processing. Namely, a PIM router will need to be able additional PIM processing. Namely, a PIM router will need to be able
to recognize the encoding and derive the RP address from the address to recognize the encoding and derive the RP address from the address
using the rules in section 4 and to be able to use the embedded RP, using the rules in section 4 and to be able to use the embedded RP,
instead of its own for multicast addresses in this specified range. instead of its own for multicast addresses in this specified range.
The two key places where these modifications are used are the The two key places where these modifications are used are the
Designated Routers (DRs) on the receiver networks and the RPs in the Designated Routers (DRs) on the receiver/sender networks and the RPs
sending domain (see figure below). in the domain where the embdedded address has been derived from (see
figure below).
For the DR's (rtrR1, rtrR23, and rtrR4), this means sending PIM For the foreign DR's (rtrR1, rtrR23, and rtrR4), this means sending
Join/Prune/Register messages to the foreign RP (rtrRP_S). Naturally, PIM Join/Prune/Register messages towards the foreign RP (rtrRP_S).
PIM Register-Stop and other messages must also be allowed from the Naturally, PIM Register-Stop and other messages must also be allowed
foreign RP. Receivers in the local PIM domain (receiverS) do the from the foreign RP. DR's in the local PIM domain (rtrS) do the
same, but the RP used is the same as with regular Any-Source same, but the RP used should the same as with regular Any-Source
Multicast (ASM). Multicast (ASM); however, see the appendix for more.
For the RP (rtrRP_S), this means being able to recognize and validate For the RP (rtrRP_S), this means being able to recognize and validate
PIM messages originated from any DR at all and which use RP-embedded PIM messages which use RP-embedded addressing originated from any DR
addressing. at all.
In particular, there is no need to have all routers on the path In particular, there is no need to have all routers (like rtrBB) on
modified: this is a major benefit for quick deployment. the path modified: this is a major benefit for quick deployment.
source - rtrS - rtrRP_S - rtrBB -----+--- rtrR1 - receiver1 nodeS - rtrS - rtrRP_S - rtrBB -----+--- rtrR1 - node1
| | | | | |
| | +-- rtrR23 - receiver2 node2_S ---------+ | +-- rtrR23 - node2
receiverS -+ | | | |
| +---- receiver3 | +---- node3
| |
+------------ rtrR4 - receiver4 +------------ rtrR4 - node4
In addition, the administration of the PIM domain will require a In addition, the administration of the PIM domain will require a
policy decision on where the PIM messages to the encoded RP be sent; policy decision on where the PIM messages to the encoded RP be sent;
this is typically assumed to everywhere unless explicitly configured this is typically assumed to everywhere unless explicitly configured
otherwise. otherwise.
The extraction of the RP information from the multicast address The extraction of the RP information from the multicast address
should be done during forwarding state creation. That is, if no should be done during forwarding state creation. That is, if no
state exists for the multicast address, PIM must take the embedded RP state exists for the multicast address, PIM must take the embedded RP
information into account when creating forwarding state. Depending information into account when creating forwarding state. Depending
on administrative policy, this would result in a receiver's DR on administrative policy, this would result in a receiver's DR
initiating a PIM Join towards the foreign RP. initiating a PIM Join towards the foreign RP or a source's DR sending
PIM Register messages towards the foreign RP.
It should be noted that this approach removes the need to run inter- It should be noted that this approach removes the need to run inter-
domain MSDP. Multicast distribution trees in foreign networks can be domain MSDP. Multicast distribution trees in foreign networks can be
joined by issuing a PIM Join/Prune/Register to the RP address encoded joined by issuing a PIM Join/Prune/Register to the RP address encoded
in the multicast address. in the multicast address.
7.1. Overview of the Model 7.1. Overview of the Model
The steps when a receiver wishes to join a group are: The steps when a receiver wishes to join a group are:
1. A receiver finds out a group address from some means (e.g. SDR 1. A receiver finds out a group address from some means (e.g. SDR
or a web page) or a web page).
2. The receiver issues an MLD Report Joining the group 2. The receiver issues an MLD Report, joining the group.
3. The receiver's DR will initiate the PIM Join process towards 3. The receiver's DR will initiate the PIM Join process towards
the RP embedded in the multicast address the RP embedded in the multicast address.
The sender side has two cases: The steps when a sender wishes to send to a group are:
1. A sender in the local domain. Nothing should be different 1. A sender finds out a group address from some means, whether in
here. an existing group (e.g. SDR, web page) or in a new group (e.g.
2. A sender in a foreign domain. The DR will send the packets a call to the administrator for group assignment, use of a
unicast-encapsulated in PIM Register-messages to the RP address multicast address assignment protocol).
encoded in the multicast address. The messages go on as 2. The sender sends to the group.
before, often with a Register-Stop and SPT Join; there is no 3. The sender's DR will send the packets unicast-encapsulated in
difference in them except for the fact that the RP address is PIM unicast-encapsulated in PIM Register-messages to the RP
derived from the multicast address. address encoded in the multicast address (in the special case
that DR is the RP, such sending is only conceptual).
Whether a sender is in local or foreign domain can be distinguished In both cases, the messages then go on as specified in [PIM] and
by checking whether the embedded address is one of RP's configured other specifications (e.g. Register-Stop and/or SPT Join); there is
using conventional mechanisms. Further mechanisms and behaviour is no difference in them except for the fact that the RP address is
TBD (also see the appendix). derived from the multicast address.
When sending or receiving, there is a special case when the DR is in
local domain, and information about RP to be used with the group is
available with conventional mechanisms, and that differs from the RP
embedded in the address; see the appendix for more information.
8. Scalability/Usability Analysis 8. Scalability/Usability Analysis
Interdomain MSDP model for connecting PIM domains is mostly Interdomain MSDP model for connecting PIM domains is mostly
hierarchical. The "embedded RP address" changes this to a mostly hierarchical. The "embedded RP address" changes this to a mostly
flat, sender-centered, full-mesh virtual topology. flat, sender-centered, full-mesh virtual topology.
This may or may not cause some effects; it may or may not be This may or may not cause some effects; it may or may not be
desirable. At the very least, it makes many things much more robust desirable. At the very least, it makes many things much more robust
as the number of third parties is minimized. A good scalability as the number of third parties is minimized. A good scalability
skipping to change at page 9, line 7 skipping to change at page 9, line 16
local multicast), some degree of hierarchy would be highly desirable, local multicast), some degree of hierarchy would be highly desirable,
for scalability (e.g. take the advantage of shared multicast state) for scalability (e.g. take the advantage of shared multicast state)
and administrative point-of-view. and administrative point-of-view.
Being able to join/send to remote RP's has security considerations Being able to join/send to remote RP's has security considerations
that are considered below, but it has an advantage too: every group that are considered below, but it has an advantage too: every group
has a "home RP" which is able to control (to some extent) who are has a "home RP" which is able to control (to some extent) who are
able to send to the group. able to send to the group.
One should note that the model presented here simplifies the PIM One should note that the model presented here simplifies the PIM
multicast routing model slightly by removing the receivers' local RP. multicast routing model slightly by removing the RP for senders and
One scalability consideration should be noted: previously foreign receivers in foreign domains. One scalability consideration should
sources sent the unicast-encapsulated data to their local RP, now be noted: previously foreign sources sent the unicast-encapsulated
they do so to foreign RP. This is especially important with large data to their local RP, now they do so to the foreign RP responsible
for the specific group. This is especially important with large
multicast groups where there are a lot of heavy senders -- multicast groups where there are a lot of heavy senders --
particularly if implementations do not handle unicast-decapsulation particularly if implementations do not handle unicast-decapsulation
well. well.
This model increases the amount of Internet-wide multicast state
slightly: the backbone routers might end up with at least temporary
(*, G) and (S, G, rpt) state in addition to (S, G) states between the
receivers and senders. Certainly, the amount of inter-domain
multicast traffic between sources and the embedded-RP will increase
compared to the ASM model with MSDP; however, the domain responsible
for the RP is expected to be able to handle this.
As the address of the RP is tied to the multicast address, in the
case of RP failure, PIM BSR mechanisms cannot pick a new RP; the
failover mechanisms, if used, for backup RP's are different, and
typically would depend on sharing one address. The failover
techniques are outside of the scope of this memo.
9. Acknowledgements 9. Acknowledgements
Jerome Durand commented on an early draft of this memo. Marshall Jerome Durand commented on an early draft of this memo. Marshall
Eubanks noted an issue regarding short plen values. Tom Pusateri Eubanks noted an issue regarding short plen values. Tom Pusateri
noted problems with earlier SPT-join approach. Rami Lehtonen pointed noted problems with earlier SPT-join approach. Rami Lehtonen pointed
out issues with the scope of SA-state. The whole MboneD working out issues with the scope of SA-state and provided extensive
group is also acknowledged for the continued support and comments. commentary. The whole MboneD working group is also acknowledged for
the continued support and comments.
10. Security Considerations 10. Security Considerations
The address of the PIM RP is embedded in the multicast address. RPs The address of the PIM RP is embedded in the multicast address. RPs
may be a good target for Denial of Service attacks, and in this way, may be a good target for Denial of Service attacks -- as they are a
the target would be clearly visible. However, it could be argued single point of failure (excluding failover techniques) for a group.
that if interdomain multicast was to be made work e.g. with MSDP, the In this way, the target would be clearly visible. However, it could
address would have to be visible anyway (through via other channels, be argued that if interdomain multicast was to be made work e.g. with
which may be more easily securable). MSDP, the address would have to be visible anyway (through via other
channels, which may be more easily securable).
As any RP will have to accept PIM Join/Prune/Register messages from As any RP will have to accept PIM Join/Prune/Register messages from
any DR's, this might cause a potential DoS attack scenario. However, any DR's, this might cause a potential DoS attack scenario. However,
this can be mitigated by the fact that the RP can discard all such this can be mitigated by the fact that the RP can discard all such
messages for all multicast addresses that do not embed the address of messages for all multicast addresses that do not embed the address of
the RP, and if deemed important, the implementation could also allow the RP, and if deemed important, the implementation could also allow
manual configuration of which multicast addresses or prefixes manual configuration of which multicast addresses or prefixes
embedding the RP could be used; however, at least with addresses, embedding the RP could be used; however, at least with addresses,
this would increase the need for coordination between multicast this would increase the need for coordination between multicast
sources and administration. sources and administration.
skipping to change at page 10, line 32 skipping to change at page 11, line 20
Addressing Architecture", RFC2373, July 1998. Addressing Architecture", RFC2373, July 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[UNIPRFXM] Haberman, B., Thaler, D., "Unicast-Prefix-based IPv6 [UNIPRFXM] Haberman, B., Thaler, D., "Unicast-Prefix-based IPv6
Multicast Addresses", RFC3306, August 2002. Multicast Addresses", RFC3306, August 2002.
11.2. Informative References 11.2. Informative References
[ANYCASTRP] Kim, D. et al, q(Anycast RP mechanism using PIM and [ANYCASTRP] Kim, D. et al, "Anycast RP mechanism using PIM and
MSDP", work-in-progress, draft-ietf-mboned-anycast- MSDP", work-in-progress, draft-ietf-mboned-anycast-
rp-08.txt, May 2001. rp-08.txt, May 2001.
[ANYPIMRP] Farinacci, D., Cai, Y., "Anycast-RP using PIM", [ANYPIMRP] Farinacci, D., Cai, Y., "Anycast-RP using PIM",
work-in-progress, draft-farinacci-pim-anycast-rp-00.txt, work-in-progress, draft-farinacci-pim-anycast-rp-00.txt,
January 2003. January 2003.
[MSDP] Meyer, D., Fenner, B, (Eds.), "Multicast Sourc [MSDP] Meyer, D., Fenner, B, (Eds.), "Multicast Sourc
Discovery Protocol (MSDP)", work-in-progress, Discovery Protocol (MSDP)", work-in-progress,
draft-ietf-msdp-spec-14.txt, November 2002. draft-ietf-msdp-spec-14.txt, November 2002.
[PIM] Fenner, B. et al, "Protocol Independent Multicast - [PIM] Fenner, B. et al, "Protocol Independent Multicast -
Sparse Mode (PIM-SM): Protocol Specification (Revised), Sparse Mode (PIM-SM): Protocol Specification (Revised),
work-in-progress, draft-ietf-pim-sm-v2-new-06.txt, work-in-progress, draft-ietf-pim-sm-v2-new-06.txt,
December 2002. December 2002.
[SSM] Holbrook, H. et al, "Source-Specific Multicast for IP", [SSM] Holbrook, H. et al, "Source-Specific Multicast for IP",
work-in-progress, draft-ietf-ssm-arch-00.txt, work-in-progress, draft-ietf-ssm-arch-02.txt,
November 2001. February 2003.
[V6MISSUES] Savola, P., "IPv6 Multicast Deployment Issues", [V6MISSUES] Savola, P., "IPv6 Multicast Deployment Issues",
work-in-progress, draft-savola-v6ops-multicast- work-in-progress, draft-savola-v6ops-multicast-
issues-01.txt, November 2002. issues-01.txt, November 2002.
Authors' Addresses Authors' Addresses
Pekka Savola Pekka Savola
CSC/FUNET CSC/FUNET
Espoo, Finland Espoo, Finland
skipping to change at page 11, line 48 skipping to change at page 12, line 35
example, using two /33's instead of one /32 would gain another 16 RP example, using two /33's instead of one /32 would gain another 16 RP
addresses. addresses.
Some hierarchy (e.g. two-level, "ISP/customer") for RPs could Some hierarchy (e.g. two-level, "ISP/customer") for RPs could
possibly be added if necessary, but that would be torturing one 128 possibly be added if necessary, but that would be torturing one 128
bits even more. bits even more.
One particular case with a sender in the local domain is where One particular case with a sender in the local domain is where
regular ASM RP would be X, and the embedded RP address would be Y. regular ASM RP would be X, and the embedded RP address would be Y.
This would typically be due to a misconfiguration, but the DR SHOULD This would typically be due to a misconfiguration, but the DR SHOULD
be conservative and use the configured address X. Any other thoughts be conservative and use the configured address X. However, the
on that? simplest approach, and one which would typically be least surprising,
would be the one where one would always use the embedded RP address
by default. Any other thoughts on that?
 End of changes. 27 change blocks. 
75 lines changed or deleted 103 lines changed or added

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