Network Working Group J. Korhonen
Internet-Draft TeliaSonera
Expires: April 3, 2008 V. Devarapalli
Azaire
G. Giaretta
Telecom Italia
R. Koodli
Nokia
October 2007
IP Mobility and Policy Control
draft-korhonen-mobopts-mobility-policy-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on April 3, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The IETF has developed many IP Mobility protocols, some of which have
been successfully deployed. There has also been work done on
enabling fast and efficient handovers at L3 and extensions to access
Korhonen, et al. Expires April 3, 2008 [Page 1]
Internet-Draft IP Mobility and Policy Control October 2007
control protocols to enable fast handovers. One aspect that has not
been considered so far is the policies that a user is subjected to
when accessing a subscribed network. These policies, defined by the
network operator, have a significant impact on the user's mobility
experience. This document aims to provide a discussion document on
policy control and IP Mobility in controlled operator networks.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IP Mobility in IETF . . . . . . . . . . . . . . . . . . . . . 5
4. Policies in Operator Controlled Environments . . . . . . . . . 6
4.1. Policy Taxonomy . . . . . . . . . . . . . . . . . . . . . 6
4.2. Firewall Protected Networks . . . . . . . . . . . . . . . 7
4.3. Deployment Model Originating Restrictions . . . . . . . . 7
4.4. Controlled Access to Services . . . . . . . . . . . . . . 8
4.5. Service Access Through Multiple Accesses . . . . . . . . . 9
4.6. Location of the Policy Enforcement . . . . . . . . . . . . 9
4.7. Example - 3GPP PCC Architecture . . . . . . . . . . . . . 9
5. Issues in Integrating IP Mobility and Policies . . . . . . . . 13
5.1. Mandatory Reverse Tunneling through the Mobility Anchor . 13
5.2. Firewalling at Multiple Layers . . . . . . . . . . . . . . 13
5.3. Binding of Service Flows . . . . . . . . . . . . . . . . . 14
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Korhonen, et al. Expires April 3, 2008 [Page 2]
Internet-Draft IP Mobility and Policy Control October 2007
1. Introduction
The IETF has developed many IP Mobility protocols, some of which have
been successfully deployed. There has also been work done on
enabling fast and efficient handovers at L3 and extensions to access
control protocols to enable fast handovers. One aspect that has not
been considered so far is the policies that a user is subjected to
when accessing a subscribed network. These policies, defined by the
network operator, have a significant impact on the user's mobility
experience.
The policies configured on a network may govern what kind of service
the user is allowed, which access network the user is allowed to
attach to, enforce a particular quality of service (QoS) and restrict
the user to certain mobility protocols. The main purpose of this
document is to describe the problems encountered when applying IP
Mobility protocols to networks where such policies and the resulting
constraints exist. This would be useful to protocol designers who
can make better choices when designing IP Mobility protocols and to
network designers who develop the policy architecture and configure
the policies.
This document also includes a case study on a well known policy
architecture, developed by 3GPP, that is expected to be deployed in
various architectures developed in different standards organizations.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
Application Function (AF)
A service such as a SIP application server.
Home PCEF (H-PCEF)
A PCEF located in the Home PLMN.
General Packet Radio Service (GPRS)
GPRS is a mobile data service available to users of GSM and IS-136
mobile phones. 2G cellular systems combined with GPRS are often
described as "2.5G", that is, a technology between the second (2G)
and third (3G) generations of mobile telephony
Korhonen, et al. Expires April 3, 2008 [Page 3]
Internet-Draft IP Mobility and Policy Control October 2007
IP Connectivity Access Network (IP-CAN)
The collection of network entities and interfaces that provide the
underlying IP transport connectivity for the mobile node.
Policy and Charging Enforcement Function (PCEF)
A policy enforcement point like entity in the 3GPP Policy and
Charging Control framework that encompasses service IP flow
detection, policy enforcement and IP flow based charging
functionalities.
Policy and Charging Rules Function (PCRF)
A policy decision point like entity in the 3GPP Policy and
Charging Control framework that encompasses policy control
decision and IP flow based charging control functionalities.
Subscription Profile Repository (SPR):
A logical entity that contains all subscriber & subscription
related information needed for subscription-based policies and
access level policy and charging rules by the PCRF.
Visited PCEF (V-PCEF)
A PCEF located in the Visited PLMN.
Policy Decision Function (PDF)
A point where policy decisions are made.
Policy Enforcement Point (PEP)
A point where the policy decisions are actually enforced.
Public Land Mobile Network (PLMN)
A telecommunications network providing mobile cellular services.
Korhonen, et al. Expires April 3, 2008 [Page 4]
Internet-Draft IP Mobility and Policy Control October 2007
3. IP Mobility in IETF
This section reviews a few IP Mobility solutions being developed in
IETF.
IP Mobility support may be divided into several technical layers and
also categories depending on the nature of mobility. In this
document, we consider mobility solutions and protocols starting from
the network layer (layer 3 in the OSI stack) and up.
Mobility is inherently tied with the way nodes are addressed in a
distributed network. In this document, we present two different ways
to address mobile nodes: addresses with combined location and
identity, and addresses with a distinct locator and an identity.
There is a third way, content-based addressing [2][3], however that
is not typically within the scope of IETF. The first addressing
model is traditionally used by the IP based protocols. The second
model is an extension of the first and used, for example, in the Host
Identity Protocol (HIP) [4].
The most fundamental host controlled network-level protocols for
supporting mobile hosts are the family of Mobile IP protocols (
Mobile IPv4 [5] and Mobile IPv6 [6]). Another related network-level
solution reusing Mobile IP signaling is Network Mobility (NEMO) [7],
in which complete subnetworks may change location as well as single
hosts. It is also possible manage the IP Mobility completely on the
access network side without mobile host's involvement. In this case
mobility could also be handled locally, typically within one
administrative domain. Network based Localized Mobility management
(NetLMM) is a recent such example. Protocol proposals exist for both
Mobile IPv6 based solution [8] and Mobile IPv4 based solution [9].
It is also possible to have mobility handled on the transport layer.
Transport Layer Seamless Handover (TraSH), Datagram Congestion
Control Protocol (DCCP) and mobile-SCTP are recent examples of such
solutions. Yet another way of managing host mobility is the mobility
aware Virtual Private Network (VPN) such as MOBIKE [10] based IPSec
VPN. Protocols such as the Session Initiation Protocol (SIP) may
provide fine-grained mobility at the application level and they do
not assume underlying transport or network level mobility support.
There has been recent work on various enhancements to the existing IP
mobility protocols. Hierarchical Mobile IP (HMIPv6) [11] and Mobile
IPv4 Regional Registration [12] are examples of such protocol
enhancements that attempt to reduce signaling latencies based on
localized mobility agents. Furthermore, Fast Handovers for Mobile IP
(FMIPv6 [13] and FMIPv4 [14]) minimize the period during the handover
to a new access router where the MN is not able to send and/or
Korhonen, et al. Expires April 3, 2008 [Page 5]
Internet-Draft IP Mobility and Policy Control October 2007
receive IP packets due to the normal handover procedures. These
handover procedures include the Mobile IP based location update, IP
address configuration and movement detection.
Mobile IP for IPv4 and IPv4 are separate protocols, and in order to
solve the IP version migration there is ongoing work to introduce
dual-stack extensions to both Mobile IPv4 [15] and Mobile IPv6 [16].
The rationale for dual-stack solutions have been that MNs will anyway
have dual-stack support once Mobile IP gets deployed in large scale
and the IP version migration is more of an access network problem.
Depending what is the selected mobility management protocol version
these solutions function more efficiently in terms of tunneling
overhead and available functionality, such as route optimization,
over their native IP version in the access network. In case of IP
version migration the network controlled mobility management approach
could have less impact on MNs. They just use their native IP version
and the access network takes care of the migration. However, in this
approach the impact on the access networks is huge and unavoidable.
4. Policies in Operator Controlled Environments
Operator networks are typically well managed and controlled
networking environments. The cellular operators especially have
great interest in "managing" their subscribers access and services.
This has both regulatory and charging based background in general.
This section discusses some background related to the policies in
mobile operator type of network deployments. We also provide
examples of existing policy control frameworks that have been defined
for mobile operator space.
4.1. Policy Taxonomy
More text TBD.
Bearer Binding - The association between a service data flow and the
IP-CAN bearer transporting that service data flow.
Binding Mechanism - The method for creating, modifying and deleting
bindings. The binding mechanism is the procedure that associates
a service data flow, to the IP-CAN bearer deemed to transport the
service data flow. Thus, the binding mechanism shall associate
the application/service session information with the IP-CAN bearer
that is intended to carry the service data flow
Korhonen, et al. Expires April 3, 2008 [Page 6]
Internet-Draft IP Mobility and Policy Control October 2007
authorized QoS - The maximum QoS that is authorized for a service
data flow. In case of an aggregation of multiple service data
flows within one IP-CAN bearer, the combination of the Authorized
QoS information of the individual service data flows is the
"Authorized QoS" for the IP-CAN bearer.
service data flow - An aggregate set of packet flows.
packet flow - A specific user data flow carried through the policy
enforcement point. A packet flow can be an IP flow.
IP CAN bearer - An IP transmission path of defined capacity, delay
and bit error rate, etc.
4.2. Firewall Protected Networks
Today in typical operator network deployments everything is protected
with firewalls operating at various OSI layers. Even the so-called
public hotspot and residential broadband accesses are protected from
unknown inbound traffic from the Internet towards the access network
and the mobile node respectively. Issues regarding firewalls and
Mobile IPv6 have been discussed in detail in [17] and [18].
Furthermore, as a general case, discarding inbound IP-in-IP tunneled
and ESP encapsulated traffic is common even if the mobile node inside
the firewall protected network initiates the communication. This has
lead to the use of various UDP based NAT traversal solutions to solve
firewall issues as well.
It is becoming common in operator networks to extend the firewall
from the OSI layer-3 to upper layers. This leads quickly to cases
where, for example, the application layer protocol uses mobile node's
HoA for something and embeds the actual IP address inside the
protocol payload or header. Now if the firewall compares the outmost
IP addresses of the IP flow and those IP addresses embedded inside
the upper layer protocol it is possible there is a mismatch and the
firewall discards the packet.
4.3. Deployment Model Originating Restrictions
Original triangular routing of IP packets in case of Mobile IP was
soon enhanced with a capability to reverse tunnel all IP packets
through the Home Agent (HA). In general, reverse tunneling prohibits
the natural IP routing even more than the triangular routing as all
Korhonen, et al. Expires April 3, 2008 [Page 7]
Internet-Draft IP Mobility and Policy Control October 2007
IP packets must always go through the HA regardless of the
topological location of the HA. Reverse tunneling option remains
even in Mobile IPv6, which specifies a route optimization mode.
However, in commercial operator management networks there is no
urgency seen to deploy any of the available solutions that would
allow IP packets to bypass the HA, either to downlink or to uplink.
There are no insurmountable technical reasons to restrict the Mobile
IP deployment models to HA-centric one. The reason is basically the
same in case of Mobile IP that has hindered the deployment and the
use of visited PLMN GGSNs in GPRS networks [19]. Operators desire
control over the media flows that are related to their services and
offerings. Eventually, it is the requirement from an operator to
control access to services and bill for those services that appears
to dominate over technically superior solutions. If all IP packets
must be routed through a central controlling gateway (in this context
the HA) then the operator has total control and does not possibly
need to depend on visited networks and roaming partners when it comes
to billing information and services policy enforcement.
4.4. Controlled Access to Services
Some wireless access technologies, such as GPRS, allow services
categorization and access control based on the requested and the
initiated service. Eventually the selected service affects the
routing decision in the operator service selection gateway and also
allows binding service related policies to the specific access or the
IP flow.
It can be questioned whether this kind of approach is actually
feasible anymore in multi-radio terminals and in generic
heterogeneous networking environment where the operator might not be
the sole owner of all provided access technologies and services. In
such a multi-access environment, there is no uniform way of
performing service selection during the network access establishment
across different access technologies. Also, binding service level
policies to a specific access type in an access specific gateway
might not meet all new multi-access requirements where changing the
access technology during the application session is highly probable.
Furthermore, it is likely that the terminal runs multiple
applications and services simultaneously, and each of them having
different requirements for their access. Thus, binding policies to a
single access based on a single application's needs is unlikely to
work flawlessly.
Korhonen, et al. Expires April 3, 2008 [Page 8]
Internet-Draft IP Mobility and Policy Control October 2007
4.5. Service Access Through Multiple Accesses
Most of the existing policy control mechanisms has been designed with
static service scenario in mind. With static we mean that the MN's
IP address remains constant during the user session, and once
activated through some access (i.e. bearer) it is assumed that the
bearer does not change. If the bearer changes mid session, the
policy framework is likely to fall back to a default behavior rather
than attempt any optimization. It is also possible that the policy
control mechanism in question supports mid session updates on
policies.
4.6. Location of the Policy Enforcement
In many mobile networks a logical place for the Policy Enforcement
Point (PEP) is the gateway that terminates the user plane traffic.
Depending on the network deployment, there might be a number of
gateways terminating the user plane traffic. This is especially the
case in heterogeneous networks with multiple access technologies and
multihomed terminals. With multiple PEPs, policy enforcement for
service flows is obviously more challenging. For one IP flow one PEP
is active at given time.
The location of the PEP also matters in inter-operator roaming cases.
As mentioned earlier operators prefer to have total control over
their subscribers' service flows. This has lead to a situation where
basically all IP traffic gets forcibly routed back to home network's
anchoring gateways, even if the MN is roaming on the other side of
the world. Allowing the visited network also to apply policy rules
on behalf of the home operator is something that should be carefully
considered as a part of the general policy framework design.
4.7. Example - 3GPP PCC Architecture
Figure 1 shows overall architecture of 3GPP defined Policy and
Charging Control (PCC) (roaming) architecture that was defined for
the 3GPP Release-7 [20]. The solution has yet since raised interest
also outside 3GPP for other networking systems as a generic policy
framework. The PCC architecture makes extensive use of Diameter [21]
and especially the Credit Control [22] and NASREQ application
commands [23]. However, the usage of Diameter in the PCC has heavily
been altered and is basically 3GPP specific application [24][25] at
the moment. The PCC aims to be access technology agnostic but as of
its current state it requires more abstraction or either more
possibilities how to handle different types of access technologies.
From 3GPP point of view one of the issues is that the PCC needs also
address the policy solutions defined in earlier releases of the
general architecture [26].
Korhonen, et al. Expires April 3, 2008 [Page 9]
Internet-Draft IP Mobility and Policy Control October 2007
+--------------------------+ +--------------------------+
| +--------+ | | +--------------+ |
| | Proxy |--------------------------------------| OCS | |
| | OCS | | | | | |
| +--------+ | | +----+ +--------------+ |
| | | | | AF | |
| | | | +----+ |
| | | | | |
| | | | | |
| | +--------+ | | +--------+ +-----+ |
| | | V-PCRF |----------------| H-PCRF |--| SPR | |
| | +--------+ | | +--------+ +-----+ |
| | | | | |
| | | | | |
| +----------------------+ | | |
| | V-PCEF & GW | | | |
| +----------------------+ | | |
| | | | |
| | | | |
| +------+ +--------+ | | +--------+ |
| | OFCS |------| BSyst |----------------| BSyst | |
| +------+ +--------+ | | +--------+ |
| | | |
+--------------------------+ +--------------------------+
Figure 1: Logical PCC Architecture when the PCEF is in visited
network
Another issue that needs to be kept in mind concerning the policy
frameworks relates to generic access network deployments and inter-
operator connectivity. Typically, for example, GSM (GPRS) operators
have had a total control over the access networks, and the
interconnection and roaming traffic. This can still be seen from the
PCC framework. Today, GSM operators are connected through isolated
roaming and interconnection IP backbone network [27] with strict
Service Level Agreements (SLA) and rules that define how the roaming
must be deployed. This model works for services that are all within
the control of operators (mobile networks or even external networks
in some cases).
Within the PCC framework there are numerous different signaling
scenarios depending on for example:
Korhonen, et al. Expires April 3, 2008 [Page 10]
Internet-Draft IP Mobility and Policy Control October 2007
o Who initiates the bearer setup and/or update.
o Which node terminates session.
o Whether event notifications are used.
o Whether application function affects policies.
This document does not try to go through them all. Consult [20] and
[28] for more details. Figure 2 shows one example signaling
sequences for a policy download to the policy enforcement point after
the MN has established IP connectivity to the networking and service
system. The same signaling sequence can also be applied almost as is
to bearer update procedures.
Korhonen, et al. Expires April 3, 2008 [Page 11]
Internet-Draft IP Mobility and Policy Control October 2007
+------------+ +--------+ +-----+ +-----+ +-----+
| GW & PCEF | | PCRF | | SPR | | AF | | OCS |
+------------+ +--------+ +-----+ +-----+ +-----+
| | | | |
| | (1. App & Serv | info) | |
| |<------------------------| |
| | | | |
| | (2. Ack) | | |
3. Bearer | |------------------------>| |
signaling req | | | | |
--------------->| | | | |
| 4. Request or | | | |
| Indication | | | |
|-------------->| | | |
| | (5. Event info)| | |
| |------------------------>| |
| | | | |
| | (6. Ack) | | |
| |<------------------------| |
| | | | |
| | (7. Profile | req) | |
| |--------------->| | |
| | | | |
| | (8. Profile | rep) | |
| |<---------------| | |
| | | | |
| +--------------+ | | |
| | 9. Policy | | | |
| | decision | | | |
| | | | | |
| +--------------+ | | |
| | | | |
| 10. Ack & push| | | |
| policies | | | |
|<--------------| | | |
| | | | |
| 11. Credit req| | | |
|------------------------------------------------->|
| | | | |
| 12. Credit rep| | | |
|<-------------------------------------------------|
11. rep | | | | |
<---------------| | | | |
| | | | |
Figure 2: An overall 3GPP PCC signaling overview
Korhonen, et al. Expires April 3, 2008 [Page 12]
Internet-Draft IP Mobility and Policy Control October 2007
The first two steps assume that the MN has already established
connectivity and the initial policy might also have been established.
These step are relevant when the application function (e.g. some SIP-
based service) needs to update policies for a reason or another.
1) The application function provides service related information to
the PCRF (PDF). The trigger for the application function to
originates from the applications that the MN is using.
2) The PCRF (PDF) stores the service related information and
acknowledges the application function.
Rest of the signaling sequence details TBD later.
5. Issues in Integrating IP Mobility and Policies
This section discussed about identified issues when it comes to
policies and IP mobility. The background is mostly based on the
operator and network architecture assumptions discussed in previous
chapters.
5.1. Mandatory Reverse Tunneling through the Mobility Anchor
As already briefly discussed earlier mobile network operators prefer
routing all service relates IP traffic through their home network
independent where the MN is located. In IP Mobility sense this means
all IP traffic must traverse through the HA to both uplink and
downlink directions.
The model of described here has a number of issues. Firstly,
mandatory reverse tunneling effectively prohibits for example Mobile
IPv6 Route Optimization. The implications of this will be discussed
in more detail in section TBD. Secondly, another related issue is
the desire to use the mobility anchor located in the home network.
This kind of deployment decision affects inter-operator roaming cases
and effectively prohibits the use of local breakouts in the visited
networks. The implications of this issue will be discussed further
in section TBD.
5.2. Firewalling at Multiple Layers
In operator network environments it is common that firewalling is not
only applied to application level user traffic. Especially in inter-
operator roaming cases it is typical that operator also do rather (or
try to) intense packet analysis on received traffic. It is not
entirely clear what are the implications of this, if any, when MNs
Korhonen, et al. Expires April 3, 2008 [Page 13]
Internet-Draft IP Mobility and Policy Control October 2007
and possibly visited network gateways providing proxy mobility
services [8] for MNs change their point of attachment to the network
frequently.
More text TBD.
5.3. Binding of Service Flows
Policies that are tightly integrated to a specific access or a bearer
might make handovers rather inefficient. All service flows are bound
to a specific bearer and the binding needs to be updated when a
handover takes place. The update mechanism is typically reactive,
which means that both PEP and PDF react after the bearer has changed.
At least this could be the case for host controlled mobility, where
the policy update is partially triggered at the application rather
than only at the access level. After that the service flows need to
re-bound to the new bearer. Clearly this is not the most optimal
possible approach.
As mentioned earlier the trigger to update policies and binding may
also originate from the application (and application server).
However, if the mobility management functionality keeps the IP layer
intact the application does not really have a simple uniform way to
discover the change of bearer. Based on this, it is highly possible
that the trigger to update policies and binding always originates
from the gateway/mobility management function, after the handover has
taken place.
If the PEP and gateway functionality are separated from the first
user plane termination point and the access network specific
information gets abstracted completely away some new signaling is
required to inform the mobility management entity (e.g. the HA) about
the characteristics of the new bearer. Currently Mobile IP does not
have this functionality. This issue is discussed further in section
TBD.
6. Conclusions
TBD
7. IANA Considerations
This document does not define any new name spaces to be managed by
IANA. This document does not either reserve any new numbers or names
under any existing name space managed by IANA.
Korhonen, et al. Expires April 3, 2008 [Page 14]
Internet-Draft IP Mobility and Policy Control October 2007
8. Security Considerations
TBD
9. Acknowledgments
TBD
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
10.2. Informative References
[2] Carzaniga, A., Rosenblum, D., and A. Wolf, "Achieving
expressiveness and scalability in an internet-scale event
notification service", Nineteenth ACM Symposium on Principles
of Distributed Computing (PODC2000), July 2000.
[3] Muhl, G., Ulbrich, A., Herrman, K., and T. Weis, "Disseminating
information to mobile clients using publish/subscribe", IEEE
Internet Computing 46-53, May 2004.
[4] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP)
Architecture", RFC 4423, May 2006.
[5] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[7] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[8] Gundavelli, S., "Proxy Mobile IPv6",
draft-sgundave-mip6-proxymip6-01 (work in progress),
January 2007.
[9] Leung, K., "Mobility Management using Proxy Mobile IPv4",
draft-leung-mip4-proxy-mode-02 (work in progress),
January 2007.
Korhonen, et al. Expires April 3, 2008 [Page 15]
Internet-Draft IP Mobility and Policy Control October 2007
[10] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)",
RFC 4555, June 2006.
[11] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier,
"Hierarchical Mobile IPv6 Mobility Management (HMIPv6)",
RFC 4140, August 2005.
[12] Fogelstroem, E., "Mobile IPv4 Regional Registration",
draft-ietf-mip4-reg-tunnel-04 (work in progress), October 2006.
[13] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
[14] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers",
draft-ietf-mip4-fmipv4-03 (work in progress), February 2007.
[15] Tsirtsis, G., "Dual Stack Mobile IPv4",
draft-ietf-mip4-dsmipv4-01 (work in progress), December 2006.
[16] Soliman, H. and G. Tsirtsis, "Problem Statement: Dual Stack
Mobility", draft-ietf-mip6-dsmip-problem-03 (work in progress),
January 2007.
[17] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile IPv6
and Firewalls: Problem Statement", RFC 4487, May 2006.
[18] Chen, X., "Problem Statement for MIPv6 Interactions with GPRS/
UMTS Packet Filtering", draft-chen-mip6-gprs-07 (work in
progress), February 2007.
[19] 3GPP, "General Packet Radio Service (GPRS); Service
description; Stage 2", 3GPP TS 23.060 7.2.0, September 2006.
[20] 3GPP, "Policy and charging control architecture", 3GPP
TS 23.203 7.0.0, October 2006.
[21] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[22] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
Loughney, "Diameter Credit-Control Application", RFC 4006,
August 2005.
[23] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter
Network Access Server Application", RFC 4005, August 2005.
[24] 3GPP, "Policy and charging control over Gx reference point",
3GPP TS 29.212 1.0.0, December 2006.
Korhonen, et al. Expires April 3, 2008 [Page 16]
Internet-Draft IP Mobility and Policy Control October 2007
[25] 3GPP, "Policy and charging control over Rx reference point",
3GPP TS 29.214 1.0.0, December 2006.
[26] 3GPP, "Policy control over Go interface", 3GPP TS 29.207 6.5.0,
September 2005.
[27] GSM Association, "Inter-PLMN Backbone Guidelines", Public
Reference Document IR.34, April 2006.
[28] 3GPP, "Policy and charging control signalling flows and Quality
of Service (QoS) parameter mapping", 3GPP TS 29.213 1.0.0,
December 2006.
Authors' Addresses
Jouni Korhonen
TeliaSonera
P.O. Box 970
FIN-00051 Sonera
Finland
Email: jouni.korhonen@teliasonera.com
Vijay Devarapalli
Azaire Networks
4800 Great America Pkwy
Santa Clara, CA 95054
USA
Email: vijay.devarapalli@azaire.com
Gerardo Giaretta
Telecom Italia
via Reiss Romoli 274
Torino 10148
Italy
Email: gerardo.giaretta@gmail.com
Korhonen, et al. Expires April 3, 2008 [Page 17]
Internet-Draft IP Mobility and Policy Control October 2007
Rajeev Koodli
Nokia
313 Fairchild Drive
Mountain View, CA 94043
USA
Email: rajeev.koodli@nokia.com
Korhonen, et al. Expires April 3, 2008 [Page 18]
Internet-Draft IP Mobility and Policy Control October 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Korhonen, et al. Expires April 3, 2008 [Page 19]