[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/