RE: GPRS Tunnel Protocol (GTP)

 > Not sure what you mean by "mobility header". 

=> The Mobility Header is an extension header that
carries MIPv6 signalling as defined in the MIPv6 spec.

 > >That is, a static config for all
 > >nodes, independently of the content of their
 > >secondary PDP context. Unless a UE specifically
 > >removes this for its TFT (can't imagine why)
 > >then this is the default. It's a requirement
 > >on GGSN, there is no magic or protocol changes here.
 > 
 > Do you mean that GGSN should maintain a static config. ( 
 > e.g. a PDP Context) to
 > allow for MIPv6 messages to pass through without filtering  ? If yes,

=> Yes.

 > 
 >      1) How would the MN know when it should open  a UMTS 
 > session with reserved
 > resources for the MIPv6 signalling messages ?

=> Like I said before, you only need that if you require
special air interface configuration for MIPv6 signalling.
Since MIPv6 is not used within the UMTS network, I don't
think this is necessary. If a UE has a MIPv6 implementation
it will rarely send a BU to the HA and it might send one 
every 7 minutes to a CN. Do you want a special RAB for that?
If you do it's obviously more work in 3GPP. I was trying to
give a simple and less efficient solution. If you want a more
optimal one you'll have to make more modification to 3GPP
specs.

 >   I am not sure if it is a good practice to keep a session 
 > open all the time in
 > case there are MIPv6 messages coming in or going out.

=> Neither am I that's why I didn't suggest this. 
What I suggested means that every TFT has what 
you called "wild card" filter in it by default even
if the UE doesn't ask for it. If the UE overwrites it
then its the UE's responsibility.

 >      2) Even if there is a session for MIPv6 signalling, the 
 > GGSN would have to
 > see if it is a legitimate MIPv6 signalling message or 
 > something else which
 > should not be delivered anyway ? How would the GGSN know this ?

=> Don't know what you mean. MIPv6 signalling messages are
clearly specified and the current spec does not allow piggybacking
of other data on them.

 >      3) Even if the MIPv6 control messages manage to pass 
 > around between the UE
 > and the GGSN, the data packets would have to go through the 
 > TFT based session
 > selection process. To do so, the GGSN will keep what you 
 > call a MIP flag per
 > session per UE in downlink direction  and udpate the TFT 
 > each time the MN's
 > moves around from one CoA to another. 

=> Yes.

   If the SBLP is taken 
 > into account,  GGSN
 > would have to set up and maintain this per session MIP flag 
 > and maintain MIPv6
 > status update for the uplink direction each time the MN moves.

=> I hope that by MN you are referring to the CN not the UE because
obviously the UE doesn't move. If you are referring to a CN
then yes the above is correct. But of course any of these 
problems is only relevant when you use route optimisation.

 > >=> I tried to explain to you what could be done in
 > >previous messages. It needs to be solved in 3GPP specs.
 > 
 > This has surely been considered and discussed.  But it has 
 > been realised that
 > this means a tremendous cost and extra complexity  to our 
 > systems unless the
 > 3GPP specs are changed in a way to limit the use of MIPv6 
 > partly or completely.

=> The cost is only a result of the core network design.
Normally, filtering in the access router is not as costly
when it serves a small number of nodes. So that's why this 
is a special case.

 > 
 >  Filtering based on "wildcard" will not enable the GGSN to 
 > select the individual
 > sessions with different QoS/resource configurations.

=> Why not? it's a default filter that is unilaterally added
by the GGSN in addition to whatever the UE requests. What's
the problem?

 > So you are talking about setting up a special sesssion to 
 > pass the siganlling
 > message, and to do so, the GGSN will have to parse the 
 > mobility headers.  There
 > are some costly and very complicated implications to the 3G 
 > systems especailly
 > to the air interface and the GGSN as I explained before.

=> See answers above and previous mails about why this is 
not a big issue for access routers serving a small number of nodes.

 > 
 > >- For media, you will need to look inside the tunnel,
 > >if it comes from the HA, or look for the HAO for route
 > >optimised packets. The decision of whether the GGSN should
 > >inspect the packet in this special way should be based
 > >on PDP context signalling extensions in the UE and GTP-C.
 > 
 > Surely, this is one of the solutions that we are looking at 
 > but  I am not sure
 > this internal packet inspection for the mobility header 
 > information is always
 > possible especially when end-to-end IPSec is used.  

=> We're going in circles here. We already discussed this
and I suggested that the SPI or flow label can be used. 

   There 
 > may well be a simpler
 > and better solution that does not  incure too much change 
 > and little cost and
 > little extra complexity to the existing design and 
 > deployment practice  of 3G
 > systems  that have been widely going on today. 

=> A Hop-by-Hop option is not an option (pardon the pun).
If there is another feasible option please suggest it.

   And I believe 
 > that MIPv6 WG is
 > the right group to help  find the solution(s). 

=> Well, here we are :) 

Hesham