[lisp] Next steps with the LISP multiplexing draft

"Jose Saldana" <jsaldana@unizar.es> Mon, 05 September 2016 07:10 UTC

Return-Path: <jsaldana@unizar.es>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B07F12B0D1 for <lisp@ietfa.amsl.com>; Mon, 5 Sep 2016 00:10:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.829
X-Spam-Level:
X-Spam-Status: No, score=-3.829 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHBvTsfc0bGO for <lisp@ietfa.amsl.com>; Mon, 5 Sep 2016 00:10:27 -0700 (PDT)
Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA73128E18 for <lisp@ietf.org>; Mon, 5 Sep 2016 00:10:26 -0700 (PDT)
Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) (authenticated bits=0) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id u857ALJl013927; Mon, 5 Sep 2016 09:10:21 +0200
From: Jose Saldana <jsaldana@unizar.es>
To: lisp@ietf.org
Date: Mon, 05 Sep 2016 09:10:25 +0200
Message-ID: <005b01d20744$935a87c0$ba0f9740$@unizar.es>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_005C_01D20755.56E4DE60"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQIr2ICXVE2JVEbYqIUOhZq/XStrbw==
Content-Language: es
X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/-O0jUMicd3AP0thYMzqDLybzeeU>
Cc: 'José Ruiz Mas' <jruiz@unizar.es>
Subject: [lisp] Next steps with the LISP multiplexing draft
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Sep 2016 07:10:30 -0000

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).