Subject: RE: [6lowpan] Fwd: I-DACTION:draft-daniel-6lowpan-interoperability-01.txt

From: Tiago Camilo <[email-masked]>
Date: Tue, 2 Aug 2005 08:47:03 +0100

Hi Daniel,
I have some comments/suggestions in the following draft: 
Interoperability of 6LoWPAN
	1) In this draft you describe the gateway architecture for the interoperability
between 6LoWPAN/external IPv6 networks, but I think that is important to
describe the requirements of such gateway. Do you think that this gateway
functions can be perform at a normal FFD?
	2) In your architecture you always “translate” IPv6 addresses to 16-bit short
addresses, but I think that is reasonable to think that it may be cases when it
is necessary to forward packets containing the source 64-bit address or even
the full 128-bit address. This can be passed as an option field, do you agree?
	3) What about AAA services, are your thinking in addressing this type of
services in your gateway architecture?
	4) You only address the IPv6 unicast addresses, are you planning in enabling
multicast/broadcast addresses?

Regards,
Tiago Camilo
University of Coimbra

________________________________________
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Daniel Park
Sent: terça-feira, 19 de Julho de 2005 22:30
To: [email-masked]
Subject: [6lowpan] Fwd: I-DACTION:draft-daniel-6lowpan-interoperability-01.txt

fyi...

------- Original Message -------
Sender : [email-masked]<[email-masked]>
Date : Jul 20, 2005 04:50
Title : I-D ACTION:draft-daniel-6lowpan-interoperability-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.

    Title        : Interoperability of 6LoWPAN 
    Author(s)    : S. Park, et al. 
    Filename    : draft-daniel-6lowpan-interoperability-01.txt 
    Pages        : 10 
    Date        : 2005-7-19 
     
This document specifies the gateway architecture for the 
   interoperability between 6LoWPAN and external IPv6 networks.  The 
   gateway does the compression and decompression of IPv6 packets and 
   performs the mapping between 16 bit short addresses and the IPv6 
   addresses for both the external IPv6 networks and 6LowPAN, 
   respectively. 

A URL for this Internet-Draft is: 
http://www.ietf.org/internet-drafts/draft-daniel-6lowpan-interoperability-01.txt

 
Regards 
 
Daniel (Soohong Daniel Park) 
Mobile Platform Laboratory. SAMSUNG Electronics

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

---

From: Soohong Daniel Park <[email-masked]>
Date: Tue, 02 Aug 2005 18:16:34 +0900

Tiago,

Firstly, thanks your comments and that will be a
good seed to raise the awareness of folks hopefully.

> functions can be perform at a normal FFD?

Yes, technical requirements of gateway would be useful
to sense what 6lowpan gateway is. And I am currently
assuming FFD can be used to this gateway.

> 2) In your architecture you always "translate" IPv6 addresses to 16-bit 
> short

In my understanding, it depends on what 6lowpan needs to achieve wrt
gateway. Originally, we did focus on of how we could reduce traffic amounts
over the limited bandwidth of 6lowpan, so 16-bits short address appeared
in our document. Also, others (64-bits full IPv6 address) are open...

> services in your gateway architecture?

Well, I know 6lowpan is considering of how we can support
security solutions, but I am not sure whether or not 6lowpan
needs AAA in its scenarions. It's also controversial issue.

> multicast/broadcast addresses?

The usage of multicast/broadcast is ongoing issue of course.

I don't have any hard stance regarding your comments and
all comments can be discussed as an open issue during
our face-to-face meeting...

Regards,

Daniel (Soohong Daniel Park)
Mobile Platform Lab., SAMSUNG Electronics.

---

From: Tiago Camilo <[email-masked]>
Date: Tue, 2 Aug 2005 11:54:08 +0100

Daniel,
please see inline comments,

> in our document. Also, others (64-bits full IPv6 address) are open...

tc: Yes I also agree about the need to reduce traffic amounts over 6lowpan
network, however I think interesting to introduce this capability so we can
indicate to the lowpan node who is requesting, I see two options to do this,
(please note both options use/can use 16-bit addresses)
   - A new pair of messages, where the lowpan node after received the a request
can ask to the gateway, who was the source of such a query/request;
   - A new option that the gateway can add to the first message sent to the
lowpan node, where it can describe the IPv6 address or the 64-bit address.

> needs AAA in its scenarions. It's also controversial issue.

tc: I see one very important issue concerning authorization, because if no
method is used, one can requesting infinity the lowpan network, which will
reduce dramatic the energy levels..
 
> our face-to-face meeting...
 
tc: OK we should do it. Unfortunately, I wasn’t able to attend the Monday
meeting, so my apologies if this points were already discussed yesterday.

Regard,
Tiago Camilo
University of Coimbra