Subject: [lisp] Next steps with the LISP multiplexing draft

From: "Jose Saldana" <[email-masked]>
Date: Mon, 5 Sep 2016 09:10:25 +0200

Hi all,
 
Regarding the multiplexing draft
(https://datatracker.ietf.org/doc/draft-saldana-lisp-compress-mux/), these
are the next steps we would consider:
 
1) Signaling: How to signal that some traffic flows will be multiplexed. We
would use LCAF, as suggested by Dino in July:
 
> You could also use the “Encapsulation Format” LCAF type which tells the
ITR, on a
> lookup what the ETR is willing to accept. We COULD treat this new
capability as a
> different encapsulation type.
> 
> Dino
 
Our plan is to include this in the next version of the draft, and in the
implementation.

2) How to distinguish between a multiplexed and a non-multiplexed packet
(once the negotiation is finished).
 
In the ETR we must be able to distinguish between a multiplexed and a
non-multiplexed packet. There would be two options for this:
 
a) the use of a port number different from 4341 in the UDP header preceding
the LISP header.
b) something in the LISP header that flags the fact.
 
We are currently using a) in the draft, and also in the implementation
(https://github.com/Simplemux/lispmob-with-simplemux), but perhaps b) could
be considered instead.

Any thoughts?
 
Jose
PS: We have also received some feedback about an adaptive encapsulation
scheme that maximizes the number IP packets encapsulated into a single one
(see  <http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4151444>
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4151444).