Context and Micro-mobility Routing Working Group O. H. Levkowetz
Internet Draft ABNW
draft-ietf-seamoby-context-transfer-problem- P. R. Calhoun
stat-01.doc Sun MicroSystems, Inc
Expires: November 2001 G. Kenward
H. M. Syed
Nortel Networks
J. Manner
University of Helsinki
M. Nakhjiri
Motorola
G. Krishnamurthi
R. Koodli
Nokia
K. S. Atwal
Zucotto Wireless
M. Thomas
Cisco
M. Horan
COM DEV
P. Neumiller
3Com
May 2001
Problem Description: Reasons For Performing Context Transfers
Between Nodes in an IP Access Network
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 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.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Levkowetz et al. [Page 1]
Internet Draft May 2001
draft-ietf-seamoby-context-transfer-problem-stat-01.txt
Abstract
There are a large number of IP access networks that support mobility
of hosts. For example, wireless Personal Area Networks (PANs),
wireless LANs, satellite WANs and cellular WANs. The nature of this
mobility is such that the communication path to the host changes
frequently and rapidly.
This Internet-Draft describes the problem encountered during
mobility that requires the exchange of IP context between different
forwarding nodes in an access network.
Table of Contents
1 Introduction...................................................2
2 Reference Definitions..........................................3
3 The Need for Context Transfer..................................4
3.1 Scope of the Context Transfer Solution .....................5
3.2 Reference Architectures ....................................6
4 A Description of Context.......................................6
4.1 Feature ....................................................6
4.2 Feature Context ............................................7
4.3 Microflow Context ..........................................7
4.4 Common Context .............................................7
4.5 Examples of Feature Context ................................7
5 Context Transfer and Mobility..................................8
6 Forwarding Node Capabilities...................................8
7 Inter-technology Context Transfers.............................8
8 Performance Considerations.....................................8
9 Security Considerations........................................9
10 Recommendations...............................................9
1 Introduction
There are a large number of IP access networks that support hosts
that are mobile. For example, wireless Personal Area Networks
(PANs), wireless LANs, satellite WANs and cellular WANs. The nature
of this mobility is such that the communication path to a host may
change frequently and rapidly.
In networks where the hosts are mobile, the forwarding path through
the access network must often be redirected in order to deliver the
host's IP traffic to the new point of access. The success of a time
sensitive service such as VoIP telephony, video, etc., in a mobile
environment depends heavily upon the minimization of the impact of
this traffic redirection. In the process of establishing the new
forwarding path, the nodes along the new path must be prepared to
provide similar forwarding treatment to the IP packets.
Levkowetz et al. [Page 2]
Internet Draft May 2001
draft-ietf-seamoby-context-transfer-problem-stat-01.txt
The information required in support of a specific forwarding
treatment provided to IP traffic is part of the context for that
traffic. This context is comprised of configuration and state
information. To minimize the impact of a path change on an IP flow,
the context used at the forwarding nodes along the original path,
must be replicated at the forwarding nodes along the new path.
The transfer of context information may be advantageous in
minimizing the impact of host mobility on, for example, AAA, header
compression, QoS, Policy, and possibly sub-IP protocols and services
such as PPP. Context transfer at a minimum will be used to replicate
the configuration information needed to establish the respective
protocols and services. In addition, it may also provide the
capability to replicate state information, allowing stateful
protocols and services at the new node to be activated along the new
path with less delay and less signalling overhead.
2 Reference Definitions
Mobile Node
An IP node capable of changing its point of attachment to the
network. The mobile node is usually an end user host, but may be a
forwarding node for a network that is itself mobile.
Forwarding Node
A node that supports IP forwarding within the access network. This
includes all routers, gateways, servers and other nodes within the
network that have IP protocol stacks and forward IP traffic to and
from a mobile node.
A forwarding node will be connected to one or more other forwarding
nodes. Some forwarding nodes will be connected to zero or more
mobile nodes. The forwarding nodes that connect to mobile nodes will
do so through a layer two entity that supports wireless
communications.
Microflow
One useful definition for the fundamental unit of IP service is the
microflow. RFC 2475 [1] defines a microflow as:
A single instance of an application-to application flow of packets
destined to or originated from a mobile device (MN or MH), which is
identified by source address, source port, destination address,
destination port and protocol id.
Levkowetz et al. [Page 3]
Internet Draft May 2001
draft-ietf-seamoby-context-transfer-problem-stat-01.txt
RFC 2207 [2] provides a definition of a microflow that applies to
IPSec packets. It is based on the IPSec SPI found in the AH or ESP
headers. Other methods for identifying for IP microflows may be
defined in the future, e.g. the Ipv6 flow label.
3 The Need for Context Transfer
In networks where the hosts are mobile, the forwarding path through
the access network must often be redirected in order to deliver the
host's IP traffic to the new point of access. The success of a time
sensitive service such as VoIP telephony, video, etc., in a mobile
environment depends heavily upon the minimization of the impact of
this traffic redirection. In the process of establishing the new
forwarding path, the nodes along the new path must be prepared to
provide similar forwarding treatment to the IP packets.
Figure 1 and 2 below illustrate an example of a handover scenario. A
mobile node, MN7, is shown attached to the Internet via an access
network. The forwarding nodes, FN1 through to FN7 comprise a portion
of this access network. FN1 and FN7 are the last forwarding nodes
before the untethered link to MN7. This last link allows the nodes
to move while maintaining connectivity to the edge of the access
network - e.g. the last link is wireless. For simplicity, many
details of a real access network topology have been left out of the
diagrams.
Prior to handoff, the path for MN7's traffic traverses FN1 and FN2.
It is presumable that FN1 and FN2 have been configured to provide
specific forwarding services for MN7's traffic, and that some of
these services may require state information to be maintained.
MN7's traffic
<------------------>
------- -------
[ MN7 ]<= = = =>| FN1 |=================| FN2 |========
------- /-------
/
-------/
| FN4 |
/-------\
/ \
/ \
-------/ \-------
- - -| FN7 | | FN6 |----
------- -------
Figure 1: Path Prior to Handover
Levkowetz et al. [Page 4]
Internet Draft May 2001
draft-ietf-seamoby-context-transfer-problem-stat-01.txt
When MN7's movement results in the link to FN1 to be replaced by a
link to FN7, MN7's traffic must be re-directed along a new
forwarding path, illustrated in Figure 2 as the path through FN7,
FN4 and FN2. In many mobile networks, this handover can occur
frequently, and sometimes with little or no warning.
------- -------
- - -| FN1 |----------------| FN2 |========
------- //-------
// MN7's traffic
-------/ <----------->
| FN4 |
//------\
MN7's traffic // \
<-----------> // \
-------/ \-------
[ MN7 ]<= = = =>| FN7 | | FN6 |----
------- -------
Figure 2: Path Re-Directed After Handover
If the forwarding treatment provided to MN7's traffic is to be
sustained, the support conditions at FN1 and FN2 must be reproduced
at FN7 and FN4. At the very least, this requires that FN7 and FN4 be
configured to provide the appropriate support to the traffic flow.
However, establishing forwarding support along the new path through
the use of IP signalling protocols would be relatively time
consuming. In addition, given that some forwarding services may
maintain state information, simply configuring FN7 and FN4 would not
circumvent disruption of the services.
Given that FN7 and FN4 support the same functionality as FN1, it
should be possible to reproduce the needed support along the new
forwarding path by capturing the salient information at FN1 as it
exists just prior to the handover, and then use that information to
replicate the state of FN1 at FN7 and FN4.
3.1 Scope of the Context Transfer Solution
The information required to produce the necessary forwarding
treatments at a node is referred to as the support "context". In
order to replicate the context of one forwarding node at another
forwarding node, an open, standard solution for context transfer
must be developed.
In addition, for a forwarding node to be able to interpret the
transferred context, both the syntax and the semantics of the
context information must be defined. Definition of the actual
context information will be specific to the support feature being
replicated, however, a generic container format of the payload of
context transfer messages is required for inter-operability.
Levkowetz et al. [Page 5]
Internet Draft May 2001
draft-ietf-seamoby-context-transfer-problem-stat-01.txt
3.2 Reference Architectures
The concept of the "forwarding node" is used here to describe the
general context transfer problem. In different networks, the actual
context transfer may take place between different entities within
the network. In some cases the preferred context transfer peers
might be the routers at the edge of the access network. In other
situations, it may be more appropriate to transfer context between
wireless access points that also support forwarding of IP packets.
The context transfer solution will be applicable to any nodes that
support forwarding of a mobile nodes IP traffic.
4 A Description of Context
The term _context_ pertains to all information required by a
forwarding node specific to supporting the IP traffic for a
particular mobile node.
The context for a mobile node can be partitioned into three
categories:
- information required to provide generaly support to the
mobile node;
- information required to provide common support to the
mobile node's traffic;
- information required to support specific features of the
forwarding treatment for an IP microflow.
4.1 Feature
A feature is an aspect of the IP forwarding treatment that is
instantiated for each mobile node, and which may support one or more
of the mobile nodes microflows. A feature must include associated
configuration information: at the very least, some identification
information for the mobile node, such as the mobile node's IP
address. A feature may have associated state information.
In other words, for the purpose of supporting mobility the features
of interest all have context pertinent to the forwarding of a
specific mobile nodes IP packets. Examples of features include:
header compression, security, subscriber policy, and quality of
service.
Levkowetz et al. [Page 6]
Internet Draft May 2001
draft-ietf-seamoby-context-transfer-problem-stat-01.txt
Each feature is, in general, supported by an amalgamation of one or
more protocols and associated local support mechanisms. As an
example, header compression is a feature that consists of various
"mechanisms" such as IP/TCP header compression and IPv6/UDP/RTP
header compression, operating according to well-defined "protocols".
Thus, an instance of a feature reflects the state associated with
protocols and the corresponding mechanisms.
4.2 Feature Context
Feature context is the condition or state of an instance of a
particular feature. It represents the current evolution of the
behaviour of that feature instance. At a given instant in time,
feature context is represented by the values of the associated data
elements.
Some of the data elements associated with a feature are time
invariant and, thus, represent the configuration of the feature
instance. Other data elements, which are often referred to as the
"state variables" for the feature instance, change value over time
as a consequence of the various operations performed in support of
the feature instance.
A feature context is believed to be the smallest indivisible unit of
context that can be transferred between forwarding nodes.
4.3 Microflow Context
A microflow context is the collection of the various feature
contexts associated with a single IP microflow. It is the smallest
unit of context that must be transferred in order to re-establish
support for the microflow at a forwarding node.
4.4 Common Context
Some of the associated feature contexts may be applicable to more
then one of the IP microflows comprising the mobile node's traffic.
An example of this might be the authentication state for the mobile.
This type of feature context is also required to support each
microflow, but because of the multiplicity of the relationship to
the mobile node's microflows, it would seem prudent to transfer one
instance of the context, independent of the microflow context.
4.5 Examples of Feature Context
Some examples of feature contexts that are candidates for context
transfer are given below. This list is provided solely to illustrate
the nature of the context transfer problem domain.
- encryption context;
- authentication context;
Levkowetz et al. [Page 7]
Internet Draft May 2001
draft-ietf-seamoby-context-transfer-problem-stat-01.txt
- authorization context;
- accounting context;
- header compression context;
- quality of service context;
- policy enforcement context;
- multicast group membership;
- buffer state;
- sub-network layer context (e.g. PPP context).
5 Context Transfer and Mobility
Context transfer is an enhancement to a mobility solution that is
clearly most effective when used on a local scale between forwarding
nodes within a subnetwork. However, with due consideration to the
nature of the context and the requirements for transfer of that
context, context transfer should be applicable between any two
similar forwarding nodes.
6 Forwarding Node Capabilities
Context transfer between two forwarding nodes is worthwhile only if
the receiving node's capabilities are similar enough to those of the
sending node that the received context can be utilized. This does
not mean that the two nodes are identical in their implementation,
nor does it even imply that they must have identical capabilities.
A forwarding node that cannot make use of received context could,
and should, refuse the transfer. This would result in a situation no
different then mobile handover without context transfer.
7 Inter-technology Context Transfers
The context transfer described here operates at the IP layer, and
should be applicable to situations where the forwarding nodes are
supporting different wireless link technologies.
An exception to this would be where sub-IP layer context is an
intrinsic part of the forwarding treatment. In this situation, an
interworking solution must be developed for sub-IP context transfer
between the two technologies. This issue is outside the scope of the
Seamoby working group.
8 Performance Considerations
The purpose of context transfer is to sustain the services being
provided to a mobile node's traffic during handover. It is
essentially an enhancement to a mobility solution that ultimately
must result in an improvement in handover performance. The various
aspects of performance must be a prime consideration in the
development of the context transfer solution.
Levkowetz et al. [Page 8]
Internet Draft May 2001
draft-ietf-seamoby-context-transfer-problem-stat-01.txt
9 Security Considerations
Context transfer does not introduce any new types of threats to the
security of an IP network. The context itself may contain sensitive
information; in which case security measures applied to its transfer
should be the same as those measures applied to the transport of
information between peers in an IP network.
10 Recommendations
The Seamoby context transfer design team recommends the following:
- investigation into candidates for context transfer - in
particular, feature context transfer, and an analysis
of the transfer requirements for each candidate;
- the development of a framework and protocol(s) that will
support the transfer of configuration and state context
between the forwarding nodes of an IP network.
The context transfer solution must interwork with existing and
emerging IP protocols, in particular, those protocols supporting
mobility in an IP network.
References
[1] Blake, et al., "An Architecture for Differentiated Services",
RFC 2475, December 1998.
[2] Berger & O'Malley, "RSVP Extensions for IPSEC Data Flows",
RFC 2207, September 1997.
Authors' Addresses
O. Henrik Levkowetz
A Brand New World
Osterogatan 1
S-164 28 Kista
SWEDEN
Phone: +46 8 477 9942
EMail: henrik@levkowetz.com
Pat R. Calhoun
Network and Security Research Center, Sun Labs
15 Network Circle
Menlo Park CA 94025
USA
Phone: +1 650-786-7733
EMail: pcalhoun@eng.sun.com
Levkowetz et al. [Page 9]
Internet Draft May 2001
draft-ietf-seamoby-context-transfer-problem-stat-01.txt
Gary Kenward
Nortel Networks
3500 Carling Avenue
Nepean, Ontario K2G 6J8
CANADA
Phone: +1 613-765-1437
EMail: gkenward@nortelnetworks.com
Hamid Syed
Nortel Networks
100 Constellation Crescent
Nepean Ontario K2G 6J8
CANADA
Phone: +1 613 763-6553
EMail: hmsyed@nortelnetworks.com
Jukka Manner
Department of Computer Science, University of Helsinki
P.O. Box 26 (Teollisuuskatu 23)
FIN-00014 Helsinki
FINLAND
Phone: +358-9-191-44210
EMail: jmanner@cs.helsinki.fi
Madjid Nakhjiri
Motorola
1501 West Shure Drive
Arlington Heights IL 60004
USA
Phone: +1 847-632-5030
EMail: madjid.nakhjiri@motorola.com
Govind Krishnamurthi
Communications Systems Laboratory, Nokia Research Center
5 Wayside Road
Burlington MA 01803
USA
Phone: +1 781 993 3627
EMail: govind.krishnamurthi@nokia.com
Levkowetz et al. [Page 10]
Internet Draft May 2001
draft-ietf-seamoby-context-transfer-problem-stat-01.txt
Rajeev Koodli
Communications Systems Lab, Nokia Research Center
313 Fairchild Drive
Mountain View CA 94043
USA
Phone: +1 650 625 2359
EMail: rajeev.koodli@nokia.com
Kulwinder S. Atwal
Zucotto Wireless Inc.
Ottawa Ontario K1P 6E2
CANADA
Phone: +1 613 789 0090
EMail: kulwinder.atwal@zucotto.com
Michael Thomas
Cisco Systems
375 E Tasman Rd
San Jose CA 95134
USA
Phone: +1 408 525 5386
EMail: mat@cisco.com
Mat Horan
COM DEV Wireless Group
San Luis Obispo CA 93401
USA
Phone: +1 805 544 1089
EMail: mat.horan@comdev.cc
Phillip Neumiller
3Com Corporation
1800 W. Central Road
Mount Prospect IL 60056
USA
EMail: phil_neumiller@3com.com
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
Levkowetz et al. [Page 11]
Internet Draft May 2001
draft-ietf-seamoby-context-transfer-problem-stat-01.txt
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Levkowetz et al. [Page 12]
