Re: [pcp] comments for draft "Analysis of Port Control P0rotocol in Mobile Network"

[GangChen <[e-mail]>]

Hi Tiru,

Thanks for the deep and detailed review.
I apology for my late reply.
In order to easy the discussion, I excerpt your comments and add the
replies as below.

Section 2.1
Would FW as network service be offered to all  Mobile subscribers or
based on some premium paid to some subscribers only ?

[cg] FW would offer to all subscribers as a basic service

where will the Firewalls be located in the Mobile Network when  SIPTO
is taken into consideration?

[cg] Each entry has their-own FW. In SIPTO case, there are two FWs
located in differnet data paths

How is this problem different from let’s say Firewall offered by SP ?

[cg] The discussion is more focused on issues in mobile networks.
I guess the issue is orthogonal to the FW in SP or NP.
SP could take mobile network as a access path. Therefore, the benefits
could also applicable to SP.

There are various modes in which Firewalls operate as explained in
http://tools.ietf.org/html/draft-ietf-opsawg-firewalls-01;
[1] you may want to clarify that you are referring to a firewall
configuration which “Block all outside-initiated traffic, allow all
inside-initiated
Traffic”

[cg]  I would add clarification texts in the next update. The FW in
the networks falls into the Category I

[2] will the subscriber be allowed to modify the Firewall configuration ?

[cg]  Subscriber can't modify configuration. It's only allowed using
administrator account.

[3] what is the Firewall capability offered by the Mobile Network -
Layer 4 and/or Layer 7 ?

[cg]  Only Layer4. Going upper layer requires DPI which is not widely deployed.

PCP messages are required to refresh the mapping. Further application
keep-alive would still be required to refresh the server state.
For more details refer to
http://tools.ietf.org/html/draft-reddy-pcp-optimize-keepalives-01#section-3.4

[cg]  I made following revision.

==Old==
thus would not need to be using keep-alive to keep the Firewall session open.

==New==

thus would lighten the traffic flow of keep-alive by reducing the
number of sending packets



Section 2.2/2.3

The problems of 2.2 and 2.3 seem to be also valid if the MN is using
Wifi in a Hot spot, Home Network etc. Why is this specific to 3GPP
network ?

[cg] Section 2.2 is specific to 3GPP network, since there are
different channels using for control messages and actual data trasport
in 3GPP network.
Those beacon messages are occupy the data channels so as to congest
voice calls. This issue would not occur in wifi case.
We may need to clarify this in next version.

[cg] Section 2.3 may applicable to wifi case. But there is different
state-changes in 3GPP networks. We may clarify that?

BTW, we don't want to differentiate 3GPPP and wifi. Because wifi is
also a part of mobile network.

Section 4

How will MN receive any other information that is provided by DHCP server ?

[cg]  MN usually receive the information through PCO

Will these techniques solve the IPv4 problem ?

[cg] Those are potential solutions. I guess the document is more
targeted to the discovery of specific issues.
We may add comments on those solutions in the next.

Section 5

Some time back there was discussion in the netext WG that – Mobile
Networks should move away from the model
of building application specific APN's and consolidate them into a
single home network.
For more details refer to
http://tools.ietf.org/html/draft-gundavelli-netext-multiple-apn-pmipv6-01

[cg]  This work is triggered by integration of 3GPP networks and Wifi
networks. PMIPv6 based S2a can't is restricted
with a single APN/home network. Therefore, the consolidation of
multiple APN feed this requirement.
However,this may not be a trend in a pure 3GPP environment.
At least, 3GPP doesn't discuss the APN aggregation and multiple APN
still widely used.

Section 6

This is a problem with any protocol using UDP. Retransmission is a
case of error;
With both PCP client and server in the same network – will
retransmission of PCP request be frequent because of packet loss ?

This is a implementation problem on the Mobile Device and not a
protocol problem;
PCP client could either be implemented in the kernel or each
application could be using its own PCP client.


[cg]  Compared to packet loss, we are more concerning about the roaming case.
MN with PCP-client may roam to a network where there is no PCP-server available.
Subsribers may easily find their MN running into outage when they are
on business trips.
That is not a protocol problem. We also not intend to change protocol
or impede the retransmission.
However, it's desirable to notice this potential consumption and
configure optimal value to each parameter in order to optimize radio
link usage.
That may easy mobile-operator's life to deploy PCP.


Section 7

I am not sure how NAT/Firewall would do this when rebooted ?
Are you referring they need persistence storage ?

[cg] I'm referring to using HA with hot-standby

Unsolicited responses could also be sent for other PCP requests like MAP.

[cg] Would you point me the description in PCP-base document?  I may miss that.


Section 8

Please clarify the procedure the PCP client must follow - Delete the
Mappings on the old PCP server;
before sending PCP requests to the new PCP server ?

[cg]  that is a good suggestion. I will add the procedure at next udpate.

TOF and NAT are co-located, so what is the problem in using RAB ID ?
SIPTO rules could be different per subscriber ;
so the PCP proxy needs to determine that the PCP request is coming
from a specific client
to pick the associated SIPTO rules for the subscriber so as to
determine if the request is to be processed locally or forwarded to
the PCP server in the EPC

[cg] The issue could refer to
http://www.3gpp.org/ftp/Specs/html-info/23060.htm.
In the TS 23.060 V10.0.0, the description of "SIPTO with Traffic
Offload Function" states:
"TOF inspects the NAS and RANAP messages to build the local UE context
and local session context.
When a RAB is requested to be set up and should be offloaded, ..."

Therefore, the offloaded IP flow is identified with RAB-ID, other than
IP 5-tuples.
If the intention is to adopt PCP-proxy with advanced functions in the
case of multiple PCP servers, PCP proxy must understand RAB-ID.
Additional mapping function may be required.


Section 9


Both NAT/Firewall and AAA are in the same administrative domain in the
Mobile Network
and that would be the same problem with NAT/Firewall in the Enterprise Network.
Please clarify how is this problem unique to 3GPP networks only ?

[cg]  We will make futher revision for this section. More
clarification will be added.

Best Regards

Gang

2013/4/27, Tirumaleswar Reddy (tireddy) <[e-mail]>:
> Hi Gang,
>
> As per the discussion during the interim; attached my comments for the
> draft.
>
> Regards,
> --Tiru.
>