draft-ietf-mboned-auto-multicast-06.txt   draft-ietf-mboned-auto-multicast-07.txt 
Network Working Group D. Thaler Network Working Group D. Thaler
Internet-Draft M. Talwar Internet-Draft M. Talwar
Expires: December 22, 2006 A. Aggarwal Expires: May 20, 2007 A. Aggarwal
Microsoft Corporation Microsoft Corporation
L. Vicisano L. Vicisano
Cisco Systems Cisco Systems
T. Pusateri T. Pusateri
!j !j
June 20, 2006 November 16, 2006
Automatic IP Multicast Without Explicit Tunnels (AMT) Automatic IP Multicast Without Explicit Tunnels (AMT)
draft-ietf-mboned-auto-multicast-06 draft-ietf-mboned-auto-multicast-07
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 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.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 22, 2006. This Internet-Draft will expire on May 20, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
Automatic Multicast Tunneling (AMT) allows multicast communication Automatic Multicast Tunneling (AMT) allows multicast communication
amongst isolated multicast-enabled sites or hosts, attached to a amongst isolated multicast-enabled sites or hosts, attached to a
network which has no native multicast support. It also enables them network which has no native multicast support. It also enables them
skipping to change at page 3, line 14 skipping to change at page 3, line 14
6.4.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 19 6.4.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 19
6.4.5. IGMP/MLD Query (including IP Header) . . . . . . . . . 19 6.4.5. IGMP/MLD Query (including IP Header) . . . . . . . . . 19
6.5. AMT Membership Update . . . . . . . . . . . . . . . . . . 20 6.5. AMT Membership Update . . . . . . . . . . . . . . . . . . 20
6.5.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.5.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.5.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 20 6.5.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 20
6.5.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 20 6.5.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 20
6.5.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 21 6.5.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 21
6.5.5. IGMP/MLD Message (including IP Header) . . . . . . . . 21 6.5.5. IGMP/MLD Message (including IP Header) . . . . . . . . 21
6.6. AMT IP Multicast Data . . . . . . . . . . . . . . . . . . 21 6.6. AMT IP Multicast Data . . . . . . . . . . . . . . . . . . 21
6.6.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.6.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.6.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 22 6.6.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 21
6.6.3. IP Multicast Data . . . . . . . . . . . . . . . . . . 22 6.6.3. IP Multicast Data . . . . . . . . . . . . . . . . . . 22
7. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 23 7. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 23
7.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . 23 7.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . 23
7.2. Gateway Group and Source Addresses . . . . . . . . . . . . 23 7.2. Gateway Group and Source Addresses . . . . . . . . . . . . 23
7.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.3. Joining Groups with MBone Sources . . . . . . . . . . . . 24 7.3. Joining Groups with MBone Sources . . . . . . . . . . . . 24
7.4. Responding to Relay Changes . . . . . . . . . . . . . . . 25 7.4. Responding to Relay Changes . . . . . . . . . . . . . . . 25
7.5. Joining SSM Groups with AMT Gateway Sources . . . . . . . 26 7.5. Joining SSM Groups with AMT Gateway Sources . . . . . . . 26
7.6. Receiving AMT Membership Updates by the Gateway . . . . . 26 7.6. Receiving AMT Membership Updates by the Gateway . . . . . 26
skipping to change at page 5, line 18 skipping to change at page 5, line 18
configured multicast tunnel for high traffic flow. Unicast configured multicast tunnel for high traffic flow. Unicast
replication is required to reach multiple receivers that are not part replication is required to reach multiple receivers that are not part
of the native multicast infrastructure. Unicast replication is also of the native multicast infrastructure. Unicast replication is also
required by non-native sources to different parts of the native required by non-native sources to different parts of the native
multicast infrastructure. However, this is no worse than regular multicast infrastructure. However, this is no worse than regular
unicast distribution of streams and in most cases much better. unicast distribution of streams and in most cases much better.
The following problems are addressed: The following problems are addressed:
1. Allowing isolated sites/hosts to receive the SSM flavor of 1. Allowing isolated sites/hosts to receive the SSM flavor of
multicast ([I-D.ietf-ssm-arch]). multicast ([RFC4607]).
2. Allowing isolated non-NAT sites/hosts to transmit the SSM flavor 2. Allowing isolated non-NAT sites/hosts to transmit the SSM flavor
of multicast. of multicast.
3. Allowing isolated sites/hosts to receive general multicast (ASM 3. Allowing isolated sites/hosts to receive general multicast (ASM
[RFC1112]). [RFC1112]).
This document does not address allowing isolated sites/hosts to This document does not address allowing isolated sites/hosts to
transmit general multicast. We expect that other solutions (e.g., transmit general multicast. We expect that other solutions (e.g.,
Tunnel Brokers, a la [RFC3053]) will be used for sites that desire Tunnel Brokers, a la [RFC3053]) will be used for sites that desire
skipping to change at page 9, line 52 skipping to change at page 9, line 52
Each relay, plus the set of all gateways using the relay, together Each relay, plus the set of all gateways using the relay, together
are thought of as being on a separate logical NBMA link. This are thought of as being on a separate logical NBMA link. This
implies that the AMT recipient-list is a list of "link layer" implies that the AMT recipient-list is a list of "link layer"
addresses which are (IP address, UDP port) pairs. addresses which are (IP address, UDP port) pairs.
Since the number of gateways using a relay can be quite large, and we Since the number of gateways using a relay can be quite large, and we
expect that most sites will not want to receive most groups, an expect that most sites will not want to receive most groups, an
explicit-joining protocol is required for gateways to communicate explicit-joining protocol is required for gateways to communicate
group membership information to a relay. The two most likely group membership information to a relay. The two most likely
candidates are the IGMP/MLD protocol [RFC3376], [RFC3810], and the candidates are the IGMP/MLD protocol [RFC3376], [RFC3810], and the
PIM-Sparse Mode protocol [I-D.ietf-pim-sm-v2-new]. Since an AMT PIM-Sparse Mode protocol [RFC4601]. Since an AMT gateway may be a
gateway may be a host, and hosts typically do not implement routing host, and hosts typically do not implement routing protocols,
protocols, gateways will use IGMP/MLD as described in Section 7 gateways will use IGMP/MLD as described in Section 7 below. This
below. This allows a host kernel (or a pseudo device driver) to allows a host kernel (or a pseudo device driver) to easily implement
easily implement AMT gateway behavior, and obviates the relay from AMT gateway behavior, and obviates the relay from the need to know
the need to know whether a given gateway is a host or a router. From whether a given gateway is a host or a router. From the relay's
the relay's perspective, all gateways are indistinguishable from perspective, all gateways are indistinguishable from hosts on an NBMA
hosts on an NBMA leaf network. leaf network.
5.1.1. Scalability Considerations 5.1.1. Scalability Considerations
It is possible that millions of hosts will enable AMT gateway It is possible that millions of hosts will enable AMT gateway
functionality and so an important design goal is not to create functionality and so an important design goal is not to create
gateway state in each relay until the gateway joins a multicast gateway state in each relay until the gateway joins a multicast
group. But even the requirement that a relay keep group state per group. But even the requirement that a relay keep group state per
gateway that has joined a group introduces potential scalability gateway that has joined a group introduces potential scalability
concerns. concerns.
skipping to change at page 14, line 14 skipping to change at page 14, line 14
per relay from which membership reports have been sent, and forward per relay from which membership reports have been sent, and forward
multicast traffic from the site to all relays from which membership multicast traffic from the site to all relays from which membership
reports have been received. The choice of whether this state and reports have been received. The choice of whether this state and
replication is done at the link-layer (i.e., by the tunnel interface) replication is done at the link-layer (i.e., by the tunnel interface)
or at the network-layer is implementation dependent. or at the network-layer is implementation dependent.
If there are multiple relays present, this ensures that data from the If there are multiple relays present, this ensures that data from the
AMT site is received via the closest relay to the receiver. This is AMT site is received via the closest relay to the receiver. This is
necessary when the routers in the native multicast infrastructure necessary when the routers in the native multicast infrastructure
employ Reverse-Path Forwarding (RPF) checks against the source employ Reverse-Path Forwarding (RPF) checks against the source
address, such as occurs when PIM Sparse-Mode [I-D.ietf-pim-sm-v2-new] address, such as occurs when PIM Sparse-Mode [RFC4601] is used by the
is used by the multicast infrastructure. multicast infrastructure.
The solution above will scale to an arbitrary number of relays, as The solution above will scale to an arbitrary number of relays, as
long at the number of relays requiring multicast traffic from a given long at the number of relays requiring multicast traffic from a given
AMT site remains reasonable enough to not overly burden the site's AMT site remains reasonable enough to not overly burden the site's
gateway. gateway.
A source at or behind an AMT gateway requires the gateway to do the A source at or behind an AMT gateway requires the gateway to do the
replication to one or more relays and receiving gateways. If this replication to one or more relays and receiving gateways. If this
places too much of a burden on the sourcing gateway, the source places too much of a burden on the sourcing gateway, the source
should join the native multicast infrastructure through a permanent should join the native multicast infrastructure through a permanent
skipping to change at page 21, line 36 skipping to change at page 21, line 36
The UDP source and destination port numbers should be the same ones The UDP source and destination port numbers should be the same ones
sent in the original Query. The UDP checksum SHOULD be 0 in the AMT sent in the original Query. The UDP checksum SHOULD be 0 in the AMT
IP Multicast Data message. IP Multicast Data message.
The payload of the UDP packet contains the following fields. The payload of the UDP packet contains the following fields.
0 1 2 3 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 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=0x6 | Reserved | | Type=0x6 | Reserved | IP Multicast Data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Multicast Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
6.6.1. Type 6.6.1. Type
The type of the message. The type of the message.
6.6.2. Reserved 6.6.2. Reserved
A 24-bit reserved field. Sent as 0, ignored on receipt. An 8-bit reserved field. Sent as 0, ignored on receipt.
6.6.3. IP Multicast Data 6.6.3. IP Multicast Data
The original IP Multicast data packet that is being replicated by the The original IP Multicast data packet that is being replicated by the
relay to the gateways including the original IP header. relay to the gateways including the original IP header.
7. AMT Gateway Details 7. AMT Gateway Details
This section details the behavior of an AMT Gateway, which may be a This section details the behavior of an AMT Gateway, which may be a
router serving an AMT site, or the site may consist of a single host, router serving an AMT site, or the site may consist of a single host,
skipping to change at page 23, line 26 skipping to change at page 23, line 26
note the unicast address (which is treated as a link-layer address to note the unicast address (which is treated as a link-layer address to
the encapsulation interface) from the AMT Relay Advertisement the encapsulation interface) from the AMT Relay Advertisement
message. This discovery SHOULD be done periodically (e.g., once a message. This discovery SHOULD be done periodically (e.g., once a
day) to re-resolve the unicast address of a close relay. The gateway day) to re-resolve the unicast address of a close relay. The gateway
also SHOULD initialize a timer used to send periodic membership also SHOULD initialize a timer used to send periodic membership
reports to a random value from the interval [0, [Query Interval]] reports to a random value from the interval [0, [Query Interval]]
before sending the first periodic report, in order to prevent startup before sending the first periodic report, in order to prevent startup
synchronization (e.g., after a power outage). synchronization (e.g., after a power outage).
If the gateway is serving as a local router, it SHOULD also function If the gateway is serving as a local router, it SHOULD also function
as an IGMP/MLD Proxy, as described in [I-D.ietf-magma-igmp-proxy], as an IGMP/MLD Proxy, as described in [RFC4605], with its IGMP/MLD
with its IGMP/MLD host-mode interface being the AMT pseudo-interface. host-mode interface being the AMT pseudo-interface. This enables it
This enables it to translate group memberships on its downstream to translate group memberships on its downstream interfaces into
interfaces into IGMP/MLD Reports. Hosts receiving multicast packets IGMP/MLD Reports. Hosts receiving multicast packets through an AMT
through an AMT gateway acting as a proxy should ensure that their gateway acting as a proxy should ensure that their M-RIB accepts
M-RIB accepts multicast packets from the AMT gateway for the sources multicast packets from the AMT gateway for the sources it is joining.
it is joining.
7.2. Gateway Group and Source Addresses 7.2. Gateway Group and Source Addresses
To support sourcing traffic to SSM groups by a gateway with a global To support sourcing traffic to SSM groups by a gateway with a global
unicast address, the AMT Subnet Anycast Prefix is treated as the unicast address, the AMT Subnet Anycast Prefix is treated as the
subnet prefix of the AMT pseudo-interface, and an anycast address is subnet prefix of the AMT pseudo-interface, and an anycast address is
added on the interface. This anycast address is formed by added on the interface. This anycast address is formed by
concatenating the AMT Subnet Anycast Prefix followed by the high bits concatenating the AMT Subnet Anycast Prefix followed by the high bits
of the gateway's global unicast address. of the gateway's global unicast address.
skipping to change at page 34, line 9 skipping to change at page 34, line 9
Shepherd, Dino Farinacci, Toerless Eckert, Marshall Eubanks, John Shepherd, Dino Farinacci, Toerless Eckert, Marshall Eubanks, John
Zwiebel, and Lenny Giuliano. Zwiebel, and Lenny Giuliano.
Juniper Networks was instrumental in funding several versions of this Juniper Networks was instrumental in funding several versions of this
draft as well as an open source implementation. draft as well as an open source implementation.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-magma-igmp-proxy]
Fenner, B., He, H., Haberman, B., and H. Sandick, "IGMP/
MLD-based Multicast Forwarding ('IGMP/MLD Proxying')",
draft-ietf-magma-igmp-proxy-06 (work in progress),
April 2004.
[I-D.ietf-ssm-arch]
Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", draft-ietf-ssm-arch-07 (work in progress),
October 2005.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981. RFC 792, September 1981.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002. 3", RFC 3376, October 2002.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
13.2. Informative References [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006.
[I-D.ietf-pim-sm-v2-new] [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
Fenner, B., "Protocol Independent Multicast - Sparse Mode IP", RFC 4607, August 2006.
(PIM-SM): Protocol Specification (Revised)",
draft-ietf-pim-sm-v2-new-12 (work in progress), 13.2. Informative References
March 2006.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989. RFC 1112, August 1989.
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host
Anycasting Service", RFC 1546, November 1993. Anycasting Service", RFC 1546, November 1993.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
skipping to change at page 36, line 5 skipping to change at page 35, line 5
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
Tunnel Broker", RFC 3053, January 2001. Tunnel Broker", RFC 3053, January 2001.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001. via IPv4 Clouds", RFC 3056, February 2001.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001. RFC 3068, June 2001.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
Authors' Addresses Authors' Addresses
Dave Thaler Dave Thaler
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052-6399
USA USA
Phone: +1 425 703 8835 Phone: +1 425 703 8835
Email: dthaler@microsoft.com Email: dthaler@microsoft.com
 End of changes. 15 change blocks. 
44 lines changed or deleted 36 lines changed or added

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