Network Working Group F. Xia
Internet-Draft B. Sarikaya
Intended status: Standards Track Huawei USA
Expires: September 3, 2007 March 2, 2007
FMIPv6 extension for Multicast Handover
<draft-xia-mipshop-fmip-multicast-01.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 September 3, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Xia & Sarikaya Expires September 3, 2007 [Page 1]
Internet-Draft FMIP extension for Multicast March 2007
Abstract
FMIPv6 extends Mobile IPv6 for reducing handover delays. But it does
not deal with the scenario that an MN joins multicast trees using
it's CoA in a visited link. The document proposes an extension to
FMIPv6 to handle local multicast traffic during handover.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Operation of Multicast Fast Handover . . . . . . . . . . . . . 4
4.1. Predictive Fast Handover . . . . . . . . . . . . . . . . . 5
4.2. Reactive Fast Handover . . . . . . . . . . . . . . . . . . 6
4.3. Handover Latency Analysis . . . . . . . . . . . . . . . . 6
5. New Options . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Multicast Group Information Option . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Xia & Sarikaya Expires September 3, 2007 [Page 2]
Internet-Draft FMIP extension for Multicast March 2007
1. Introduction
[MULTICASTPS] specifies the problem scope for a multicast mobility
management. The attempt is made to subdivide the various challenges
according to their originating aspects and to present existing
proposals for solution. There are two general multicast mobility
problems, that is, Multicast Source Mobility and Multicast Listener
Mobility. This draft only deals with the latter.
The mobility support for IPv6 protocol [MIP] has specified two basic
methods for mobile multicast:
1. via a bi-directional tunnel from a MN to its Home Agent. The MN
uses its home address to send MLD(Multicast Listener Discovery)
messages. The MLD messages are tunneled to its Home Agent.
2. via a local multicast router on the foreign link being visited.
the MN MUST use its care-of address when sending MLD packets
Fast Mobile IPv6 [FMIPv6] extends Mobile IPv6 for reducing handover
delays. But it does not deal with the scenario that an MN joins
multicast trees using it's CoA in a visited link. The scenario
occurs in emerging mobile IPTV deployments. This draft proposes an
elaborate way to handle the problem, that is, in handover
preparation, a PAR informs a NAR to build related multicast deliver
trees; during handover, the NAR buffers multicast traffic; after
handover, The NAR sends the buffered traffic as soon as possible.
These benefits can be achieved through extension of Fast Handover for
Mobile IPv6 [FMIPv6]
The document continues in Section 2 to define the terminology used
and then Section 3 states the problem, Section 4 defines the protocol
operation, Section 5 introduces a new option, Section 6 discusses the
security considerations. Finally, Section 7 concludes the document.
Xia & Sarikaya Expires September 3, 2007 [Page 3]
Internet-Draft FMIP extension for Multicast March 2007
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 BCP 14 [STANDARDS].
The terminology in this document is based on the definitions in
[FMIPv6], in addition to the ones specified in this section
Local Multicast Traffic: Multicast traffic delivered to an MN not
through the MN's HA. In this case the MN joins multicast trees using
it's CoA. But in fact, the MN joins multicast group using local link
address as source address [MLDv2] not CoA, but it does not affect the
problem statement and solution proposed in this document
3. Problem Statement
FMIPv6 extends Mobile IPv6 for reducing handover delays. But it does
not deal with the scenario that an MN joins multicast trees using
it's CoA in a visited link when handover occurs. There are two
problems in this scenario. One is that PAR can't deliver temporarily
multicast traffic to the MN at NAR during handover, because PAR has
no idea about the MN's multicast membership. This could be handled
by a small extension of FMIPv6 proposed in this document. The second
problem is how to prevent multicast joins and this needs to be
addressed with other context transfer [RFC4067] which is out of the
memo's scope .
4. Operation of Multicast Fast Handover
In Multicast Fast Handover (MFH), the mobile node joins multicast
groups such as IPTV sessions using its care-of address (CoA).
MFH extends FMIPv6 signaling as follows:
1. An MN sends FBU message with Multicast Group Information to
notify PAR tunneling related multicast traffic to NAR .
2. PAR sends HI message with Multicast Group Information to notify
NAR establishing related multicast deliver trees in advance.
3. PAR tunnels all multicast packets to NAR.
We explain MFH operation for the predictive and reactive fast
handover modes of FMIPv6.
Xia & Sarikaya Expires September 3, 2007 [Page 4]
Internet-Draft FMIP extension for Multicast March 2007
4.1. Predictive Fast Handover
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
|------FBU----------->|--------HI--------->|
| |<------HAck---------|
| <--FBack---|--FBack---> |
| | |
disconnect forward |
| packets===============>|
| | |
| | |
connect | |
| | |
|--------- FNA --------------------------->|
|<=================================== deliver packets
| |
Figure 1: Predictive Fast Handover
Figure 1 is characterized as "predictive" mode of operation.
1. With interaction of RtSolPr and PrRtAdv, the MN formulates a
prospective NCoA and learns some information about the NAR.
2. The purpose of the FBU is to authorize PAR to bind PCoA to NCoA,
so that arriving packets can be tunneled to the new location of
MN. Upon receiving FBU, PAR sends HI message. FBU and HI
include Multicast Group Information Option (MGIO). The option
which is defined in Section 5.1 consists of the multicast groups
that the MN is a member of and other related information needed
in [MLDv2].
3. If NAR already has the state for the multicast groups in MGIO, no
action is required. Otherwise, NAR constructs new multicast
delivery trees for any new multicast group. For example, in
PIM-SM [PIM-SM], On receiving the MN's expression of interest,
NAR then sends a PIM Join message towards a router which is the
root of the non-source-specific distribution tree for the
multicast group. The Join message travels hop-by-hop towards the
root router for the group, and in each router it passes through,
multicast tree state for the group is instantiated
4. When HAck message is received, the PAR MUST deliver all the
traffic , unicast and multicast traffic, to NAR for buffering
through the established tunnel.
Xia & Sarikaya Expires September 3, 2007 [Page 5]
Internet-Draft FMIP extension for Multicast March 2007
5. Once FNA is received, the NAR delivers all the buffered packets
to the MN.
6. On finishing IPv6 network attachment, the MN initiates multicast
signaling procedure using its new CoA. At the same time, the MN
receives buffered multicast traffic from the NAR and tunneled
traffic from the PAR. When multicast delivery trees are
constructed, the PAR stops delivering multicast traffic to MN
while the NAR delivers multicast traffic directly.
4.2. Reactive Fast Handover
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|------FNA[FBU]-------|------------------->|
| |<-----FBU-----------|
| |------FBack-------->|
| forward |
| packets===============>|
| | |
|<=================================== deliver packets
| |
Figure 2: Reactive Fast Handover
Figure 2 is characterized as "reactive" mode of operation. An MN
MUST include Multicast Group Information Option in FBU which is
encapsulated in FNA. Once receiving FBU, the PAR establishes a
tunnel to MN and delivers related multicast traffic to the MN. At
the same time, the MN initiates multicast signaling with NCoA in the
visited network. Once the NAR has constructed related multicast
deliver trees the NAR delivers multicast traffic directly.
4.3. Handover Latency Analysis
When an MN moves from one AR to another AR, the overall multicast
handover consists of link layer(L2) delays, network layer(L3)
attachment delays, and multicast signaling delays:
HO time = L2 delay + L3 network attachment delays + multicast
signaling delays.
Xia & Sarikaya Expires September 3, 2007 [Page 6]
Internet-Draft FMIP extension for Multicast March 2007
FMIPv6 reduces HO time especially in predictive mode. L2 delay is
unavoidable, while buffering related multicast traffic in an NAR can
reduce the affect of a handover delay. IPv6 network attachment
commonly includes activities such as default router discovery, CoA
configuration and its DAD. Through RtSolPr and PrRtAdv interactions,
an MN can finish the network attachment before link layer handover.
Multicast signaling consists of joining multicast groups and
constructing multicast delivery trees. Through tunnel between a PAR
and a NAR, older delivery trees can be used before new delivery trees
are constructed.
5. New Options
This draft introduces one new option.
5.1. Multicast Group Information Option
One or more Multicast Group Information Options SHOULD be included in
the message FBU and HI.
Xia & Sarikaya Expires September 3, 2007 [Page 7]
Internet-Draft FMIP extension for Multicast March 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 | Length | Record Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Multicast Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address [1] +
| |
. . .
| |
+ Source Address [N] +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Multicast Group Information Option
Type: TBD
Length: The size of this option in 8 octets. The option is variable
Reserved: MUST be set to zero
Record Type: refer to section 5.2.5 in [MLDv2].
Multicast Address: the multicast group address
Source Address: a vector of N unicast addresses of the senders of
this multicast group.
6. Security Considerations
This memo is based on FMIPv6, and no additional messages are defined.
No additional threats are introduced. For a more analysis, see
Xia & Sarikaya Expires September 3, 2007 [Page 8]
Internet-Draft FMIP extension for Multicast March 2007
related section. [FMIPv6]
7. Conclusions
We presented a simple extension to FMIPv6 to transfer local multicast
traffic of an MN from PAR to NAR during handover. We also defined a
new option to be used in FMIPv6 messages.
8. References
8.1. Normative References
[FMIPv6] Ed., R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005, <ftp://ftp.isi.edu/in-notes/rfc4068>.
[MIP] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004,
<ftp://ftp.isi.edu/in-notes/rfc3775>.
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004,
<ftp://ftp.isi.edu/in-notes/rfc3810>.
[PIM-SM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006,
<ftp://ftp.isi.edu/in-notes/rfc4601>.
[STANDARDS]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997,
<ftp://ftp.isi.edu/in-notes/rfc2119>.
8.2. Informative References
[MULTICASTPS]
Schmidt, Thomas C. and Matthias. Waehlisch, "Multicast
Mobility in MIPv6: Problem Statement", March 2007,
<draft-schmidt-mobopts-mmcastv6-ps-02.txt>.
[RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli,
"Context Transfer Protocol (CXTP)", July 2005,
<ftp://ftp.isi.edu/in-notes/rfc4067>.
Xia & Sarikaya Expires September 3, 2007 [Page 9]
Internet-Draft FMIP extension for Multicast March 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: bsarikaya@huawei.com
Xia & Sarikaya Expires September 3, 2007 [Page 10]
Internet-Draft FMIP extension for Multicast March 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 September 3, 2007 [Page 11]