RE: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE]

[<Jonne.Soininen@nokia.com>]

Hi Pekka,

> Certainly.  But this is no problem.  You can get that information
> using some means, e.g. SNMP.  I don't know which kind of interfaces
> 3GPP boxes have, and which kind management systems they connect to,
> but I'm pretty sure there can be ways to extract that information.

But this is a problem. The new solution has to be specified and implemented. This is not a trivial process. The boxes (and most probably are) of different vendors and implementing something like this and integrating it to the current networks is not a trivial task. 
So, theoretically everything is possible but practically this is not an option. Automatic tunneling would be much better fit in this case.

> 
> >  > if for no other reason, but because it's tunneled back from the 
> >  > foreign network.  
> > 
> > => I don't get this.
> 
> I mean, I understand foreign 3GPP operators use something 
> like L2TP to 
> transport the IPv4 packets back to the home operator, correct?  

Not quite. The mobility management and roaming are based on GPRS Tunneling Protocol. It works a bit different than how I would assume roaming works in the fixed network.
> The 
> home operator has to have some kind of policy to who will be allowed 
> in its network, i.e., when decapsulating the L2TP stream from the 
> foreign operator, the 3GPP operator should check the source addresses 
> of the packets (or at least do something to check that the 
> packets are 
> valid, for billing etc. reasons if for nothing else).

The policy is enforsed at the PDP Context activation time and GPRS attach time point. If the GGSN is at the home network (even when the user is roaming) the IP address is allocated from the home GGSN. Thus, if the PDP Context could be activated it means that the user has the right to use the IP services of that GGSN and the network where the GGSN is. There is a short summary how GPRS works at RFC3314.


> On the contrary, there is no reason to bless a solution (and impose
> the burden of the solution on everyone eelse) that some have chosen
> because they didn't think of alternative ways to achieve the result.
> 
> > => We can't assume that it is not well understood
> > because one person made a mistake.
> 
> I can read myself, and I can say for sure that it isn't well 
> understood. :-)
> 
> > It is implemented
> > on 4 different products that I know of (2 host platforms
> > and two router platforms) and are all interoperable. 
> 
> Implementatable & interoperable is VERY FAR from being well
> understood.

We have to look at this. However, I have come to the same conclusion about the implementation status of ISATAP. Maybe some vendors that have implemented ISATAP could indicate which version of the ISATAP they are shipping.

Cheers,

Jonne.