Subject: RE: FW: [mobile-ip] Ext. for FMIPv6 - comments

From: Gopal Dommety <[email-masked]>
Date: Thu, 05 Jul 2001 09:48:53 -0700

Mayank,

What you are suggesting is a technique called Chaining (where in as you 
move create a tunnel between the old AR and new AR).
Chaining and Anchoring are two possible techniques. Typically in a 
connectionless environment Anchoring tends to do well for the following 
reasons:

1. The latency involved in the message transfer between the new and the 
anchor is comparable to that of message transfer between the oldAR and the 
new AR (in connection oriented networks it involves redoing the circuits, 
therefore chaining could do better).

2. The performance of ARs might be impacted in chaining as the path has a 
higher degree of suboptimaility compared to that of anchoring (each AR on 
the path has to de-cap a packet and then encap it again)

3. It introduces additional single points of failure (i.e, the ARs in 
between the Anchor AR and the New AR).

4. since different ARs could potentially have different timers for the 
tunnel, it complicates the problem (obvioiusly this can be solved).

5. Routing loop detection could be tricky (this again can be solved).

Thanks
Gopal

At 04:18 PM 7/3/2001 -0700, Mayank Chaudhary wrote:
>jak> With regard to relay tunnels, the problem with relay tunnels is
>that
>they can lead to routing loops. Suppose MN  moves from aAR
>to AR1 to AR2 ... to ARn then back to aAR again. There would
>need to be some kind of protocol to detect and break the loop.
>If the wireless end of the BET gets moved every time the
>MN moves, there is no need for such a protocol.
>
>mayank> true. but this can be easily avoided by maintaining some state
>information is each AR that is part of the relay(such as IP addresses
>for ARs that are already part of this session). current signalling
>networks like SS7 already use this technique so i'm sure that we can
>borrow from those solutions. besides the advantages outweigh the
>additional overhead of loop detection :)
>
>So in such an architecture -
>1) a relay tunnel is setup between the oAR and the nAR. Since no
>HRqst/Hrply messages need to be exchanged between aAR and nAR this
>allows for quick setup of the BET. also this has additional advantages
>of reducing the buffering in the network(no bicasting required) that
>must ensure when the oAR starts bicasting before BET setup in the
>current proposal
>2) the relay tunnel can be maintained as long as the network determines
>that ping-pong of the MN is likely between the oAR and nAR
>3) additionally the network can intitate Path Minimization at any time
>to reduce additional hops. this is done by creating a BET between the
>aAR and nAR and tearing down any relay tunnels that may exist
>
>now for the advantages -
>1) reduced signalling during tunnel setup because no messages need be
>exchanged between nAR and aAR reducing setup times and buffering load in
>the network
>2) bicasting is not required. the aAR continues to send data to the oAR
>as usual. buffering needs to be performed at the oAR if the oAR-nAR
>relay tunnel is not up, but then you cant avoid that in the current
>proposal either :(
>3) path minimization can be performed during periods of inactivity in
>the session(how does one determine this ?) thus avoiding interruptions
>in real-time traffic
>
>
>what do you think ?
>-mayank
>
>                  >-----Original Message-----
> >From: Mayank Chaudhary
> >Sent: Tuesday, July 03, 2001 1:08 PM
> >To: [email-masked]';
> >Subject: FW: [mobile-ip] Ext. for FMIPv6 - comments
> >
> >
> >I wanted to point out a couple of mistakes in the draft
> >
> >1) Section 3.3. , page 17, item 4) states
> >"A BET is placed between oAR and nAR". I think you meant
> >"A BET is placed between aAR and nAR"
> >
> >2) In the timing diagram for Three Party Source Trigger Handover
> >an HTT Request should be followed by an HTT Reply from the nAR to the
> >oAR.
> >This is not really a mistake (as i initially thought) but will make the
> >timing
> >diagram much clearer
> >
> >as i understand there is never a relay tunnel established between oAR
> >and nAR
> >in BETH . instead tunnels are always anchored at aAR. if this is true,
>i
> >will propose
> >an architecture where relay tunnels can be established to the authors
>of
> >the draft(much like in SS7 networks), with the advantages of that
> >architecture. If i am wrong about this
> >then i'll take it as premature enthusiasm :-)
> >
> >Mayank Chaudhary
> >Seven Networks

---

From: [email-masked]
Date: Mon, 9 Jul 2001 10:04:43 +0300

Hi Behcet,
 
  Here is an excerpt from 
