Internet DRAFT - draft-chen-pcp-sipto-serv-discovery
draft-chen-pcp-sipto-serv-discovery
PCP Working Group G. Chen
Internet-Draft China Mobile
Intended status: Standards Track T. Reddy
Expires: March 22, 2014 P. Patil
Cisco
M. Boucadair
France Telecom
September 18, 2013
PCP Server Discovery in Mobile Networks with SIPTO
draft-chen-pcp-sipto-serv-discovery-00
Abstract
This document proposes an extension to DHCPv4 Relay information so
that a PCP client learns the relevant PCP server deployed in the
context of traffic offload.
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 March 22, 2014.
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
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
Chen, et al. Expires March 22, 2014 [Page 1]
Internet-Draft PCP Server Discovery with SIPTO September 2013
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DHCPv4 Relay Agent . . . . . . . . . . . . . . . . . . . . . 3
3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Relay Agent behavior . . . . . . . . . . . . . . . . . . 4
3.3. DHCPv4 Server behavior . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
7. Change History . . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
Given the exponential growth in the mobile data traffic, Mobile
Operators are investigating solutions to offload some of the IP
traffic flows at the nearest access edge that has an Internet
interconnection point. This approach results in efficient usage of
the mobile packet core and helps lower the transport cost. Since
Release 10, 3GPP starts supporting of Selected IP Traffic Offload
(SIPTO) function defined in [TS23.060], [TS23.401].
The SIPTO function described in [TS23.060] 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. Traffic Offload
Function(TOF) has been defined to make such decisions and enforces
NAT for those traffic. The traffic would go through the Mobile
Packet Core only if the flow identification doesn't match TOF
filters. SIPTO architecture is also explained in
[I-D.chen-pcp-mobile-deployment].
[I-D.ietf-pcp-dhcp] specifies DHCP (IPv4 and IPv6) options to
communicate Port Control Protocol (PCP) Server addresses to hosts.
However, PCP Client on the mobile node will not know whether a flow
will traverse the Mobile Packet Core or will get offloaded at the TOF
and hence will not know which PCP server to send its requests to.
Even if the mobile node learns its PCP server using DHCP, it will
only learn about the PCP server in the Mobile Packet Core since the
source of information is the DHCP server in the Mobile Packet Core.
The mobile node may never learn the presence of the PCP server at
Chen, et al. Expires March 22, 2014 [Page 2]
Internet-Draft PCP Server Discovery with SIPTO September 2013
TOF. This requires TOF to act as a PCP Proxy for the PCP server in
the Mobile Packet Core and as a PCP server for the offloaded traffic
at the TOF. However, this alone does not solve this problem since
the mobile node needs to be informed of the PCP proxy on the TOF.
This document proposes an extension to DHCPv4 Relay Information
Option to achieve this objective. This will also ensure that the PCP
client will only learn the PCP server address of the TOF.
Note:
o The SIPTO problem can be addressed for IPv6 either by using NPTv6
[RFC6296] or associating the mobile device with multiple IPv6
prefixes (one prefix to offload the traffic and other one provided
by the Mobile Packet Core for IP Mobility, access to Application
Servers in Mobile Packet Core etc). New DHCPv6 Relay Agent PCP
Server option will only be required if NPTv6 is used to offload
the traffic. However if multiple IPv6 prefixes are assigned to
the mobile device then it can use the mechanism explained in
[I-D.ietf-pcp-server-selection] to contact multiple PCP servers.
o The proposed extension to DHCPv4 Relay Information Option in this
document is also useful to solve problems in other deployments
like PMIPv6 [RFC5213] where mobile access gateway can selectively
offload some of the IPv4 traffic flows in the access network
instead of tunneling back to the local mobility anchor in the home
network [RFC6909].
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. DHCPv4 Relay Agent
When DHCPv4 Relay Agent [RFC3046] is co-located with the TOF, the
proposal is for the relay agent to influence the DHCPv4 Server to opt
for the PCP server address proposed by the Relay Agent over the one
configured on the DHCPv4 Server. The DHCPv4 Relay Agent will insert
a new suboption under relay agent information option indicating the
IP address of the appropriate PCP server/proxy. For this to happen,
the UE MUST ensure that it includes OPTION_PCP_SERVER in the
Parameter Request List Option in the DHCPv4 Discover/Request message.
3.1. Format
Chen, et al. Expires March 22, 2014 [Page 3]
Internet-Draft PCP Server Discovery with SIPTO September 2013
To realize the mechanism described above, the document proposes a new
PCP Server suboption for the DHCPv4 relay agent information option
that carries the IP address of PCP Server. If a PCP server is
associated with more than one IP address, all those IP addresses can
be listed as part of this option. If there is more than one PCP
server, there will be multiple instances of this option each
corresponding to a PCP server.
Code Length PCP IP address
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| TBA | n | a1 | a2 | a3 | a4 | a1 | a2 | a3 | a4 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
Code: TBA
Length: Includes the length of the "PCP Server IP address" field in
octets; The maximum length is 255 octets. The length should be
multiple of 4.
PCP Server IP address: The IP address of the PCP Server to be used
by the PCP Client when issuing PCP messages.
3.2. Relay Agent behavior
A DHCPv4 relay agent MAY be configured to include a PCP Server
suboption in relayed DHCPv4 messages. If the source IP address in
the DHCPv4 request matches the TOF filter configuration then the PCP
Server IP address SHOULD be inserted into the PCP Server suboption.
The PCP Server IP address is determined through mechanisms outside
the scope of this document.
3.3. DHCPv4 Server behavior
The proposed suboption provides additional information to the DHCP
server. Upon receiving a DHCPv4 Discover/Request containing the
suboption, the DHCPv4 server, if configured to support this
suboption, MUST populate the DHCPv4 Offer/Ack with the suggested PCP
server IP address overriding any other PCP server IP address
configuration that it may already have. There is no special
additional processing for this suboption.
4. Security Considerations
The security considerations in [RFC6887] , [I-D.ietf-pcp-proxy] and
section 5 of [RFC3046] also apply to this use.
Chen, et al. Expires March 22, 2014 [Page 4]
Internet-Draft PCP Server Discovery with SIPTO September 2013
5. IANA Considerations
Authors of this document request IANA to assign a suboption number
for the PCP Server Suboption from the DHCP Relay Agent Information
Option [RFC3046] suboption number space.
6. Acknowledgements
TODO
7. Change History
[Note to RFC Editor: Please remove this section prior to
publication.]
8. References
8.1. Normative References
[I-D.ietf-pcp-dhcp]
Boucadair, M., Penno, R., and D. Wing, "DHCP Options for
the Port Control Protocol (PCP)", draft-ietf-pcp-dhcp-08
(work in progress), August 2013.
[I-D.ietf-pcp-proxy]
Boucadair, M., Penno, R., and D. Wing, "Port Control
Protocol (PCP) Proxy Function", draft-ietf-pcp-proxy-04
(work in progress), July 2013.
[I-D.ietf-pcp-server-selection]
Boucadair, M., Penno, R., Wing, D., Patil, P., and T.
Reddy, "PCP Server Selection", draft-ietf-pcp-server-
selection-01 (work in progress), May 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
2013.
8.2. Informative References
[I-D.chen-pcp-mobile-deployment]
Chen, et al. Expires March 22, 2014 [Page 5]
Internet-Draft PCP Server Discovery with SIPTO September 2013
Chen, G., Cao, Z., Boucadair, M., Ales, V., and L.
Thiebaut, "Analysis of Port Control Protocol in Mobile
Network", draft-chen-pcp-mobile-deployment-04 (work in
progress), July 2013.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, June 2011.
[RFC6909] Gundavelli, S., Zhou, X., Korhonen, J., Feige, G., and R.
Koodli, "IPv4 Traffic Offload Selector Option for Proxy
Mobile IPv6", RFC 6909, April 2013.
[TS23.060]
3GPP, ., ""General Packet Radio Service (GPRS); Service
description; Stage 2", June 2012.", September 2012.
[TS23.401]
3GPP, ., "General Packet Radio Service (GPRS) enhancements
for Evolved Universal Terrestrial Radio Access Network (E-
UTRAN) access (Release 11), 3GPP TS 23.401, V11.2.0 (2012-
06).", September 2012.
Authors' Addresses
Gang Chen
China Mobile
No.32 Xuanwumen West Street
Xicheng District
Beijing 100053
China
Email: phdgang@gmail.com
Tirumaleswar Reddy
Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: tireddy@cisco.com
Chen, et al. Expires March 22, 2014 [Page 6]
Internet-Draft PCP Server Discovery with SIPTO September 2013
Prashanth Patil
Cisco Systems, Inc.
Bangalore
India
Email: praspati@cisco.com
Mohamed Boucadair
France Telecom
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Chen, et al. Expires March 22, 2014 [Page 7]
