< draft-ietf-seamoby-context-transfer-problem-stat-03.txt		draft-ietf-seamoby-context-transfer-problem-stat-04.txt >
			A new Request for Comments is now available in online RFC libraries.
	Context and Micro-mobility Routing Working Group J. Kempf,		RFC 3374
	Editor
	Internet Draft
	draft-ietf-seamoby-context-transfer-problem-stat-
	03.txt
	Expires: April, 2002
	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.
	Context Transfer Problem Statement October 2001
	Abstract
	In IP access networks that support host mobility, the routing paths
	between the host and the network may change frequently and rapidly.
	In some cases, the host may establish certain routing-related
	services on subnets that are left behind when the host moves.
	Examples of such services are AAA, header compression, and QoS. In
	order for the host to obtain those services on the new subnet, the
	host must explicitly re-establish the service by performing the
	necessary signaling flows from scratch. In some cases, this process
	would considerably slow the process of establishing the mobile host
	on the new subnet. An alternative is to transfer information on the
	existing state associated with these services, or context, to the
	new subnet, a process called "context transfer". This document
	discusses the desirability of context transfer for facilitating
	seamless IP mobility.
	Table of Contents
	1.0 Introduction.................................................2
	2.0 Reference Definitions........................................3
	3.0 Scope of the Context Transfer Problem........................4
	4.0 The Need for Context Transfer................................4
	4.1 Fast Routing-Related Service Re-establishment...............4
	4.1.1 Authentication, Authorization, and Accounting (AAA)....4
	4.1.2 Header Compression.....................................5
	4.1.3 Quality of Service (QoS)...............................5
	4.2 Interoperability............................................6
	5.0 Limitations on Context Transfer..............................6
	5.1 Router Compatibility........................................6
	5.2 Requirement to Re-initialize Service from Scratch...........7
	5.3 Suitability for the Particular Service......................7
	5.4 Layer 2 Solutions Better....................................7
	6.0 Performance Considerations...................................7
	7.0 Security Considerations......................................7
	8.0 Recommendations..............................................8
	9.0 Acknowledgements.............................................8
	10.0 References..................................................8
	11.0 Complete List of Authors' Addresses.........................9
	12.0 Full Copyright Statement...................................11
	13.0 Funding Acknowledgement....................................12
	1.0 Introduction
	In networks where the hosts are mobile, the routing path through the
	network must often be changed in order to deliver the host's IP
	traffic to the new point of access. Changing the basic routing path
	is the job of a IP mobility protocol, such as Mobile IPv4 [1] and
	Mobile IPv6 [2]. But the success of real time services such as VoIP
	telephony, video, etc., in a mobile environment depends heavily upon
	the minimization of the impact of this traffic redirection. In the
	Context Transfer Problem Statement October 2001
	process of establishing the new routing path, the nodes along the
	new path must be prepared to provide similar routing treatment to
	the IP packets as was provided along the old routing path.
	In many cases, the routing treatment of IP packets within a network
	may be regulated by a collection of routing-related services that
	influence how packets for the host are treated. For example, whether
	a particular host has the right to obtain any routing at all out of
	the local subnet may depend on whether the host negotiated a
	successful AAA exchange with a network access server at some point
	in the past. Establishing these services initially results in a
	certain amount of related state within the network and requires a
	perhaps considerable amount of time for the protocol exchanges. If
	the host is required to re-establish those services by the same
	process as it uses to initially establish them, delay-sensitive real
	time traffic may be seriously impacted.
	An alternative is to transfer enough information on the routing-
	related service state, or context, to the new subnet so that the
	services can be re-established quickly, rather than require the
	mobile host to establish them from scratch. The transfer of routing-
	related service context 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 can 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 signaling overhead.
	In this document, a case is made for why the Seamoby Working Group
	should investigate context transfer.
	2.0 Reference Definitions
	Context
	The information on the current state of a routing-related service
	required to re-establish the routing-related service on a new
	subnet without having to perform the entire protocol exchange
	with the mobile host from scratch.
	Context Transfer
	The movement of context from one router or other network entity
	to another as a means of re-establishing routing related services
	on a new subnet or collection of subnets.
	Routing-related Service
	A modification to the default routing treatment of packets to and
	from the mobile host. Initially establishing routing-related
	services usually requires a protocol exchange with the mobile
	Context Transfer Problem Statement October 2001
	host. An example of a routing-related service is header
	compression. The service may also be indirectly related to
	routing, for example, security. Security may not affect the
	forwarding decision of all intermediate routers, but a packet may
	be dropped if it fails a security check (can't be encrypted,
	authentication failed, etc.). Dropping the packet is basically a
	routing decision.
	3.0 Scope of the Context Transfer Problem
	The context transfer problem examined in this document is restricted
	to re-establishing routing-related services for a mobile host. It is
	not concerned with re-establishing routing itself. Routing changes
	due to mobility are the domain of the IP mobility protocol. In
	addition, transfer of context related to application-level services,
	such as those associated with the mobile host's HTTP proxy, is also
	not considered in this document, although a generic context transfer
	protocol for transferring routing-related services may also function
	for application-level services as well.
	4.0 The Need for Context Transfer
	There are two basic motivations for context transfer:
	1) The primary motivation, as mentioned in the introduction, is
	the need to quickly re-establish routing-related services
	without requiring the mobile host to explicitly perform all
	protocol flows for those services from scratch.
	2) An additional motivation is to provide an interoperable
	solution that works for any Layer 2 radio access technology.
	These points are discussed in more detail in the following
	subsections.
	4.1 Fast Routing-Related Service Re-establishment
	As mentioned in the introduction, there are a variety of routing-
	related services that could utilize a context transfer solution. In
	this section, three representative services are examined. The
	consequences of not having a context transfer solution are examined
	as a means of motivating the need for such a solution.
	4.1.1 Authentication, Authorization, and Accounting (AAA)
	One of the more compelling applications of context transfer is
	facilitating the re-authentication of the mobile host and re-
	establishment of the mobile host's authorization for network access
	in a new subnet by transferring the AAA context from the mobile
	host's previous AAA server to another. This would allow the mobile
	host to continue access in the new subnet without having to redo an
	AAA exchange with the new subnet's AAA server. Naturally, a security
	association between the AAA servers is necessary so that the mobile
	Context Transfer Problem Statement October 2001
	host's sensitive authentication information can be securely
	transferred.
	In the absence of context transfer, there are two ways that can
	currently be used for AAA:
	1) Layer 2 mechanisms, such as EAP [3] in PPP [4] or 802.1x [5]
	can be used to redo the initial protocol exchange, or possibly
	to update it. Currently, there is no general Layer 3 mechanism
	for conducting an AAA exchange between a host and an AAA
	server in the network.
	2) If the mobile host is using Mobile IPv4 (but not Mobile IPv6
	currently), the host can use the AAA registration keys [6]
	extension for Mobile IPv4 to establish a security association
	with the new Foreign Agent.
	Since 2) is piggybacked on the Mobile IPv4 signaling, the
	performance is less likely to be an issue, but 2) is not a general
	solution. The performance of 1) is likely to be considerably less
	than is necessary for maintaining good real time stream performance.
	4.1.2 Header Compression
	In [7], protocols are described for efficient compression of IP
	headers to avoid sending large headers over low bandwidth radio
	network links. Establishing header compression generally requires
	from 1 to 4 exchanges between the last hop router and the mobile
	host with full or partially compressed headers before full
	compression is available. During this period, the mobile host will
	experience an effective reduction in the application-available
	bandwidth equivalent to the uncompressed header information sent
	over the air. Limiting the uncompressed traffic required to
	establish full header compression on a new last hop router
	facilitates maintaining adequate application-available bandwidth for
	real time streams, especially for IPv6 where the headers are larger.
	Context transfer can help in this case by allowing the network
	entity performing header compression, usually the last hop router,
	to transfer the header compression context to the new router. The
	timing of context transfer must be arranged so that the header
	context is transferred from the old router as soon as the mobile
	host is no longer receiving packets through the old router, and
	installed on the new router before any packets are delivered to or
	forwarded from the mobile host.
	4.1.3 Quality of Service (QoS)
	Significant QoS protocol exchanges between the mobile host and
	routers in the network may be required in order to establish the
	initial QoS treatment for a mobile host's packets. The exact
	mechanism whereby QoS for a mobile host should be established is
	currently an active topic of investigation in the IETF. For existing
	QoS approaches (Diffsrv and Intsrv) preliminary studies have
	Context Transfer Problem Statement October 2001
	indicated that the protocol flows necessary to re-establish QoS in a
	new subnet from scratch can be very time consuming for Mobile IP,
	and other mobility protocols may suffer as well.
	A method of transferring the mobile host's QoS context from the old
	network to the new could facilitate faster re-establishment of the
	mobile host's QoS treatment on the new subnet. However, for QoS
	mechanisms that are end-to-end, transferring context at the last hop
	router may be insufficient to completely re-initialize the mobile
	host's QoS treatment, since some number of additional routers in the
	path between the mobile host and corresponding node may also need to
	be involved.
	4.2 Interoperability
	A particular concern for seamless handover is that different Layer 2
	radio protocols may define their own solutions for context transfer.
	There are ongoing efforts within 3GPP [8] and IEEE [9] to define
	such solutions. These solutions are primarily designed to facilitate
	the transfer of Layer 2-related context over a wired IP network
	between two radio access networks or two radio access points.
	However, the designs can include extensibility features that would
	allow Layer 3 context to be transferred. Such is the case with [10],
	for example.
	If Layer 2 protocols were to be widely adopted as an optimization
	measure for Layer 3 context transfer, seamless mobility of a mobile
	host having Layer 2 network interfaces that support multiple radio
	protocols would be difficult to achieve. Essentially, a gateway or
	translator between Layer 2 protocols would be required, or the
	mobile host would be required to perform a full re-initialization of
	its routing-related services on the new radio network, if no
	translator were available, in order to hand over a mobile host
	between two access technologies.
	A general Layer 3 context transfer solution may also be useful for
	Layer 2 protocols that do not define their own context transfer
	protocol. Consideration of this issue is outside the scope of the
	Seamoby Working Group, however, since it depends on the details of
	the particular Layer 2 protocol.
	5.0 Limitations on Context Transfer
	Context transfer may not always be the best solution for re-
	establishing routing-related services on a new subnet. There are
	certain limitations on when context transfer may be useful. These
	limitations are discussed in the following subsections.
	5.1 Router Compatibility
	Context transfer between two routers is possible only if the
	receiving router supports the same routing-related services as the
	sending router. This does not mean that the two nodes are identical
	in their implementation, nor does it even imply that they must have
	Context Transfer Problem Statement October 2001
	identical capabilities. A router that cannot make use of received
	context should refuse the transfer. This results in a situation no
	different than a mobile host handover without context transfer, and
	should not be considered an error or failure situation.
	5.2 Requirement to Re-initialize Service from Scratch
	The primary motivation for context transfer assumes that quickly re-
	establishing the same level of routing-related service on the new
	subnet is desirable. And yet, there may be situations where either
	the device or the access network would prefer to re-establish or re-
	negotiate the level of service. For example, if the mobile host
	crosses administrative domains where the operational policies
	change, negotiation of a different level of service may be required.
	5.3 Suitability for the Particular Service
	Context transfer assumes that it is faster to establish the service
	by context transfer rather than from scratch. This may not be true
	for certain types of service, for example, multicast, "push"
	information services.
	5.4 Layer 2 Solutions Better
	Context transfer is an enhancement to improve upon the performance
	of a handover for Layer 3 routing-related services. Many networks
	provide support for handover at Layer 2, within and between subnets.
	Layer 3 context transfer may not provide a significant improvement
	over Layer 2 solutions, even for Layer 3 context, if the handover is
	occurring between two subnets supporting the same Layer 2 radio
	access technology.
	6.0 Performance Considerations
	The purpose of context transfer is to sustain the routing-related
	services being provided to a mobile host's traffic during handover.
	It is essentially an enhancement to IP mobility that ultimately must
	result in an improvement in handover performance. A context transfer
	solution must provide performance that is equal to or better than
	re-initializing the routing-related service between the mobile host
	and the network from scratch. Otherwise, context transfer is of no
	benefit.
	7.0 Security Considerations
	Any context transfer standard must provide mechanism for adequately
	securely the context transfer process, and a recommendation to
	deploy security, as is typically the case for Internet standards.
	Some general considerations for context transfer security include:
	- Information privacy: the context may contain information which
	the end user or network operator would prefer to keep hidden
	from unauthorized viewers.
	Context Transfer Problem Statement October 2001
	- Transfer legitimacy: a false or purposely corrupted context
	transfer could have a severe impact upon the operation of the
	receiving router, and therefore could potentially affect the
	operation of the access network itself. The potential threats
	include denial of service and theft of service attacks.
	- Security preservation: part of the context transfer may include
	information pertinent to a security association established
	between the mobile host and another entity on the network. For
	this security association to be preserved during handover, the
	transfer of the security context must include the appropriate
	security measures.
	It is expected that the measures used to secure the transport of
	information between peers (e.g. IPSEC [10]) in an IP network should
	be sufficient for context transfer. However, given the above
	considerations, there may be reason to provide for additional
	security measures beyond the available IETF solutions.
	The context transfer investigation must identify any novel security
	measures required for context transfer that exceed the capabilities
	of the existing or emerging IETF solutions.
	8.0 Recommendations
	The following steps are recommended for Seamoby:
	- Investigation into candidate router-related services for
	context and an analysis of the transfer requirements for each
	candidate;
	- The development of a framework and protocol(s) that will
	support the transfer of context between the routing nodes of
	an IP network.
	The context transfer solution must inter-work with existing and
	emerging IP protocols, in particular, those protocols supporting
	mobility in an IP network.
	9.0 Acknowledgements
	The editor would like to thank the Seamoby CT design team (listed at
	the end of the draft as co-authors), who were largely responsible
	for the initial content of this draft, for their hard work, and
	especially Gary Kenward, who shepherded the draft through its
	initial versions.
	10.0 References
	[1] Perkins, C., editor, "IP Mobility Support," RFC 2002, October,
	1996.
	Context Transfer Problem Statement October 2001
	[2] Johnson, D., and Perkins, C., "Mobility Support in IPv6," draft-
	ietf-mobileip-ipv6-14.txt, a work in progress.
	[3] Blunk, L., and Vollbrecht, J., "PPP Extensible Authentication
	Protocol (EAP)," RFC 2284, March, 1998.
	[4] Simpson, W., editor, "The Point-to-Point Protocol (PPP)," STD
	51, July, 1994.
	[5] IEEE Std. P802.1X/D11, "Standard for Port based Network Access
	Control," March, 2001.
	[6] Perkins, C., and Calhoun, P., "AAA Registration Keys for Mobile
	IP", draft-ietf-mobileip-aaa-key-08.txt, a work in progress.
	[7] Borman, C., editor, "RObust Header Compression (ROHC): Framework
	and four profiles: RTP, UDP, ESP, and uncompressed," RFC 3095,
	July, 2001.
	[8] 3GPP TR 25.936 V4.0.0, "Handovers for Real Time Services from PS
	Domain," 3GPP, March, 2001.
	[9] IEEE Std. 802.11f/D2.0, "Draft Recommended Practice for Multi-
	Vendor Access Point Interoperability via an Inter-Access Point
	Protocol Across Distribution Systems Supporting IEEE 802.11
	Operation," July, 2001.
	[10] Kent, S. and Atkinson, R., "Security Architecture for the
	Internet Protocol", RFC 2401, November, 1998.
	11.0 Complete List of 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
	Black Storm Networks
	250 Cambridge Ave.
	Palo Alto CA 94306
	USA
	Phone: +1 650-617-2932
	EMail: pcalhoun@bstormnetworks.com
	James Kempf
	NTT DoCoMo USA Laboratories
	Context Transfer Problem Statement October 2001
	181 Metro Drive, Suite 300
	San Jose, CA 95110
	USA
	Phone: 408-451-4711
	EMail: kempf@docomolabs-usa.com
	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
	Rajeev Koodli
	Context Transfer Problem Statement October 2001
	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		Title: Problem Description: Reasons For Performing
	COM DEV Wireless Group		Context Transfers Between Nodes in an IP Access
	San Luis Obispo CA 93401		Network
	USA		Author(s): J. Kempf, Ed.
			Status: Informational
			Date: September 2002
			Mailbox: kempf@docomolabs-usa.com
			Pages: 14
			Characters: 28245
			Updates/Obsoletes/SeeAlso: None
	Phone: +1 805 544 1089		I-D Tag: draft-ietf-seamoby-context-transfer-problem-stat-04.txt
	EMail: mat.horan@comdev.cc
	Phillip Neumiller		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3374.txt
	3Com Corporation
	1800 W. Central Road
	Mount Prospect IL 60056
	USA
	EMail: phil_neumiller@3com.com		In IP access networks that support host mobility, the routing paths
			between the host and the network may change frequently and rapidly.
			In some cases, the host may establish certain context transfer
			candidate services on subnets that are left behind when the host
			moves. Examples of such services are Authentication, Authorization,
			and Accounting (AAA), header compression, and Quality of Service
			(QoS). In order for the host to obtain those services on the new
			subnet, the host must explicitly re-establish the service by
			performing the necessary signaling flows from scratch. In some cases,
			this process would considerably slow the process of establishing the
			mobile host on the new subnet. An alternative is to transfer
			information on the existing state associated with these services, or
			context, to the new subnet, a process called "context transfer". This
			document discusses the desirability of context transfer for
			facilitating seamless IP mobility.
	12.0 Full Copyright Statement		This document is a product of the Context Transfer, Handoff Candidate
			Discovery, and Dormant Mode Host Alerting Working Group.
	Copyright (C) The Internet Society (2001). All Rights Reserved.		This memo provides information for the Internet community. It does
			not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	This document and translations of it may be copied and furnished to		This announcement is sent to the IETF list and the RFC-DIST list.
	others, and derivative works that comment on or otherwise explain it		Requests to be added to or deleted from the IETF distribution list
	or assist in its implementation may be prepared, copied, published		should be sent to IETF-REQUEST@IETF.ORG. Requests to be
	and distributed, in whole or in part, without restriction of any		added to or deleted from the RFC-DIST distribution list should
	kind, provided that the above copyright notice and this paragraph		be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	are included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing
	Context Transfer Problem Statement October 2001
	the copyright notice or references to the Internet Society or other		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
	Internet organizations, except as needed for the purpose of		an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
	developing Internet standards in which case the procedures for		help: ways_to_get_rfcs. For example:
	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		To: rfc-info@RFC-EDITOR.ORG
	revoked by the Internet Society or its successors or assigns. This		Subject: getting rfcs
	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.
	13.0 Funding Acknowledgement		help: ways_to_get_rfcs
	Funding for the RFC editor function is currently provided by the		Requests for special distribution should be addressed to either the
	Internet Society.		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
			specifically noted otherwise on the RFC itself, all RFCs are for
			unlimited distribution.echo
			Submissions for Requests for Comments should be sent to
			RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 13 change blocks.
	591 lines changed or deleted		45 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/