RE: GPRS Tunnel Protocol (GTP)

Hi,

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

Not sure what you mean by "mobility header". I assume that you are talking abou
the MIPv6 extension headers. If I have not missed anything from our previous
discussion, these "mobility headers" are not always readable to GGSN.

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

Do you mean that GGSN should maintain a static config. ( e.g. a PDP Context) to
allow for MIPv6 messages to pass through without filtering  ? If yes,

     1) How would the MN know when it should open  a UMTS session with reserved
resources for the MIPv6 signalling messages ?
  I am not sure if it is a good practice to keep a session open all the time in
case there are MIPv6 messages coming in or going out.

     2) Even if there is a session for MIPv6 signalling, the GGSN would have to
see if it is a legitimate MIPv6 signalling message or something else which
should not be delivered anyway ? How would the GGSN know this ?

     3) Even if the MIPv6 control messages manage to pass around between the UE
and the GGSN, the data packets would have to go through the TFT based session
selection process. To do so, the GGSN will keep what you call a MIP flag per
session per UE in downlink direction  and udpate the TFT each time the MN's
moves around from one CoA to another. If the SBLP is taken into account,  GGSN
would have to set up and maintain this per session MIP flag and maintain MIPv6
status update for the uplink direction each time the MN moves.


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

If it does not use a separate session, which session is used to pass the MIPv6
signalling then ?  If it uses the session set up for the data packets, it will
experience the same problem.


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

This has surely been considered and discussed.  But it has been realised that
this means a tremendous cost and extra complexity  to our systems unless the
3GPP specs are changed in a way to limit the use of MIPv6 partly or completely.
I am sure very few people including those who have been working hard on MIPv6
would like to see this practice.

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

Even though UE's  in our network may not have "IP mobility", they may well talk
to UE's that are using MIPv6 mobility or IPv6 nodes that only use MIPv6 for
mobility control.  And there will be some  problems.

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

 Filtering based on "wildcard" will not enable the GGSN to select the individual
sessions with different QoS/resource configurations.

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

So you are talking about setting up a special sesssion to pass the siganlling
message, and to do so, the GGSN will have to parse the mobility headers.  There
are some costly and very complicated implications to the 3G systems especailly
to the air interface and the GGSN as I explained before.

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

Surely, this is one of the solutions that we are looking at but  I am not sure
this internal packet inspection for the mobility header information is always
possible especially when end-to-end IPSec is used.  There may well be a simpler
and better solution that does not  incure too much change and little cost and
little extra complexity to the existing design and deployment practice  of 3G
systems  that have been widely going on today. And I believe that MIPv6 WG is
the right group to help  find the solution(s). In the meantime, we also believe
that it is to the benefit to the work to be aware of some pracitcal deployment
issues of MIPv6 in real life networks.


Xiaobao





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