RE: GPRS Tunnel Protocol (GTP)

Hi,

Your comments are appreciated. My response is line line.

Regards,

Xiaobao

Orange PCS





Soliman Hesham <[email protected]> on 31/07/2003 05:12:01




To:   Xiaobao CHEN/EN/HTLUK@HTLUK
cc:   [email protected]
      [email protected]
      [email protected]
      [email protected]
      "'Ashish Sharma'" <[email protected]>
      "'Anurag Uxa'" <[email protected]>
      "'Amir Hermelin'" <[email protected]>
      [email protected]
      [email protected]
      Martin HARRIS/EN/HTLUK@HTLUK
      Nick SAMPSON/EN/HTLUK@HTLUK


Subject:  RE: [mobile-ip] GPRS Tunnel Protocol (GTP)




>>TFT operates separately from IMS SBLP.

>=> I realise that but I think you might end up with
similar problems in IMS.

>>So there are two obvious alternatives for solving this:
>>- Make the UE use the right address in the PDP context setup
>>for the TFT.

>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. For MIPv6 Route Optimisation, as an example, the
correspodent binding update coming from a mobile CN will use its CoA as the
Source Address once it is away from its Home Network and attached to foreign
network and the similar problem happens ....

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.

  And there are some other
>associated issues such as the existing standards may not allow the MT to
change
>the TFT for a 2ndary PDP Context, ....

>=> I can't parse the above. Existing standard do not
>stop you from extending the TFT for a secondary
>context. Especially if there is a clear problem like
>this. You might even want to push for it to be changed
>for previous releases on the grounds that MIPv6
>was also designed this way and people always knew
>that this will be a problem. In fact I remember coauthoring
>a contribution once on this years ago and it got no
>attention.

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.

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 ....

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  ? ....



>>In the first alternative, the MT's implementation could
>>snoop the PDP context activation messages and get the
>>IPv6 prefix that is allocated to the UE and replace the
>>HoA in any messages that are sent to set the TFT with the CoA.
>>However, this will clearly not work for the CN if it
>>were also mobile because the MT could not possibly
>>know what the CN's CoA would be.

>Correct. And for this to work, the MIPv6 control messages will have to pass
>through the GPRS/UMTS network in the first place.

>=> They do pass through the network. Note the word
>"snoop". It does not have to be addressed to the GGSN.

Maybe I missed your point. But the UE will have to let the GGSN know what TFT it
selects for which session/QoS. And once it is accepted and the session is set
up, the GGSN will use this TFT to select the right sesssion to  transmit an
incoming packet.

>- Add a "MIP flag" in the message that sets up the TFT
>(PDP context)and make the GGSN parse the packet to check for
>the real addresses.

>>The second bullet above would imply making the GGSN
>>aware of IPv6 headers and parse them to see if the
>>HoA is included in the HAO (for route opt) or inside
>>the tunnel (when the packets are forwarded by the HA).

>I am just wondering if this HAO or the packet information inside the tunnel
is
>always possible to check by the GGSN. What if E2E IPSec is applied ?... Any
>clarification would be appreciated.

=> 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.




Hesham


*******************************************************************************
Important.
Confidentiality: This communication is intended for the above-named person and
may be confidential and/or legally privileged. Any opinions expressed in this
communication are not necessarily those of the company. If it has come to you
in error you must take no action based on it, nor must you copy or show it to
anyone; please delete/destroy and inform the sender immediately.

Monitoring/Viruses
Orange may monitor all incoming and outgoing emails in line with current
legislation.  Although we have taken steps to ensure that this email and
attachments are free from any virus, we advise that in keeping with good
computing practice the recipient should ensure they are actually virus free.

Orange PCS Limited is a subsidiary of Orange SA and is registered in England No
2178917, with its address at St James Court, Great Park Road, Almondsbury Park,
Bradley Stoke, Bristol BS32 4QJ.
*******************************************************************************