Subject: [nemo] RE: Nemo Digest, Vol 12, Issue 15

From: 김성호 <[email-masked]>
Date: Mon, 18 Apr 2005 11:44:50 +0900

I don't want to receive this mail  from today...
Thanks..

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Saturday, April 16, 2005 1:05 AM
To: [email-masked]
Subject: Nemo Digest, Vol 12, Issue 15

Send Nemo mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/nemo
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Nemo digest..."

Today's Topics:

   1. Re: Fwd: FW: I-D ACTION:draft-minaburo-rohc-nemo-00.txt
      (Vijay Devarapalli)
   2. Re: Fwd: FW: I-D ACTION:draft-minaburo-rohc-nemo-00.txt
      (Greg Daley)
   3. Re: [rohc] Re: [nemo] Fwd: FW: I-D
      ACTION:draft-minaburo-rohc-nemo-00.txt (Carsten Bormann)

----------------------------------------------------------------------

Message: 1
Date: Thu, 14 Apr 2005 11:54:08 -0700
From: Vijay Devarapalli <[email-masked]>
Subject: Re: [nemo] Fwd: FW: I-D
	ACTION:draft-minaburo-rohc-nemo-00.txt
To: [email-masked]
Cc: [email-masked], [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii; format=flowed

In general, I like the the idea of using ROHC in the tunnel between the
mobile router and the home agent, to reduce the tunnel overhead.
I would like to see this draft standardized.

one quick comment.

> As the addresses are classified as static, each time the MR changes 
> its attachment point the ROHC context will be initialized.

wonder why? the MR could just send a binding update to the HA from the new
CoA. binding updates are sent reliably. when the HA processes the binding
update, its updates the ROHC context with the new CoA.
once the MR receives a binding acknowledgement which shows success status,
it also updates the local ROHC context with the new CoA.

Vijay

Ana Minaburo wrote:

> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> On Behalf Of [email-masked]
> Sent: Wednesday, March 16, 2005 12:09 AM
> To: [email-masked]
> Subject: I-D ACTION:draft-minaburo-rohc-nemo-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
>         Title           : ROHC (Robust Header Compression) in NEMO network
>         Author(s)       : A. Minaburo, et al.
>         Filename        : draft-minaburo-rohc-nemo-00.txt
>         Pages           : 0
>         Date            : 2005-3-9
> 
> This document defines the use of ROHC header compression mechanisms 
> for the NEMO Basic Support protocol [9]. The idea is to use both NEMO 
> and ROHC as they have been defined without any change. The tunneling 
> in the NEMO Basic Support protocol will be done over different 
> supports (Wireless LAN, 3G or PPP) links, where ROHC compression can 
> work.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-minaburo-rohc-nemo-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of 
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then
>         "get draft-minaburo-rohc-nemo-00.txt".
> 
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>         [email-masked].
> In the body type:
>         "FILE /internet-drafts/draft-minaburo-rohc-nemo-00.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail
readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader 
> implementation to automatically retrieve the ASCII version of the 
> Internet-Draft.
> 
> 
> ENCODING mime
> FILE /internet-drafts/draft-minaburo-rohc-nemo-00.txt
> 
> 
> ----------------------------------------------------------------------
> --
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
> 

------------------------------

Message: 2
Date: Fri, 15 Apr 2005 10:59:09 +1000
From: Greg Daley <[email-masked]>
Subject: Re: [nemo] Fwd: FW: I-D
	ACTION:draft-minaburo-rohc-nemo-00.txt
To: Vijay Devarapalli <[email-masked]>
Cc: [email-masked], [email-masked],
	[email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii; format=flowed

Hi Vijay,

I think there may be some value in this, if more than just the next
IPv6 header can be compressed.   If it doesn't mitigate the
NEMO MTU issue, people may not care for it.

Regarding the draft itself:

Section 2 has all of the details about ROHC compression.
For the 7 paragraphs after paragraph 2, there is not a single explicit
reference to the ROHC documents for NEMO people to investigate.

This section, while brimming with details, seems to leave me feeling I
don't have enough ROHC context myself.  It would be good to have diagrams
illustrating which headers will be subject to compression, and some
considerations about the NEMOs themselves (apart from the 10 lines in the
first, second and last paragraph of the section).
After all, it is called:  "The use of ROHC in NEMO"

Apart from that, it seems like a good idea in general, not just for NEMO.
It seems like a MIPv6 HA/MAP/FMIPv6AR issue too, although the addresses in
the upper layer tunnel have more constrained destinations in the non-router
case.

I didn't see any text about packet reordering in the document.
I'd guess that the Internet is about the most likely point-to-point medium
to re-order packets.

Vijay Devarapalli wrote:
> In general, I like the the idea of using ROHC in the tunnel between 
> the mobile router and the home agent, to reduce the tunnel overhead.
> I would like to see this draft standardized.
> 
> one quick comment.
> 
>> As the addresses are classified as static, each time the MR changes 
>> its attachment point the ROHC context will be initialized.
> 
> 
> wonder why? the MR could just send a binding update to the HA from the 
> new CoA. binding updates are sent reliably. when the HA processes the 
> binding update, its updates the ROHC context with the new CoA.
> once the MR receives a binding acknowledgement which shows success 
> status, it also updates the local ROHC context with the new CoA.

Actually, I'm not sure that the draft text itself was accurate.

If addresses INSIDE the tunnel changed, then there would have to be changes
to the binding or to the context.

Why would there need to be changes to the context if the transporting
tunnel endpoint addresses - the outer addresses (which aren't subject to
compression) change?

The data transferred on the tunnel doesn't change because of the CoA change.

I'd like to see this document develop maybe as informational if no NEMO-
specific protocol issues arise.

Greg

------------------------------

Message: 3
Date: Fri, 15 Apr 2005 09:18:46 +0200
From: Carsten Bormann <[email-masked]>
Subject: Re: [rohc] Re: [nemo] Fwd: FW: I-D
	ACTION:draft-minaburo-rohc-nemo-00.txt
To: [email-masked]
Cc: [email-masked], Vijay Devarapalli <[email-masked]>,	Carsten
	Bormann <[email-masked]>, "[email-masked]'"
<[email-masked]>,	Henrik
	Levkowetz <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed

I'm not sure the present draft is really doing much more than pointing out
a potential use for ROHC.

To get interoperability, one would need to
-- specify how the use of ROHC is negotiated or otherwise initiated between
the parties
-- specify the encapsulation
-- specify how to deal with reordering (see also draft-ietf-rohc-over-
reordering-02.txt, which just went to WGLC)
-- possibly select a subset of the now no longer trivial gamut of ROHC
profiles to choose from.
A standards-track document should nail down these (and anything I might
have forgotten).
We can do without a rehash of ROHC fundamentals.
(A couple of diagrams/examples pointing out how the result of the whole
thing will look like would be nice, though.)

RFC 3241 is one example for the kind of "ROHC-over-X" document needed.

Clearly, the two working groups will need to collaborate on this.
I don't have a strong feeling which working group should be the "home" 
WG.
Given that similar considerations apply in other uses of ROHC in a mobile
IP environment, I'd like to spend some time hallway-discussing this with
the usual suspects in Paris.

Gruesse, Carsten

------------------------------

_______________________________________________
Nemo mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nemo

End of Nemo Digest, Vol 12, Issue 15
************************************