📄 rfc3374.txt
字号:
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
transfer-candidate 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
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 service required to re-
establish the 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 specific services on a new
subnet or collection of subnets.
Context Transfer Candidate Service
A service that is a candidate for context transfer. In this
document, only services that are concerned with the forwarding
treatment of packets, such as QoS and security, or involve
granting or denying the mobile host access to the network, such as
AAA, are considered to be context transfer-candidate services.
3.0 Scope of the Context Transfer Problem
The context transfer problem examined in this document is restricted
to re-establishing services for a mobile host that are, in some
sense, related to the forwarding treatment of the mobile host's
Kempf Informational [Page 3]
RFC 3374 Context Transfer Problem Statement September 2002
packets or network access for the mobile host. It is not concerned
with actually re-establishing routing information. 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 the context of services related to
forwarding treatment or network access may also function for
application-level services as well.
An important consideration in whether a service is a candidate for
context transfer is whether it is possible to obtain a "correct"
context transfer for the service in a given implementation and
deployment, that is, one which will result in the same context at the
new access router as would have resulted had the mobile host
undergone a protocol exchange with the access router from scratch.
For some services, the circumstances under which context transfer may
result in correctness may be very limited [11].
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 context transfer-candidate 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 Context Transfer-candidate Service Re-establishment
As mentioned in the introduction, there are a variety of context
transfer-candidate 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
Kempf Informational [Page 4]
RFC 3374 Context Transfer Problem Statement September 2002
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 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
Kempf Informational [Page 5]
RFC 3374 Context Transfer Problem Statement September 2002
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
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
context transfer-candidate services on the new radio network, if no
translator were available, in order to hand over a mobile host
between two access technologies.
Kempf Informational [Page 6]
RFC 3374 Context Transfer Problem Statement September 2002
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 context transfer-candidate 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 context transfer-candidate
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 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 context transfer-candidate 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 context transfer-candidate services. Many
networks provide support for handover at Layer 2, within and between
Kempf Informational [Page 7]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -