Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network
RFC 3374

Document Type RFC - Informational (September 2002; No errata)
Last updated 2015-10-14
Stream IETF
Formats plain text pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3374 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Allison Mankin
IESG note Approved for Informational - 2002-06-13.
Published: RFC 3374
Send notices to (None)
Network Working Group                                      J. Kempf, Ed.
Request for Comments: 3374                                September 2002
Category: Informational

     Problem Description: Reasons For Performing Context Transfers
                 Between Nodes in an IP Access Network

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

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 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.

Kempf                        Informational                      [Page 1]
RFC 3374           Context Transfer Problem Statement     September 2002

Table of Contents

   1.0   Introduction................................................2
   2.0   Reference Definitions.......................................3
   3.0   Scope of the Context Transfer Problem.......................3
   4.0   The Need for Context Transfer...............................4
   4.1   Fast Context Transfer-candidate 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)....................................6
   4.2   Interoperability............................................6
   5.0   Limitations on Context Transfer.............................7
   5.1   Router Compatibility........................................7
   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..................................8
   7.0   Security Considerations.....................................8
   8.0   Recommendations.............................................9
   9.0   Acknowledgements............................................9
   10.0  References.................................................10
   11.0  Complete List of Authors' Addresses........................12
   12.0  Full Copyright Statement...................................14

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
   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 context transfer-candidate
   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

Kempf                        Informational                      [Page 2]
RFC 3374           Context Transfer Problem Statement     September 2002

   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 context
Show full document text