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]