One document matched: draft-jaehwoon-netext-flowmob-00.txt
netext Working Group Jaehwoon Lee
Internet-Draft Dongguk University
Intended status: Informational Yoonyoung An
Expires: January 2, 2011 Byungjun Ahn
ETRI
July 3, 2010
Flow-based mobility support in Proxy Mobile IPv6
draft-jaehwoon-netext-flowmob-00.txt
Abstract
IN Proxy Mobile IPv6 (PMIPv6), a multi-homed MN can connect to the
PMIPv6 by using only one interface even though it has multiple
interfaces. It would be efficient when such a multi-homed MN can
connect to the PMIPv6 by using all of its interfaces. If such a
multi-homed MN can utilize all of its interfaces, flow mobility can
be provided that the MN handovers one or more flows from one
interface to another without re-establishing sessions. This document
specifies the layer-3 based flow mobility mechanism by considering
the intention of the MN. Here, a MN chooses the interface for sending
the service traffic and transmits the traffic by using the chosen
interface. The PMIPv6 domain can know the intention of the MN when a
MAG receives a service flow via a specific network.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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.
Jaehwoon Lee, et al. Expires Jan. 2, 2011 [Page 1]
Internet-Draft Flow-based mobility support July 3, 2010
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 2, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction..................................................3
2. Terminology...................................................4
3. Protocol operation............................................4
4. Security Considerations.......................................6
5. IANA Considerations...........................................6
References.......................................................6
Author's Addresses...............................................7
Jaehwoon Lee, et al. Expires Jan. 2, 2011 [Page 2]
Internet-Draft Flow-based mobility support July 3, 2010
1. Introduction
The Proxy Mobile IPv6 (PMIPv6) is considered as the network-based
mobility management mechanism that the access network within the
PMIPv6 domain support the mobility of the mobile node (MN) on
behalf of the MN itself [1]. In PMIPv6, the Mobile Access Gateway
(MAG) is defined to support the mobility of an MN. The MAG acts as
the default gateway of the access link to which an MN is connected.
Also, the Localized Mobility Anchor (LMA) is defined as the Home
Agent within the PMIPv6 domain.
IN PMIPv6, a multi-homed MN can connect to the PMIPv6 by using only
one interface even though it has multiple interfaces. It would be
efficient when such a multi-homed MN can connect to the PMIPv6
by using all of its interfaces. If such a multi-homed MN can utilize
all of its interfaces, flow mobility can be provided that the MN
handovers one or more flows from one interface to another without
re-establishing sessions.
However, as described before, the PMIPv6 is the network-based
mobility management protocol, and PMIPv6 domain cannot know the
intention of the MN. Therefore, it does not reflect the intention
of the MN for the PMIPv6 domain to statically assign the interface
for a specific flow. For example, assume that a MN connects both to
3GPP network via an interface and Wireless LAN via another interface
and exchange the VoIP traffic with the host resided in the Internet.
Then some users prefer to utilize the 3GPP network that satisfies
the QoS requirement of the VoIP traffic. On the other hand, other
users prefer to utilize the Wireless LAN due to its high speed and
low cost.
This document specifies the layer-3 based flow mobility mechanism by
considering the intention of the MN. In this document, the service
flow is defined by using the 5-tuple composed of source IP address,
destination IP address, protocol ID of the transport layer protocol,
source port number and destination port number. Here, a MN chooses
the interface for sending the service traffic and transmits the
traffic by using the chosen interface. The PMIPv6 domain can know the
intention of the MN when a MAG receives a service flow via a specific
network.
Jaehwoon Lee, et al. Expires Jan. 2, 2011 [Page 3]
Internet-Draft Flow-based mobility support July 3, 2010
2. Terminology
Flow Mapping Table Entry (FMTE)
The entry that support the flow handover. The 5-tuple information
identifying the service flow is included in the entry. The tunnel
end-point address for the service flow is also included.
Service Flow (SF)
The flow that is exchanged between two end hosts. The SF is
identified by using the 5-tuple information including source IP
address, destination IP address, protocol ID of the transport
layer protocol, source port number and destination port number.
3. Protocol Operation
MN-IF1 MN-IF2 MAG1 MAG2 LMA (Internet) CN
| | | | | |
|----------------->| | | |
| L2 attachment |---------- PBU ------------>| |
| | |<------ PBAck(HNP1) --------| |
|<--- RA(HNP1) ----| | |
| | | | |
(Configure HoA1 to IF1) | | | |
|<~~~~~~~~~~~~~~~~>|<~~~~~~~~~ Flow ~~~~~~~~~~~>|<~~~~~~~~~~~>|
| |----------------->| | |
| | L2 Attachment |------ PBU ------>| |
| | | |<-----------------| |
| |<-----------------| PBAck(HNP2,HNP1) | |
| | RA(HNP2,HNP1) | | |
| (Configure HoA2 to IF2) | | |
| | |<---------------------------| |
|<-----------------| PBAck(HNP1,HNP2) | |
| RA(HNP1,HNP2) | | | |
(Flow mobility from IF1 to IF2) | | |
| |~~~~~~ SF1 ~~~~~~>| | |
| | (create FMTE) | |
| | | |~~~~~~ SF1 ~~~~~~>| |
| | | | (create FMTE) |
| | | | |~~~ SF1 ~~~>|
| | | | |<~~ SF1 ~~~>|
| | | |<~~~~ SF1 ~~~~> | |
| |<~~~~ SF1 ~~~~> | | |
Figure 1: Message exchange scenario
Jaehwoon Lee, et al. Expires Jan. 2, 2011 [Page 4]
Internet-Draft Flow-based mobility support July 3, 2010
In this document, MN is assumed to follow the weak host model [2].
Figure 1 shows the message exchange scenario considered in this
document. it is assument that a MN is equipped with 2 interfaces
and can simultaneouly connect to 2 access network each having
different access technology within the PMIPv6 domain. In reality,
the MN can be equipped with N interfaces.
When a MN enters a PMIPv6 domain and connect to a MAG (say, MAG1)
with one of its interfaces (say, IF1), MAG1 transmits the Proxy
Binding Update (PBU) message having the MN-ID to LMA as described
in the PMIPv6 protocol. LMA assignes a network prefix (say, HNP1)
for the MN and creates the binding cache entry for the MN. The
HNP1 and Proxy-CoA1 information is include in the binding cache
entry, where the Proxy-CoA1 is the IP address of the MAG1. And then,
the LMA sends the Proxy Binding Acknowledgement (PBAck) message
having HNP1 to MAG1. MAG1 having received the PBAck message announces
the Router Advertisement (RA) message to the MN. The HNP1 information
is included in the RA message. MN assigns one IPv6 address
(say, MN-HoA1) that belongs to the HNP1. Form now on, MN can
communicate with a host resided in the Internet. Assume that the MN
establishes a VoIP session with a correspondent node (CN) in the
Internet by using the IF1 and exchanges the service flow (say SF1).
The SF1 can be classified with 5-tuple information having MN-HoA1,
the IP address of CN, protocol IP of the transport layer protocol,
source port number and destination port number. While exchanging SF1
by using IF1, if the MN connects to another MAG (say, MAG2) within
the same PMIPv6 domain by using another interface (say, IF2), MAG2
sends the PBU message having the MN-ID to the LMA. The LMA checks
if there exists the binding cache entry for the MN. If it exists,
the LMA checks the access technology type (ATT) that is included in
the PBU message. If the value of the ATT is different, the LMA
considers that the MN wants to connect to the PMIPv6 domain by using
both two interfaces (that is, two different networks). The LMA
assigns another network prefix (say, HNP2) for the MN and adds
HNP2 and Proxy-CoA2 information in the binding cache entry for the MN
where Proxy-CoA2 is the IP address of the MAG2. And then, the LMA
sends the PBAck message having HNP2 and HNP1 to MAG2. The LMA also
sends the PBAck message having HNP1 and HNP2 to MAG1.
MAG2 having received the PBAck message can know that the MN wants to
connect to the PMIPv6 domain via multiple access networks by using
the number of network prefixes within the message. MAG2 transmits the
RA message having HNP2 and HNP1 to the MN. MN having received the RA
message via IF2 configures one of the IPv6 address (say, MN-HoA2)
belonging to HNP2 to IF2. MAG1 having received the PBAck message also
can know that the MN wants to connect to the PMIPv6 domain via
multiple access networks by using the number of network prefixes
Jaehwoon Lee, et al. Expires Jan. 2, 2011 [Page 5]
Internet-Draft Flow-based mobility support July 3, 2010
within the message. MAG1 transmits the RA message having HNP1 and
HNP2 to the MN. The MN finds that the IP address already configured
to the IF1 is the subset of the HNP1 that is the first network prefix
included in the RA message. From now, the MN knows that a multi-homed
connection is established between it and the PMIPv6 domain. The MN
can exchange traffic via any one of two interfaces.
After the IP address is configured in the IF2, if the MN decides to
handover the VoIP traffic exchanged with the CN from IF1 to IF2, it
transmits the service flow (that is, SF1) via IF2. How the MN decides
to handover is out of scope of this document. The MAG2 having
received the SF1 identifies that the source address of SF1 belongs to
HNP1 (not HNP2) and considers that the MN wants the flow handover.
MAG2 creates the flow mapping table entry (FMTE) for the MN. The
5-tuple information for the SF1 is included in the FMTE for the MN.
And then, the MAG2 sends the SF1 to LMA via the tunnel established
between the LMA and the MAG2. The LMA havind received the SF1
identifies that the MN wants the flow handover for the flow. The LMA
creates the FMTE for the MN that includes 5-tuple information for SF1
and the IP address of the MAG2 (that is, Proxy-CoA2). And then the
LMA transmits the SF1 to the CN. When the LMA receives the SF1
transmitted by the CN, it checks the FMTE. If the LMA finds the entry
matching the same 5-tuple information with the SF1, it transmits
the SF1 to the MAG2 via the tunnel. Here, the IP address of the MAG2
is also included in the SMTE. MAG2 also sends the SF1 to the MN after
having checked its FMTE for the MN.
4. Security Consideration
TBD.
5. IANA Considerations
TBD.
References
[1] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury and
B. Patil, "Proxy Mobile IPv6", RFC 5213, Aug. 2008.
[2] R. Braden, "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, Oct. 1989.
Jaehwoon Lee, et al. Expires Jan. 2, 2011 [Page 6]
Internet-Draft Flow-based mobility support July 3, 2010
Author's Addresses
Jaehwoon Lee
Dongguk University
26, 3-ga Pil-dong, Chung-gu
Seoul 100-715, KOREA
Email: jaehwoon@dongguk.edu
Yoon-Young An
Network Research Division, ETRI
Jeonmin-Dong, Yusung-Gu
Daejeon, Chungnam, Korea
Email: yyahn@etri.re.kr
Byung-Jun Ahn
Network Research Division, ETRI
Jeonmin-Dong, Yusung-Gu
Daejeon, Chungnam, Korea
Email: bjahn@etri.re.kr
Jaehwoon Lee, et al. Expires Jan. 2, 2011 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-24 05:41:27 |