[Roll-bier-dt] TRANSPORT vs TUNNEL mode

["Pascal Thubert (pthubert)" <[e-mail]>]

Dear all

At the last call we made that important distinction, tunnel vs transport, that creates a new dimension to our matrix, which was so far (BIER, BIER-TE) * (Bitwise BIER, Bloom).


-          Transport would be when the bitmap indicates one or more final destination. In that case, there is no IP address in the packet. The RPL-BIER termination needs to rebuild individual packets from the bits, and forward the packets individually in a 6LoWPAN form or in an incompressed form. One way of presenting it is that BIER becomes a new more of 6LoWPAN stateful compression. Transport mode enables to distribute a copy of a packet to one or more distinct destination 6LNs attached to one or more 6LRs.

-          Tunnel could be when the bits indicate the terminating RPL-BIER routers. Those routers decapsulate the BIER and forward the inner packet. This model can be seen as an overlay to a RPL-BIER network, whereby only the en/decapsulators can forward the inner packets, but the RPL infra is not aware of those addresses. One way of presenting this is that BIER becomes a way to compress the amount of routing state in the RPL fabric. Tunnel mode allows to distribute one unicast packet to one 6LR or one multicast packet to one or more 6LRs.

We discussed how this maps to MLD/IGMP. My view is that a different draft should enable the 6LR (== RPL-BIER termination router, or RPL leaf) to proxy MLD to the 6LBR (== root). When  a 6LN node registers to the 6LR using MLD, the 6LR relays that to the 6LBR, and the 6LBR adds the bit of the 6LR in the bitmap for that multicast address. When a packet is intended for the mcast group, the route encapsulates the packet to the collection of 6LRs that got MLD registrations in tunnel mode, which decapsulate and do normal multicast distribution on the last hop.

Note that in transport mode,  each copy is a distinct packet with a different destination address. The result is that the UDP checksum is different and has to be regenerated by the endpoints (6LoWPAN allows for that since the checksum can be compressed under some conditions of equivalent protection in the framing). This means that false positives can not be filtered out by the UDP checksum. This means that unless the application is protected against misdistribution (eg app level session / security), false positive are not acceptable. IOW, transport mode is compatible with bitwise BIER but not with Bloom.

Do I make sense?

Pascal

[banner4]

Pascal Thubert
Principal Engineer
Chief Technology & Architecture Office

[e-mail]<mailto:[e-mail]>
Phone :[phone]
Mobile :[phone]

Cisco Systems
Building D (Regus)
45 Allee des Ormes - BP1200
06254 MOUGINS cedex
France
Cisco.com<http://www.cisco.com/global/FR/>


[Description: Think before you print.]Think before you print.
This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
Please click here<http://www.cisco.com/web/about/doing_business/legal/cri/index.html> for Company Registration Information.