One document matched: draft-lee-netlmm-nemo-ps-00.txt
Network Working Group J-C. Lee
Internet-Draft D. Kaspar
Intended status: Standards Track ETRI
Expires: August 30, 2007 February 26, 2007
The Problem Statements for NEMO in NetLMM domains
(draft-lee-netlmm-nemo-ps-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 August 30, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Lee & Kaspar Expires August 30, 2007 [Page 1]
Internet-Draft ps for nemo in netlmm February 2007
Abstract
The NetLMM protocol provides local mobility to the mobile node
without requiring any modification of mobile node. The NetLMM domain
provides this service by maintaining forwarding state for the mobile
node's prefix. In case that the mobile node is a mobile router in
the home network the NetLMM domain may not have the forwarding state
for the mobile network prefix, so it can't forward packets from nodes
within the mobile network, that is to say, existing NetLMM protocols
do not consider mobile routers enough.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. The Granularity of Mobility Management . . . . . . . . . . 6
4.2. The Requirements for NetLMM protocol . . . . . . . . . . . 6
4.3. NetLMM protocol . . . . . . . . . . . . . . . . . . . . . 6
5. Problem Statement for NEMO in NetLMM domain . . . . . . . . . 7
6. Packet Forwarding Scenario for NEMO in NetLMM domain . . . . . 8
6.1. Mobile Router is "at home" . . . . . . . . . . . . . . . . 8
6.2. Mobile Router is "away" . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Lee & Kaspar Expires August 30, 2007 [Page 2]
Internet-Draft ps for nemo in netlmm February 2007
1. Requirements notation
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].
Lee & Kaspar Expires August 30, 2007 [Page 3]
Internet-Draft ps for nemo in netlmm February 2007
2. Introduction
The NetLMM (Network-based Localized Mobility Management) protocol
provides local mobility to the mobile nodes without requiring any
involvement of a mobile node stack. From the perspective of the
mobile node, the entire NetLMM domain appears as a single link, the
network ensures the mobile node believes it is always on its home
link. So the mobile node in a NetLMM domain may operate as if it
were still in the same subnet while it is moving in the NetLMM
domain.
The NetLMM protocol has two principal functional entities, which are
called MAG (Mobile Access Gateway) and LMA (Local Mobility Anchor).
The LMA maintains a collection of routes for individual mobile nodes
while the mobile nodes moves around in the NetLMM domain. The route
information that the LMA keeps is, however, only for the packets
based on the subnet prefix allocated to the mobile node itself.
So if a mobile router (MR) implementing the NEMO protocol [RFC3963]
joins the NetLMM domain as a home network and moves around among MAGs
in the NetLMM domain, the MAG may not know how to handle the packets
from nodes attached to the mobile router.
Lee & Kaspar Expires August 30, 2007 [Page 4]
Internet-Draft ps for nemo in netlmm February 2007
3. Terminology
Localized Mobility Management Protocol
Same as defined in [netlmm-ps].
NetLMM protocol
This term does not mean "NetLMM design team protocol" but
assumes a network-based localized mobility management protocol
that supports the NetLMM functional architecture described in
[netlmm-goals]. So this term includes "netlmm dt protocol" and
"proxy MIPv6 protocol".
NetLMM domain
This term is defined in [netlmm-dt-protocol] but the meaning of
"the NetLMM protocol" follows the term "NetLMM protocol"
previously defined.
Lee & Kaspar Expires August 30, 2007 [Page 5]
Internet-Draft ps for nemo in netlmm February 2007
4. Assumptions
In general, the localized/global mobility management scheme follows
the assumptions below, which this draft is based on.
4.1. The Granularity of Mobility Management
Mobility management is broken down into localized mobility management
and global mobility management. Local mobility involves movements
across some administratively and geographically contiguous set of
subnets. The mobile node that implements a global mobility protocol
moves across broader administrative, geographical, and topological
domains and these domains could be localized mobility management
domain or not.
4.2. The Requirements for NetLMM protocol
o The NetLMM protocol should be able to support unmodified mobile
nodes (goal #7 of [netlmm-goals]). In this goal the mobile node
can be a normal host or a node that has some kind of global
mobility protocol.
o Localized mobility management is independent of global mobility
management (goal #10 of [netlmm-goals]). This goal says that the
implementation and deployment of the localized mobility management
protocol should not restrict, or be restricted by, the choice of
global mobility management protocol. This means that the mobile
node which has a global mobility protocol can move freely across
NetLMM domains or any ordinary subnet; and from the mobile node's
point of view both appear as the same, that is to say, single
subnet. In other words, the mobile node does not know and does
not need to know whether the domain that it just entered is a
NetLMM domain or not
4.3. NetLMM protocol
Currently there are two NetLMM protocol candidates; the design team
protocol and the proxy mobile IPv6 protocol [netlmm-pmipv6]. This
draft considers both of them.
Lee & Kaspar Expires August 30, 2007 [Page 6]
Internet-Draft ps for nemo in netlmm February 2007
5. Problem Statement for NEMO in NetLMM domain
[netlmm-goals] describes the goals (or requirements) for NetLMM.
Section 3.7 "Support for Unmodified Mobile Nodes (Goal #7)" of
[netlmm-goals] says that the NetLMM solution should be able to
support any mobile node without requiring localized mobility
management software on the mobile node. In this context, the mobile
node can be an ordinary host or a node that has some kind of global
mobility protocol.
Since the entire NetLMM domain appears as a single link to the mobile
node, the mobile node that has a global mobility protocol will not
trigger the global mobility protocol while moving into (or inside of)
the NetLMM domain. In this situation most of the mobile nodes that
have a host-based global mobility protocol may work well, but if the
mobile node is a mobile router that implements NEMO protocol there
may be problems in forwarding packets from the nodes attached to the
mobile router.
The NetLMM protocol has two principal functional entities, which are
called MAG (Mobile Access Gateway) and LMA (Local Mobility Anchor).
The LMA maintains a collection of routes for individual mobile nodes
and it will be used while the mobile node moves around in the NetLMM
domain. The route information that the LMA keeps is, however, only
for the packets based on the subnet prefix allocated to the mobile
node itself. Thus, if a mobile router joins the NetLMM domain as a
home network and moves around among MAGs that belong to the NetLMM
domain a MAG may not know how to handle the packets from nodes
attached to the mobile router because there is no way to inform the
MAG and LMA of the mobile network prefix.
If the mobile router boots up in a normal access network and then
moves into a NetLMM domain this problem does not occur because in the
foreign network the mobile router will make a tunnel to the home
agent and forward all packets from its mobile network through this
tunnel to the home agent. In this case the source address of packet
is the CoA of the mobile router and the MAG that the mobile router is
attached to can handle this packet.
So, This problem statement might have an impact on the NetLMM
protocol specification itself.
Lee & Kaspar Expires August 30, 2007 [Page 7]
Internet-Draft ps for nemo in netlmm February 2007
6. Packet Forwarding Scenario for NEMO in NetLMM domain
We consider two scenarios in that a mobile router joins NetLMM
domain.
6.1. Mobile Router is "at home"
The MR will obtain a prefix by attaching to the NetLMM domain. But
all the nodes within the mobile network attached to the MR will keep
their prefix. Because the MR is "at home", it will not encapsulate
packets from attached nodes, but forward them to a MAG. The MAG only
knows the prefix of the MR, but not the prefix of any attached node.
This situation might cause the combination of NEMO and NetLMM to
fail.
6.2. Mobile Router is "away"
The MR will also receive a prefix during NetLMM domain attachment.
But the NEMO protocol which is implemented at the MR will encapsulate
packets from nodes attached to the MR. Therefore, the mobile network
will appear to the MAG as if it is a single node. It is assumed that
in this case, no problems will occur.
Lee & Kaspar Expires August 30, 2007 [Page 8]
Internet-Draft ps for nemo in netlmm February 2007
7. IANA Considerations
There is no IANA consideration in this document.
Lee & Kaspar Expires August 30, 2007 [Page 9]
Internet-Draft ps for nemo in netlmm February 2007
8. Security Considerations
The security consideration is not studied for this issue yet.
Lee & Kaspar Expires August 30, 2007 [Page 10]
Internet-Draft ps for nemo in netlmm February 2007
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.
[netlmm-dt-protocol]
Levkowetz, H., "The NetLMM Protocol", October 2006.
[netlmm-goals]
Kempf, J., "Goals for Network-based Localized Mobility
Management", October 2006.
[netlmm-pmipv6]
Gundavelli, S., "Proxy Mobile IPv6", January 2007.
[netlmm-ps]
Kempf, J., "Problem Statement for Network-based Localized
Mobility Management", September 2006.
9.2. Informative References
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.
Lee & Kaspar Expires August 30, 2007 [Page 11]
Internet-Draft ps for nemo in netlmm February 2007
Authors' Addresses
Joo-Chul Lee
ETRI
161 Gajeong-dong Yuseong-gu
Daejeon, 305-700
Korea
Fax: +82 42 861 5404
Email: rune@etri.re.kr
Dominik Kaspar
ETRI
161 Gajeong-dong Yuseong-gu
Daejeon, 305-700
Korea
Fax: +82 42 861 5404
Email: dominik@etri.re.kr
Lee & Kaspar Expires August 30, 2007 [Page 12]
Internet-Draft ps for nemo in netlmm February 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).
Lee & Kaspar Expires August 30, 2007 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 01:54:59 |