Network Working Group F. Xia
Internet-Draft B. Sarikaya
Expires: May 9, 2008 Huawei USA
November 6, 2007
Hybrid Subscription for Multicast Reciever Mobility in MIPv6
draft-xia-multimob-hybrid-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
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 May 9, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Xia & Sarikaya Expires May 9, 2008 [Page 1]
Internet-Draft Optimization Multicast November 2007
Abstract
In MIPv6 specification, there are two basic methods for mobile
multicast: 1) via a bi-directional tunnel from MN to its Home
Agent;2) via a local multicast router on the foreign link being
visited. In this memo, a hybrid method is introduced. MN subscribes
multicast service through Home agent at first. Then, MN changes its
subscription router to a local multicast router which can provide the
same multicast service.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Solution Detail . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Local Multicast Service Discovery . . . . . . . . . . . . 6
4.2. Multicast Group Membership Management in HA . . . . . . . 6
5. MLDv2 Extension . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Multicast Listener Hold-Release . . . . . . . . . . . . . 6
5.2. Multicast Listening State Advertisement . . . . . . . . . 7
5.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2.2. Reserved and Checksum . . . . . . . . . . . . . . . . 8
5.2.3. Nr of Mcast Address Records (M) . . . . . . . . . . . 8
5.2.4. Multicast Address Record . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative references . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Xia & Sarikaya Expires May 9, 2008 [Page 2]
Internet-Draft Optimization Multicast November 2007
1. Introduction
[I-D.irtf-mobopts-mmcastv6-ps] specifies the problem scope for a
multicast mobility management which is further subdivided into two
categories: multicast listener mobility and multicast sender
mobility. In this memo, only the former is dealt with.
The problem of achieving seamless multicast listener mobility is then
further analyzed in three aspects:
1. Ensuring multicast reception even in visited networks without
appropriate multicast support.
2. Realizing native multicast forwarding whenever applicable to
preserve network resources and avoid data redundancy.
3. Expediting primary multicast forwarding at handovers.
Items 1 and 2 are discussed in this document, while item 3 is handled
in [I-D.xia-mipshop-fmip-multicast].
MIPv6 [RFC3775] has specified two basic methods for mobile multicast:
1)via a bi-directional tunnel from MN to its HA (Home Agent), which
is called Home Subscription; 2) via a local multicast router on the
foreign link being visited, which is called Remote Subscription. In
Home Subscription, MN tunnels its multicast group membership control
packets to its HA, and the HA forwards multicast packets down the
tunnel to the MN . In Remote Subscription, the local multicast
router MUST terminate MLD messages. These two basic methods can
retain multicast communications when MN moves, but some issues still
exist.
o Home Subscription suffers from triangle route which is composed of
MN- HA tunnel and HA-S (multicast source server) multicast tree
path. When the MN is far from its HA, the data forwarding path of
multicast becomes sub-optimal.
o Although the multicast path in Remote Subscription is optimal,
frequent handoffs of MN among subnets will produce much latency.
Because when MN handovers, it will leave and re-join multicast
groups frequently.
As to unicast traffic, there are two possible modes in [RFC3775] for
communication between the mobile node and a correspondent node, that
is, bi-directional tunneling and route optimization. The former
provides basic IP connectivity while MN is moving, while the latter
provides efficient communication. In optimization mode, routing
packets directly to the mobile node's care-of address allows the
Xia & Sarikaya Expires May 9, 2008 [Page 3]
Internet-Draft Optimization Multicast November 2007
shortest communications path to be used. It also eliminates
congestion at the mobile node's home agent and home link.
Borrowing some ideas from unicast traffic optimization, this document
proposes an optimized solution for a multicast listener.
Subscription from home network provides basic multicast service
availability, while subscription from visited network provides
optimal multicast traffic delivery. The combination of two methods
is a comprehensive solution which is preliminarily referred to in
[Progress and Challenges].
2. Terminology
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 [RFC2119].
The terminology in this document is based on the definitions in
[RFC3775], in addition to the ones specified in this section.
Multicast Services Capability: multicast traffic forwarding
capability of a multicast router. Different multicast routers
probably have different capability because of different local
policy, router processing capability and so on. In this memo, MN
can receive multicast traffic from HA or local AR. These two
entities probably have different capability to provide multicast
service because of different administrative domain, different
processing capability and so on.
3. Solution Overview
The Home Subscription or bi-directional tunneling relies on Mobile
IPv6 architectural entities ( HA and MN ) and uses a multicast router
(which is probably collocated with HA or not) on the home network.
If the multicast router is physically separated from HA, the HA
operates as a MLD proxy [RFC4605]. For simplification, this memo
only considers the situation that HA acts as a multicast router.
This simplification does not affect the operation defined in the
document.
To join a multicast group, MN establishes a bi-directional tunnel
with its HA and tunnels its membership report message to the HA.
This is encapsulated within the same tunnel header used for routing
unicast packets between MN and HA. HA intercepts the membership
message and sends a join message to an upstream router using
multicast control protocols (e.g. [RFC4601]). Once the multicast
Xia & Sarikaya Expires May 9, 2008 [Page 4]
Internet-Draft Optimization Multicast November 2007
branch is established, the HA forwards the incoming multicast packets
down the tunnel to the MN.
When the mobile receiver moves to a new foreign network, it does not
need to re-join the multicast group since the HA is already informed
about its membership. This approach suffers from triangular routing
across the home network, which may increase join latency. Moreover,
tunnel via HA incurs overhead at the home network.
With the Remote Subscription approach, MN joins a multicast group
through a local multicast router on a foreign network. To join a
multicast group, MN sends its membership report to the local
multicast router (i.e. Access Router) located on the visited
network. The local multicast router intercepts this membership
report message and joins the requested multicast group. After
handover to a new network, MN sends a new membership report message
to a new Access Router acting as a multicast router. The main
problem with the Remote Subscription is that the multicast services
capability provided by HA is probably different from AR. That is, HA
can join some multicast group while AR can not.
Multicasting according to current standards (e.g. MLDv2 [RFC3810])
has drawbacks compared to unicasting when one applies it to
commercial services. Accounting of each user's actions is not
possible with multicasting as it is with unicasting.
[I-D.ietf-mboned-maccnt-req] proposes requirements for AAA in well
managed IP multicasting services. In MIPv6 scenario, HA is a default
multicast service provider for MN. If MN wants to subscribe
multicast service directly from AR, some AAA operation may be
performed. So, when MN in a foreign link wants to subscribe to a
multicast group, it sends its membership report to HA by default.
While MN receives multicast traffic from HA, MN initiates a Remote
Subscription by sending membership report. After successful Remote
Subscription, MN notifies HA to stop delivery of corresponding
multicast traffic, but hold the multicast membership in HA, as will
be described further in the later.
During handover, there is a multicast service negotiation between
Previous Access Router(PAR) and New Access Router (NAR). That is,
PAR presents MN's multicast services to NAR, and NAR replies with
supported multicast services based on its local policy. If the
multicast services (multicast group) are not supported by NAR, MN
then reverts to Home Subscription .
4. Solution Detail
Xia & Sarikaya Expires May 9, 2008 [Page 5]
Internet-Draft Optimization Multicast November 2007
4.1. Local Multicast Service Discovery
When MN wants to switch from Home Subscription to Remote
Subscription, MN should learn the multicast service capability
provided by local multicast routers. To do so, MN presents its
existing multicast services to AR, and AR acknowledges the multicast
services which can be provided locally.
MN sends its existing multicast services to AR through State Change
Report [RFC3810] once the IP connectivity with AR is established. AR
sends a Multicast Listening State Advertisement which is detailed in
Section 5.2. In this message, AR tells MN which multicast services
can be provided locally, so MN switches corresponding Home
Subscriptions to Remote Subscriptions.
4.2. Multicast Group Membership Management in HA
When MN use Remote Subscription, HA MAY terminate its packet
forwarding to the MN. However, to preserve its ability to restart
fast packet forwarding, it may be desirable for HA to remain part of
the multicast delivery tree. The Home Subscription is kept active by
a new membership message called Multicast Listener Hold defined in
Section 5.1 sent by MN to its HA. When MN performs Remote
Subscription, it sends Multicast Listener Hold message to HA for
stopping corresponding multicast traffic forwarding while keeping the
multicast membership. When MN reverts from Remote Subscription to
Home Subscription, it sends a message to restart the multicast
traffic forwarding quickly.
When MN wishes to leave a multicast group and sends Multicast
Listener Report to HA, a specific query is supposed to be sent by HA
to check if other listeners for the same group are present on the
link. But because the tunnel is per MN, HA should not send the
specific query message to relieve traffic.
5. MLDv2 Extension
5.1. Multicast Listener Hold-Release
This message is to notify a multicast router (e.g. HA) to stop
forwarding multicast data for the groups specified, but still
maintain the multicast membership on that interface. The message has
twofold functions: stopping forwarding a multicast traffic and
resuming forwarding. The following figure is Multicast Listener
Report format defined in [RFC3810]. Based on this, a code field is
designed for Multicast Listener Hold-Release message.
Xia & Sarikaya Expires May 9, 2008 [Page 6]
Internet-Draft Optimization Multicast November 2007
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 143 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Nr of Mcast Address Records (M)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Address Record [1] |
. .
. ... .
| Multicast Address Record [M] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type and other fields are defined in [RFC3810].
An 8-bit Code field is defined. Code value
1 is used to activate forwarding multicast traffic specified in the
message,
2 is used to stop forwarding while hold the membership of the
specified multicast address records.
5.2. Multicast Listening State Advertisement
Multicast Listening State Advertisement is sent by multicast routers
to advertise available multicast services for MN. The format of the
message is similar to Multicast Listener Report Message in [RFC3810].
Xia & Sarikaya Expires May 9, 2008 [Page 7]
Internet-Draft Optimization Multicast November 2007
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 143 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Nr of Mcast Address Records (M)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [1] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [N] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2.1. Type
A new message type is defined , and the value SHOULD be allocated by
IANA.
5.2.2. Reserved and Checksum
These fields have the same meaning as the fields define in Multicast
Listener Report Message [RFC3810].
5.2.3. Nr of Mcast Address Records (M)
The Nr of Mcast Address Records (M) field specifies how many
Multicast Address Records are present in this Report.
5.2.4. Multicast Address Record
Each Multicast Address Record is a block of fields that contain
multicast groups information that MN can subscribe on the link from
which the advertisement is sent.
Xia & Sarikaya Expires May 9, 2008 [Page 8]
Internet-Draft Optimization Multicast November 2007
6. Security Considerations
Home Subscription shares bi-directional tunnel which is built for
unicast traffic. HA and MN has a security association to protect the
tunnel. As for Remote Subscription, there is no addition threats
introduced comparing with MLDv2 [RFC3810].
7. IANA consideration
8. Acknowledgements
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[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.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
9.2. Informative references
[Progress and Challenges]
Jelger, C. and T. Noel, "Multicast for Mobile Hosts in IP
Networks: Progress and Challenges", IEEE Wireless Comm.,
2002.
[I-D.irtf-mobopts-mmcastv6-ps]
Schmidt, T. and M. Waehlisch, "Multicast Mobility in
MIPv6: Problem Statement and Brief Survey",
draft-irtf-mobopts-mmcastv6-ps-01 (work in progress),
July 2007.
Xia & Sarikaya Expires May 9, 2008 [Page 9]
Internet-Draft Optimization Multicast November 2007
[I-D.xia-mipshop-fmip-multicast]
Xia, F. and B. Sarikaya, "FMIPv6 extension for Multicast
Handover", draft-xia-mipshop-fmip-multicast-01 (work in
progress), March 2007.
[I-D.ietf-mboned-maccnt-req]
He, H., "Requirements for Multicast AAA coordinated
between Content Provider(s) and Network Service
Provider(s)", draft-ietf-mboned-maccnt-req-05 (work in
progress), October 2007.
Xia & Sarikaya Expires May 9, 2008 [Page 10]
Internet-Draft Optimization Multicast November 2007
Authors' Addresses
Frank Xia
Huawei USA
1700 Alma Dr. Suite 100
Plano, TX 75075
Phone: +1 972-509-5599
Email: xiayangsong@huawei.com
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 100
Plano, TX 75075
Phone: +1 972-509-5599
Email: sarikaya@ieee.org
Xia & Sarikaya Expires May 9, 2008 [Page 11]
Internet-Draft Optimization Multicast November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Xia & Sarikaya Expires May 9, 2008 [Page 12]