Network Working Group G. Chen Internet-Draft Z. Cao Intended status: Informational China Mobile Expires: April 25, 2013 M. Boucadair France Telecom A. Vizdal Deutsche Telekom AG L. Thiebaut Alcatel-Lucent October 22, 2012 Analysis of Port Control Protocol in Mobile Network draft-chen-pcp-mobile-deployment-02 Abstract This memo provides a motivation description for the Port Control Protocol (PCP) deployment in a 3GPP mobile network environment. The document focuses on a mobile network specific issues (e.g. cell phone battery power consumption, keep-alive traffic reduction), PCP applicability to these issues is further studied and analysed. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 25, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Chen, et al. Expires April 25, 2013 [Page 1] Internet-Draft PCP-Mobile October 2012 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Benefits of Introducing PCP in Mobile Network . . . . . . . . 3 2.1. Restoring Internet Reachability . . . . . . . . . . . . . 3 2.2. Keepalive Message Optimization . . . . . . . . . . . . . . 4 2.3. Energy Saving . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Balance Resource Assignment . . . . . . . . . . . . . . . 4 3. Overviews of PCP Deployment in Mobile Network . . . . . . . . 5 4. PCP Server Discovery . . . . . . . . . . . . . . . . . . . . . 5 5. MN and multi-homing . . . . . . . . . . . . . . . . . . . . . 7 6. Retransmission Consideration . . . . . . . . . . . . . . . . . 7 7. Unsolicited Messages Delivery . . . . . . . . . . . . . . . . 8 8. SIPTO Architecture . . . . . . . . . . . . . . . . . . . . . . 9 9. Authentication Consideration . . . . . . . . . . . . . . . . . 9 10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 14.1. Normative References . . . . . . . . . . . . . . . . . . . 11 14.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Chen, et al. Expires April 25, 2013 [Page 2] Internet-Draft PCP-Mobile October 2012 1. Introduction The Port Control Protocol[I-D.ietf-pcp-base] allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a network address translator (NAT) or simple firewall(FW), and also allows a host to optimize its outgoing NAT keepalive messages. A 3rd Generation Partnership Project (3GPP) network can benefit from the use of the PCP service. Traffic in a mobile network is becoming a complex mix of various protocols, different applications and user behaviors. Mobile networks are currently facing several issues such as a frequent keepalive message, terminal battery consumption and etc. In order to mitigate these issues, PCP could be used to improve terminal behaviour by managing how incoming packets are forwarded by upstream devices such as NAT64, NAT44 translators and firewall devices. It should be noticed that mobile network have their particular characteristics. There are several factors that should be investigated before implementing PCP in a mobile context. Without the particular considerations , PCP may not provide desirable outcomes. Some default behaviours may even cause negative impacts or system failures in a mobile environment. Considering very particular environments of mobile networks , it's needed to have a document describing specific concerns from mobile network side. That would also encourage PCP support in mobile network as well. This memo covers PCP-related considerations in a mobile networks. The intension of publishing this memo is to elaborate major issues during the deployment and share the thoughts for a potential usages in mobile networks. Such considerations would provide a pointer to parties interested (e.g. mobile operators) to be included in their UE profile requirements. Some adaptation of PCP protocol might be derived from this document. Such a work would be documented in separated memo(s). 2. Benefits of Introducing PCP in Mobile Network 2.1. Restoring Internet Reachability Many Mobile networks are making use of a Firewall to protect their customers from an unwanted Internet originated traffic. The firewall is usually configured to reject all unknown inbound connections and only permit inbound traffic that belongs to a connection initiated from the Firewall or NAT/PAT device. There are applications that can be running on the terminal that require to be reachable from the Internet or there could be services running behind the terminal that require reachability from the Internet. PCP enabled applications / Chen, et al. Expires April 25, 2013 [Page 3] Internet-Draft PCP-Mobile October 2012 devices could request a port from the Firewall to ensure Internet reachability, and thus would not need to be using keep- alive to keep the Firewall session open. This would result in resource savings on the Firewall node whilst still keeping the customer protected form the unwanted traffic. 2.2. Keepalive Message Optimization Many always-on applications, e.g. instant message and p2p applications, are usually keeping long-lived connections with their network peers. To make sure that they can receive incoming traffic from their network peers, they issue periodic keep-alive messages in order to keep the NAT/FW bindings active. As the NAT/FW binding timer may be short and unknown to the UE, the frequency of these keep-alive may be high. These keep-alive generally do not contain useful data and thus correspond to "useless" usage of the radio spectrum and of network resources, e.g.: o Allocation of radio resources to traffic that could be avoided or limited o For each of these keep-alive messages, the UE needs to be put in CONNECTED state, i.e. an operation that consumes a fair amount of signaling PCP helps to reduce the frequency of periodic messages aimed at refreshing a NAT/FW binding by indicating to the mobile the Life time of a binding. PCP helps to avoid different periodic (keep-alive) messages from different applications by allowing the aggregation of binding refresh within one round-trip control message with the NAT/FW. 2.3. Energy Saving Devices with low battery resources exist widely in mobile environments, such as mobile terminals, advanced sensors, etc. Mobile terminals often go to "sleep" (IDLE) mode to extend battery life and save air resources. . Host initiated message needs to "wake-up" mobile terminals by changing the state to active. That would cause more energy on such terminals. Testing reports show that energy consumption is dramatically reduced with prolonged sending interval of signalling messages [VTC2007_Energy_Consumption]. 2.4. Balance Resource Assignment Network resources have been consumed due to heavy signaling process, like frequent beacon message, retransmission control. Such various usages are significantly increasing the resource consumption on a Chen, et al. Expires April 25, 2013 [Page 4] Internet-Draft PCP-Mobile October 2012 control plan and decreasing the efficiency on data forwarding (user plane). For example, 16% of traffic caused by instant signalling message would consume 50%~70% radio resource in some area. Since radio access is a resource constrained environment, imbalance of resource assignment would decline Call Setup Success Rate(CSSR) and operational profits. Reduction on control plan load would shift more resources for data transmission, which could contribute the optimization of resource arrangements. 3. Overviews of PCP Deployment in Mobile Network The Figure 1 shows the architecture of a mobile network. Radio access network would provide wireless connectivity to the MN. Packets are transmitted through Packet Switch(PS) domain heading to MGW. MGW bear the responsibilities of address allocation, routing and transfer. The connection between MN and MGW normally is a point-to- point link, on which MGW is the default router for MN. NAT/Firewall could either be integrated with MGW or deployed behind MGW as standalone. The traffic is finally destined to application servers, which manage subscriber service. MN Internet | +---------------+ +----------------+ +-+ +-----+ | +--|--+ +-------+ | +----------+ | | | /|/ | RAN |---| PS Network | MGW |---- |NAT/FW |----| |APP Server| | +-+ +-----+ | +--|--+ +-------+ | +----------+ | +---------------+ +----------------+ MN: Mobile Nodes RAN: Radio Access Network PS: Packet Switch MGW:Mobile GateWay NAT/FW: Network Address Translator or Firewall Figure 1: Mobile Networks Scenario A PCP client could be located on MN to control the outbound and inbound traffic on PCP servers. The PCP server is hosted by the NAT/FW respectively. Corresponding to the various behaviours of PCP client, MN would perform PCP operation using MAP, PEER or ANNOUNCE opcodes. A specific application programming interface may be provided to applications. More discussions and recommendations are presented in following sub-sections. 4. PCP Server Discovery A straightforward solution seems that MN assume their default router Chen, et al. Expires April 25, 2013 [Page 5] Internet-Draft PCP-Mobile October 2012 as the PCP Server. However, NAT/FW normally is deployed in a different node than the MGW. Thus there is the need to ensure that MN get information allowing them to discover a PCP server. [I-D.ietf-pcp-dhcp] specified name options in DHCPv4 and DHCPv6 to discover PCP server. It's expected the same mechanism could be used in mobile network. 3GPP network allocates IP address and respective parameter during the PDP (Packet Data Protocol)/PDN(Packet Data Network) context activation phase (PDP and PDN represent terminology in 3G and LTE network respectively ). On the UE, a PDP/PDN context has same meaning which is equivalent to a network interface. It should be noted that the Stateful DHCPv6-based address configuration[RFC3315]is not supported by 3GPP specifications. 3GPP adopts IPv6 Stateless Address Auto-configuration (SLAAC) [RFC4861]to allocate IPv6 address. The UE uses stateless DHCPv6[RFC3736] for additional parameter configuration. The MGW acts as the DHCPv6 server. PCP servers discovery could leverage current process to perform the functionalities. The M-bit is set to zero and the O-bit may be set to one in the Router Advertisement (RA) sent to the UE. To carry out PCP sever discovery, a MN should thus send an Information-request message that includes an Option Request Option (ORO) requesting the DHCPv6 PCP Server Name option. Regarding the IPv4 bearer, MN generally indicates that it prefers to obtain an IPv4 address as part of the PDP context activation procedure. In such a case, the MN relies on the network to provide IPv4 parameters as part of the PDP context activation/ PDN connection set-up procedure. The MN may nevertheless indicate that it prefers to obtain the IPv4 address and configuration parameter after the PDP Context activation by DHCPv4, but it is not available on a wide scale[RFC6459]. PCP server name options in DHCPv4 would not help the PCP servers discovery in that case. Alternative ways could be considered to support PCP server discovery by a MN: o Protocol Configuration Options(PCO) based[TS24.008] o DNS based A specific method in 3GPP is to extend PCO information element to transfer a request of PCP server name. However, additional specification efforts are required in 3GPP to make that happen. Another alternative solution is to directly perform an inverse name query in IN-ADDR.ARPA domain[RFC1035]. Normally, MN and NAT/FW would locate in same IPv4 subnet. The MN could easily determine the number of labels associating with IN-ADDR.ARPA to identify a particular zone. For example, Chen, et al. Expires April 25, 2013 [Page 6] Internet-Draft PCP-Mobile October 2012 UE with IPv4 10.1.0.0/16 could resolve the 1.10.IN-ADDR.ARPA locating PCP servers, the domain database would contain: 1.10.IN-ADDR.ARPA. PTR PCP.server.3gppnetwork.org. When it receives a RRs in response, like PCP.server.3gppnetwork.org. The UE could then originate QTYPE=A, QCLASS=IN queries for PCP.server.3gppnetwork.org. to discover the addresses. 5. MN and multi-homing As a MN may activate multiple PDP context / PDN connection, it may be multi-homed (the UE receives at least an IP address / an IPv6 prefix per PDN connection). Different MGW are likely to be associated with each of these PDP context / PDN connection and may thus advertise different PCP servers (using the mechanism described in the previous section). In that case, a MN has to be able to manage multiple PCP servers and to associate an IP flow with the PCP server corresponding to the PDP context / PDN connection used to carry that IP flow. 6. Retransmission Consideration A class of devices in mobile networks are usually powered with limited battery . Users would like to use such MN for several days without charging, even several weeks in sensor case. Many applications do not send or receive traffic constantly; instead, the network interface is idle most of the time. That could help to save energy unless there is data leading the link to be activated. Such state changes is based on network-specific timer values corresponding to a number of Radio Resource Control (RRC) states(see more at Section 8.2.2 3GPP[TS23.060]. In order to maximize battery life, it's desirable that all activities on battery-powered devices needs to be coordinated and synchronized. It's not specific to PCP. Whereas , those concerns also can be applied to PCP retransmission behavior. PCP designed retransmission mechanisms on the client for reliable delivery of PCP request. The client must retransmit request message until successfully receiving response or determining failure. Several timers were specified to control the retransmission behavior.The time transiting to idle is normally less than default Maximum Retransmission Time (MRT), i.e. 1024 seconds. With "no maximum" setting of MRD, it would cause devices activating their uplink radio in order to retransmit the request messages. Furthermore, the state transition and the transmission take some time, which causes significant power consumption. The MRD should be Chen, et al. Expires April 25, 2013 [Page 7] Internet-Draft PCP-Mobile October 2012 configured with an optimal time which in line with activated state duration on the device. The power consumption problem is made complicated if several PCP clients residing on a MN. Several clients are potentially sending requests at random times and by so doing causing MN uplink radio into a significantly power consuming state for unnecessarily often. It's necessary to perform a synchronization process for tidy up several PCP clients retransmission. A time-line observer maybe required to control different PCP clients resending requests in an optimal transmission window. If the uplink radio of MN is active at the time of sending retransmission from several clients, a proper MRD described as above should be set in a client. If the uplink radio of MN is in idle mode, the time-line observer should hold Initial Retransmission Time(IRT) for while to synchronize different retransmitted PCP requests into same optimal transmission window. 7. Unsolicited Messages Delivery When the states on NAT/FW have been changed like reboot or changed configuration, PCP servers can send unsolicited messages (e.g. ANNOUNCE Operation )to clients informing them of the new state of their mappings. This aims at achieving rapid detection of PCP failure and rapid PCP recovery. When those messages are delivered in a mobile environment, it should be noted multicast delivery may not be available in 3GPP network. PCP servers would use unicast delivery of ANNOUNCE. o This requires PCP servers to retain knowledge of the IP address(es) and port(s) of their clients even though they have rebooted o Care should be taken not to generate floods of unicast ANNOUNCE messages, e.g. to multiple thousands of MN that were served by a PCP server that has rebooted. Such flood may have a detrimental impact on Mobile Networks as it may imply the simultaneous generation of Paging process(see more at Section 8.2.4 3GPP[TS23.060]) for very big numbers of MN. o Paging function is optionally supported at some particular nodes, e.g. Traffic Offload Function (TOF) in Selected IP Traffic Offload architecture (more discussions on this issues is described in Section 7). The delivery of unsolicited messages would fail in this case. Chen, et al. Expires April 25, 2013 [Page 8] Internet-Draft PCP-Mobile October 2012 8. SIPTO Architecture Since Release 10, 3GPP starts supporting of Selected IP Traffic Offload (SIPTO) function defined in [TS23.060], [TS23.401].The SIPTO function allows an operator to offload certain types of traffic at a network node close to the UE's point of attachment to the access network. It can be achieved by selecting a set of MGWs that is geographically/topologically close to a UE's point of attachment. Two variants of solutions has specified in 3GPP. The mainstream standard deployment relies on selecting a MGW that is / are geographically/ topologically close to a UE's point of attachment. This deployment may apply to both 3G and LTE. The MN may sometimes be requested to re-activate its PDP context / PDN connection, in which case it is allocated a new MGW and thus a new IP address and a new PCP server. In this case SIPTO has no detrimental impact on PCP as SIPTO resolves to a change of MGW and of PCP server. As an implementation option dedicated to 3G networks, it is also possible to carry out Selected IP Traffic Offload in a TOF entity located at the interface of the Radio Access Network i.e. in the path between the Radio stations and the Mobile Gateway. The TOF decides on which traffic to offload and enforces NAT for that traffic. The point is that the deployment of a TOF is totally transparent for the UE that even cannot know which traffic is subject to TOF (NATed at the TOF) and which traffic is processed by the MGW (and the FW/NAT controlled by the PCP server whose address has been determined per mechanisms described in section 5 of this document). In case of TOF deployment, the PCP server advertised by the MGW does not take into account the NAT carried out by the TOF function. Therefore, PCP client doesn't know which PCP servers should be selected to send the request. [I-D.rpcw-pcp-pmipv6-serv-discovery]provides a solution in similar architecture, in which a smart PCP proxy[I-D.ietf-pcp-proxy] is required on the offloading point to dispatch requests to a right PCP server. However, TOF in 3GPP stores radio network layer information(e.g. RAB ID) to build the local offload context. That can't directly be used to identify a IP flow with 5 tuples. Additional functionalities is required to map identifier of IP flow to RAB ID. PCP proxy may need to include such radio link information in its local context. 9. Authentication Consideration The authentication issue in PCP is important to any operating networks, because operators do not want unauthenticated requests to Chen, et al. Expires April 25, 2013 [Page 9] Internet-Draft PCP-Mobile October 2012 control their NAT/FW ports and addresses. In mobile networks, this issue becomes especially important due to the fact that the mis- function of Carrier Grade NAT will severely destroy user experience and network operating. It may not be required if address validation[RFC3704] is enforced in the network. If the mechanism of IP address anti-spoofing is absent, the problem of PCP authentication comes from the fact that the PCP client (device) and PCP server (FW) usually do not have trust pre- established relationship with each other. To ensure client authentication, we can either use in-band or out-of-band solutions. In-band means that the authentication service is provided within the PCP exchange (e.g., by defining extended options), while out-of-band solutions handle the problem by establishing new trust relationships or reuse existing trust without extending the PCP base protocol. As an in-band solution, [I-D.ietf-pcp-authentication] has provided solutions for PCP authentication, in which an EAP option is included in the PCP requests from the devices. In mobile network, provisioning of new credentials to mobile devices is a difficult task. Taking this into consideration, using EAP-SIM/EAP-AKA/ EAP- AKA' authentication is recommended as in-band solution for 3GPP network. One possible out-band solution is the use of open authentication capability such as 3GPP GAA (Generic Authentication Architecture) defined in 3GPP[TS33.220]. So that, the PCP client can invoke the authentication ability provided by the operator. The other way is to reuse the trust relationship between UE and the MGW. Because the UE has been authenticated to the MGW during context setup, if the MGW delegates its trust to the NAT/FW device (PCP server), the NAT/FW device can trust the PCP requests from those users. 10. Conclusion PCP mechanism could be potentially adopted in different usage contexts. The deployment in mobile network described applicability analysis, which could give mobile operators a explicit recommendation for PCP implementation. Operators would benefit from such particular considerations. The memo would take the role to document such considerations for PCP deployment in mobile network. Chen, et al. Expires April 25, 2013 [Page 10] Internet-Draft PCP-Mobile October 2012 11. Security Considerations TBD 12. IANA Considerations This document makes no request of IANA. 13. Acknowledgements The authors would like to thank Dan Wing, Stuart Cheshire, Tirumaleswar Reddy, Ping Lin and Tao Sun for their discussion and comments. 14. References 14.1. Normative References [I-D.ietf-pcp-authentication] Wasserman, M., Hartman, S., and D. Zhang, "Port Control Protocol (PCP) Authentication Mechanism", draft-ietf-pcp-authentication-01 (work in progress), October 2012. [I-D.ietf-pcp-base] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", draft-ietf-pcp-base-28 (work in progress), October 2012. [I-D.ietf-pcp-dhcp] Boucadair, M., Penno, R., and D. Wing, "DHCP Options for the Port Control Protocol (PCP)", draft-ietf-pcp-dhcp-05 (work in progress), September 2012. [I-D.ietf-pcp-proxy] Boucadair, M., Dupont, F., Penno, R., and D. Wing, "Port Control Protocol (PCP) Proxy Function", draft-ietf-pcp-proxy-01 (work in progress), August 2012. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. Chen, et al. Expires April 25, 2013 [Page 11] Internet-Draft PCP-Mobile October 2012 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [TS23.060] "General Packet Radio Service (GPRS); Service description; Stage 2", June 2012. [TS23.401] "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", June 2012. 14.2. Informative References [I-D.rpcw-pcp-pmipv6-serv-discovery] Reddy, T., Patil, P., Chandrasekaran, R., and D. Wing, "PCP Server Discovery with IPv4 traffic offload for Proxy Mobile IPv6", draft-rpcw-pcp-pmipv6-serv-discovery-01 (work in progress), August 2012. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, January 2012. [TS24.008] "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3", 9.11.0 3GPP TS 24.008, June 2012. [TS33.220] "Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA)", 10.1.0 3GPP TS 33.220, March 2012. [VTC2007_Energy_Consumption] "Energy Consumption of Always-On Applications in WCDMA Networks", 2007. Chen, et al. Expires April 25, 2013 [Page 12] Internet-Draft PCP-Mobile October 2012 Authors' Addresses Gang Chen China Mobile No.32 Xuanwumen West Street Xicheng District Beijing 100053 China Email: phdgang@gmail.com Zhen Cao China Mobile No.32 Xuanwumen West Street Xicheng District Beijing 100053 China Email: caozhen@chinamobile.com Mohamed Boucadair France Telecom No.32 Xuanwumen West Street Rennes, 35000 France Email: mohamed.boucadair@orange.com Vizdal Ales Deutsche Telekom AG Tomickova 2144/1 Prague 4,, 149 00 Czech Republic Phone: Fax: Email: ales.vizdal@t-mobile.cz URI: Chen, et al. Expires April 25, 2013 [Page 13] Internet-Draft PCP-Mobile October 2012 Laurent Thiebaut Alcatel-Lucent Phone: Fax: Email: laurent.thiebaut@alcatel-lucent.com URI: Chen, et al. Expires April 25, 2013 [Page 14]