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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Hi Gang,

Please see inline

> -----Original Message-----
> From: GangChen [mailto:[e-mail]]
> Sent: Monday, May 06, 2013 2:37 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: [e-mail]
> Subject: Re: comments for draft "Analysis of Port Control P0rotocol in Mobile
> Network"
> 
> 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.

If the use-case is applicable to other networks, I would suggest to explicitly state that to avoid confusion.

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

Ok.

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

Yes, that would help.

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

Ok.

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

clarify that.

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

It's explained in the following section http://tools.ietf.org/html/rfc6887#section-14.2


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

I thought there are multiple techniques, the other one is :

The new NAT would be informed about the UE point-of-attachment by the Home Node B Management System (HNS) (HNS is updated by the Node B (cell tower)). The new NAT is updated with the traffic offload policy rules for the subscriber by the HNS.

Does this also require using RAB-ID ?

Regards,
Tiru.

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