Subject: [mobile-ip] Hierarchical MIPv6 Requirements

From: James Kempf <[email-masked]>
Date: Fri, 16 Mar 2001 08:44:03 -0800 (PST)

Hesham & Jari,

I don't want to get involved in taking sides on either of your proposals
because I see points with which I agree and disagree in both. 
While I don't want to cast any aspersions, I'm very curious to know
how one proposal was selected as a working group draft without an
agreed upon set of requirements. Much of the disagreement I've seen
in the mailing list discussion seems to be founded on some fundamental
disagreements about what the requirements should be. Given the lack of an agreed 
upon set of requirements for hierarchical MIPv6,  I think it is going to be 
difficult to resolve the differences.

In a previous email, I expressed my reservations about tunnelling 
over the radio link, and the requirement for efficient use of the
radio link.

In this email, I'd like to bring up an additional requirement. There
has been some discussion about whether or not arbitrary levels of
hierarchy are of value. We recently did a study of using HMIP for
a next generation IP based radio access network, and one of the 
issues was supporting arbitrary levels of hierarchy with minimal (ideally
no) mobile involvement. It seemed like it could be done with extended
mode, but there were other problems with extended mode that made
it less attractive. I have not looked at the most recent draft yet,
perhaps those points have been addressed.

One of our requirements is that it shall be possible to support
multiple levels of hierarchy with minimal (ideally no) mobile involvement.

		jak

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Fri, 16 Mar 2001 19:06:56 +0100

Hello James

> agreed upon set of requirements.

If you're looking for a formal set of requirements in draft form,
there aren't any apart from those in the individual drafts. However,
the local anchor point problem was addressed in v4 with Regional
Registrations, so the same set of supporting reasons exist in v6.
So it seems logical that a solution was proposed for v6.
If you remember there were three proposals in Pittsburgh. Some
issues, esp. security were raised about one of them (Jari's). The
remaining two (Claude's and Hesham's) had a lot of things in common and
were merged. The request to make this into a WG doc and move the HMIP
work forward was put on the list and there seemed to be no problem.
Of course any comments on HMIPv6 are still welcome. Hope this clarifies
things.

> over the radio link, and the requirement for efficient use of the

Working for Ericsson I am of course interested in spectrum efficiency.
However it has been already pointed out that this is probably
a ROHC issue, independent of HMIP, and I believe ROHC WG is working
on this.

> no) mobile involvement.

Can you give reasons?
I believe that it is important for HMIPv6 not to be tailored only to
RAN issues. It should be simple and generic.

> It seemed like it could be done with extended

OK.

> multiple levels of hierarchy with minimal (ideally no) mobile 

This is a very specific case, so I'd be interested if you
could provide more reasons for this requirement. It's not a requirement
from RAN standards I'm involved in.

Regards
/Karim

---

From: [email-masked]
Date: Fri, 16 Mar 2001 13:57:36 -0600

>agreed upon set of requirements. 

We did a WG consensus call sometime last year (need to dig the
archives for the details), before deciding on making HMIPv6 a WG
document. I wonder where were all these views and arguments when the
call was issued.

>		jak

-Basavaraj

> -----Original Message-----
> From: ext James Kempf [mailto:[email-masked]]
> Sent: Friday, March 16, 2001 12:28 PM
> To: [email-masked]
> Subject: RE: [mobile-ip] Hierarchical MIPv6 Requirements
> 
> 
> Hi Karim,
> 
> Thanx for your reply.
> 
> The specific issue had to do with moving header compression context,
> and especially whether there is additional overhead involved 
> in re-establishing 
> header compression after handover at all or with additional 
> tunnel headers or
> header options. I think this is probably a Seamoby/Context 
> Transfer issue.
> 
> >Can you give reason?
> Yes. In the RAN design we are looking at, there is an upper part
> on which packets are application or user packets. We would like
> to use a hierarchical MIP to implement mobility (what we call
> micromobility, which is different from what Seamoby calls 
> micromobility)
> across this part of the RAN. I can't say more without getting into
> deeper technical details, which I would rather not at the moment.
> The important point is that we would like the mobile to be aware
> of just one level of hierarchy, and there will be hierarchy outside
> the RAN, in the core, if the operator wants to optimize signalling,
> or provide a locally assigned home address.
> 
> Agreed.
> The requirements come out of the MWIF study on IP based RANs, but 
> 3GPP2 has begun an activity to redesign their RAN to be more 
> compatible
> with IP. So far, 3GPP hasn't been very receptive to this idea. We
> would like to submit the design we've been  looking at to 3GPP2, but
> we want to make sure we have a good hierarchical scheme.
> 
> 		jak
>

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 19 Mar 2001 12:52:39 +0000 (PST)

> multiple levels of hierarchy with minimal (ideally no) mobile involvement.

James,

While I understand the basis for your requirement to minimize (header) overhead
on the radio link, I don't understand the basis for the multiple levels of
hirarchy.

Can you enlighten me,

  Erik

---

From: James Kempf <[email-masked]>
Date: Mon, 19 Mar 2001 10:34:28 -0700

Hi Erik,

>on the radio link, I don't understand the basis for the multiple levels of

One of the things we've been looking at in MWIF is using hierarchical MIP
in a future all-IP radio access network. This list is not the right place
to get into details about exactly what this would allow, but the point
is that if an hierarchical MIP is used in the RAN, the core network
also needs the option to have its own level of hierarchy. There are 
other possible configurations that might require this.

Also, while general principles can be misleading, those of us who remember
the DOS or VMS file system have a general distrust of hierarchical systems that
limit the number of levels. Eventually, somebody wants more than that
limit. This isn't a hard and fast requirement, but I think maybe it
is a design principle.

		jak