[MIP-QOS] Regarding requirements that you mentioned

[Hemant.Chaskar@nokia.com]

 Hi Glenn: Thanks for your comments. Here are my thoughts on some of them.
 
  -----Original Message----- 
From: ext Glenn Morrow [ mailto:gmorrow@nortelnetworks.com
<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 

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.  

Hemant>> Help me understand this. If MN wants absolute location privacy, the
only way we can do it today with MIP is dog leg routing. Now if I have a
real time application as well as I want location privacy, I have to go
through HA. Isn't that true? 

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. 

Hemant>> Agreed. I think the best approach  is to highlight for the solution
designer the fact that CoA may change upon handover.  

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. 

Hemant>> Making two way reservations at once looks to me as optimization
rather than a requirement. What if one comes up with solution that does two
one-way reservations while satisfying the rest of the requirements.?

14> 
It should be possible to send an application packet along with the 
signaling.  

Solution specific.  

GM] What solution did I specify?  

Hemant>> Let me reword it this way. How will the Qos mechanism fail if it
cannot do (14)? If we come up with answer to that question then we should
include it as a requirement. 

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.  

Hemant>> Suppose we have solutions A and B. A combines authorization and
accounting, while B keeps them separate. Both of them satisfy all the rest
of the requirements. Then, do we have right to dump A?

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.  

Hemant>> We will quote that the requirements are generic and independent of
IP version. The solutions for 4 and 6 could be independent or one solution
may work with both versions. 

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. 

Hemant>> Should we be adding a section on suggested guidelines in the
document? We have to discuss this with WG chairs. I agree that such a
section will be useful and we can probably collect other issues which are
not best justified as requirements in this section.

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