[Spud] "framing for UDP"
Lars Westberg <lars.westberg@ericsson.com> Tue, 14 April 2015 11:03 UTC
Return-Path: <lars.westberg@ericsson.com>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id BC0861A88F4
for <spud@ietfa.amsl.com>; Tue, 14 Apr 2015 04:03:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
SPF_PASS=-0.001] autolearn=ham
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 ZwNTH5FUEZ_I for <spud@ietfa.amsl.com>;
Tue, 14 Apr 2015 04:03:44 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id AEEB31A8901
for <spud@ietf.org>; Tue, 14 Apr 2015 04:03:20 -0700 (PDT)
X-AuditID: c1b4fb3a-f79146d0000070a3-e8-552cf3f6f609
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124])
by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id
8D.69.28835.6F3FC255; Tue, 14 Apr 2015 13:03:19 +0200 (CEST)
Received: from ESESSMB303.ericsson.se ([169.254.3.196]) by
ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0210.002; Tue, 14
Apr 2015 13:03:18 +0200
From: Lars Westberg <lars.westberg@ericsson.com>
To: "spud@ietf.org" <spud@ietf.org>
Thread-Topic: "framing for UDP"
Thread-Index: AdB2ojygOYQmYmTKS9+tBuj/AuTbYw==
Date: Tue, 14 Apr 2015 11:03:17 +0000
Message-ID: <5A0CBBC6F5BA334D94DF4DFCC2674B253CD5C48F@ESESSMB303.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.146]
Content-Type: multipart/alternative;
boundary="_000_5A0CBBC6F5BA334D94DF4DFCC2674B253CD5C48FESESSMB303erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvje73zzqhBvdKLBZdeMrowOixZMlP
pgDGKC6blNSczLLUIn27BK6MTa+eMhes1qjYduw+WwPjU+UuRk4OCQETiVlL3jJD2GISF+6t
Z+ti5OIQEjjKKHH0YyszhLOEUWLZ8SfsIFVsAgYSf/qfsYDYIgLKEmvvLAKLCwtISdxcNhkq
Li9xffEhZghbT2LOv11sIDaLgKrE/AnTwOp5BXwlzs1fCmYzAm3+fmoNE4jNLCAucevJfCaI
iwQkluw5D3WdqMTLx/9YIWwliR8bLrFA1OdL9H34zwIxU1Di5MwnLBMYhWYhGTULSdksJGUQ
cQOJ9+fmM0PY2hLLFr6GsvUlNn45y4gsvoCRfRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZG
YEwc3PLbagfjweeOhxgFOBiVeHgXlOiECrEmlhVX5h5ilOZgURLntTM+FCIkkJ5YkpqdmlqQ
WhRfVJqTWnyIkYmDU6qBMT3w2WXjyAxXk8W7JNUD75+o+JbMuY1f/2dukKTd59z0s4vaeH//
vZt9T5j3TTfbFp6eFXax3u8iZ8//9WKFQVSu+bLJMfvnR8/ImfL19Lf6gy9tGtw/3s+QN5rR
zNd67XTXVj/bL/kJl8UcXDpKZqTdSE7PCPWb8GnF1+JN1hEVFQqHjaMfKrEUZyQaajEXFScC
ADrudNxqAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/olyZwpMqBP4L65X3btnF-n5OvjE>
Subject: [Spud] "framing for UDP"
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>,
<mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>,
<mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Apr 2015 11:03:45 -0000
Hi all, We have prepared a draft on a UDP-based container architecture to transfer transport protocol components in an end2end UDP-stream. The concept proposes a standard “encapsulation” to identify/select the used protocol components rather than having separate specification for different protocols. The idea is to allow for a more open protocol design where each smaller protocol component can be modified and replaced separately. This end2end component identification/selection has the same semantics as SPUD (meant to bring information about higher protocol layers in an end2end header), so in principle SPUD could be used as a protocol for both end2end transport protocol (component) negotiation and middlebox interception of the information about the used components. Is this relevant for the SPUD-work? http://www.ietf.org/internet-drafts/draft-mihaly-tp-flexibility-00.txt http://www.ietf.org/internet-drafts/draft-westberg-tp-compositioning-framework-00.txt -Lars Westberg, Ericsson
- [Spud] "framing for UDP" Lars Westberg