[Mobopts] MPA review
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Mobopts] MPA review
Hi,
my high-level comment is that the document captures many things. While
this is a good thing in one way, it diminishes the focus as a bye
product, unfortunately. So, I am suggesting that it should be
streamlined to make it crisp to better retain its focus on pre-auth
related issues, framework and procedures for inter-domain handovers.
More comments below:
Regards,
-Rajeev
The paragraph starting with "An end-to-end delay consists of several.."
is too dense and long. I am not sure if all of the text is needed.
Please consider making this brief, and keep only the parts which are
essential. In general, detailed descriptions of the previous work should
be referenced out, and not be repeated here.
"This type of Inter-technology handover is often
called as Vertical Handover since the mobile makes movement between
two different cell sizes."
^^^^^^^^^^ ??
Section 2 is titled "Inter-domain handover", but it includes the
definitions for different types of handovers. Perhaps revise the section
heading to something like "Handover Types". Also, please provide more
succinct definitions. You may move details which may be useful (but not
crucial) to an Appendix.
(I am trying to see if we can make the presentation little more
crisper).
Section 3 provides a good survey. You may want to revise the title to
"Related Work"
Section 4 - Applicability should be no more than two paragraphs I think
Shouldn't the Terminology Section be earlier, say right after
Introduction?
Section 6.1:
"MPA provides four basic procedures to provide this functionality.
The first procedure is referred to as "pre-authentication", the
second procedure is referred to as "pre-configuration", the
combination of the third and fourth procedures are referred to as
"secure proactive handover"."
Either state 4 procedures or 3 procedures.
Section 6.1, paragraph 3 is important for people to get a high-level
overview. It is too condensed. Please try to make the steps clear. And,
do no use acronyms (such as MMP) that are not defined earlier.
PHT (Proactive Handover Tunnel) -> Proactive Handover Tunnel (PHT)
Section 6.2:
"..securely executing a configuration protocol to
securely deliver an IP address .."
too many 'securely'
"An access router is a router that is responsible for the other part
of pre-configuration, i.e., securely executing a tunnel management
protocol to establish a proactive handover tunnel to the mobile node.
The signaling messages of the configuration protocol MUST be
protected using a key derived from the key corresponding to the
MPA-SA."
May be I missed it.. How does the AR get the corresponding keys? You
describe it later, but please make a reference
Section 6.3:
Step 2: "It then performs pre-configuration,
with the configuration agent using the configuration protocol to
obtain an IP address, say nCoA (new care-of address), and other
configuration parameters from the CTN, and with the access router
using the tunnel management protocol to establish a proactive
handover tunnel. "
There are two distinct steps here: pre-configuration, tunnel set up.
You should not combine them into a single sentence (this applies as a
general rule). Also, specify what "other configuration parameters"
mean; it should be clear.
Step 4:
"The mobile may execute the tunnel
management protocol to delete or disable the proactive handover
tunnel and cache nCoA after deletion or disabling of the tunnel. "
Do you allow tunnel deletion prior to link switching? If so, what does
the AR do for packets arriving for nCoA, once tunnel interface is
deleted? "Caching" an address does not sound right.
"An example call flow for MPA is shown in Figure 3 and Figure 4."
Why is this an example call flow? This is _the_ call flow right?
Section 7:
Please focus on the parts essential to the MPA, and move rest of the
description to the Appendix.
Section 7.3.5. is perhaps not crucial, and can be moved to the appendix
Section 7.4 is not necessary I think. You have created a tunnel
interface between the MN and AR. There are references on how to ue ND
over tunnel interfaces. You can also disable it.
Sections 7.6 and 7.9 are related, and should be condensed into one
section I think.
Section 7.8 does not belong to the main body of the document
Section 8 on Deployment Issues: IMHO, this may be a little early for the
framework. I would consider a separate document once enough experience
is obtained. If there are parts you consider worth documenting now,
please move them to the Appendix.
Section 9 is important since it is supposed to capture the Inter-domain
Handover, which is the primary focus of this ID.
I would consider the key issues that come up, and move multicast
mobility out, or considerably condense it.
In sum, please revise the ID keeping the essential parts in the main
body, referencing known work (without too much description) and moving
the adjoining and descriptive material you consider necessary to
appendix.
General presentation:
please revise phrases such as "A mobile may like to.." to "A mobile may
wish to.." And, please avoid sentences such as "..should not be a big
problem".
"Third, a mobility optimization mechanism needs to support not only
multi-interface terminals where multiple simultaneous connectivity
through multiple interfaces can be expected, but also single-interface
terminals."
RKo> I assume you mean single interface connectivity right? Even with
multiple interfaces, you could still have a single interface
connectivity.
"References [RFC2679], [RFC2680] and 2681 [RFC2681] describe some of the
measurement techniques for delay and
jitter."
RKo> "Measurement techniques for delay and jitter are described in [],
[].."
"This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster at starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."
_______________________________________________
Mobopts mailing list
Mobopts at ietf.org
https://www.ietf.org/mailman/listinfo/mobopts
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.