RE: GPRS Tunnel Protocol (GTP)

Ed,

Thanks for your comments. Please find my response  in line.


>Unless I'm misreading this, it sounds like you are recommending that the
>issues that MIPv6 route optimization introduces to GPRS packet filtering
>(performed by gateway nodes, part of the GPRS infrastructure) should not
>be fixed on the GPRS gateway nodes, but instead should be fixed in all
>MIPv6 CNs


Maybe there are some misunderstandings.

1) The inter-working issues are not limited to  MIPv6 Route Optimisation only.
An MIPv6 CN will expererience similar problems to send packets across GPRS/UMTS
network  if HA Tunnelling is used.


2)  The I-D does not argue that  all  MIPv6 CN should be fixed  to support GPRS
packet filtering. It does NOT propose  that MIPv6 need "fixing", rather that
there are some interworking issues that need to be investigated and an optional
function proposed.

We did this because we believe that  most of us who are interested  in  or have
seen the value of MIPv6 would like to see  if there are any issues in its real
deployment, especially in one of the most important global 3G  wireless/mobile
systems.  So far, I have not heard any objections to those " problem
statements".

And I believe that  all of us would be happy to see that MIPv6 will eventually
inter-work with GPRS/UMTS without any problems.

>(i.e. all non-GPRS servers on the IPv6 Internet,
>MIPv6-capable, now forced to implement this brand new GPRS-specific
>Hop-by-Hop Options Header requirement solely to avoid needing to upgrade
> the GPRS gateway nodes).

The  I-D proposes  an optional  function for IPv6 nodes if they use MIPv6 so as
to avoid  some  interworking problems with GPRS/UMTS. This is included in the
I-D for open discussion. We believe that the expertise is in this group and the
viable solution(s) lie(s) in the hand of the group members that will help us
address this issue.

>IMO this is the wrong recommendation...

Thank you for pointing out something that may not  be appropriate. We will look
at the issue and make some changes.

>should fix this problem in the GPRS gateway nodes.

Thank  you  for proposing a solution which we had  considered very carefully
before we raised the issues to  group.This solution  would require some
fundamental changes to the current GPRS/UMTS deployments that are already in
operation or being rolled out. This could involve major cost and have
significant implications for networks.

Alternatively,changing GPRS/UMTS means  to change the GPRS/UMTS specs to
restrict the use of  some or all of MIPv6 functions in GPRS/UMTS IPv6 nodes. I
am sure very few people would like to see this practice.

Even if GPRS/UMTS could be changed to support MIPv6,  do you think that these
kind of " packet filtering" are only limited to GPRS/UMTS network ?


All in all, we would like  to raise the issues to the attention to the relevant
WG and work with the WG to work out the best solution; as such we would welcome
any proposals or collaborations in this area.


Regards,

Xiaobao Chen

Orange PCS

Email: [email protected]
Mobile: +44 (0) 7989 477 679







"Ed Remmell" <[email protected]> on 24/07/2003 18:09:38




To:   Xiaobao CHEN/EN/HTLUK@HTLUK
      "'Ashish Sharma'" <[email protected]>
cc:   "'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)



Xiaobao -

> 4) Mobile IPv6, however, is expected to have some impact on
> some  operations on GPRS/UMTS, especially on IPv6 (only) IMS.
> This is  because Mobile IPv6 runs on an end-to-end basis,
> i.e, an IPv6 GPRS/UMTS terminal can activate MIPv6 with its
> peers without the knowledge of the intermediate GPRS/UMTS
> systems. We have done some analysis. The details can be found
> in an I-D located at
> http://www.ietf.org/internet-drafts/draft-chen-mobileip-packet
> -fitlering-xc-01.txt
> .

>From this draft:

"4.1.2 The Case of Route Optimisation when the CN is mobile
...

   A typical example is the case when  the GSSN uses ingress
   filtering for selecting the UMTS sessions.Although the packet sent
   from the mobile CN to the MN has the  "Home Address Destination
   Option" containing its Home  address[1], a gateway node as
   an intermediate node operating standard IPv6 does not read it.
   This will have some serious implications such as the disruption of
   existing live sessions."

"5. Requirements on Inter-working Mobile IPv6 with Packet Filtering

   The following requirements are recommended for a gateway node that
   performs source address and/or destination address based packet
   filtering:

   * A gateway node running standard IPv6 should not be required to
     change to support packet filtering function.

   * The policy control functions for packet filtering such as the PCF
     should not be aware of the mobility control based on mobile IP."

"6.1.2 The Recommended Practice in case of Route Optimisation

   For a CN communicating to a MN using route optimisation
   to send packets directly to the MN, the CN should insert its IP
   address in the Hop-by-Hop Options Header. In the case where the CN
   is a mobile itself and away from its network, the CN should insert
   its Home IP address in the Options filed in the Hop-by-Hop Options
   Header."

Unless I'm misreading this, it sounds like you are recommending that the
issues that MIPv6 route optimization introduces to GPRS packet filtering
(performed by gateway nodes, part of the GPRS infrastructure) should not
be fixed on the GPRS gateway nodes, but instead should be fixed in all
MIPv6 CNs (i.e. all non-GPRS servers on the IPv6 Internet,
MIPv6-capable, now forced to implement this brand new GPRS-specific
Hop-by-Hop Options Header requirement solely to avoid needing to upgrade
the GPRS gateway nodes). IMO this is the wrong recommendation... you
should fix this problem in the GPRS gateway nodes.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.497 / Virus Database: 296 - Release Date: 7/4/2003


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