Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network
RFC 3374
Document | Type | RFC - Informational (September 2002; No errata) | |
---|---|---|---|
Author | James Kempf | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3374 (Informational) | |
Action Holders |
(None)
|
||
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 contextShow full document text