draft-manyfolks-ipv6-cellular-host-00.txt: 
Within the current 3GPP architecture, a cellular host will always 
   keep the connection to the same GGSN (default router) for a context. 
   Movement between default routers is not permitted. The only scenario 
   where a MN would change default routers is in the case of a handover 
   between two different access technologies. In this case the MN will 
   be simultaneously connected to both routers which would eliminate 
   the need for anticipation through the current router. Hence the Fast 
   Handoffs draft will not be required within the current 3GPP 
   architecture. 

[<JAL> ] While I'm not George, and I'm not entirely sure what email you 
are responding to (clipping part of the previous email is always helpful to
relate context to), but as an author of the
"draft-manyfolks-ipv6-cellular-host-00.txt"
draft let me say a word or two.
 
Since 3GPP started from a non-Internet point (3GPP's archictecture
is more-or-less an evolution of the circuit-switch GSM architecture), 
mobility for voice & data are handled by layer-2 mobility.  This is the
current architecture.  As it evolves, I don't think we can completely
discount the adoption of MIP or FMIP.  Additionally, 3GPP does not
specify interworking between different technologies such as WCDMA,
WLAN, Bluetooth, etc.  I'm sure some clever folks could find a way
to make handovers between these technologies.
 
Our document is not to discount MIP, but to be realistic for those
folks looking at making devices.
 
I think both FMIPv6 and the BETH extensions are very important documents,
and I think they will enable folks to construct devices that work well with
MIP.
 
best regards,
John

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 9 Jul 2001 05:59:43 -0400

Hi Bechet/John,

I am not sure I can read Bechet's sentiment...

I certainly agree that 3GPP (today in all visible releases) does not have
much use for fast MIP handoffs... I am, however, aware that 3G bodies (not
only 3GPP) are looking at MIP and would like to get more IP in their
architecture, although I am not sure how far they can really go and what
good will that do...but that is another story...My point with the
manyfolks-ipv6-cellular-host draft was that it should state that these are
guidelines to 3G host implementers...rather than general internet hosts (ot
even mobile hosts)

Now I am not sure if this has anything to do with the BETH extensions, which
to my understanding attempt to be applicable to IP networks in general...not
3G in particular...thank god there is life beyond 3G!

George

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, July 09, 2001 8:05 AM
To: [email-masked]
Subject: RE: [mobile-ip] Ext. for FMIPv6 - comments

Hi Behcet,
 
  Here is an excerpt from 

 

best regards,
John

---

From: James Kempf <[email-masked]>
Date: Mon, 9 Jul 2001 09:31:50 -0700 (PDT)

George/Bechet/John,

With regard to BETH, actually, it would be possible for a MN to do
exactly what the manyfolks-ipv6-cellular-host drafts says about
keeping the same router as it moved until the MN shut off, but that
is not the intent of the BETH draft. The intent is to provide
a zero L3 latency alternative to the techniques outlined in the
current FMIPv6 draft as a complementary solution for cases where
wireless bandwidth is low. The BETH draft states that the MN should
use FMIPv6 or the original Johnson and Perkins algorithm to obtain
a new CoA as soon as its traffic profile allows it. This would work
for either current 3G devices (which don't have particularly high
bandwidth as compared with, say, WLAN) or for new, low bandwidth
devices.

With  regard to GPRS in general, while there has been a considerable
amount of controversy in the MIP group about GPRS and there is
a certain amount of antagonism on both sides over the issue, 
I certainly welcome the manyfolks-ipv6-cellular-host draft *if* it
provides guidance about how to get MIP available in UTRAN systems
for inter-domain handover (I have not had an opportunity to read
the draft yet). The details of this have not been well worked out,
to my knowledge. I have been told that there is an alternative inter-domain 
handover technology called GPRX that involves tunnelling GPRS over the Internet. 
This is supposedly used by some GSM operators, and some are pushing to extend it 
to UTRAN. I sent out email on this awhile back. IMHO, having this technology 
spread to UTRAN is a really bad idea, because it will make handover between 
domains that choose to use MIP and those that use GPRS impossible, regardless of 
the radio technology.

Over the longer term, I think it would make sense for IETF to look
at ways to get MIP and GPRS to interoperate better, just as was
done in the late 80's and early 90's with NETBIOS and IP. If 3G takes off
(a big "if" at this point), there will be alot of GPRS nodes out there, so it 
would be in the interests of interoperability and the Internet to make
this happen.

		jak

>From: George Tsirtsis <[email-masked]>
>To: "[email-masked]'" <[email-masked]>
>Date: Mon, 9 Jul 2001 05:59:43 -0400 
>
>Hi Bechet/John,
>

---

From: [email-masked]
Date: Tue, 10 Jul 2001 10:03:58 +0300

