[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [MIP-QOS] RE: MIP-QOS MIP QoS Mailing List is Active Now
Hi guys:
Can we stop discussing micro-mobility here. It is already a hot topic in
Mobile IP. We have already agreed upon the requirement that:
"The QoS mechanism should interoperate with micro-mobility techniques being
defined in Mobile IP".
How it does it is solution specific.
Hemant
-----Original Message-----
From: ext Gwendal Le Grand [mailto:Gwendal.Le-Grand@lip6.fr]
Sent: 18. April 2001 12:34
To: mip-qos@research.nokia.com
Subject: RE: [MIP-QOS] RE: MIP-QOS MIP QoS Mailing List is Active Now
Phil,
Micro mobility introduces a kind of hierarchy in a domain
Some well known protocols are Hawaii, Cellular IP, Hierarchical Mobile IP
The basic idea (with IPv4) is that you move within the hierarchy.
Your COA (Care of Address) is the COA of an agent at the top of the
hierarchy so that you always keep the same COA as long as you stay in the
domain.
Moreover, signalling is done only locally (you need not tell your HA you are
moving when you roam within the hierarchy since your COA remains unchanged).
There is only a need to refresh the binding lifetime regularly.
I hope this answers the question
Gwendal
-------Gwendal LE GRAND-------
mailto:Gwendal.Le-Grand@lip6.fr <mailto:Gwendal.Le-Grand@lip6.fr> tel: +33
(0) 1 44 27 75 12
http://www-rp.lip6.fr/~legrand <http://www-rp.lip6.fr/~legrand> fax: +33
(0) 1 44 27 74 95
Universite Pierre et Marie Curie, Laboratoire LIP6-CNRS, Bureau C646
8 Rue du Capitaine Scott, 75015 Paris, France
-----Message d'origine-----
De : owner-mip-qos@research.nokia.com
[mailto:owner-mip-qos@research.nokia.com]De la part de ext Phil Roberts
Envoyé : mercredi 18 avril 2001 18:00
À : 'mip-qos@research.nokia.com'
Objet : RE: [MIP-QOS] RE: MIP-QOS MIP QoS Mailing List is Active Now
-----Original Message-----
From: ext Gwendal Le Grand [mailto:Gwendal.Le-Grand@lip6.fr]
Sent: Wednesday, April 18, 2001 5:27 AM
To: mip-qos@research.nokia.com
Subject: RE: [MIP-QOS] RE: MIP-QOS MIP QoS Mailing List is Active Now
Hello,
Here are some comments on the requirements :
2> I believe this can be accomplished with micro mobility protocols which
hide the mobility to the home network. About the delay to establish the new
QoS path, my feeling is that it can be done before the IP handoff by some
sort of predictive reservation scheme (which would be relatively easy to set
up in a micro mobility domain). The problem here lies when the mobile moves
between two micro mobility domains. The QOS path may take more time to be
set up but once again some predictive path could be determined in advance.
Using micro mobility has many advantages one of which is that the qos path
is not changed in the core (which can then easily use Diffserv since the
path is not highly dynamic) when you move within a domain. In the domain
itself, it seems feasible to maintain more states and therefore deal with a
higher handoff rate.
[Phil Roberts]
Could you clarify what you mean by micromobility?
4> Micro mobility also answers the scalibility problem. Maybe the micro
mobility domain can be handled with a Diffserv mechanism but i believe the
cells themselves should maintain more states. This comes to the conclusion
that you can use Diffserv on the wired part of the network (micro mobility +
core) but probably not on the wireless link.
6> I don't understand this. Using the mobile's home address is not fine ?
7> More protection could be provided if the medium has a a high error rate.
In IEEE 802.11, many transmission rates (with a more or less robust code --
high rate is less robust of course) are used according to the link's
quality. Is this what is meant in this requirement ? What media should be
considered ?
8> Is two way really an issue ? Maybe for the ACKs ? RSVP deals with duplex
links as 2 simplex links.
9> Same comment as 8>
14> I believe this depends on whether we talk about IPv4 or IPv6. It seems
to me that the solution is not the same in both cases. When talking about
IPV4/IPV6 being dealt with seperately, i think the principles should be the
same (esp. if route optimization is a requirement). However, IPv6 has some
specific functionnalities which we should take advantage of.
Gwendal LE GRAND
-------Gwendal LE GRAND-------
mailto:Gwendal.Le-Grand@lip6.fr <mailto:Gwendal.Le-Grand@lip6.fr> tel: +33
(0) 1 44 27 75 12
http://www-rp.lip6.fr/~legrand <http://www-rp.lip6.fr/~legrand> fax: +33
(0) 1 44 27 74 95
Universite Pierre et Marie Curie, Laboratoire LIP6-CNRS, Bureau C646
8 Rue du Capitaine Scott, 75015 Paris, France
Requirements:
------------
1>
The solution should provide the simultaneous operation of location privacy
and route optimization as dog leg routing can increase unecessary delay -
affect QoS. A person using a mobile node should not have to sacrifice one
for the other.
2>
The signaling should be as fast as possible. Waiting on the dynamic dog-leg
establishment of a security associations to authenticate and authorize a
binding and reservation are occuring is probably not an option.
3>
If at all possible the solution should leverage any existing security
associations that exist and are utilized in networks today in order to speed
up the binding and reservation.
4>
The solution should be as scalable as possible. Any effort to reduce the
amount to signaling and processing through core edge and intermediary
routers should be made. Localization of proxy functions into aggregates and
hierarchical topologies at the edge should be utilized to improve the
scalability.
5>
The solution should be as stateless as possible. States should only be kept
at the edge or pertaining to aggregatations.
6>
The solution should not require an implementation to key any logical data
structures (FIB, RIB, PIB, BC, SIB, etc..) using the source IP address of an
MN as this will change.
7>
This is really a wireless requirement:
In order to provide for unequal protection of media streams on wireless link
layers, the signaling should be able to convey the actual media types used
as part of the flows being reserved.
8>
The solution should allow for both one way and two way reservation when
asymmetric routing is not an issue i.e. a point to point link on the first
hop.
9>
The solution should work with asymmetric routes.
10>
The solution should provide for proxy functions of the signaling with
"older" solutions for backward compatibility and when the signaling is
considered too verbose for a specific link layer.
11>
The solution should provide for fast recovery mechanisms when intermidary
nodes fail.
12>
A method must be provided to encrypt the signaling as it passes to the
affected nodes of the network.
13>
A method must be provided to authenticate the credentials of the signaling
entities.
14>
It should be possible to send an application packet along with the
signaling.
15>
Authorization and Accounting should be treated as separate, decoupled
back-end processes.
Questions to discuss:
--------------------
1>
Should the signaling solution be the same for IPv4 as for IPv6?
2>
What assumptions, if any, can be made about pre-existing security
associations between the MN with its visited and home domains can be made?
3>
What assumptions, if any, can be made about any pre-existing SAs between a
CN and it's visited and home domains can be made?
Hope this helps,
Glenn