Subject: Re: [dhcwg] [3gv6] about Prefix delegation in 3GPP EPC networks

From: [email-masked]
Date: Thu, 1 Apr 2010 23:26:23 +0800

Hi, Frank,
 
If the prefixes assigned to one PDN connection are aggregable, it is fine. The problem is we have to carefully deal with the possible gaps that may be left after several times PDs.
I think it is better if we can assign one shorter prefix to UE in one time.
 
I don't think R11 needs more complex alternatives. If we can figure a good solution for R10, R11 absolutely can use this solution if the requirement is not changed.
 
I will check your contributions to 3GPP and give you feedback in a few day.
 
Using different APN for different prefix length is not practical. Usually, We do not set too many APNs in the field network. It is not convenient for the UE to change one APN to another if it wants a different length prefix. Usually, differnt APN is set for different service.  UEs connected to the same APN may want to get different length prefixes due to differnt networks behind them.

--------------------------------------------------------------------------------

Zhenqiang Li
13911635816
Department of Network Technology
China Mobile Research Institute
2010-04-01

--------------------------------------------------------------------------------

发件人： Frank Brockners (fbrockne)
发送时间： 2010-03-30 15:50:07
收件人： [email-masked]; [email-masked]
抄送： [email-masked]; [email-masked]; [email-masked]; Dhananjay Patki (dhpatki)
主题： RE: [3gv6] about Prefix delegation in 3GPP EPC networks
 
Hi Zhenqiang Li,
 
please see some thoughts inline.. (Suresh will probably add more)
 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> [email-masked]
> Subject: [3gv6] about Prefix delegation in 3GPP EPC networks
> 
> Dear Suresh,
> 
> Nice meeting you at IETF 77.
> 
> First of all, I agree with you that it is good for a UE to use a
> shorter prefix to meet the situation, rather than using multiple /64
> prefixes.
 
...FB: there's been several discussions at this past IETF on this
particular topic - and the approach which seems to have wide support is
that for Release 10, one would support a model where one PDN connection
would continue to be represented by a *single* prefix. This prefix could
be shorter that /64. This means that we can still hand out multiple
prefixes to the UE, but it would always be possible to aggregate all of
them into a single prefix. We'd continue using SLAAC for assigning the
/64 for the UE (or better PDN-Connection-link) and would hand out the
remainder of the "shorter prefix" using DHCP PD. This will keep changes
to the current architecture to a minimum (incl. PCC will need to deal
with only a single prefix in its rules). More complex alternatives would
be explored in future releases (i.e. Release 11 and onwards).
 
I'm working on updating the contributions S2-101176, S2-101177,
S2-101178 that were submitted "for information" to the last 3GPP SA2
meeting to reflect these changes (which are only small deltas to the
current versions, so hope to have them available for discussion in the
next few days) (You can find the submitted version at
http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_78_San_Francisco/Docs/)
 
> 
> Some additional comments about your draft:
> 1. Where to store the prefix length that you reserved for each UE?
> 2. How to validate the request from UE to avoid address abusing?
 
...FB: The expected approach is that shorter prefixes would be handled
as a capability of the APN. This way you also won't have any issues with
"abuse" - each UE (for a particular APN supporting shorter prefixes)
could use DHCPv6 PD to request portions of the prefix. 

> 3. The proposed method in your draft seems address wasting, because
you
> reserve /x (x  < 64) prefix for each UE. It is better to store the
> minimum length that a UE can apply, and assign the proper lengh to UE
> based on the available adrress pool, the minimum length the UE can
> apply, and the length the UE actually requests.
 
...FB: If we do things on a per APN basis (as mentioned above), one
would expect that only those UEs who need shorter prefixes would use the
particular APN, so the amount of "wasted" addresses would be relatively
small. That said, the approach would just be for Release 10 (we just
have two more meetings to get this off the ground) - more optimal
approaches could be studied in future releases.
 
Regards, Frank
 
> 4. Are there any other alternatives besides DHCPv6-PD? I listed some
> potential solutions in a 3GPP document. What is your opinion to them?
> 
> Best Regards,
> Zhenqiang Li
> 13911635816
> Department of Network Technology
> China Mobile Research Institute
> 2010-03-26
> _______________________________________________
> 3gv6 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/3gv6

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Thu, 1 Apr 2010 17:54:50 +0200

Hi Zhenqiang,

> 
> Using different APN for different prefix length is not practical.
> Usually, We do not set too many APNs in the field network. It is not
> convenient for the UE to change one APN to another if it wants a
> different length prefix. Usually, differnt APN is set for different
> service.  UEs connected to the same APN may want to get different
> length prefixes due to differnt networks behind them.

