Mooi,
Some good cents - my thoughts below.
-----Original Message-----
From: ext chuah [mailto:chuah@hoserve.ho.lucent.com]
Sent: Wednesday, April 18, 2001 8:34 AM
To: mip-qos@research.nokia.com
Subject: Re: [MIP-QOS] RE: MIP-QOS MIP QoS Mailing List is Active Now
Hi,
my 2cents
Comments to Requirements:
1) shouldn't these be the requirements for mobility management topic?
If they design it right, we will have optimized route as well as location
privacy (location privacy should be an option).
GM] I agree. It seems that NSIS is trying to fix the whole wagon - might as well make sure it starts with the right requirements.
2) the signaling mechanism should be robust against out-of-order delivery
GM] Good point - agreed.
3) agreed
4) are we assuming only the same type of signaling mechanism works e2e (across
access network as well as core network)?
GM] Not necessarily - we would be getting into solutions if we choose either way at this time.
5) perhaps should include edges between different administrative domains
in the core network as well
GM] I think they may have to process some of the signaling but depending on what is trying to be accomplished and the particulars of the relationship between the two parties, CEs may not need to keep any state.
GM] I guess I can see some aggregate state being kept but I am just a little bit reluctant to bring these requirements from the MIP WG.
6) I don't quite understand this requirement. Also, can someone enlighten me
when we will have mobile equipment that can change source IP address say during
an on-going web session?
GM] Aaaagh, it seems the MIPv6 spec current says the mobile node changes the address - someone or something has to do it. I'm not sure if you are "disbelieving" the MIPv6 spec or not but it seems that the topological correctness issue has to be avoided somehow and the other approaches involve tunneling over the air which is also less efficient or having a router do it which is counter to the "morality" of some purists. I'm trying to be pragmatic and recognize that source filtering is needed for DDoS and that a mobile's address will change on handoff and that at some point we will need to figure out some implementation concept such as a database and a method of unique indexing such that the address can change.
7) Wouldn't a solution that provides mechanism to specify QOS requirements
suffice to take care of this rather than specially say what media type?
GM] I am not apposed to figuring out some generic method of specifying this but from my understanding, the actual codec must be known in order to set up the unequal protection on specific segments of the codes as they come in. You will have achieved true decoupling from layer 5 proxies if you add the ability to convey media types. If you don't then there is still an excuse to have the layer 5 signaling in the loop of everything for these high-price wireless spectrums. I guess you could snoop for this info in each packet but that's not exactly the most delay efficient method of doing it - not to mention I would feel very sorry for the poor person who had to code it. My biggest concern on this requirement is that it is a cellular wireless requirement and many people even in that camp favor the coupling for other reasons anyway. I don't really see people doing unequal protection over Ethernet or even 802.11.
8) agreed
9) agreed but are asymmetric routes common? In some cases, we may not want
asymmetric routes (ease of traffic engineering, revenue collection reasoning)
GM] I agree but perhaps the routing tables on the hosts themselves can be "smart" enough to know when they need to do one thing or the other.
10) I don't understand this requirement. can Glenn explain what he meant
by older solutions? RSVP-based solution?
GM] I mean we should be careful about security, authentication mechanisms such as database indexing and encryption so that we can insure that interworking proxies can be built for "supposedly optimized" access specific junk. I do not think the requirements should mention any specific protocol. If we do come up with another protocol, I suspect older systems will have to interwork with it to some degree.
11) should we treat network element redundancy and failover mechanisms
separately? however, we may need to specify how the mobile node can
quickly use alternative route when one route cann't be used.
GM] I think the functionality is needed as a requirement and it does affect the protocol. Let's not get into solution space yet.
12) not sure if this is always required
GM] There are some information/snooping, DoS, privacy concerns that MUST be dealt with. The only way I see to deal with this is encryption of some sort. This requirement kills several birds with one stone.
13) agreed
14) can you pls explain why?
GM] There are several reasons:
-some applications that are end to end may wish to begin the process of reservation, binding and application signaling with one packet.
-typically it is more efficient over the air to do more than one thing with a single packet.
GM] I guess this is a "something to shoot for" requirement. It seems that a solution that did this compared with one that didn't might be more favorable. There are some very creative minds in the IETF and I certainly don't want to dissuade them from solving the whole ball of wax. I have already seen some security-related contributions come in that build a basis for such functionality.
15) agreed
Mooi Choo
Thank You for your excellent comments and insight.
=========================================================================
Here goes a first stab at discussion:
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