Subject: I-D Action: draft-ietf-6man-6lobac-01.txt

From: [email-masked]
Date: Mon, 12 Mar 2012 10:06:44 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

	Title           : Transmission of IPv6 over MS/TP Networks
	Author(s)       : Kerry Lynn
                          Jerry Martocci
                          Carl Neilson
                          Stuart Donaldson
	Filename        : draft-ietf-6man-6lobac-01.txt
	Pages           : 20
	Date            : 2012-03-12

   MS/TP (Master-Slave/Token-Passing) is a contention-free access method
   for the RS-485 physical layer that is used extensively in building
   automation networks.  This document describes the frame format for
   transmission of IPv6 packets and the method of forming link-local and
   statelessly autoconfigured IPv6 addresses on MS/TP networks.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-6lobac-01.txt

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 13 Mar 2012 07:47:55 -0400

Greetings,

The main changes to the WG version of this draft are: a) tweaks that
resulted from the initial public review of the BACnet MS/TP change
proposal, the most significant being the COBS encoding of data and
data crc fields to remove preamble sequences; and b) addition of
two informative appendices to provide code examples for the data
crc and COBS encoder/decoder.  These appendices are insufficient
to implement the data link, but are provided e.g. for those writing
Wireshark dissectors or otherwise wanting more detail about over-
the-wire format.

I'd like to solicit specific comments on what is needed to move this
draft forward - IOW, what would you like to see added in order for
this draft to be ready for WGLC?

For anyone who'd like to view the details of data link state machines,
etc., I can provide the relevant clause (9) of the ASHRAE 135-2010
(BACnet) spec, as well as the MS/TP change proposal (Addendum
an).

Thanks, -K-

On Mon, Mar 12, 2012 at 1:06 PM,  <[email-masked]> wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 Mar 2012 18:54:21 +0100

HEllo,

A side note about this.  It is not a request for modification, just a
thought.

I wonder why do we want the Interface Identifier to be of length 64 when
the MS/TP node address seems to be 8bit only.

In a sense, it may be because SLAAC over Ethernet (802) is used to use
64bit IIDs.

But in another sense, this is not Ethernet and hence the IID could be of
length 8bit of MS/TP, right?

I am asking this because of other contexts (non-MS/TP) whereby the
link-layer addresses are shorter than 48bit and yet the Interface ID is
still 64bit, "to make SLAAC work".

In some contexts too, the ISP delivers a 64bit prefix to a leaf network
and if that IID is almost always 64bit it means that it's hard next to
impossible to form sub-prefixes of that ISP 64bit prefix and still use
SLAAC.

In a sense, it would be better to define the IIDs of MS/TP (or other
link) to be of length 8, allow the ISP to assign 64bit prefix to leaf
network, and let the gateway in between to derive prefixes out of that
64bit (up to 120) and still use SLAAC.

This is just a thought, not a request to modify.

Yours,

Alex

Le 13/03/2012 12:47, Kerry Lynn a écrit :
> data crc fields to remove preamble sequences; and b) addition of two
> informative appendices to provide code examples for the data crc and
> COBS encoder/decoder.  These appendices are insufficient to implement
> the data link, but are provided e.g. for those writing Wireshark
> dissectors or otherwise wanting more detail about over- the-wire
> format.
>
> For anyone who'd like to view the details of data link state
> machines, etc., I can provide the relevant clause (9) of the ASHRAE
> 135-2010 (BACnet) spec, as well as the MS/TP change proposal
> (Addendum an).
>
> Thanks, -K-
>
>
> On Mon, Mar 12, 2012 at 1:06 PM,<[email-masked]>  wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the IPv6 Maintenance
>> Working Group of the IETF.
>>
>> Author(s)       : Kerry Lynn Jerry Martocci Carl Neilson Stuart
>> Donaldson Filename        : draft-ietf-6man-6lobac-01.txt Pages
>> : 20 Date            : 2012-03-12
>>
>> MS/TP (Master-Slave/Token-Passing) is a contention-free access
>> method for the RS-485 physical layer that is used extensively in
>> building automation networks.  This document describes the frame
>> format for transmission of IPv6 packets and the method of forming
>> link-local and statelessly autoconfigured IPv6 addresses on MS/TP
>> networks.
>>
>>
>> [email-masked] Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 13 Mar 2012 14:51:32 -0400

Hi Alex,

Thanks for your comment.

I was following the method of generating IIDs used by 6LoWPAN [RFC 4944].

