Mobility for IPv4 working Group Chunyan.Yao
Internet-Draft Alcatel-Lucent-Sbell
Intended status: Standards Track Bruno Mongazon-Cazavet
draft-yao-mip4-mobile-agent-proxy-00.txt Alcatel-Lucent
Expires: April 27, 2009 October 28, 2008
Mobile Agent Discovery Proxy (MADP) in IPv4 Mobility Management
draft-yao-mip4-mobile-agent-proxy-00.txt
Status of This Memo
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 April 27, 2009.
Abstract
In some networks such as xDSL networks with WiFi extension, the
periodical transmission of Agent Advertisements (AA) by mobility
agents is used by Mobile Nodes (MN) to detect movement. To allow fast
movement detection, the interval at which AAs are sent should not be
long. In the early deployment of Mobile IPv4 (MIPv4), mobility agents
are deployed in the edge network. For example, in xDSL networks, Home
Agents (HA) and Foreign Agents (FA) are located on or beside Edge
Routers (ER) that usually serves thousands of MNs (typically between
2000 and 5000 in xDSL networks). The periodical transmission of
multicast AA to MNs in such a large network consumes a significant
amount of the aggregation network bandwidth and CPU resources of ERs.
Yao etc. Expires April 27, 2009 [Page 1]
Internet-Draft MADP in IPv4 Mobility Management October 2008
This is a practical problem in xDSL networks with WiFi extension.
This is also a common problem for others access networks in which a
large layer-2 network is served by one router. Hence a Mobility
Agent Discovery proxy (MADP) can be set in access nodes to make the
MNs detect movement fast meanwhile avoiding CPU and network bandwidth
consumption in the aggregation network. The MADP acts as a proxy to
MNs as far as agent discovery is concerned allowing for AS issued by
MNs to be locally replied according to AA issued by HA/FA on the
access network. MADP is a logical function that can be placed on a
suitable node location depending on access network technology and
architecture (i.e. WiMAX) to reduce network resource cost related to
agent discovery.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of MADP . . . . . . . . . . . . .. . . . . . . . . . . 4
3. Protocol Operation. . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .10
Intellectual Property and Copyright Statements . . . . . . . . . .10
Yao etc. Expires April 27, 2009 [Page 2]
Internet-Draft MADP in IPv4 Mobility Management October 2008
1. Introduction
With the development of mobile Internet, the advent of deploying IP
mobility in the IP network is necessary. In existing IPv4 networks,
Mobile IPv4 is a necessary selection. In MIPv4, Agent Discovery is
used for a Mobile Node (MN) to detect movement and determine the
Foreign Agent Care-of Address (FACoA) offered by each FA on that
network. When no link-layer mechanism is available for a MN to
determine that the attached subnet (corresponding to a layer 3 prefix)
has changed, Agent Solicitation (AS) and Agent Advertisment (AA)
messages are used to fulfill Agent Discovery. In the xDSL network
illustrated in Figure 1, a mobility agent usually needs to transmit
AA periodically to advertise its services on a link. To allow the MN
to detect movement and re-register in a fast way, the interval at
which AA are sent should be minimum.
_________________________________________
| |
| IP Core Network |
|_________________________________________|
| |
___ ___|_____ ___|___
| | ER | ... | ER |
| |_________| |_______| ___
| | \ | \ |
| _|_____ \ _______ __|____ \ _______ |
| | Switch|... | Switch| | Switch|...| Switch| |
EMAN |_______| |_______| |_______| |_______| Aggregation
| | \ | \ network
| | \ | \ |
| | \ | \ |
_|_ __|__ \ ____ __|__ \ ____ _|_
| |AN | ... |AN | | AN |... |AN |
| |_____| |_____| |_____| |____|
| | \ | \
Access | \ | \
Network | \ | \
| __|__ \ _____ __|___ \ _____
| | AP |... |AP | | AP | ... | AP |
_|_ |_____| |_____| |______| |_____|
| \ | \
| \ | \
__|__ \ ______ __|__ \ _____
| MN |... | MN | | MN |... | MN |
|_____| |_____| |_____| |_____|
AP: Access Point
AN: Access Node, one example of AN is DSLAM
EMAN: Ethernet Metropolitan Area Network
Figure 1. Network architecture of an xDSL network
Yao etc. Expires April 27, 2009 [Page 3]
Internet-Draft MADP in IPv4 Mobility Management October 2008
In the earlier deployment of MIPv4 in xDSL Networks with WiFi
extension, Mobility Agents including HA and FA are usually located on
Edge Routers and WiFi uses hard handover in physical layer. To reduce
movement detection and perform fast re-registration, it is generally
better for a MN to get an (almost) immediate unsolicited AA from a
mobility agent than to request it through an agent solicitation. The
agent solicitation / agent advertisement exchange might result in a
longer IP handover time. In addition, WiFi systems can afford enough
bandwidth for highly rated unsolicited mobility agent advertisements.
In existing xDSL deployment, there are usually 2000 to 5000
subscribers under an ER. The periodical transmission of multicast AAs
to MNs in such a large network consumes a significant amount of the
aggregation network bandwidth and CPU resources of ERs. This is a
practical problem in the deployment of WiFi into xDSL networks.
The current solution to this pratical problem is a matter of
trade-off between the amount of bandwidth consumed by AAs and
handover delay time. Better handover time (and thus little packet
loss) implies high bandwidth consumption. Little bandwidth
consumption implies worst handover time (and thus higher packet loss)
. Hence, there is no efficient solution for the whole problem yet.
2. Overview of MADP
A solution is given in this document to avoid the above trade-off by
implementing a low-cost MADP at access node. The MADP behaves as a
proxy to the MNs regarding the Agent Discovery process.
1) MADP maintains mobility agents information locally. This
information includes all fields required to build valid AA
messages for MNs that are consistent with mobility agents (HA/FA)
information. The local information can be statically configured
or dynamically received from upstream HA/FA agents solicited or
unsolicited AA messages. In the later case, the information is
cached and periodically refreshed by MADP. Management of MADP
cached information depends on MADP strategy. Cached information
can be retrieved at startup and refreshed at re-configuration
time or on MADP demand. In particular, if MADP performs periodic
refresh of the cached information, it is expected that the
bandwidth consumed by such an activity is less than the bandwidth
that would be consumed without MADP function.
2) MADP transmits AAs to MN periodically on behalf of its
HA/FA and responds to AS from MNs on behalf of its HA/FA.
3) MADP transmits AS when it needs them (e.g. at its startup,
re-configuration, at the request of a MN if required)
Yao etc. Expires April 27, 2009 [Page 4]
Internet-Draft MADP in IPv4 Mobility Management October 2008
By this way, the AAs can be multicast in access network at requested
frequency to help MNs to discover mobility agents. Multicast AAs
traffic in EMAN can be reduced greatly. The AA information in AN can
be synchronized with upstream HA/FA agents in various way described
above.
3. Protocol Operation
This section describes the MADP protocol.
3.1. Possible information included in upstream AA
The upstream AA information to be cached by MADP includes:
1). The Values in ICMP Router Advertisement fields of AA (specified
in section 2.1 of [RFC3344]): ICMP Code, Lifetime, Router
Address(es), Num Addrs.
2). The values in Mobility Agent Advertisement Extension fields of
AA: Length, Sequence Number, Registration Lifetime, "R"bit, "B"
bit, "H"bit, "F"bit, "M"bit, "G"bit, "r"bit, "T"bit, "reserved"
field, Care-of Address(es), the number of Care-of Addresses.
3). The values in Prefix-Lengths Extension fields of AA: Prefix
Length(s) list in the same sequence as that of router address of
field in ICMP Router Advertisement. (one prefix corresponds to
one router address)
4). IP address and link-layer address of its upstream HA/FA.
5). Mobile IP Agent Advertisement Challenge Extension as defined in
[RFC4721]. This extension may be carried in AAs issued by FA,
and in such a case, be present in MIP Registration Requests
issued by MN in order to be accepted by the FA. The extension
carries a random value generated by the FA. The value is
expected to change over time to prevent MNs from re-using a past
value and performing MIP replay attacks. The usability of a
challenge extension is controled by a CHALLENGE_WINDOW parameter
at FA. Each time a Challenge Extension is present in a AA
received by MADP, it must be stored by the MADP locally in the
order of its arrival. When MADP is sending AAs to a MN (
solicited or unsolicited), it shall check for presence of a
Challenge Extension and, if present, shall include the last
received (and stored) extension into the AAs.
Yao etc. Expires April 27, 2009 [Page 5]
Internet-Draft MADP in IPv4 Mobility Management October 2008
By keeping the Challenge extensions in the order of their
advertisement and by proxying the most recent extension to MN,
MADP enforces compliance with [RFC4721]. But MADP should not
issue on itself Challenge extension" in downstream AAs (to MNs)
since this value is a MN-FA end-to-end value.
3.2. Link-layer addresses, IP addresses and TTL fields of AA and AS
For AA from MADP to MN:
IP Destination address:
For unsolicited AA: "all systems on this link" multicast address
(224.0.0.1) or the "limited broadcast" address (255.255.255.255).
For Solicited AA: the source IP address of the Agent Solicitation
which prompted the Advertisement.
IP Source address:
For both solicited and unsolicited AA, the source address is the
IP address of the MADP's upstream agent (HA/FA) as previously
received and stored by MADP in upstream solicited or unsolicited
AA message. Such an address can be used since it is assumed that
ANs work in bridge mode and don't have their own IP addresses for
data forwarding.
TTL field:
The TTL for all Agent Advertisements MUST be set to 1.
The source link-layer address:
The MAC address of DSLAM's network interface if ARP proxy is
running on the AN, or the MAC address of the HA/FA's interface
attached to the AN in the same EMAN if no ARP proxy is running on
the AN.
The destination link-layer address:
For a solicited AA : is the same as the source link-layer
address of the Agent Solicitation which prompted the
Advertisement.
For an unsolicited AA or solicited with an unspecified IP address
(0.0.0.0), the address equals the corresponding multicast
/broadcast MAC address of "224.0.0.1" or "255.255.255.255".
For AS from MN to MADP:
IP Destination address:
Mobile-Agents multicast group address "224.0.0.11"
Yao etc. Expires April 27, 2009 [Page 6]
Internet-Draft MADP in IPv4 Mobility Management October 2008
IP Source address:
An IP unicast address belonging to the interface from which this
message is sent, or unspecified address: 0.0.0.0.
TTL field:
The TTL for all Agent Advertisements MUST be set to 1.
The source link-layer address:
The MAC address of the interface from which this message is sent.
The destination link-layer address:
The corresponding multicast/broadcast MAC address of "224.0.0.11".
For AA from HA/FA to MADP:
IP Destination address:
For unsolicited AA:
"all systems on this link" multicast address (224.0.0.1) or the
"limited broadcast" address (255.255.255.255).
For Solicited AA:
The source IP address of the Agent Solicitation which prompted the
Advertisement.
IP Source address:
The source address is the IP address of the MADP's upstream HA/FA's
interface from which this message is sent. The interface is the one
attached to the AN in the same EMAN.
TTL field:
The TTL for all Agent Advertisements MUST be set to 1.
The source link-layer address:
The MAC address of the interface from which this message is sent.
The destination link-layer address:
For a solicited AA: is the same as the source link-layer address of
the Agent Solicitation which prompted the Advertisement.
For an unsolicited AA: the corresponding multicast/broadcast MAC
address of "224 .0.0.1" or "255.255.255.255".
For AS from MADP to HA/FA:
IP destination address:
Mobile Agents multicast group address "224.0.0.11"
Yao etc. Expires April 27, 2009 [Page 7]
Internet-Draft MADP in IPv4 Mobility Management October 2008
IP source address:
If this AS is prompted by an AS received from a MN, then the MN's IP
address can be used. In all cases, the unspecified address (0.0.0.0)
can be used since it is assumed that AN works in bridge mode and has
no IP address for data service.
TTL field:
The TTL for all Agent Advertisements MUST be set to 1.
The source link-layer address:
The MAC of DSLAM's NT if ARP proxy is running on the AN, or the MAC
address of the MN if this AS is prompted by an AS received from a MN
and no ARP proxy running on the AN.
The destination link-layer address:
The corresponding multicast/broadcast MAC address of "224.0.0.11"
3.3 Loop Prevention
The MADP should be configured to know which of its interfaces is the
upstream interface and which are are downstream interfaces. An AS
received on the upstream interface should be silently dropped. An AA
received on a downstream interface should be silently dropped.
3.4 Message exchanges with MADP
Message exchanges between MADP and MN:
MADP transmits AA to MNs periodically on behalf of its HA/FA and
responds to Agent Solicitation (AS) from MNs on behalf of its HA/FA.
MADP transmits AA to MNs immediately whenever locally cached AA
information changes (i.e. update by manual configuration or upon
reception of AA from upstream HA/FA).
Message exchange between MADP and its upstream HA/FA:
HA/FA can transmit AA to ANs either at startup, re-configuration
time or on MADP request. MADP request can be either on behalf of a
MN request or self-initiated on a periodic basis (a convenient
period shall be used not to overload upstream network). When MADP
receives an AA, it validates the message and updates its AA
information accordingly.
Yao etc. Expires April 27, 2009 [Page 8]
Internet-Draft MADP in IPv4 Mobility Management October 2008
The usage of MADP and [RFC4721] together can raise synchronization
/timing problems that might result in the complete failure of MN-FA
registration. This might happen if MADP-FA and MADP-MN AA are always
out-of-sync regarding challenge extension. For example, the
extension in MADP-MN AA (lastly stored in MADP) is exhausted from
FA's point of view but the new valid extension in MADP-FA AA is not
yet received by MADP. To solve this problem, the value of the
CHALLENGE_WINDOW parameter shall be tuned accordingly at FA level.
In particular, the CHALLENGE_WINDOW might be increased to allow
Challenge Extensions to be longer valid.
In addition, MADP should process separately Challenge Extensions
received in multicast/broadcast AA more and Challenge Extensions
received in unicast AA resulting from a AS issued by a MN.
Challenge Extensions received in multicast/broadcast AA are
delivered downstream (to MNs) only in multicast/broadcast AA issued
by MADP. Challenge extensions received in unicast AA are delivered
downstream (to MNs) only in unicast AA issued by MADP. As far as
unicast is concerned, MADP should not store the challenge extension.
Instead, MADP should first forward unicast AS received from MN
toward upstream HA/FA and then forward unicast AA received from
HA/FA toward downstream MN. Thus doing, MADP ensures that the last
Challenge Extension built by a HA/FA for a MN is provided to the MN.
4. IANA Considerations
This document makes no request to IANA.
5. Security Considerations
This document deals with Agent Discovery messages in MIPv4, and
keeps consistent with that of [RFC3344] and [RFC1256] in future
evolution.
6. References
[RFC4721] C. Perkins, "Mobile IPv4 Challenge/Response extensions",
January 2007
[RFC3344] C. Perkins, "IP Mobility Support for IPv4", August 2002
[RFC1256] S. Deering, "ICMP Router Discovery Messages", September
1991
Yao etc. Expires April 27, 2009 [Page 9]
Internet-Draft MADP in IPv4 Mobility Management October 2008
Authors' Addresses
Chunyan Yao
Research and innovation center in Shanghai, Alcatel-Lucent.
Email: Chunyan.Yao@alcatel-sbell.com.cn
Phone: 86-21-50554550 extension 7250
Bruno Mongazon-Cazavet
Alcatel-Lucent France Centre de Villarceaux, Alcatel-Lucent.
Email: Bruno.Mongazon-Cazavet@alcatel-lucent.fr
Phone: 33-1-30772744
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.
Yao etc. Expires April 27, 2009 [Page 10]
Internet-Draft MADP in IPv4 Mobility Management October 2008
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.
Yao etc. Expires April 27, 2009 [Page 11]