NetLMM Working Group J.-H. Lee
Internet-Draft B.-J. Han
Intended status: Informational T.-M. Chung
Expires: March 24, 2009 Sungkyunkwan University
H.-J. Lim
Korea Financial Security Agency
September 20, 2008
Network Mobility Basic Support within Proxy Mobile IPv6: scenarios and
analysis
draft-jhlee-netlmm-nemo-scenarios-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 March 24, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
As Proxy Mobile IPv6 is deployed, a Mobile Network will be
initialized in or move to a Proxy Mobile IPv6 domain. In this
document, the scenarios of Network Mobility Basic Support within
Proxy Mobile IPv6 that ensure session continuance for all nodes in
Lee, et al. Expires March 24, 2009 [Page 1]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
the Mobile Network are presented. In addition, an analysis of all
scenarios that comprise the interactions between Network Mobility
Basic Support and Proxy Mobile IPv6 is provided as a guideline to
PMIPv6 deployments.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 3
2.1. Conventions used in this document . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of scenarios . . . . . . . . . . . . . . . . . . . . 5
3.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Scenario A.1 . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Scenario A.2 . . . . . . . . . . . . . . . . . . . . . 7
3.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Scenario B.1 . . . . . . . . . . . . . . . . . . . . . 8
3.2.2. Scenario B.2 . . . . . . . . . . . . . . . . . . . . . 9
3.2.3. Scenario B.3 . . . . . . . . . . . . . . . . . . . . . 9
3.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1. Scenario C.1 . . . . . . . . . . . . . . . . . . . . . 10
3.3.2. Scenario C.2 . . . . . . . . . . . . . . . . . . . . . 11
3.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.1. Scenario D.1 . . . . . . . . . . . . . . . . . . . . . 12
3.4.2. Scenario D.2 . . . . . . . . . . . . . . . . . . . . . 13
4. Chaining scenarios . . . . . . . . . . . . . . . . . . . . . . 13
5. Analysis of scenarios . . . . . . . . . . . . . . . . . . . . 13
5.1. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 13
5.1.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . 13
5.1.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . 16
5.1.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . 21
5.1.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . 24
5.2. Tunneling Management . . . . . . . . . . . . . . . . . . . 25
6. Returning Home . . . . . . . . . . . . . . . . . . . . . . . . 25
7. Multihoming Considerations . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28
Lee, et al. Expires March 24, 2009 [Page 2]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
1. Introduction
Network Mobility Basic Support (NBS) described in [1] provides that a
Mobile Network (NEMO) moves from its home link to a new link based on
Mobile IPv6 (MIPv6) [2]. The base protocol for NBS is MIPv6 and
derived scenarios therefore focused on the interactions between NBS
and MIPv6. As Proxy Mobile IPv6 (PMIPv6) is deployed [3], a NEMO
will be initialized in or move to a PMIPv6 domain. Thus, the
scenarios where NBS operates within PMIPv6 need to be analyzed as a
guideline to PMIPv6 deployments. Note that the interaction scenarios
between PMIPv6 and MIPv6 are presented in [4].
This document specifies the scenarios where NBS operates within
PMIPv6 and related issues. In addition, an analysis for each
scenario is presented. The NEMO Route Optimization is not considered
in the scenarios because this document focuses on the interactions
between NBS and PMIPv6.
2. Conventions & Terminology
2.1. Conventions used in this document
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 [5].
2.2. Terminology
Terminologies related to mobility support are defined in [3] and [6].
The following terminologies are frequently used in this document.
o Proxy Mobile IPv6 domain (PMIPv6 domain), As defined in [3], it
refers to the network where the mobility management is handled by
PMIPv6.
o Non-Proxy Mobile IPv6 domain (Non-PMIPv6 domain), It refers to the
network in where PMIPv6 is not supported.
o Mobile Network (NEMO): As defined in [6], it is an entire network
that consists of one or more subnets and involves any node (host
or router). A NEMO can be initialized at an Non-PMIPv6 domain or
at a PMIPv6 domain and move from and to different mobility
management domains. In this document, a NEMO is classified into
two types: Mobile Network-MIPv6 and Mobile Network-PMIPv6.
o Mobile Network-MIPv6 (NEMO-MIPv6): It is a NEMO that has been
initialized at an Non-PMIPv6 domain. The Home Address (HoA) of
Lee, et al. Expires March 24, 2009 [Page 3]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
NEMO-MIPv6 is configured from a prefix advertised in the home
link.
o Mobile Network-PMIPv6 (NEMO-PMIPv6): It is a NEMO that has been
initialized at a PMIPv6 domain. The HoA of NEMO-PMIPv6 is taken
from the Home Network Prefix (HNP) that is topologically anchored
at the Local Mobility Anchor (LMA) defined in [3]. From a
perspective of NEMO-PMIPv6, the LMA acts as the Home Agent (HA).
o Mobile Router (MR): As defined in [6], it is a router that acts as
a gateway in a NEMO. In this document, an MR MUST take cognizance
of that the current domain provides a PMIPv6 service or not.
o Mobile Router of Mobile Network-MIPv6 (MR-NEMO-MIPv6): It is an MR
that acts as a gateway in the current NEMO-MIPv6.
o Mobile Router of Mobile Network-PMIPv6 (MR-NEMO-PMIPv6): It is an
MR that acts as a gateway in the current NEMO-PMIPv6.
o Bi-directional Tunnel between a Mobile Router and its Home Agent
(MRHA tunnel): As defined in [6], it is a bi-directional tunnel
between an MR and its HA. In NBS, this tunnel is used to preserve
session continuance between the MR and the HA.
o Mobile Router Identifier (MR-Identifier): It is an identity for an
MR used in a PMIPv6 domain. Similar to Mobile Node Identifier
(MN-Identifier) defined in [3], mobility entities in a PMIPv6
domain MUST acquire and use it for identifying an MR. NAI or MAC
address of MR can be used as an identifier.
o Care-of Address of Mobile Router in Mobile Network-MIPv6 (CoA-
NEMO-MIPv6): It is a Care-of Address (CoA) of MR-NEMO-MIPv6
obtained in the new link. When a NEMO-MIPv6 enters to a PMIPv6
domain, the CoA is configured based on the HNP and is used as long
as the NEMO-MIPv6 is attached to the PMIPv6 domain.
o Care-of Address of Mobile Router in Mobile Network-PMIPv6 (CoA-
NEMO-PMIPv6): It is a CoA of MR-NEMO-PMIPv6 obtained in another
PMIPv6. This address is configured based on the HNP and is used
as long as the NEMO-PMIPv6 is attached to the PMIPv6 domain.
o Home Address of Mobile Router in Mobile Network-MIPv6 (HoA-NEMO-
MIPv6): It is a HoA of MR-NEMO-MIPv6 obtained in the home link.
o Home Address of Mobile Router in Mobile Network-PMIPv6 (HoA-NEMO-
PMIPv6): It is a HoA of MR-NEMO-PMIPv6 obtained in the home PMIPv6
domain. This address is configured based on the HNP defined in
[3].
Lee, et al. Expires March 24, 2009 [Page 4]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
o Mobile Network Prefix (MNP): As defined in [6], it is a network
prefix delegated to an MR that is used to advertise in the NEMO.
o Mobile Network Node (MNN): As defined in [6], it represents any
node that exists and has an address containing the MNP in a NEMO.
A MNN is classified into three types: Local Fixed Node, Visiting
Mobile Node, and Local Mobile Node.
o Local Fixed Node (LFN): As defined in [6], it represents any
normal node that has no mobility support stack. An LFN cannot
change its point of attachment while communicating with other
nodes and its address is taken from the MNP in a NEMO.
o Visiting Mobile Node (VMN): As defined in [6], it represents any
node that has a mobility support stack. A VMN is a temporarily
attached node in a NEMO. From a perspective of VMN, the NEMO is a
foreign link in where the VMN obtains its CoA from the MNP.
o Local Mobile Node (LMN): As defined in [6], it represents any node
that has a mobility support stack. From a perspective of LMN, the
NEMO is a home link in where the LMN obtains its HoA from the MNP.
o Local Mobility Anchor existing in the home PMIPv6 doamin (LMAh):
It is a Local Mobility Anchor for NEMO-PMIPv6 in the home PMIPv6
doamin.
o Local Mobility Anchor existing in the visit PMIPv6 doamin (LMAv):
It is a Local Mobility Anchor for NEMO-PMIPv6 in the visit PMIPv6
doamin.
o AAA server existing in the home domain (AAAh): It is a AAA server
for a NEMO in the home domain. The AAAh is responsible for
authenticating and authorizing the NEMO.
o AAA server existing in the visit domain (AAAv): It is a AAA server
for a NEMO in the visit domain. The AAAv is responsible for
authenticating and authorizing the NEMO. The AAAv and the AAAh
have a security association to support security credential
exchanges.
3. Overview of scenarios
Several interaction scenarios between NBS and PMIPv6 exist. In the
following scenarios, a NEMO ensure that all MNNs keep their session
continuance while the NEMO moves around. The main goal of describing
scenarios is to show how to establish the MRHA tunnel between a NEMO
and its HA when the NEMO moves within PMIPv6 domains.
Lee, et al. Expires March 24, 2009 [Page 5]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
In the all scenarios, the mobility service selection option defined
in [7] SHOULD be used to select the PMIPv6 service by a NEMO. AAA
servers are used to provide secure access service and service
parameters when the NEMO is attached in the access link. Note that
the MR-Identifier is used as like as the use of the MN-Identifier.
3.1. Scenario A
As shown in Figure 1, Scenario A describes that a NEMO moves from an
Non-PMIPv6 domain to a PMIPv6 domain. There are two identified sub-
scenarios depending on the NEMO type.
__
+-----------+ __ __ _/ \__ +----+
( Home Link ) _/ \_/ \_/ \------| CN |
( ) / / +----+
( +----+ ) / Internet \__
( |HA/ |---+---\ _ _ / \
( |LMAh| | ) \__ __/ \__/ \__/ +--\------------------------+
( +----+ | ) \__/ ( +----+ +----+ )
( | ) / ( |LMAv| |AAAv| )
( +----+ | ) / _______( +----+ +----+ )
( |AAAh|---+ ) / ( //\\ <-- LMAA )
( +----+ ) / ( +-----//--\\-----+ )
+-----------+ / ( ( // \\ )<-- IPv4/IPv6)
| ( +---//------\\---+ Network )
+-------------|---------+ ( // \\ )
( Non-PMIPv6 | ) ( //<-- pCoA1 \\<-- PCoA2 )
( Domain +----+ ) ( +----+ +----+ )
( | AR | ) ( |MAG1| |MAG2| )
( +----+ ) ( +----+ +----+ )
( : ) ( : )
( : ) ( : <-- CoA-NEMO-MIPv6 )
( +------+ ==============> +------+ /CoA-NEMO-PMIPv6 )
( +------| MR |-----+ ) ( +----| MR |-----+ )
( ( +------+ ) ) ( ( +------+ ) )
( ( / : : : ) ) ( ( / : : : ) )
( ( / : : +--+ ) ) ( ( / : : +--+) )
( ( [LFN][VMN][LMN]|MR| ) ) ( ([LFN][VMN][LMN]|MR|) )
( ( +--+ ) ) ( ( +--+) )
( ( MNP = A::/64 ) ) ( ( MNP = A::/64 ) PMIPv6 )
( +-------------------+ ) ( +-----------------+ Domain )
+-----------------------+ +------------------------------------+
Figure 1. Scenario A: a NEMO moves from an Non-PMIPv6 domain to a
PMIPv6 domain
Lee, et al. Expires March 24, 2009 [Page 6]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
3.1.1. Scenario A.1
In this scenario, a NEMO-MIPv6 that has been initialized at an Non-
PMIPv6 domain moves from another Non-PMIPv6 domain to a PMIPv6
domain.
As the NEMO-MIPv6 moves from the Non-PMIPv6 domain to the PMIPv6
domain, it attaches to one of MAGs. Similar to the MN attachment
defined in [3], the NEMO-MIPv6 MUST be authenticated and authorized
by the deployed security service mechanism. For instance, the AAA
server can be used for authenticating and authorizing the MR-NEMO-
MIPv6 based on the MR-Identifier. The serving MAG, MAG1, sends a
Proxy Binding Update (PBU) message to the LMAv. Upon accepting the
PBU message, the LMAv sends a Proxy Binding Acknowledgement (PBA)
message to the MAG1. As a result of registration, a bi-directional
tunnel between the MAG1 and the LMAv for the NEMO-MIPv6 is
established. As the MAG1 adverties a Router Advertisement (RA)
message cotaining the HNP, the MR-NEMO-MIPv6 obtains its CoA based on
the HNP. In other words, the MR in NEMO-MIPv6 configues its CoA-
NEMO-MIPv6 from the HNP in the PMIPv6 domain. The configured CoA-
NEMO-MIPv6 is registered to the HA by sending Binding Update (BU)
message as defined in [1]. The HA on receiving the BU message
establishes a binding between the HoA-NEMO-MIPv6 and CoA-NEMO-MIPv6
of MR. As a result of establishing the binding, the HA can forward
the packets for NEMO-MIPv6 to the current attachement point of MR-
NEMO-MIPv6.
3.1.2. Scenario A.2
In this scenario, a NEMO-PMIPv6 that has been initialized at a PMIPv6
domain moves from an Non-PMIPv6 domain to another PMIPv6 domain.
As the NEMO-PMIPv6 moves from the Non-PMIPv6 domain to the PMIPv6
domain, it attaches to one of MAGs. Similar to Scenario A.1, after
successful authentication and authorization for PMIPv6 service, the
registration procedure between the MAG1 and the LMAv is performed. A
point of difference between Scenario A.1 and Scenario A.2 is that the
MR-NEMO-PMIPv6 registers its CoA, CoA-NEMO-PMIPv6, to the LMAh by
sending BU message. The LMAh on receiving the BU message sent from
the MR establishes a binding between the HoA-NEMO-PMIPv6 and CoA-
NEMO-PMIPv6 of MR.
3.2. Scenario B
This scenario describes that a NEMO moves between links in a PMIPv6
domain as shown in Figure 2. There are three identified sub-
scenarios depending on the NEMO type.
Lee, et al. Expires March 24, 2009 [Page 7]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
+-----------+ +----+
( Home Link ) | CN |
( ) +----+
( +----+ ) __ /
( |HA/ |---+ ) __ __ _/ \/_
( |LMAh| | ) _/ \_/ \_/ \
( +----+ +------/ /
( | ) / Internet \
( +----+ | ) \ _ _ /
( |AAAh|---+ ) \__ __/ \__/ \__/
( +----+ ) \__/ |
+-----------+ |
|
+------------------------------|---------------------------------+
( PMIPv6 +---------+ +-------+ )
( Domain |LMAv/LMAh| | AAAv/ | )
( +---------+ | AAAh | )
( // \\ <-- LMAA +-------+ )
( +-----//----\\-----+ )
( ( // \\ )<- IPv4/IPv6 )
( +---//--------\\---+ Network )
( // \\ )
( //<--pCoA1 \\<--pCoA2 )
( +----+ +----+ )
( |MAG1| |MAG2| )
( +----+ +----+ )
( CoA-NEMO-MIPv6 : : )
( /CoA-NEMO-PMIPv6 : : )
( /HoA-NEMO-PMIPv6--> : : )
( +------+ ==========> +------+ )
( +----| MR |-----+ +----| MR |-----+ )
( ( +------+ ) ( +------+ ) )
( ( / : : : ) ( / : : : ) )
( ( / : : +--+) ( / : : +--+) )
( ([LFN][VMN][LMN]|MR|) ([LFN][VMN][LMN]|MR|) )
( ( +--+) ( +--+) )
( ( MNP = A::/64 ) ( MNP = A::/64 ) )
( +-----------------+ +-----------------+ )
+----------------------------------------------------------------+
Figure 2. Scenario B: a NEMO moves between links in a PMIPv6 domain
3.2.1. Scenario B.1
In this scenario, a NEMO-MIPv6 that has been initialized at an Non-
PMIPv6 domain moves between links in a PMIPv6 domain.
This scenario is an extension of Scenario A.1. As described in
Lee, et al. Expires March 24, 2009 [Page 8]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
Scenario A.1, the NEMO-MIPv6 has been registered at both the LMAv and
the HA. According to [3], there is no additionally registration
messages by sending the MR-NEMO-MIPv6 whenever the NEMO-MIPv6 moves
between links in the PMIPv6 domain. The serving MAG, MAG2, sends a
PBU message to the LMAv to inform that the NEMO-MIPv6 has been moved
from the MAG1 to the MAG2.
3.2.2. Scenario B.2
In this scenario, a NEMO-PMIPv6 that has been initialized at a PMIPv6
domain moves between links in another PMIPv6 domain.
This scenario is an extension of Scenario A.2. As described in
Scenario A.2, the NEMO-PMIPv6 has been registered at both the LMAv
and the LMAh. When the NEMO-PMIPv6 attaches to the MAG2, the MAG2
sends a PBU message to the LMAv.
3.2.3. Scenario B.3
In this scenario, a NEMO-PMIPv6 that has been initialized at a PMIPv6
domain moves between links in the PMIPv6 domain.
When the NEMO-PMIPv6 boots up in the PMIPv6 domain, it is registered
to the LMAh as a result of PBU message sent from the MAG1. The MR-
NEMO-PMIPv6 also creates its HoA based on the RA message including
the HNP. The created HoA, pHoA-NEMO-PMIPv6, is used to send a BU
message to the LMAh. In this scenario, the LMAh acts as the HA of
NEMO-PMIPv6. Similar to Scenario B.2, the MAG2 sends a PBU message
to the LMAh when the NEMO-PMIPv6 attaches to the MAG2.
3.3. Scenario C
This scenario describes that a NEMO moves between different PMIPv6
domains as shown in Figure 3. There are two identified sub-scenarios
depending on the NEMO type.
Lee, et al. Expires March 24, 2009 [Page 9]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
+-----------+ +----+
( Home Link ) | CN |
( ) +----+
( +----+ ) __ /
( |HA/ |---+ ) __ __ _/ \/_
( |LMAh| | ) _/ \_/ \_/ \
( +----+ +---------/ /
( | ) / Internet \
( +----+ | ) \ _ _ /
( |AAAh|---+ ) \__ __/ \__/ \__/\
( +----+ ) / \__/ \____
+-----------+ / \
/ \
+-----------------/------------+ +------------\--------------+
( PMIPv6-v1 +-----+ +-----+ ) ( PMIPv6-v2 +-----+ +-----+ )
( Domain |LMAv1| |AAAv1| ) ( Domain |LMAv2| |AAAv2| )
( +-----+ +-----+ ) ( +-----+ +-----+ )
( LMAA1 --> || ) ( LMAA2 --> || )
( +-------||-------+ ) ( +-------||-------+ )
( ( IPv4 || IPv6 ) ) ( ( IPv4 || IPv6 ) )
( +-------||-------+ ) ( +-------||-------+ )
( || ) ( || )
( || <--pCoA1 ) ( || <--pCoA2 )
( +----+ ) ( +----+ )
( |MAG1| ) ( |MAG2| )
( +----+ ) ( +----+ )
( : ) ( : )
( CoA-NEMO-MIPv6 : ) ( : )
( CoA-NEMO-PMIPv6 : ) ( : )
( +-------+ ==================> +-------+ )
( +----| MR |----+ ) ( +----| MR |----+ )
( ( +-------+ ) ) ( ( +-------+ ) )
( ( / : : : ) ) ( ( / : : : ) )
( ( / : : +--+) ) ( ( / : : +--+) )
( ([LFN][VMN][LMN]|MR|) ) ( ([LFN][VMN][LMN]|MR|) )
( ( +--+) ) ( ( +--+) )
( ( MNP = A::/64 ) ) ( ( MNP = A::/64 ) )
( +-----------------+ ) ( +-----------------+ )
+------------------------------+ +---------------------------+
Figure 3. Scenario C: a NEMO moves between different PMIPv6 domains
3.3.1. Scenario C.1
In this scenario, a NEMO-MIPv6 that has been initialized at an Non-
PMIPv6 domain moves between different PMIPv6 domains.
As the NEMO-MIPv6 moves from a PMIPv6 domain (PMIPv6-v1 domain) to
Lee, et al. Expires March 24, 2009 [Page 10]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
another PMIPv6 domain (PMIPv6-v2 domain), the CoA-NEMO-MIPv6 is
changed because the serving MAG, MAG2, advertises a RA message
including the different HNP that is previously assigned in the
PMIPv6-v1 domain. Similar to Scenario A.1, there are two types of
registration; registering to the LMAv2 and registering to the HA.
For registering to the LMAv2, the MAG2 sends a PBU message to the
LMAv2 when the MR-NEMO-MIPv6 is attached to the MAG2. As the MR-
NEMO-MIPv6 receives the RA message from the MAG2, the MR sends a BU
message to register its new CoA-NEMO-MIPv6 to the HA.
3.3.2. Scenario C.2
In this scenario, a NEMO-PMIPv6 that has been initialized at a PMIPv6
domain moves between different PMIPv6 domains.
Similar to Scenario C.1, the MAG2 registers the NEMO-PMIPv6 to the
LMAv2 by sending PBU message. The MR-NEMO-PMIPv6 on receiving the RA
message sent from the MAG2 configures its new CoA-NEMO-PMIPv6 because
the contained HNP in the RA message is a different HNP compared to
the previous HNP. After the address configuration, the MR-NEMO-
PMIPv6 informs its new CoA-NEMO-PMIPv6 to the LMAh located in the
home domain.
3.4. Scenario D
This scenario describes that a NEMO moves from a PMIPv6 domain to an
Non-PMIPv6 domain as shown in Figure 4. There are two identified
sub-scenarios depending on the NEMO type.
Lee, et al. Expires March 24, 2009 [Page 11]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
+-----------+ +----+
( Home Link ) | CN |
( ) +----+
( +----+ ) __ /
( |HA/ |---+ ) __ __ _/ \/_
( |LMAh| | ) _/ \_/ \_/ \
( +----+ +------/ /
( | ) / Internet \
( +----+ | ) \ _ _ /\
( |AAAh|---+ ) \__ __/ \__/ \__/ \
( +----+ ) /\__/ \
+-----------+ / \_______
/ \
+----------------/-----------------+ |
( PMIPv6 +----+ ) |
( Domain |LMAv| ) |
( +----+ ) |
( // \\ <-- LMAA ) |
( +------//----\\------+ ) |
( ( IPv4 // \\ IPv6 ) ) |
( +----//--------\\----+ ) +----------|----------+
( // \\ ) ( Non-PMIPv6 )
( //<--pCoA1 \\<--pCoA2 ) ( Domain +----+ )
( +----+ +----+ ) ( | AR | )
( |MAG1| |MAG2| ) ( +----+ )
( +----+ +----+ ) ( : )
( : ) ( : )
( CoA-NEMO-MIPv6 : ) ( : )
( CoA-NEMO-PMIPv6 +------+ ==============> +------+ )
( +----| MR |-----+ ) ( +----| MR |-----+ )
( ( +------+ ) ) ( ( +------+ ) )
( ( / : : : ) ) ( ( / : : : ) )
( ( / : : +--+) ) ( ( / : : +--+) )
( ([LFN][VMN][LMN]|MR|) ) ( ([LFN][VMN][LMN]|MR|) )
( ( +--+) ) ( ( +--+) )
( ( MNP = A::/64 ) ) ( ( MNP = A::/64 ) )
( +-----------------+ ) ( +-----------------+ )
+----------------------------------+ +---------------------+
Figure 4. Scenario D: a NEMO moves from a PMIPv6 domain to an Non-
PMIPv6 domain
3.4.1. Scenario D.1
In this scenario, a NEMO-MIPv6 that has been initialized at an Non-
PMIPv6 domain moves from a PMIPv6 domain to another MIPv6 domain.
As the NEMO-MIPv6 attaches to a new link in the Non-PMIPv6 domain,
Lee, et al. Expires March 24, 2009 [Page 12]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
the MR-NEMO-MIPv6 receives a RA message sent from the access router
(AR). The MR-NEMO-MIPv6 takes cognizance of that it has been moved
to a new link based on the RA message. As described in [1], the MR-
NEMO-MIPv6 sends a BU message to its HA after the adress
configuration on the new link.
3.4.2. Scenario D.2
In this scenario, a NEMO-PMIPv6 that has been initialized at a PMIPv6
domain moves from another PMIPv6 domain to an Non-PMIPv6 domain.
As the NEMO-PMIPv6 attaches to a new link in the Non-PMIPv6 domain,
the NEMO-PMIPv6 receives a RA message sent from the AR. Similar to
Scenario D.1, the MR-NEMO-PMIPv6 sends a BU message to its LMAh after
the adress configuration on the new link.
4. Chaining scenarios
Scenarios described in Section 3 SHOULD be chained according to the
movement patterns of NEMO. The chaining scenarios is defined in the
next version of this document.
5. Analysis of scenarios
This section presents the message flows for each scenario described
in Section 3. Based on the message flow, the tunneling management
issues are presented.
5.1. Message Flow
5.1.1. Scenario A
As mentioned in Section 3.1, Scenario A considers the case in where a
NEMO moves from an Non-PMIPv6 domain to a PMIPv6 domain.
5.1.1.1. Scenario A.1
Figure 5 shows the message flow when the NEMO-MIPv6 that has been
initialized at an Non-PMIPv6 domain enters from another Non-PMIPv6
domain to a PMIPv6 domain.
o The NEMO-MIPv6 enters from the Non-PMIPv6 domain to a PMIPv6
domain.
o The NEMO-MIPv6 is attached to the MAG1.
Lee, et al. Expires March 24, 2009 [Page 13]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
+-----+ +----+ +------+ +------+ +------+ +----+ +----+
| MNN | | MR | | MAG1 | | LMAv | | AAAv | | HA | | CN |
+-----+ +----+ +------+ +------+ +------+ +----+ +----+
| | | | | | |
| Movement from | | | | |
| Non-PMIPv6 domain | | | | |
| | | | | | |
| L2 Attachment | | | | |
| | L2 Attached Event | | | |
| | | | | | |
| | Authentication | | |
| |<------------------------------>| | |
| | | Parameters | | |
| | |<--------------------| | |
| | | PBU | | | |
| | |--------->| | | |
| | | PBA | | | |
| | RA(HNP) |<---------| | | |
| |<---------| | | | |
| | | | | | |
| Address | | | | |
| Configuration | | | | |
| | | BU | | | |
| |------------------------------------------>| |
| |<------------------------------------------| |
| | | BA | | | |
| | | | | | |
| | MR=HA | MAG1=LMAv| MR=HA | |
|<-------->0<========>0<########>0<===================>0<-------->|
| [CN|MNN] | | | | | [HA|MR][CN|MNN] | [CN|MNN] |
| | v | | | | | |
| [HA|MR][CN|MNN] v | | | |
| | [LMAv|MAG1][HA|MR][CN|MNN] | | |
| | | | | | |
Figure 5. Message Flow for Scenario A.1
o The authentication procedure for PMIPv6 service is done between
the MR-NEMO-MIPv6 and AAAv.
o The AAAv provides PMIPv6 service parameters including the MR-
Identifier and the corresponding Local Mobility Anchor Address
(LMAA) after successfully completing the authentication procedure.
o The MAG1 sends a PBU message to the LMAv.
o The LMAv sends a PBA message to the MAG1 after successfully
completing the binding registration procedure. As a result, the
Lee, et al. Expires March 24, 2009 [Page 14]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
bi-directional tunnel between the MAG1 and the LMAv is established
for the MR-NEMO-MIPv6.
o The MAG1 sends a RA message to the MR-NEMO-MIPv6. The RA message
includes the HNP that is the IPv6 prefix and is topologically
anchored at the LMAv.
o Based on the HNP, the MR-NEMO-MIPv6 creates its new CoA-NEMO-
MIPv6.
o The MR-NEMO-MIPv6 sends a BU message to its HA located in the home
domain.
o The HA establishes a binding between the HoA-NEMO-MIPv6 and CoA-
NEMO-MIPv6 of MR.
o Any packet destinated to the MNNs in the MR-NEMO-MIPv6 is
forwarded to the current attachement point of MR-NEMO-MIPv6
through the HA and the LMAv.
5.1.1.2. Scenario A.2
Figure 6 shows the message flow when the NEMO-PMIPv6 that has been
initialized at a PMIPv6 domain moves from an Non-MIPv6 domain to
another PMIPv6 domain. The message flow is similar to Scenario A.1.
Distinguishing differences are as follows.
o As the NEMO-PMIPv6 is attached to the MAG1, the AAAv requests the
authentication decision to the AAAh.
o As the MR-NEMO-PMIPv6 configures its new CoA-NEMO-PMIPv6 based on
the HNP contained in the RA message sent from the MAG1, it sends a
BU message to its LMAh located in the home domain.
o The LMAh on receiving the BU message sent from MR-NEMO-PMIPv6
establishes a binding between the HoA-NEMO-PMIPv6 and CoA-NEMO-
PMIPv6.
Lee, et al. Expires March 24, 2009 [Page 15]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
+-----+ +----+ +------+ +------+ +------+ +------+ +----+ +----+
| MNN | | MR | | MAG1 | | LMAv | | AAAv | | AAAh | |LMAh| | CN |
+-----+ +----+ +------+ +------+ +------+ +------+ +----+ +----+
| | | | | | | |
| Movement from | | | | | |
| Non-PMIPv6 domain| | | | | |
| | | | | | | |
| L2 Attachment | | | | | |
| | L2 Attached Event | | | | |
| | | | | | | |
| | Authentication Authentication | |
| |<--------------------------->|<------->| | |
| | | Parameters | Parameters | |
| | |<------------------|<--------| | |
| | | PBU | | | | |
| | |-------->| | | | |
| | | PBA | | | | |
| | RA(HNP) |<--------| | | | |
| |<--------| | | | | |
| | | | | | | |
| Address | | | | | |
| Configuration | | | | | |
| | | BU | | | | |
| |----------------------------------------------->| |
| |<-----------------------------------------------| |
| | | BA | | | | |
| | | | | | | |
| | MR=LMAh |MAG1=LMAv| MR=LMAh | | |
|<------>0<=======>0<#######>0<==========================>0<------>|
|[CN|MNN]| | | | | [LMAh|MR][CN|MNN] | |[CN|MNN]|
| | v | | | | | | |
| [LMAh|MR][CN|MNN] v | | | | |
| | [LMAv|MAG1][LMAh|MR][CN|MNN]| | | |
| | | | | | | |
Figure 6. Message Flow for Scenario A.2
5.1.2. Scenario B
As mentioned in Section 3.2, Scenario B considers the case in where a
NEMO moves between links in a PMIPv6 domain.
5.1.2.1. Scenario B.1
Figure 7 shows the message flow when the NEMO-MIPv6 that has been
initialized at an Non-PMIPv6 domain moves between links in a PMIPv6
domain. This scenario is an extension of Scenario A.1 or Scenario
C.1.
Lee, et al. Expires March 24, 2009 [Page 16]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
o From a perspective of the PMIPv6 domain, the MR-NEMO-MIPv6 is
treated as a node. As the MR-NEMO-MIPv6 is attached to the MAG2,
the MAG2 sends a PBU message to the LMAv on behalf of the MR-NEMO-
MIPv6.
o The MR-NEMO-MIPv6 on receiving the RA message sent from the MAG2
can continue to use the same address, CoA-NEMO-MIPv6, configured
in the previous MAG.
o Since the CoA-NEMO-MIPv6 is not changed, the MR-NEMO-MIPv6 does
not need to register its movement to the HA. According to [3],
the MR-NEMO-MIPv6 will always detect the same link as long as its
attached network is in the scope of PMIPv6 domain.
+-----+ +----+ +------+ +------+ +------+ +----+ +----+
| MNN | | MR | | MAG2 | | LMAv | | AAAv | | HA | | CN |
+-----+ +----+ +------+ +------+ +------+ +----+ +----+
| | | | | | |
| Movement from | | | | |
| a pervious MAG | | | | |
| | | | | | |
| L2 Attachment | | | | |
| | L2 Attached Event | | | |
| | | | | | |
| | Authentication | | |
| |<------------------------------>| | |
| | | Parameters | | |
| | |<--------------------| | |
| | | PBU | | | |
| | |--------->| | | |
| | | PBA | | | |
| | RA(HNP) |<---------| | | |
| |<---------| | | | |
| | | | | | |
| | MR=HA | MAG2=LMAv| MR=HA | |
|<-------->0<========>0<########>0<===================>0<-------->|
| [CN|MNN] | | | | | [HA|MR][CN|MNN] | [CN|MNN] |
| | v | | | | | |
| [HA|MR][CN|MNN] v | | | |
| | [LMAv|MAG2][HA|MR][CN|MNN] | | |
| | | | | | |
Figure 7. Message Flow for Scenario B.1
Lee, et al. Expires March 24, 2009 [Page 17]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
5.1.2.2. Scenario B.2
Figure 8 shows the message flow when the NEMO-PMIPv6 that has been
initialized at a PMIPv6 domain moves between links in another PMIPv6
domain. This scenario is an extension of Scenario A.2 or Scenario
C.2.
o Similar to the message flow of Scenario B.1, the MR-NEMO-MIPv6 is
treated as a node. The movement of NEMO-PMIPv6 is detected by the
MAG2 and the MAG2 sends a PBU message on behalf of the MR-NEMO-
PMIPv6.
+-----+ +----+ +------+ +------+ +------+ +------+ +----+ +----+
| MNN | | MR | | MAG2 | | LMAv | | AAAv | | AAAh | |LMAh| | CN |
+-----+ +----+ +------+ +------+ +------+ +------+ +----+ +----+
| | | | | | | |
| Movement from | | | | | |
| a pervious MAG | | | | | |
| | | | | | | |
| L2 Attachment | | | | | |
| | L2 Attached Event | | | | |
| | | | | | | |
| | Authentication Authentication | |
| |<--------------------------->|<------->| | |
| | | Parameters | Parameters | |
| | |<------------------|<--------| | |
| | | PBU | | | | |
| | |-------->| | | | |
| | | PBA | | | | |
| | RA(HNP) |<--------| | | | |
| |<--------| | | | | |
| | | | | | | |
| | MR=LMAh |MAG2=LMAv| MR=LMAh | | |
|<------>0<=======>0<#######>0<==========================>0<------>|
|[CN|MNN]| | | | | [LMAh|MR][CN|MNN] | |[CN|MNN]|
| | v | | | | | | |
| [LMAh|MR][CN|MNN] v | | | | |
| | [LMAv|MAG2][LMAh|MR][CN|MNN]| | | |
| | | | | | | |
Figure 8. Message Flow for Scenario B.2
5.1.2.3. Scenario B.3
Figure 9 shows the message flow for Scenario B.3 in where the MR-
NEMO-PMIPv6 boots up under an MAG of the PMIPv6 domain and then moves
to another MAG in the same PMIPv6 domain, e.g., inter MAG handoff.
Lee, et al. Expires March 24, 2009 [Page 18]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
Since the MR-NEMO-PMIPv6 is registered by sending PBU message sent
from MAG1 to the LMAh, the MR-NEMO-PMIPv6 configures its HoA-NEMO-
PMIPv6 from the RA message sent from the MAG1. The MR-NEMO-PMIPv6 is
treated as a node as long as it moves in the PMIPv6 domain.
o As the MR-NEMO-PMIPv6 boots up in the PMIPv6 domain, it is
attached to the MAG1.
o The authentication procedure between the MR-NEMO-PMIPv6 and the
AAAh is done, then the MAG1 obtains PMIPv6 service parameters for
the MR-NEMO-PMIPv6 through the AAAh.
o The binding registration procedure between the MAG1 and the LMAh
is done.
o After the address configuration based on the RA message sent from
the MAG1, the MR-NEMO-PMIPv6 sends a BU message to the LMAh.
o As the MR-NEMO-PMIPv6 moves from the MAG1 to the MAG2, the MAG2
detects its movement. Then the further message flow is the same
to the case of Scenario B.2
Lee, et al. Expires March 24, 2009 [Page 19]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
+-----+ +----+ +------+ +------+ +------+ +------+ +----+
| MNN | | MR | | MAG1 | | MAG2 | | LMAh | | AAAh | | CN |
+-----+ +----+ +------+ +------+ +------+ +------+ +----+
| | | | | | |
| Boot up | | | | |
| | | | | | |
| L2 Attachment | | | | |
| | L2 Attached Event | | | |
| | | | | | |
| | | Authentication | | |
| |<----------------------------------------->| |
| | | Parameters | | |
| | |<-------------------------------| |
| | | PBU | | | |
| | |-------------------->| | |
| | | PBA | | | |
| | RA(HNP) |<--------------------| | |
| |<---------| | | | |
| Address | | | | |
| Configuration | | | | |
| | | BU | | | |
| |------------------------------->| | |
| |<-------------------------------| | |
| Movement from | BA | | | |
| MAG1 to MAG2 | | | | |
| | | | | | |
| L2 Attachment | | | | |
| | | L2 Attached Event | | |
| | | | | | |
| | | Authentication | | |
| |<----------------------------------------->| |
| | | | Parameters | |
| | | |<--------------------| |
| | | | PBU | | |
| | | |--------->| | |
| | | | PBA | | |
| | RA(HNP) | |----------| | |
| |<--------------------| | | |
| | | | | | |
| | | | MAG2=LMAh| | |
|<------------------------------>0<========>0<------------------->|
| [CN|MNN] | | [LMAh|MAG2][CN|MNN] | [CN|MNN] |
| | | | | | |
Figure 9. Message Flow for Scenario B.3
Lee, et al. Expires March 24, 2009 [Page 20]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
5.1.3. Scenario C
As mentioned in Section 3.3, Scenario C considers the case in where a
NEMO moves between different PMIPv6 domains, e.g., inter domain
handoff.
5.1.3.1. Scenario C.1
Figure 10 shows the message flow when the NEMO-MIPv6 that has been
initialized at an Non-PMIPv6 moves between different PMIPv6 domains.
Becuase this scenario represents the inter domain handoff, two types
of registration MUST be performed; registering to the current
visiting LMA (LMAv2) and registering to the HA located in the home
domain. This scenario is an extension of Scenarios A.1 or B.1.
o As the MR-NEMO-MIPv6 moves to the new PMIPv6 domain in where the
LMAv2 is the topological anchor point for all nodes' HNP, the MR-
NEMO-MIPv6 performs the authentication procedure with the AAAv2.
o After successfully completing the authentication procedure, the
serving MAG, MAG2, obtains PMIPv6 service parameters for the MR-
NEMO-MIPv6 via the AAAv2.
o The binding registration procedure between the MAG2 and the LMAv2
is done.
o The MAG2 sends a RA message to the MR-NEMO-MIPv6.
o The MR-NEMO-MIPv6 on receiving the RA message performs the address
configuration procedure and then sends a BU message to its HA.
o The HA establishes a binding between the HoA-NEMO-MIPv6 and CoA-
NEMO-MIPv6 of MR.
Lee, et al. Expires March 24, 2009 [Page 21]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
+-----+ +----+ +------+ +-------+ +-------+ +----+ +----+
| MNN | | MR | | MAG2 | | LMAv2 | | AAAv2 | | HA | | CN |
+-----+ +----+ +------+ +-------+ +-------+ +----+ +----+
| | | | | | |
| Movement from | | | | |
| a PMIPv6 domain | | | | |
| | | | | | |
| L2 Attachment | | | | |
| | L2 Attached Event | | | |
| | | | | | |
| | Authentication | | |
| |<------------------------------>| | |
| | | Parameters | | |
| | |<--------------------| | |
| | | PBU | | | |
| | |--------->| | | |
| | | PBA | | | |
| | RA(HNP) |<---------| | | |
| |<---------| | | | |
| | | | | | |
| Address | | | | |
| Configuration | | | | |
| | | BU | | | |
| |------------------------------------------>| |
| |<------------------------------------------| |
| | | BA | | | |
| | | | | | |
| | MR=HA |MAG2=LMAv2| MR=HA | |
|<-------->0<========>0<########>0<===================>0<-------->|
| [CN|MNN] | | | | | [HA|MR][CN|MNN] | [CN|MNN] |
| | v | | | | | |
| [HA|MR][CN|MNN] v | | | |
| | [LMAv2|MAG1][HA|MR][CN|MNN] | | |
| | | | | | |
Figure 10. Message Flow for Scenario C.1
5.1.3.2. Scenario C.2
Figure 11 shows the message flow when the NEMO-PMIPv6 that has been
initialized at an Non-PMIPv6 moves between different PMIPv6 domains.
Similar to Scenario C.1, it represents the inter domain handoff so
that two types of registration MUST be performed; registering to the
current visiting LMA (LMAv2) and registering to the LMAh located in
the home domain. This scenario is an extension of Scenarios A.2 or
B.2. The message flow is similar to Scenario C.1. Distinguishing
differences are as follows.
Lee, et al. Expires March 24, 2009 [Page 22]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
o As the MR-NEMO-PMIPv6 receives the RA message from the MAG2, the
MR-NEMO-PMIPv6 configures its new CoA-NEMO-PMIPv6 and then sends a
BU message to its LMAh.
o The HA on receiving the BU message establishes a binding between
the HoA-NEMO-PMIPv6 and CoA-NEMO-PMIPv6 of MR.
+-----+ +----+ +------+ +-------+ +-------+ +------+ +----+ +----+
| MNN | | MR | | MAG2 | | LMAv2 | | AAAv2 | | AAAh | |LMAh| | CN |
+-----+ +----+ +------+ +-------+ +-------+ +------+ +----+ +----+
| | | | | | | |
| Movement from | | | | | |
| a PMIPv6 domain | | | | | |
| | | | | | | |
| L2 Attachment | | | | | |
| | L2 Attached Event | | | | |
| | | | | | | |
| | Authentication Authentication | |
| |<--------------------------->|<------->| | |
| | | Parameters | Parameters | |
| | |<------------------|<--------| | |
| | | PBU | | | | |
| | |-------->| | | | |
| | | PBA | | | | |
| | RA(HNP) |<--------| | | | |
| |<--------| | | | | |
| | | | | | | |
| Address | | | | | |
| Configuration | | | | | |
| | | BU | | | | |
| |----------------------------------------------->| |
| |<-----------------------------------------------| |
| | | BA | | | | |
| | | | | | | |
| | MR=LMAh |MAG2=LMAv2 MR=LMAh | | |
|<------>0<=======>0<#######>0<==========================>0<------>|
|[CN|MNN]| | | | | [LMAh|MR][CN|MNN] | |[CN|MNN]|
| | v | | | | | | |
| [LMAh|MR][CN|MNN] v | | | | |
| |[LMAv2|MAG2][LMAh|MR][CN|MNN]| | | |
| | | | | | | |
Figure 11. Message Flow for Scenario C.2
Lee, et al. Expires March 24, 2009 [Page 23]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
5.1.4. Scenario D
As mentioned in Section 3.4, Scenario D considers the case in where a
NEMO moves from a PMIPv6 to an Non-PMIPv6 domain.
5.1.4.1. Scenario D.1
Figure 12 shows the message flow when the NEMO-MIPv6 that has been
initialized at an Non-PMIPv6 domain moves from a PMIPv6 domain to
another Non-PMIPv6 domain. This scenario is an extension of
Scenarios A.1 or B.1 or C.1.
o As the MR-NEMO-MIPv6 moves out from a PMIPv6, the MR-NEMO-MIPv6
receives the RA message sent from AR in the new link.
o The MR-NEMO-MIPv6 creates its new CoA-NEMO-MIPv6 because the IPv6
prefix is different from its previous prefix. In other words, the
MR-NEMO-MIPv6 takes cognizance of that it has been moved to a new
link based on the prefix information sent from the AR.
o The MR-NEMO-MIPv6 sends a BU message to its LMAh to inform its
movement.
+-----+ +----+ +----+ +----+ +----+
| MNN | | MR | | AR | | HA | | CN |
+-----+ +----+ +----+ +----+ +----+
| | | | |
| Movement from | | |
| a PMIPv6 domain | | |
| | RA | | |
| |<--------------| | |
| | | | |
| Address | | |
| Configuration | | |
| | | BU | |
| |------------------------------>| |
| |<------------------------------| |
| | | BA | |
| | | | |
| | MR=HA | |
|<------------->0<=============================>0<------------->|
| [CN|MNN] | [HA|MR][CN|MNN] | [CN|MNN] |
| | | | |
Figure 12. Message Flow for Scenario D.1
Lee, et al. Expires March 24, 2009 [Page 24]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
5.1.4.2. Scenario D.2
Figure 13 shows the message flow when the NEMO-PMIPv6 that has been
initialized at a PMIPv6 domain moves from another PMIPv6 domain to an
Non-PMIPv6 domain. This scenario is an extension of Scenarios A.2 or
B.2 or C.2. The message flow is similar to Scenario D.1.
Distinguishing differences are as follows.
o As the MR-NEMO-PMIPv6 receives the RA message from the AR, the MR-
NEMO-PMIPv6 configures its new CoA-NEMO-PMIPv6 and then sends a BU
message to its LMAh.
+-----+ +----+ +----+ +----+ +----+
| MNN | | MR | | AR | |LMAh| | CN |
+-----+ +----+ +----+ +----+ +----+
| | | | |
| Movement from | | |
| a PMIPv6 domain | | |
| | RA | | |
| |<--------------| | |
| | | | |
| Address | | |
| Configuration | | |
| | | BU | |
| |------------------------------>| |
| |<------------------------------| |
| | | BA | |
| | | | |
| | MR=LMAh | |
|<------------->0<=============================>0<------------->|
| [CN|MNN] | [LMAh|MR][CN|MNN] | [CN|MNN] |
| | | | |
Figure 13. Message Flow for Scenario D.2
5.2. Tunneling Management
In the next version of this document, the tunneling management is
presented.
6. Returning Home
In the next version of this document, the returning home case is
presented.
Lee, et al. Expires March 24, 2009 [Page 25]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
7. Multihoming Considerations
The NEMO can connect to a PMIPv6 domain through multiple interfaces.
In the next version of this document, the multihoming considerations
are presented.
8. Security Considerations
TBA
9. IANA Considerations
TBA
10. Acknowledgment
Comments are solicited and should be addressed to NetLMM working
group's mailing list at netlmm@ietf.org and/or the authors.
This study was supported by a grant of the Korea Health 21 R&D
Project, Ministry of Health & Welfare, Republic of Korea (02-PJ3-PG6-
EV08-0001).
11. References
[1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and
B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[4] Giaretta, G., "Interactions between PMIPv6 and MIPv6: scenarios
and related issues", draft-giaretta-netlmm-mip-interactions-02
(work in progress), November 2007.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology",
RFC 4885, July 2007.
Lee, et al. Expires March 24, 2009 [Page 26]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
[7] Damic, D., Premec, D., Patil, B., Sahasrabudhe, M., and S.
Krishnan, "Proxy Mobile IPv6 indication and discovery",
draft-damic-netlmm-pmip6-ind-discover-03 (work in progress),
February 2008.
Authors' Addresses
Jong-Hyouk Lee
Sungkyunkwan University
26316, Engineering Building 2, Internet Management Technology Lab.
Suwon-si, Gyeonggi-do, 440-746
Korea
Phone: +82 031 290 7222
Email: jhlee@imtl.skku.ac.kr; jonghyouk@gmail.com
Byung-Jin Han
Sungkyunkwan University
26316, Engineering Building 2, Internet Management Technology Lab.
Suwon-si, Gyeonggi-do, 440-746
Korea
Phone: +82 031 290 7222
Email: bjhan@imtl.skku.ac.kr
Tai-Myoung Chung
Sungkyunkwan University
27328, Engineering Building 2, Internet Management Technology Lab.
Suwon-si, Gyeonggi-do, 440-746
Korea
Phone: +82 031 290 7131
Email: tmchung@ece.skku.ac.kr
Hyung-Jin Lim
Korea Financial Security Agency
15F, 36-1, Yoido-dong, Youngdeungpo-gu
Seoul, 150-886
Korea
Phone: +82 02 6919 9156
Email: hjlim@fsa.or.kr
Lee, et al. Expires March 24, 2009 [Page 27]
Internet-Draft NEMO Basic Support within PMIPv6 September 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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).
Lee, et al. Expires March 24, 2009 [Page 28]