As far as I know, nobody's approached 802.15.4 about this. I have worded it
as additional constraints beyond 802.15.4 for 6lowpan operation.
-gabriel
as additional constraints beyond 802.15.4 for 6lowpan operation.
-gabriel
----- Original Message ----
From: Samita Chakrabarti <[EMAIL PROTECTED]>
To: gabriel montenegro <[EMAIL PROTECTED]>
Cc: Carsten Bormann <[EMAIL PROTECTED]>; [email protected]
Sent: Saturday, June 24, 2006 4:15:40 PM
Subject: Re: [6lowpan] 6lowpan 16-bit address space map
From: Samita Chakrabarti <[EMAIL PROTECTED]>
To: gabriel montenegro <[EMAIL PROTECTED]>
Cc: Carsten Bormann <[EMAIL PROTECTED]>; [email protected]
Sent: Saturday, June 24, 2006 4:15:40 PM
Subject: Re: [6lowpan] 6lowpan 16-bit address space map
Gabriel/Carsten:
Are the suggested 16bit MAC addresses only meant for 6lowpan usage?
Or they would be blessed by IEEE standards for 802.15.4 devices?
Thanks,
-Samita
On 6/24/06, gabriel montenegro <[EMAIL PROTECTED]> wrote:
>
>
> I've added a much simpler version, only mentioning those fields we are
> specifying in the document.
> Anything not currently specified can be defined later, right now the
> important thing is to reserve the
> relevant space.
>
> I include below the IANA section on 16-bit address format, as it currently
> looks.
>
> -gabriel
> ps - currently on vacation and with spotty email connectivity, but I'll be
> submitting this before the deadline.
> This document creates a new IANA registry for the 16-bit short
> address fields used in 6LoWPAN packets.
>
> 0 1
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
| 16-bit short Address |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> Figure 11
>
> These address fields MUST follow this format (referring to bit fields
> in the order from 0 to 7):
>
> O: The first bit SHALL be zero if the 16-bit address is a non-
> multicast (e.g., unicast) address. This leaves 15 bits for the
> actual address.
>
> 100: Bits 0,1 and 2 SHALL follow this pattern if the 16-bit address
> is a multicast address. This leaves 13 bits for the actual
> multicast address.
>
> 101, 110 or 111: These patterns for bits 0,1 and 2 are reserved. for
> future assignment as per the policy mentioned above.
>
>
> ----- Original Message ----
> From: Carsten Bormann <[EMAIL PROTECTED]>
> To: [email protected]
> Cc: Carsten Bormann <[EMAIL PROTECTED]>
> Sent: Friday, April 21, 2006 11:40:52 AM
> Subject: [6lowpan] 6lowpan 16-bit address space map
>
> Lowpanners,
>
> here is a more detailed idea of how the addressing map for 16-bit
> addresses could look like. Comments welcome.
>
> 0xxxxxxxxxxxxxxx unicast addresses allocated by the PAN coordinator
> 100xxxxxxxxxxxxx special unicast addresses, e.g.
> 1000000000000000 PAN coordinator
> 1000000000000001 backup PAN coordinator (just making this up now)
> allocation requires standards action
> 101xxxxxxxxxxxxx reserved (allocation requires standards action)
> 110xxxxxxxxxxxxx multicast addresses (mapping per format document)
> 111xxxxxxxxxxxxx special addresses, often multicast, e.g.
> 1111111111111110 (the 0xfffe thing from 802.15.4)
> 1111111111111111 radio-range-limited localcast to non-sleepers
> allocation requires standards action
>
> I'm not so sure about using 100xxxxxxxxxxxxx for the PAN coordinator
> things etc; maybe we should use 111xxxxxxxxxxxxx for all "special"
> addresses to have more contiguous space reserved for future use.
>
> Gruesse, Carsten
>
>
> _______________________________________________
> 6lowpan mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/6lowpan
>
>
> _______________________________________________
> 6lowpan mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/6lowpan
>
>
>
Are the suggested 16bit MAC addresses only meant for 6lowpan usage?
Or they would be blessed by IEEE standards for 802.15.4 devices?
Thanks,
-Samita
On 6/24/06, gabriel montenegro <[EMAIL PROTECTED]> wrote:
>
>
> I've added a much simpler version, only mentioning those fields we are
> specifying in the document.
> Anything not currently specified can be defined later, right now the
> important thing is to reserve the
> relevant space.
>
> I include below the IANA section on 16-bit address format, as it currently
> looks.
>
> -gabriel
> ps - currently on vacation and with spotty email connectivity, but I'll be
> submitting this before the deadline.
> This document creates a new IANA registry for the 16-bit short
> address fields used in 6LoWPAN packets.
>
> 0 1
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
| 16-bit short Address |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> Figure 11
>
> These address fields MUST follow this format (referring to bit fields
> in the order from 0 to 7):
>
> O: The first bit SHALL be zero if the 16-bit address is a non-
> multicast (e.g., unicast) address. This leaves 15 bits for the
> actual address.
>
> 100: Bits 0,1 and 2 SHALL follow this pattern if the 16-bit address
> is a multicast address. This leaves 13 bits for the actual
> multicast address.
>
> 101, 110 or 111: These patterns for bits 0,1 and 2 are reserved. for
> future assignment as per the policy mentioned above.
>
>
> ----- Original Message ----
> From: Carsten Bormann <[EMAIL PROTECTED]>
> To: [email protected]
> Cc: Carsten Bormann <[EMAIL PROTECTED]>
> Sent: Friday, April 21, 2006 11:40:52 AM
> Subject: [6lowpan] 6lowpan 16-bit address space map
>
> Lowpanners,
>
> here is a more detailed idea of how the addressing map for 16-bit
> addresses could look like. Comments welcome.
>
> 0xxxxxxxxxxxxxxx unicast addresses allocated by the PAN coordinator
> 100xxxxxxxxxxxxx special unicast addresses, e.g.
> 1000000000000000 PAN coordinator
> 1000000000000001 backup PAN coordinator (just making this up now)
> allocation requires standards action
> 101xxxxxxxxxxxxx reserved (allocation requires standards action)
> 110xxxxxxxxxxxxx multicast addresses (mapping per format document)
> 111xxxxxxxxxxxxx special addresses, often multicast, e.g.
> 1111111111111110 (the 0xfffe thing from 802.15.4)
> 1111111111111111 radio-range-limited localcast to non-sleepers
> allocation requires standards action
>
> I'm not so sure about using 100xxxxxxxxxxxxx for the PAN coordinator
> things etc; maybe we should use 111xxxxxxxxxxxxx for all "special"
> addresses to have more contiguous space reserved for future use.
>
> Gruesse, Carsten
>
>
> _______________________________________________
> 6lowpan mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/6lowpan
>
>
> _______________________________________________
> 6lowpan mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/6lowpan
>
>
>
_______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
