idnits 2.17.1 draft-chen-pcp-sipto-serv-discovery-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 date (September 18, 2013) is 3873 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-13) exists of draft-ietf-pcp-dhcp-08 == Outdated reference: A later version (-09) exists of draft-ietf-pcp-proxy-04 == Outdated reference: A later version (-10) exists of draft-ietf-pcp-server-selection-01 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP Working Group G. Chen 3 Internet-Draft China Mobile 4 Intended status: Standards Track T. Reddy 5 Expires: March 22, 2014 P. Patil 6 Cisco 7 M. Boucadair 8 France Telecom 9 September 18, 2013 11 PCP Server Discovery in Mobile Networks with SIPTO 12 draft-chen-pcp-sipto-serv-discovery-00 14 Abstract 16 This document proposes an extension to DHCPv4 Relay information so 17 that a PCP client learns the relevant PCP server deployed in the 18 context of traffic offload. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 22, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. DHCPv4 Relay Agent . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.2. Relay Agent behavior . . . . . . . . . . . . . . . . . . 4 59 3.3. DHCPv4 Server behavior . . . . . . . . . . . . . . . . . 4 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 63 7. Change History . . . . . . . . . . . . . . . . . . . . . . . 5 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 66 8.2. Informative References . . . . . . . . . . . . . . . . . 5 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 Given the exponential growth in the mobile data traffic, Mobile 72 Operators are investigating solutions to offload some of the IP 73 traffic flows at the nearest access edge that has an Internet 74 interconnection point. This approach results in efficient usage of 75 the mobile packet core and helps lower the transport cost. Since 76 Release 10, 3GPP starts supporting of Selected IP Traffic Offload 77 (SIPTO) function defined in [TS23.060], [TS23.401]. 79 The SIPTO function described in [TS23.060] allows an operator to 80 offload certain types of traffic at a network node close to the UE's 81 point of attachment to the access network. Traffic Offload 82 Function(TOF) has been defined to make such decisions and enforces 83 NAT for those traffic. The traffic would go through the Mobile 84 Packet Core only if the flow identification doesn't match TOF 85 filters. SIPTO architecture is also explained in 86 [I-D.chen-pcp-mobile-deployment]. 88 [I-D.ietf-pcp-dhcp] specifies DHCP (IPv4 and IPv6) options to 89 communicate Port Control Protocol (PCP) Server addresses to hosts. 90 However, PCP Client on the mobile node will not know whether a flow 91 will traverse the Mobile Packet Core or will get offloaded at the TOF 92 and hence will not know which PCP server to send its requests to. 93 Even if the mobile node learns its PCP server using DHCP, it will 94 only learn about the PCP server in the Mobile Packet Core since the 95 source of information is the DHCP server in the Mobile Packet Core. 96 The mobile node may never learn the presence of the PCP server at 97 TOF. This requires TOF to act as a PCP Proxy for the PCP server in 98 the Mobile Packet Core and as a PCP server for the offloaded traffic 99 at the TOF. However, this alone does not solve this problem since 100 the mobile node needs to be informed of the PCP proxy on the TOF. 102 This document proposes an extension to DHCPv4 Relay Information 103 Option to achieve this objective. This will also ensure that the PCP 104 client will only learn the PCP server address of the TOF. 106 Note: 108 o The SIPTO problem can be addressed for IPv6 either by using NPTv6 109 [RFC6296] or associating the mobile device with multiple IPv6 110 prefixes (one prefix to offload the traffic and other one provided 111 by the Mobile Packet Core for IP Mobility, access to Application 112 Servers in Mobile Packet Core etc). New DHCPv6 Relay Agent PCP 113 Server option will only be required if NPTv6 is used to offload 114 the traffic. However if multiple IPv6 prefixes are assigned to 115 the mobile device then it can use the mechanism explained in 116 [I-D.ietf-pcp-server-selection] to contact multiple PCP servers. 118 o The proposed extension to DHCPv4 Relay Information Option in this 119 document is also useful to solve problems in other deployments 120 like PMIPv6 [RFC5213] where mobile access gateway can selectively 121 offload some of the IPv4 traffic flows in the access network 122 instead of tunneling back to the local mobility anchor in the home 123 network [RFC6909]. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 3. DHCPv4 Relay Agent 133 When DHCPv4 Relay Agent [RFC3046] is co-located with the TOF, the 134 proposal is for the relay agent to influence the DHCPv4 Server to opt 135 for the PCP server address proposed by the Relay Agent over the one 136 configured on the DHCPv4 Server. The DHCPv4 Relay Agent will insert 137 a new suboption under relay agent information option indicating the 138 IP address of the appropriate PCP server/proxy. For this to happen, 139 the UE MUST ensure that it includes OPTION_PCP_SERVER in the 140 Parameter Request List Option in the DHCPv4 Discover/Request message. 142 3.1. Format 143 To realize the mechanism described above, the document proposes a new 144 PCP Server suboption for the DHCPv4 relay agent information option 145 that carries the IP address of PCP Server. If a PCP server is 146 associated with more than one IP address, all those IP addresses can 147 be listed as part of this option. If there is more than one PCP 148 server, there will be multiple instances of this option each 149 corresponding to a PCP server. 151 Code Length PCP IP address 152 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 153 | TBA | n | a1 | a2 | a3 | a4 | a1 | a2 | a3 | a4 | ... 154 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 156 Code: TBA 158 Length: Includes the length of the "PCP Server IP address" field in 159 octets; The maximum length is 255 octets. The length should be 160 multiple of 4. 162 PCP Server IP address: The IP address of the PCP Server to be used 163 by the PCP Client when issuing PCP messages. 165 3.2. Relay Agent behavior 167 A DHCPv4 relay agent MAY be configured to include a PCP Server 168 suboption in relayed DHCPv4 messages. If the source IP address in 169 the DHCPv4 request matches the TOF filter configuration then the PCP 170 Server IP address SHOULD be inserted into the PCP Server suboption. 171 The PCP Server IP address is determined through mechanisms outside 172 the scope of this document. 174 3.3. DHCPv4 Server behavior 176 The proposed suboption provides additional information to the DHCP 177 server. Upon receiving a DHCPv4 Discover/Request containing the 178 suboption, the DHCPv4 server, if configured to support this 179 suboption, MUST populate the DHCPv4 Offer/Ack with the suggested PCP 180 server IP address overriding any other PCP server IP address 181 configuration that it may already have. There is no special 182 additional processing for this suboption. 184 4. Security Considerations 186 The security considerations in [RFC6887] , [I-D.ietf-pcp-proxy] and 187 section 5 of [RFC3046] also apply to this use. 189 5. IANA Considerations 191 Authors of this document request IANA to assign a suboption number 192 for the PCP Server Suboption from the DHCP Relay Agent Information 193 Option [RFC3046] suboption number space. 195 6. Acknowledgements 197 TODO 199 7. Change History 201 [Note to RFC Editor: Please remove this section prior to 202 publication.] 204 8. References 206 8.1. Normative References 208 [I-D.ietf-pcp-dhcp] 209 Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 210 the Port Control Protocol (PCP)", draft-ietf-pcp-dhcp-08 211 (work in progress), August 2013. 213 [I-D.ietf-pcp-proxy] 214 Boucadair, M., Penno, R., and D. Wing, "Port Control 215 Protocol (PCP) Proxy Function", draft-ietf-pcp-proxy-04 216 (work in progress), July 2013. 218 [I-D.ietf-pcp-server-selection] 219 Boucadair, M., Penno, R., Wing, D., Patil, P., and T. 220 Reddy, "PCP Server Selection", draft-ietf-pcp-server- 221 selection-01 (work in progress), May 2013. 223 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 224 Requirement Levels", BCP 14, RFC 2119, March 1997. 226 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 227 3046, January 2001. 229 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 230 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 231 2013. 233 8.2. Informative References 235 [I-D.chen-pcp-mobile-deployment] 236 Chen, G., Cao, Z., Boucadair, M., Ales, V., and L. 237 Thiebaut, "Analysis of Port Control Protocol in Mobile 238 Network", draft-chen-pcp-mobile-deployment-04 (work in 239 progress), July 2013. 241 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 242 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 244 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 245 Translation", RFC 6296, June 2011. 247 [RFC6909] Gundavelli, S., Zhou, X., Korhonen, J., Feige, G., and R. 248 Koodli, "IPv4 Traffic Offload Selector Option for Proxy 249 Mobile IPv6", RFC 6909, April 2013. 251 [TS23.060] 252 3GPP, ., ""General Packet Radio Service (GPRS); Service 253 description; Stage 2", June 2012.", September 2012. 255 [TS23.401] 256 3GPP, ., "General Packet Radio Service (GPRS) enhancements 257 for Evolved Universal Terrestrial Radio Access Network (E- 258 UTRAN) access (Release 11), 3GPP TS 23.401, V11.2.0 (2012- 259 06).", September 2012. 261 Authors' Addresses 263 Gang Chen 264 China Mobile 265 No.32 Xuanwumen West Street 266 Xicheng District 267 Beijing 100053 268 China 270 Email: phdgang@gmail.com 272 Tirumaleswar Reddy 273 Cisco Systems, Inc. 274 Cessna Business Park, Varthur Hobli 275 Sarjapur Marathalli Outer Ring Road 276 Bangalore, Karnataka 560103 277 India 279 Email: tireddy@cisco.com 280 Prashanth Patil 281 Cisco Systems, Inc. 282 Bangalore 283 India 285 Email: praspati@cisco.com 287 Mohamed Boucadair 288 France Telecom 289 Rennes 35000 290 France 292 Email: mohamed.boucadair@orange.com