Internet DRAFT - draft-ishi-mobileip-behavior-ma
draft-ishi-mobileip-behavior-ma
Mobile IP Working Group Koichi Ishibashi
INTERNET-DRAFT Keiichi Shimizu
Expires: April 2002 Shoichiro Seno
Mitsubishi Electric Corporation
October, 2001
Behavior of A Mobility Agent in Mobile IP in order to manage the flow
<draft-ishi-mobileip-behavior-ma-00.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 cite them other than as "work in
progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments
should be directed to the authors.
Abstract
Mobile IP [1] protocol allows a mobile node (MN) to move between
different networks seamlessly. However, in certain cases,
the latency involved in the handoff can be beyond the threshold
required for the support of delay-sensitive or real-time services.
In order to address the above problem, there have been many
proposals related to extensions of Mobile IP handoffs in order to
achieve efficient handoff procedures.
Originally the Mobile IP should be considered a protocol
that deals solely with terminal mobility. On the other hand,
when the future mobile network supports QoS, mobility agents
should support QoS treatment of tunneling and forwarding and
distinguish individual flows. And the above support of the QoS
treatment should be applied to a handoff procedure as well as the
tunneling and forwarding procedure.
Ishibashi, Shimizu, Seno Expires April 2002 [Page 1]
INTERNET-DRAFT Behavior of a Mobility Agent October, 2001
This draft aims at bringing up a problem that a mobility agent
should apply different handoff mechanisms to individual flows
according to an implicit or explicit configuration.
TABLE OF CONTENTS
1. Introduction
2. Terminology
3. Backgrounds
4. Example of a Behavior of a Mobility Agent Supporting
Fast MIP and Buffer Management Simultaneously
5. Future Issues
6. IPv6 Consideration
7. References
8. Authors' Addresses
1. Introduction
Mobile IP [1] protocol allows a mobile node (MN) to move between
different networks seamlessly. That is, Mobile IP presents
a solution for ensuring an IP-layer handoff as the MN changes
its point of attachment with the Internet. However, in certain
cases, the latency involved in the handoff can be beyond the
threshold required for the support of delay-sensitive or real-time
services.
In order to address the above problem, Fast MIP [2] proposes
methods to achieve low-latency Mobile IP handoffs when an MN
moves between different networks served by each network's foreign
agent (FA). And there are many proposals related to extensions of
Mobile IP handoffs in order to achieve efficient handoff procedures.
Originally the Mobile IP should be considered a protocol
that deals solely with terminal mobility, so that we think Fast MIP
and the other proposals are based on assumption of terminal
mobility. On the other hand, in the future, we envision an MN that
has multiple flows simultaneously and each flow may request
its own distinctive QoS (Quality-of-Service) attribute, that is,
low-latency, low-loss, best-effort, and so on. For example,
whereas one flow may request the low-latency service as its QoS
attribute, another flow may request the best-effort service as
its QoS attribute.
Ishibashi, Shimizu, Seno Expires April 2002 [Page 2]
INTERNET-DRAFT Behavior of a Mobility Agent October, 2001
However, mobility agents of Mobile IP or Fast MIP are unable to
distinguish individual flows and therefore apply the same
procedure to all intercepted traffic for an MN. Consequently,
if an MN requests for simultaneous bindings, the home agent (HA)
will redirect, or bi-cast, all intercepted packets to the MN to
all registered care-of addresses. However, a flow that requests
the best-effort service may be tolerant of disruption involved
in the handoff. So, applying the method for the low-latency
service, such as bi-casting, to the flow requesting the
best-effort service results in ineffective utilization of
the resource in mobility agents and the bandwidth of a mobile
network.
In our opinion, a future network will support a QoS mechanism
and a future mobile network will support a QoS mechanism also.
When the future mobile network supports QoS,
mobility agents should support QoS treatment of tunneling and
forwarding and distinguish individual flows. And the above
support of the QoS treatment should be applied to a handoff
procedure as well as the tunneling and forwarding procedure.
This draft aims at bringing up a problem that a mobility agent
should apply different handoff mechanisms to individual flows
according to an implicit or explicit configuration.
The configuration for individual flows is outside the scope of
this document.
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 RFC 2119.
3. Backgrounds
In a future network, a mobile node may have multiple flows
simultaneously. And each flow may request its own distinctive QoS
(Quality-of-Service) attribute, that is, low-latency, low-loss,
best-effort, and so on. Here, Fast MIP primarily proposes methods
to achieve low-latency Mobile IP handoffs. That is, by introducing
a new concept i.e, "anticipation", and implementing the mechanism
of "bi-casting" or BET (bi-directional edge tunnel), a new foreign
agent (nFA) can be allowed to receive IP packets to the mobile
node before the MN has completed movement to the new network
served by the nFA. And forwarding IP packets to the mobile node
before the mobile node has completed registration of its location
can realize reduction of the latency involved in the handoff.
Ishibashi, Shimizu, Seno Expires April 2002 [Page 3]
INTERNET-DRAFT Behavior of a Mobility Agent October, 2001
As an illustration, suppose that the mobile network supports
the PRE-REGISTRATION handoff method presented by Fast MIP and
an MN has two flows. One flow requests the low-latency service,
another flow requests the best-effort service. When the HA
receives IP packets to the MN during movement between an old
foreign agent(oFA) and a new foreign agent (nFA), the HA must
bi-cast the received packets to both the oFA and the nFA.
That is, the IP packets belonging to the flow with the best-effort
service may be forwarded to the nFA by the bi-casting mechanism.
This forwarding procedure may be inefficient for the best-effort
service, and result in increase of processing load on the HA and
consumption of network resource.
Note that the oFA's and n FA's decision on which action to be
taken should depend on the type of traffic involved.
- drop all packets to the MN or
- buffer packets to the MN.
However, it is not shown how the FA behaves to support the
low-latency service and the loss-less service simultaneously.
Although Fast MIP allows a protocol to minimize the amount of
service disruption during movement between FAs, it is difficult
to avoid packet loss completely. So we think that in order to
support the low-loss service, it may be necessary to apply a
specific mechanism, for example, such as the mechanism described
in Buffer Management [3]. And the mobile network may need to
support multiple mechanisms for the low-latency and the low-loss
services since each mechanism can only satisfy a requirement
related to a specific QoS attribute.
When supporting the buffering method described in Buffer
Management, a mobility agent should not buffer all IP packets
destined to the MN, but the IP packets belonging to the flow
requesting the low-loss service, to make efficient use of limited
buffer capacity. Note that in order to support multiple handoff
mechanisms, the mobility agent must distinguish IP packets
belonging to individual flows, and apply the behavior according
to the flow to the IP packets.
And, the QoS treatment should be applied to the packet stream
not only before and after the handoff, but also during the
handoff. That is, the behavior or action of a mobility agent
should be decided according to the QoS attributes of relayed
packets.
Here, in order to satisfy the requested QoS between end-to-end
hosts, it may be necessary to specify the behavior of nodes along
the path. Thus it is important to describe the behavior of a
mobility agent that is a component of the end-to-end path.
Ishibashi, Shimizu, Seno Expires April 2002 [Page 4]
INTERNET-DRAFT Behavior of a Mobility Agent October, 2001
Because the future mobile network will support QoS, each component
in the future mobile network must support a behavior or an action
that realizes the requested QoS, so that a mobility agent can
support a QoS mechanism. Under this environment,
since the mobility agent may forward IP packets according to
its requested QoS, excessive overhead may not occur
if the mobility agent applies individual handoff mechanisms
according to the requested QoS.
4. Example of a Behavior of a Mobility Agent Supporting
Fast MIP and Buffer Management Simultaneously
First, suppose that a mobile network implements both
the PRE-REGISTRATION handoff method presented by Fast MIP
and the method presented by Buffer Management.
While the flow that requests the low-latency may be serviced
by the PRE-REGISTRATION handoff method during movement
between networks, the flow that requests the low-loss may
be serviced by the method presented by Buffer Management.
Note that the flow that requests the best-effort service may
be serviced by the method presented by Mobile IP.
In the 51th IETF meeting, there was the consensus that bi-casting
mechanism should be moved to a separate document for Fast MIP draft.
However, in this draft, we address the requirement that
a mobility agent should apply an appropriate behavior for each
requested QoS to individual flows according to an implicit or
explicit configuration. And for the above purpose, we refer to
the bi-casting mechanism as an example for supporting the
low-latency handoffs, and Buffer Management as an example for
supporting the low-loss handoffs. Note that the mechanisms to
achieve the low-latency Mobile IP handoff or the low-loss
Mobile IP handoff are outside the scope of this document.
Therefore, for a mobility agent to apply an appropriate behavior for
each requested QoS, it is necessary to distinguish individual
flows and decide which QoS attribute each flow deserves.
Ishibashi, Shimizu, Seno Expires April 2002 [Page 5]
INTERNET-DRAFT Behavior of a Mobility Agent October, 2001
As an illustration, suppose that the MN requests the simultaneous
bindings to the HA by the PRE-REGISTRATION handoff method.
When the HA receives an IP packet to the MN, it must bi-cast
the packet destined to the MN to multiple locations registered
by the MN. After this process, IP packet transmission routine on
the HA would discard IP packets destined to the MN corresponded
with the flows that do not request the low-latency handoffs.
In this point, the behavior for individual flows may be ruled
by an implicit or explicit configuration. However, the HA must
forward the IP packets destined to the MN to at least one location
among multiple locations registered by the MN. Which location
the HA selects may depend on its policy, that is, the MN may
indicate the location that the HA should primarily forward the
IP packets, or the HA may forward the IP packets to the oldest
location among locations that the MN registered.
On the other hand, when the FA receives an encapsulated IP packet,
first it de-encapsulates the received IP packet. And the FA may:
- drop the received packet,
- buffer packet for the MN, or
- buffer packet for the MN according to the mechanism
presented by the Buffer Management.
The choice of which action to be taken may depend on the type
of the received packet.
The following contains message timing diagram describing
the above behavior.
Ishibashi, Shimizu, Seno Expires April 2002 [Page 6]
INTERNET-DRAFT Behavior of a Mobility Agent October, 2001
MN oFA nFA HA
| | | |
|<~~L2-Triffer | | |
| | | |
| RegReq(with Buffer Control Request extension)
|------------->| | |
| RegRep(with OPTIONAL Buffer Control |
|<-------------| Response extension) |
| | | |
| ProxyRtSol | | |
|------------->| | |
| ProxyRtAdv | | |
|<-------------| | |
| | | |
| RegReq | | |
|--------------|------------->| |
| | |---------->|
| | | RegRep |
| |<----------|
|<-------------|--------------| |
|<-------------|<-------------| | IP packet to MN
| | | |<--- for low-latency
| |<-------------------------|#
|<-------------| *|<----------|# bi-casting
| | Buffering or Discard |
| | | | IP packet to MN
| | | |<--- for loss-less
| *|<-------------------------|
| Buffering for Buffer Management |
| | | |
| | | |
| RegReq(with two Buffer Control extensions
| | and Previous FA Notification extension)
|--------------|------------->| |
| | |---------->|
| | Binding Update(with Buffer Control
| |<-------------| Request extension)
| | [Forwarding] | |
| |=============>| |
| |<----------|
|<-------------|--------------| |
| RegRep(with OPTIONAL Buffer Control Response extension)
| | | |
RegReq : Registration Request
RegRep : Registration Reply
ProxyRtSol : Proxy Router Solicitation
ProxtRtAdv : Proxy Router Advertisement
Ishibashi, Shimizu, Seno Expires April 2002 [Page 7]
INTERNET-DRAFT Behavior of a Mobility Agent October, 2001
Note that a traffic flow may be identified by using
the DS codepoint of DiffSev or by combining the destination
address, the source address, transport protocol number
and port numbers.
And, if we consider the POST-REGISTRATION handoff method
presented by Fast MIP as an example for supporting the
low-latency, we will encounter the same issues when an FA decides
whether it should forward an IP packet by using BET or not.
5. Future Issues
This section describes the requirements for realizing MA's
behavior according to individual flows in brief.
The following shows the list of the requirements.
- capability to configure for individual flows on
each mobility agent,
- capability to distinguish between individual flows
on each mobility agent,
- capability to map handoff mechanisms to individual flows
according to its configuration,
- if possible, aggregation of signaling messages involved in
each handoff mechanism.
6. IPv6 Consideration
In this draft, we consider the problem and an example of behavior
of Mobile IPv4 mobility agents when a mobile node has multiple
flows simultaneously and each flow requests its own distinctive
QoS attribute.
There is the same problem when we consider the issues with the
Mobile IPv6. That is, a home agent and access routers of Mobile
IPv6 should apply different handoff mechanisms to individual flows
that may request its own distinctive QoS attributes.
Ishibashi, Shimizu, Seno Expires April 2002 [Page 8]
INTERNET-DRAFT Behavior of a Mobility Agent October, 2001
7. References
[1] C. Perkins, Editor, "IP Mobiity Support", RFC 2002, October
1996.
[2] MIPv4 Handoffs Design Team, "Low Latency Handoffs in Mobile
IPv4", draft-ietf-mobileip-lowlatency-handoffs-v4-01.txt,
work in progress, May 2001.
[3] M. Khalil et. al., "Buffer Management for Mobile IP",
draft-mkhalil-mobileip-buffer-00.txt, October 1999.
8. Authors' Addresses
Koichi Ishibashi
Mitsubishi Electric Corporation
5-1-1 Ofuna,
Kamakura, Kanagawa 247-8501, JAPAN
Phone: +81 467-41-2430
Enail: ishi@isl.melco.co.jp
Keiichi Shimizu
Mitsubishi Electric Corporation
5-1-1 Ofuna,
Kamakura, Kanagawa 247-8501, JAPAN
Phone: +81 467-41-2869
Enail: kei1@csc.melco.co.jp
Shoichiro Seno
Mitsubishi Electric Corporation
5-1-1 Ofuna,
Kamakura, Kanagawa 247-8501, JAPAN
Phone: +81 467-41-2430
Enail: senos@isl.melco.co.jp
Ishibashi, Shimizu, Seno Expires April 2002 [Page 9]
