1 / 86

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [ 6TiSCH Overview & Status ] Date Submitted: [ 18 September 2014 ” ] Source: [ Pascal Thubert ] Company [ Cisco Systems ]

kacy
Télécharger la présentation

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [6TiSCH Overview & Status] Date Submitted: [18 September 2014”] Source: [Pascal Thubert] Company [Cisco Systems] Address [Building D (Regus) 45 Allee des Ormes - BP1200 06254 MOUGINS cedex France ] Voice:[+33 6 1998 2985], FAX: [pdf =>], E-Mail:[pthubert@cisco.com] Re: [IG 6tisch.] Abstract: [Latest news from 6TiSCH and current issues being worked on] Purpose: [Liaison Work. Ideas and Contributions welcome!] Notice: This document has been prepared to assist the IEEE P802.15. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15. <Pascal Thubert>, <Cisco>

  2. IPv6 over the TSCH mode of IEEE 802.15.4e Chairs: Pascal Thubert Thomas Watteyne Mailing list: 6tisch@ietf.org <Pascal Thubert>, <Cisco>

  3. Motivation for 6LoWPAN? • IPv6 to the end node however small • IETF WG formed in March 2005 • Chartered for IPv6 over LoWPAN (802.15.4) • Now closed, replaced by 6lo • Defined: • Header Compression (HC) RFC 4944 and RFC 6282 • Fragmentation and mesh header (mostly unused) • Registration-based IPv6 Neighbor Discovery (ND) RFC 6775 <Pascal Thubert>, <Cisco>

  4. How does 6LoWPAN compare to Zigbee & al. ? • Standards such as Zigbee(IP), ISA100.11a and WirelessHART all define whole stacks and application profiles whereas 6LoWPAN is (just) an adaptation layer for IP (version 6) • ISA100.11a incorporates 6LoWPAN Header Compression (HC) • ZigbeeIP incorporates 6LoWPAN HC & Neighbor Discovery (ND) • Yet 6LoWPAN marks the transition for WSN towards IP • So the popular image is that 6LoWPAN means IP in sensors • 6LoWPAN failed to deliver routing. ROLL WG took over with RPL <Pascal Thubert>, <Cisco>

  5. What’s missing now ? • Generalize to all technologies, provide generic abstraction • 6lo now chartered to define IPv6 over IOT Links • Current work on: • 6lo also handles 6LoWPAN maintenance e.g. as stimulated by 6TiSCH to improve 6LoWPAN - RPL interworking http://tools.ietf.org/html/draft-ietf-6lo-btle http://tools.ietf.org/html/draft-ietf-6lo-dect-ule http://tools.ietf.org/html/draft-brandt-6man-lowpanz http://tools.ietf.org/html/draft-hong-6lo-ipv6-over-nfc http://tools.ietf.org/html/draft-ietf-6lo-6lobac http://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer Bluetooth Low Energy DECT Ultra Low Energy Zwave Near Field Comms BACNET 802.15.4e TSCH <Pascal Thubert>, <Cisco>

  6. What about 6TiSCH ? • 6TiSCH also specifies an IPv6-over-foo for 802.15.4e TSCH • but does not update 6LoWPAN (that’s pushed to 6lo). • Rather 6TiSCH defines the missing Data Link Layer. • The 6TiSCH architecture defines the global Layer-3 operation. • It incorporates 6LoWPAN but also RPL, DetNet (PCE), COMAN, SACM, CoAP, DICE … • Thus 6TiSCH has to make those components work together • E.g. of work being pushed to other WGs: http://tools.ietf.org/html/draft-thubert-6man-flow-label-for-rpl http://tools.ietf.org/html/draft-thubert-6lo-forwarding-fragments http://tools.ietf.org/html/draft-thubert-6lo-rfc6775-update-reqs <Pascal Thubert>, <Cisco>

  7. Milestones 12/2013 - WG to adopt 6TiSCH terminology 12/2013 - WG to adopt IEEE802.15.4e TSCH overview 12/2013 - WG to adopt 6TiSCH architecture 12/2013 - WG to adopt 6TiSCH minimal configuration 04/2014 - WG to adopt 6top draft(s) 04/2014 - WG to adopt 6TiSCH data model for CoAP 08/2014 - Submit YANG data model in 6top draft for preliminary OPSDIR review 08/2014 - Submit 6TiSCH architecture for preliminary SECDIR review 11/2014 - Initial submission of 6TiSCH minimal configuration to the IESG 11/2014 - Initial submission of 6top draft(s) to the IESG 11/2014 - Initial submission of 6TiSCH data model for CoAP to the IESG 12/2014 - Initial submission of 6TiSCH terminology to the IESG 12/2014 - Initial submission of 6TiSCH architecture to the IESG 12/2014 - Evaluate WG progress, propose new charter to the IESG 06/2015 - 6TiSCH Minimal and 6top draft(s) in RFC publication queue 12/2015 - 6TiSCH architecture and terminology in RFC publication queue <Pascal Thubert>, <Cisco>

  8. draft-ietf-6tisch-terminology-02 Maria Rita Palattella (Ed.)Pascal ThubertThomas WatteyneQin Wang <Pascal Thubert>, <Cisco>

  9. Chunks A Chunk is a well-known list of cells, well-distributed in time and frequency, within the CDU matrix; a chunk represents a portion of the CDU. The partition of the CDU in chunks is globally known by all the nodes in the network to support the appropriation process, which is a negotiation between nodes within an interference domain. A node that manages to appropriate a chunk gets to decide which transmissions will occur over the cells in the chunk within its interference domain. Ultimately, a chunk represents some amount of bandwidth and can be seen as the generalization of a transmission channel in the time/frequency domain. Chunk 1 Chunk 2 ... Chunk 9 CDU matrix, 7 channels, 7 timeslots, 9 chunks, represented from ASN= 0 draft-ietf-6tisch-terminology-02 14 <Pascal Thubert>, <Cisco>

  10. Chunk usage 13 11 12 22 23 24 25 33 34 35 31 32 46 42 41 44 45 43 draft-ietf-6tisch-terminology-02 15 <Pascal Thubert>, <Cisco>

  11. Schedule The RPL parent allocates timeslots between itself and its children. The parent takes the timeslots off a chunk that it has appropriated. Slotframe Say a parent appropriates the pink chunk from the CDU matrix above. Now the parent gets to decide when the pink cells are used and by which node. A device maintains a schedule that dictates its transmissions and receptions inside the slotframe. Parent schedule Child 1 schedule Child 2 schedule Child 3 schedule draft-ietf-6tisch-terminology-02 16 <Pascal Thubert>, <Cisco>

  12. 6TiSCH finally defines the peer-wise concept of a bundle, that is needed for the communication between adjacent nodes. A Bundle is a group of equivalent scheduled cells, i.e. cells identified by different [slotOffset, channelOffset], which are scheduled for a same purpose (a Track, a Link), with the same neighbor and overall properties. The size of the bundle refers to the number of cells it contains. Given the length of the slotframe, the size of the bundle translates directly into bandwidth. Ultimately a bundle represent a half-duplex link between nodes, one transmitter and one or more receivers, with a bandwidth that amount to the sum of the timeslots in the bundle. Bundles thus come as the pair of an incoming and an outgoing bundle, that is associated to either a (L3) Link or a (L2) Track. A bundle is globally identified by (source MAC, destination MAC, trackID) Bundle timeslot bundle draft-ietf-6tisch-terminology-02 17 <Pascal Thubert>, <Cisco>

  13. Bundle pair for a (L3) Link We use a well-known constant  as trackId for a L3 link, that I’ll refer as NULLT. So an IP link between adjacent nodes A and B comprises 2 bundles, (macA, macB, NULLT) and (macB, macA, NULLT). IP layer B TX-cell RX-cell bundle bundle Incoming outgoing A A draft-ietf-6tisch-terminology-02 18 <Pascal Thubert>, <Cisco>

  14. Bundle pair for a (L2) Track Along a track that has a segment …A->B->C… , there are 2 bundles in node B, incoming = (macA, macB, trackId) and outgoing = (macB, macC, trackId). B TX-cell RX-cell bundle bundle Incoming outgoing A C draft-ietf-6tisch-terminology-02 19 <Pascal Thubert>, <Cisco>

  15. draft-ietf-6tisch-architecture-03 Pascal Thubert (Ed.)Thomas WatteyneRobert Assimiti <Pascal Thubert>, <Cisco>

  16. Issue 19 21 draft-ietf-6tisch-architecture-03 <Pascal Thubert>, <Cisco>

  17. Track Management 22 draft-ietf-6tisch-architecture-03 <Pascal Thubert>, <Cisco>

  18. Normal L3 operation shaping QoS RED Packets are serialized U A 1RX 1TX X Y 1+1 TX B V 1RX 1TX 23 draft-ietf-6tisch-architecture-03 <Pascal Thubert>, <Cisco>

  19. Normal Trackoperation DSCP Deterministic (packet delivered at determined time) Dest MAC not changed DSCP set to Deterministic Dest MAC set to 0xFFFF U A 1RX 1TX Dest MAC restored by 6top at final destination X Y 2TX 2RX B V 1TX 1RX 24 draft-ietf-6tisch-architecture-03 <Pascal Thubert>, <Cisco>

  20. (Existing) Opportunistictrack slot reuse DSCP not Deterministic Dest MAC set to X No frame in slot Associated to deterministic P Packet to be routed via Y Dest MAC set to Y Placed of deterministic track U A 1RX 1TX Dest MAC restored by 6top X Y 2TX 2RX B V Packet extracted from track due to dmac == Y and/or DSCP and then routed to a next hop != V 1TX 1RX Q 25 draft-ietf-6tisch-architecture-03 <Pascal Thubert>, <Cisco>

  21. (New) Retrackingafterrecovery If arrival in time Dest MAC reset to broadcast 0xFFFF DSCP Deterministic Placed back on track Dest MAC set to broadcast 0xFFFF DSCP Deterministic Transmission failure Over track slots Retries exhausted over Track L2 bundle U A 2TX 2RX 1RX 1TX X Y 1TX 1RX B V Additional retries Using L3 bundle Dest MAC set to Y DSCP Deterministic 1TX 1RX 26 <Pascal Thubert>, <Cisco> draft-ietf-6tisch-architecture-03

  22. draft-ietf-6tisch-minimal-02 Xavi Vilajosana (Ed.)Kris Pister 27 <Pascal Thubert>, <Cisco>

  23. Status • Status: • Adopted at IETF88 Vancouver • Latest version (02) published on 4 July 2014https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/ • Changes since IETF89 • Redefined slotframe length • Redefined number of active cells • Redefined timeslot length • Added Requirement for Timeslot IE and Ch.Hopping IE in EB 28 draft-ietf-6tisch-minimal-02 <Pascal Thubert>, <Cisco>

  24. Slotframe Before 101 time slots slotframe (fixed size) 6 active cells (1EB, 5 Slotted Aloha) Problems Not flexible Possibly notenoughbandwidth draft-ietf-6tisch-minimal-02 <Pascal Thubert>, <Cisco>

  25. Slotframe • Now • Variable number of time slots in the slotframe • 1 active cells (EB and Data in the same cell) • Active Cell LinkOption and LinkType • DATA (not BEACON), Rx, Tx, Shared • TimeKeeping flag never set. • Time source neighbor is selected using the DODAG structure of the network • Pros • More flexible • Duty cycle can be tuned draft-ietf-6tisch-minimal-02 <Pascal Thubert>, <Cisco>

  26. Slotframe draft-ietf-6tisch-minimal-02 <Pascal Thubert>, <Cisco>

  27. Timeslot • Before: 15ms MUST aiming to support old platforms • Now: 10ms RECOMMENDATION (not a MUST) • Using IEEE802.15.4e-2012 default timeslot template (timing) • MUST use TimeSlot IE only using 1B payload to send default timeslot template Id. • Other configurations supported • MUST use EB and TimeSlot IE to announce slot timing. 25B payload required at each EB • Recommendation to use power of 2 multiples of the default timeslot duration (e.g 20ms, 40ms, 80ms) so timeslots can align if coexist with recommended 10ms draft-ietf-6tisch-minimal-02 <Pascal Thubert>, <Cisco>

  28. EBs • To be strictly compliant with 15.4e EBs MUST contain: • Sync IE (ASN, Join Priority) • Timeslot IE (timeslot template, slot length and timing in the slot) • Ch.Hopping IE (Ch.Hopping template, using the default) • Frame and Link IE (slotframe and link information) • No dedicated slot for EB. Using single DATA slot from slotframe. • No pre-configured slotframe at node • Learnt from Frame and Link IE from EBs. draft-ietf-6tisch-minimal-02 <Pascal Thubert>, <Cisco>

  29. draft-ietf-6tisch-6top-interface-01draft-wang-6tisch-6top-sublayer-01draft-ietf-6tisch-6top-interface-01draft-wang-6tisch-6top-sublayer-01 Qin Wang (Ed.)Xavier VilajosanaThomas Watteyne <Pascal Thubert>, <Cisco>

  30. Next steps • Apply YANG review comments during IETF 90 • Integration with COAP IE • Language / editorial work <Pascal Thubert>, <Cisco>

  31. draft-richardson-6tisch--security-6top-01 Michael Richardson 36 <Pascal Thubert>, <Cisco>

  32. BEACON (1) Router Solicitation Router Advertisement Certificate Request (2) Certificate Reply (3) Join Request (4) (NS w/(E)ARO) NS (DAR) (5) ?? (6) ?? (7) NS (DAC) (8) DAO DAO DAOACK DAOACK NS / Join ACK (9) 6top (CoAP/DTLS) Join Coordination Entity Akin to PCE 6top/NS/ARO join protocol(“wirelessHART”-like) 6tisch mesh JCE 6LBR Join Assistant (proxy) Joining Node Could be part of 6LBR Or co-located in PCE (2) and (3) May have limited Utility, kept for now OUI field of EARO Contains 802.11AR IDevID Mesh node DTLS connection Has client and server Autonomic certificates 37 draft-richardson-6tisch--security-6top <Pascal Thubert>, <Cisco>

  33. Next steps • Consensus that this is the right way to go. • Finish architectural considerations; merge to architecture document • Get the details of the protocol right. 38 draft-richardson-6tisch--security-6top <Pascal Thubert>, <Cisco>

  34. WIP:Compressing the RPL option 39 <Pascal Thubert>, <Cisco>

  35. RPL info in current RPL implementations • [RFC655011.2. Loop Avoidance and Detection] : “RPL loop detection uses RPL Packet Information that is transported within the data packets, relying on an external mechanism such as [RFC6553] that places in the RPL Packet Information in an IPv6 Hop- by-Hop option header.” • [RFC6553] : 8 octets encoding (2 octets for HbH header and then 6 octets option): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O|R|F|0|0|0|0|0| RPLInstanceID | SenderRank | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (sub-TLVs) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ • [RFC6553 4. RPL Router Behavior] : • “When the router is the source of the original packet and the destination is known to be within the same RPL Instance, the router SHOULD include the RPL Option directly within the original packet. Otherwise, routers MUST use IPv6-in-IPv6 tunneling[RFC2473] and place the RPL Option in the tunnel header.” <Pascal Thubert>, <Cisco>

  36. Problem with RPL option in HbH header [RFC6553] 8-octets overhead detrimental to the LLN operation • Almost innocuous with G-PHY (ZigbeeIP, CG-Mesh) • May cause fragmentation with classical PHY (127 octets/Frame) • Not compressed by 6LoWPAN HC • Wasted Energy in constrained devices Additional IP-in-IP encapsulation • Deeply aggravating factor for energy consumption and fragmentation 6TiSCH supports classical PHY • Overheads above are show stoppers for adoption by ext. SDOs <Pascal Thubert>, <Cisco>

  37. RFC 6282: 6LoWPAN Adaptation Layer Simple MAC allows coexistence with other network protocols over same link, similar to Ethernet, although not seen in deployment Mesh Address Frag. 6LoWPAN Compressed Hdr Payload Mesh + Fragmentation Frag. 6LoWPAN Compressed Hdr Payload Frame Fragmentation Mesh Address 6LoWPAN Compressed Hdr Payload Mesh (L2 Routing) DSP + IPHC Other 6LoWPAN Hdr field Payload 6LoWPAN Frame Control Data Seq. Nbr Addressing Auxiliary Security Header IEs Header & Payload DSP Payload FCS Preamble SPD PHY Header 0 0 1 1 0 1 1 0 X Not a LoWPAN frame DST PAN ID DST MAC Address SRC PAN ID SRC MAC Address LoWPAN IPv6 addressing Hdr LoWPAN mesh Hdr Header Dispatch (DSP) – understand what is coming LoWPAN fragmentation Hdr <Pascal Thubert>, <Cisco>

  38. RFC 6282: 6LoWPAN IPv6 Header Compression 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 1 TF NH HLIM CID SAC SAM M DAC DAM Addressing <Pascal Thubert>, <Cisco>

  39. 6LoWPAN: Traffic Class & Flow Label 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 1 TF NH HLIM CID SAC SAM M DAC DAM 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ECN DSCP rsv Flow Label TF = 0 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 ECN rsv Flow Label TF = 1 0 0 1 2 3 4 5 6 7 ECN DSCP TF = 2 TF = 3 Traffic Class and Flow Label elided. <Pascal Thubert>, <Cisco>

  40. draft-thubert-6man-flow-label-for-rpl 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 ? O R F SenderRank InstanceID Places in Flow Label the RPL Packet Information is defined in RFC 655 Section 11.2 Save extra HbH header bytes incurred in RFC 6553 AND eventual IP-in-IP tunneling Discussed with Brian Carpenter on the ROLL ML than converged on 6MAN ML • http://www.ietf.org/mail-archive/web/roll/current/msg06967.html <Pascal Thubert>, <Cisco>

  41. Shown at the plugfest Impl. draft-thubert-6man-flow-label-for-rpl-03 RPL Non-Storing Mode (rfc6550-53,54) draft-ietf-6tisch-minimal-02 On IEEE802.15.4eTSCH 3 hop network, demonstrating the use of flow label as a replacement to the IPv6 Extension Header (rfc6282#section-4.2) On OpenWSN. (www.openwsn.org) OpenMote platform (www.openmote.com) <Pascal Thubert>, <Cisco>

  42. SenderRank = 1792 <Pascal Thubert>, <Cisco>

  43. Status By default the only format is HbH can we leave it at that for 6TiSCH? • Consensus that no Will 6MAN allow the LLN to update the Flow Label • On its way, optimistic Should we go for a 6Lo compression or a ROLL solution (based on flow label) ? • TBD <Pascal Thubert>, <Cisco>

  44. Flow Label vs. 6LoWPAN approach Both solutions work for 6TiSCH since 6TiSCH uses 6LoWPAN anyway • No commitment so far from 6lo side Dependency for minimal draft, shipping in Nov. • What will an implementation do till 6lo delivers ? Dependency for track ID • Architecture says to use the flow label • The 6LoWPAN compression could be adapted <Pascal Thubert>, <Cisco>

  45. draft-bormann-6lo-rpl-mesh 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 0 0 1|0|U| Rank | Inst | (continuation)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 0 0 1|1|U| Rank | Inst | (continuation)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: RPL Mesh Header: Short and Long Version <Pascal Thubert>, <Cisco>

  46. draft-bormann-6lo-rpl-mesh 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | O | R | F | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ CB for continuation for U=0 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ RFC 6282 LOWPAN_IPHC base Encoding <Pascal Thubert>, <Cisco>

  47. Performance • Flow Label is 20 bits flat • The most compressed CB version claims 16 • But the sense that makes is debatable, Pascal’s expectation is 24 bits • The proposal c(sh)ould be extended to enable the full 2 octet Rank <Pascal Thubert>, <Cisco>

  48. Complexity • To even reach 24 bits, new proposal “hacks” IPHC • IPHC first bits would have multiple interpretations • A really clean version with a new dispatch would cost even more <Pascal Thubert>, <Cisco>

  49. Compressing the Rank • 8 bits corresponds to OF0 and a standard maximum depth, used in Minimal RPL • Rank can reach 16 bits. Would be a value add for the 6Lo format to support it • Rank is dynamic. What should a node do if Rank representation exceeds 4 bits? • Change the compression from the root down ? • Increase the frame size but then what is > 127 ? => A non mutable format would probably be better <Pascal Thubert>, <Cisco>

  50. Instance ID (RFC 6550) 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |0| ID | Global RPLInstanceID in 0..127 +-+-+-+-+-+-+-+-+ Figure 4: RPLInstanceID Field Format for Global Instances 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |1|D| ID | Local RPLInstanceID in 0..63 +-+-+-+-+-+-+-+-+ Figure 5: RPLInstanceID Field Format for Local Instances <Pascal Thubert>, <Cisco>

More Related