Hemant,
Thanks for your input - comments below:
-----Original Message-----
From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com]
Sent: Wednesday, April 18, 2001 10:04 AM
To: mip-qos@research.nokia.com
Subject: RE: [MIP-QOS] RE: MIP-QOS MIP QoS Mailing List is Active Now
-----Original Message-----
From: ext Glenn Morrow [mailto:gmorrow@nortelnetworks.com]
Sent: 17. April 2001 12:37
To: mip-qos@research.nokia.com
Subject: [MIP-QOS] RE: MIP-QOS MIP QoS Mailing List is Active Now
Hi Glenn;
Some comments on the requirements list:
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.
We can say as a requirement that:
"QoS mechanism SHOULD be able to support QoS along different potential
paths, namely, direct path, triangle path and temporary tunnel between ARs.
However, whether all paths are supported or only a subset of them is
supported will be determined by external mechanisms such as, say, mobility
management, policy etc. Further, the same QoS mechanism may not be able to
support all the three alternatives.
GM] It seems to me that at least for real-time bandwidth and delay sensitive communications such as voice or video, that is it economically "stupid" to triangle route it. It also appears to me that the signaling will be intercepted that could easily provide the simultaneous functions will absolutely no more overhead in terms of state kept. To again see my point, consider a small enterprise connected to the Internet with a T1 with the MN's home subnet inside the premises. Now if the customer wants location privacy then the customer will be using up 2x the bandwidth necessary on their little T1 when no bandwidth usage was needed at all.
Though I think your requirement is good, it somehow does not convey the same thing as 1. I would recommend both.
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.
This can be covered by the following statement:
"Minimize the interruption in QoS at the time of handover: Interruption in
QoS would occur if the MN's packets arrive at the intermediate node in the
new end-to-end path without that node having information about their QoS
forwarding requirement. Such QoS interruption MUST be minimized. A good
metric for this performance aspect is the time difference between the
instant MN's packet may potentially arrive at a node and the instant that
node is supplied with sufficient information to perform appropriate QoS
forwarding."
GM] Agreed
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.
Same as comment on 2.
GM] Agreed
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.
We will quote scalability, security and saving wireless bandwidth as obvious
desirable features.
GM] I thought so too but based upon the current definition of HMIP, RR - apparently not even in the MIP WG.
5>
The solution should be as stateless as possible. States should only be kept
at the edge or pertaining to aggregatations.
Covered in 4. Where the state is kept depends upon how your network domains
are organized. If you are using IntServ in access and DiffServ in core, the
state will be at the edge only. Thus our requirement cannot dictate where
the state is kept. Its upto the network planner.
GM] state is kept or not
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.
Shall we call this an interoperability requirement. I listed
interoperability with (IntServ, DiffServ, MPLS), (Mobile IP, micro-mobility,
fast handover, context transfer) in my earlier mail. Shall we be adding the
databases you mentioned to that list? If yes, can you send me the complete
list with references.
GM] Interoperability is a separate issue. Irrespective of which signaling is used MIP, IP options, ICMP, RSVP, YESSIR, etc.. or not, the COA will have to change on a handoff. There is currenlty no signaling that does what NSIS needs to do in entirety - so as soon as you say BW compatible with X you have to not be BW compatible or interoperable with Y especially in IPv4. Two functions must be done with one packet - one or more protocols is going to be dumped with respect to IPv4.
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.
Does this cause layer violation? Does IP layer really see if the link layer
offers unequal error protection or not. Isn't it that at IP layer, QoS is
essentially a packet forwarding priority. Should link and media descriptions
be included in IP layer QoS mechanism?
GM] Some signaling has to convey this information to the link layer equipment. This signaling will reside at layer 3 or above. That signaling can be layer 5 signaling or QoS signaling for layer 3. What I am proposing is actually to not have a violation. I would like to see some NSIS layer 3 (network signaling) tell layer 2 what it needs. It is normal and proper for layer 2 and 3 to communicate. The violation would be if Layer 5 had to tell layer 2 what to do which is what is currently occuring in the 3G SDOs. Do you see my point?
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.
This wanders into solution space. If you do two-way at once or two one-way
QoS establishment is solution specific.
GM] Nope, the problem of assymetric routes is disjunct in that routing policy sets this up. I am saying that your signaling MUST handle both as a requirement. I do not recommend how. I think you may have read one of my suggested responses to someone else who started proposing solutions. This is a requirement.
9>
The solution should work with asymmetric routes.
Covered in 8.
GM] Agreed.
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.
Could you explain this further? Wouldn't it be an optimization achieved by
certain solution rather than a requirement. Further, this issue is covered
by the general requirements stated in 4.
GM] The point is that the security and encryption must be designed with proxies and interworking with legacy systems in mind.
11>
The solution should provide for fast recovery mechanisms when intermidary
nodes fail.
This is an important topic to consider. Should we make robustness against
topology changes (as achieved in say RSVP) a requirement or option. Note
that by topology change, I mean a route change not related to handover.
GM] I'm for both as requirements.
12>
A method must be provided to encrypt the signaling as it passes to the
affected nodes of the network.
Covered in 4.
GM] I don't think this is covered in 4, it might be covered as part of a requirement for 1. See 13 response.
13>
A method must be provided to authenticate the credentials of the signaling
entities.
Covered in 4.
GM] No 4 is LMM - only one (the mobile) side of the network. This affects both sides of the network i.e the CN side too.
14>
It should be possible to send an application packet along with the
signaling.
Solution specific.
GM] What solution did I specify?
15>
Authorization and Accounting should be treated as separate, decoupled
back-end processes.
Covered in 4 and is solution specific.
GM] Now I am really confused. What solution did I specify. If anything I opened the door to many solutions.
Questions to discuss:
--------------------
1>
Should the signaling solution be the same for IPv4 as for IPv6?
Not necessary.
GM] Do you want to state that as something that is O.K. in your document. It is often helpful to specify such things.
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?
We can let solution designers worry about that.
GM] This information would affect what the solution designers would design. Why do you want to waste your own and other peoples time when a guidline can be given.
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?
Same as 2 above.
GM] Same as above.
Thanks,
Glenn