RE: GPRS Tunnel Protocol (GTP)

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

=> I understand how it works. My point is that the
MN will _not_ send the first BU until the link
is up. Now if you always allow the GGSN to pass
an packet containing a mobility header (from any
IP address to any other IP address) then there 
is no "blocking of BU" problem. This is what I mean
by static TFT. That is, a static config for all
nodes, independently of the content of their
secondary PDP context. Unless a UE specifically
removes this for its TFT (can't imagine why)
then this is the default. It's a requirement 
on GGSN, there is no magic or protocol changes here.

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

=> I hope the above makes it clear.

 > The scenario  I described is not about TFT but SBLP in IMS 
 > for a UE attached to

=> I thought you didn't want to discuss SBLP in a previous
mail. Anyway, see below.

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

=> It does _not_ need a separate session for MIPv6
signalling, but of course you can do that. The only reason
for having a separate session would be if you require
a different radio config for the signalling. If you don't
need special treatment over the air then you should just
allow all packets with a mobility header to pass.

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

=> I tried to explain to you what could be done in 
previous messages. It needs to be solved in 3GPP specs.

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

=> Don't know how you read that. I'll summarise my 
suggestions at the end.

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

=> No, it's a context update initiated by MIPv6
(acting as an application).

  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.

=> I know! This is what I said a couple of emails ago
and it's a direct consequence of having an access 
router that manages a VERY large number of users. This
is specific to the GGSN. Normally access routers don't
manage this large number of devices.

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

=> Like what? do you have an example?

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

=> Physical movement is not relevant, it's IP movement
that we care about. IP movement will only happen between
WLAN and UMTS, this will cost one BU to the HA. 

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

=> Yes and we solved the FW problem (not sure what NAT problem
you refer to in IPv6) by having a mobility header and 
strict rules for routing header use and HAO. Basically, 
with any FW you can have the "wildcard" configuration
that I explained above and it works. This is the 
expectation from MIPv6 because it's authenticated 
end-to-end. 

So the summary:

- For signalling messages, allow all packets containing
mobility header to pass through regardless of the 
source and destination addresses. Of course this does not
preclude ingress filtering. I'm only including the src address
in the above statement to allow inbound traffic.

- For media, you will need to look inside the tunnel, 
if it comes from the HA, or look for the HAO for route
optimised packets. The decision of whether the GGSN should
inspect the packet in this special way should be based
on PDP context signalling extensions in the UE and GTP-C. 

Hesham



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