RE: GPRS Tunnel Protocol (GTP)

Hi,

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


I assume that you are talking about radio link, or in genera,  layer 2. Unlike
WLAN or Ethernet,  a session between the UE and the GGSN  in GPRS/UMTS needs to
be set up  before sending /receving IP packets including those packets carrying
the MIPv6  control messages. The radio link is set up as part of the session
establishment  and no packets can cross the link until the GPRS/UMTS session
terminated at the GGSN  is set up successfully.

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

Not sure what you mean by "static TFT". A UE creates a TFT when it requests to
set up a GPRS/UMTS session (with specific QoS and resource requirements) and the
TFT is associated with the session for GGSN to use to select the session for
incoming packets. Unless the UE could change the TFT dynamically, the TFT will
remain "static".

>the scenario you describe should never happen.

The scenario  I described is not about TFT but SBLP in IMS for a UE attached to
GPRS/UMTS having a authorised IMS session with a MIPv6 CN. Upon attached to the
GPRS/UMTS, UE can initiate an IMS session  which can only send packets to
authorised destinations ,i.e. to its MIPv6 CN. Unless the UE can set up a
separate session to HA for MIPv6 control messages, the binding update can not
pass  the SBLP control at the GGSN.

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

TFT does not contain QoS requirements but some IP layer, Transport Layer as well
as some security information etc.  The current session management in GPRS/UMTS
is independent of Mobile IP. As long as a session  is set up, apps can or should
be able to send/receive packets irrepective of the control in Mobile IP.  This
will stop being the case if Mobile IPv6 is activated by IPv6  end nodes
including IPv6 UE's  unless something is done.

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

This seems suggesting that the session management in GPRS/UMTS should be
combined with the MIPv6 based Mobility. And this is going to be hard because the
current  GPRS/UMTS session management is designed and used  independent of the
Mobile  IP.

> In short, make sure that
>if MIPv6 exists, the UE always allows traffic with the
>following filters:
>- src : CoA
>- dst: HA
>- Proto: Mobility header

This looks like making the filtering change with the movement  of the mobile
nodes when they start using  MIPv6.  But we have foreseen some serious impact on
the resources, especially over the air interfaces,  and the peformance for
GPRS/UMTS Session Management, Mobility Management and on the GGSN.

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

This seems to be suggesting the  wildcard filtering.  But this  can't be used in
many cases.

> Well, there is no seamless IP mobility issues for a UMTS
>UE!

I don't understand what you mean.  The term "seamless IP mobility" is not used
in UMTS but low  lowtency and low/no loss in  handover/mobility is an important
objective to achieve in UMTS.

> The UE will _never_ move.

The UE will move around ,intra-PLMN, Inter-PLMN and  between WLAN and UMTS at
least.


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.

We are considering this option and need to understand if it always works.

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

I disagree. Although the examples in the I-D are given specific to GPRS/UMTS,  I
don't think  these issues will only exist in GPRS/UMTS. And there have been some
quite extensive discussions about the similar issues in Firewalls/NAT.


Regards,

Xiaobao Chen



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