Re: [v6ops] draft-ietf-v6ops-ipv6-roaming-analysis WGLC

2014-07-30 15:27 GMT+08:00, Ross Chandler <ross@eircom.net>:
>
> On 15 Jul 2014, at 06:16, gangchen <phdgang@gmail.com> wrote:
>
> Gang,
>
> Wording tweak below.  I hope haven’t altered the meaning.
>
> Section 6. HLR/HSS User Profile Recommendation
>
> A proper user profile configuration should provide deterministic network
> control of the connectivity that can be set-up from the device:
> IPv4-only, IPv6-only, dual-stack using separate bearers, or dual-stack
> using a single beaerer. The HLR/HSS may have to apply extra logic
> to achieve this.

IMHO, we may have to avoid dual-stack using separate bearers. So I
make a minor revision on the texts as below.

A proper user profile configuration could provide deterministic
network control of
the connectivity requests from dual-stack, IPv4-only and IPv6-only
devices. It's desirable
that the network could set-up proper connectivity for any type of the
devices.The HLR/HSS may have to apply extra logic to achieve this.

The following are examples to demonstrate the settings for the scenarios
and decision criteria to apply when returning user profile information to
the SGSN.

BRs

Gang

> It may be expected that the device could attempt to set-up connectivity by
> any
> of the above means.
>
> The following are examples to demonstrate the settings for the scenarios
> and decision criteria to apply when returning user profile information to
> the SGSN.
>
> Ross
>
>
>> One section will be added according to the discussion. The following is
>> proposed text.
>> Please kindly check.
>>
>>
>>
>> Section 6. HLR/HSS User Profile Recommendation
>>
>>
>>
>> A proper user profile configuration should provide devices with good
>>
>> tolerance to various scenarios. The following are examples to demonstrate
>>
>> the setting.
>>
>>
>>
>> Scenario 1: Support IPv6-only, IPv4-only and dual-stack devices
>>
>>
>>
>> user profile #1:
>>
>>
>>
>>   PDP-Context ::= SEQUENCE {
>>
>>          pdp-ContextId ContextId,
>>
>>          pdp-Type           PDP-Type-IPv4
>>
>>   ....
>>
>>          ext-pdp-Type    Ext-PDP-Type
>>
>>   ...
>>
>>          }
>>
>>
>>
>>
>>
>> user profile #2:
>>
>>
>>
>>   PDP-Context ::= SEQUENCE {
>>
>>          pdp-ContextId ContextId,
>>
>>          pdp-Type           PDP-Type-IPv6
>>
>>   ....
>>
>>          }
>>
>>
>>
>> Note: the full PDP-context list is referred to section 17.7.1 "Mobile
>> Service date types" of TS29.002. User profile 1 and 2 share the same
>> contextId.
>>
>>
>>
>> Scenario 2: Support dual-stack devices with pre-R9 vSGSN access
>>
>>
>>
>> user profile #1:
>>
>>
>>
>>   PDP-Context ::= SEQUENCE {
>>
>>          pdp-ContextId ContextId,
>>
>>          pdp-Type           PDP-Type-IPv4
>>
>>   ....
>>
>>          ext-pdp-Type    Ext-PDP-Type
>>
>>   ...
>>
>>          }
>>
>>
>>
>>
>>
>> user profile #2:
>>
>>
>>
>>   PDP-Context ::= SEQUENCE {
>>
>>          pdp-ContextId ContextId,
>>
>>          pdp-Type           PDP-Type-IPv4
>>
>>   ....
>>
>>          }
>>
>>
>>
>> Note: User profile 1 and 2 share the same contextId.
>>
>> HLR/HSS is able to identify pre-R9 vSGSN and only send user profile#2 to
>> vSGSN.
>>
>>
>> BRs
>>
>> Gang
>>
>> On 07/29/2014 03:14 PM, Ross Chandler wrote:
>>>
>>> On 29 Jul 2014, at 06:10, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
>>>
>>>> On Tue, 29 Jul 2014, GangChen wrote:
>>>>
>>>>> Only the value IPv4v6 is allowed for ext_pdp. If HLR doesn't support
>>>>> IPv4v6 setting(that is the most case pre-R9), in other words, it can't
>>>>> set ext_pdp. It may not able to support all cases.
>>>>
>>>> Then I guess it's a matter of implementation. The HLR I was exposed to,
>>>> did for 2G/3G show to the user that IPv4 could have ext_pdp_type IPv6,
>>>> and this enabled IPv4 and IPv4v6 to work with this setting. If UE asked
>>>> for IPv6 only PDP context that didn’t work, so we had to add a profile
>>>> that said "IPv6" without ext_pdp_context_type.
>>>
>>> We have to define two allowed PDP Types for the same APN, so that legacy
>>> IPv4 PDPs and IPv6 PDPs for 464xlat can both be requested for the same
>>> APN.
>>>
>>> e.g.
>>>
>>> <hgppp:pdpcp=240;
>>> HLR PACKET DATA PROTOCOL CONTEXT PROFILE DATA
>>> PDPCP  APNID  EQOSID  VPAA  PDPCH    PDPTY  PDPID EPDPIND
>>> 240       80     1    NO             IPV4   25    NO
>>>           76     1    NO             IPV4   26    NO
>>>           74     1    NO             IPV4   31    NO
>>>           73     1    NO             IPV4   32    NO  <-- testdata APN V4
>>>
>>>           73     1    NO             IPV6   50    NO  <-- testdata APN
>>> V6
>>>
>>> If the Android UE APN Protocol is set to “IPv4/IPv6” with this it sets up
>>> parallel bearers to the GGSN/PGW.
>>>
>>> I agree with Mikael that it might be worth having a section noting this
>>> behaviour. An operator doing 464xlat could have UEs connecting with
>>> dual-stack done over separate bearers when they’d prefer it to either be
>>> single bearer with legacy IPv4 or         IPv6 with 464xlat.  This
>>> applies in the home and roaming case.
>>>
>>> Ross
>>>
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>
>