Internet DRAFT - draft-sijeon-netext-mmag-pmip
draft-sijeon-netext-mmag-pmip
NETEXT WG S. Jeon
Internet Draft Instituto de Telecomunicacoes
Intended status: Standard Track B. Sarikaya
Expires: April 16, 2013 Huawei
R. L. Aguiar
Universidade de Aveiro
October 15, 2012
Network Mobility Support using Mobile MAG in Proxy Mobile IPv6 Domain
draft-sijeon-netext-mmag-pmip-00.txt
Abstract
This draft specifies IP mobility support protocol for moving network
including mobile nodes (MNs) over Proxy Mobile IPv6 network by
introducing a new functional entity, mobile MAG (mMAG) on the moving
network. The mMAG takes charge of MN's movement detection, binding
update on behalf of MNs as a mobile access gateway (MAG) does in
PMIPv6 infrastructure. This protocol also supports IP session
continuity for a mobile node to move between mobile network and fixed
MAG. This protocol does not require any modification or extension on
the MN.
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
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Jeon, et al. Expires April 16, 2013 [Page 1]
Internet-Draft NEMO Support in PMIPv6 Domain October 2012
This Internet-Draft will expire on April 16, 2013.
Copyright Notice
Copyright (c) 2012 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 Simplified BSD License.
Table of Contents
1. Introduction ................................................ 3
2. Conventions and Terminology.................................. 3
3. Overview .................................................... 4
3.1. Initial Attach ......................................... 4
3.2. mMAG Handoff ........................................... 6
3.3. Mobile Node Handoff..................................... 6
4. mMAG Operation .............................................. 7
5. LMA Operation ............................................... 7
6. MAG Operation ............................................... 7
7. MN Operation ................................................ 7
8. IANA Considerations ......................................... 8
9. Security Considerations...................................... 8
10. References ................................................. 8
10.1. Normative References................................... 8
10.2. Informative References................................. 8
Authors' Addresses ............................................. 9
Jeon, et al. Expires January 16, 2013 [Page 2]
Internet-Draft NEMO Support in PMIPv6 Domain October 2012
1. Introduction
Network mobility is a novel concept for handling a group of nodes
within a moving vehicular area. It provides an effective way for
wireless hosts to access the Internet through an intermediate router
connecting to an external wireless wide access network.
Proxy Mobile IPv6 (PMIPv6) is a network-based IP mobility protocol,
taking charge of host movement detection, binding update on behalf of
mobile nodes (MNs). It does not require any modification on mobile
node and thus provides better mobility performance compared to host-
based mobility protocol, e.g. Mobile IPv6 [RFC6275]. However, it does
not support network mobility in the specification [RFC5213].
NEMO Basic Support protocol (NEMO-BSP) [RFC3963] addressed this issue
for allowing a host within a moving vehicle to continue their IP
sessions when the vehicle is moving between access routers. However,
NEMO-BSP employs a mobile router (MR), which requires MIPv6 client
function having host-based mobility protocol feature. According to
this fact, a MR introduced in NEMO-BSP is not aligned with network-
based PMIPv6 approach, thus it is not suited to be used in PMIPv6
domain.
This draft describes network mobility support over PMIPv6 domain by
introducing a new entity, called mobile MAG (mMAG) [N-PMIPv6], which
is responsible for detecting MN's movement, performing mobility
management operation on behalf of MNs, and managing binding update
list as a MAG does.
This draft is based on stateless IPv6 address configuration for mMAG
and MNs to configure their IP addresses not by using DHCP. This idea
does not require any modification or extension on the MN.
2. Conventions and 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 RFC 2119 [RFC2119].
This document uses the terminology defined in [RFC5213]. In addition
to, we defined Mobile MAG (mMAG) as follow.
- Mobile MAG (mMAG): A mobile router, which has a similar function
to MAG defined in PMIPv6 specification.
Jeon, et al. Expires January 16, 2013 [Page 3]
Internet-Draft NEMO Support in PMIPv6 Domain October 2012
3. Overview
3.1. Initial Attach
This sub-section describes initial attach of mMAG and MN. The mMAG is
not a mobile router (MR) having Mobile IPv6 client functionality
presented in [RFC3963]. The mMAG is the entity that performs the
mobility management on behalf of MNs within mobile network. It has
upstream and downstream interfaces; upstream interface is seen as
normal MN to a MAG and it is connected as a tunnel with a LMA over
PMIPv6 tunnel between a MAG and a LMA. Downstream interface is seen
as fixed MAG in PMIPv6 infrastructure to attached MNs. LMA sees mMAG
as a normal MN and then process initial attach process specified in
[RFC5213] for normal MN.
MN mMAG MAG LMA
| | | |
*********** mMAG attaches to MAG **************
| | | |
| |---- RS ---->| |
| | |---- PBU --->|
| | | |
| | |<--- PBA ----|
| |<--- RA -----| |
| | | |
| mMAG's IP address | |
| configuration | |
| | | |
| | | |
*********** MN attaches to mMAG ***************
| | | |
| | | |
|---- RS ---->| | |
| |-------- PBU('M')--------->|
| | | |
| |<------- PBA('M')----------|
|<--- RA -----| | |
| | | |
MN's IP address | | |
configuration | | |
| | | |
Figure 1 mMAG and MN Attachment - Signaling Call Flow
Jeon, et al. Expires January 16, 2013 [Page 4]
Internet-Draft NEMO Support in PMIPv6 Domain October 2012
Figure 1 shows the signaling call flow when the mMAG enters the Proxy
Mobile IPv6 domain. In order to enable network mobility service
support, the mMAG should be attached first to PMIPv6 domain. The MAG
on detecting the mMAG performs authentication and authorization
process as it does normal MN in [RFC5213] and then sends Proxy
Binding Update message to the LMA.
The LMA on receiving Proxy Binding Update message creates new Binding
Cache entry and assigns new prefix and associates mMAG's ID and
assigned prefix. The LMA sends Proxy Binding Acknowledgement message
including assigned prefix to the MAG. The mMAG configures its IPv6
address based on the prefix received from Router Advertisement.
Subsequently, when a MN enters into wireless range of mobile network,
the mMAG detects MN's attachment and performs NEMO service
availability of attached MN through authentication and authorization
processes. If is verified, the mMAG will be aware of the address of
the LMA to which it belongs for attached MN. The mMAG then sends
Proxy Binding Update message with setting 'M' flag to the associated
LMA. The MAG as intermediate entity between mMG and LMA will treat
this message as normal packets originated from the mMAG and send it
after encapsulating the message with destination IP address of LMA.
On receiving encapsulated Proxy Binding Update message, the LMA will
decapsulate and processes the message by adding the MN's ID to
Binding Cache with setting 'M' flag indicating that this node belongs
to a mobile network and store mMAG's source IP address as Proxy Care-
of Address in Proxy Binding Update message.
The LMA then assigns and delivers new prefix to the mMAG by sending
Proxy Biding Acknowledgement message with setting 'M' flag. The mMAG
sends Router Advertisement message to the MN. The MN configures its
stateless IPv6 address based on received prefix in Router
Advertisement message.
The MAG is transparent for exchanging signaling messages and data
packets between mMAG and LMA. 'M' flag is used to let the LMA know
that additional Binding Cache entry lookup should be allowed when it
receives packets destined MN's prefix. On receiving Proxy Binding
Update message, the LMA sets 'M' flag in Binding Cache entry of the
MN. As a result, when a LMA receives a packet destined MN's prefix
within mobile network, it performs recursive look up processing. In a
first look up, the LMA obtains the mMAG to which the MN is attached.
And in a second look up, the LMA obtains a MAG to which the mMAG of
the MN is attached. The packets will be tunneled with mMAG's IP
address and MAG's address to which mMAG belongs, for destination IP
address in inner/outer tunnel header, respectively.
Jeon, et al. Expires January 16, 2013 [Page 5]
Internet-Draft NEMO Support in PMIPv6 Domain October 2012
3.2. mMAG Handoff
The mMAG's handoff is assumed that the mMAG moves to the newly
attached mobile access gateway (n-MAG) from the previously attached
mobile access gateway (p-MAG).
The mMAG's handoff process follows normal PMIPv6 handoff specified in
[RFC5213]. The n-MAG detects mMAG attach and sends Proxy Binding
Update message to mMAG's associated LMA by following standard PMIPv6
operation.
On receiving Proxy Binding Update message from n-MAG, the LMA will
change the transport endpoint of the tunnel from p-MAG to n-MAG in
LMA Binding Cache. The LMA is not required to perform additional
operations for MNs within mMAG in Binding Cache due to mMAG's handoff
because each binding of MN and mMAG, mMAG and MAG is managed
separately. After updating Binding Cache entry of mMAG, the LMA sends
Proxy Binding Acknowledgment message to the n-MAG. The n-MAG will
send Router Advertisements containing the mMAG's home network prefix,
and this will ensure the mMAG will not detect any change with respect
to layer-3 attachment of its interface.
3.3. Mobile Node Handoff
MN mMAG MAG LMA
| | | |
| | | |
| |-De-Registration PBU('M')->|
| | | |
| |<------- PBA('M')----------|
| | | |
| MN's BCE deleted | |
| | | |
| | | |
|----------- RS ----------->| |
| | |---- PBU --->|
| | | |
| | |<--- PBA ----|
|<---------- RA ------------| |
| | | |
Figure 2 Mobile Node Handoff - Signaling Call Flow
Jeon, et al. Expires January 16, 2013 [Page 6]
Internet-Draft NEMO Support in PMIPv6 Domain October 2012
Figure 2 shows the signaling call flow for the MN's handoff from mMAG
to fixed MAG in same PMIPv6 domain. When the mMAG detects the MN
detach, it will send de-registration Proxy Binding Update with the
lifetime value of zero and setting 'M' flag to the LMA. Upon
receiving the Proxy Binding Update message, the LMA waits for amount
of time specified in [RFC5213], before it deletes the Binding Cache
entry. On accepting Proxy Binding Acknowledgment message from the LMA
the mMAG deletes the MN in the Binding Update List. On detecting new
MN, the MAG performs initial attach operation following the
specification in [RFC5213]. The LMA updates MN's Binding Cache entry
by changing Proxy CoA with the MAG's address and setting 'M' flag to
'0'.
4. mMAG Operation
A mMAG, a new functional entity, is responsible for taking charge of
MNs within mobile network to detect the MN's movements to and from
the access link and to send the Proxy Binding Update message on
behalf of the MN to the LMA as a MAG does in this document. The mMAG
has same data structure of Binding Update List a MAG has and it
emulates attached MNs by sending Router Advertisements based on each
MN's home network prefix in the Proxy Binding Update List. But when
the mMAG sends the Proxy Binding Update message to the LMA, it is
required to add 'M' flag in Proxy Biding Update message.
5. LMA Operation
When the LMA receives Proxy Binding Update message, it is not
required to recognize where the message comes from fixed MAG or mMAG
and to have knowledge of mMAG list not to extend PMIPv6 specification
possibly. However, the LMA needs to have additional element called
'M' flag in Binding Cache to distinguish which kinds of MAG the node
is attached. This is used to provide efficient mMAG handoff
management, not requiring the changes of Binding Cache of MNs within
mobile network due to mMAG's handoff and to forward the packets
destined the MN that belongs to mMAG.
6. MAG Operation
A MAG is transparent for providing network mobility support. The mMAG
attached to the MAG is treated as normal MN. No extension or
modification is required to the MAG.
7. MN Operation
No extension is required.
Jeon, et al. Expires January 16, 2013 [Page 7]
Internet-Draft NEMO Support in PMIPv6 Domain October 2012
8. IANA Considerations
This document makes no request of IANA.
9. Security Considerations
TBD
10. References
10.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC6275] C. Perkins, D. Johnson, and J. Arkko, "Mobility Support in
IPv6", IETF RFC 6275, July 2011.
[RFC5213] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and
B. Patil, "Proxy Mobile IPv6", IETF RFC 5213, August 2008.
[RFC3963] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC3963,
January 2005.
10.2. Informative References
[N-PMIPv6]I. Sogo, C. J. Bernardos, M. Calderon, A. Banchs, and A.
Azcorra, "NEMO-Enabled Localized Mobility Support for
Internet Access in Automotive Scenarios", IEEE Coms. Mag.,
vol.47, no.5, pp.152-159, May 2009.
Jeon, et al. Expires January 16, 2013 [Page 8]
Internet-Draft NEMO Support in PMIPv6 Domain October 2012
Authors' Addresses
Seil Jeon
Instituto de Telecomunicacoes
Campus Universitario de Santiago
3810-193 Aveiro, Portugal
E-mail: seiljeon@av.it.pt
Behcet Sarikaya
Huawei
5340 Legacy Dr.
Plano, TX 75024, USA
E-mail: sarikaya@ieee.org
Rui L. Aguiar
Universidade de Aveiro
3810-193 Aveiro, Portugal
E-mail: ruilaa@ua.pt
Jeon, et al. Expires January 16, 2013 [Page 9]
