Subject: [nemo] New draft draft-ming-nemo-sipnemo-00.txt

From: "Lee, Chao-Hsien" <[email-masked]>
Date: Sat, 8 Oct 2005 14:53:19 +0800

Dear all:

We have submitted a new draft that extends SIP to support network mobility
and to achieve RO.

You can get this document from the following URL.

http://www.ietf.org/internet-drafts/draft-ming-nemo-sipnemo-00.txt

Abstract is as follows.

   The Network Mobility (NEMO) Basic Support protocol enables a mobile
   network to change its point of attachment and keeps nodes in the
   mobile network reachable when the mobile network moves in the
   Internet.  However, using the NEMO Basic Support protocol, all
   traffic must pass through the bi-directional tunnel between a mobile
   router and its home agent when the mobile router leaves its home
   network.  It results in sub-optimal routing and long transmission
   delay.  This document describes the SIP-based Network Mobility (SIP-
   NEMO) Route Optimization (RO) that achieves optimal routing and
   reduces the limitation due to the bi-direction tunnel using Session
   Initiation Protocol (SIP).

Any question or comment is welcome. 

best regards,

Lee, Chao-Hsien
Ph. D student,
Lab of Multimedia Mobile Network,
Dept. of Computer & Information Engineer,
National Cheng Kung University, Tainan, Taiwan, R.O.C

Lab's phone: +886-6-2080362
E-mail : [email-masked]

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 25 Oct 2005 09:55:00 -0400

> http://www.ietf.org/internet-drafts/draft-ming-nemo-sipnemo-00.txt

The use of SIP to perform route optimization that this document describes
is fairly straightforward and seems technically sound to me.  The only
problem I see is that the solution doesn't seem to satisfy NEMO goals.

The sipnemo-00 draft says: "The extensions, which is called SIP-based
Network Mobility (SIP-NEMO) protocol, are compatible with SIP and satisfy
the goals and requirements defined in [6] for network mobility.", where
[6] is Ernst, T., "Network Mobility Support Goals and Requirements",
       draft-ietf-nemo-requirements-04 (work in progress),
       February 2005.

This statement doesn't seem to be correct, since in [6], section 3.3, it
is stated: "Consequently, NEMO support is expected to be performed only
by the MR(s).  Specific support functions on any other node than the
MR(s) would better be avoided."  Also, in 3.4, "NEMO support is to be
implemented at the level of IP layer.  It is expected to be transparent
to upper layers so that any upper layer protocol can run unchanged on
top of an IP layer extended with NEMO support."

SIP-NEMO seems to break these desired transparencies since it requires a
SIP server infrastructure, and presumably applications would have to use
SIP in order to have their traffic route optimized.  So although this is
a neat solution, it doesn't quite seem to fit the NEMO goals.  Would you
agree with this analysis?

-Wes

-- 
Wesley M. Eddy
Verizon Federal Network Systems
http://roland.grc.nasa.gov/~weddy

---

From: "Lee, Chao-Hsien" <[email-masked]>
Date: Wed, 26 Oct 2005 00:57:22 +0800

Dear Mr. Wesley Eddy:

Yes, I agree your analysis. I think that our wording needs to be revised
more precisely. Since the proposed SIP-NEMO adopts SIP to achieve RO,
SIP-NEMO only satisfies some NEMO goals, such as Migration Transparency,
Arbitrary Configurations, Scalability, and Backward Compatibility. Thus, I
think that SIP-NEMO satisfies the basic spirit/concept of Network Mobility
except that SIP-NEMO is from the perspective of application layer. Thanks
for your suggestions and comments.

best regards,

Lee, Chao-Hsien

-----Original Message-----
From: Wesley Eddy [mailto:[email-masked]] 
Sent: Tuesday, October 25, 2005 9:55 PM
To: Lee, Chao-Hsien
Cc: [email-masked]; [email-masked]
Subject: Re: [nemo] New draft draft-ming-nemo-sipnemo-00.txt

-Wes

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 28 Oct 2005 16:22:56 +0900

Dear all,

I have 3 comments to make on the comments:
1. Section 3 of draft-ietf-nemo-requirements are "design goals", not
requirements, so a specific solution (for extended support) doesn't have
to fulfill them.
2. Design goal "3.3" says "expected to be transparent" not "must be
transparent"
3. I agree that NEMO WG may not be relevant to discuss application layer
solutions to the RO problem.

But, more importantly, we are still not in the process of evaluating
solutions since we haven't decided yet if the NEMO WG will work on the
solutions ... So, 1st thing 1st, we need to debate around the 2 RO
drafts draft-ietf-nemo-ro-problem-statement and
draft-ietf-nemo-ro-space-analysis.

And, in Vancouver, we need to answer the question "what are the next
steps for the NEMO WG. Are we going to conclude the WG (if yes, with
which missions), or recharter?"

Thierry.

 On Wed, 26 Oct 2005 00:57:22 +0800
"Lee, Chao-Hsien" <[email-masked]> wrote:

> Dear Mr. Wesley Eddy:
> 
> Yes, I agree your analysis. I think that our wording needs to be
> revised more precisely. Since the proposed SIP-NEMO adopts SIP to
> achieve RO, SIP-NEMO only satisfies some NEMO goals, such as Migration
> Transparency, Arbitrary Configurations, Scalability, and Backward
> Compatibility. Thus, I think that SIP-NEMO satisfies the basic
> spirit/concept of Network Mobility except that SIP-NEMO is from the
> perspective of application layer. Thanks for your suggestions and
> comments.
> 
> best regards,
> 
> Lee, Chao-Hsien
> 
> > We have submitted a new draft that extends SIP to support network
> > mobility and to achieve RO.
> > 
> The use of SIP to perform route optimization that this document
> describes is fairly straightforward and seems technically sound to me.
>  The only
> Network Mobility (SIP-NEMO) protocol, are compatible with SIP and
> satisfy the goals and requirements defined in [6] for network
> mobility.", where[6] is Ernst, T., "Network Mobility Support Goals and
> Requirements",
> This statement doesn't seem to be correct, since in [6], section 3.3,
> it is stated: "Consequently, NEMO support is expected to be performed
> only by the MR(s).  Specific support functions on any other node than
> the MR(s) would better be avoided."  Also, in 3.4, "NEMO support is to
> be implemented at the level of IP layer.  It is expected to be
> transparent to upper layers so that any upper layer protocol can run
> unchanged on top of an IP layer extended with NEMO support."
> 
> SIP-NEMO seems to break these desired transparencies since it requires
> a SIP server infrastructure, and presumably applications would have to
> use SIP in order to have their traffic route optimized.  So although
> this is a neat solution, it doesn't quite seem to fit the NEMO goals. 
> Would you agree with this analysis?
> 
> -Wes
> 
> -- 
> Wesley M. Eddy

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Oct 2005 12:43:22 +0200

> which missions), or recharter?"

_If_ new Charter, I'd support the following new missions as part of it:
-v4 stuff
-clarifying DHAAD interactions.
-deployment aspects, implementation feedback, eventual implementation
 feedback about security leaks.

Alex