Pascal, Makes sense.
I'm taking as an example the DAO from 3->2 from https://tools.ietf.org/html/draft-munoz-6tisch-examples-02#page-15. The Join Request will have the same header format for IEEE802.15.4 and 6LoWPAN. Here is a before/after comparison of adding the traffic class bits by hand, diff in *red*. Can you confirm that's the right format? >From https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml, I get that the 6b DSCP space is mapped to: - class service (CS) 1-7 - assured forwarding (AF) 11-43 - expedited forwarding (EF) - VOICE-ADMIT Our job at 6TiSCH would then to map join request/response traffic to a CS which we define as "forward, but don't take into account for adding/deleting cells". We would also map other traffic to another CS, leaving space for future extensions (SFs) which would use high CS number to guarantee latencies. Thoughts welcome, Thomas *BEFORE* (no traffic class) IEEE 802.15.4 Data, Dst: 14:15:92:cc:00:00:00:02, Src: 14:15:92:cc:00:00:00:03 Frame Control Field: 0xec21, Frame Type: Data .... .... .... .001 = Frame Type: Data (0x0001) .... .... .... 0... = Security Enabled: False .... .... ...0 .... = Frame Pending: False .... .... ..1. .... = Acknowledge Request: True .... .... .0.. .... = Intra-PAN: False .... ...0 .... .... = Sequence Number Suppression: False .... ..0. .... .... = Information Elements present: False .... 11.. .... .... = Destination Addressing Mode: Long/64-bit (0x0003) ..10 .... .... .... = Frame Version: 2 11.. .... .... .... = Source Addressing Mode: Long/64-bit (0x0003) Sequence Number: 5 Destination PAN: 0xcafe Destination: 14:15:92:cc:00:00:00:02 (14:15:92:cc:00:00:00:02) Extended Source: 14:15:92:cc:00:00:00:03 (14:15:92:cc:00:00:00:03) FCS: 0x1640 (Correct) 6LoWPAN .... 0001 = Page Number: 1 6LoRH: Routing Protocol Information 100. .... = Routing Header 6lo: Critical Routing Header (0x04) ...0 .... .... .... = Packet direction: UP false, DOWN true: False .... 0... .... .... = Error detected: False .... .0.. .... .... = No link to destination: False .... ..1. .... .... = Context identifier extension: True .... ...1 .... .... = Context identifier extension: True .... .... 0000 0101 = 6loRH Type: Routing Protocol Information RPL Instance: 0x00 Sender Rank: 0x21 IPHC Header 011. .... = Pattern: IP header compression (0x03) ...1 1... .... .... = Traffic class and flow label: Version, traffic class, and flow label compressed (0x0003) .... .0.. .... .... = Next header: Inline .... ..10 .... .... = Hop limit: 64 (0x0002) .... .... 0... .... = Context identifier extension: False .... .... .0.. .... = Source address compression: Stateless .... .... ..01 .... = Source address mode: 64-bits inline(0x01) .... .... .... 0... = Multicast address compression: False .... .... .... .0.. = Dest address compression: Stateless .... .... .... ..01 = Dest address mode: 64-bits inline (0x01) [Source context: fe80::] [Destination context: fe80::] Next header: ICMPv6 (0x3a) Source: fe80::1415:92cc:0:3 Destination: fe80::1415:92cc:0:1 Internet Protocol Version 6, Src: fe80::1415:92cc:0:3, Dst: fe80::1415:92cc:0:1 0110 .... = Version: 6 .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00 (DSCP: CS0, ECN: Not-ECT) .... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0) .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0) .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000 Payload length: 46 Next header: ICMPv6 (58) Hop limit: 64 Source: fe80::1415:92cc:0:3 Destination: fe80::1415:92cc:0:1 Internet Control Message Protocol v6 Type: RPL Control (155) Code: 2 (Destination Advertisement Object) Checksum: 0xd31a [incorrect, should be 0x4d90] RPLInstanceID: 0 Flags: 0x40 0... .... = DAO-ACK Request (K): False .1.. .... = DODAGID Present (D): True ..00 0000 = Reserved: 0 Reserved: 00 DAO Sequence: 0 DODAGID: bbbb::1415:92cc:0:1 ICMPv6 RPL Option (Transit Information bbbb::1415:92cc:0:2) Type: Transit Information (6) Length: 20 Flags: 0x00 0... .... = External: Not set .000 0000 = Reserved: 0 Path Control: 0 Path Sequence: 0 Path Lifetime: 170 Parent Address: bbbb::1415:92cc:0:2 *AFTER* (with traffic class) IEEE 802.15.4 Data, Dst: 14:15:92:cc:00:00:00:02, Src: 14:15:92:cc:00:00:00:03 Frame Control Field: 0xec21, Frame Type: Data .... .... .... .001 = Frame Type: Data (0x0001) .... .... .... 0... = Security Enabled: False .... .... ...0 .... = Frame Pending: False .... .... ..1. .... = Acknowledge Request: True .... .... .0.. .... = Intra-PAN: False .... ...0 .... .... = Sequence Number Suppression: False .... ..0. .... .... = Information Elements present: False .... 11.. .... .... = Destination Addressing Mode: Long/64-bit (0x0003) ..10 .... .... .... = Frame Version: 2 11.. .... .... .... = Source Addressing Mode: Long/64-bit (0x0003) Sequence Number: 5 Destination PAN: 0xcafe Destination: 14:15:92:cc:00:00:00:02 (14:15:92:cc:00:00:00:02) Extended Source: 14:15:92:cc:00:00:00:03 (14:15:92:cc:00:00:00:03) FCS: 0x1640 (Correct) 6LoWPAN .... 0001 = Page Number: 1 6LoRH: Routing Protocol Information 100. .... = Routing Header 6lo: Critical Routing Header (0x04) ...0 .... .... .... = Packet direction: UP false, DOWN true: False .... 0... .... .... = Error detected: False .... .0.. .... .... = No link to destination: False .... ..1. .... .... = Context identifier extension: True .... ...1 .... .... = Context identifier extension: True .... .... 0000 0101 = 6loRH Type: Routing Protocol Information RPL Instance: 0x00 Sender Rank: 0x21 IPHC Header 011. .... = Pattern: IP header compression (0x03) * ...1 0... .... .... = ECN + DSCP (1 byte), Flow Label is elided.* .... .0.. .... .... = Next header: Inline .... ..10 .... .... = Hop limit: 64 (0x0002) .... .... 0... .... = Context identifier extension: False .... .... .0.. .... = Source address compression: Stateless .... .... ..01 .... = Source address mode: 64-bits inline(0x01) .... .... .... 0... = Multicast address compression: False .... .... .... .0.. = Dest address compression: Stateless .... .... .... ..01 = Dest address mode: 64-bits inline (0x01) [Source context: fe80::] [Destination context: fe80::] * Traffic Class: TBD (0x??) [1 byte]* Next header: ICMPv6 (0x3a) Source: fe80::1415:92cc:0:3 Destination: fe80::1415:92cc:0:1 Internet Protocol Version 6, Src: fe80::1415:92cc:0:3, Dst: fe80::1415:92cc:0:1 0110 .... = Version: 6 .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00 (DSCP: CS0, ECN: Not-ECT) .... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0) .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0) .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000 Payload length: 46 Next header: ICMPv6 (58) Hop limit: 64 Source: fe80::1415:92cc:0:3 Destination: fe80::1415:92cc:0:1 Internet Control Message Protocol v6 Type: RPL Control (155) Code: 2 (Destination Advertisement Object) Checksum: 0xd31a [incorrect, should be 0x4d90] RPLInstanceID: 0 Flags: 0x40 0... .... = DAO-ACK Request (K): False .1.. .... = DODAGID Present (D): True ..00 0000 = Reserved: 0 Reserved: 00 DAO Sequence: 0 DODAGID: bbbb::1415:92cc:0:1 ICMPv6 RPL Option (Transit Information bbbb::1415:92cc:0:2) Type: Transit Information (6) Length: 20 Flags: 0x00 0... .... = External: Not set .000 0000 = Reserved: 0 Path Control: 0 Path Sequence: 0 Path Lifetime: 170 Parent Address: bbbb::1415:92cc:0:2 On Sun, Nov 12, 2017 at 8:54 AM, Pascal Thubert (pthubert) < [email protected]> wrote: > Hello Thomas > > > > For what I see: > > We need to specify that with 6LoRH IP in IP, the TOS bits are in the inner > (RFC6282) packet. > > It will cost one octet in RFC 6282 encoding https://tools.ietf.org/html/ > rfc6282#section-3.2.1 > > 0 1 2 3 4 5 6 7 > > +-+-+-+-+-+-+-+-+ > > |ECN| DSCP | > > +-+-+-+-+-+-+-+-+ > > > > Figure 6: TF = 10: Traffic Class carried in-line > > > > We need to specify (ranges of) traffic classes and how they are used by > mSF, which are ignored (e.g. CSx in https://www.iana.org/ > assignments/dscp-registry/dscp-registry.xhtml), which are taken seriously > or over seriously. > > We have to specify which traffic class we use in the join (e.g. CS1), and > it must match mSF spec ignored. > > > > Make sense? > > > > Pascal > > > > *From:* Thomas Watteyne [mailto:[email protected]] > *Sent:* dimanche 12 novembre 2017 08:33 > *To:* Pascal Thubert (pthubert) <[email protected]> > *Cc:* Michael Richardson <[email protected]>; 6tisch <[email protected]>; > Mališa Vučinić <[email protected]> > *Subject:* Re: [6tisch] Tagging join traffic > > > > Pascal, > > > > Thanks for the input. Trying to evaluate the overhead of using the traffic > class bits. I assume we want to have one dedicated traffic class for the > join request/reply, which tells nodes NOT to take that traffic into account > for deciding whether to add cells. > > > > - what must be standardized, if anything? > > - what would a join request now look like, and what's the hit in terms of > byte count? > > > > Thomas > > > > > > On Thu, Nov 9, 2017 at 9:31 AM, Pascal Thubert (pthubert) < > [email protected]> wrote: > > I do > > > > Digging in the packet even with nice names like DPI is a layer violation. > It breaks the e2e principle so that if we add something to the end points > the join message may become unreadable by the dpi. The art of the IETF > translates upper layer semantics in lower layer abstraction and in this > case we have the TOS bits. RFC 6282 allows to express those in a concise > fashion. 6LoRH does not and if IP in IP is used the TOS bits of the inner > packet must be used.... > > > > Regards, > > > > Pascal > > > Le 8 nov. 2017 à 23:42, Thomas Watteyne <[email protected]> a > écrit : > > Thanks Michael. > > > > Does everyone agree with Michael's comments? > > > > On Wed, Nov 8, 2017 at 8:12 PM, Michael Richardson <[email protected]> > wrote: > > > Thomas Watteyne <[email protected]> wrote: > > option 1: we don't change the format of the packet, and ask > forwarding > > nodes to (deep) inspect the packets, looking for the CoAP > > Stateless-Proxy option. > > It's specific to this join process, and is expensive to do. > > > option 2: we change the packet format, and > > introduce semantics in the traffic class bits in the IPv6 header > > It's general to many things. > > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > > -- > > _______________________________________ > > > > Thomas Watteyne, PhD > > Research Scientist & Innovator, Inria > > Sr Networking Design Eng, Linear Tech > > Founder & co-lead, UC Berkeley OpenWSN > > Co-chair, IETF 6TiSCH > > > > www.thomaswatteyne.com > > _______________________________________ > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > > > > > -- > > _______________________________________ > > > > Thomas Watteyne, PhD > > Research Scientist & Innovator, Inria > > Sr Networking Design Eng, Linear Tech > > Founder & co-lead, UC Berkeley OpenWSN > > Co-chair, IETF 6TiSCH > > > > www.thomaswatteyne.com > > _______________________________________ > -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
