From nobody Fri Apr 4 13:49:30 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FBF1A010B for ; Fri, 4 Apr 2014 13:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 3e0T4PYWpIQB for ; Fri, 4 Apr 2014 13:49:23 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id 371521A0280 for ; Fri, 4 Apr 2014 13:49:23 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WWB37-0000gL-Fb; Fri, 04 Apr 2014 22:49:17 +0200 Received: from ydvlwo1-85-199.uibk.ac.at ([138.232.85.199]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WWB37-0006Sb-0K; Fri, 04 Apr 2014 22:49:17 +0200 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Apr 2014 22:49:14 +0200 Message-Id: <0275A4C1-05B7-41CD-B296-CBFAFD0CB358@ifi.uio.no> To: taps@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 10 msgs/h 5 sum rcpts/h 14 sum msgs/h 7 total rcpts 14697 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 09F02EC7F315F5E349CBA395ED05EB072634DFA8 X-UiO-SPAM-Test: remote_host: 138.232.85.199 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 95 max/h 10 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/oRP7HkgEHGMS9MUAeOxxW_478wM Cc: Bob Briscoe Subject: [Taps] How composable stacks can interoperate: Flexinet (1998) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 20:49:28 -0000 Dear all, I just took a look at the management interface of the old TAPS list, and = coincidentially found a bounced message there that Bob Briscoe tried to = send to the list on 5 March; it seems it never made it through on either = of the lists! My sincere apologies to everyone and above all, to Bob, = for this! Strange that the system didn't just "say no"... the new list = was created on 6 March, so I guess that happened just before the move = and in the process this trouble happened... very very sorry. So here it is, in all its glory - old but still interesting. Sorry once = again! Cheers, Michael ------ TAPS folks, When you allow a programme to create its protocol stack from its=20 requirements, the choices have to be the same for the other=20 correspondents in the session - they have to interoperate. Flexinet=20 addressed this problem (amongst others). Flexinet communicates a stack /name/ between all the participants in=20 the session. The neat idea in Flexinet is that the name the=20 programmer gives to the composition of components that comprise a=20 stack is itself a name object, which contains the specification for=20 how the stack is composed. [BTW, Flexinet was for higher layers (mostly OSI L5-7), which is=20 where I think this composable stack stuff makes more sense, and has=20 been more successful in the past. My main concern is that I doubt=20 programmers will want to lose control over their choice of transport=20 protocol, because L4 is where all the partial reliability is done=20 (because the network underneath is unreliable in all senses of the=20 word - packets get lost, connectivity gets lost, etc). The programmer=20 has to to handle all the exceptions, which will depend on the protocol = choice.] I've found a bootlegged copy of the paper here:=20 , or you can=20 pay Springer for it if you prefer. Given time I could retrieve the Flexinet java code (if I could find=20 my archived copy of the ANSA site it was on), but that's not the=20 important thing - it's the idea of the name object that is worth = re-using. @INPROCEEDINGS{Hayton98:Flexinet, author =3D {Richard Hayton and Andrew Herbert and Douglas Donaldson}, title =3D {{FlexiNet --- A flexible component oriented middleware = system}{}}, booktitle =3D {Proc. SIGOPS'98}, year =3D {1998}, affiliation =3D {APM}, keywords =3D {Data Communication, Networks, Internet, Computing,=20 Software Engineering, Object-Oriented, Mobility, Multimedia, Quality of Service,=20 QoS, Management, Adaptation, Architecture, Middleware, Layering, Reflection, = Java}, owner =3D {RJB}, timestamp =3D {1998.05.11}, url =3D {\url{http://dl.acm.org/citation.cfm?id=3D319199}} } Bob ________________________________________________________________ Bob Briscoe, BT =20 From nobody Mon Apr 7 15:19:32 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEEF1A02D9 for ; Mon, 7 Apr 2014 15:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 n8bmz3QfZlsr for ; Mon, 7 Apr 2014 15:19:24 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFDE1A029E for ; Mon, 7 Apr 2014 15:19:24 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s37MIVn4025525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 7 Apr 2014 15:18:31 -0700 (PDT) Message-ID: <53432437.50803@isi.edu> Date: Mon, 07 Apr 2014 15:18:31 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Michael Welzl , taps@ietf.org References: <0275A4C1-05B7-41CD-B296-CBFAFD0CB358@ifi.uio.no> In-Reply-To: <0275A4C1-05B7-41CD-B296-CBFAFD0CB358@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/taps/T0DmGS4E4pMaTjXSpePcokq_n2w Cc: Bob Briscoe Subject: Re: [Taps] How composable stacks can interoperate: Flexinet (1998) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 22:19:29 -0000 FWIW, this was a focus of a lot of what was called "middleware" in the late 1990s. There's also plenty of more recent work in this area (e.g., SILO at NCSU). Joe On 4/4/2014 1:49 PM, Michael Welzl wrote: > Dear all, > > I just took a look at the management interface of the old TAPS list, and coincidentially found a bounced message there that Bob Briscoe tried to send to the list on 5 March; it seems it never made it through on either of the lists! My sincere apologies to everyone and above all, to Bob, for this! Strange that the system didn't just "say no"... the new list was created on 6 March, so I guess that happened just before the move and in the process this trouble happened... very very sorry. > > > So here it is, in all its glory - old but still interesting. Sorry once again! > > Cheers, > Michael > > ------ > > > TAPS folks, > > When you allow a programme to create its protocol stack from its > requirements, the choices have to be the same for the other > correspondents in the session - they have to interoperate. Flexinet > addressed this problem (amongst others). > > Flexinet communicates a stack /name/ between all the participants in > the session. The neat idea in Flexinet is that the name the > programmer gives to the composition of components that comprise a > stack is itself a name object, which contains the specification for > how the stack is composed. > > [BTW, Flexinet was for higher layers (mostly OSI L5-7), which is > where I think this composable stack stuff makes more sense, and has > been more successful in the past. My main concern is that I doubt > programmers will want to lose control over their choice of transport > protocol, because L4 is where all the partial reliability is done > (because the network underneath is unreliable in all senses of the > word - packets get lost, connectivity gets lost, etc). The programmer > has to to handle all the exceptions, which will depend on the protocol choice.] > > I've found a bootlegged copy of the paper here: > , or you can > pay Springer for it if you prefer. > > Given time I could retrieve the Flexinet java code (if I could find > my archived copy of the ANSA site it was on), but that's not the > important thing - it's the idea of the name object that is worth re-using. > > @INPROCEEDINGS{Hayton98:Flexinet, > author = {Richard Hayton and Andrew Herbert and Douglas Donaldson}, > title = {{FlexiNet --- A flexible component oriented middleware system}{}}, > booktitle = {Proc. SIGOPS'98}, > year = {1998}, > affiliation = {APM}, > keywords = {Data Communication, Networks, Internet, Computing, > Software Engineering, > Object-Oriented, Mobility, Multimedia, Quality of Service, > QoS, Management, > Adaptation, Architecture, Middleware, Layering, Reflection, Java}, > owner = {RJB}, > timestamp = {1998.05.11}, > url = {\url{http://dl.acm.org/citation.cfm?id=319199}} > } > > > > > Bob > > > > ________________________________________________________________ > Bob Briscoe, BT > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Tue Apr 8 13:17:19 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B3A1A053B for ; Tue, 8 Apr 2014 09:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 qaggyVW0hG3Z for ; Tue, 8 Apr 2014 09:36:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D4C541A049A for ; Tue, 8 Apr 2014 09:35:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFK25371; Tue, 08 Apr 2014 16:35:34 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Apr 2014 17:34:21 +0100 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Apr 2014 17:35:33 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml702-chm.china.huawei.com ([169.254.4.119]) with mapi id 14.03.0158.001; Tue, 8 Apr 2014 09:35:28 -0700 From: Linda Dunbar To: "sustrik@250bpm.com" , Michael Welzl , "superuser@gmail.com" Thread-Topic: TAPS is what SDN is really about Thread-Index: Ac9TSI1NXF4ICgtKTO+YQoB7amWUwQ== Date: Tue, 8 Apr 2014 16:35:27 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645CF151B@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.150.53] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645CF151Bdfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/taps/Ow2095fFmWpabQ5HZid0etxYBZw X-Mailman-Approved-At: Tue, 08 Apr 2014 13:17:16 -0700 Cc: Martin Stiemerling , Spencer Dawkins , "taps@ietf.org" Subject: [Taps] TAPS is what SDN is really about X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 16:36:17 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645CF151Bdfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks to Martin's presentation on "Towards Transport - Agnostic Middleware= ". I think what Martin's presented is the key value of SDN, providing the h= ooks and ways for Applications to control the desired services from network= (transport), more than what TCP/UDP can provide. I've been closely following and contributing to SFC, SDNrg, and have been c= hairing ONF's L4-L7 Service group. There has been a lot of talks on Metadat= a in SFC, but the metadata discussion has been mudded by information among = various entities. The "messaging middleware Layer" is a really good way to show metadata amo= ng Middle ware boxes. There could be metadata among applications, metadata = among transport layers or network layers. Then there could be metadata acro= ss layers: such as meta data from middle ware boxes to Transport layer, the= meta data from applications to middleware layer, etc. I think the work proposed by TAPS is a concrete step towards allowing appli= cations to have better control of the network services. Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F645CF151Bdfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks to Martin’s presentation on “Towa= rds Transport – Agnostic Middleware”. I think what Martin’= ;s presented is the key value of SDN, providing the hooks and ways for Appl= ications to control the desired services from network (transport), more than what TCP/UDP can provide.

 

I’ve been closely following and contributing t= o SFC, SDNrg, and have been chairing ONF’s L4-L7 Service group. There= has been a lot of talks on Metadata in SFC, but the metadata discussion ha= s been mudded by information among various entities.

 

 

The  “messaging middleware Layer” i= s a really good way to show metadata among Middle ware boxes. There could b= e metadata among applications, metadata among transport layers or network l= ayers. Then there could be metadata across layers: such as meta data from middle ware boxes to Transport layer, the meta data= from applications to middleware layer, etc.

 

I think the work proposed by TAPS is a concrete step= towards allowing applications to have better control of the network servic= es.

 

Linda Dunbar

--_000_4A95BA014132FF49AE685FAB4B9F17F645CF151Bdfweml701chmchi_-- From nobody Mon Apr 14 09:23:48 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4F01A04C1 for ; Mon, 14 Apr 2014 09:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.772 X-Spam-Level: X-Spam-Status: No, score=-9.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 tCxlKLr28hw2 for ; Mon, 14 Apr 2014 09:23:41 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9551A02CD for ; Mon, 14 Apr 2014 09:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8544; q=dns/txt; s=iport; t=1397492619; x=1398702219; h=from:to:cc:subject:date:message-id:mime-version; bh=n74sA6rczS9oxBOiZ9I2sigxiH85MlYyiiRHDZgmvnM=; b=fS665EscAkek6CAvk/99quePlo7Dw3P76IFBsYQEn0guqK85zDdAS97X SWMNW0+v9XW2i3pqfpN1GROgifM/iCMcOtoIk2xY0vq/pwmgLclmFkFMj ovWhw2I5TY8xiWLrTbSStzJJmgb+b01s9ZIXDIJX6HF980wgJbAxk79ro Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FALoKTFOtJV2b/2dsb2JhbABZgkJEO1fDJIEkFnSCJQECBC1MEgEIEQMBAigoERQJCgQBDQWHaAMRDcRgDYZjEwSMVYIIDQSEPwSWc4FujHSFT4Mxgis X-IronPort-AV: E=Sophos; i="4.97,857,1389744000"; d="scan'208,217"; a="35665535" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP; 14 Apr 2014 16:23:38 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s3EGNc5x021785 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Apr 2014 16:23:38 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Mon, 14 Apr 2014 11:23:38 -0500 From: "Charles Eckel (eckelcu)" To: Linda Dunbar , "sustrik@250bpm.com" , Michael Welzl , "superuser@gmail.com" Thread-Topic: [Taps] TAPS is what SDN is really about Thread-Index: AQHPV/3jnczMhX7HWUW7gP9CGdYHGA== Date: Mon, 14 Apr 2014 16:23:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.73.123] Content-Type: multipart/alternative; boundary="_000_CF7156D526146eckelcuciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/VjxTDQGO_bRtGUKm1ausUyvZ08w Cc: Martin Stiemerling , Spencer Dawkins , "taps@ietf.org" Subject: Re: [Taps] TAPS is what SDN is really about X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 16:23:46 -0000 --_000_CF7156D526146eckelcuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Linda, I agree and would like to add that TAPS and AEON (https://sites.google.com/= site/aeonsignalling/) are aligning in terms of specification and usage of a= pplication metadata. Some of the =93metadata=94 conveyed by applications wh= en describing the transport services they need are applicable for network s= ervices as well, such as those envisioned by AEON. Ideally, mechanisms used= to exchange this information between applications to the network could be = used to aid with classification for SFC. Cheers, Charles From: Linda Dunbar = > Date: Tuesday, April 8, 2014 at 9:35 AM To: "sustrik@250bpm.com" >, Michael Welzl >, "superuser@gmail.com" > Cc: Martin Stiemerling >, Spe= ncer Dawkins >, "taps@ietf.org" > Subject: [Taps] TAPS is what SDN is really about Thanks to Martin=92s presentation on =93Towards Transport =96 Agnostic Midd= leware=94. I think what Martin=92s presented is the key value of SDN, provi= ding the hooks and ways for Applications to control the desired services fr= om network (transport), more than what TCP/UDP can provide. I=92ve been closely following and contributing to SFC, SDNrg, and have been= chairing ONF=92s L4-L7 Service group. There has been a lot of talks on Met= adata in SFC, but the metadata discussion has been mudded by information am= ong various entities. The =93messaging middleware Layer=94 is a really good way to show metadata= among Middle ware boxes. There could be metadata among applications, metad= ata among transport layers or network layers. Then there could be metadata = across layers: such as meta data from middle ware boxes to Transport layer,= the meta data from applications to middleware layer, etc. I think the work proposed by TAPS is a concrete step towards allowing appli= cations to have better control of the network services. Linda Dunbar --_000_CF7156D526146eckelcuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <21967F8AEAD76043AE3F4D4ADA117B59@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Linda,

I agree and would like to add that TAPS and AEON (https://sites.google.com/site/aeonsign= alling/) are aligning in terms of specification and usage of applicatio= n metadata. Some of the =93metadata=94 conveyed by applications when describing the transport services they need = are applicable for network services as well, such as those envisioned by AE= ON. Ideally, mechanisms used to exchange this information between applicati= ons to the network could be used to aid with classification for SFC.

Cheers,
Charles 

From: Linda Dunbar <linda.dunbar@huawei.com>
Date: Tuesday, April 8, 2014 at 9:3= 5 AM
To: "sustrik@250bpm.com" <sustrik@250bpm.com>, Michael Welzl <michawe@ifi.uio.no>, "superuser@gmail.com" <superuser@gmail.com>
Cc: Martin Stiemerling <mls.ietf@gmail.com>, Spencer Dawkins = <spencerdawkins.ietf@gm= ail.com>, "taps@ietf.org&q= uot; <taps@ietf.org>
Subject: [Taps] TAPS is what SDN is= really about

Thanks to Martin=92s presentation on =93Towards Tran= sport =96 Agnostic Middleware=94. I think what Martin=92s presented is the = key value of SDN, providing the hooks and ways for Applications to control = the desired services from network (transport), more than what TCP/UDP can provide.

 

I=92ve been closely following and contributing to SF= C, SDNrg, and have been chairing ONF=92s L4-L7 Service group. There has bee= n a lot of talks on Metadata in SFC, but the metadata discussion has been m= udded by information among various entities.

 

 

The  =93messaging middleware Layer=94 is a real= ly good way to show metadata among Middle ware boxes. There could be metada= ta among applications, metadata among transport layers or network layers. T= hen there could be metadata across layers: such as meta data from middle ware boxes to Transport layer, the meta data= from applications to middleware layer, etc.

 

I think the work proposed by TAPS is a concrete step= towards allowing applications to have better control of the network servic= es.

 

Linda Dunbar

 --_000_CF7156D526146eckelcuciscocom_-- From nobody Mon Apr 14 09:45:39 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B0E1A0522 for ; Mon, 14 Apr 2014 09:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272] 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 rEcvwkcVUeP0 for ; Mon, 14 Apr 2014 09:45:30 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id C98A91A02CF for ; Mon, 14 Apr 2014 09:45:28 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 49FB2602DA; Mon, 14 Apr 2014 18:45:25 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 482C0602D9; Mon, 14 Apr 2014 18:45:25 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: taps@ietf.org Date: Mon, 14 Apr 2014 18:45:25 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201404141845.25290.mirja.kuehlewind@ikr.uni-stuttgart.de> Archived-At: http://mailarchive.ietf.org/arch/msg/taps/zhKH0UEnmrdMqQUa83jCKy6LPH4 Cc: "Charles Eckel \(eckelcu\)" , Michael Welzl , Linda Dunbar Subject: Re: [Taps] TAPS is what SDN is really about X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 16:45:36 -0000 Hi Linda, hi Charles, for me Taps was mainly about the interface between the application and the= =20 transport layer (within one host without any signalling through the network= ).=20 I believe this interface is also one aspect that could help to address your= =20 problem(s) but for my understanding what you propose it much more than Taps. Mirja On Monday 14 April 2014 18:23:38 Charles Eckel (eckelcu) wrote: > Hi Linda, > > I agree and would like to add that TAPS and AEON > (https://sites.google.com/site/aeonsignalling/) are aligning in terms of > specification and usage of application metadata. Some of the =E2=80=9Cmet= adata=E2=80=9D > conveyed by applications when describing the transport services they need > are applicable for network services as well, such as those envisioned by > AEON. Ideally, mechanisms used to exchange this information between > applications to the network could be used to aid with classification for > SFC. > > Cheers, > Charles > > From: Linda Dunbar > > Date: Tuesday, > April 8, 2014 at 9:35 AM > To: "sustrik@250bpm.com" > >, Michael Welzl > >, > "superuser@gmail.com" > > Cc: Martin Stiemerling > >, Spencer Dawkins > >, > "taps@ietf.org" > > Subject: [Taps] TAPS is what SDN is really about > > Thanks to Martin=E2=80=99s presentation on =E2=80=9CTowards Transport =E2= =80=93 Agnostic > Middleware=E2=80=9D. I think what Martin=E2=80=99s presented is the key v= alue of SDN, > providing the hooks and ways for Applications to control the desired > services from network (transport), more than what TCP/UDP can provide. > > I=E2=80=99ve been closely following and contributing to SFC, SDNrg, and h= ave been > chairing ONF=E2=80=99s L4-L7 Service group. There has been a lot of talks= on > Metadata in SFC, but the metadata discussion has been mudded by informati= on > among various entities. > > > The =E2=80=9Cmessaging middleware Layer=E2=80=9D is a really good way to= show metadata > among Middle ware boxes. There could be metadata among applications, > metadata among transport layers or network layers. Then there could be > metadata across layers: such as meta data from middle ware boxes to > Transport layer, the meta data from applications to middleware layer, etc. > > I think the work proposed by TAPS is a concrete step towards allowing > applications to have better control of the network services. > > Linda Dunbar =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=C3=BChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From nobody Mon Apr 14 10:29:53 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5015F1A06BD for ; Mon, 14 Apr 2014 10:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.773 X-Spam-Level: X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 ScHsETlcbgGe for ; Mon, 14 Apr 2014 10:29:46 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 216E21A06BB for ; Mon, 14 Apr 2014 10:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3903; q=dns/txt; s=iport; t=1397496584; x=1398706184; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iZhwjJerfmFZxswAgH5BELu1brqqaRUQW7t4yAjdiYE=; b=VmtjKlNxkdmu7dvbmRsJ70rOr8jM0UJTpCcgImP/vfoZReLPItGBcYrQ 4UsByuuwFXsnUSHXT8ONYKhwysAM032Odx2wgeJZHRsBKZ7R/tjX2fUuJ G1pNImRIyH65ZLVURZHdRuLoPkuIJR8vOWTWXzJhgKxMA4nrbSpLMnS0q g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAAcaTFOtJV2a/2dsb2JhbABZgwY7V8MmgSQWdIIlAQEBAwFJMBACAQgRAwECAScHIREUCQgCBAENBYdoAwkIDcRqDYZjF4xVgTcRAR0zB4Q4BIkkjU+Bbox0hU+DMYFyOQ X-IronPort-AV: E=Sophos;i="4.97,858,1389744000"; d="scan'208";a="317712022" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 14 Apr 2014 17:29:43 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3EHThXS023089 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Apr 2014 17:29:43 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 14 Apr 2014 12:29:43 -0500 From: "Charles Eckel (eckelcu)" To: Mirja Kuehlewind , "taps@ietf.org" Thread-Topic: [Taps] TAPS is what SDN is really about Thread-Index: AQHPV/3jnczMhX7HWUW7gP9CGdYHGJsRpbOA//+XBoA= Date: Mon, 14 Apr 2014 17:29:42 +0000 Message-ID: References: <201404141845.25290.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: <201404141845.25290.mirja.kuehlewind@ikr.uni-stuttgart.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.75.189] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/WKT5Z5gSc_2ZAvSTHUJ1CFh0Wes Cc: Michael Welzl , Linda Dunbar Subject: Re: [Taps] TAPS is what SDN is really about X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 17:29:51 -0000 Hi Mirja, As for the application is concerned, the transport services are local to the host. However, several of the TAPS use cases involve communication between the local transport services and the network, to determine available interfaces, level of congestion, interaction with NATs/firewalls, etc. At a minimum I would expect some of the information conveyed by the application to the local transport services via TAPS APIs to be communicated with the network. Cheers, Charles On 4/14/14, 9:45 AM, "Mirja Kuehlewind" wrote: >Hi Linda, hi Charles, > >for me Taps was mainly about the interface between the application and >the=20 >transport layer (within one host without any signalling through the >network).=20 >I believe this interface is also one aspect that could help to address >your=20 >problem(s) but for my understanding what you propose it much more than >Taps. > >Mirja > > >On Monday 14 April 2014 18:23:38 Charles Eckel (eckelcu) wrote: >> Hi Linda, >> >> I agree and would like to add that TAPS and AEON >> (https://sites.google.com/site/aeonsignalling/) are aligning in terms of >> specification and usage of application metadata. Some of the =B3metadata= =B2 >> conveyed by applications when describing the transport services they >>need >> are applicable for network services as well, such as those envisioned by >> AEON. Ideally, mechanisms used to exchange this information between >> applications to the network could be used to aid with classification for >> SFC. >> >> Cheers, >> Charles >> >> From: Linda Dunbar >> > Date: Tuesday, >> April 8, 2014 at 9:35 AM >> To: "sustrik@250bpm.com" >> >, Michael Welzl >> >, >> "superuser@gmail.com" >> > Cc: Martin Stiemerling >> >, Spencer Dawkins >> >, >> "taps@ietf.org" >>> >> Subject: [Taps] TAPS is what SDN is really about >> >> Thanks to Martin=B9s presentation on =B3Towards Transport =AD Agnostic >> Middleware=B2. I think what Martin=B9s presented is the key value of SDN= , >> providing the hooks and ways for Applications to control the desired >> services from network (transport), more than what TCP/UDP can provide. >> >> I=B9ve been closely following and contributing to SFC, SDNrg, and have >>been >> chairing ONF=B9s L4-L7 Service group. There has been a lot of talks on >> Metadata in SFC, but the metadata discussion has been mudded by >>information >> among various entities. >> >> >> The =B3messaging middleware Layer=B2 is a really good way to show metad= ata >> among Middle ware boxes. There could be metadata among applications, >> metadata among transport layers or network layers. Then there could be >> metadata across layers: such as meta data from middle ware boxes to >> Transport layer, the meta data from applications to middleware layer, >>etc. >> >> I think the work proposed by TAPS is a concrete step towards allowing >> applications to have better control of the network services. >> >> Linda Dunbar > > > >--=20 >------------------------------------------------------------------- >Dipl.-Ing. Mirja K=FChlewind >Institute of Communication Networks and Computer Engineering (IKR) >University of Stuttgart, Germany >Pfaffenwaldring 47, D-70569 Stuttgart > >tel: +49(0)711/685-67973 >email: mirja.kuehlewind@ikr.uni-stuttgart.de >web: www.ikr.uni-stuttgart.de >------------------------------------------------------------------- From nobody Mon Apr 14 11:46:35 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506E51A06E1 for ; Mon, 14 Apr 2014 11:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272] 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 XzFcJ03kKxi8 for ; Mon, 14 Apr 2014 11:46:26 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 85D2F1A06AC for ; Mon, 14 Apr 2014 11:46:25 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WZltY-0007PX-Bv; Mon, 14 Apr 2014 20:46:16 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WZltX-0005wl-92; Mon, 14 Apr 2014 20:46:16 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_5B2536E7-63ED-4E7E-9738-72577F81AEF3" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Welzl In-Reply-To: Date: Mon, 14 Apr 2014 20:46:12 +0200 Message-Id: <27D55D64-EDA9-4221-B51D-DAF0627BC2CE@ifi.uio.no> References: <201404141845.25290.mirja.kuehlewind@ikr.uni-stuttgart.de> To: "Charles Eckel (eckelcu)" X-Mailer: Apple Mail (2.1874) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 11 sum msgs/h 2 total rcpts 15226 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 034CEE47AF06057CF6D94B995062091E35FECABA X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1206 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/q43lxsF5oXTWzZmqql_-cVqYIZk Cc: Linda Dunbar , Mirja Kuehlewind , "taps@ietf.org" Subject: Re: [Taps] TAPS is what SDN is really about X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 18:46:31 -0000 --Apple-Mail=_5B2536E7-63ED-4E7E-9738-72577F81AEF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Well - these use cases are possibilities.. I'd agree with Mirja about = the scope of TAPS. Anyway there is no doubt that TAPS and AEON = complement each other very well. Cheers, Michael On 14. apr. 2014, at 19:29, Charles Eckel (eckelcu) = wrote: > Hi Mirja, >=20 > As for the application is concerned, the transport services are local = to > the host. However, several of the TAPS use cases involve communication > between the local transport services and the network, to determine > available interfaces, level of congestion, interaction with > NATs/firewalls, etc. At a minimum I would expect some of the = information > conveyed by the application to the local transport services via TAPS = APIs > to be communicated with the network. >=20 > Cheers, > Charles >=20 > On 4/14/14, 9:45 AM, "Mirja Kuehlewind" > wrote: >=20 >> Hi Linda, hi Charles, >>=20 >> for me Taps was mainly about the interface between the application = and >> the=20 >> transport layer (within one host without any signalling through the >> network).=20 >> I believe this interface is also one aspect that could help to = address >> your=20 >> problem(s) but for my understanding what you propose it much more = than >> Taps. >>=20 >> Mirja >>=20 >>=20 >> On Monday 14 April 2014 18:23:38 Charles Eckel (eckelcu) wrote: >>> Hi Linda, >>>=20 >>> I agree and would like to add that TAPS and AEON >>> (https://sites.google.com/site/aeonsignalling/) are aligning in = terms of >>> specification and usage of application metadata. Some of the = =B3metadata=B2 >>> conveyed by applications when describing the transport services they >>> need >>> are applicable for network services as well, such as those = envisioned by >>> AEON. Ideally, mechanisms used to exchange this information between >>> applications to the network could be used to aid with classification = for >>> SFC. >>>=20 >>> Cheers, >>> Charles >>>=20 >>> From: Linda Dunbar >>> > Date: = Tuesday, >>> April 8, 2014 at 9:35 AM >>> To: "sustrik@250bpm.com" >>> >, Michael Welzl >>> >, >>> "superuser@gmail.com" >>> > Cc: Martin = Stiemerling >>> >, Spencer Dawkins >>> = >, >>> "taps@ietf.org" >>> > >>> Subject: [Taps] TAPS is what SDN is really about >>>=20 >>> Thanks to Martin=B9s presentation on =B3Towards Transport =AD = Agnostic >>> Middleware=B2. I think what Martin=B9s presented is the key value of = SDN, >>> providing the hooks and ways for Applications to control the desired >>> services from network (transport), more than what TCP/UDP can = provide. >>>=20 >>> I=B9ve been closely following and contributing to SFC, SDNrg, and = have >>> been >>> chairing ONF=B9s L4-L7 Service group. There has been a lot of talks = on >>> Metadata in SFC, but the metadata discussion has been mudded by >>> information >>> among various entities. >>>=20 >>>=20 >>> The =B3messaging middleware Layer=B2 is a really good way to show = metadata >>> among Middle ware boxes. There could be metadata among applications, >>> metadata among transport layers or network layers. Then there could = be >>> metadata across layers: such as meta data from middle ware boxes to >>> Transport layer, the meta data from applications to middleware = layer, >>> etc. >>>=20 >>> I think the work proposed by TAPS is a concrete step towards = allowing >>> applications to have better control of the network services. >>>=20 >>> Linda Dunbar >>=20 >>=20 >>=20 >> --=20 >> ------------------------------------------------------------------- >> Dipl.-Ing. Mirja K=FChlewind >> Institute of Communication Networks and Computer Engineering (IKR) >> University of Stuttgart, Germany >> Pfaffenwaldring 47, D-70569 Stuttgart >>=20 >> tel: +49(0)711/685-67973 >> email: mirja.kuehlewind@ikr.uni-stuttgart.de >> web: www.ikr.uni-stuttgart.de >> ------------------------------------------------------------------- --Apple-Mail=_5B2536E7-63ED-4E7E-9738-72577F81AEF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Well - = these use cases are possibilities.. I'd agree with Mirja about the scope = of TAPS. Anyway there is no doubt that TAPS and AEON complement each = other very = well.

Cheers,
Michael


=
On 14. apr. 2014, at 19:29, Charles Eckel (eckelcu) <eckelcu@cisco.com> = wrote:

Hi Mirja,

As for the = application is concerned, the transport services are local to
the = host. However, several of the TAPS use cases involve = communication
between the local transport services and the network, = to determine
available interfaces, level of congestion, interaction = with
NATs/firewalls, etc. At a minimum I would expect some of the = information
conveyed by the application to the local transport = services via TAPS APIs
to be communicated with the = network.

Cheers,
Charles

On 4/14/14, 9:45 AM, "Mirja = Kuehlewind"
<mirja.kuehlewind@ikr= .uni-stuttgart.de> wrote:

Hi = Linda, hi Charles,

for me Taps was mainly about the interface = between the application and
the 
transport layer (within = one host without any signalling through the
network). 
I believe this = interface is also one aspect that could help to address
your 
problem(s) but for my = understanding what you propose it much more = than
Taps.

Mirja


On Monday 14 April 2014 18:23:38 = Charles Eckel (eckelcu) wrote:
Hi = Linda,

I agree and would like to add that TAPS and AEON
(https://sites.googl= e.com/site/aeonsignalling/) are aligning in terms = of
specification and usage of application metadata. Some of the = =B3metadata=B2
conveyed by applications when describing the transport = services they
need
are applicable for network services as well, = such as those envisioned by
AEON. Ideally, mechanisms used to = exchange this information between
applications to the network could = be used to aid with classification = for
SFC.

Cheers,
Charles

From: Linda = Dunbar
<linda.dunbar@huawei.com<mailto:linda.dunbar@huawei.com= >> Date: Tuesday,
April 8, 2014 at 9:35 AM
To: "sustrik@250bpm.com<mailto:sustrik@250bpm.com>"
&= lt;sustrik@250bpm.com<mailto:sustrik@250bpm.com>>, = Michael Welzl
<michawe@ifi.uio.no<mailto:michawe@ifi.uio.no>>,<= br>"superuser@gmail.com<mailto:superuser@gmail.com>"<superuser@gmail.com<mailto:superuser@gmail.com>>= Cc: Martin Stiemerling
<mls.ietf@gmail.com<mailto:mls.ietf@gmail.com>>, = Spencer Dawkins
<spencerdawkins.ietf@gmail.co= m<mailto:spencerdawkins.ietf@g= mail.com>>,
"taps@ietf.org<mailto:taps@ietf.org>"
<taps@ietf.org<mailto:taps@ietf.org>>
Subject:= [Taps] TAPS is what SDN is really about

Thanks to Martin=B9s = presentation on =B3Towards Transport =AD Agnostic
Middleware=B2. I = think what Martin=B9s presented is the key value of SDN,
providing = the hooks and ways for Applications to control the desired
services = from network (transport), more than what TCP/UDP can = provide.

I=B9ve been closely following and contributing to SFC, = SDNrg, and have
been
chairing ONF=B9s L4-L7 Service group. There = has been a lot of talks on
Metadata in SFC, but the metadata = discussion has been mudded by
information
among various = entities.


The  =B3messaging middleware Layer=B2 is a = really good way to show metadata
among Middle ware boxes. There could = be metadata among applications,
metadata among transport layers or = network layers. Then there could be
metadata across layers: such as = meta data from middle ware boxes to
Transport layer, the meta data = from applications to middleware layer,
etc.

I think the work = proposed by TAPS is a concrete step towards allowing
applications to = have better control of the network services.

Linda = Dunbar



-- 
-------------------------= ------------------------------------------
Dipl.-Ing. Mirja = K=FChlewind
Institute of Communication Networks and Computer = Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring = 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: mirja.kuehlewind@ikr= .uni-stuttgart.de
web: www.ikr.uni-stuttgart.de
-= ------------------------------------------------------------------

= --Apple-Mail=_5B2536E7-63ED-4E7E-9738-72577F81AEF3-- From nobody Mon Apr 14 13:12:34 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C551A0213 for ; Mon, 14 Apr 2014 13:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 tCH9Jf8ld9KJ for ; Mon, 14 Apr 2014 13:12:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 720861A06AC for ; Mon, 14 Apr 2014 13:11:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDC22494; Mon, 14 Apr 2014 20:11:49 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 14 Apr 2014 21:10:24 +0100 Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 14 Apr 2014 21:11:41 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml706-chm.china.huawei.com ([169.254.8.2]) with mapi id 14.03.0158.001; Mon, 14 Apr 2014 13:11:35 -0700 From: Linda Dunbar To: "Charles Eckel (eckelcu)" , Mirja Kuehlewind , "taps@ietf.org" Thread-Topic: [Taps] TAPS is what SDN is really about Thread-Index: AQHPV/3jnczMhX7HWUW7gP9CGdYHGJsRxzqAgAAMYAD//7arMA== Date: Mon, 14 Apr 2014 20:11:35 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645CF48E9@dfweml701-chm.china.huawei.com> References: <201404141845.25290.mirja.kuehlewind@ikr.uni-stuttgart.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/taps/WjvyAzM189X3y44TK_ucLvvrF9I Cc: Michael Welzl Subject: Re: [Taps] TAPS is what SDN is really about X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 20:12:32 -0000 At a minimum I would expect some of the information conveyed by the applica= tion to the local transport services via TAPS APIs to be communicated with = the network. [Linda] 100% agree. As more application developers start to use those trans= port (and network) services, more demand may come up.=20 Linda