...FB: Could you detail the deployment scenario a bit more? From what I've heard so far, the expectation is that subscriptions which will use shorter/multiple prefixes will be different from the typical service subscription of a mobile-phone user, e.g. those subscriptions would be broadband-home-router type devices using LTE to connect to the network. Hence the approach of using different APNs. You obviously have a different deployment model in mind. 

Appreciate your thoughts.

Thanks, Frank

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 01 Apr 2010 15:42:39 -0700

> if the prefixes assigned to one PDN connection are aggregable, it is fine. The
> problem is we have to carefully deal with the possible gaps that may be left
> after several times PDs.
I think it is better if we can assign one shorter
> prefix to UE in one time.

The individual prefix allocations are from a pre-assigned prefix block for
the UE, so, any holes due to non-assignment should not matter. You will
still have one aggregatable route on the anchor for each UE.

Sri

> Hi, Frank,
 
If the prefixes assigned to one PDN connection are aggregable, it
> is fine. The problem is we have to carefully deal with the possible gaps that
> may be left after several times PDs.
I think it is better if we can assign one
> shorter prefix to UE in one time.
 
I don't think R11 needs more complex
> alternatives. If we can figure a good solution for R10, R11 absolutely can use
> this solution if the requirement is not changed.
 
I will check your
> contributions to 3GPP and give you feedback in a few day.
 
Using different
> APN for different prefix length is not practical. Usually, We do not set too
> many APNs in the field network. It is not convenient for the UE to change one
> APN to another if it wants a different length prefix. Usually, differnt APN is
> set for different service.  UEs connected to the same APN may want to get
> different length prefixes due to differnt networks behind them.

----------------------------------------------------------------------------
> ----

Zhenqiang Li
13911635816
China Mobile
> Research 
> Institute
2010-04-01

--------------------------------------------------------
> ------------------------

发送时间： 2010-03-30
> 15:50:07
抄送：
> [email-masked]; [email-masked]; [email-masked]; Dhananjay Patki
> (dhpatki)
 
Hi
> Zhenqiang Li,
 
please see some thoughts inline.. (Suresh will probably add
> more)
 
Of
> Dear
> Suresh,
 
...FB: there's been several
> discussions at this past IETF on this
particular topic - and the approach
> which seems to have wide support is
that for Release 10, one would support a
> model where one PDN connection
would continue to be represented by a *single*
> prefix. This prefix could
be shorter that /64. This means that we can still
> hand out multiple
prefixes to the UE, but it would always be possible to
> aggregate all of
them into a single prefix. We'd continue using SLAAC for
> assigning the
/64 for the UE (or better PDN-Connection-link) and would hand
> out the
remainder of the "shorter prefix" using DHCP PD. This will keep
> changes
to the current architecture to a minimum (incl. PCC will need to
> deal
with only a single prefix in its rules). More complex alternatives
> would
 
I'm
> working on updating the contributions S2-101176, S2-101177,
S2-101178 that
> were submitted "for information" to the last 3GPP SA2
meeting to reflect these
> changes (which are only small deltas to the
current versions, so hope to have
> them available for discussion in the
next few days) (You can find the
> submitted version
> at
 
> to avoid address abusing?
 
...FB: The expected approach is that shorter
> prefixes would be handled
as a capability of the APN. This way you also won't
> have any issues with
"abuse" - each UE (for a particular APN supporting
> shorter prefixes)

you
> minimum
> length that a UE can apply, and assign the proper lengh to UE
> based on the
> available adrress pool, the minimum length the UE can
> apply, and the length
 
...FB: If we do things on a per APN basis (as
> mentioned above), one
would expect that only those UEs who need shorter
> prefixes would use the
particular APN, so the amount of "wasted" addresses
> would be relatively
small. That said, the approach would just be for Release
> 10 (we just
have two more meetings to get this off the ground) - more
> optimal
 
Regards, Frank
 
> potential solutions in a 3GPP document. What is your opinion to them?
___________________________________
> ____________
3gv6 mailing
> list
[email-masked]

---

From: [email-masked]
Date: Fri, 2 Apr 2010 10:44:50 +0800

Hi,
some comments inline.

[email-masked] 写于 2010-04-01 下午 11:26:23:

> Hi, Frank,
> 
> If the prefixes assigned to one PDN connection are aggregable, it is
> fine. The problem is we have to carefully deal with the possible 
> gaps that may be left after several times PDs.
XY: Yes, agree.
> 
> I don't think R11 needs more complex alternatives. If we can figure 
> a good solution for R10, R11 absolutely can use this solution if the
> requirement is not changed.
> 
XY: Yes. It is not practical that using different APN to represente 
different length prefix service. But defining a particular APN can be used 
to help UE to select the PDN which providing shorter prefix service or 
supporting DHCPv6 PD. Anyway, not every UE needs shorter prefix, neither 
of the P-GW.
Xingyue
ZTE Corporation