RE: GPRS Tunnel Protocol (GTP)

>Things are not that simple.  The UE (  or specifically the MT)  will only
know
>when  and how to  update the TFT when the MIPv6 function (speficially, the
>binding update process is successful) is activated. And the MIPv6 control
>messages may not be able to get through to the  UE  because the control
messages
>may get blocked by the GGSN in the first place.

>=> why would the GGSN would block that? I can't think of
a good reason.

>The Binding Update will experience the same problem  with that for the data
>packets; the assumption is that the mobile ip control messages will use
the
>same GPRS/UMTS session for data packets.  When the Binding Update message
>arrives at the GGSN, the GGSN will need to select the appropriate GPRS/UMTS
>session with the right QoS. 

=> I disagree with this sequence of events. As soon as the link
is up, a MN would send the BU to its HA (after receiving
the RA). So, unless you have a "static" TFT (i.e.
the TFT is setup irrespective of the application running)
the scenario you describe should never happen. The QoS requirements
in the TFT come from apps. The BU to the HA is sent before
any apps have started so I fail to see how the BU would
not be allowed unless your default is not to allow
anything and this should not be the case.


>Similarly for SBLP in IMS,  a Binding Update message to HA may fail to pass
the
>GGSN filtering because the authorised destination address is not the HA's
>address.

=> Well, not for the first BU. For the second BU to the HA
(refreshing) this might be the case. But the UE will need to
ensure that the secondary PDP context allows BUs to the HA.
I don't understand the problem. In short, make sure that 
if MIPv6 exists, the UE always allows traffic with the 
following filters:
- src : CoA
- dst: HA
- Proto: Mobility header


>I remember that similar attempts were made for different reasons;  With
regard
>to changing TFT/2nd PDP Context for supporting MIPv6, this means that each
time
>mobile node moves at  either end and starts using MIPv6,  then there would
be
>some extra messages back and forth across the  expensive air interface and
the
>GGSN would have to remember the states related to MIPv6 related states as
well
>as those for  GPRS/UMTS session management  plus those for QoS .... a for
each
>UE for both uplink and downlink directions. Not sure how practical this
solution
>is.

=> Not sure how practical the limitation is :)
If you don't like this then always allow IP packets
as follows:
- Src: any
- dst: any
- Proto: Mobility header
This means that you will always allow MIPv6 signalling
independently of the sender or the receiver.

>Even if TFT in 2ndary PDP Context could be changed, the UE would only know
how
>to change the TFT only when the Binding Update is successful. But the
Binding
>update messages would only be able to pass the GGSN when the TFT or SBLP
>information is updated.  But without the binding update, the UE does not
know
>how to change the TFT ....

=> See above. Once the signalling is through the UE can
update the filter. So your safest bet is to always allow
proto = mobility header to get through. This solves the
signalling part. To solve the QoS filtering for data 
then you can use one of the solutions discussed earlier.

>In addition, the SBLP authorisation information comes from the Application
>Layer, changing the SBLP means that the session will need to be
re-authorised by
>the Application Layer (PCF/P-CSCF). Do you think that this is practical
each
>time Mobile IPv6 is activated by the IPv6 nodes ? Would the so-called
"seamless
>mobility "  be possible  by adopting this solution  ? ....

=> Well, there is no seamless IP mobility issues for a UMTS
UE! The UE will _never_ move. So I assume you are referring
to the peer's mobility. As I said in previous emails, you
can always filter on the HAO if RO is used. If packets
are delivered by the HA, then you can look inside the 
tunnel. 


=> Two comments:
>- When communicating with a CN and IPsec is used
>the HAO will be visible.
>- When IPsec only covers the HA-MN path then
>there is no HAO, but the TFT includes the SPD
>and the flow label so you can filter on either
>one of those, with the src and dst addresses.

>I am not sure if  I understand what you mean. As you are aware, not all
three
>options of TFT combinations  include SPI but the Source Address is included
in
>all three options.  If the Source Address does not match whichever optional
>combination of TFT is used, there will be some problems as described in the
I-D.

=> But this is clearly a TFT issue that needs to be solved
on that end not in IETF. You have everything you need to
know inside the packet. If the TFT option chosen does not
include some of these parameters then that's the TFT's
problem. This is not specific to MIPv6, this will affect
any IPsec-protected traffic. 

Hesham