I note that RFC 4291 states in section 2.5.1
"For all unicast addresses, except those that start with the binary value
000, Interface IDs are required to be 64 bits long and to be constructed
in Modified EUI-64 format."

Technically, locally assigned MS/TP IIDs could be shorter than 64 bits.
However, if EUI-64s become popular for MS/TP devices there might
then be a situation where some devices have 64-bit IIDs and others have
shorter.  I am also not sure how a numbering scheme that uses prefixes
longer than 64 bits would work in the general case (given that many
other data links use 64-bit IIDs).

-K-

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 29 Mar 2012 15:49:12 +0200

Le 13/03/2012 19:51, Kerry Lynn a écrit :
> I note that RFC 4291 states in section 2.5.1 "For all unicast
> addresses, except those that start with the binary value 000,
> Interface IDs are required to be 64 bits long and to be constructed

That would mean that addresses prefixed by 000 (instead of 001) could
have interface ids with lengths larger than 64, no?

That RFC says "There are a number of types of links that have link-layer
interface identifiers other than IEEE EUI-64 or IEEE 802 48-bit MACs.
Examples include LocalTalk and Arcnet."

Is MS/TP a link with IEEE tag on it now or in the future?

(if not then one would be free to have Interface IDs wiht lengths
shorter than 64 and thus maybe with an easier to implement one-to-one
mapping between the link address and the IP address).

> Technically, locally assigned MS/TP IIDs could be shorter than 64
> bits. However, if EUI-64s become popular for MS/TP devices there
> might then be a situation where some devices have 64-bit IIDs and
> others have shorter.

Yes, I listen to that.  I do not know about that tendency, maybe you see
whether EUI-64s are becoming popular for MS/TP.

> I am also not sure how a numbering scheme that uses prefixes longer
> than 64 bits would work in the general case (given that many other
> data links use 64-bit IIDs).

I believe it may work with DHCP and RAs.  Off of the top of my head I'd
say that implementations don't impose this prefix length max 64 for
assigned prefix, or for interface identifier.

Alex

>> A side note about this.  It is not a request for modification,
>> just a thought.
>>
>> I wonder why do we want the Interface Identifier to be of length
>> 64 when the MS/TP node address seems to be 8bit only.
>>
>> In a sense, it may be because SLAAC over Ethernet (802) is used to
>> use 64bit IIDs.
>>
>> But in another sense, this is not Ethernet and hence the IID could
>> be of length 8bit of MS/TP, right?
>>
>>  link-layer addresses are shorter than 48bit and yet the Interface
>> ID is still 64bit, "to make SLAAC work".
>>
>> In some contexts too, the ISP delivers a 64bit prefix to a leaf
>> network and if that IID is almost always 64bit it means that it's
>> hard next to impossible to form sub-prefixes of that ISP 64bit
>> prefix and still use SLAAC.
>>
>> In a sense, it would be better to define the IIDs of MS/TP (or
>> other link) to be of length 8, allow the ISP to assign 64bit
>> prefix to leaf network, and let the gateway in between to derive
>> prefixes out of that 64bit (up to 120) and still use SLAAC.
>>
>>> The main changes to the WG version of this draft are: a) tweaks
>>> that resulted from the initial public review of the BACnet MS/TP
>>> change proposal, the most significant being the COBS encoding of
>>> data and data crc fields to remove preamble sequences; and b)
>>> addition of two informative appendices to provide code examples
>>> for the data crc and COBS encoder/decoder.  These appendices are
>>> insufficient to implement the data link, but are provided e.g.
>>> for those writing Wireshark dissectors or otherwise wanting more
>>> detail about over- the-wire format.
>>>
>>> I'd like to solicit specific comments on what is needed to move
>>> this draft forward - IOW, what would you like to see added in
>>> order for this draft to be ready for WGLC?
>>>
>>> machines, etc., I can provide the relevant clause (9) of the
>>> ASHRAE 135-2010 (BACnet) spec, as well as the MS/TP change
>>> proposal (Addendum an).
>>>
>>> Thanks, -K-
>>>
>>>
>>>> A New Internet-Draft is available from the on-line
>>>> Internet-Drafts directories. This draft is a work item of the
>>>> IPv6 Maintenance Working Group of the IETF.
>>>>
>>>>  method for the RS-485 physical layer that is used extensively
>>>> in building automation networks.  This document describes the
>>>> frame format for transmission of IPv6 packets and the method
>>>> of forming link-local and statelessly autoconfigured IPv6
>>>> addresses on MS/TP networks.
>>>>
>>>>