Hi James,

> to my knowledge. 

The draft doesn't seek to provide any network functions - it attempts
to outline a list of requirements for a cellular host (i.e. - a
terminal with IPv6 that connects to the internet through a  cellular
network).  

> I have been told that there is an 
> alternative inter-domain handover technology called GPRX that involves 
> tunnelling GPRS over the Internet. This is supposedly used by some GSM 
> operators, and some are pushing to extend it to UTRAN. I sent out email 
> on this awhile back. IMHO, having this technology  spread to UTRAN is 
> a really bad idea, because it will make handover between domains that
choose 
> to use MIP and those that use GPRS impossible, regardless of the radio 
> technology.

Do you mean GRX?  At least as I have read about GRX, it is currently
used for roaming, not for handovers.  I haven't heard of any
plans within 3GPP to use it for anything else ... but I don't
attend 3GPP meetings.  Could you point to info on how GRX would 
be used in the UTRAN?  If that is something real, it does sound like
a hack.

Anyhow, I'll try to dig up some more info on this.

> done in the late 80's and early 90's with NETBIOS and IP. If 
> 3G takes off (a big "if" at this point), there will be alot of GPRS 
> nodes out there, so it  would be in the interests of interoperability 
> and the Internet to make this happen.

I agree.  In my mind, the current 3GPP architecture resembles an
access network.  This makes the GGSN look like the first hop
router.  The GGSN will be the network element that is involved
in address selection, etc.  What would be an area to first tackle 
would be:

1) Getting an RFC on MIP v6 
2) Proposing how to allow handoffs from the GGSN to other 
   routers (inter-system)
3) Proposing how to allow handoffs from the GGSN to other
   GGSNs (inter-domain).

I think that some of these issues have been brought to the
IETF's attention at the most recent IPNGWG's Interim
Meeting in Seattle.

PS - one goal of the manyfolks-ipv6-cellular-host is to enable
cellular hosts to be good citizens of the Internet, so comments
on the draft with regards to this point are very much appreciated.

best regards,
John

---

From: [email-masked]
Date: Tue, 10 Jul 2001 10:35:47 +0300

Hi George,

> I certainly agree that 3GPP (today in all visible releases) 
> does not have much use for fast MIP handoffs... I am, however, 
> aware that 3G bodies (not only 3GPP) are looking at MIP and 
> would like to get more IP in their architecture, although I am 
> not sure how far they can really go and what
> good will that do...but that is another story...

I agree.  One of the intentions of the manyfolks-ipv6-cellular-host
is to work with the current architecture.  By no means do I want
to limit future evolution.  Think of the draft as a starting 
point.

> My point with the manyfolks-ipv6-cellular-host draft was that 
> it should state that these are guidelines to 3G host implementers
> ...rather than general internet hosts (ot even mobile hosts)

We intended it to.  The introduction does state what a 
cellular host is to be considered:

   For the purposes of this draft, a cellular host is considered to be
   a terminal which uses an air interface to connect to a cellular
   access network (i.e. - GPRS, UMTS, CDMA2000) in order to provide
   IPv6 connectivity to an IP network.  The functionality to provide
   IPv6 connectivity is outlined in this draft.

This is getting off the topic of the original subject, but 
just to bring the conversation around to Mobile IP ...
There will be some devices that will want to support MIP
as well as 3G.  The draft should not limit such devices,
in fact, we would like to have some text that helps 
implementors know what functionality is needed in the 
host in order to support MIP.  Now, we are not stating
that 3GPP will use MIP, but rather if there was some 
hybrid device - let's say WLAN with MIP and WCDMA with
UMTS, what would be needed to support MIP.

> Now I am not sure if this has anything to do with the BETH 
> extensions, which to my understanding attempt to be applicable 
> to IP networks in general...not 3G in particular...thank god 
> there is life beyond 3G!

Exactly.  I don't want to be here for the purpose of promoting
3G architectures, but to make sure that everyone plays nice :)

John

---

From: Phil Roberts <[email-masked]>
Date: Tue, 10 Jul 2001 10:16:18 -0400

> impossible, regardless of 

GPRX is from what I understand the GPRS routing exchange, a private IP
network
over which GTP is run and allows roaming between different GPRS operator
networks.  If by domains you mean different operator GPRS networks handover
is already defined.  If by domains you mean GPRS networks and other kinds of
networks (WLAN clouds) I'm not aware of anything being done to extend GTP
to cover those.  I'm not sure who would do that, it seems a little out of
scope
for 3gpp, but MIP would be well suited for that.

> 3G takes off

Agreed.

> does not have
> extensions, which