RE: GPRS Tunnel Protocol (GTP)

Hi,

Thanks for your comments. My response  to your comments is in line.

>The problem you're trying to solve is essentially
>that the "application" sets the filter on a default
>router. You are essentially saying that the application
>only sees a home address and the default router only
>sees the CoA therefore the filter (TFT) will never
>match the incoming/outgoing traffic. I'm not going
>through the Go interface just the basic problem in
>the absence of IMS.


TFT operates separately from IMS SBLP.  TFT is  generated by the UE while the
SBLP information is generated by application layer.  I am happy to provide more
clarifications if needed.


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


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

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


>IP networks are not generally designed in the way that
>the GPRS core network is designed. I.e. An access router
>is expected to serve a small number of customers. Therefore,
>you can afford to have complex filters in it.


The load condition at the GGSN can become  an important  issue. And this should
be  considered when we look at various options. Again thanks for suggesting the
options.


Regards,

Xiaobao Chen

Orange PCS








Soliman Hesham <[email protected]> on 29/07/2003 07:25:27




To:   Xiaobao CHEN/EN/HTLUK@HTLUK
      Ed Remmell <[email protected]>
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)



Hi,

The problem you're trying to solve is essentially
that the "application" sets the filter on a default
router. You are essentially saying that the application
only sees a home address and the default router only
sees the CoA therefore the filter (TFT) will never
match the incoming/outgoing traffic. I'm not going
through the Go interface just the basic problem in
the absence of 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.
- 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.

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.

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 guess the immediate answer to the second solution is
"this will increase the load on the GGSN". That's true,
but increasing the load is not a general issue for any access
router today, because none of them are _designed_ to handle
an entire city. So, if you think that this will reduce the
performance in the GGSN then I'd say use more GGSNs and make
them have a smaller coverage area.

IP networks are not generally designed in the way that
the GPRS core network is designed. I.e. An access router
is expected to serve a small number of customers. Therefore,
you can afford to have complex filters in it.

Hope this helps,
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.
*******************************************************************************