[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04                                                
Network Working Group                                            G. Chen
Internet-Draft                                                    Z. Cao
Intended status: Informational                              China Mobile
Expires: January 17, 2013                                   M. Boucadair
                                                          France Telecom
                                                               A. Vizdal
                                                     Deutsche Telekom AG
                                                             L. Thiebaut
                                                          Alcatel-Lucent
                                                           July 16, 2012


          Analysis of Port Control Protocol in Mobile Network
                  draft-chen-pcp-mobile-deployment-01

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 January 17, 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 January 17, 2013                [Page 1]


Internet-Draft                 PCP-Mobile                      July 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 . . . . . . . . . . . . . . . . . 10
   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 January 17, 2013                [Page 2]


Internet-Draft                 PCP-Mobile                      July 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 January 17, 2013                [Page 3]


Internet-Draft                 PCP-Mobile                      July 2012


   devices could request a port or a port range 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 January 17, 2013                [Page 4]


Internet-Draft                 PCP-Mobile                      July 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 January 17, 2013                [Page 5]


Internet-Draft                 PCP-Mobile                      July 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 January 17, 2013                [Page 6]


Internet-Draft                 PCP-Mobile                      July 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

   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.
   Configurable timers of Maximum Retransmission Duration(MRD) gives an
   opportunity to optimize the behavior fitting into different
   environments.

   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].  The time transiting to idle is
   normally less than default Maximum Retransmission Time (MRT), i.e.
   1024 seconds.  With "no maximum" of MRD, 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.  That could help to avoid



Chen, et al.            Expires January 17, 2013                [Page 7]


Internet-Draft                 PCP-Mobile                      July 2012


   frequent wake-up the device and consume the battery.

   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 is 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 for the clients.  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.
   Such duration of optimal transmission window should equal with RRC
   state timer on the MN.  The holding timer in idle mode may be set as
   100 seconds as recommended in
   [I-D.savolainen-6man-optimal-transmission-window].  Several PCP
   clients should wait a random amount of time between 0 and 100
   milliseconds to prevent synchronization of all PCP clients.


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.  However, it may induce difficulties
   in mobile environments.

   Multicast delivery may not be available in 3GPP network, because it
   optionally supports IP Multicast routing of packets.  When multicast
   delivery is not possible, PCP servers may use unicast delivery of
   ANNOUNCE noting that

   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.




Chen, et al.            Expires January 17, 2013                [Page 8]


Internet-Draft                 PCP-Mobile                      July 2012


   Thus a PCP server SHOULD take care to throttle unicast ANNOUNCE
   messages it sends towards a collection of MN.

   Furthermore, such 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
   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



Chen, et al.            Expires January 17, 2013                [Page 9]


Internet-Draft                 PCP-Mobile                      July 2012


   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
   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.

   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



Chen, et al.            Expires January 17, 2013               [Page 10]


Internet-Draft                 PCP-Mobile                      July 2012


   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 Ping Lin an 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-00 (work in progress),
              June 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-26 (work in progress), June 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-03
              (work in progress), May 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-00 (work in progress), April 2012.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.




Chen, et al.            Expires January 17, 2013               [Page 11]


Internet-Draft                 PCP-Mobile                      July 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-00
              (work in progress), February 2012.

   [I-D.savolainen-6man-optimal-transmission-window]
              Savolainen, T. and J. Nieminen, "Optimal Transmission
              Window Configuration Option for ICMPv6 Router
              Advertisement",
              draft-savolainen-6man-optimal-transmission-window-00 (work
              in progress), June 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,



Chen, et al.            Expires January 17, 2013               [Page 12]


Internet-Draft                 PCP-Mobile                      July 2012


              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


   Mohamed Boucadair
   France Telecom
   No.32 Xuanwumen West Street
   Rennes,
   35000
   France

   Email: mohamed.boucadair@orange.com














Chen, et al.            Expires January 17, 2013               [Page 13]


Internet-Draft                 PCP-Mobile                      July 2012


   Vizdal Ales
   Deutsche Telekom AG
   Tomickova 2144/1
   Prague 4,,   149 00
   Czech Republic

   Phone:
   Fax:
   Email: ales.vizdal@t-mobile.cz
   URI:


   Laurent Thiebaut
   Alcatel-Lucent


   Phone:
   Fax:
   Email: laurent.thiebaut@alcatel-lucent.com
   URI:































Chen, et al.            Expires January 17, 2013               [Page 14]