One document matched: draft-kumar-dna-rqmnt-IPv4-00.txt
DNA
Internet Draft Brijesh Kumar
Sathya Narayanan
Document: draft-kumar-dna-rqmnt-IPv4-00.txt Panasonic
Expires: April 2004 October 2003
Detecting Network Attachment - Requirements for IPv4
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026 [1].
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 made obsolete 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.
Abstract
This specification summarizes the requirements for detecting
network attachment for IPv4 devices. It discusses various issues
such as address assignments, the need for layer 2 triggers,
security requirements, and interaction with context transfer
mechanisms.
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
RFC-2119 [2].
Table of Contents
Kumar Expires - April 2004 [Page 1]
DNA Requirements for IPv4 October 2003
1. Introduction...................................................2
2. Problem Definition and Issues..................................3
3. Terminology....................................................3
4. Movement Detection.............................................5
5. Mobile IPv4 Movement Detection.................................7
5.1 IP address Assignments and Reconfiguration.................8
6. Scenarios......................................................9
6.1 A Device Moving from one IP subnet to another IP subnet....9
6.2 A Device Moving Back and from to the same IP subnet........9
7. General Requirements for the Solution..........................9
7.1 Movement Detection........................................10
7.2 Determining Configuration Action..........................10
7.3 Device Configuration......................................10
8. DNA and Context Transfer Protocol.............................11
9. DNA & QoS.....................................................11
10. Security Considerations......................................12
References.......................................................12
Acknowledgments..................................................13
Author's Addresses...............................................13
1. Introduction
One of the main pre-requisites for providing time sensitive
services such as VOIP telephony, video streaming, etc., in a
mobile environment is the ability of a mobile node to quickly
establish its presence on a new link. Any movement of a mobile
node from one IP subnet to another results in an IP level hand-
off, which introduces long latency due to the need for
reconfiguration both at the device side as well as at the network
side. Therefore, it is very important that when a mobile host
arrives on a new IP subnet, it must quickly detect the movement,
and determine whether it requires new configuration for obtaining
service from the network, or it has re-entered the same network
on which it was previously connected.
The problem of network attachment detection can be broken into
three basic steps [3]:
a) Movement Detection
b) Determine the Next Action
c) Change Configuration, if Needed
This document discusses requirements in the above three areas for
an IPv4 mobile device. The requirements for an IPv6 mobile node
are discussed in a separate document [8]
<Kumar> Expires - April [Page 2]
DNA Requirements for IPv4 October 2003
2. Problem Definition and Issues
Any time a device moves from one IP subnet to another, it needs to
re-establish its presence on the network by registering itself on
the link. The first step in this process is to acquire the wireless
link by completing the procedure for the device registration using
the specified layer 2 signaling. The second step involves getting a
new IP address from the network to obtain the application level
service. These steps are time consuming, and can add to substantial
latency before a device can obtain the service at a new location.
Therefore, there is clear need to define standards and procedures
that can minimize the latency in the above scenario. Several drafts
in the past have dealt with minimizing the hand-off delays [4, 6,7].
The existing optimization techniques rely on movement prediction and
the redirection of tunneled packets from previous location to new
location. If movement prediction is available, then the detection
of network attachment may not be at a critical path. However, many
times, movement prediction is not available or fails. In these
situations, the latency introduced in re-acquiring services can
significantly impact many applications. There is clearly a need to
reduce overlap times for make-before-break mechanisms used in
Mobile-IP hand-off optimizations [6]. Network attachment detection
should define mechanisms and procedures that rely on unambiguous
movement information rather than depending on prediction.
3. Terminology
This document uses the following terms, originally defined in Mobile
IPv4 specifications document [5] or in [4]:
Access Point (AP)
A Layer 2 (L2) access entity, e.g. a radio transceiver
Station, connected to one or more Routers working as a
Foreign Agent or a Home Agent (HA). Its primary function is
to provide MNs an L2 wireless link via its specific air-
interface technology.
Binding
<Kumar> Expires - April [Page 3]
DNA Requirements for IPv4 October 2003
A binding is a collection of configuration parameters,
including at least an IP address, associated with or bound
to a DHCP Client. Bindings are managed by DHCP servers.
DHCP Client
A DHCP client is an Internet host using DHCP to obtain
configuration parameters such as a network address.
DHCP Server
A DHCP server is an Internet host that returns
configuration parameters to DHCP clients.
Home Agent
A router on a mobile node's home network which tunnels
datagrams for delivery to the mobile node when it is away
from home, and maintains current location information for
the mobile node.
Foreign Agent
A router on a mobile node's visited network which provides
routing services to the mobile node while registered. The
foreign agent detunnels and delivers datagrams to the
mobile node that were tunneled by the mobile node's home
agent. For datagrams sent by a mobile node, the foreign
agent may serve as a default router for registered mobile
nodes.
L2 Handover
Change of MN's link layer connection from one AP to
another. No change in off-subnet routing reachability
information is required if both APs are part of the same
subnet.
L3 Handover
Change of MN's routable address from one AR to another. An
L3 handover results in a change in the MN's routing
<Kumar> Expires - April [Page 4]
DNA Requirements for IPv4 October 2003
reachability, that will require action on the part of the
IP mobility protocol running in the MN and/or ARs.
Mobility Agent (MA)
Either a home agent or a foreign agent.
Mobile Node (MN)
A user device capable of requesting L2/L3 access to the
IP network.
4. Movement Detection
There are several currently proposed methods to minimize the
delay in movement detection. These are discussed below.
A. Link Layer Hints
One of the suggested approach for movement detection is to use
Link Layer hints. Layer 2 Hints differ for various link layer 2
protocols, therefore recent proposals have been to mask the
details of link layers from the above layer, and instead use an
abstraction of the link layer [4]. A layer 2 hint or trigger for
movement detection can identify the event that caused it, the
parameters associated with the trigger event, and other
parameters that may be useful for the upper layer in processing
the event.
Link Layer triggers can be delivered to the device, to the
foreign agent (specially, when FA is located on AP hardware) or
to the APs. Since layer 2 trigger corresponds to a layer 2 hand-
off, both the device and network side will generate a L2 hand-off
event at the same time. However, since they are not aware about
each other's ability to process Layer 2 event, both the network
side and device side may utilize this information in parallel to
optimize the hand-off.
Requirements:
1. SHOULD use link layer hints.
2. Link layer hints MUST be defined as STRONG or WEAK.
3. When Link Layer hints are used, the DNA protocol MUST be able
to process the event notification of a link torn down event
immediately.
<Kumar> Expires - April [Page 5]
DNA Requirements for IPv4 October 2003
4. When Link Layer hints are used, the DNA protocol MUST be able
to process the event notification of a link reestablishment
event immediately.
5. When Link Layer hints are used, the DNA protocol MUST be able
to differentiate between old and new L2 links by local
mechanisms. To accomplish this, it may request additional
Link Layer parameters from the Link Layer.
6. When multiple hints are received simultaneously, the DNA
protocol SHOULD be able to filter Link Layer hints and MUST
prefer STRONG hints over WEAK Hints.
7. Link Layer 2 hints MUST not overwhelm the upper layer and
create un-stability.
8. DNA mechanism MUST apply suitable damping mechanism so that
it is able to isolate the upper layers from link layer un-
stability or false reporting due to extraneous events.
B. Network Layer Hints
Network Layer can detect:
o Presence of new Mobility Agent or absence of the current
Mobility Agent
o Presence or absence of a DHCP server
o Presence or absence of on-link prefix by promiscuous
snooping of the link
The network layer can detect the movement by detecting the
presence of a new Mobility Agent (or an absence of an existing
Mobility Agent). This can be deduced when it receives unsolicited
agent advertisements (from a previously unknown Mobility Agent)
or by soliciting the advertisements from the existing Mobility
Agents.[5]
Requirements:
1. MUST use network layer hints since Network layer hints are
reliable indication of movement or mobility events associated
with the device movement.
2. Network layer hints SHOULD be processed at higher priority
than link layer hints. If a mobile node receives an unsolicited
Agent advertisement message, it should compare it with the
current mobility agents known to it.
3. SHOULD immediately confirm the movement from the existing
Mobility Agent by soliciting agent advertisement
<Kumar> Expires - April [Page 6]
DNA Requirements for IPv4 October 2003
Also, Network layer can detect movement by detecting presence or
absence of a DHCP server.
Requirements:
1. MUST be able to learn and remember configuration for
previously visited networks.
2. If no clear indication as to movement or current point of
attachment is available, the host MUST assume it is still
attached to the most recently attached network.
3. If a previous saved configuration is available or if the host
assumes to be at the same network after receiving WEAK layer
2 or layer 3 hints for movement, every element of the assumed
configuration MUST be verified.
5. Mobile IPv4 Movement Detection
RFC 3220 [5] defines two primary mechanisms for a mobile node to
detect that it has moved from one IP subnet to another.
Method 1: Foreign Agent did not renew its Agent Advertisement
within the time period specified.
Requirements:
1. A Mobile node MUST immediately generate an agent solicitation
message if it fails to receive another Agent advertisement
message from the agent within the Lifetime advertised by it.
2. In absence of any Layer 2 hint SHOULD assume that the mobile
has not moved from the current subnet.
3. MUST immediately register with the new agent
Method 2: This method matches the Prefix-Length extension field in
agent advertisement. If the prefixes differ the mobile node MAY
assume that it has moved.
Requirements:
1. If a mobile node is currently using a foreign agent care-of
address, the mobile node SHOULD NOT use this method of move
detection unless both the current agent and the new agent include
the Prefix-Lengths Extension in their respective Agent
Advertisements; if this Extension is missing from one or both of
the advertisements, this method of move detection SHOULD NOT be
used.
<Kumar> Expires - April [Page 7]
DNA Requirements for IPv4 October 2003
2. If a mobile node is using a co-located care-of address, it
SHOULD not use this method of move detection unless the new agent
includes the Prefix-Lengths Extension in its Advertisement and
the mobile node knows the network prefix of its current co-
located care-of address.
5.1 IP address Assignments and Reconfiguration
`
DHCP server and DHCP client interaction is used for learning
parameters for new configuration including new IP address [9].
According to DHCP protocol, a client is required to make up to four
request for a total delay of 60 seconds before assuming a no
response from the server. Also, for it is recommended that the
allocating server should probe reallocating the address with a
mechanism such as an ICMP echo request, and the client should probe
the newly address with a mechanism such as ARP [. This is
recommended to ensure the integrity of the new address.
If a client has a valid lease on an address, and the client loses
network connectivity, it is recommended that the client SHOULD
reacquire or verify its IP address and network parameters. This
essentially defines the expected behavior of the mobile node that
loses network connectivity and re-enters subnet.
Link Local Addresses have been proposed in ZEROConf [10] . The
host seeds a random number generator with the hardware address (MAC
address) of the interface, and randomly chooses an address in the
required range (169.254/16 with the top and bottom 256 addresses
reserved). The host then does an ARP probe for the address, and if
there are any responses, then the host chooses another IP address at
random, and tries again. If there are no answers, then no one is
currently using the address on local link, the host is free to
assign the selected address. The host then does a couple of
gratuitous ARPs to flush any old ARP caches before using the address
for any application.
A "Zeroconf" capable hosts will have at least two addresses -
routable IP address (RFC 1918 address) and a zeroconf link-local
address from the 169.254/16 space.
Link Local addresses can be quite confusing since they have no
uniqueness beyond the local link.
Requirements:
1. Link-local addresses SHOULD be used only as a last resort.
<Kumar> Expires - April [Page 8]
DNA Requirements for IPv4 October 2003
6. Scenarios
The following sections describe various scenarios applicable to a
solution for network attachment detection.
6.1 A Device Moving from one IP subnet to another IP subnet
This is a normal scenario in which a mobile device moves from one
access point to another. This may at times result in crossing the
IP subnet boundaries.
Requirements:
1. SHOULD use link layer hints when available
2. SHOULD NOT make unnecessary attempt to change configuration
when not needed
3. MUST NOT generate un-necessary messages for the verification
of COA agent if the subnet has not changed.
4. In absence of any link ID change SHOULD assume that the
mobile is still on the same IP subnet.
5. SHOULD dampen the link level change information to suppress
erroneous hint
6.2 A Device Moving Back and from to the same IP subnet
This is another common scenario in which a mobile device moves
from one access point to another, but on the same subnet. It may
loose the link layer 2 connection while doing so, but will always
return to the same subnet.
1. SHOULD use link layer hints when available
2. SHOULD NOT make unnecessary attempt to change configuration
as they are not needed
3. MUST NOT generate un-necessary messages for the verification
of COA agent since the subnet has not changed.
4. SHOULD dampen the link level change information to suppress
erroneous hint
7. General Requirements for the Solution
<Kumar> Expires - April [Page 9]
DNA Requirements for IPv4 October 2003
This section contains a subsection for each of the three
identified areas. Within each subsection, terms and assumptions
are followed by specific DNA requirements in that area.
7.1 Movement Detection
General Requirements:
1. DNA method SHOULD not rely on prediction of the movement.
2. DNA method MUST not generate false event as it has impact on
the routing and configuration of the Mobility Agents and the
device.
3. DNA method SHOULD minimize introduction of new changes to
Mobile-IP protocol as defined in [5].
4. DNA method MUST not generate AGENT solicitation/
Advertisement messages at a faster rate than defined in [5].
5. DNA method SHOULD not rely on reducing agent advertisement
frequency.
6. DNA method MUST NOT require changes to any existing
applications running above the network/ transport layer.
7.2 Determining Configuration Action
It is important to dampen re-registrations when a device is
oscillating between coverage and non-coverage area.
Requirements
1. DNA mechanism SHOULD NOT require a device to make
extensive computation in making configuration decision.
2. The decision derived by the decision process SHOULD be
deterministic i.e., a device must always obtain the same
next configuration action under the same movement
conditions.
7.3 Device Configuration
<Kumar> Expires - April [Page 10]
DNA Requirements for IPv4 October 2003
The device and network configuration will be adjusted as result
of the movement detection. The requirements for the solution are
given below.
Requirements:
1. The device or network configuration MUST not be changed until
the movement detection has been verified, and both the network
mobility agent and the mobile device agree about the movement
event.
8. DNA and Context Transfer Protocol
Context Transfer [7] has been suggested as a mechanism to
optimize the hand-off delays between foreign agents on different
IP subnets. Like DNA, the L2 trigger can be used to initiate the
context transfer between two FAs. It is possible that the same L2
trigger at the network side can be used both for context transfer
as well as for DNA. Conceptually, the context transfer can take
place during, before or after device hand-off depending upon the
nature of context being transferred.
Requirements
1. The trigger used by DNA protocol can also be used as a
triggering mechanism for initiating the context transfer.
2. The DNA protocol MUST be independent of Context Transfer
protocol, and MUST not be affected by the failure of the context
transfer due to any reason.
9. DNA & QoS
The main purpose of DNA protocol is to be able to provide minimum
delay hand-offs. Therefore, it is important that the protocol is
able to operate within the desirable latency bounds required for
such applications.
Requirements:
1. The DNA protocol MUST not require any changes to the
applications to obtain the benefit of low latency hand-offs.
2. The DNA protocol SHOULD not require any knowledge of desired
QoS from any currently running applications on the device.
<Kumar> Expires - April [Page 11]
DNA Requirements for IPv4 October 2003
10. Security Considerations
Requirements:
1. DNA protocols MUST NOT be any less secure than current
IETF-standard protocols.
2. When Layer 2/3 trigger are used, the DNA protocol MUST be
secure with regards to some attackers generating false
L2/L3 triggers as to introduce reconfiguration action.
References
1 Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
3 Bernard Aboba, ôDetection of Network Attachment (DNA) in
IPv4ö, draft-ietf-dhc-dna-ipv4-00.txt, Expires 10 August 2003.
4 James Kempf (editor), ôSupporting Optimized handover for IP
Mobility - Requirements for Underlying systems", draft-
manyfolks-l2-mobilereq-02.txt, Expires 10 August 2003.
5 C. Perkins (editor), ôIP Mobility Support ", RFC 3220, January
2002
6 Karim El Malki (editor), ôLow Latency handoffs in Mobile
IPv4", draft-ietf-mobileip-lowlatency-handoffs-v4-05.txt,
Expires December 2003.
7. James Kemph (editor), "Problem Description: Reasons For
Performing Context Transfers Between Nodes in an IP Access
Network", RFC 3374, September 2002.
8. Brijesh Kumar, "Detecting Network Attachment - Requirements
for IPv6", draft-kumar-dna-rqmnt-IPv6-00.txt, October 2003
9. R. Droms, "Dynamic Host Configuration Protocol", RFC 2131,
March 1997
<Kumar> Expires - April [Page 12]
DNA Requirements for IPv4 October 2003
10. Stuart Cheshire et. Al., "Dynamic Configuration of Link-Local
IPv4 Addresses", <draft-ietf-zeroconf-ipv4-linklocal-10.txt>,
Sept 2003
Acknowledgments
< TBD>
Author's Addresses
Brijesh Kumar
Panasonic Technologies Company
2 Research Way, Princeton, NJ 08540
Phone: (609) 734 7329
Email: kumarb@research.panasonic.com
Sathya Narayanan
Panasonic Technologies Company
2 Research Way, Princeton, NJ 08540
Phone: (609) 734 7599
Email: sathya@research.panasonic.com
<Kumar> Expires - April [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-23 15:11:54 |