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

From: "Amir Hermelin" <[email-masked]>
Date: Wed, 23 Jul 2003 12:57:56 +0300

Hi,
can anyone point me to the GPRS tunnel protocol (GTP) spec?
Thanks.

---

From: [email-masked]
Date: Wed, 23 Jul 2003 11:14:25 +0100

http://www.3gpp.org/ftp/Specs/2003-06/Rel-5/29_series/TS29.060 for Release 5.

Xiaobao

"Amir Hermelin" <[email-masked]> on 23/07/2003 10:57:56

To:   [email-masked]
cc:    (bcc: Xiaobao CHEN/EN/HTLUK)

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

Hi,

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

---

From: Soliman Hesham <[email-masked]>
Date: Tue, 29 Jul 2003 02:25:27 -0400

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

---

From: [email-masked]
Date: Wed, 30 Jul 2003 12:00:29 +0100

Hi,

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

>through the Go interface just the basic problem in

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.

>- Make the UE use the right address in the PDP context setup

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

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

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

>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-masked]> on 29/07/2003 07:25:27

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

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

Hi,

Hope this helps,
Hesham

Monitoring/Viruses

---

From: Soliman Hesham <[email-masked]>
Date: Thu, 31 Jul 2003 00:12:01 -0400

>TFT operates separately from IMS SBLP.  

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

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

  And there are some other
>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.

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

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

Hesham

---

From: Soliman Hesham <[email-masked]>
Date: Thu, 31 Jul 2003 00:41:14 -0400

> there is no HAO, but the TFT includes the SPD
                                             ^^^
=> Obviously a typo, I meant SPI.

Hesham