idnits 2.17.1 draft-cao-pcp-mobapp-online-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (March 6, 2011) is 4799 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-06 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP Working Group Z. Cao 3 Internet-Draft G. Chen 4 Intended status: Informational H. Deng 5 Expires: September 7, 2011 T. Sun 6 China Mobile 7 March 6, 2011 9 Requirements for Always Online Applications 10 draft-cao-pcp-mobapp-online-00 12 Abstract 14 This document discusses several requirements for always online mobile 15 applications which reveals that PCP only solution does not fill the 16 gap. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 7, 2011. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Conventions used in this document . . . . . . . . . . . . . 3 54 2. Scenario and Problems . . . . . . . . . . . . . . . . . . . . . 3 55 3. Requirements for Always-online Mobile Applications . . . . . . 4 56 3.1. R1: Support for NAT and Firewall State Keep-alive . . . . . 4 57 3.2. R2: Keep the State on Mobile App Server . . . . . . . . . . 4 58 3.3. R3: Keep the State on Mobile Network Gateway . . . . . . . 4 59 3.4. R4: Relieve Burden on Air Interface . . . . . . . . . . . . 5 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 62 6. Normative References . . . . . . . . . . . . . . . . . . . . . 5 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Introduction 67 This document discusses several requirements for always online mobile 68 applications which reveals that PCP only solution does not fill the 69 gap. 71 1.1. Conventions used in this document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 2. Scenario and Problems 79 Figure 1 depicts the secenario of the mobile network environment. BS 80 is the radio Base Station which provides wireless connectivity to the 81 MN. The MNG/FW is the MN's default router which provides IP address 82 management and NAT/Firewall functionality. The Border Router (BR) as 83 the name implies, borders the Internet for the mobile network. The 84 BR does not perform subscriber management for the mobile network. 85 The mobile application server is server on the Internet that provides 86 application layer service to the MN. 88 To make the mobile application behave like always online, there are 89 several states that need to be kept. Below, we take Instant Message 90 applications as an example, 92 1. Mobile App Server: the server needs to know if the mobile client 93 is still active and if the mobile node is still on-line. Mobile 94 application developers always make the mobile client send keep 95 alive messages at an interval. 96 2. NAT state: The GW/FW needs to keep the NAT binding state for the 97 TCP/UDP mappings. Once the NAT states staled, the mobile 98 application server is not able to push messages to the mobile 99 client. 100 3. IP address state: the mobile network normally uses the so called 101 "packet data protocol (PDP)" to manage the IP connection with the 102 MN. 103 4. Wireless Channel State: when packets are ready, the mobile node 104 needs to acquire the wireless channel in order to receive or 105 transmit those packet. 107 MN BS +----+ 108 | /\ /---------\ +------+ /-----------\ +--+ / \ 109 +-+ /_ \---/ Internal \|MNG/FW|/ Operator's \|BR|/Internet\ 110 | |---/ \ \IP Network /+------+\ IP Network /+--+\ / 111 +-+ \---------/ \-----------/ \ / 112 +----+ 113 | 114 +--------+ | 115 |Mob App |---+ 116 |Server | 117 +--------+ 118 MNG: Mobile Network Gateway 119 FW: Firewall 120 BR: Border Router 122 Figure 1: Mobile Client/Server Applications 124 3. Requirements for Always-online Mobile Applications 126 The requirements that need to be addressed by an always-online mobile 127 applications. 129 3.1. R1: Support for NAT and Firewall State Keep-alive 131 Mapping states on the NAT box or Firewall should be retained in order 132 to make the MN visible and reachable from outside. PCP 133 [I-D.ietf-pcp-base] is an instant solution this problem, however it 134 does not take into account the other problems as list below. 136 3.2. R2: Keep the State on Mobile App Server 138 The mobile application server needs to keep track of the mobile node 139 in order to know the status of the mobile application. For example, 140 mobile Instant Message servers need to know the MN's presence status 141 and notify their friends accordingly. 143 Note: most mobile applications send keep alive messages between the 144 MN and the server in order to keep the state on both the App Server 145 and the NAT/FW. 147 3.3. R3: Keep the State on Mobile Network Gateway 149 The IP connection between the MN and Mobile Network Gateway (MNG) is 150 managed by a certain Packet Data Protocol (PDP) in the mobile 151 network. The MNG frequently releases the resources and state of IP 152 connection after a setup timeout. In order to make the mobile 153 applications always online, the state on the MNG should be 154 maintained. 156 3.4. R4: Relieve Burden on Air Interface 158 In order to maintain any states mentioned above, it necessarily send 159 many small packets between the MN and MNG or MN and the APP Server 160 which incurs a huge burden on the air interface. Whenever 161 transmitting packets, one dedicated channel is required. When the 162 channel is released, the paging procedure is triggered. Both of 163 these incur a lot of signalling on the air interface. It is highly 164 indispensable to relieve the burden on air interface. 166 4. Security Considerations 168 TBD. 170 5. IANA Considerations 172 This document does not require any IANA actions. 174 6. Normative References 176 [I-D.ietf-pcp-base] 177 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and F. 178 Dupont, "Port Control Protocol (PCP)", 179 draft-ietf-pcp-base-06 (work in progress), February 2011. 181 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 182 Requirement Levels", BCP 14, RFC 2119, March 1997. 184 Authors' Addresses 186 Zhen Cao 187 China Mobile 188 Unit2, 28 Xuanwumenxi Ave,Xuanwu District 189 Beijing 100053 190 China 192 Email: zehn.cao@gmail.com 193 Gang Chen 194 China Mobile 195 Unit2, 28 Xuanwumenxi Ave,Xuanwu District 196 Beijing 100053 197 China 199 Email: chengang@chinamobile.com 201 Hui Deng 202 China Mobile 203 Unit2, 28 Xuanwumenxi Ave,Xuanwu District 204 Beijing 100053 205 China 207 Email: denghui@chinamobile.com 209 Tao Sun 210 China Mobile 211 Unit2, 28 Xuanwumenxi Ave,Xuanwu District 212 Beijing 100053 213 China 215 Email: suntao@chinamobile.com