Network Working Group G. Chen
Internet-Draft Z. Cao
Intended status: Informational China Mobile
Expires: October 27, 2013 M. Boucadair
France Telecom
A. Vizdal
Deutsche Telekom AG
L. Thiebaut
Alcatel-Lucent
April 25, 2013
Analysis of Port Control P0rotocol in Mobile Network
draft-chen-pcp-mobile-deployment-03
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 analyzed.
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 October 27, 2013.
Copyright Notice
Copyright (c) 2013 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
Expires October 27, 2013 [Page 1]
Internet-Draft PCP-Mobile April 2013
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Benefits of Introducing PCP in Mobile Networks . . . . . . . 3
2.1. Restoring Internet Reachability . . . . . . . . . . . . . 3
2.2. Radio Resource Optimization . . . . . . . . . . . . . . . 3
2.3. Energy Saving . . . . . . . . . . . . . . . . . . . . . . 4
3. Overviews of PCP Deployment in Mobile Network . . . . . . . . 4
4. PCP Server Discovery . . . . . . . . . . . . . . . . . . . . 4
5. MN and multi-homing . . . . . . . . . . . . . . . . . . . . . 5
6. Retransmission Consideration . . . . . . . . . . . . . . . . 6
7. Unsolicited Messages Delivery . . . . . . . . . . . . . . . . 7
8. SIPTO Architecture . . . . . . . . . . . . . . . . . . . . . 7
9. Authentication Consideration . . . . . . . . . . . . . . . . 8
10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 9
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
14.1. Normative References . . . . . . . . . . . . . . . . . . 9
14.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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 behavior by managing
how incoming packets are forwarded by upstream devices such as NAT64,
NAT44 translators and firewall devices.
It should be noticed that mobile networks have particular
characteristics and therefore, there are several factors that should
Expires October 27, 2013 [Page 2]
Internet-Draft PCP-Mobile April 2013
be investigated before implementing PCP in a mobile context. Without
the particular considerations , PCP may not provide desirable
outcomes. Some default behaviors may even cause negative impacts or
system failures in a mobile environment. Considering very particular
environment 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 mobile networks. The
intension of publishing this memo is to elaborate major issues during
the deployment and share the thoughts for 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 Networks
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. For example, mobile phones
should be able to reachable for instant message or online game. PCP
enabled applications / 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 from the unwanted traffic.
2.2. Radio Resource Optimization
It's observed that radio resource is occupied by a number of trivial
keepalive mesages. Those messages are usually generated by always-on
application, e.g. IM, VoIP or P2P based applications. For each of
these keep-alive messages, the UE needs to be put in CONNECTED state,
which consumes a fair amount of signaling. For example, 16% of
traffic caused by instant signalling message would consume 50%~70%
radio resource in some area. PCP could help 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.
Expires October 27, 2013 [Page 3]
Internet-Draft PCP-Mobile April 2013
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].
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
Expires October 27, 2013 [Page 4]
Internet-Draft PCP-Mobile April 2013
A straightforward solution seems that MN assume their default router
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.
A specific method in 3GPP is to extend PCO [TS24.008]information
element to transfer a request of PCP server name. However,
additional specification efforts are required in 3GPP to make that
happen.
[I-D.cheshire-pcp-anycast]and
[I-D.kiesel-pcp-ip-based-srv-disc]provided another alternatives to
discover the closest PCP server on the data path.
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
Expires October 27, 2013 [Page 5]
Internet-Draft PCP-Mobile April 2013
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. If a PCP client fails to receive an
expected response from a server, the client must retransmit its
message. 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
configured with an optimal time which in line with activated state
duration on the device.
Expires October 27, 2013 [Page 6]
Internet-Draft PCP-Mobile April 2013
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.
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
Expires October 27, 2013 [Page 7]
Internet-Draft PCP-Mobile April 2013
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 general authentication requirements have been analyzed in
[I-D.reddy-pcp-auth-req]. In mobile networks, it is desirable to
reuse the existing credentials for the pcp authentication between
involved entities.
The [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 the EAP framework, the EAP
authentication server could be the co-located with the PCP server or
Expires October 27, 2013 [Page 8]
Internet-Draft PCP-Mobile April 2013
separated and located on a third-party entity. If the EAP
authentication server is placed on the AAA/Radius server, there is a
need of an interface between the PCP server and AAA. But per our
investigation, most exisiting NAT devices do not have such an
interface with AAA. So in practical deployment, this could be taken
into consideration.
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.
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-29 (work in progress), November 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-07
(work in progress), March 2013.
Expires October 27, 2013 [Page 9]
Internet-Draft PCP-Mobile April 2013
[I-D.ietf-pcp-proxy]
Boucadair, M., Penno, R., and D. Wing, "Port Control
Protocol (PCP) Proxy Function", draft-ietf-pcp-proxy-02
(work in progress), February 2013.
[I-D.reddy-pcp-auth-req]
Reddy, T., Patil, P., Wing, D., and R. Penno, "PCP
Authentication Requirements", draft-reddy-pcp-auth-req-02
(work in progress), April 2013.
[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.
[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.cheshire-pcp-anycast]
Cheshire, S., "PCP Anycast Address", draft-cheshire-pcp-
anycast-01 (work in progress), March 2013.
[I-D.kiesel-pcp-ip-based-srv-disc]
Kiesel, S. and R. Penno, "PCP Server Discovery based on
well-known IP Address", draft-kiesel-pcp-ip-based-srv-
disc-00 (work in progress), February 2013.
[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-02
(work in progress), February 2013.
Expires October 27, 2013 [Page 10]
Internet-Draft PCP-Mobile April 2013
[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.
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
Expires October 27, 2013 [Page 11]
Internet-Draft PCP-Mobile April 2013
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
Email: ales.vizdal@t-mobile.cz
Laurent Thiebaut
Alcatel-Lucent
Email: laurent.thiebaut@alcatel-lucent.com
Expires October 27, 2013 [Page 12]