From lars@netapp.com Mon Jan 14 01:25:05 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D438621F8445; Mon, 14 Jan 2013 01:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.494 X-Spam-Level: X-Spam-Status: No, score=-10.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPsQoSazr7It; Mon, 14 Jan 2013 01:25:04 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id DD7BF21F8480; Mon, 14 Jan 2013 01:25:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,466,1355126400"; d="scan'208";a="7542577" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 14 Jan 2013 01:25:00 -0800 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r0E9Owgn013239; Mon, 14 Jan 2013 01:25:00 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.51]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0328.009; Mon, 14 Jan 2013 01:24:57 -0800 From: "Eggert, Lars" To: "" , "" Thread-Topic: Software-Defined Networking Research Group (SDNRG) Thread-Index: AQHN8jkFmbntnBj5HUqdErDmyVmaLg== Date: Mon, 14 Jan 2013 09:24:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <3D7D2B6D4029484E9D220AA04D722883@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sdn@irtf.org" Subject: [Sdn] New: Software-Defined Networking Research Group (SDNRG) X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "irtf-discuss@irtf.org" List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 09:25:05 -0000 A new IRTF research group on Software-Defined Networking has been chartered= : The Software-Defined Networking Research Group (SDNRG) investigates SDN from various perspectives with the goal of identifying the approaches tha= t can be defined, deployed and used in the near term as well identifying future research challenges. In particular, key areas of interest include solution scalability, abstractions, and programming languages and paradig= ms particularly useful in the context of SDN. In addition, it is an explicit goal of the SDNRG to provide a forum for researchers to investigate key and interesting problems in the Software-Defined Networking field. Charter and participation information can be found at http://irtf.org/sdnrg Lars Eggert IRTF Chair From sitaraman@nmsworks.co.in Mon Jan 14 08:49:29 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F403F21F8844 for ; Mon, 14 Jan 2013 08:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-uR3dXmIJre for ; Mon, 14 Jan 2013 08:49:28 -0800 (PST) Received: from indlocal.nmsworks.co.in (indus.nmsworks.co.in [14.140.238.3]) by ietfa.amsl.com (Postfix) with ESMTP id D1C3821F8828 for ; Mon, 14 Jan 2013 08:49:27 -0800 (PST) Received: from www.nmsworks.co.in (localhost [127.0.0.1]) by indlocal.nmsworks.co.in (8.13.8/8.13.8) with ESMTP id r0EGlfG9003702; Mon, 14 Jan 2013 22:17:41 +0530 Received: from 117.193.212.120 (SquirrelMail authenticated user sitaraman) by www.nmsworks.co.in with HTTP; Mon, 14 Jan 2013 22:17:43 +0530 (IST) Message-ID: <50265.117.193.212.120.1358182063.squirrel@www.nmsworks.co.in> In-Reply-To: References: Date: Mon, 14 Jan 2013 22:17:43 +0530 (IST) From: sitaraman@nmsworks.co.in To: "Eggert, Lars" User-Agent: SquirrelMail/1.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-NMSWorks-MailScanner-Information: Please contact the ISP for more information X-NMSWorks-MailScanner-ID: r0EGlfG9003702 X-NMSWorks-MailScanner: Found to be clean X-NMSWorks-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.9, required 4, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-NMSWorks-MailScanner-From: sitaraman@nmsworks.co.in Cc: "openflow-discuss@mailman.stanford.edu" , sdn@irtf.org Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG) X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:49:29 -0000 Hi, Some thoughts. 1. Does the separation of control plane from the forwarding necessarily mean the control now is to be centralized? It likely is not. Though the network device itself need not implment the control plane and can be interacted via an OpenFlow interface, the control funcationality can be a separate distributed system. 2. Model to represent Network Network and traffic flows are fundamentally flows in capacitated graphs. Could we look at using Stanford Graph Processing System (GPS) for SDN based networks. The periodic communication amongst nodes seem to naturally map to a traffic and information flow in a network? 3. Model to repsresent capacities of network resources and logical abstractions of physical resources. SDN dosent and probably should not change anything fundamental in the traffic flow itself. This means that here SDN must look into reusing existing models. TMF models is a likely candidate. 4. Model to represent faults. Same as above. New type of faults related to the decoupled (possibly yet distributed) control plane to be harmonized with model for existing faults. Again TMF is a source. 5. Model to respresent Business aspects (Products, Orders such as time to delivery commitments) Same as above and again TMF is a source for this model. The new SDN network could leverage by being able to be invoked or referred to in the existing TMF business model aspects. After all these are directly related to revenue and Customer Experience Management. 6. Is it distributed control, distribution of control or soemwhere in between that is preferable. Distributed control can be a conceptual centralized control which is implemented in a distribued manner. Can this nature be adaptively changed. Any aspects of learning in control plane in SDN networks. 7. Layers of control Ethernet Layer, MPLS layer, IP layer. 8. Service Providers' bottom line is business and this means the TMF FAB Fulfilment, Assurance and Billing. SDN models must leverage the existing model as transparently as is practically feasibile. Sitaraman > Possibly of interest. > > Begin forwarded message: > >> From: "Eggert, Lars" >> Subject: [irtf-discuss] New: Software-Defined Networking Research Group >> (SDNRG) >> Date: January 14, 2013 10:24:57 GMT+01:00 >> To: "" , >> "" >> Cc: "sdn@irtf.org" >> Reply-To: "irtf-discuss@irtf.org" >> >> A new IRTF research group on Software-Defined Networking has been >> chartered: >> >> The Software-Defined Networking Research Group (SDNRG) investigates SDN >> from various perspectives with the goal of identifying the approaches >> that >> can be defined, deployed and used in the near term as well identifying >> future research challenges. In particular, key areas of interest >> include >> solution scalability, abstractions, and programming languages and >> paradigms >> particularly useful in the context of SDN. In addition, it is an >> explicit >> goal of the SDNRG to provide a forum for researchers to investigate key >> and interesting problems in the Software-Defined Networking field. >> >> Charter and participation information can be found at >> http://irtf.org/sdnrg >> >> Lars Eggert >> IRTF Chair >> > > _______________________________________________ > openflow-discuss mailing list > openflow-discuss@lists.stanford.edu > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From Sharon@Contextream.com Mon Jan 14 20:25:38 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE5711E8099 for ; Mon, 14 Jan 2013 20:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3PlFxNZkXIC for ; Mon, 14 Jan 2013 20:25:37 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB5321F86D3 for ; Mon, 14 Jan 2013 20:25:35 -0800 (PST) Received: from mail216-co1-R.bigfish.com (10.243.78.196) by CO1EHSOBE008.bigfish.com (10.243.66.71) with Microsoft SMTP Server id 14.1.225.23; Tue, 15 Jan 2013 04:25:34 +0000 Received: from mail216-co1 (localhost [127.0.0.1]) by mail216-co1-R.bigfish.com (Postfix) with ESMTP id 776EE4400CE; Tue, 15 Jan 2013 04:25:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.53; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0610HT003.eurprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: VPS1(zf7Iz98dI1432I9a6kzz1ee6h1de0h1202h1e76h1d1ah1d2ahzz177df4h17326ah8275bh8275dhz32i2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1155h) Received: from mail216-co1 (localhost.localdomain [127.0.0.1]) by mail216-co1 (MessageSwitch) id 135822393272789_14294; Tue, 15 Jan 2013 04:25:32 +0000 (UTC) Received: from CO1EHSMHS004.bigfish.com (unknown [10.243.78.208]) by mail216-co1.bigfish.com (Postfix) with ESMTP id 0E459480063; Tue, 15 Jan 2013 04:25:32 +0000 (UTC) Received: from DB3PRD0610HT003.eurprd06.prod.outlook.com (157.56.252.53) by CO1EHSMHS004.bigfish.com (10.243.66.14) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 15 Jan 2013 04:25:31 +0000 Received: from DB3PRD0610MB379.eurprd06.prod.outlook.com ([169.254.11.42]) by DB3PRD0610HT003.eurprd06.prod.outlook.com ([10.255.47.38]) with mapi id 14.16.0257.004; Tue, 15 Jan 2013 04:25:30 +0000 From: Sharon Barkai To: "sitaraman@nmsworks.co.in" Thread-Topic: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG) Thread-Index: AQHN8ncs/WieLg8uU0a3kZ7TS77kb5hJy8V5 Date: Tue, 15 Jan 2013 04:25:29 +0000 Message-ID: <92F03B02-83C1-4BA2-8212-FD50D22FC6FD@Contextream.com> References: , <50265.117.193.212.120.1358182063.squirrel@www.nmsworks.co.in> In-Reply-To: <50265.117.193.212.120.1358182063.squirrel@www.nmsworks.co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [213.41.153.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Contextream.com Cc: "openflow-discuss@mailman.stanford.edu" , "Eggert, Lars" , "sdn@irtf.org" Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG) X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 04:25:38 -0000 These bring up interesting global-local distinctions. The scope of a flow definition is clearly local to the aggregation point: IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a connection ..de= pends. The context of handling a flow in a specific point is clearly has global us= er-app considerations. Distributing control logic is therefore according to global context mapping= not aggregation topology. This is different then control distribution cons= iderations for packet forwarding. The touch point between control and forwarding is therefore a practical cho= ice. The control has to be both locally (scope & mechanics) and globally (user-a= pp) aware. Overlays work quite well in that sense, global awareness by distributed clu= stering, local touch point splits, or merges encapsulates flows based on global pipe= line need. On Jan 14, 2013, at 17:49, "sitaraman@nmsworks.co.in" wrote: Hi, Some thoughts. 1. Does the separation of control plane from the forwarding necessarily mean the control now is to be centralized? It likely is not. Though the network device itself need not implment the control plane and can be interacted via an OpenFlow interface, the control funcationality can be a separate distributed system. 2. Model to represent Network Network and traffic flows are fundamentally flows in capacitated graphs. Could we look at using Stanford Graph Processing System (GPS) for SDN based networks. The periodic communication amongst nodes seem to naturally map to a traffic and information flow in a network? 3. Model to repsresent capacities of network resources and logical abstractions of physical resources. SDN dosent and probably should not change anything fundamental in the traffic flow itself. This means that here SDN must look into reusing existing models. TMF models is a likely candidate. 4. Model to represent faults. Same as above. New type of faults related to the decoupled (possibly yet distributed) control plane to be harmonized with model for existing faults. Again TMF is a source. 5. Model to respresent Business aspects (Products, Orders such as time to delivery commitments) Same as above and again TMF is a source for this model. The new SDN network could leverage by being able to be invoked or referred to in the existing TMF business model aspects. After all these are directly related to revenue and Customer Experience Management. 6. Is it distributed control, distribution of control or soemwhere in between that is preferable. Distributed control can be a conceptual centralized control which is implemented in a distribued manner. Can this nature be adaptively changed. Any aspects of learning in control plane in SDN networks. 7. Layers of control Ethernet Layer, MPLS layer, IP layer. 8. Service Providers' bottom line is business and this means the TMF FAB Fulfilment, Assurance and Billing. SDN models must leverage the existing model as transparently as is practically feasibile. Sitaraman Possibly of interest. >=20 > Begin forwarded message: >=20 >> From: "Eggert, Lars" >> Subject: [irtf-discuss] New: Software-Defined Networking Research Group >> (SDNRG) >> Date: January 14, 2013 10:24:57 GMT+01:00 >> To: "" , >> "" >> Cc: "sdn@irtf.org" >> Reply-To: "irtf-discuss@irtf.org" >>=20 >> A new IRTF research group on Software-Defined Networking has been >> chartered: >>=20 >> The Software-Defined Networking Research Group (SDNRG) investigates SDN >> from various perspectives with the goal of identifying the approaches >> that >> can be defined, deployed and used in the near term as well identifying >> future research challenges. In particular, key areas of interest >> include >> solution scalability, abstractions, and programming languages and >> paradigms >> particularly useful in the context of SDN. In addition, it is an >> explicit >> goal of the SDNRG to provide a forum for researchers to investigate key >> and interesting problems in the Software-Defined Networking field. >>=20 >> Charter and participation information can be found at >> http://irtf.org/sdnrg >>=20 >> Lars Eggert >> IRTF Chair >=20 > _______________________________________________ > openflow-discuss mailing list > openflow-discuss@lists.stanford.edu > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >=20 > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ sdn mailing list sdn@irtf.org https://www.irtf.org/mailman/listinfo/sdn From sitaraman@nmsworks.co.in Mon Jan 14 21:27:36 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761A521F8596 for ; Mon, 14 Jan 2013 21:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alcYNyH5CyLA for ; Mon, 14 Jan 2013 21:27:35 -0800 (PST) Received: from indlocal.nmsworks.co.in (indus.nmsworks.co.in [14.140.238.3]) by ietfa.amsl.com (Postfix) with ESMTP id 511AE21F8828 for ; Mon, 14 Jan 2013 21:27:33 -0800 (PST) Received: from www.nmsworks.co.in (localhost [127.0.0.1]) by indlocal.nmsworks.co.in (8.13.8/8.13.8) with ESMTP id r0F5OYq8024811; Tue, 15 Jan 2013 10:54:38 +0530 Received: from 192.168.9.56 (SquirrelMail authenticated user sitaraman) by www.nmsworks.co.in with HTTP; Tue, 15 Jan 2013 10:54:40 +0530 (IST) Message-ID: <63510.192.168.9.56.1358227480.squirrel@www.nmsworks.co.in> In-Reply-To: <92F03B02-83C1-4BA2-8212-FD50D22FC6FD@Contextream.com> References: , <50265.117.193.212.120.1358182063.squirrel@www.nmsworks.co.in> <92F03B02-83C1-4BA2-8212-FD50D22FC6FD@Contextream.com> Date: Tue, 15 Jan 2013 10:54:40 +0530 (IST) From: sitaraman@nmsworks.co.in To: "Sharon Barkai" User-Agent: SquirrelMail/1.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-NMSWorks-MailScanner-Information: Please contact the ISP for more information X-NMSWorks-MailScanner-ID: r0F5OYq8024811 X-NMSWorks-MailScanner: Found to be clean X-NMSWorks-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.9, required 4, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-NMSWorks-MailScanner-From: sitaraman@nmsworks.co.in Cc: "Eggert, Lars" , "openflow-discuss@mailman.stanford.edu" , "sdn@irtf.org" Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG) X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 05:27:36 -0000 Hi Sharon, Thanks for these valuable insights. In the preSDN networking world, due to practicality of evolution and backward compatibility needs there arose multiple ways of doing the same thing….i.e gather and use graph reachability information. SDN is our chance to begin with a clean slate, while we need not throw the interoperation with existing networks totally out the window, we must also be careful not to avoid falling into the trap of restricting the capabilities and flexibility due to its need, even at first as options in isolation, for SDN. What we could consider in IRTF is standardizing a single way to gather reachability information (in a capacitated graph, typically). Indeed as you point out very aptly, such reachability information can be of varying geographical spans and varying aggregation level spans and these can have causal connections. If I understand you correctly, an Aggregration pivot has implications on the geographic spans that need to considered, and such aggregation pivots serve to segment/split the geographic expanse (conceptually in the graph model of the network that is) that the control has to deal with. It appears then if only we have a control of a control that based on the specified aggregation pivots redistribute the division between distributed control and distribution of control that when combined with operations on Graph model with scalable algorithmic schemes as mentioned in GPS, then we will have a powerful means to exercise traffic control, shaping and delivery which are the fundamental aspects of any network. A source of complexity we may need to handle is to be able to allow for multiple instances of such distributed control and distribution of control working together. Such segmentation between distributed control and distribution of control also could yield to a scalable solution… Sitaraman > > These bring up interesting global-local distinctions. > > The scope of a flow definition is clearly local to the aggregation point: > IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a connection > ..depends. > > The context of handling a flow in a specific point is clearly has global > user-app considerations. > Distributing control logic is therefore according to global context > mapping not aggregation topology. This is different then control > distribution considerations for packet forwarding. > > The touch point between control and forwarding is therefore a practical > choice. > The control has to be both locally (scope & mechanics) and globally > (user-app) aware. > > Overlays work quite well in that sense, global awareness by distributed > clustering, > local touch point splits, or merges encapsulates flows based on global > pipeline need. > > > > > > On Jan 14, 2013, at 17:49, "sitaraman@nmsworks.co.in" > wrote: > > Hi, > Some thoughts. > 1. Does the separation of control plane from the forwarding necessarily > mean the control now is to be centralized? It likely is not. Though the > network device itself need not implment the control plane and can be > interacted via an OpenFlow interface, the control funcationality can be > a separate distributed system. > 2. Model to represent Network > Network and traffic flows are fundamentally flows in capacitated > graphs. Could we look at using Stanford Graph Processing System > (GPS) for SDN based networks. The periodic communication amongst > nodes seem to naturally map to a traffic and information flow in a > network? > > 3. Model to repsresent capacities of network resources and logical > abstractions of physical resources. > SDN dosent and probably should not change anything fundamental in the > traffic flow itself. This means that here SDN must look into reusing > existing models. TMF models is a likely candidate. > 4. Model to represent faults. > Same as above. New type of faults related to the decoupled (possibly > yet distributed) control plane to be harmonized with model for > existing faults. Again TMF is a source. > 5. Model to respresent Business aspects (Products, Orders such as time > to delivery commitments) > Same as above and again TMF is a source for this model. The new SDN > network could leverage by being able to be invoked or referred to in > the existing TMF business model aspects. After all these are directly > related to revenue and Customer Experience Management. > 6. Is it distributed control, distribution of control or soemwhere in > between that is preferable. Distributed control can be a conceptual > centralized control which is implemented in a distribued manner. Can > this nature be adaptively changed. Any aspects of learning in control > plane in SDN networks. > 7. Layers of control Ethernet Layer, MPLS layer, IP layer. > 8. Service Providers' bottom line is business and this means the TMF FAB > Fulfilment, Assurance and Billing. SDN models must leverage the existing > model as transparently as is practically feasibile. > Sitaraman > > Possibly of interest. >> >> Begin forwarded message: >> >>> From: "Eggert, Lars" >>> Subject: [irtf-discuss] New: Software-Defined Networking Research Group >>> (SDNRG) >>> Date: January 14, 2013 10:24:57 GMT+01:00 >>> To: "" , >>> "" >>> Cc: "sdn@irtf.org" >>> Reply-To: "irtf-discuss@irtf.org" >>> >>> A new IRTF research group on Software-Defined Networking has been >>> chartered: >>> >>> The Software-Defined Networking Research Group (SDNRG) investigates SDN >>> from various perspectives with the goal of identifying the approaches >>> that >>> can be defined, deployed and used in the near term as well identifying >>> future research challenges. In particular, key areas of interest >>> include >>> solution scalability, abstractions, and programming languages and >>> paradigms >>> particularly useful in the context of SDN. In addition, it is an >>> explicit >>> goal of the SDNRG to provide a forum for researchers to investigate key >>> and interesting problems in the Software-Defined Networking field. >>> >>> Charter and participation information can be found at >>> http://irtf.org/sdnrg >>> >>> Lars Eggert >>> IRTF Chair >> >> _______________________________________________ >> openflow-discuss mailing list >> openflow-discuss@lists.stanford.edu >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > > > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From Sharon@Contextream.com Mon Jan 14 22:11:32 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E2E21F8B67 for ; Mon, 14 Jan 2013 22:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9eRug4mXZjJ for ; Mon, 14 Jan 2013 22:11:30 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id B4DD221F8B61 for ; Mon, 14 Jan 2013 22:11:29 -0800 (PST) Received: from mail174-ch1-R.bigfish.com (10.43.68.233) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.23; Tue, 15 Jan 2013 06:11:28 +0000 Received: from mail174-ch1 (localhost [127.0.0.1]) by mail174-ch1-R.bigfish.com (Postfix) with ESMTP id C4B6D460271; Tue, 15 Jan 2013 06:11:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.53; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0610HT002.eurprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zf7Iz98dI9371I1432I1447I9a6kzz1ee6h1de0h1202h1e76h1d1ah1d2ahzz177df4h17326ah8275bh8275dhz32i2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1155h) Received: from mail174-ch1 (localhost.localdomain [127.0.0.1]) by mail174-ch1 (MessageSwitch) id 1358230286727990_23135; Tue, 15 Jan 2013 06:11:26 +0000 (UTC) Received: from CH1EHSMHS006.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.241]) by mail174-ch1.bigfish.com (Postfix) with ESMTP id A510F2C0119; Tue, 15 Jan 2013 06:11:26 +0000 (UTC) Received: from DB3PRD0610HT002.eurprd06.prod.outlook.com (157.56.252.53) by CH1EHSMHS006.bigfish.com (10.43.70.6) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 15 Jan 2013 06:11:26 +0000 Received: from DB3PRD0610MB379.eurprd06.prod.outlook.com ([169.254.11.42]) by DB3PRD0610HT002.eurprd06.prod.outlook.com ([10.255.47.37]) with mapi id 14.16.0257.004; Tue, 15 Jan 2013 06:11:24 +0000 From: Sharon Barkai To: "sitaraman@nmsworks.co.in" Thread-Topic: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG) Thread-Index: AQHN8uDnw68H+LRV/0+j2UewsCJ3aJhJ6IgF Date: Tue, 15 Jan 2013 06:11:23 +0000 Message-ID: References: , <50265.117.193.212.120.1358182063.squirrel@www.nmsworks.co.in> <92F03B02-83C1-4BA2-8212-FD50D22FC6FD@Contextream.com>, <63510.192.168.9.56.1358227480.squirrel@www.nmsworks.co.in> In-Reply-To: <63510.192.168.9.56.1358227480.squirrel@www.nmsworks.co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.147.114.201] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Contextream.com Cc: "Eggert, Lars" , "openflow-discuss@mailman.stanford.edu" , "sdn@irtf.org" Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG) X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 06:11:32 -0000 depends on what you try to achieve- if you try to extend network reach then back-comp interoperable control is = key, therefore a "need to know basis" distribution (topo) makes that feasib= le.=20 If you try to extended network functionality, your control distribution emp= hasis changes significantly, and you still have to consider the touch point= of the control application with the wire - tcams, scope, aging, etc Since non of these reach & function needs are going away it looks like SDN = overlays on IP can be used to sandbox the conflicting requirements. I haven= 't seen a hammer other then layers that can handle such different nails. On Jan 15, 2013, at 6:26 AM, "sitaraman@nmsworks.co.in" wrote: Hi Sharon, Thanks for these valuable insights. In the preSDN networking world, due to practicality of evolution and backward compatibility needs there arose multiple ways of doing the same thing..i.e gather and use graph reachability information. SDN is our chance to begin with a clean slate, while we need not throw the interoperation with existing networks totally out the window, we must also be careful not to avoid falling into the trap of restricting the capabilities and flexibility due to its need, even at first as options in isolation, for SDN. What we could consider in IRTF is standardizing a single way to gather reachability information (in a capacitated graph, typically). Indeed as you point out very aptly, such reachability information can be of varying geographical spans and varying aggregation level spans and these can have causal connections. If I understand you correctly, an Aggregration pivot has implications on the geographic spans that need to considered, and such aggregation pivots serve to segment/split the geographic expanse (conceptually in the graph model of the network that is) that the control has to deal with. It appears then if only we have a control of a control that based on the specified aggregation pivots redistribute the division between distributed control and distribution of control that when combined with operations on Graph model with scalable algorithmic schemes as mentioned in GPS, then we will have a powerful means to exercise traffic control, shaping and delivery which are the fundamental aspects of any network.=20 A source of complexity we may need to handle is to be able to allow for multiple instances of such distributed control and distribution of control working together. Such segmentation between distributed control and distribution of control also could yield to a scalable solution. Sitaraman >=20 > These bring up interesting global-local distinctions. >=20 > The scope of a flow definition is clearly local to the aggregation point: > IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a connection > ..depends. >=20 > The context of handling a flow in a specific point clearly has global > user-app considerations. > Distributing control logic is therefore according to global context > mapping not aggregation topology. This is different then control > distribution considerations for packet forwarding. >=20 > The touch point between control and forwarding is therefore a practical > choice. > The control has to be both locally (scope & mechanics) and globally > (user-app) aware. >=20 > Overlays work quite well in that sense, global awareness by distributed > clustering, > local touch point splits, or merges encapsulates flows based on global > pipeline need. >=20 >=20 >=20 >=20 >=20 > On Jan 14, 2013, at 17:49, "sitaraman@nmsworks.co.in" > wrote: >=20 > Hi, > Some thoughts. > 1. Does the separation of control plane from the forwarding necessarily > mean the control now is to be centralized? It likely is not. Though the > network device itself need not implment the control plane and can be > interacted via an OpenFlow interface, the control funcationality can be > a separate distributed system. > 2. Model to represent Network > Network and traffic flows are fundamentally flows in capacitated > graphs. Could we look at using Stanford Graph Processing System > (GPS) for SDN based networks. The periodic communication amongst > nodes seem to naturally map to a traffic and information flow in a > network? >=20 > 3. Model to repsresent capacities of network resources and logical > abstractions of physical resources. > SDN dosent and probably should not change anything fundamental in the > traffic flow itself. This means that here SDN must look into reusing > existing models. TMF models is a likely candidate. > 4. Model to represent faults. > Same as above. New type of faults related to the decoupled (possibly > yet distributed) control plane to be harmonized with model for > existing faults. Again TMF is a source. > 5. Model to respresent Business aspects (Products, Orders such as time > to delivery commitments) > Same as above and again TMF is a source for this model. The new SDN > network could leverage by being able to be invoked or referred to in > the existing TMF business model aspects. After all these are directly > related to revenue and Customer Experience Management. > 6. Is it distributed control, distribution of control or soemwhere in > between that is preferable. Distributed control can be a conceptual > centralized control which is implemented in a distribued manner. Can > this nature be adaptively changed. Any aspects of learning in control > plane in SDN networks. > 7. Layers of control Ethernet Layer, MPLS layer, IP layer. > 8. Service Providers' bottom line is business and this means the TMF FAB > Fulfilment, Assurance and Billing. SDN models must leverage the existing > model as transparently as is practically feasibile. > Sitaraman >=20 > Possibly of interest. >>=20 >> Begin forwarded message: >>=20 >>> From: "Eggert, Lars" >>> Subject: [irtf-discuss] New: Software-Defined Networking Research Group >>> (SDNRG) >>> Date: January 14, 2013 10:24:57 GMT+01:00 >>> To: "" , >>> "" >>> Cc: "sdn@irtf.org" >>> Reply-To: "irtf-discuss@irtf.org" >>>=20 >>> A new IRTF research group on Software-Defined Networking has been >>> chartered: >>>=20 >>> The Software-Defined Networking Research Group (SDNRG) investigates SDN >>> from various perspectives with the goal of identifying the approaches >>> that >>> can be defined, deployed and used in the near term as well identifying >>> future research challenges. In particular, key areas of interest >>> include >>> solution scalability, abstractions, and programming languages and >>> paradigms >>> particularly useful in the context of SDN. In addition, it is an >>> explicit >>> goal of the SDNRG to provide a forum for researchers to investigate key >>> and interesting problems in the Software-Defined Networking field. >>>=20 >>> Charter and participation information can be found at >>> http://irtf.org/sdnrg >>>=20 >>> Lars Eggert >>> IRTF Chair >>=20 >> _______________________________________________ >> openflow-discuss mailing list >> openflow-discuss@lists.stanford.edu >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>=20 >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >=20 >=20 >=20 > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. >=20 > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn >=20 >=20 > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn >=20 > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From sitaraman@nmsworks.co.in Mon Jan 14 22:20:35 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF8921F88F0 for ; Mon, 14 Jan 2013 22:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hZYJX9KPqV2 for ; Mon, 14 Jan 2013 22:20:34 -0800 (PST) Received: from indlocal.nmsworks.co.in (nmsworks.co.in [14.140.238.3]) by ietfa.amsl.com (Postfix) with ESMTP id 06ADF21F881A for ; Mon, 14 Jan 2013 22:20:31 -0800 (PST) Received: from www.nmsworks.co.in (localhost [127.0.0.1]) by indlocal.nmsworks.co.in (8.13.8/8.13.8) with ESMTP id r0F6Hd6S031381; Tue, 15 Jan 2013 11:47:43 +0530 Received: from 14.140.238.4 (SquirrelMail authenticated user sitaraman) by www.nmsworks.co.in with HTTP; Tue, 15 Jan 2013 11:47:43 +0530 (IST) Message-ID: <39063.14.140.238.4.1358230663.squirrel@www.nmsworks.co.in> In-Reply-To: References: , <50265.117.193.212.120.1358182063.squirrel@www.nmsworks.co.in> <92F03B02-83C1-4BA2-8212-FD50D22FC6FD@Contextream.com>, <63510.192.168.9.56.1358227480.squirrel@www.nmsworks.co.in> Date: Tue, 15 Jan 2013 11:47:43 +0530 (IST) From: sitaraman@nmsworks.co.in To: "Sharon Barkai" User-Agent: SquirrelMail/1.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-NMSWorks-MailScanner-Information: Please contact the ISP for more information X-NMSWorks-MailScanner-ID: r0F6Hd6S031381 X-NMSWorks-MailScanner: Found to be clean X-NMSWorks-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.9, required 4, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-NMSWorks-MailScanner-From: sitaraman@nmsworks.co.in Cc: "Eggert, Lars" , "openflow-discuss@mailman.stanford.edu" , "sdn@irtf.org" Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG) X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 06:20:35 -0000 Hi Sharon, Would appreciate if you could elaborate on the extended network functionality and the conflict between the reach and functionality...Thanks Sitaraman > depends on what you try to achieve- > > if you try to extend network reach then back-comp interoperable control is > key, therefore a "need to know basis" distribution (topo) makes that > feasible. > > If you try to extended network functionality, your control distribution > emphasis changes significantly, and you still have to consider the touch > point of the control application with the wire - tcams, scope, aging, etc > > Since non of these reach & function needs are going away it looks like SDN > overlays on IP can be used to sandbox the conflicting requirements. I > haven't seen a hammer other then layers that can handle such different > nails. > > > > On Jan 15, 2013, at 6:26 AM, "sitaraman@nmsworks.co.in" > wrote: > > Hi Sharon, > Thanks for these valuable insights. > In the preSDN networking world, due to practicality of evolution and > backward compatibility needs there arose multiple ways of doing the same > thing..i.e gather and use graph reachability information. > SDN is our chance to begin with a clean slate, while we need not throw > the interoperation with existing networks totally out the window, we > must also be careful not to avoid falling into the trap of restricting > the capabilities and flexibility due to its need, even at first as > options in isolation, for SDN. > What we could consider in IRTF is standardizing a single way to gather > reachability information (in a capacitated graph, typically). Indeed as > you point out very aptly, such reachability information can be of > varying geographical spans and varying aggregation level spans and these > can have causal connections. If I understand you correctly, an > Aggregration pivot has implications on the geographic spans that need to > considered, and such aggregation pivots serve to segment/split the > geographic expanse (conceptually in the graph model of the network that > is) that the control has to deal with. > It appears then if only we have a control of a control that based on the > specified aggregation pivots redistribute the division between > distributed control and distribution of control that when combined with > operations on Graph model with scalable algorithmic schemes as mentioned > in GPS, then we will have a powerful means to exercise traffic control, > shaping and delivery which are the fundamental aspects of any network. > A source of complexity we may need to handle is to be able to allow for > multiple instances of such distributed control and distribution of > control working together. > Such segmentation between distributed control and distribution of > control also could yield to a scalable solution. > Sitaraman > > >> >> These bring up interesting global-local distinctions. >> >> The scope of a flow definition is clearly local to the aggregation >> point: >> IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a connection >> ..depends. >> >> The context of handling a flow in a specific point clearly has global >> user-app considerations. >> Distributing control logic is therefore according to global context >> mapping not aggregation topology. This is different then control >> distribution considerations for packet forwarding. >> >> The touch point between control and forwarding is therefore a practical >> choice. >> The control has to be both locally (scope & mechanics) and globally >> (user-app) aware. >> >> Overlays work quite well in that sense, global awareness by distributed >> clustering, >> local touch point splits, or merges encapsulates flows based on global >> pipeline need. >> >> >> >> >> >> On Jan 14, 2013, at 17:49, "sitaraman@nmsworks.co.in" >> wrote: >> >> Hi, >> Some thoughts. >> 1. Does the separation of control plane from the forwarding necessarily >> mean the control now is to be centralized? It likely is not. Though the >> network device itself need not implment the control plane and can be >> interacted via an OpenFlow interface, the control funcationality can be >> a separate distributed system. >> 2. Model to represent Network >> Network and traffic flows are fundamentally flows in capacitated >> graphs. Could we look at using Stanford Graph Processing System >> (GPS) for SDN based networks. The periodic communication amongst >> nodes seem to naturally map to a traffic and information flow in a >> network? >> >> 3. Model to repsresent capacities of network resources and logical >> abstractions of physical resources. >> SDN dosent and probably should not change anything fundamental in the >> traffic flow itself. This means that here SDN must look into reusing >> existing models. TMF models is a likely candidate. >> 4. Model to represent faults. >> Same as above. New type of faults related to the decoupled (possibly >> yet distributed) control plane to be harmonized with model for >> existing faults. Again TMF is a source. >> 5. Model to respresent Business aspects (Products, Orders such as time >> to delivery commitments) >> Same as above and again TMF is a source for this model. The new SDN >> network could leverage by being able to be invoked or referred to in >> the existing TMF business model aspects. After all these are directly >> related to revenue and Customer Experience Management. >> 6. Is it distributed control, distribution of control or soemwhere in >> between that is preferable. Distributed control can be a conceptual >> centralized control which is implemented in a distribued manner. Can >> this nature be adaptively changed. Any aspects of learning in control >> plane in SDN networks. >> 7. Layers of control Ethernet Layer, MPLS layer, IP layer. >> 8. Service Providers' bottom line is business and this means the TMF FAB >> Fulfilment, Assurance and Billing. SDN models must leverage the existing >> model as transparently as is practically feasibile. >> Sitaraman >> >> Possibly of interest. >>> >>> Begin forwarded message: >>> >>>> From: "Eggert, Lars" >>>> Subject: [irtf-discuss] New: Software-Defined Networking Research >>>> Group >>>> (SDNRG) >>>> Date: January 14, 2013 10:24:57 GMT+01:00 >>>> To: "" , >>>> "" >>>> Cc: "sdn@irtf.org" >>>> Reply-To: "irtf-discuss@irtf.org" >>>> >>>> A new IRTF research group on Software-Defined Networking has been >>>> chartered: >>>> >>>> The Software-Defined Networking Research Group (SDNRG) investigates >>>> SDN >>>> from various perspectives with the goal of identifying the approaches >>>> that >>>> can be defined, deployed and used in the near term as well identifying >>>> future research challenges. In particular, key areas of interest >>>> include >>>> solution scalability, abstractions, and programming languages and >>>> paradigms >>>> particularly useful in the context of SDN. In addition, it is an >>>> explicit >>>> goal of the SDNRG to provide a forum for researchers to investigate >>>> key >>>> and interesting problems in the Software-Defined Networking field. >>>> >>>> Charter and participation information can be found at >>>> http://irtf.org/sdnrg >>>> >>>> Lars Eggert >>>> IRTF Chair >>> >>> _______________________________________________ >>> openflow-discuss mailing list >>> openflow-discuss@lists.stanford.edu >>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >> >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> >> _______________________________________________ >> sdn mailing list >> sdn@irtf.org >> https://www.irtf.org/mailman/listinfo/sdn >> >> >> _______________________________________________ >> sdn mailing list >> sdn@irtf.org >> https://www.irtf.org/mailman/listinfo/sdn >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From Sharon@Contextream.com Tue Jan 15 00:14:21 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC7521F8840 for ; Tue, 15 Jan 2013 00:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYU7caw5Isrs for ; Tue, 15 Jan 2013 00:14:20 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 682BD21F883F for ; Tue, 15 Jan 2013 00:14:20 -0800 (PST) Received: from mail195-tx2-R.bigfish.com (10.9.14.236) by TX2EHSOBE014.bigfish.com (10.9.40.34) with Microsoft SMTP Server id 14.1.225.23; Tue, 15 Jan 2013 08:14:19 +0000 Received: from mail195-tx2 (localhost [127.0.0.1]) by mail195-tx2-R.bigfish.com (Postfix) with ESMTP id 18FFF260223; Tue, 15 Jan 2013 08:14:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.53; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0610HT003.eurprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -2 X-BigFish: VPS-2(zf7Iz98dI9371Ic3f2I1432I1447I9a6kzz1ee6h1de0h1202h1e76h1d1ah1d2ahzz177df4h17326ah8275bh8275dhz32i2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1155h) Received: from mail195-tx2 (localhost.localdomain [127.0.0.1]) by mail195-tx2 (MessageSwitch) id 1358237656596753_12658; Tue, 15 Jan 2013 08:14:16 +0000 (UTC) Received: from TX2EHSMHS019.bigfish.com (unknown [10.9.14.246]) by mail195-tx2.bigfish.com (Postfix) with ESMTP id 8B6B1C0071; Tue, 15 Jan 2013 08:14:16 +0000 (UTC) Received: from DB3PRD0610HT003.eurprd06.prod.outlook.com (157.56.252.53) by TX2EHSMHS019.bigfish.com (10.9.99.119) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 15 Jan 2013 08:14:15 +0000 Received: from DB3PRD0610MB379.eurprd06.prod.outlook.com ([169.254.11.42]) by DB3PRD0610HT003.eurprd06.prod.outlook.com ([10.255.47.38]) with mapi id 14.16.0257.004; Tue, 15 Jan 2013 08:14:08 +0000 From: Sharon Barkai To: "sitaraman@nmsworks.co.in" Thread-Topic: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG) Thread-Index: AQHN8uhLPP+eYURAwEmfFDtRXMZae5hKCsS/ Date: Tue, 15 Jan 2013 08:14:08 +0000 Message-ID: <07EEE1C0-6D3F-4885-9F77-F317ACA076B1@Contextream.com> References: , <50265.117.193.212.120.1358182063.squirrel@www.nmsworks.co.in> <92F03B02-83C1-4BA2-8212-FD50D22FC6FD@Contextream.com>, <63510.192.168.9.56.1358227480.squirrel@www.nmsworks.co.in> , <39063.14.140.238.4.1358230663.squirrel@www.nmsworks.co.in> In-Reply-To: <39063.14.140.238.4.1358230663.squirrel@www.nmsworks.co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.14.217.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Contextream.com Cc: "Eggert, Lars" , "openflow-discuss@mailman.stanford.edu" , "sdn@irtf.org" Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG) X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 08:14:21 -0000 Happy to but don't want to bear on the list - Can you take two simple examples and can extrapolate: One: get a ping across to multiple locations, with different gear from diff= erent generations of hardware and different administrative domains that hav= e no reason to trust one another as an example ISPs from conflicting nation= s or competing vendors. Two: globally balance a function instantiated using the same address in mul= tiple locations with global awareness in each location of the exact health = state load and affinity associated with each of the resources. =20 On Jan 15, 2013, at 7:19, "sitaraman@nmsworks.co.in" wrote: Hi Sharon, Would appreciate if you could elaborate on the extended network functionality and the conflict between the reach and functionality...Thanks Sitaraman > depends on what you try to achieve- >=20 > if you try to extend network reach then back-comp interoperable control i= s > key, therefore a "need to know basis" distribution (topo) makes that > feasible. >=20 > If you try to extended network functionality, your control distribution > emphasis changes significantly, and you still have to consider the touch > point of the control application with the wire - tcams, scope, aging, etc >=20 > Since non of these reach & function needs are going away it looks like SD= N > overlays on IP can be used to sandbox the conflicting requirements. I > haven't seen a hammer other then layers that can handle such different > nails. >=20 >=20 >=20 > On Jan 15, 2013, at 6:26 AM, "sitaraman@nmsworks.co.in" > wrote: >=20 > Hi Sharon, > Thanks for these valuable insights. > In the preSDN networking world, due to practicality of evolution and > backward compatibility needs there arose multiple ways of doing the same > thing..i.e gather and use graph reachability information. > SDN is our chance to begin with a clean slate, while we need not throw > the interoperation with existing networks totally out the window, we > must also be careful not to avoid falling into the trap of restricting > the capabilities and flexibility due to its need, even at first as > options in isolation, for SDN. > What we could consider in IRTF is standardizing a single way to gather > reachability information (in a capacitated graph, typically). Indeed as > you point out very aptly, such reachability information can be of > varying geographical spans and varying aggregation level spans and these > can have causal connections. If I understand you correctly, an > Aggregration pivot has implications on the geographic spans that need to > considered, and such aggregation pivots serve to segment/split the > geographic expanse (conceptually in the graph model of the network that > is) that the control has to deal with. > It appears then if only we have a control of a control that based on the > specified aggregation pivots redistribute the division between > distributed control and distribution of control that when combined with > operations on Graph model with scalable algorithmic schemes as mentioned > in GPS, then we will have a powerful means to exercise traffic control, > shaping and delivery which are the fundamental aspects of any network. > A source of complexity we may need to handle is to be able to allow for > multiple instances of such distributed control and distribution of > control working together. > Such segmentation between distributed control and distribution of > control also could yield to a scalable solution. > Sitaraman >=20 >=20 >>=20 >> These bring up interesting global-local distinctions. >>=20 >> The scope of a flow definition is clearly local to the aggregation >> point: >> IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a connection >> ..depends. >>=20 >> The context of handling a flow in a specific point clearly has global >> user-app considerations. >> Distributing control logic is therefore according to global context >> mapping not aggregation topology. This is different then control >> distribution considerations for packet forwarding. >>=20 >> The touch point between control and forwarding is therefore a practical >> choice. >> The control has to be both locally (scope & mechanics) and globally >> (user-app) aware. >>=20 >> Overlays work quite well in that sense, global awareness by distributed >> clustering, >> local touch point splits, or merges encapsulates flows based on global >> pipeline need. >>=20 >>=20 >>=20 >>=20 >>=20 >> On Jan 14, 2013, at 17:49, "sitaraman@nmsworks.co.in" >> wrote: >>=20 >> Hi, >> Some thoughts. >> 1. Does the separation of control plane from the forwarding necessarily >> mean the control now is to be centralized? It likely is not. Though the >> network device itself need not implment the control plane and can be >> interacted via an OpenFlow interface, the control funcationality can be >> a separate distributed system. >> 2. Model to represent Network >> Network and traffic flows are fundamentally flows in capacitated >> graphs. Could we look at using Stanford Graph Processing System >> (GPS) for SDN based networks. The periodic communication amongst >> nodes seem to naturally map to a traffic and information flow in a >> network? >>=20 >> 3. Model to repsresent capacities of network resources and logical >> abstractions of physical resources. >> SDN dosent and probably should not change anything fundamental in the >> traffic flow itself. This means that here SDN must look into reusing >> existing models. TMF models is a likely candidate. >> 4. Model to represent faults. >> Same as above. New type of faults related to the decoupled (possibly >> yet distributed) control plane to be harmonized with model for >> existing faults. Again TMF is a source. >> 5. Model to respresent Business aspects (Products, Orders such as time >> to delivery commitments) >> Same as above and again TMF is a source for this model. The new SDN >> network could leverage by being able to be invoked or referred to in >> the existing TMF business model aspects. After all these are directly >> related to revenue and Customer Experience Management. >> 6. Is it distributed control, distribution of control or soemwhere in >> between that is preferable. Distributed control can be a conceptual >> centralized control which is implemented in a distribued manner. Can >> this nature be adaptively changed. Any aspects of learning in control >> plane in SDN networks. >> 7. Layers of control Ethernet Layer, MPLS layer, IP layer. >> 8. Service Providers' bottom line is business and this means the TMF FAB >> Fulfilment, Assurance and Billing. SDN models must leverage the existing >> model as transparently as is practically feasibile. >> Sitaraman >>=20 >> Possibly of interest. >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: "Eggert, Lars" >>>> Subject: [irtf-discuss] New: Software-Defined Networking Research >>>> Group >>>> (SDNRG) >>>> Date: January 14, 2013 10:24:57 GMT+01:00 >>>> To: "" , >>>> "" >>>> Cc: "sdn@irtf.org" >>>> Reply-To: "irtf-discuss@irtf.org" >>>>=20 >>>> A new IRTF research group on Software-Defined Networking has been >>>> chartered: >>>>=20 >>>> The Software-Defined Networking Research Group (SDNRG) investigates >>>> SDN >>>> from various perspectives with the goal of identifying the approaches >>>> that >>>> can be defined, deployed and used in the near term as well identifying >>>> future research challenges. In particular, key areas of interest >>>> include >>>> solution scalability, abstractions, and programming languages and >>>> paradigms >>>> particularly useful in the context of SDN. In addition, it is an >>>> explicit >>>> goal of the SDNRG to provide a forum for researchers to investigate >>>> key >>>> and interesting problems in the Software-Defined Networking field. >>>>=20 >>>> Charter and participation information can be found at >>>> http://irtf.org/sdnrg >>>>=20 >>>> Lars Eggert >>>> IRTF Chair >>>=20 >>> _______________________________________________ >>> openflow-discuss mailing list >>> openflow-discuss@lists.stanford.edu >>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>>=20 >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >>=20 >>=20 >>=20 >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >>=20 >> _______________________________________________ >> sdn mailing list >> sdn@irtf.org >> https://www.irtf.org/mailman/listinfo/sdn >>=20 >>=20 >> _______________________________________________ >> sdn mailing list >> sdn@irtf.org >> https://www.irtf.org/mailman/listinfo/sdn >>=20 >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >=20 >=20 >=20 > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. >=20 >=20 >=20 >=20 > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From sitaraman@nmsworks.co.in Tue Jan 15 00:27:04 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F64521F8B2E for ; Tue, 15 Jan 2013 00:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAjVbsHJK7gZ for ; Tue, 15 Jan 2013 00:27:03 -0800 (PST) Received: from indlocal.nmsworks.co.in (nmsworks.co.in [14.140.238.3]) by ietfa.amsl.com (Postfix) with ESMTP id BA5C421F8B1A for ; Tue, 15 Jan 2013 00:27:02 -0800 (PST) Received: from www.nmsworks.co.in (localhost [127.0.0.1]) by indlocal.nmsworks.co.in (8.13.8/8.13.8) with ESMTP id r0F8P6kx014544; Tue, 15 Jan 2013 13:55:07 +0530 Received: from 192.168.9.56 (SquirrelMail authenticated user sitaraman) by www.nmsworks.co.in with HTTP; Tue, 15 Jan 2013 13:55:07 +0530 (IST) Message-ID: <53502.192.168.9.56.1358238307.squirrel@www.nmsworks.co.in> In-Reply-To: <07EEE1C0-6D3F-4885-9F77-F317ACA076B1@Contextream.com> References: , <50265.117.193.212.120.1358182063.squirrel@www.nmsworks.co.in> <92F03B02-83C1-4BA2-8212-FD50D22FC6FD@Contextream.com>, <63510.192.168.9.56.1358227480.squirrel@www.nmsworks.co.in> , <39063.14.140.238.4.1358230663.squirrel@www.nmsworks.co.in> <07EEE1C0-6D3F-4885-9F77-F317ACA076B1@Contextream.com> Date: Tue, 15 Jan 2013 13:55:07 +0530 (IST) From: sitaraman@nmsworks.co.in To: "Sharon Barkai" User-Agent: SquirrelMail/1.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-NMSWorks-MailScanner-Information: Please contact the ISP for more information X-NMSWorks-MailScanner-ID: r0F8P6kx014544 X-NMSWorks-MailScanner: Found to be clean X-NMSWorks-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.9, required 4, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-NMSWorks-MailScanner-From: sitaraman@nmsworks.co.in Cc: "Eggert, Lars" , "openflow-discuss@mailman.stanford.edu" , "sdn@irtf.org" Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG) X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 08:27:04 -0000 Thanks Sharon, Looking at the examples, I seem to think the second one has a strong reach component to it, only the reach is not for the traffic that is carried but metadata about the traffic? Sitaraman > Happy to but don't want to bear on the list - > Can you take two simple examples and can extrapolate: > > One: get a ping across to multiple locations, with different gear from > different generations of hardware and different administrative domains > that have no reason to trust one another as an example ISPs from > conflicting nations or competing vendors. > > Two: globally balance a function instantiated using the same address in > multiple locations with global awareness in each location of the exact > health state load and affinity associated with each of the resources. > > > > On Jan 15, 2013, at 7:19, "sitaraman@nmsworks.co.in" > wrote: > > Hi Sharon, > Would appreciate if you could elaborate on the extended network > functionality and the conflict between the reach and > functionality...Thanks > Sitaraman >> depends on what you try to achieve- >> >> if you try to extend network reach then back-comp interoperable control >> is >> key, therefore a "need to know basis" distribution (topo) makes that >> feasible. >> >> If you try to extended network functionality, your control distribution >> emphasis changes significantly, and you still have to consider the touch >> point of the control application with the wire - tcams, scope, aging, >> etc >> >> Since non of these reach & function needs are going away it looks like >> SDN >> overlays on IP can be used to sandbox the conflicting requirements. I >> haven't seen a hammer other then layers that can handle such different >> nails. >> >> >> >> On Jan 15, 2013, at 6:26 AM, "sitaraman@nmsworks.co.in" >> wrote: >> >> Hi Sharon, >> Thanks for these valuable insights. >> In the preSDN networking world, due to practicality of evolution and >> backward compatibility needs there arose multiple ways of doing the same >> thing..i.e gather and use graph reachability information. >> SDN is our chance to begin with a clean slate, while we need not throw >> the interoperation with existing networks totally out the window, we >> must also be careful not to avoid falling into the trap of restricting >> the capabilities and flexibility due to its need, even at first as >> options in isolation, for SDN. >> What we could consider in IRTF is standardizing a single way to gather >> reachability information (in a capacitated graph, typically). Indeed as >> you point out very aptly, such reachability information can be of >> varying geographical spans and varying aggregation level spans and these >> can have causal connections. If I understand you correctly, an >> Aggregration pivot has implications on the geographic spans that need to >> considered, and such aggregation pivots serve to segment/split the >> geographic expanse (conceptually in the graph model of the network that >> is) that the control has to deal with. >> It appears then if only we have a control of a control that based on the >> specified aggregation pivots redistribute the division between >> distributed control and distribution of control that when combined with >> operations on Graph model with scalable algorithmic schemes as mentioned >> in GPS, then we will have a powerful means to exercise traffic control, >> shaping and delivery which are the fundamental aspects of any network. >> A source of complexity we may need to handle is to be able to allow for >> multiple instances of such distributed control and distribution of >> control working together. >> Such segmentation between distributed control and distribution of >> control also could yield to a scalable solution. >> Sitaraman >> >> >>> >>> These bring up interesting global-local distinctions. >>> >>> The scope of a flow definition is clearly local to the aggregation >>> point: >>> IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a connection >>> ..depends. >>> >>> The context of handling a flow in a specific point clearly has global >>> user-app considerations. >>> Distributing control logic is therefore according to global context >>> mapping not aggregation topology. This is different then control >>> distribution considerations for packet forwarding. >>> >>> The touch point between control and forwarding is therefore a practical >>> choice. >>> The control has to be both locally (scope & mechanics) and globally >>> (user-app) aware. >>> >>> Overlays work quite well in that sense, global awareness by distributed >>> clustering, >>> local touch point splits, or merges encapsulates flows based on global >>> pipeline need. >>> >>> >>> >>> >>> >>> On Jan 14, 2013, at 17:49, "sitaraman@nmsworks.co.in" >>> wrote: >>> >>> Hi, >>> Some thoughts. >>> 1. Does the separation of control plane from the forwarding necessarily >>> mean the control now is to be centralized? It likely is not. Though the >>> network device itself need not implment the control plane and can be >>> interacted via an OpenFlow interface, the control funcationality can be >>> a separate distributed system. >>> 2. Model to represent Network >>> Network and traffic flows are fundamentally flows in capacitated >>> graphs. Could we look at using Stanford Graph Processing System >>> (GPS) for SDN based networks. The periodic communication amongst >>> nodes seem to naturally map to a traffic and information flow in a >>> network? >>> >>> 3. Model to repsresent capacities of network resources and logical >>> abstractions of physical resources. >>> SDN dosent and probably should not change anything fundamental in the >>> traffic flow itself. This means that here SDN must look into reusing >>> existing models. TMF models is a likely candidate. >>> 4. Model to represent faults. >>> Same as above. New type of faults related to the decoupled (possibly >>> yet distributed) control plane to be harmonized with model for >>> existing faults. Again TMF is a source. >>> 5. Model to respresent Business aspects (Products, Orders such as time >>> to delivery commitments) >>> Same as above and again TMF is a source for this model. The new SDN >>> network could leverage by being able to be invoked or referred to in >>> the existing TMF business model aspects. After all these are directly >>> related to revenue and Customer Experience Management. >>> 6. Is it distributed control, distribution of control or soemwhere in >>> between that is preferable. Distributed control can be a conceptual >>> centralized control which is implemented in a distribued manner. Can >>> this nature be adaptively changed. Any aspects of learning in control >>> plane in SDN networks. >>> 7. Layers of control Ethernet Layer, MPLS layer, IP layer. >>> 8. Service Providers' bottom line is business and this means the TMF >>> FAB >>> Fulfilment, Assurance and Billing. SDN models must leverage the >>> existing >>> model as transparently as is practically feasibile. >>> Sitaraman >>> >>> Possibly of interest. >>>> >>>> Begin forwarded message: >>>> >>>>> From: "Eggert, Lars" >>>>> Subject: [irtf-discuss] New: Software-Defined Networking Research >>>>> Group >>>>> (SDNRG) >>>>> Date: January 14, 2013 10:24:57 GMT+01:00 >>>>> To: "" , >>>>> "" >>>>> Cc: "sdn@irtf.org" >>>>> Reply-To: "irtf-discuss@irtf.org" >>>>> >>>>> A new IRTF research group on Software-Defined Networking has been >>>>> chartered: >>>>> >>>>> The Software-Defined Networking Research Group (SDNRG) investigates >>>>> SDN >>>>> from various perspectives with the goal of identifying the approaches >>>>> that >>>>> can be defined, deployed and used in the near term as well >>>>> identifying >>>>> future research challenges. In particular, key areas of interest >>>>> include >>>>> solution scalability, abstractions, and programming languages and >>>>> paradigms >>>>> particularly useful in the context of SDN. In addition, it is an >>>>> explicit >>>>> goal of the SDNRG to provide a forum for researchers to investigate >>>>> key >>>>> and interesting problems in the Software-Defined Networking field. >>>>> >>>>> Charter and participation information can be found at >>>>> http://irtf.org/sdnrg >>>>> >>>>> Lars Eggert >>>>> IRTF Chair >>>> >>>> _______________________________________________ >>>> openflow-discuss mailing list >>>> openflow-discuss@lists.stanford.edu >>>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>>> >>>> -- >>>> This message has been scanned for viruses and >>>> dangerous content by MailScanner, and is >>>> believed to be clean. >>> >>> >>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >>> >>> _______________________________________________ >>> sdn mailing list >>> sdn@irtf.org >>> https://www.irtf.org/mailman/listinfo/sdn >>> >>> >>> _______________________________________________ >>> sdn mailing list >>> sdn@irtf.org >>> https://www.irtf.org/mailman/listinfo/sdn >>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >> >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> >> >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From sircar.rana@gmail.com Tue Jan 15 00:29:42 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D3F21F8B1A for ; Tue, 15 Jan 2013 00:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.757 X-Spam-Level: X-Spam-Status: No, score=-2.757 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKWX6vD1ioy6 for ; Tue, 15 Jan 2013 00:29:40 -0800 (PST) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id C591A21F8B11 for ; Tue, 15 Jan 2013 00:29:40 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id um15so2733582pbc.30 for ; Tue, 15 Jan 2013 00:29:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Yz5bwjcBHWPechqD5nNOTbsHlvFnBeyHpdjVjpEPDFs=; b=LGfHZ77+FjXcDgX8A+bHZIDiTtFNMh1uzx4//XVgyb29ZXcGMk5zQf8h7x7G5Lqbpx lfOyhOLbp0EZ8P4opjIaQt9Q1ba+wf4+yvdQyXaYqPBW7rH5K40qZ1xC3Gq8/7KaTBWA ogTzGYOddL7zZk74+ns4Rz2lYfPEzjTgBNnEN4tVLYey4nZqrpLPf7g8J8O5EPyNuFCs p4y52aKXJpPLUf0jRGSTZpLPFSqc0OnpA4T6y0ufzZ7EVJ6356eelzPSIvRPF0tOSY3J Fj9uTz+emtCgiSk2kj1/cm0acilnrtrX47FCG690m65/Nd5ox3ypT1UE/IWzHWfbb7iu qVMg== Received: by 10.69.0.8 with SMTP id au8mr264572647pbd.58.1358238580457; Tue, 15 Jan 2013 00:29:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.73.167 with HTTP; Tue, 15 Jan 2013 00:29:20 -0800 (PST) In-Reply-To: <63510.192.168.9.56.1358227480.squirrel@www.nmsworks.co.in> References: <50265.117.193.212.120.1358182063.squirrel@www.nmsworks.co.in> <92F03B02-83C1-4BA2-8212-FD50D22FC6FD@Contextream.com> <63510.192.168.9.56.1358227480.squirrel@www.nmsworks.co.in> From: Rana Sircar Date: Tue, 15 Jan 2013 13:59:20 +0530 Message-ID: To: sitaraman@nmsworks.co.in Content-Type: multipart/alternative; boundary=047d7b2e136f1bbfb104d34f9051 Cc: "Eggert, Lars" , Sharon Barkai , "sdn@irtf.org" , "openflow-discuss@mailman.stanford.edu" Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG) X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 08:29:42 -0000 --047d7b2e136f1bbfb104d34f9051 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Sitaraman, In my opinion, there could be three scenarios for SDN deployment - 1. Greenfield deployment 2. Upgrade from existing 3. Transformation of current network Any deployment is cost intensive. Thus, fork-lift upgrades may not be the first choice for many. Thus, we should not create the use cases such a way as to support only fork-lift upgrades. I like the idea of Overlay networks. It is always helpful to roll-out new technologies. Best Regards, Rana Pratap Sircar GSM+919899003705| On 15 January 2013 10:54, wrote: > Hi Sharon, > Thanks for these valuable insights. > In the preSDN networking world, due to practicality of evolution and > backward compatibility needs there arose multiple ways of doing the same > thing=85.i.e gather and use graph reachability information. > SDN is our chance to begin with a clean slate, while we need not throw > the interoperation with existing networks totally out the window, we > must also be careful not to avoid falling into the trap of restricting > the capabilities and flexibility due to its need, even at first as > options in isolation, for SDN. > What we could consider in IRTF is standardizing a single way to gather > reachability information (in a capacitated graph, typically). Indeed as > you point out very aptly, such reachability information can be of > varying geographical spans and varying aggregation level spans and these > can have causal connections. If I understand you correctly, an > Aggregration pivot has implications on the geographic spans that need to > considered, and such aggregation pivots serve to segment/split the > geographic expanse (conceptually in the graph model of the network that > is) that the control has to deal with. > It appears then if only we have a control of a control that based on th= e > specified aggregation pivots redistribute the division between > distributed control and distribution of control that when combined with > operations on Graph model with scalable algorithmic schemes as mentioned > in GPS, then we will have a powerful means to exercise traffic control, > shaping and delivery which are the fundamental aspects of any network. > A source of complexity we may need to handle is to be able to allow for > multiple instances of such distributed control and distribution of > control working together. > Such segmentation between distributed control and distribution of > control also could yield to a scalable solution=85 > Sitaraman > > > > > > These bring up interesting global-local distinctions. > > > > The scope of a flow definition is clearly local to the aggregation poin= t: > > IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a connection > > ..depends. > > > > The context of handling a flow in a specific point is clearly has globa= l > > user-app considerations. > > Distributing control logic is therefore according to global context > > mapping not aggregation topology. This is different then control > > distribution considerations for packet forwarding. > > > > The touch point between control and forwarding is therefore a practical > > choice. > > The control has to be both locally (scope & mechanics) and globally > > (user-app) aware. > > > > Overlays work quite well in that sense, global awareness by distributed > > clustering, > > local touch point splits, or merges encapsulates flows based on global > > pipeline need. > > > > > > > > > > > > On Jan 14, 2013, at 17:49, "sitaraman@nmsworks.co.in" > > wrote: > > > > Hi, > > Some thoughts. > > 1. Does the separation of control plane from the forwarding necessaril= y > > mean the control now is to be centralized? It likely is not. Though the > > network device itself need not implment the control plane and can be > > interacted via an OpenFlow interface, the control funcationality can be > > a separate distributed system. > > 2. Model to represent Network > > Network and traffic flows are fundamentally flows in capacitated > > graphs. Could we look at using Stanford Graph Processing System > > (GPS) for SDN based networks. The periodic communication amongst > > nodes seem to naturally map to a traffic and information flow in a > > network? > > > > 3. Model to repsresent capacities of network resources and logical > > abstractions of physical resources. > > SDN dosent and probably should not change anything fundamental in t= he > > traffic flow itself. This means that here SDN must look into reusing > > existing models. TMF models is a likely candidate. > > 4. Model to represent faults. > > Same as above. New type of faults related to the decoupled (possibl= y > > yet distributed) control plane to be harmonized with model for > > existing faults. Again TMF is a source. > > 5. Model to respresent Business aspects (Products, Orders such as time > > to delivery commitments) > > Same as above and again TMF is a source for this model. The new SDN > > network could leverage by being able to be invoked or referred to in > > the existing TMF business model aspects. After all these are directly > > related to revenue and Customer Experience Management. > > 6. Is it distributed control, distribution of control or soemwhere in > > between that is preferable. Distributed control can be a conceptual > > centralized control which is implemented in a distribued manner. Can > > this nature be adaptively changed. Any aspects of learning in control > > plane in SDN networks. > > 7. Layers of control Ethernet Layer, MPLS layer, IP layer. > > 8. Service Providers' bottom line is business and this means the TMF F= AB > > Fulfilment, Assurance and Billing. SDN models must leverage the existin= g > > model as transparently as is practically feasibile. > > Sitaraman > > > > Possibly of interest. > >> > >> Begin forwarded message: > >> > >>> From: "Eggert, Lars" > >>> Subject: [irtf-discuss] New: Software-Defined Networking Research Gro= up > >>> (SDNRG) > >>> Date: January 14, 2013 10:24:57 GMT+01:00 > >>> To: "" , > >>> "" > >>> Cc: "sdn@irtf.org" > >>> Reply-To: "irtf-discuss@irtf.org" > >>> > >>> A new IRTF research group on Software-Defined Networking has been > >>> chartered: > >>> > >>> The Software-Defined Networking Research Group (SDNRG) investigates S= DN > >>> from various perspectives with the goal of identifying the approaches > >>> that > >>> can be defined, deployed and used in the near term as well identifyin= g > >>> future research challenges. In particular, key areas of interest > >>> include > >>> solution scalability, abstractions, and programming languages and > >>> paradigms > >>> particularly useful in the context of SDN. In addition, it is an > >>> explicit > >>> goal of the SDNRG to provide a forum for researchers to investigate k= ey > >>> and interesting problems in the Software-Defined Networking field. > >>> > >>> Charter and participation information can be found at > >>> http://irtf.org/sdnrg > >>> > >>> Lars Eggert > >>> IRTF Chair > >> > >> _______________________________________________ > >> openflow-discuss mailing list > >> openflow-discuss@lists.stanford.edu > >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > >> > >> -- > >> This message has been scanned for viruses and > >> dangerous content by MailScanner, and is > >> believed to be clean. > > > > > > > > -- > > This message has been scanned for viruses and > > dangerous content by MailScanner, and is > > believed to be clean. > > > > _______________________________________________ > > sdn mailing list > > sdn@irtf.org > > https://www.irtf.org/mailman/listinfo/sdn > > > > > > _______________________________________________ > > sdn mailing list > > sdn@irtf.org > > https://www.irtf.org/mailman/listinfo/sdn > > > > -- > > This message has been scanned for viruses and > > dangerous content by MailScanner, and is > > believed to be clean. > > > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > --047d7b2e136f1bbfb104d34f9051 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Sitaram= an,

In my opinion, there could be three scenarios for SDN deployment= -
1. Greenfield deployment
2. Upgrade from existing
3. Transform= ation of current network

Any deployment is cost intensive. Thus, fork-lift upgrades may not be t= he first choice for many. Thus, we should not create the use cases such a w= ay as to support only fork-lift upgrades.

I like the idea of Overlay networks. It is always helpful to roll-out n= ew technologies.

Best Regards,
Rana Pratap Si= rcar
GSM+919899003705|


On 15 January 2013 10:54, <sita= raman@nmsworks.co.in> wrote:


>
> These bring up interesting global-local distinctions.
>
> The scope of a flow definition is clearly local to the aggregation poi= nt:
> IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a connection=
> ..depends.
>
> The context of handling a flow in a specific point is clearly has glob= al
> user-app considerations.
> Distributing control logic is therefore according to global context > mapping not aggregation topology. This is different then control
> distribution considerations for packet forwarding.
>
> The touch point between control and forwarding is therefore a practica= l
> choice.
> The control has to be both locally (scope & mechanics) and globall= y
> (user-app) aware.
>
> Overlays work quite well in that sense, global awareness by distribute= d
> clustering,
> local touch point splits, or merges encapsulates flows based on global=
> pipeline need.
>
>
>
>
>
> On Jan 14, 2013, at 17:49, "sitaraman@nmsworks.co.in"
> <sitaraman@nmsworks.co.= in> wrote:
>
> Hi,
> Some thoughts.
> =A01. Does the separation of control plane from the forwarding necessa= rily
> mean the control now is to be centralized? It likely is not. Though th= e
> network device itself need not implment the control plane and can be > interacted via an OpenFlow interface, the control funcationality can b= e
> a separate distributed system.
> =A02. Model to represent Network
> =A0 =A0 Network and traffic flows are fundamentally flows in capacitat= ed
> graphs. =A0Could we look at using Stanford Graph Processing System
> (GPS) for SDN based networks. The periodic communication amongst
> nodes seem to naturally map to a traffic and information flow in a
> network?
>
> =A03. Model to repsresent capacities of network resources and logical<= br> > abstractions of physical resources.
> =A0 =A0 SDN dosent and probably should not change anything fundamental= in the
> traffic flow itself. This means that here SDN must look into reusing > existing models. =A0TMF models is a likely candidate.
> =A04. Model to represent faults.
> =A0 =A0 Same as above. New type of faults related to the decoupled (po= ssibly
> yet distributed) control plane to be harmonized with model for
> existing faults. Again TMF is a source.
> =A05. Model to respresent Business aspects (Products, Orders such as t= ime
> to delivery commitments)
> =A0 =A0 Same as above and again TMF is a source for this model. The ne= w SDN
> network could leverage by being able to be invoked or referred to in > the existing TMF business model aspects. After all these are directly<= br> > related to revenue and Customer Experience Management.
> =A06. Is it distributed control, distribution of control or soemwhere = in
> between that is preferable. Distributed control can be a conceptual > centralized control which is implemented in a distribued manner. =A0Ca= n
> this nature be adaptively changed. Any aspects of learning in control<= br> > plane in SDN networks.
> =A07. Layers of control Ethernet Layer, MPLS layer, IP layer.
> =A08. Service Providers' bottom line is business and this means th= e TMF FAB
> Fulfilment, Assurance and Billing. SDN models must leverage the existi= ng
> model as transparently as is practically feasibile.
> Sitaraman
>
> Possibly of interest.
>>
>> Begin forwarded message:
>>
>>> From: "Eggert, Lars" <lars@netapp.com>
>>> Subject: [irtf-discuss] New: Software-Defined Networking Resea= rch Group
>>> (SDNRG)
>>> Date: January 14, 2013 10:24:57 GMT+01:00
>>> To: "<irtf-a= nnounce@irtf.org>" <irtf-announce@irtf.org>,
>>> "<irtf-discus= s@irtf.org>" <irtf-= discuss@irtf.org>
>>> Cc: "sdn@irtf.org&quo= t; <sdn@irtf.org>
>>> Reply-To: "irtf-= discuss@irtf.org" <irt= f-discuss@irtf.org>
>>>
>>> A new IRTF research group on Software-Defined Networking has b= een
>>> chartered:
>>>
>>> The Software-Defined Networking Research Group (SDNRG) investi= gates SDN
>>> from various perspectives with the goal of identifying the app= roaches
>>> that
>>> can be defined, deployed and used in the near term as well ide= ntifying
>>> future research challenges. In particular, key areas of intere= st
>>> include
>>> solution scalability, abstractions, and programming languages = and
>>> paradigms
>>> particularly useful in the context of SDN. In addition, it is = an
>>> explicit
>>> goal of the SDNRG to provide a forum for researchers to invest= igate key
>>> and interesting problems in the Software-Defined Networking fi= eld.
>>>
>>> Charter and participation information can be found at
>>> http://irt= f.org/sdnrg
>>>
>>> Lars Eggert
>>> IRTF Chair
>>
>> _______________________________________________
>> openflow-discuss mailing list
>> openflow-di= scuss@lists.stanford.edu
>> https://mailman.stanford.edu/mailman/listinfo/op= enflow-discuss
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> sdn mailing list
> sdn@irtf.org
> https://www.irtf.org/mailman/listinfo/sdn
>
>
> _______________________________________________
> sdn mailing list
> sdn@irtf.org
> https://www.irtf.org/mailman/listinfo/sdn
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>



--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
sdn mailing list
sdn@irtf.org
htt= ps://www.irtf.org/mailman/listinfo/sdn

--047d7b2e136f1bbfb104d34f9051-- From sitaraman@nmsworks.co.in Tue Jan 15 00:34:21 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B895E21F863B for ; Tue, 15 Jan 2013 00:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwY1tc0TzTpE for ; Tue, 15 Jan 2013 00:34:20 -0800 (PST) Received: from indlocal.nmsworks.co.in (nmsworks.co.in [14.140.238.3]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8C421F844F for ; Tue, 15 Jan 2013 00:34:20 -0800 (PST) Received: from www.nmsworks.co.in (localhost [127.0.0.1]) by indlocal.nmsworks.co.in (8.13.8/8.13.8) with ESMTP id r0F8WPiT015283; Tue, 15 Jan 2013 14:02:25 +0530 Received: from 192.168.9.56 (SquirrelMail authenticated user sitaraman) by www.nmsworks.co.in with HTTP; Tue, 15 Jan 2013 14:02:25 +0530 (IST) Message-ID: <46722.192.168.9.56.1358238745.squirrel@www.nmsworks.co.in> In-Reply-To: References: <50265.117.193.212.120.1358182063.squirrel@www.nmsworks.co.in> <92F03B02-83C1-4BA2-8212-FD50D22FC6FD@Contextream.com> <63510.192.168.9.56.1358227480.squirrel@www.nmsworks.co.in> Date: Tue, 15 Jan 2013 14:02:25 +0530 (IST) From: sitaraman@nmsworks.co.in To: "Rana Sircar" User-Agent: SquirrelMail/1.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-NMSWorks-MailScanner-Information: Please contact the ISP for more information X-NMSWorks-MailScanner-ID: r0F8WPiT015283 X-NMSWorks-MailScanner: Found to be clean X-NMSWorks-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.9, required 4, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-NMSWorks-MailScanner-From: sitaraman@nmsworks.co.in Cc: "Eggert, Lars" , Sharon Barkai , "sdn@irtf.org" , "openflow-discuss@mailman.stanford.edu" Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG) X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 08:34:21 -0000 Hi Rana, I agree completely with the approach you are suggesting, but i do not see why that negates or even changes the considerations i have raised on the control plane deployment styles? Sitaraman > Dear Sitaraman, > > In my opinion, there could be three scenarios for SDN deployment - > 1. Greenfield deployment > 2. Upgrade from existing > 3. Transformation of current network > > Any deployment is cost intensive. Thus, fork-lift upgrades may not be the > first choice for many. Thus, we should not create the use cases such a way > as to support only fork-lift upgrades. > > I like the idea of Overlay networks. It is always helpful to roll-out new > technologies. > > Best Regards, > Rana Pratap Sircar > GSM+919899003705| > > > On 15 January 2013 10:54, wrote: > >> Hi Sharon, >> Thanks for these valuable insights. >> In the preSDN networking world, due to practicality of evolution and >> backward compatibility needs there arose multiple ways of doing the same >> thing….i.e gather and use graph reachability information. >> SDN is our chance to begin with a clean slate, while we need not throw >> the interoperation with existing networks totally out the window, we >> must also be careful not to avoid falling into the trap of restricting >> the capabilities and flexibility due to its need, even at first as >> options in isolation, for SDN. >> What we could consider in IRTF is standardizing a single way to gather >> reachability information (in a capacitated graph, typically). Indeed as >> you point out very aptly, such reachability information can be of >> varying geographical spans and varying aggregation level spans and these >> can have causal connections. If I understand you correctly, an >> Aggregration pivot has implications on the geographic spans that need to >> considered, and such aggregation pivots serve to segment/split the >> geographic expanse (conceptually in the graph model of the network that >> is) that the control has to deal with. >> It appears then if only we have a control of a control that based on >> the >> specified aggregation pivots redistribute the division between >> distributed control and distribution of control that when combined with >> operations on Graph model with scalable algorithmic schemes as mentioned >> in GPS, then we will have a powerful means to exercise traffic control, >> shaping and delivery which are the fundamental aspects of any network. >> A source of complexity we may need to handle is to be able to allow for >> multiple instances of such distributed control and distribution of >> control working together. >> Such segmentation between distributed control and distribution of >> control also could yield to a scalable solution… >> Sitaraman >> >> >> > >> > These bring up interesting global-local distinctions. >> > >> > The scope of a flow definition is clearly local to the aggregation >> point: >> > IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a connection >> > ..depends. >> > >> > The context of handling a flow in a specific point is clearly has >> global >> > user-app considerations. >> > Distributing control logic is therefore according to global context >> > mapping not aggregation topology. This is different then control >> > distribution considerations for packet forwarding. >> > >> > The touch point between control and forwarding is therefore a >> practical >> > choice. >> > The control has to be both locally (scope & mechanics) and globally >> > (user-app) aware. >> > >> > Overlays work quite well in that sense, global awareness by >> distributed >> > clustering, >> > local touch point splits, or merges encapsulates flows based on global >> > pipeline need. >> > >> > >> > >> > >> > >> > On Jan 14, 2013, at 17:49, "sitaraman@nmsworks.co.in" >> > wrote: >> > >> > Hi, >> > Some thoughts. >> > 1. Does the separation of control plane from the forwarding >> necessarily >> > mean the control now is to be centralized? It likely is not. Though >> the >> > network device itself need not implment the control plane and can be >> > interacted via an OpenFlow interface, the control funcationality can >> be >> > a separate distributed system. >> > 2. Model to represent Network >> > Network and traffic flows are fundamentally flows in capacitated >> > graphs. Could we look at using Stanford Graph Processing System >> > (GPS) for SDN based networks. The periodic communication amongst >> > nodes seem to naturally map to a traffic and information flow in a >> > network? >> > >> > 3. Model to repsresent capacities of network resources and logical >> > abstractions of physical resources. >> > SDN dosent and probably should not change anything fundamental in >> the >> > traffic flow itself. This means that here SDN must look into reusing >> > existing models. TMF models is a likely candidate. >> > 4. Model to represent faults. >> > Same as above. New type of faults related to the decoupled >> (possibly >> > yet distributed) control plane to be harmonized with model for >> > existing faults. Again TMF is a source. >> > 5. Model to respresent Business aspects (Products, Orders such as >> time >> > to delivery commitments) >> > Same as above and again TMF is a source for this model. The new >> SDN >> > network could leverage by being able to be invoked or referred to in >> > the existing TMF business model aspects. After all these are directly >> > related to revenue and Customer Experience Management. >> > 6. Is it distributed control, distribution of control or soemwhere in >> > between that is preferable. Distributed control can be a conceptual >> > centralized control which is implemented in a distribued manner. Can >> > this nature be adaptively changed. Any aspects of learning in control >> > plane in SDN networks. >> > 7. Layers of control Ethernet Layer, MPLS layer, IP layer. >> > 8. Service Providers' bottom line is business and this means the TMF >> FAB >> > Fulfilment, Assurance and Billing. SDN models must leverage the >> existing >> > model as transparently as is practically feasibile. >> > Sitaraman >> > >> > Possibly of interest. >> >> >> >> Begin forwarded message: >> >> >> >>> From: "Eggert, Lars" >> >>> Subject: [irtf-discuss] New: Software-Defined Networking Research >> Group >> >>> (SDNRG) >> >>> Date: January 14, 2013 10:24:57 GMT+01:00 >> >>> To: "" , >> >>> "" >> >>> Cc: "sdn@irtf.org" >> >>> Reply-To: "irtf-discuss@irtf.org" >> >>> >> >>> A new IRTF research group on Software-Defined Networking has been >> >>> chartered: >> >>> >> >>> The Software-Defined Networking Research Group (SDNRG) investigates >> SDN >> >>> from various perspectives with the goal of identifying the >> approaches >> >>> that >> >>> can be defined, deployed and used in the near term as well >> identifying >> >>> future research challenges. In particular, key areas of interest >> >>> include >> >>> solution scalability, abstractions, and programming languages and >> >>> paradigms >> >>> particularly useful in the context of SDN. In addition, it is an >> >>> explicit >> >>> goal of the SDNRG to provide a forum for researchers to investigate >> key >> >>> and interesting problems in the Software-Defined Networking field. >> >>> >> >>> Charter and participation information can be found at >> >>> http://irtf.org/sdnrg >> >>> >> >>> Lars Eggert >> >>> IRTF Chair >> >> >> >> _______________________________________________ >> >> openflow-discuss mailing list >> >> openflow-discuss@lists.stanford.edu >> >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >> >> >> >> -- >> >> This message has been scanned for viruses and >> >> dangerous content by MailScanner, and is >> >> believed to be clean. >> > >> > >> > >> > -- >> > This message has been scanned for viruses and >> > dangerous content by MailScanner, and is >> > believed to be clean. >> > >> > _______________________________________________ >> > sdn mailing list >> > sdn@irtf.org >> > https://www.irtf.org/mailman/listinfo/sdn >> > >> > >> > _______________________________________________ >> > sdn mailing list >> > sdn@irtf.org >> > https://www.irtf.org/mailman/listinfo/sdn >> > >> > -- >> > This message has been scanned for viruses and >> > dangerous content by MailScanner, and is >> > believed to be clean. >> > >> >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> >> _______________________________________________ >> sdn mailing list >> sdn@irtf.org >> https://www.irtf.org/mailman/listinfo/sdn >> > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From sircar.rana@gmail.com Tue Jan 15 01:42:26 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5B121F8B14 for ; Tue, 15 Jan 2013 01:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.778 X-Spam-Level: X-Spam-Status: No, score=-2.778 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yXN9fla-DJE for ; Tue, 15 Jan 2013 01:42:24 -0800 (PST) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id AE76721F8AD4 for ; Tue, 15 Jan 2013 01:42:24 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id bi5so2850569pad.41 for ; Tue, 15 Jan 2013 01:42:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xePGNrQixdqwUVd8vBh+rPZpyNeFdGes9dZFJ/1kdu0=; b=QAI6u+F/n3W4slHjUKbXn84gl0JPEtvyEI1YnbT8bebQHJVOgBDxMU8svWAYA2GA5D LAtBM0FX11gVmdfnGMJCL5fDnnpEUx227NK0l/p46uga1XhgkmrZe/pegS0jciqlW7s+ 31pLhPI+W2KSQqNklj1qgPLaGXm/HRmzCbok2FyYgceWnWdImGghJvire/mZQGWgW8kM VufGE0bz+DcUY0YKs1mOGAKMsz+g+jkQjIidYlkAKAldjcyTBs6SX7zMRgd+1HUAQ8Fe 8xjqRv5YRzo8h4fWkESLIrN2dXrjUDEM4cjXAt/GYbkaalaEw5Zs7eaN5o1F0KH4W6gL 4yUw== Received: by 10.69.0.8 with SMTP id au8mr265065009pbd.58.1358242944397; Tue, 15 Jan 2013 01:42:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.73.167 with HTTP; Tue, 15 Jan 2013 01:42:04 -0800 (PST) In-Reply-To: <46722.192.168.9.56.1358238745.squirrel@www.nmsworks.co.in> References: <50265.117.193.212.120.1358182063.squirrel@www.nmsworks.co.in> <92F03B02-83C1-4BA2-8212-FD50D22FC6FD@Contextream.com> <63510.192.168.9.56.1358227480.squirrel@www.nmsworks.co.in> <46722.192.168.9.56.1358238745.squirrel@www.nmsworks.co.in> From: Rana Sircar Date: Tue, 15 Jan 2013 15:12:04 +0530 Message-ID: To: sitaraman@nmsworks.co.in Content-Type: multipart/alternative; boundary=047d7b2e136f38348d04d35094c7 Cc: "Eggert, Lars" , Sharon Barkai , "sdn@irtf.org" , "openflow-discuss@mailman.stanford.edu" Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG) X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 09:42:26 -0000 --047d7b2e136f38348d04d35094c7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Sitaraman, As I understand, you are keen on fixing a single way to get reach-ability information from the nodes - which is based on GPS. Thereby, in a way you are doing two things - 1. Creating a fixed way of routing in Control plane 2. Creating a fixed topology for control - that is centralized logically If my understanding is correct, then how do you propose to migrate from current topologies to the one proposed by you? Best Regards, Rana Pratap Sircar GSM+919899003705| On 15 January 2013 14:02, wrote: > Hi Rana, > I agree completely with the approach you are suggesting, but i do not se= e > why that negates or even changes the considerations i have raised on the > control plane deployment styles? > Sitaraman > > Dear Sitaraman, > > > > In my opinion, there could be three scenarios for SDN deployment - > > 1. Greenfield deployment > > 2. Upgrade from existing > > 3. Transformation of current network > > > > Any deployment is cost intensive. Thus, fork-lift upgrades may not be t= he > > first choice for many. Thus, we should not create the use cases such a > way > > as to support only fork-lift upgrades. > > > > I like the idea of Overlay networks. It is always helpful to roll-out n= ew > > technologies. > > > > Best Regards, > > Rana Pratap Sircar > > GSM+919899003705| > > > > > > On 15 January 2013 10:54, wrote: > > > >> Hi Sharon, > >> Thanks for these valuable insights. > >> In the preSDN networking world, due to practicality of evolution and > >> backward compatibility needs there arose multiple ways of doing the sa= me > >> thing=C5=AF.i.e gather and use graph reachability information. > >> SDN is our chance to begin with a clean slate, while we need not thr= ow > >> the interoperation with existing networks totally out the window, we > >> must also be careful not to avoid falling into the trap of restricting > >> the capabilities and flexibility due to its need, even at first as > >> options in isolation, for SDN. > >> What we could consider in IRTF is standardizing a single way to gath= er > >> reachability information (in a capacitated graph, typically). Indeed a= s > >> you point out very aptly, such reachability information can be of > >> varying geographical spans and varying aggregation level spans and the= se > >> can have causal connections. If I understand you correctly, an > >> Aggregration pivot has implications on the geographic spans that need = to > >> considered, and such aggregation pivots serve to segment/split the > >> geographic expanse (conceptually in the graph model of the network tha= t > >> is) that the control has to deal with. > >> It appears then if only we have a control of a control that based on > >> the > >> specified aggregation pivots redistribute the division between > >> distributed control and distribution of control that when combined wit= h > >> operations on Graph model with scalable algorithmic schemes as mention= ed > >> in GPS, then we will have a powerful means to exercise traffic control= , > >> shaping and delivery which are the fundamental aspects of any network. > >> A source of complexity we may need to handle is to be able to allow fo= r > >> multiple instances of such distributed control and distribution of > >> control working together. > >> Such segmentation between distributed control and distribution of > >> control also could yield to a scalable solution=C5=AF > >> Sitaraman > >> > >> > >> > > >> > These bring up interesting global-local distinctions. > >> > > >> > The scope of a flow definition is clearly local to the aggregation > >> point: > >> > IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a connecti= on > >> > ..depends. > >> > > >> > The context of handling a flow in a specific point is clearly has > >> global > >> > user-app considerations. > >> > Distributing control logic is therefore according to global context > >> > mapping not aggregation topology. This is different then control > >> > distribution considerations for packet forwarding. > >> > > >> > The touch point between control and forwarding is therefore a > >> practical > >> > choice. > >> > The control has to be both locally (scope & mechanics) and globally > >> > (user-app) aware. > >> > > >> > Overlays work quite well in that sense, global awareness by > >> distributed > >> > clustering, > >> > local touch point splits, or merges encapsulates flows based on glob= al > >> > pipeline need. > >> > > >> > > >> > > >> > > >> > > >> > On Jan 14, 2013, at 17:49, "sitaraman@nmsworks.co.in" > >> > wrote: > >> > > >> > Hi, > >> > Some thoughts. > >> > 1. Does the separation of control plane from the forwarding > >> necessarily > >> > mean the control now is to be centralized? It likely is not. Though > >> the > >> > network device itself need not implment the control plane and can be > >> > interacted via an OpenFlow interface, the control funcationality can > >> be > >> > a separate distributed system. > >> > 2. Model to represent Network > >> > Network and traffic flows are fundamentally flows in capacitated > >> > graphs. Could we look at using Stanford Graph Processing System > >> > (GPS) for SDN based networks. The periodic communication amongst > >> > nodes seem to naturally map to a traffic and information flow in a > >> > network? > >> > > >> > 3. Model to repsresent capacities of network resources and logical > >> > abstractions of physical resources. > >> > SDN dosent and probably should not change anything fundamental i= n > >> the > >> > traffic flow itself. This means that here SDN must look into reusing > >> > existing models. TMF models is a likely candidate. > >> > 4. Model to represent faults. > >> > Same as above. New type of faults related to the decoupled > >> (possibly > >> > yet distributed) control plane to be harmonized with model for > >> > existing faults. Again TMF is a source. > >> > 5. Model to respresent Business aspects (Products, Orders such as > >> time > >> > to delivery commitments) > >> > Same as above and again TMF is a source for this model. The new > >> SDN > >> > network could leverage by being able to be invoked or referred to in > >> > the existing TMF business model aspects. After all these are directl= y > >> > related to revenue and Customer Experience Management. > >> > 6. Is it distributed control, distribution of control or soemwhere = in > >> > between that is preferable. Distributed control can be a conceptual > >> > centralized control which is implemented in a distribued manner. Ca= n > >> > this nature be adaptively changed. Any aspects of learning in contro= l > >> > plane in SDN networks. > >> > 7. Layers of control Ethernet Layer, MPLS layer, IP layer. > >> > 8. Service Providers' bottom line is business and this means the TM= F > >> FAB > >> > Fulfilment, Assurance and Billing. SDN models must leverage the > >> existing > >> > model as transparently as is practically feasibile. > >> > Sitaraman > >> > > >> > Possibly of interest. > >> >> > >> >> Begin forwarded message: > >> >> > >> >>> From: "Eggert, Lars" > >> >>> Subject: [irtf-discuss] New: Software-Defined Networking Research > >> Group > >> >>> (SDNRG) > >> >>> Date: January 14, 2013 10:24:57 GMT+01:00 > >> >>> To: "" , > >> >>> "" > >> >>> Cc: "sdn@irtf.org" > >> >>> Reply-To: "irtf-discuss@irtf.org" > >> >>> > >> >>> A new IRTF research group on Software-Defined Networking has been > >> >>> chartered: > >> >>> > >> >>> The Software-Defined Networking Research Group (SDNRG) investigate= s > >> SDN > >> >>> from various perspectives with the goal of identifying the > >> approaches > >> >>> that > >> >>> can be defined, deployed and used in the near term as well > >> identifying > >> >>> future research challenges. In particular, key areas of interest > >> >>> include > >> >>> solution scalability, abstractions, and programming languages and > >> >>> paradigms > >> >>> particularly useful in the context of SDN. In addition, it is an > >> >>> explicit > >> >>> goal of the SDNRG to provide a forum for researchers to investigat= e > >> key > >> >>> and interesting problems in the Software-Defined Networking field. > >> >>> > >> >>> Charter and participation information can be found at > >> >>> http://irtf.org/sdnrg > >> >>> > >> >>> Lars Eggert > >> >>> IRTF Chair > >> >> > >> >> _______________________________________________ > >> >> openflow-discuss mailing list > >> >> openflow-discuss@lists.stanford.edu > >> >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > >> >> > >> >> -- > >> >> This message has been scanned for viruses and > >> >> dangerous content by MailScanner, and is > >> >> believed to be clean. > >> > > >> > > >> > > >> > -- > >> > This message has been scanned for viruses and > >> > dangerous content by MailScanner, and is > >> > believed to be clean. > >> > > >> > _______________________________________________ > >> > sdn mailing list > >> > sdn@irtf.org > >> > https://www.irtf.org/mailman/listinfo/sdn > >> > > >> > > >> > _______________________________________________ > >> > sdn mailing list > >> > sdn@irtf.org > >> > https://www.irtf.org/mailman/listinfo/sdn > >> > > >> > -- > >> > This message has been scanned for viruses and > >> > dangerous content by MailScanner, and is > >> > believed to be clean. > >> > > >> > >> > >> > >> -- > >> This message has been scanned for viruses and > >> dangerous content by MailScanner, and is > >> believed to be clean. > >> > >> _______________________________________________ > >> sdn mailing list > >> sdn@irtf.org > >> https://www.irtf.org/mailman/listinfo/sdn > >> > > > > -- > > This message has been scanned for viruses and > > dangerous content by MailScanner, and is > > believed to be clean. > > > > > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > --047d7b2e136f38348d04d35094c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Sitaraman= ,

As I understand, you are keen on fixing a single w= ay to get=C2=A0reach-ability=C2=A0information from the nodes - which is bas= ed on GPS. Thereby, in a way you are doing two things -=C2=A0=
1. Crea= ting a fixed way of routing in Control plane
2. Creating a fixe= d topology for control - that is=C2=A0centralized=C2=A0logically=C2=A0

If my understanding is correct, then how do you propose to migrat= e from current topologies to the one proposed by you?

Best Regards,
Rana Pratap Sircar
GSM+91= 9899003705|


On 15 January 2013 14:02, <sita= raman@nmsworks.co.in> wrote:
> Dear Sitaraman,
>
> In my opinion, there could be three scenarios for SDN deployment -
> 1. Greenfield deployment
> 2. Upgrade from existing
> 3. Transformation of current network
>
> Any deployment is cost intensive. Thus, fork-lift upgrades may not be = the
> first choice for many. Thus, we should not create the use cases such a= way
> as to support only fork-lift upgrades.
>
> I like the idea of Overlay networks. It is always helpful to roll-out = new
> technologies.
>
> Best Regards,
> Rana Pratap Sircar
> GSM+919899003705|
>
>
> On 15 January 2013 10:54, <sitaraman@nmsworks.co.in> wrote:
>
>> Hi Sharon,
>> =C2=A0 Thanks for these valuable insights.
>> =C2=A0 In the preSDN networking world, due to practicality of evol= ution and
>> backward compatibility needs there arose multiple ways of doing th= e same
>> thing=C5=AF.i.e gather and use graph reachability informatio= n.
>> =C2=A0 SDN is our chance to begin with a cl= ean slate, while we need not throw
>> the interoperation with existing networks totally out the window, = we
>> must also be careful not to avoid falling into the trap of restric= ting
>> the capabilities and flexibility due to its need, even at first as=
>> options in isolation, for SDN.
>> =C2=A0 What we could consider in IRTF is standardizing a single wa= y to gather
>> reachability information (in a capacitated graph, typically). Inde= ed as
>> you point out very aptly, such reachability information can be of<= br> >> varying geographical spans and varying aggregation level spans and= these
>> can have causal connections. If I understand you correctly, an
>> Aggregration pivot has implications on the geographic spans that n= eed to
>> considered, and such aggregation pivots serve to segment/split the=
>> geographic expanse (conceptually in the graph model of the network= that
>> is) that the control has to deal with.
>> =C2=A0 It appears then if only we have a control of a control that= based on
>> the
>> specified aggregation pivots redistribute the division between
>> distributed control and distribution of control that when combined= with
>> operations on Graph model with scalable algorithmic schemes as men= tioned
>> in GPS, then we will have a powerful means to exercise traffic con= trol,
>> shaping and delivery which are the fundamental aspects of any netw= ork.
>> A source of complexity we may need to handle is to be able to allo= w for
>> multiple instances of such distributed control and distribution of=
>> control working together.
>> =C2=A0 Such segmentation between distributed control and distribut= ion of
>> control also could yield to a scalable solution=C5=AF<= br>
>> =C2=A0Sitaraman
>>
>>
>> >
>> > These bring up interesting global-local distinctions.
>> >
>> > The scope of a flow definition is clearly local to the aggreg= ation
>> point:
>> > IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a c= onnection
>> > ..depends.
>> >
>> > The context of handling a flow in a specific point is clearly= has
>> global
>> > user-app considerations.
>> > Distributing control logic is therefore according to global c= ontext
>> > mapping not aggregation topology. This is different then cont= rol
>> > distribution considerations for packet forwarding.
>> >
>> > The touch point between control and forwarding is therefore a=
>> practical
>> > choice.
>> > The control has to be both locally (scope & mechanics) an= d globally
>> > (user-app) aware.
>> >
>> > Overlays work quite well in that sense, global awareness by >> distributed
>> > clustering,
>> > local touch point splits, or merges encapsulates flows based = on global
>> > pipeline need.
>> >
>> >
>> >
>> >
>> >
>> > On Jan 14, 2013, at 17:49, "sitaraman@nmsworks.co.in"
>> > <sitaraman@nms= works.co.in> wrote:
>> >
>> > Hi,
>> > Some thoughts.
>> > =C2=A01. Does the separation of control plane from the forwar= ding
>> necessarily
>> > mean the control now is to be centralized? It likely is not. = Though
>> the
>> > network device itself need not implment the control plane and= can be
>> > interacted via an OpenFlow interface, the control funcational= ity can
>> be
>> > a separate distributed system.
>> > =C2=A02. Model to represent Network
>> > =C2=A0 =C2=A0 Network and traffic flows are fundamentally flo= ws in capacitated
>> > graphs. =C2=A0Could we look at using Stanford Graph Processin= g System
>> > (GPS) for SDN based networks. The periodic communication amon= gst
>> > nodes seem to naturally map to a traffic and information flow= in a
>> > network?
>> >
>> > =C2=A03. Model to repsresent capacities of network resources = and logical
>> > abstractions of physical resources.
>> > =C2=A0 =C2=A0 SDN dosent and probably should not change anyth= ing fundamental in
>> the
>> > traffic flow itself. This means that here SDN must look into = reusing
>> > existing models. =C2=A0TMF models is a likely candidate.
>> > =C2=A04. Model to represent faults.
>> > =C2=A0 =C2=A0 Same as above. New type of faults related to th= e decoupled
>> (possibly
>> > yet distributed) control plane to be harmonized with model fo= r
>> > existing faults. Again TMF is a source.
>> > =C2=A05. Model to respresent Business aspects (Products, Orde= rs such as
>> time
>> > to delivery commitments)
>> > =C2=A0 =C2=A0 Same as above and again TMF is a source for thi= s model. The new
>> SDN
>> > network could leverage by being able to be invoked or referre= d to in
>> > the existing TMF business model aspects. After all these are = directly
>> > related to revenue and Customer Experience Management.
>> > =C2=A06. Is it distributed control, distribution of control o= r soemwhere in
>> > between that is preferable. Distributed control can be a conc= eptual
>> > centralized control which is implemented in a distribued mann= er. =C2=A0Can
>> > this nature be adaptively changed. Any aspects of learning in= control
>> > plane in SDN networks.
>> > =C2=A07. Layers of control Ethernet Layer, MPLS layer, IP lay= er.
>> > =C2=A08. Service Providers' bottom line is business and t= his means the TMF
>> FAB
>> > Fulfilment, Assurance and Billing. SDN models must leverage t= he
>> existing
>> > model as transparently as is practically feasibile.
>> > Sitaraman
>> >
>> > Possibly of interest.
>> >>
>> >> Begin forwarded message:
>> >>
>> >>> From: "Eggert, Lars" <lars@netapp.com>
>> >>> Subject: [irtf-discuss] New: Software-Defined Network= ing Research
>> Group
>> >>> (SDNRG)
>> >>> Date: January 14, 2013 10:24:57 GMT+01:00
>> >>> To: "<irtf-announce@irtf.org>" <irtf-announce@irtf.org>,
>> >>> "<ir= tf-discuss@irtf.org>" <irtf-discuss@irtf.org>
>> >>> Cc: "sdn@irtf.or= g" <sdn@irtf.org>
>> >>> Reply-To: "irtf-discuss@irtf.org" <irtf-discuss@irtf.org>
>> >>>
>> >>> A new IRTF research group on Software-Defined Network= ing has been
>> >>> chartered:
>> >>>
>> >>> The Software-Defined Networking Research Group (SDNRG= ) investigates
>> SDN
>> >>> from various perspectives with the goal of identifyin= g the
>> approaches
>> >>> that
>> >>> can be defined, deployed and used in the near term as= well
>> identifying
>> >>> future research challenges. In particular, key areas = of interest
>> >>> include
>> >>> solution scalability, abstractions, and programming l= anguages and
>> >>> paradigms
>> >>> particularly useful in the context of SDN. In additio= n, it is an
>> >>> explicit
>> >>> goal of the SDNRG to provide a forum for researchers = to investigate
>> key
>> >>> and interesting problems in the Software-Defined Netw= orking field.
>> >>>
>> >>> Charter and participation information can be found at=
>> >>> h= ttp://irtf.org/sdnrg
>> >>>
>> >>> Lars Eggert
>> >>> IRTF Chair
>> >>
>> >> _______________________________________________
>> >> openflow-discuss mailing list
>> >> op= enflow-discuss@lists.stanford.edu
>> >> https://mailman.stanford.edu/mailman/li= stinfo/openflow-discuss
>> >>
>> >> --
>> >> This message has been scanned for viruses and
>> >> dangerous content by MailScanner, and is
>> >> believed to be clean.
>> >
>> >
>> >
>> > --
>> > This message has been scanned for viruses and
>> > dangerous content by MailScanner, and is
>> > believed to be clean.
>> >
>> > _______________________________________________
>> > sdn mailing list
>> > sdn@irtf.org
>> > https://www.irtf.org/mailman/listinfo/sdn
>> >
>> >
>> > _______________________________________________
>> > sdn mailing list
>> > sdn@irtf.org
>> > https://www.irtf.org/mailman/listinfo/sdn
>> >
>> > --
>> > This message has been scanned for viruses and
>> > dangerous content by MailScanner, and is
>> > believed to be clean.
>> >
>>
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>> _______________________________________________
>> sdn mailing list
>> sdn@irtf.org
>> https://www.irtf.org/mailman/listinfo/sdn
>>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>



--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--047d7b2e136f38348d04d35094c7-- From sitaraman@nmsworks.co.in Tue Jan 15 01:50:12 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE6421F8B4A for ; Tue, 15 Jan 2013 01:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgO+VaDORi4S for ; Tue, 15 Jan 2013 01:50:11 -0800 (PST) Received: from indlocal.nmsworks.co.in (nmsworks.co.in [14.140.238.3]) by ietfa.amsl.com (Postfix) with ESMTP id 26E6121F8B1A for ; Tue, 15 Jan 2013 01:50:09 -0800 (PST) Received: from www.nmsworks.co.in (localhost [127.0.0.1]) by indlocal.nmsworks.co.in (8.13.8/8.13.8) with ESMTP id r0F9mCFB022830; Tue, 15 Jan 2013 15:18:13 +0530 Received: from 192.168.9.56 (SquirrelMail authenticated user sitaraman) by www.nmsworks.co.in with HTTP; Tue, 15 Jan 2013 15:18:17 +0530 (IST) Message-ID: <53892.192.168.9.56.1358243297.squirrel@www.nmsworks.co.in> In-Reply-To: References: <50265.117.193.212.120.1358182063.squirrel@www.nmsworks.co.in> <92F03B02-83C1-4BA2-8212-FD50D22FC6FD@Contextream.com> <63510.192.168.9.56.1358227480.squirrel@www.nmsworks.co.in> <46722.192.168.9.56.1358238745.squirrel@www.nmsworks.co.in> Date: Tue, 15 Jan 2013 15:18:17 +0530 (IST) From: sitaraman@nmsworks.co.in To: "Rana Sircar" User-Agent: SquirrelMail/1.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-NMSWorks-MailScanner-Information: Please contact the ISP for more information X-NMSWorks-MailScanner-ID: r0F9mCFB022830 X-NMSWorks-MailScanner: Found to be clean X-NMSWorks-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.9, required 4, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-NMSWorks-MailScanner-From: sitaraman@nmsworks.co.in Cc: "Eggert, Lars" , Sharon Barkai , "sdn@irtf.org" , "openflow-discuss@mailman.stanford.edu" Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG) X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 09:50:12 -0000 Hi Rana, Thanks for the discussion. GPS was more of mooting an implementation choice which (GPS or something similar) philosophy seemed to mesh very well with the problem at hand. So let us set that aside for now, as it dosent impact this particular topic of discussion. I did not intend to come across as saying that there should be only a single way to get reachability information in the control. But i did intend to say that there should be a single way (that is, there is a single solution possible, but that does not claim to be the only solution that will work to get reachability information). In addition this single way of getting the reachability could also be able to get reachability information from the existing sources of such information too... Sitaraman > Hi Sitaraman, > > As I understand, you are keen on fixing a single way to > get reach-ability information from the nodes - which is based on GPS. > Thereby, in a way you are doing two things - > 1. Creating a fixed way of routing in Control plane > 2. Creating a fixed topology for control - that is centralized logically > > If my understanding is correct, then how do you propose to migrate from > current topologies to the one proposed by you? > > Best Regards, > Rana Pratap Sircar > GSM+919899003705| > > > On 15 January 2013 14:02, wrote: > >> Hi Rana, >> I agree completely with the approach you are suggesting, but i do not >> see >> why that negates or even changes the considerations i have raised on the >> control plane deployment styles? >> Sitaraman >> > Dear Sitaraman, >> > >> > In my opinion, there could be three scenarios for SDN deployment - >> > 1. Greenfield deployment >> > 2. Upgrade from existing >> > 3. Transformation of current network >> > >> > Any deployment is cost intensive. Thus, fork-lift upgrades may not be >> the >> > first choice for many. Thus, we should not create the use cases such a >> way >> > as to support only fork-lift upgrades. >> > >> > I like the idea of Overlay networks. It is always helpful to roll-out >> new >> > technologies. >> > >> > Best Regards, >> > Rana Pratap Sircar >> > GSM+919899003705| >> > >> > >> > On 15 January 2013 10:54, wrote: >> > >> >> Hi Sharon, >> >> Thanks for these valuable insights. >> >> In the preSDN networking world, due to practicality of evolution >> and >> >> backward compatibility needs there arose multiple ways of doing the >> same >> >> thingů.i.e gather and use graph reachability information. >> >> SDN is our chance to begin with a clean slate, while we need not >> throw >> >> the interoperation with existing networks totally out the window, we >> >> must also be careful not to avoid falling into the trap of >> restricting >> >> the capabilities and flexibility due to its need, even at first as >> >> options in isolation, for SDN. >> >> What we could consider in IRTF is standardizing a single way to >> gather >> >> reachability information (in a capacitated graph, typically). Indeed >> as >> >> you point out very aptly, such reachability information can be of >> >> varying geographical spans and varying aggregation level spans and >> these >> >> can have causal connections. If I understand you correctly, an >> >> Aggregration pivot has implications on the geographic spans that need >> to >> >> considered, and such aggregation pivots serve to segment/split the >> >> geographic expanse (conceptually in the graph model of the network >> that >> >> is) that the control has to deal with. >> >> It appears then if only we have a control of a control that based >> on >> >> the >> >> specified aggregation pivots redistribute the division between >> >> distributed control and distribution of control that when combined >> with >> >> operations on Graph model with scalable algorithmic schemes as >> mentioned >> >> in GPS, then we will have a powerful means to exercise traffic >> control, >> >> shaping and delivery which are the fundamental aspects of any >> network. >> >> A source of complexity we may need to handle is to be able to allow >> for >> >> multiple instances of such distributed control and distribution of >> >> control working together. >> >> Such segmentation between distributed control and distribution of >> >> control also could yield to a scalable solutionů >> >> Sitaraman >> >> >> >> >> >> > >> >> > These bring up interesting global-local distinctions. >> >> > >> >> > The scope of a flow definition is clearly local to the aggregation >> >> point: >> >> > IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a >> connection >> >> > ..depends. >> >> > >> >> > The context of handling a flow in a specific point is clearly has >> >> global >> >> > user-app considerations. >> >> > Distributing control logic is therefore according to global context >> >> > mapping not aggregation topology. This is different then control >> >> > distribution considerations for packet forwarding. >> >> > >> >> > The touch point between control and forwarding is therefore a >> >> practical >> >> > choice. >> >> > The control has to be both locally (scope & mechanics) and globally >> >> > (user-app) aware. >> >> > >> >> > Overlays work quite well in that sense, global awareness by >> >> distributed >> >> > clustering, >> >> > local touch point splits, or merges encapsulates flows based on >> global >> >> > pipeline need. >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > On Jan 14, 2013, at 17:49, "sitaraman@nmsworks.co.in" >> >> > wrote: >> >> > >> >> > Hi, >> >> > Some thoughts. >> >> > 1. Does the separation of control plane from the forwarding >> >> necessarily >> >> > mean the control now is to be centralized? It likely is not. Though >> >> the >> >> > network device itself need not implment the control plane and can >> be >> >> > interacted via an OpenFlow interface, the control funcationality >> can >> >> be >> >> > a separate distributed system. >> >> > 2. Model to represent Network >> >> > Network and traffic flows are fundamentally flows in >> capacitated >> >> > graphs. Could we look at using Stanford Graph Processing System >> >> > (GPS) for SDN based networks. The periodic communication amongst >> >> > nodes seem to naturally map to a traffic and information flow in a >> >> > network? >> >> > >> >> > 3. Model to repsresent capacities of network resources and logical >> >> > abstractions of physical resources. >> >> > SDN dosent and probably should not change anything fundamental >> in >> >> the >> >> > traffic flow itself. This means that here SDN must look into >> reusing >> >> > existing models. TMF models is a likely candidate. >> >> > 4. Model to represent faults. >> >> > Same as above. New type of faults related to the decoupled >> >> (possibly >> >> > yet distributed) control plane to be harmonized with model for >> >> > existing faults. Again TMF is a source. >> >> > 5. Model to respresent Business aspects (Products, Orders such as >> >> time >> >> > to delivery commitments) >> >> > Same as above and again TMF is a source for this model. The new >> >> SDN >> >> > network could leverage by being able to be invoked or referred to >> in >> >> > the existing TMF business model aspects. After all these are >> directly >> >> > related to revenue and Customer Experience Management. >> >> > 6. Is it distributed control, distribution of control or soemwhere >> in >> >> > between that is preferable. Distributed control can be a conceptual >> >> > centralized control which is implemented in a distribued manner. >> Can >> >> > this nature be adaptively changed. Any aspects of learning in >> control >> >> > plane in SDN networks. >> >> > 7. Layers of control Ethernet Layer, MPLS layer, IP layer. >> >> > 8. Service Providers' bottom line is business and this means the >> TMF >> >> FAB >> >> > Fulfilment, Assurance and Billing. SDN models must leverage the >> >> existing >> >> > model as transparently as is practically feasibile. >> >> > Sitaraman >> >> > >> >> > Possibly of interest. >> >> >> >> >> >> Begin forwarded message: >> >> >> >> >> >>> From: "Eggert, Lars" >> >> >>> Subject: [irtf-discuss] New: Software-Defined Networking Research >> >> Group >> >> >>> (SDNRG) >> >> >>> Date: January 14, 2013 10:24:57 GMT+01:00 >> >> >>> To: "" , >> >> >>> "" >> >> >>> Cc: "sdn@irtf.org" >> >> >>> Reply-To: "irtf-discuss@irtf.org" >> >> >>> >> >> >>> A new IRTF research group on Software-Defined Networking has been >> >> >>> chartered: >> >> >>> >> >> >>> The Software-Defined Networking Research Group (SDNRG) >> investigates >> >> SDN >> >> >>> from various perspectives with the goal of identifying the >> >> approaches >> >> >>> that >> >> >>> can be defined, deployed and used in the near term as well >> >> identifying >> >> >>> future research challenges. In particular, key areas of interest >> >> >>> include >> >> >>> solution scalability, abstractions, and programming languages and >> >> >>> paradigms >> >> >>> particularly useful in the context of SDN. In addition, it is an >> >> >>> explicit >> >> >>> goal of the SDNRG to provide a forum for researchers to >> investigate >> >> key >> >> >>> and interesting problems in the Software-Defined Networking >> field. >> >> >>> >> >> >>> Charter and participation information can be found at >> >> >>> http://irtf.org/sdnrg >> >> >>> >> >> >>> Lars Eggert >> >> >>> IRTF Chair >> >> >> >> >> >> _______________________________________________ >> >> >> openflow-discuss mailing list >> >> >> openflow-discuss@lists.stanford.edu >> >> >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >> >> >> >> >> >> -- >> >> >> This message has been scanned for viruses and >> >> >> dangerous content by MailScanner, and is >> >> >> believed to be clean. >> >> > >> >> > >> >> > >> >> > -- >> >> > This message has been scanned for viruses and >> >> > dangerous content by MailScanner, and is >> >> > believed to be clean. >> >> > >> >> > _______________________________________________ >> >> > sdn mailing list >> >> > sdn@irtf.org >> >> > https://www.irtf.org/mailman/listinfo/sdn >> >> > >> >> > >> >> > _______________________________________________ >> >> > sdn mailing list >> >> > sdn@irtf.org >> >> > https://www.irtf.org/mailman/listinfo/sdn >> >> > >> >> > -- >> >> > This message has been scanned for viruses and >> >> > dangerous content by MailScanner, and is >> >> > believed to be clean. >> >> > >> >> >> >> >> >> >> >> -- >> >> This message has been scanned for viruses and >> >> dangerous content by MailScanner, and is >> >> believed to be clean. >> >> >> >> _______________________________________________ >> >> sdn mailing list >> >> sdn@irtf.org >> >> https://www.irtf.org/mailman/listinfo/sdn >> >> >> > >> > -- >> > This message has been scanned for viruses and >> > dangerous content by MailScanner, and is >> > believed to be clean. >> > >> > >> >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> >> > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From edc@google.com Tue Jan 15 10:33:43 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE3411E80DC for ; Tue, 15 Jan 2013 10:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.177 X-Spam-Level: X-Spam-Status: No, score=-102.177 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuJSq2uYEKSn for ; Tue, 15 Jan 2013 10:33:42 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0692E11E809A for ; Tue, 15 Jan 2013 10:33:41 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id i20so473670qad.10 for ; Tue, 15 Jan 2013 10:33:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1bzNhCrqc6haaIqu/iRDD7qCTAyhTINXY004hqTHtJQ=; b=RfSwstVwBmK+Sv3Hg4Rny2sFzEHhxKpqKeze0KdmJO5xT3xp8fbavDBEnZH2NMKGgV /D7p2Zl9PWotD177W9DN4tlIj0IgBlsX66btV14fr+j4Br7n85t25fr6Ic7fTLxmpQHB o2gk7LBu9UG+ZNneIKn6DtTNnFUzufs+FElDgx2AgCesfltoRhMzSy2ocmQxvUIojzfW ZQji6MOJ8KrvAFtdxTgRiAPV442W3tyUEooomeZnEzE9VnoFYUhg6qo19F3oYQhdqCvi dTE3gfnYLMa0wYzJNceBgSI8h572jXb+7kNWgA6itUTENSFNfDrolbpTi0cj1G3oUw/m BEtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=1bzNhCrqc6haaIqu/iRDD7qCTAyhTINXY004hqTHtJQ=; b=WouE7rCRr0zCnRrEtSfPwC9djSQ6RmKjlBGdik1Y5Jv16bfudu1uRYagPJfBY71oD9 4qpAE0Fn5sTKkMYo6J2IjMXkrlAJma7V1fvODu73mzI15XA7b0t56HVUzvmWaJDNRyj6 nrqwSeTZIp9ntxtsyaGDWuvJhkRRoXJdBbns+jp/C+iYRNYRCnj/1hUQ6W2vEb4LyrFN 0gC8xJPiLrr1PRu9jUG+q2+XFGD69t0mQbLe+D9zLRd6AfHnH76YZJyM/BWmFTOUI0ff YYkLAFjQaAF/j7kZMHjPl2C3ihHp4QjifC5C+52mn2yGLnnwZNvGXaWfHL2OFdkmGOR/ sIbg== Received: by 10.224.195.133 with SMTP id ec5mr17319893qab.85.1358274820580; Tue, 15 Jan 2013 10:33:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.132.226 with HTTP; Tue, 15 Jan 2013 10:33:00 -0800 (PST) In-Reply-To: <63510.192.168.9.56.1358227480.squirrel@www.nmsworks.co.in> References: <50265.117.193.212.120.1358182063.squirrel@www.nmsworks.co.in> <92F03B02-83C1-4BA2-8212-FD50D22FC6FD@Contextream.com> <63510.192.168.9.56.1358227480.squirrel@www.nmsworks.co.in> From: Edward Crabbe Date: Tue, 15 Jan 2013 10:33:00 -0800 Message-ID: To: sitaraman@nmsworks.co.in Content-Type: multipart/alternative; boundary=20cf300fab653024fe04d35800d4 X-Gm-Message-State: ALoCoQmc9P8sHIm7MnKZSsUyVzIN/0twGTQAMCqJVgBocQ8JqzJdZ+U50CnwOhrnKDLC2thK4bdMQvYpB7t/2wT4btCc7d60CyO4lOvK3btTYMF82d74WFi1rAaNW/YezHYzqrj6gWcofWjMbPVNtHAvvODAShQSZ7BDr39/0cvKBXJ1cKMstmGiIut7zcuSROQN5xRnyOZw Cc: "Eggert, Lars" , Sharon Barkai , "sdn@irtf.org" , "openflow-discuss@mailman.stanford.edu" Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG) X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 18:33:43 -0000 --20cf300fab653024fe04d35800d4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Quick correction here: IRTF /not/ IETF. IRTF doesn't produce standards. On Mon, Jan 14, 2013 at 9:24 PM, wrote: > Hi Sharon, > Thanks for these valuable insights. > In the preSDN networking world, due to practicality of evolution and > backward compatibility needs there arose multiple ways of doing the same > thing=85.i.e gather and use graph reachability information. > SDN is our chance to begin with a clean slate, while we need not throw > the interoperation with existing networks totally out the window, we > must also be careful not to avoid falling into the trap of restricting > the capabilities and flexibility due to its need, even at first as > options in isolation, for SDN. > What we could consider in IRTF is standardizing a single way to gather > reachability information (in a capacitated graph, typically). Indeed as > you point out very aptly, such reachability information can be of > varying geographical spans and varying aggregation level spans and these > can have causal connections. If I understand you correctly, an > Aggregration pivot has implications on the geographic spans that need to > considered, and such aggregation pivots serve to segment/split the > geographic expanse (conceptually in the graph model of the network that > is) that the control has to deal with. > It appears then if only we have a control of a control that based on th= e > specified aggregation pivots redistribute the division between > distributed control and distribution of control that when combined with > operations on Graph model with scalable algorithmic schemes as mentioned > in GPS, then we will have a powerful means to exercise traffic control, > shaping and delivery which are the fundamental aspects of any network. > A source of complexity we may need to handle is to be able to allow for > multiple instances of such distributed control and distribution of > control working together. > Such segmentation between distributed control and distribution of > control also could yield to a scalable solution=85 > Sitaraman > > > > > > These bring up interesting global-local distinctions. > > > > The scope of a flow definition is clearly local to the aggregation poin= t: > > IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a connection > > ..depends. > > > > The context of handling a flow in a specific point is clearly has globa= l > > user-app considerations. > > Distributing control logic is therefore according to global context > > mapping not aggregation topology. This is different then control > > distribution considerations for packet forwarding. > > > > The touch point between control and forwarding is therefore a practical > > choice. > > The control has to be both locally (scope & mechanics) and globally > > (user-app) aware. > > > > Overlays work quite well in that sense, global awareness by distributed > > clustering, > > local touch point splits, or merges encapsulates flows based on global > > pipeline need. > > > > > > > > > > > > On Jan 14, 2013, at 17:49, "sitaraman@nmsworks.co.in" > > wrote: > > > > Hi, > > Some thoughts. > > 1. Does the separation of control plane from the forwarding necessaril= y > > mean the control now is to be centralized? It likely is not. Though the > > network device itself need not implment the control plane and can be > > interacted via an OpenFlow interface, the control funcationality can be > > a separate distributed system. > > 2. Model to represent Network > > Network and traffic flows are fundamentally flows in capacitated > > graphs. Could we look at using Stanford Graph Processing System > > (GPS) for SDN based networks. The periodic communication amongst > > nodes seem to naturally map to a traffic and information flow in a > > network? > > > > 3. Model to repsresent capacities of network resources and logical > > abstractions of physical resources. > > SDN dosent and probably should not change anything fundamental in t= he > > traffic flow itself. This means that here SDN must look into reusing > > existing models. TMF models is a likely candidate. > > 4. Model to represent faults. > > Same as above. New type of faults related to the decoupled (possibl= y > > yet distributed) control plane to be harmonized with model for > > existing faults. Again TMF is a source. > > 5. Model to respresent Business aspects (Products, Orders such as time > > to delivery commitments) > > Same as above and again TMF is a source for this model. The new SDN > > network could leverage by being able to be invoked or referred to in > > the existing TMF business model aspects. After all these are directly > > related to revenue and Customer Experience Management. > > 6. Is it distributed control, distribution of control or soemwhere in > > between that is preferable. Distributed control can be a conceptual > > centralized control which is implemented in a distribued manner. Can > > this nature be adaptively changed. Any aspects of learning in control > > plane in SDN networks. > > 7. Layers of control Ethernet Layer, MPLS layer, IP layer. > > 8. Service Providers' bottom line is business and this means the TMF F= AB > > Fulfilment, Assurance and Billing. SDN models must leverage the existin= g > > model as transparently as is practically feasibile. > > Sitaraman > > > > Possibly of interest. > >> > >> Begin forwarded message: > >> > >>> From: "Eggert, Lars" > >>> Subject: [irtf-discuss] New: Software-Defined Networking Research Gro= up > >>> (SDNRG) > >>> Date: January 14, 2013 10:24:57 GMT+01:00 > >>> To: "" , > >>> "" > >>> Cc: "sdn@irtf.org" > >>> Reply-To: "irtf-discuss@irtf.org" > >>> > >>> A new IRTF research group on Software-Defined Networking has been > >>> chartered: > >>> > >>> The Software-Defined Networking Research Group (SDNRG) investigates S= DN > >>> from various perspectives with the goal of identifying the approaches > >>> that > >>> can be defined, deployed and used in the near term as well identifyin= g > >>> future research challenges. In particular, key areas of interest > >>> include > >>> solution scalability, abstractions, and programming languages and > >>> paradigms > >>> particularly useful in the context of SDN. In addition, it is an > >>> explicit > >>> goal of the SDNRG to provide a forum for researchers to investigate k= ey > >>> and interesting problems in the Software-Defined Networking field. > >>> > >>> Charter and participation information can be found at > >>> http://irtf.org/sdnrg > >>> > >>> Lars Eggert > >>> IRTF Chair > >> > >> _______________________________________________ > >> openflow-discuss mailing list > >> openflow-discuss@lists.stanford.edu > >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > >> > >> -- > >> This message has been scanned for viruses and > >> dangerous content by MailScanner, and is > >> believed to be clean. > > > > > > > > -- > > This message has been scanned for viruses and > > dangerous content by MailScanner, and is > > believed to be clean. > > > > _______________________________________________ > > sdn mailing list > > sdn@irtf.org > > https://www.irtf.org/mailman/listinfo/sdn > > > > > > _______________________________________________ > > sdn mailing list > > sdn@irtf.org > > https://www.irtf.org/mailman/listinfo/sdn > > > > -- > > This message has been scanned for viruses and > > dangerous content by MailScanner, and is > > believed to be clean. > > > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > --20cf300fab653024fe04d35800d4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Quick correction here: IRTF /not/ IETF. =A0IRTF doesn't produce sta= ndards. =A0


On Mon, Jan 14, 2013 at 9:24 PM, <sitaraman@nmsworks.co.in>= wrote:
Hi Sharon,
=A0 Thanks for these valuable insights.
=A0 In the preSDN networking world, due to practicality of evolution and backward compatibility needs there arose multiple ways of doing the same thing=85.i.e gather and use graph reachability information.
=A0 SDN is our chance to begin with a clean slate, while we need not throw<= br> the interoperation with existing networks totally out the window, we
must also be careful not to avoid falling into the trap of restricting
the capabilities and flexibility due to its need, even at first as
options in isolation, for SDN.
=A0 What we could consider in IRTF is standardizing a single way to gather<= br> reachability information (in a capacitated graph, typically). Indeed as
you point out very aptly, such reachability information can be of
varying geographical spans and varying aggregation level spans and these can have causal connections. If I understand you correctly, an
Aggregration pivot has implications on the geographic spans that need to considered, and such aggregation pivots serve to segment/split the
geographic expanse (conceptually in the graph model of the network that
is) that the control has to deal with.
=A0 It appears then if only we have a control of a control that based on th= e
specified aggregation pivots redistribute the division between
distributed control and distribution of control that when combined with
operations on Graph model with scalable algorithmic schemes as mentioned in GPS, then we will have a powerful means to exercise traffic control,
shaping and delivery which are the fundamental aspects of any network.
A source of complexity we may need to handle is to be able to allow for
multiple instances of such distributed control and distribution of
control working together.
=A0 Such segmentation between distributed control and distribution of
control also could yield to a scalable solution=85
=A0Sitaraman


>
> These bring up interesting global-local distinctions.
>
> The scope of a flow definition is clearly local to the aggregation poi= nt:
> IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a connection=
> ..depends.
>
> The context of handling a flow in a specific point is clearly has glob= al
> user-app considerations.
> Distributing control logic is therefore according to global context > mapping not aggregation topology. This is different then control
> distribution considerations for packet forwarding.
>
> The touch point between control and forwarding is therefore a practica= l
> choice.
> The control has to be both locally (scope & mechanics) and globall= y
> (user-app) aware.
>
> Overlays work quite well in that sense, global awareness by distribute= d
> clustering,
> local touch point splits, or merges encapsulates flows based on global=
> pipeline need.
>
>
>
>
>
> On Jan 14, 2013, at 17:49, "sitaraman@nmsworks.co.in"
> <sitaraman@nmsworks.co.= in> wrote:
>
> Hi,
> Some thoughts.
> =A01. Does the separation of control plane from the forwarding necessa= rily
> mean the control now is to be centralized? It likely is not. Though th= e
> network device itself need not implment the control plane and can be > interacted via an OpenFlow interface, the control funcationality can b= e
> a separate distributed system.
> =A02. Model to represent Network
> =A0 =A0 Network and traffic flows are fundamentally flows in capacitat= ed
> graphs. =A0Could we look at using Stanford Graph Processing System
> (GPS) for SDN based networks. The periodic communication amongst
> nodes seem to naturally map to a traffic and information flow in a
> network?
>
> =A03. Model to repsresent capacities of network resources and logical<= br> > abstractions of physical resources.
> =A0 =A0 SDN dosent and probably should not change anything fundamental= in the
> traffic flow itself. This means that here SDN must look into reusing > existing models. =A0TMF models is a likely candidate.
> =A04. Model to represent faults.
> =A0 =A0 Same as above. New type of faults related to the decoupled (po= ssibly
> yet distributed) control plane to be harmonized with model for
> existing faults. Again TMF is a source.
> =A05. Model to respresent Business aspects (Products, Orders such as t= ime
> to delivery commitments)
> =A0 =A0 Same as above and again TMF is a source for this model. The ne= w SDN
> network could leverage by being able to be invoked or referred to in > the existing TMF business model aspects. After all these are directly<= br> > related to revenue and Customer Experience Management.
> =A06. Is it distributed control, distribution of control or soemwhere = in
> between that is preferable. Distributed control can be a conceptual > centralized control which is implemented in a distribued manner. =A0Ca= n
> this nature be adaptively changed. Any aspects of learning in control<= br> > plane in SDN networks.
> =A07. Layers of control Ethernet Layer, MPLS layer, IP layer.
> =A08. Service Providers' bottom line is business and this means th= e TMF FAB
> Fulfilment, Assurance and Billing. SDN models must leverage the existi= ng
> model as transparently as is practically feasibile.
> Sitaraman
>
> Possibly of interest.
>>
>> Begin forwarded message:
>>
>>> From: "Eggert, Lars" <lars@netapp.com>
>>> Subject: [irtf-discuss] New: Software-Defined Networking Resea= rch Group
>>> (SDNRG)
>>> Date: January 14, 2013 10:24:57 GMT+01:00
>>> To: "<irtf-a= nnounce@irtf.org>" <irtf-announce@irtf.org>,
>>> "<irtf-discus= s@irtf.org>" <irtf-= discuss@irtf.org>
>>> Cc: "sdn@irtf.org&quo= t; <sdn@irtf.org>
>>> Reply-To: "irtf-= discuss@irtf.org" <irt= f-discuss@irtf.org>
>>>
>>> A new IRTF research group on Software-Defined Networking has b= een
>>> chartered:
>>>
>>> The Software-Defined Networking Research Group (SDNRG) investi= gates SDN
>>> from various perspectives with the goal of identifying the app= roaches
>>> that
>>> can be defined, deployed and used in the near term as well ide= ntifying
>>> future research challenges. In particular, key areas of intere= st
>>> include
>>> solution scalability, abstractions, and programming languages = and
>>> paradigms
>>> particularly useful in the context of SDN. In addition, it is = an
>>> explicit
>>> goal of the SDNRG to provide a forum for researchers to invest= igate key
>>> and interesting problems in the Software-Defined Networking fi= eld.
>>>
>>> Charter and participation information can be found at
>>> http://irt= f.org/sdnrg
>>>
>>> Lars Eggert
>>> IRTF Chair
>>
>> _______________________________________________
>> openflow-discuss mailing list
>> openflow-di= scuss@lists.stanford.edu
>> https://mailman.stanford.edu/mailman/listinfo/op= enflow-discuss
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> sdn mailing list
> sdn@irtf.org
> https://www.irtf.org/mailman/listinfo/sdn
>
>
> _______________________________________________
> sdn mailing list
> sdn@irtf.org
> https://www.irtf.org/mailman/listinfo/sdn
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>



--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
sdn mailing list
sdn@irtf.org
htt= ps://www.irtf.org/mailman/listinfo/sdn

--20cf300fab653024fe04d35800d4-- From bhal_d@yahoo.com Tue Jan 15 10:39:26 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B643411E809C for ; Tue, 15 Jan 2013 10:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcB0dPsszQkT for ; Tue, 15 Jan 2013 10:39:25 -0800 (PST) Received: from nm35-vm5.bullet.mail.ne1.yahoo.com (nm35-vm5.bullet.mail.ne1.yahoo.com [98.138.229.101]) by ietfa.amsl.com (Postfix) with ESMTP id 805D611E809A for ; Tue, 15 Jan 2013 10:39:24 -0800 (PST) Received: from [98.138.90.51] by nm35.bullet.mail.ne1.yahoo.com with NNFMP; 15 Jan 2013 18:39:15 -0000 Received: from [98.138.89.163] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 15 Jan 2013 18:39:15 -0000 Received: from [127.0.0.1] by omp1019.mail.ne1.yahoo.com with NNFMP; 15 Jan 2013 18:39:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 244171.60288.bm@omp1019.mail.ne1.yahoo.com Received: (qmail 54518 invoked by uid 60001); 15 Jan 2013 18:39:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1358275155; bh=QxKv0RMqwfxMUSIdtJKzuEe/wClGtl2ZgQn5Vovnkw8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=rC+dMI+OOxalHgF/nlso0x+uKiDLlhibqTjAQMqONG0Dukc2n+nH8sQivq+KCcRdM05hrem615i3nqxmgnLSFVp1gEBZrNz51+MZmAOr77+EX7MI+jxx9galtqHyx5S596BCNjJegLO0NIrE9bfw4TN+0YWr55lPDWKBPFV4aGg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=jsRp6c4uw4F8RcOhzqpw0OWHcCA3DkOLhTj0DvFj8ZBnYD+LxlbTVFu25hbrxN9exqvXdDVKKOSYR4whzMPq+L+AlfPgSgzGeFsBysSJjFNeEEA5YJdsN3cuM/uELlEjTrcuI/wOQ2rzYbw/4TYTL5Ml4/5IPLQFfOm5zLdEXX0=; X-YMail-OSG: lRhmV04VM1kcsJu4Fu.9VVe.2NdTf7qSYZlY2gbnMbGjvdT C0S.i_lMjxZTaTRSyUkVO15uKPJy6UbGZAlL2vhie5Ub74waCBI8D9AhH5Ae q0pe4YVtFvjor4sFA2rakHLdvP65aYoaPeQVfNCfDJsLWuw0N6bIXlMZo_BE M2W5bTpigyhsYAvRQmGHSYE04cdjvY2vS_.urm9t4ao_1Zu4Gx9SBUPpEvOO fQPi8HlsSD2i8OLtL_JZMpulJ7KBcllZB9YQRF9bAQ.WK2ojx8B0azkMQw8v 0d_y2iLx38fXAhxcwuCUHRnz73k66PEIF2Rh7Mky.eB43x_0E0iqzqLpLYld H.L85yywN9j5A27pr_a4msu0Wb2lTUb9nKbRTLFfbrZAj5aGp2thhGCcpdds aq5k.iK2YnDzAME2EwjexhjoPD_za.jlFkeUNU3CyXK3u401hQEQdSPf7nMn UOA3N0FCf1IXWFZFX3FJX3oon.UtKpaukeoLmskH5W4doQ6X7weH5ewV2zyn hjcm.V2MwFv1iAO2lHQ-- Received: from [99.66.146.172] by web125403.mail.ne1.yahoo.com via HTTP; Tue, 15 Jan 2013 10:39:15 PST X-Rocket-MIMEInfo: 001.001, DQpUaGlzIGlzIGdyZWF0IGRpc2N1c3Npb24uIFNpbmNlIHdlIGFyZSB0YWxraW5nIGFib3V0ICJTb2Z0d2FyZSBkZWZpbmVkIiwgSSB0aGluayBpdCBpbXBsaWVzIHNvbWUgdHlwZSBvZiBzb2Z0d2FyZSBwcm9ncmFtbWFiaWxpdHkgb2YgYSBuZXR3b3JrLiBJbiBwcmVzZW50IGRheSBJIGhhdmVuJ3Qgc2VlbiB0b28gbWFueSBhcHBsaWNhdGlvbnMgdHJ5aW5nIHRvIHByb2dyYW0gbmV0d29yay4gU28gaXQgaXMgYSBuZXcgY29uY2VwdCBmb3IgdGhlbS4gU28gaG93IGFib3V0IGZpcnN0IGRlZmluaW5nLCB3aGEBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.130.494 Message-ID: <1358275155.38520.YahooMailClassic@web125403.mail.ne1.yahoo.com> Date: Tue, 15 Jan 2013 10:39:15 -0800 (PST) From: bhal d To: Rana Sircar , sitaraman@nmsworks.co.in In-Reply-To: <53892.192.168.9.56.1358243297.squirrel@www.nmsworks.co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1993147269-698348342-1358275155=:38520" Cc: Sharon Barkai , LarsEggert , "sdn@irtf.org" , "openflow-discuss@mailman.stanford.edu" Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG) X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 18:39:26 -0000 --1993147269-698348342-1358275155=:38520 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable This is great discussion. Since we are talking about "Software defined", I = think it implies some type of software programmability of a network. In pre= sent day I haven't seen too many applications trying to program network. So= it is a new concept for them. So how about first defining, what programmab= ility of network means in simple terms ?=20 I think many programmers are not networking experts and don't necessarily u= nderstand details about different protocols, link types, topological graphs= etc. However for them behavior of their application is important and they = certainly understand importance of things like control over available bandw= idth, data loss, availability of network, having shortest path to the desti= nation etc. So my question is can we define what programmability or "softwa= re defined " means in simple terms ? We can then go on to define what it ta= kes to create that programmability including API, infrastructure etc. This discussion can also involve what level of network programmability is d= esirable and then there can be a discussion about what is achievable. At present I see most of the discussion about splitting control plane and d= ata plane or distributed controller etc. All this discussion is good but wi= thout considering what user wants and type of user programmability model we= have in mind, it is incomplete. Thanks Bhalchandra --- On Tue, 1/15/13, sitaraman@nmsworks.co.in wr= ote: From: sitaraman@nmsworks.co.in Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: Software-Def= ined Networking Research Group (SDNRG) To: "Rana Sircar" Cc: "Eggert, Lars" , "Sharon Barkai" , "sdn@irtf.org" , "openflow-discuss@mailman.stanford.edu"= Date: Tuesday, January 15, 2013, 1:48 AM Hi Rana, Thanks for the discussion. GPS was more of mooting an implementation choice which (GPS or something similar) philosophy seemed to mesh very well with the problem at hand. So let us set that aside for now, as it dosent impact this particular topic of discussion. I did not intend to come across as saying that there should be only a single way to get reachability information in the control. But i did intend to say that there should be a single way (that is, there is a single solution possible, but that does not claim to be the only solution that will work to get reachability information). In addition this single way of getting the reachability could also be able to get reachability information from the existing sources of such information too... Sitaraman > Hi Sitaraman, > > As I understand, you are keen on fixing a single way to > get reach-ability information from the nodes - which is based on GPS. > Thereby, in a way you are doing two things - > 1. Creating a fixed way of routing in Control plane > 2. Creating a fixed topology for control - that is centralized logically > > If my understanding is correct, then how do you propose to migrate from > current topologies to the one proposed by you? > > Best Regards, > Rana Pratap Sircar > GSM+919899003705| > > > On 15 January 2013 14:02, wrote: > >> Hi Rana, >>=A0 I agree completely with the approach you are suggesting, but i do not >> see >> why that negates or even changes the considerations i have raised on the >> control plane deployment styles? >> Sitaraman >> > Dear Sitaraman, >> > >> > In my opinion, there could be three scenarios for SDN deployment - >> > 1. Greenfield deployment >> > 2. Upgrade from existing >> > 3. Transformation of current network >> > >> > Any deployment is cost intensive. Thus, fork-lift upgrades may not be >> the >> > first choice for many. Thus, we should not create the use cases such a >> way >> > as to support only fork-lift upgrades. >> > >> > I like the idea of Overlay networks. It is always helpful to roll-out >> new >> > technologies. >> > >> > Best Regards, >> > Rana Pratap Sircar >> > GSM+919899003705| >> > >> > >> > On 15 January 2013 10:54, wrote: >> > >> >> Hi Sharon, >> >>=A0=A0=A0Thanks for these valuable insights. >> >>=A0=A0=A0In the preSDN networking world, due to practicality of evolut= ion >> and >> >> backward compatibility needs there arose multiple ways of doing the >> same >> >> thing=C5=AF.i.e gather and use graph reachability information. >> >>=A0=A0=A0SDN is our chance to begin with a clean slate, while we need = not >> throw >> >> the interoperation with existing networks totally out the window, we >> >> must also be careful not to avoid falling into the trap of >> restricting >> >> the capabilities and flexibility due to its need, even at first as >> >> options in isolation, for SDN. >> >>=A0=A0=A0What we could consider in IRTF is standardizing a single way = to >> gather >> >> reachability information (in a capacitated graph, typically). Indeed >> as >> >> you point out very aptly, such reachability information can be of >> >> varying geographical spans and varying aggregation level spans and >> these >> >> can have causal connections. If I understand you correctly, an >> >> Aggregration pivot has implications on the geographic spans that need >> to >> >> considered, and such aggregation pivots serve to segment/split the >> >> geographic expanse (conceptually in the graph model of the network >> that >> >> is) that the control has to deal with. >> >>=A0=A0=A0It appears then if only we have a control of a control that b= ased >> on >> >> the >> >> specified aggregation pivots redistribute the division between >> >> distributed control and distribution of control that when combined >> with >> >> operations on Graph model with scalable algorithmic schemes as >> mentioned >> >> in GPS, then we will have a powerful means to exercise traffic >> control, >> >> shaping and delivery which are the fundamental aspects of any >> network. >> >> A source of complexity we may need to handle is to be able to allow >> for >> >> multiple instances of such distributed control and distribution of >> >> control working together. >> >>=A0=A0=A0Such segmentation between distributed control and distributio= n of >> >> control also could yield to a scalable solution=C5=AF >> >>=A0 Sitaraman >> >> >> >> >> >> > >> >> > These bring up interesting global-local distinctions. >> >> > >> >> > The scope of a flow definition is clearly local to the aggregation >> >> point: >> >> > IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a >> connection >> >> > ..depends. >> >> > >> >> > The context of handling a flow in a specific point is clearly has >> >> global >> >> > user-app considerations. >> >> > Distributing control logic is therefore according to global context >> >> > mapping not aggregation topology. This is different then control >> >> > distribution considerations for packet forwarding. >> >> > >> >> > The touch point between control and forwarding is therefore a >> >> practical >> >> > choice. >> >> > The control has to be both locally (scope & mechanics) and globally >> >> > (user-app) aware. >> >> > >> >> > Overlays work quite well in that sense, global awareness by >> >> distributed >> >> > clustering, >> >> > local touch point splits, or merges encapsulates flows based on >> global >> >> > pipeline need. >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > On Jan 14, 2013, at 17:49, "sitaraman@nmsworks.co.in" >> >> > wrote: >> >> > >> >> > Hi, >> >> > Some thoughts. >> >> >=A0 1. Does the separation of control plane from the forwarding >> >> necessarily >> >> > mean the control now is to be centralized? It likely is not. Though >> >> the >> >> > network device itself need not implment the control plane and can >> be >> >> > interacted via an OpenFlow interface, the control funcationality >> can >> >> be >> >> > a separate distributed system. >> >> >=A0 2. Model to represent Network >> >> >=A0 =A0=A0=A0Network and traffic flows are fundamentally flows in >> capacitated >> >> > graphs.=A0 Could we look at using Stanford Graph Processing System >> >> > (GPS) for SDN based networks. The periodic communication amongst >> >> > nodes seem to naturally map to a traffic and information flow in a >> >> > network? >> >> > >> >> >=A0 3. Model to repsresent capacities of network resources and logic= al >> >> > abstractions of physical resources. >> >> >=A0 =A0=A0=A0SDN dosent and probably should not change anything fund= amental >> in >> >> the >> >> > traffic flow itself. This means that here SDN must look into >> reusing >> >> > existing models.=A0 TMF models is a likely candidate. >> >> >=A0 4. Model to represent faults. >> >> >=A0 =A0=A0=A0Same as above. New type of faults related to the decoup= led >> >> (possibly >> >> > yet distributed) control plane to be harmonized with model for >> >> > existing faults. Again TMF is a source. >> >> >=A0 5. Model to respresent Business aspects (Products, Orders such a= s >> >> time >> >> > to delivery commitments) >> >> >=A0 =A0=A0=A0Same as above and again TMF is a source for this model.= The new >> >> SDN >> >> > network could leverage by being able to be invoked or referred to >> in >> >> > the existing TMF business model aspects. After all these are >> directly >> >> > related to revenue and Customer Experience Management. >> >> >=A0 6. Is it distributed control, distribution of control or soemwhe= re >> in >> >> > between that is preferable. Distributed control can be a conceptual >> >> > centralized control which is implemented in a distribued manner. >> Can >> >> > this nature be adaptively changed. Any aspects of learning in >> control >> >> > plane in SDN networks. >> >> >=A0 7. Layers of control Ethernet Layer, MPLS layer, IP layer. >> >> >=A0 8. Service Providers' bottom line is business and this means the >> TMF >> >> FAB >> >> > Fulfilment, Assurance and Billing. SDN models must leverage the >> >> existing >> >> > model as transparently as is practically feasibile. >> >> > Sitaraman >> >> > >> >> > Possibly of interest. >> >> >> >> >> >> Begin forwarded message: >> >> >> >> >> >>> From: "Eggert, Lars" >> >> >>> Subject: [irtf-discuss] New: Software-Defined Networking Research >> >> Group >> >> >>> (SDNRG) >> >> >>> Date: January 14, 2013 10:24:57 GMT+01:00 >> >> >>> To: "" , >> >> >>> "" >> >> >>> Cc: "sdn@irtf.org" >> >> >>> Reply-To: "irtf-discuss@irtf.org" >> >> >>> >> >> >>> A new IRTF research group on Software-Defined Networking has been >> >> >>> chartered: >> >> >>> >> >> >>> The Software-Defined Networking Research Group (SDNRG) >> investigates >> >> SDN >> >> >>> from various perspectives with the goal of identifying the >> >> approaches >> >> >>> that >> >> >>> can be defined, deployed and used in the near term as well >> >> identifying >> >> >>> future research challenges. In particular, key areas of interest >> >> >>> include >> >> >>> solution scalability, abstractions, and programming languages and >> >> >>> paradigms >> >> >>> particularly useful in the context of SDN. In addition, it is an >> >> >>> explicit >> >> >>> goal of the SDNRG to provide a forum for researchers to >> investigate >> >> key >> >> >>> and interesting problems in the Software-Defined Networking >> field. >> >> >>> >> >> >>> Charter and participation information can be found at >> >> >>> http://irtf.org/sdnrg >> >> >>> >> >> >>> Lars Eggert >> >> >>> IRTF Chair >> >> >> >> >> >> _______________________________________________ >> >> >> openflow-discuss mailing list >> >> >> openflow-discuss@lists.stanford.edu >> >> >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >> >> >> >> >> >> -- >> >> >> This message has been scanned for viruses and >> >> >> dangerous content by MailScanner, and is >> >> >> believed to be clean. >> >> > >> >> > >> >> > >> >> > -- >> >> > This message has been scanned for viruses and >> >> > dangerous content by MailScanner, and is >> >> > believed to be clean. >> >> > >> >> > _______________________________________________ >> >> > sdn mailing list >> >> > sdn@irtf.org >> >> > https://www.irtf.org/mailman/listinfo/sdn >> >> > >> >> > >> >> > _______________________________________________ >> >> > sdn mailing list >> >> > sdn@irtf.org >> >> > https://www.irtf.org/mailman/listinfo/sdn >> >> > >> >> > -- >> >> > This message has been scanned for viruses and >> >> > dangerous content by MailScanner, and is >> >> > believed to be clean. >> >> > >> >> >> >> >> >> >> >> -- >> >> This message has been scanned for viruses and >> >> dangerous content by MailScanner, and is >> >> believed to be clean. >> >> >> >> _______________________________________________ >> >> sdn mailing list >> >> sdn@irtf.org >> >> https://www.irtf.org/mailman/listinfo/sdn >> >> >> > >> > -- >> > This message has been scanned for viruses and >> > dangerous content by MailScanner, and is >> > believed to be clean. >> > >> > >> >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> >> > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ sdn mailing list sdn@irtf.org https://www.irtf.org/mailman/listinfo/sdn --1993147269-698348342-1358275155=:38520 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

This is great discussion. Since we are ta= lking about "Software defined", I think it implies some type of software pr= ogrammability of a network. In present day I haven't seen too many applicat= ions trying to program network. So it is a new concept for them. So how abo= ut first defining, what programmability of network means in simple terms ? =
I think many programmers are not networking experts and don't necessari= ly understand details about different protocols, link types, topological gr= aphs etc. However for them behavior of their application is important and t= hey certainly understand importance of things like control over available b= andwidth, data loss, availability of network, having shortest path to the d= estination etc. So my question is can we define what programmability or "so= ftware defined " means in simple terms ? We can then go on to define what i= t takes to create that programmability including API, infrastructure etc.This discussion can also involve what level of network programmability is = desirable and then there can be a discussion about what is achievable.
A= t present I see most of the discussion about splitting control plane and da= ta plane or distributed controller etc. All this discussion is good but wit= hout considering what user wants and type of user programmability model we = have in mind, it is incomplete.
Thanks
Bhalchandra
--- On Tue, = 1/15/13, sitaraman@nmsworks.co.in <sitaraman@nmsworks.co.in> wrote:

From: sitaraman@nmsworks.co.in &l= t;sitaraman@nmsworks.co.in>
Subject: Re: [Sdn] [openflow-discuss] Fwd= : [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG)To: "Rana Sircar" <sircar.rana@gmail.com>
Cc: "Eggert, Lars" <lars@netapp.com>, "Sharon Barkai" <sharon@contextream.com>, "= sdn@irtf.org" <sdn@irtf.org>, "openflow-discuss@mailman.stanford.edu"= <openflow-discuss@mailman.stanford.edu>
Date: Tuesday, January 15= , 2013, 1:48 AM

Hi Rana,
Thanks for the= discussion.
GPS was more of mooting an implementation choice which (GP= S or something
similar) philosophy seemed to mesh very well with the pro= blem at hand. So
let us set that aside for now, as it dosent impact this= particular topic
of discussion.
I did not intend to come across as = saying that there should be only a
single way to get reachability inform= ation in the control. But i did
intend to say that there should be a sin= gle way (that is, there is a
single solution possible, but that does not= claim to be the only solution
that will work to get reachability inform= ation).
In addition this single way of getting the reachability could also be
able to get reachability information from the existing so= urces of such
information too...
Sitaraman
> Hi Sitaraman,
&= gt;
> As I understand, you are keen on fixing a single way to
>= get reach-ability information from the nodes - which is based on GPS.
&= gt; Thereby, in a way you are doing two things -
> 1. Creating a fixe= d way of routing in Control plane
> 2. Creating a fixed topology for = control - that is centralized logically
>
> If my understanding= is correct, then how do you propose to migrate from
> current topolo= gies to the one proposed by you?
>
> Best Regards,
> Rana= Pratap Sircar
> GSM+919899003705|
>
>
> On 15 Janu= ary 2013 14:02, <sitaraman@nmsworks.co.in>= wrote:
>
>> Hi Rana,
>>  I agree completely with the approach you are suggesting, but i do not
>> see
>= > why that negates or even changes the considerations i have raised on t= he
>> control plane deployment styles?
>> Sitaraman
&g= t;> > Dear Sitaraman,
>> >
>> > In my opinion= , there could be three scenarios for SDN deployment -
>> > 1. G= reenfield deployment
>> > 2. Upgrade from existing
>> = > 3. Transformation of current network
>> >
>> >= Any deployment is cost intensive. Thus, fork-lift upgrades may not be
&= gt;> the
>> > first choice for many. Thus, we should not cre= ate the use cases such a
>> way
>> > as to support onl= y fork-lift upgrades.
>> >
>> > I like the idea of = Overlay networks. It is always helpful to roll-out
>> new
>&= gt; > technologies.
>> >
>> > Best Regards,
>> > Rana Pratap Sircar
>> > GSM+91989900= 3705|
>> >
>> >
>> > On 15 January 2013= 10:54, <sitaraman@nmsworks.co.in> wrote:<= br>>> >
>> >> Hi Sharon,
>> >> =   Thanks for these valuable insights.
>> >> &= nbsp; In the preSDN networking world, due to practicality of evolution=
>> and
>> >> backward compatibility needs there ar= ose multiple ways of doing the
>> same
>> >> thing= =C5=AF.i.e gather and use graph reachability information.
>> >&= gt;   SDN is our chance to begin with a clean slate, while w= e need not
>> throw
>> >> the interoperation with e= xisting networks totally out the window, we
>> >> must also = be careful not to avoid falling into the trap of
>> restricting
&= gt;> >> the capabilities and flexibility due to its need, even at = first as
>> >> options in isolation, for SDN.
>> &g= t;>   What we could consider in IRTF is standardizing a s= ingle way to
>> gather
>> >> reachability informati= on (in a capacitated graph, typically). Indeed
>> as
>> &= gt;> you point out very aptly, such reachability information can be of>> >> varying geographical spans and varying aggregation leve= l spans and
>> these
>> >> can have causal connecti= ons. If I understand you correctly, an
>> >> Aggregration pi= vot has implications on the geographic spans that need
>> to
&g= t;> >> considered, and such aggregation pivots serve to segment/sp= lit the
>> >> geographic expanse (conceptually in the graph model of the network
>> that
>> >> is) that = the control has to deal with.
>> >>   It appe= ars then if only we have a control of a control that based
>> on>> >> the
>> >> specified aggregation pivots r= edistribute the division between
>> >> distributed control a= nd distribution of control that when combined
>> with
>> = >> operations on Graph model with scalable algorithmic schemes as
= >> mentioned
>> >> in GPS, then we will have a powerfu= l means to exercise traffic
>> control,
>> >> shapi= ng and delivery which are the fundamental aspects of any
>> networ= k.
>> >> A source of complexity we may need to handle is to = be able to allow
>> for
>> >> multiple instances of= such distributed control and distribution of
>> >> control working together.
>> >>   Such segme= ntation between distributed control and distribution of
>> >>= ; control also could yield to a scalable solution=C5=AF
>> >>= ;  Sitaraman
>> >>
>> >>
>> >= ;> >
>> >> > These bring up interesting global-loca= l distinctions.
>> >> >
>> >> > The sco= pe of a flow definition is clearly local to the aggregation
>> >= ;> point:
>> >> > IP, IP-Port (NAT etc), TCP connectio= n, HTTP pipeline with a
>> connection
>> >> > ..= depends.
>> >> >
>> >> > The context of= handling a flow in a specific point is clearly has
>> >> gl= obal
>> >> > user-app considerations.
>> >>= ; > Distributing control logic is therefore according to global context
>> >> > mapping not aggregation topology. This i= s different then control
>> >> > distribution considerati= ons for packet forwarding.
>> >> >
>> >> &= gt; The touch point between control and forwarding is therefore a
>&g= t; >> practical
>> >> > choice.
>> >>= ; > The control has to be both locally (scope & mechanics) and globa= lly
>> >> > (user-app) aware.
>> >> >>> >> > Overlays work quite well in that sense, global awa= reness by
>> >> distributed
>> >> > cluste= ring,
>> >> > local touch point splits, or merges encapsu= lates flows based on
>> global
>> >> > pipeline = need.
>> >> >
>> >> >
>> >&= gt; >
>> >> >
>> >> >
>> >> > On Jan 14, 2013, at 17:49, "sitaraman@nmsworks.co.in"
>> >> > <sitaraman@nmsworks.co.in> wrote:
>> >>= ; >
>> >> > Hi,
>> >> > Some thought= s.
>> >> >  1. Does the separation of control plane = from the forwarding
>> >> necessarily
>> >> &= gt; mean the control now is to be centralized? It likely is not. Though
= >> >> the
>> >> > network device itself need = not implment the control plane and can
>> be
>> >> = > interacted via an OpenFlow interface, the control funcationality
&g= t;> can
>> >> be
>> >> > a separate distributed system.
>> >> >  2. Model to represent = Network
>> >> >     Network and traff= ic flows are fundamentally flows in
>> capacitated
>> >= ;> > graphs.  Could we look at using Stanford Graph Processing S= ystem
>> >> > (GPS) for SDN based networks. The periodic = communication amongst
>> >> > nodes seem to naturally map= to a traffic and information flow in a
>> >> > network?<= br>>> >> >
>> >> >  3. Model to repsr= esent capacities of network resources and logical
>> >> >= abstractions of physical resources.
>> >> >   =   SDN dosent and probably should not change anything fundamental<= br>>> in
>> >> the
>> >> > traffic f= low itself. This means that here SDN must look into
>> reusing
>> >> > existing models.  TMF models is a l= ikely candidate.
>> >> >  4. Model to represent faul= ts.
>> >> >     Same as above. New ty= pe of faults related to the decoupled
>> >> (possibly
>= ;> >> > yet distributed) control plane to be harmonized with mo= del for
>> >> > existing faults. Again TMF is a source.>> >> >  5. Model to respresent Business aspects (Pro= ducts, Orders such as
>> >> time
>> >> > t= o delivery commitments)
>> >> >     S= ame as above and again TMF is a source for this model. The new
>> = >> SDN
>> >> > network could leverage by being able= to be invoked or referred to
>> in
>> >> > the = existing TMF business model aspects. After all these are
>> directly
>> >> > related to revenue and Customer Experie= nce Management.
>> >> >  6. Is it distributed contro= l, distribution of control or soemwhere
>> in
>> >>= > between that is preferable. Distributed control can be a conceptual>> >> > centralized control which is implemented in a dist= ribued manner.
>> Can
>> >> > this nature be ada= ptively changed. Any aspects of learning in
>> control
>>= >> > plane in SDN networks.
>> >> >  7. La= yers of control Ethernet Layer, MPLS layer, IP layer.
>> >> = >  8. Service Providers' bottom line is business and this means the=
>> TMF
>> >> FAB
>> >> > Fulfilm= ent, Assurance and Billing. SDN models must leverage the
>> >&g= t; existing
>> >> > model as transparently as is practically feasibile.
>> >> > Sitaraman
>> >= ;> >
>> >> > Possibly of interest.
>> >= > >>
>> >> >> Begin forwarded message:
>= ;> >> >>
>> >> >>> From: "Eggert, La= rs" <lars@netapp.com>
>> >> >>> Subj= ect: [irtf-discuss] New: Software-Defined Networking Research
>> &= gt;> Group
>> >> >>> (SDNRG)
>> >>= ; >>> Date: January 14, 2013 10:24:57 GMT+01:00
>> >&g= t; >>> To: "<irtf-announce@irtf.org>= " <irtf-announce@irtf.org>,
>> >= > >>> "<irtf-discuss@irtf.org>" <irtf-discuss@irtf.org>
>> >> >>>= ; Cc: "sdn@irtf.org" <sdn@irtf.org>
>> >> >&g= t;> Reply-To: "irtf-discuss@irtf.org" <irtf-discuss@irtf.org>
>> >> >>>
= >> >> >>> A new IRTF research group on Software-Define= d Networking has been
>> >> >>> chartered:
>&= gt; >> >>>
>> >> >>> The Software-Defined Networ= king Research Group (SDNRG)
>> investigates
>> >> S= DN
>> >> >>> from various perspectives with the goa= l of identifying the
>> >> approaches
>> >> &= gt;>> that
>> >> >>> can be defined, deployed= and used in the near term as well
>> >> identifying
>= > >> >>> future research challenges. In particular, key a= reas of interest
>> >> >>> include
>> >= > >>> solution scalability, abstractions, and programming langu= ages and
>> >> >>> paradigms
>> >> &= gt;>> particularly useful in the context of SDN. In addition, it is a= n
>> >> >>> explicit
>> >> >>&= gt; goal of the SDNRG to provide a forum for researchers to
>> investigate
>> >> key
>> >> &= gt;>> and interesting problems in the Software-Defined Networking
= >> field.
>> >> >>>
>> >> >= >> Charter and participation information can be found at
>> = >> >>> h= ttp://irtf.org/sdnrg
>> >> >>>
>> >= > >>> Lars Eggert
>> >> >>> IRTF Chair<= br>>> >> >>
>> >> >> _______________= ________________________________
>> >> >> openflow-dis= cuss mailing list
>> >> >> openflow-discuss@lists.stanford.edu
>> >&= gt; >> https://mailman.stanford.edu/mailman/listinfo/openflow-disc= uss
>> >> >>
>> >> >> --
&= gt;> >> >> This message has been scanned for viruses and
= >> >> >> dangerous content by MailScanner, and is
>= > >> >> believed to be clean.
>> >> >
&= gt;> >> >
>> >> >
>> >> > -= -
>> >> > This message has been scanned for viruses and>> >> > dangerous content by MailScanner, and is
>&g= t; >> > believed to be clean.
>> >> >
>>= ; >> > _______________________________________________
>>= >> > sdn mailing list
>> >> > sdn@irtf.org
>> >&g= t; > https://www.irtf.org/mailman/listinfo/sdn
>> >> >= ;
>> >> >
>> >> > _____________________= __________________________
>> >> > sdn mailing list
&g= t;> >> > sdn@irtf.org
>> >> > https://www.irt= f.org/mailman/listinfo/sdn
>> >> >
>> >&g= t; > --
>> >> > This message has been scanned for viru= ses and
>> >> > dangerous content by MailScanner, and is<= br>>> >> > believed to be clean.
>> >> >>> >>
>> >>
>> >>
>> &= gt;> --
>> >> This message has been scanned for viruses and
&= gt;> >> dangerous content by MailScanner, and is
>> >&= gt; believed to be clean.
>> >>
>> >> _______= ________________________________________
>> >> sdn mailing l= ist
>> >> sdn@irtf.org
>> >> https://www.irtf= .org/mailman/listinfo/sdn
>> >>
>> >
>= > > --
>> > This message has been scanned for viruses and=
>> > dangerous content by MailScanner, and is
>> >= believed to be clean.
>> >
>> >
>>
>= ;>
>>
>> --
>> This message has been scanned = for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>>
>
&g= t; --
> This message has been scanned for viruses and
> dangero= us content by MailScanner, and is
> believed to be clean.
>
= >



--
This message has been scanned for viruses anddangerous content by MailScanner, and is
believed to be clean.

_= ______________________________________________
sdn mailing list
sdn@ir= tf.org
https://www.irtf.org/mailman/listinfo/sdn
--1993147269-698348342-1358275155=:38520-- From dmm@1-4-5.net Tue Jan 15 10:52:59 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662A011E80EF for ; Tue, 15 Jan 2013 10:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-oWk2UtQ4kU for ; Tue, 15 Jan 2013 10:52:57 -0800 (PST) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id A06CB11E80ED for ; Tue, 15 Jan 2013 10:52:56 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id d13so485918qak.18 for ; Tue, 15 Jan 2013 10:52:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=4haklpu7KN2FzbxXe3we9O2qGD6Zu64fbmsSOIw2zEg=; b=fjjNxA7v+dHon9H5zaFytaIfsRfXhZV70G9fAcng8gGQJX9lHirVfXT7k/texPDXKl EdfTuOgw3GDACpr3ajV2m+MeHdFmkbSawtZLLJO69h31qGGKByE/Ro2pQM7oS8CABXBS jmUuLpmcBeFc0BWvQqmO6o4VpIza7FtXdf27WDtyWwiVe7AAIq+7mCyGYzDBnpl2laCH fM77E538p5jr0cQ9uJkVBrIDMTcmbt/mZf3Vwb+oU75SJr+9zw96wfXPhlliSJZnq2N5 PmylujVxWPoIlqnmJMAGi2SfKyCtZ+1cfd92AO/DlbavQBkIDd776B+tHSAhvEexMm/T z5Lg== MIME-Version: 1.0 Received: by 10.49.2.35 with SMTP id 3mr88846397qer.36.1358275975802; Tue, 15 Jan 2013 10:52:55 -0800 (PST) Received: by 10.49.75.195 with HTTP; Tue, 15 Jan 2013 10:52:55 -0800 (PST) X-Originating-IP: [64.75.221.163] In-Reply-To: <1358275155.38520.YahooMailClassic@web125403.mail.ne1.yahoo.com> References: <53892.192.168.9.56.1358243297.squirrel@www.nmsworks.co.in> <1358275155.38520.YahooMailClassic@web125403.mail.ne1.yahoo.com> Date: Tue, 15 Jan 2013 08:52:55 -1000 Message-ID: From: David Meyer To: bhal d Content-Type: multipart/alternative; boundary=047d7b6777000b714004d358456a X-Gm-Message-State: ALoCoQkgNiMBy8G4SylYGBgcVq9u/N+yMkGipsgbxKLcGC6XEMC5goc7D3Q0GpVyEduP6uuzWPZa Cc: "sdn@irtf.org" , LarsEggert , Rana Sircar , "openflow-discuss@mailman.stanford.edu" , Sharon Barkai , sitaraman@nmsworks.co.in Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG) X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 18:52:59 -0000 --047d7b6777000b714004d358456a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jan 15, 2013 at 8:39 AM, bhal d wrote: > > This is great discussion. Since we are talking about "Software defined", = I > think it implies some type of software programmability of a network. In > present day I haven't seen too many applications trying to program networ= k. > So it is a new concept for them. So how about first defining, what > programmability of network means in simple terms ? > I think many programmers are not networking experts and don't necessarily > understand details about different protocols, link types, topological > graphs etc. However for them behavior of their application is important a= nd > they certainly understand importance of things like control over availabl= e > bandwidth, data loss, availability of network, having shortest path to th= e > destination etc. So my question is can we define what programmability or > "software defined " means in simple terms ? We can then go on to define > what it takes to create that programmability including API, infrastructur= e > etc. > This discussion can also involve what level of network programmability is > desirable and then there can be a discussion about what is achievable. > At present I see most of the discussion about splitting control plane and > data plane or distributed controller etc. All this discussion is good but > without considering what user wants and type of user programmability mode= l > we have in mind, it is incomplete. > dmm> actually my sense (and experience) is quite different. While I can agree that in the early days of "SDN" folks were talking about the issues you mention (splitting the control and data planes, programmable forwarding planes, etc), generally thinking in both the research community and industry and evolved quite a bit to include not only OF/SDN but a much wider scope. Consider for example I2RS or PCE(P), or what's going on in *So= phia Antipolis* this week (ETSI ISG on NfV). In addition, there are robust discussions going on (again, both in industry and in the research community) around the question of abstractions for "network programming" as well as ecosystem models for SDN. BTW, there are literally hundreds of use cases proposed by every segment of the network community around some form of network programmability, data models, and the like. --dmm Thanks > Bhalchandra > --- On *Tue, 1/15/13, sitaraman@nmsworks.co.in = *wrote: > > > From: sitaraman@nmsworks.co.in > Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: > Software-Defined Networking Research Group (SDNRG) > To: "Rana Sircar" > Cc: "Eggert, Lars" , "Sharon Barkai" < > sharon@contextream.com>, "sdn@irtf.org" , " > openflow-discuss@mailman.stanford.edu" < > openflow-discuss@mailman.stanford.edu> > Date: Tuesday, January 15, 2013, 1:48 AM > > Hi Rana, > Thanks for the discussion. > GPS was more of mooting an implementation choice which (GPS or something > similar) philosophy seemed to mesh very well with the problem at hand. So > let us set that aside for now, as it dosent impact this particular topic > of discussion. > I did not intend to come across as saying that there should be only a > single way to get reachability information in the control. But i did > intend to say that there should be a single way (that is, there is a > single solution possible, but that does not claim to be the only solution > that will work to get reachability information). > In addition this single way of getting the reachability could also be > able to get reachability information from the existing sources of such > information too... > Sitaraman > > Hi Sitaraman, > > > > As I understand, you are keen on fixing a single way to > > get reach-ability information from the nodes - which is based on GPS. > > Thereby, in a way you are doing two things - > > 1. Creating a fixed way of routing in Control plane > > 2. Creating a fixed topology for control - that is centralized logicall= y > > > > If my understanding is correct, then how do you propose to migrate from > > current topologies to the one proposed by you? > > > > Best Regards, > > Rana Pratap Sircar > > GSM+919899003705| > > > > > > On 15 January 2013 14:02, > > wrote: > > > >> Hi Rana, > >> I agree completely with the approach you are suggesting, but i do not > >> see > >> why that negates or even changes the considerations i have raised on t= he > >> control plane deployment styles? > >> Sitaraman > >> > Dear Sitaraman, > >> > > >> > In my opinion, there could be three scenarios for SDN deployment - > >> > 1. Greenfield deployment > >> > 2. Upgrade from existing > >> > 3. Transformation of current network > >> > > >> > Any deployment is cost intensive. Thus, fork-lift upgrades may not b= e > >> the > >> > first choice for many. Thus, we should not create the use cases such= a > >> way > >> > as to support only fork-lift upgrades. > >> > > >> > I like the idea of Overlay networks. It is always helpful to roll-ou= t > >> new > >> > technologies. > >> > > >> > Best Regards, > >> > Rana Pratap Sircar > >> > GSM+919899003705| > >> > > >> > > >> > On 15 January 2013 10:54, > > wrote: > >> > > >> >> Hi Sharon, > >> >> Thanks for these valuable insights. > >> >> In the preSDN networking world, due to practicality of evolution > >> and > >> >> backward compatibility needs there arose multiple ways of doing the > >> same > >> >> thing=C5=AF.i.e gather and use graph reachability information. > >> >> SDN is our chance to begin with a clean slate, while we need not > >> throw > >> >> the interoperation with existing networks totally out the window, w= e > >> >> must also be careful not to avoid falling into the trap of > >> restricting > >> >> the capabilities and flexibility due to its need, even at first as > >> >> options in isolation, for SDN. > >> >> What we could consider in IRTF is standardizing a single way to > >> gather > >> >> reachability information (in a capacitated graph, typically). Indee= d > >> as > >> >> you point out very aptly, such reachability information can be of > >> >> varying geographical spans and varying aggregation level spans and > >> these > >> >> can have causal connections. If I understand you correctly, an > >> >> Aggregration pivot has implications on the geographic spans that ne= ed > >> to > >> >> considered, and such aggregation pivots serve to segment/split the > >> >> geographic expanse (conceptually in the graph model of the network > >> that > >> >> is) that the control has to deal with. > >> >> It appears then if only we have a control of a control that based > >> on > >> >> the > >> >> specified aggregation pivots redistribute the division between > >> >> distributed control and distribution of control that when combined > >> with > >> >> operations on Graph model with scalable algorithmic schemes as > >> mentioned > >> >> in GPS, then we will have a powerful means to exercise traffic > >> control, > >> >> shaping and delivery which are the fundamental aspects of any > >> network. > >> >> A source of complexity we may need to handle is to be able to allow > >> for > >> >> multiple instances of such distributed control and distribution of > >> >> control working together. > >> >> Such segmentation between distributed control and distribution of > >> >> control also could yield to a scalable solution=C5=AF > >> >> Sitaraman > >> >> > >> >> > >> >> > > >> >> > These bring up interesting global-local distinctions. > >> >> > > >> >> > The scope of a flow definition is clearly local to the aggregatio= n > >> >> point: > >> >> > IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a > >> connection > >> >> > ..depends. > >> >> > > >> >> > The context of handling a flow in a specific point is clearly has > >> >> global > >> >> > user-app considerations. > >> >> > Distributing control logic is therefore according to global conte= xt > >> >> > mapping not aggregation topology. This is different then control > >> >> > distribution considerations for packet forwarding. > >> >> > > >> >> > The touch point between control and forwarding is therefore a > >> >> practical > >> >> > choice. > >> >> > The control has to be both locally (scope & mechanics) and global= ly > >> >> > (user-app) aware. > >> >> > > >> >> > Overlays work quite well in that sense, global awareness by > >> >> distributed > >> >> > clustering, > >> >> > local touch point splits, or merges encapsulates flows based on > >> global > >> >> > pipeline need. > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > On Jan 14, 2013, at 17:49, "sitaraman@nmsworks.co.in > " > >> >> > > > wrote: > >> >> > > >> >> > Hi, > >> >> > Some thoughts. > >> >> > 1. Does the separation of control plane from the forwarding > >> >> necessarily > >> >> > mean the control now is to be centralized? It likely is not. Thou= gh > >> >> the > >> >> > network device itself need not implment the control plane and can > >> be > >> >> > interacted via an OpenFlow interface, the control funcationality > >> can > >> >> be > >> >> > a separate distributed system. > >> >> > 2. Model to represent Network > >> >> > Network and traffic flows are fundamentally flows in > >> capacitated > >> >> > graphs. Could we look at using Stanford Graph Processing System > >> >> > (GPS) for SDN based networks. The periodic communication amongst > >> >> > nodes seem to naturally map to a traffic and information flow in = a > >> >> > network? > >> >> > > >> >> > 3. Model to repsresent capacities of network resources and logic= al > >> >> > abstractions of physical resources. > >> >> > SDN dosent and probably should not change anything fundamenta= l > >> in > >> >> the > >> >> > traffic flow itself. This means that here SDN must look into > >> reusing > >> >> > existing models. TMF models is a likely candidate. > >> >> > 4. Model to represent faults. > >> >> > Same as above. New type of faults related to the decoupled > >> >> (possibly > >> >> > yet distributed) control plane to be harmonized with model for > >> >> > existing faults. Again TMF is a source. > >> >> > 5. Model to respresent Business aspects (Products, Orders such a= s > >> >> time > >> >> > to delivery commitments) > >> >> > Same as above and again TMF is a source for this model. The n= ew > >> >> SDN > >> >> > network could leverage by being able to be invoked or referred to > >> in > >> >> > the existing TMF business model aspects. After all these are > >> directly > >> >> > related to revenue and Customer Experience Management. > >> >> > 6. Is it distributed control, distribution of control or soemwhe= re > >> in > >> >> > between that is preferable. Distributed control can be a conceptu= al > >> >> > centralized control which is implemented in a distribued manner. > >> Can > >> >> > this nature be adaptively changed. Any aspects of learning in > >> control > >> >> > plane in SDN networks. > >> >> > 7. Layers of control Ethernet Layer, MPLS layer, IP layer. > >> >> > 8. Service Providers' bottom line is business and this means the > >> TMF > >> >> FAB > >> >> > Fulfilment, Assurance and Billing. SDN models must leverage the > >> >> existing > >> >> > model as transparently as is practically feasibile. > >> >> > Sitaraman > >> >> > > >> >> > Possibly of interest. > >> >> >> > >> >> >> Begin forwarded message: > >> >> >> > >> >> >>> From: "Eggert, Lars" > > > >> >> >>> Subject: [irtf-discuss] New: Software-Defined Networking Resear= ch > >> >> Group > >> >> >>> (SDNRG) > >> >> >>> Date: January 14, 2013 10:24:57 GMT+01:00 > >> >> >>> To: ">" > >, > >> >> >>> ">" > > > >> >> >>> Cc: "sdn@irtf.org " < > sdn@irtf.org > > >> >> >>> Reply-To: "irtf-discuss@irtf.org" > > > >> >> >>> > >> >> >>> A new IRTF research group on Software-Defined Networking has be= en > >> >> >>> chartered: > >> >> >>> > >> >> >>> The Software-Defined Networking Research Group (SDNRG) > >> investigates > >> >> SDN > >> >> >>> from various perspectives with the goal of identifying the > >> >> approaches > >> >> >>> that > >> >> >>> can be defined, deployed and used in the near term as well > >> >> identifying > >> >> >>> future research challenges. In particular, key areas of interes= t > >> >> >>> include > >> >> >>> solution scalability, abstractions, and programming languages a= nd > >> >> >>> paradigms > >> >> >>> particularly useful in the context of SDN. In addition, it is a= n > >> >> >>> explicit > >> >> >>> goal of the SDNRG to provide a forum for researchers to > >> investigate > >> >> key > >> >> >>> and interesting problems in the Software-Defined Networking > >> field. > >> >> >>> > >> >> >>> Charter and participation information can be found at > >> >> >>> http://irtf.org/sdnrg > >> >> >>> > >> >> >>> Lars Eggert > >> >> >>> IRTF Chair > >> >> >> > >> >> >> _______________________________________________ > >> >> >> openflow-discuss mailing list > >> >> >> openflow-discuss@lists.stanford.edu > >> >> >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > >> >> >> > >> >> >> -- > >> >> >> This message has been scanned for viruses and > >> >> >> dangerous content by MailScanner, and is > >> >> >> believed to be clean. > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > This message has been scanned for viruses and > >> >> > dangerous content by MailScanner, and is > >> >> > believed to be clean. > >> >> > > >> >> > _______________________________________________ > >> >> > sdn mailing list > >> >> > sdn@irtf.org > >> >> > https://www.irtf.org/mailman/listinfo/sdn > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > sdn mailing list > >> >> > sdn@irtf.org > >> >> > https://www.irtf.org/mailman/listinfo/sdn > >> >> > > >> >> > -- > >> >> > This message has been scanned for viruses and > >> >> > dangerous content by MailScanner, and is > >> >> > believed to be clean. > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> This message has been scanned for viruses and > >> >> dangerous content by MailScanner, and is > >> >> believed to be clean. > >> >> > >> >> _______________________________________________ > >> >> sdn mailing list > >> >> sdn@irtf.org > >> >> https://www.irtf.org/mailman/listinfo/sdn > >> >> > >> > > >> > -- > >> > This message has been scanned for viruses and > >> > dangerous content by MailScanner, and is > >> > believed to be clean. > >> > > >> > > >> > >> > >> > >> -- > >> This message has been scanned for viruses and > >> dangerous content by MailScanner, and is > >> believed to be clean. > >> > >> > > > > -- > > This message has been scanned for viruses and > > dangerous content by MailScanner, and is > > believed to be clean. > > > > > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > > > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > > --047d7b6777000b714004d358456a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jan 15, 2013 at 8:39 AM, bhal d = <bhal_d@yahoo.com> wrote:

This is great discussion. Since we ar= e talking about "Software defined", I think it implies some type = of software programmability of a network. In present day I haven't seen= too many applications trying to program network. So it is a new concept fo= r them. So how about first defining, what programmability of network means = in simple terms ?
I think many programmers are not networking experts and don't necessari= ly understand details about different protocols, link types, topological gr= aphs etc. However for them behavior of their application is important and t= hey certainly understand importance of things like control over available b= andwidth, data loss, availability of network, having shortest path to the d= estination etc. So my question is can we define what programmability or &qu= ot;software defined " means in simple terms ? We can then go on to def= ine what it takes to create that programmability including API, infrastructure etc.This discussion can also involve what level of network programmability is = desirable and then there can be a discussion about what is achievable.
At present I see most of the discussion about splitting control plane and d= ata plane or distributed controller etc. All this discussion is good but wi= thout considering what user wants and type of user programmability model we= have in mind, it is incomplete.

dmm> actually= my sense (and experience) is quite different. While I can agree that in th= e early days of "SDN" folks were talking about the issues you men= tion (splitting the control and data planes, programmable forwarding planes= , etc), generally thinking in both the research community and industry and = evolved quite a bit to include not only OF/SDN but a much wider scope. Cons= ider for example I2RS or PCE(P), or what's going on in=A0Sophia Antipolis=A0this week (ETSI ISG on NfV). In = addition, there are robust discussions going on (again, both in industry an= d in the research community) around the question of abstractions for "= network programming" as well as ecosystem models for SDN. BTW, there a= re literally hundreds of use cases proposed by every segment of the network= community around some form of network programmability, data models, and th= e like. --dmm

Thanks
Bhalchandra
--- On Tue, 1= /15/13, sitar= aman@nmsworks.co.in <sitaraman@nmsworks.co.in> wrote:

From: sitaraman@nmsworks.co.in <sitaraman@nmsworks.co.in>
Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: Software-Def= ined Networking Research Group (SDNRG)
To: "Rana Sircar" <<= a href=3D"mailto:sircar.rana@gmail.com" target=3D"_blank">sircar.rana@gmail= .com>
Cc: "Eggert, Lars" <lars@netapp.com>, "Sharon Barkai" <sharon@contextream.com>, "sdn@irtf.org" <sdn@irtf.org>, "openflo= w-discuss@mailman.stanford.edu" <openflow-discuss@mailman.stanf= ord.edu>
Date: Tuesday, January 15, 2013, 1:48 AM

Hi Rana,
Thanks fo= r the discussion.
GPS was more of mooting an implementation choice whic= h (GPS or something
similar) philosophy seemed to mesh very well with th= e problem at hand. So
let us set that aside for now, as it dosent impact this particular topicof discussion.
I did not intend to come across as saying that there sh= ould be only a
single way to get reachability information in the control= . But i did
intend to say that there should be a single way (that is, there is a
sin= gle solution possible, but that does not claim to be the only solution
t= hat will work to get reachability information).
In addition this single= way of getting the reachability could also be
able to get reachability information from the existing so= urces of such
information too...
Sitaraman
> Hi Sitaraman,
&= gt;
> As I understand, you are keen on fixing a single way to
> get reach-ability information from the nodes - which is based on GPS.<= br>> Thereby, in a way you are doing two things -
> 1. Creating a = fixed way of routing in Control plane
> 2. Creating a fixed topology = for control - that is centralized logically
>
> If my understanding is correct, then how do you propose to mig= rate from
> current topologies to the one proposed by you?
>> Best Regards,
> Rana Pratap Sircar
> GSM+919899003705|=
>
>
> On 15 January 2013 14:02, <sitaraman@nmsworks.co= .in> wrote:
>
>> Hi Rana,
>>=A0 I agree comp= letely with the approach you are suggesting, but i do not
>> see
>= > why that negates or even changes the considerations i have raised on t= he
>> control plane deployment styles?
>> Sitaraman
>> > Dear Sitaraman,
>> >
>> > In my opini= on, there could be three scenarios for SDN deployment -
>> > 1.= Greenfield deployment
>> > 2. Upgrade from existing
>>= ; > 3. Transformation of current network
>> >
>> > Any deployment is cost intensive. Thus, fork= -lift upgrades may not be
>> the
>> > first choice for= many. Thus, we should not create the use cases such a
>> way
>> > as to support only fork-lift upgrades.
>> >
&g= t;> > I like the idea of Overlay networks. It is always helpful to ro= ll-out
>> new
>> > technologies.
>> >
>> > Best Regards,
>> > Rana Pratap Sircar
>> > GSM+9198990= 03705|
>> >
>> >
>> > On 15 January= 2013 10:54, <sitaraman@nmsworks.co.in> wrote:
>> >
>> >> Hi Sharon,
>> >>=A0=A0=A0= Thanks for these valuable insights.
>> >>=A0=A0=A0In the pre= SDN networking world, due to practicality of evolution
>> and
&= gt;> >> backward compatibility needs there arose multiple ways of = doing the
>> same
>> >> thing=C5=AF.i.e gather and use graph rea= chability information.
>> >>=A0=A0=A0SDN is our chance to be= gin with a clean slate, while we need not
>> throw
>> >= ;> the interoperation with existing networks totally out the window, we<= br> >> >> must also be careful not to avoid falling into the trap of
>> restricting
&= gt;> >> the capabilities and flexibility due to its need, even at = first as
>> >> options in isolation, for SDN.
>> &g= t;>=A0=A0=A0What we could consider in IRTF is standardizing a single way= to
>> gather
>> >> reachability information (in a capacit= ated graph, typically). Indeed
>> as
>> >> you poin= t out very aptly, such reachability information can be of
>> >&= gt; varying geographical spans and varying aggregation level spans and
>> these
>> >> can have causal connections. If I under= stand you correctly, an
>> >> Aggregration pivot has implica= tions on the geographic spans that need
>> to
>> >>= considered, and such aggregation pivots serve to segment/split the
>> >> geographic expanse (conceptually in the graph model of the network
>> that
>> >> is) that = the control has to deal with.
>> >>=A0=A0=A0It appears then = if only we have a control of a control that based
>> on
>>= ; >> the
>> >> specified aggregation pivots redistribute the division be= tween
>> >> distributed control and distribution of control = that when combined
>> with
>> >> operations on Grap= h model with scalable algorithmic schemes as
>> mentioned
>> >> in GPS, then we will have a powerfu= l means to exercise traffic
>> control,
>> >> shapi= ng and delivery which are the fundamental aspects of any
>> networ= k.
>> >> A source of complexity we may need to handle is to be abl= e to allow
>> for
>> >> multiple instances of such = distributed control and distribution of
>> >> control working together.
>> >>=A0=A0=A0Such segmentation b= etween distributed control and distribution of
>> >> control= also could yield to a scalable solution=C5=AF
>> >>=A0 Sita= raman
>> >>
>> >>
>> >> >
>>= ; >> > These bring up interesting global-local distinctions.
&g= t;> >> >
>> >> > The scope of a flow definiti= on is clearly local to the aggregation
>> >> point:
>> >> > IP, IP-Port (NAT etc), T= CP connection, HTTP pipeline with a
>> connection
>> >= > > ..depends.
>> >> >
>> >> > Th= e context of handling a flow in a specific point is clearly has
>> >> global
>> >> > user-app considerations.=
>> >> > Distributing control logic is therefore accordin= g to global context
>> >> > mapping not aggregation topology. This i= s different then control
>> >> > distribution considerati= ons for packet forwarding.
>> >> >
>> >> &= gt; The touch point between control and forwarding is therefore a
>> >> practical
>> >> > choice.
>> &= gt;> > The control has to be both locally (scope & mechanics) and= globally
>> >> > (user-app) aware.
>> >> = >
>> >> > Overlays work quite well in that sense, global aware= ness by
>> >> distributed
>> >> > clusteri= ng,
>> >> > local touch point splits, or merges encapsula= tes flows based on
>> global
>> >> > pipeline need.
>> >&g= t; >
>> >> >
>> >> >
>> >= ;> >
>> >> >
>> >> > On Jan 14, 2013, at 17:49, "sitaram= an@nmsworks.co.in"
>> >> > <sitaraman@nmsw= orks.co.in> wrote:
>> >> >
>> >> > Hi,
>> >> &= gt; Some thoughts.
>> >> >=A0 1. Does the separation of c= ontrol plane from the forwarding
>> >> necessarily
>&g= t; >> > mean the control now is to be centralized? It likely is no= t. Though
>> >> the
>> >> > network device itself need = not implment the control plane and can
>> be
>> >> = > interacted via an OpenFlow interface, the control funcationality
>> can
>> >> be
>> >> > a separate distributed system.
>> >> >=A0 2. Model to represent Net= work
>> >> >=A0 =A0=A0=A0Network and traffic flows are fu= ndamentally flows in
>> capacitated
>> >> > grap= hs.=A0 Could we look at using Stanford Graph Processing System
>> >> > (GPS) for SDN based networks. The periodic communica= tion amongst
>> >> > nodes seem to naturally map to a tra= ffic and information flow in a
>> >> > network?
>&g= t; >> >
>> >> >=A0 3. Model to repsresent capacities of network reso= urces and logical
>> >> > abstractions of physical resour= ces.
>> >> >=A0 =A0=A0=A0SDN dosent and probably should n= ot change anything fundamental
>> in
>> >> the
>> >> > traffic flow= itself. This means that here SDN must look into
>> reusing
>> >> > existing models.=A0 TMF models is a like= ly candidate.
>> >> >=A0 4. Model to represent faults.>> >> >=A0 =A0=A0=A0Same as above. New type of faults relat= ed to the decoupled
>> >> (possibly
>> >> > yet distributed) cont= rol plane to be harmonized with model for
>> >> > existin= g faults. Again TMF is a source.
>> >> >=A0 5. Model to r= espresent Business aspects (Products, Orders such as
>> >> time
>> >> > to delivery commitments)>> >> >=A0 =A0=A0=A0Same as above and again TMF is a sourc= e for this model. The new
>> >> SDN
>> >> >= ; network could leverage by being able to be invoked or referred to
>> in
>> >> > the existing TMF business model aspec= ts. After all these are
>> directly
>> >> > related to revenue and Customer Experie= nce Management.
>> >> >=A0 6. Is it distributed control, = distribution of control or soemwhere
>> in
>> >> &g= t; between that is preferable. Distributed control can be a conceptual
>> >> > centralized control which is implemented in a distri= bued manner.
>> Can
>> >> > this nature be adapt= ively changed. Any aspects of learning in
>> control
>> &= gt;> > plane in SDN networks.
>> >> >=A0 7. Layers of control Ethernet Layer, MPLS layer, = IP layer.
>> >> >=A0 8. Service Providers' bottom lin= e is business and this means the
>> TMF
>> >> FAB >> >> > Fulfilment, Assurance and Billing. SDN models must l= everage the
>> >> existing
>> >> > model a= s transparently as is practically feasibile.
>> >> > Sitaraman
>> >= ;> >
>> >> > Possibly of interest.
>> >= > >>
>> >> >> Begin forwarded message:
>> >> >>
>> >> >>> From: "Eg= gert, Lars" <lars@netapp.com>
>> >> >>> Su= bject: [irtf-discuss] New: Software-Defined Networking Research
>> >> Group
>> >> >>> (SDNRG)
>&g= t; >> >>> Date: January 14, 2013 10:24:57 GMT+01:00
>&= gt; >> >>> To: "<irtf-announce@irtf.org>&quo= t; <irtf-announce@irtf.org>,
>> >> >>> "<irtf-discuss@irtf.org>" <irtf-discus= s@irtf.org>
>> >> >>> Cc: "sdn@irtf.org" <sdn@irtf.org>
&= gt;> >> >>> Reply-To: "irtf-discuss@irtf.org&quo= t; <irtf-discuss@irtf.org>
>> >> >>>
>> >> >>> A new IRTF= research group on Software-Defined Networking has been
>> >>= ; >>> chartered:
>> >> >>>
>> >> >>> The Software-Defined Networ= king Research Group (SDNRG)
>> investigates
>> >> S= DN
>> >> >>> from various perspectives with the goa= l of identifying the
>> >> approaches
>> >> >>> that
>= > >> >>> can be defined, deployed and used in the near te= rm as well
>> >> identifying
>> >> >>&g= t; future research challenges. In particular, key areas of interest
>> >> >>> include
>> >> >>> so= lution scalability, abstractions, and programming languages and
>>= >> >>> paradigms
>> >> >>> particul= arly useful in the context of SDN. In addition, it is an
>> >> >>> explicit
>> >> >>> g= oal of the SDNRG to provide a forum for researchers to
>> investigate
>> >> key
>> >> &= gt;>> and interesting problems in the Software-Defined Networking
= >> field.
>> >> >>>
>> >> >= >> Charter and participation information can be found at
>> >> >>> http://irtf.org/sdnrg
>> >> >>>
>= > >> >>> Lars Eggert
>> >> >>> IR= TF Chair
>> >> >>
>> >> >> __________________= _____________________________
>> >> >> openflow-discus= s mailing list
>> >> >> openflow-discuss= @lists.stanford.edu
>> >> >> https://mailman.stanford.edu/m= ailman/listinfo/openflow-discuss
>> >> >>
>&= gt; >> >> --
>> >> >> This message has been scanned for viruses and>> >> >> dangerous content by MailScanner, and is
>= ;> >> >> believed to be clean.
>> >> >
>> >> >
>> >> >
>> >> > = --
>> >> > This message has been scanned for viruses and<= br>>> >> > dangerous content by MailScanner, and is
>&= gt; >> > believed to be clean.
>> >> >
>> >> > __________________________= _____________________
>> >> > sdn mailing list
>>= ; >> > sdn@irtf.org
>> >> > https://www.irtf.org/mailman/listinfo/sdn
>&g= t; >> >
>> >> >
>> >> > ______= _________________________________________
>> >> > sdn mailing list
>> >> > sdn@irtf.org=
>> >> > https://www.irtf.org/mailman/listinfo/sdn
>> >> >
>> >> > --
>> >> &g= t; This message has been scanned for viruses and
>> >> > = dangerous content by MailScanner, and is
>> >> > believed= to be clean.
>> >> >
>> >>
>> >>
>>= ; >>
>> >> --
>> >> This message has been scanned for viruses and
&= gt;> >> dangerous content by MailScanner, and is
>> >&= gt; believed to be clean.
>> >>
>> >> _______= ________________________________________
>> >> sdn mailing list
>> >> sdn@irtf.org
>>= >> https://www.irtf.org/mailman/listinfo/sdn
>> >>
>> >
>> > --
>> > Thi= s message has been scanned for viruses and
>> > dangerous conte= nt by MailScanner, and is
>> > believed to be clean.
>>= ; >
>> >
>>
>>
>>
>> --
>>= ; This message has been scanned for viruses and
>> dangerous conte= nt by MailScanner, and is
>> believed to be clean.
>>
>>
>
&g= t; --
> This message has been scanned for viruses and
> dangero= us content by MailScanner, and is
> believed to be clean.
>
>



--
T= his message has been scanned for viruses and
dangerous content by MailSc= anner, and is
believed to be clean.

_____________________________= __________________
sdn mailing list
sdn@irtf.org
https://www.irtf.org/mailman/listinfo/sdn<= br>

________________________________= _______________
sdn mailing list
sdn@irtf.org
htt= ps://www.irtf.org/mailman/listinfo/sdn


--047d7b6777000b714004d358456a-- From sitaraman@nmsworks.co.in Tue Jan 15 18:05:29 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7814311E80F4 for ; Tue, 15 Jan 2013 18:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id to00ERo+5nte for ; Tue, 15 Jan 2013 18:05:28 -0800 (PST) Received: from indlocal.nmsworks.co.in (indus.nmsworks.co.in [14.140.238.3]) by ietfa.amsl.com (Postfix) with ESMTP id 4596F21F85CE for ; Tue, 15 Jan 2013 18:05:26 -0800 (PST) Received: from www.nmsworks.co.in (localhost [127.0.0.1]) by indlocal.nmsworks.co.in (8.13.8/8.13.8) with ESMTP id r0G23Glc000364; Wed, 16 Jan 2013 07:33:16 +0530 Received: from 117.193.217.116 (SquirrelMail authenticated user sitaraman) by www.nmsworks.co.in with HTTP; Wed, 16 Jan 2013 07:33:21 +0530 (IST) Message-ID: <60364.117.193.217.116.1358301801.squirrel@www.nmsworks.co.in> Date: Wed, 16 Jan 2013 07:33:21 +0530 (IST) From: sitaraman@nmsworks.co.in To: "bhal d" User-Agent: SquirrelMail/1.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-NMSWorks-MailScanner-Information: Please contact the ISP for more information X-NMSWorks-MailScanner-ID: r0G23Glc000364 X-NMSWorks-MailScanner: Found to be clean X-NMSWorks-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.9, required 4, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-NMSWorks-MailScanner-From: sitaraman@nmsworks.co.in Cc: "sdn@irtf.org" , Rana Sircar , LarsEggert , David Meyer , "openflow-discuss@mailman.stanford.edu" , Sharon Barkai , sitaraman@nmsworks.co.in Subject: Re: [Sdn] {Disarmed} Re: [openflow-discuss] Fwd: [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG) X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 02:05:29 -0000 Ref: http://conferences.sigcomm.org/sigcomm/2012/paper/hotsdn/p43.pdf It appears to me we are discussing multiple aspects here all of which are relevant and important. At least two of which are 1. Architecture of the system (an SDN based network): This includes how many controller sub components are there, do they work in parallel what is their paradigm of communicating (in groups, summarization), what topologies they form (not network topologies but the controller themselves), aggregation, traffic related activities are performed where and by whom and policyt related activites are performed by where and whom 2. Programming the system with the said Architecture. This (see Ref.) can occur at several layers of granularity. This deals with how we give expressivity using increasingly higher level languages (Assembly, C/C++, Perl Java, Scripting...) to exploit the capabilities provided by the hardware. 1. and 2. are related yet different. The parallels to Computing industry is almost complete. Indeed Sun was right, the Network IS the Computer!! Dave had earlier pointed us to In case you haven't seen these: http://conferences.sigcomm.org/sigcomm/2012/hotsdn.php --dmm Maybe we can look at some of these.... > I agree that there are several different discussions in networking > communities about programmability.  However, most of the discussions still > focus on topics like control plane/data plane, distributed vs centralized > control plane, scalability of solutions, Hybrid solutions, call graph, > networking models etc. The discussion in this thread is no exception. I > think these discussions are very good but they need to happen in the > context of overall programmability goals. > Thanks > Bhalchandra > > --- On Tue, 1/15/13, David Meyer wrote: > > From: David Meyer > Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: > Software-Defined Networking Research Group (SDNRG) > To: "bhal d" > Cc: "Rana Sircar" , sitaraman@nmsworks.co.in, > "Sharon Barkai" , "LarsEggert" , > "sdn@irtf.org" , "openflow-discuss@mailman.stanford.edu" > > Date: Tuesday, January 15, 2013, 10:52 AM > > > > On Tue, Jan 15, 2013 at 8:39 AM, bhal d wrote: > > > This is great discussion. Since we are talking about "Software defined", I > think it implies some type of software programmability of a network. In > present day I haven't seen too many applications trying to program > network. So it is a new concept for them. So how about first defining, > what programmability of network means in simple terms ? > > I think many programmers are not networking experts and don't necessarily > understand details about different protocols, link types, topological > graphs etc. However for them behavior of their application is important > and they certainly understand importance of things like control over > available bandwidth, data loss, availability of network, having shortest > path to the destination etc. So my question is can we define what > programmability or "software defined " means in simple terms ? We can then > go on to define what it > takes to create that programmability including API, infrastructure etc. > This discussion can also involve what level of network programmability is > desirable and then there can be a discussion about what is achievable. > > At present I see most of the discussion about splitting control plane and > data plane or distributed controller etc. All this discussion is good but > without considering what user wants and type of user programmability model > we have in mind, it is incomplete. > > > dmm> actually my sense (and experience) is quite different. While I can > agree that in the early days of "SDN" folks were talking about the issues > you mention (splitting the control and data planes, programmable > forwarding planes, etc), generally thinking in both the research community > and industry and evolved quite a bit to include not only OF/SDN but a much > wider scope. Consider for example I2RS or PCE(P), or what's going on > in Sophia Antipolis this week (ETSI ISG on NfV). In addition, there are > robust discussions going on (again, both in industry and in the research > community) around the question of abstractions for "network programming" > as well as ecosystem models for SDN. BTW, there are literally hundreds of > use cases proposed by every segment of the network community around some > form of network programmability, data models, and the like. --dmm > > > Thanks > Bhalchandra > --- On Tue, 1/15/13, sitaraman@nmsworks.co.in > wrote: > > > From: sitaraman@nmsworks.co.in > > Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: > Software-Defined Networking Research Group (SDNRG) > To: "Rana Sircar" > > Cc: "Eggert, Lars" > , "Sharon Barkai" , > "sdn@irtf.org" , "openflow-discuss@mailman.stanford.edu" > > > Date: Tuesday, January 15, 2013, 1:48 AM > > Hi Rana, > Thanks for the discussion. > GPS was more of mooting an implementation choice which (GPS or something > similar) philosophy seemed to mesh very well with the problem at hand. So > > let us set that aside for now, as it dosent impact this particular topic > of discussion. > I did not intend to come across as saying that there should be only a > single way to get reachability information in the control. But i did > > intend to say that there should be a single way (that is, there is a > single solution possible, but that does not claim to be the only solution > that will work to get reachability information). > In addition this single way of getting the reachability > could also be > able to get reachability information from the existing sources of such > information too... > Sitaraman >> Hi Sitaraman, >> >> As I understand, you are keen on fixing a single way to > >> get reach-ability information from the nodes - which is based on GPS. >> Thereby, in a way you are doing two things - >> 1. Creating a fixed way of routing in Control plane >> 2. Creating a fixed topology for control - that is centralized logically > >> >> If my understanding is correct, then how do you propose to migrate from >> current topologies to the one proposed by you? >> >> Best Regards, >> Rana Pratap Sircar >> GSM+919899003705| > >> >> >> On 15 January 2013 14:02, wrote: >> >>> Hi Rana, >>>  I agree completely > with the approach you are suggesting, but i do not >>> see >>> why that negates or even changes the considerations i have raised on >>> the >>> control plane deployment styles? >>> Sitaraman > >>> > Dear Sitaraman, >>> > >>> > In my opinion, there could be three scenarios for SDN deployment - >>> > 1. Greenfield deployment >>> > 2. Upgrade from existing >>> > 3. Transformation of current network > >>> > >>> > Any deployment is cost intensive. Thus, fork-lift upgrades may not be >>> the >>> > first choice for many. Thus, we should not create the use cases such >>> a >>> way > >>> > as to support only fork-lift upgrades. >>> > >>> > I like the idea of Overlay networks. It is always helpful to roll-out >>> new >>> > technologies. >>> > > >>> > Best > Regards, >>> > Rana Pratap Sircar >>> > GSM+919899003705| >>> > >>> > >>> > On 15 January 2013 10:54, wrote: > >>> > >>> >> Hi Sharon, >>> >>   Thanks for these valuable insights. >>> >>   In the preSDN networking world, due to practicality of evolution >>> and >>> >> backward compatibility needs there arose multiple ways of doing the > >>> same >>> >> thingů.i.e gather and use graph reachability information. >>> >>   SDN is our chance to begin with a clean slate, while we need not >>> throw >>> >> the interoperation with existing networks totally out the window, we > >>> >> must also be > careful not to avoid falling into the trap of >>> restricting >>> >> the capabilities and flexibility due to its need, even at first as >>> >> options in isolation, for SDN. >>> >>   What we could consider in IRTF is standardizing a single way to > >>> gather >>> >> reachability information (in a capacitated graph, typically). Indeed >>> as >>> >> you point out very aptly, such reachability information can be of >>> >> varying geographical spans and varying aggregation level spans and > >>> these >>> >> can have causal connections. If I understand you correctly, an >>> >> Aggregration pivot has implications on the geographic spans that >>> need >>> to >>> >> considered, and such aggregation pivots serve to segment/split the > >>> >> geographic expanse (conceptually in the > graph model of the network >>> that >>> >> is) that the control has to deal with. >>> >>   It appears then if only we have a control of a control that based >>> on >>> >> the > >>> >> specified aggregation pivots redistribute the division between >>> >> distributed control and distribution of control that when combined >>> with >>> >> operations on Graph model with scalable algorithmic schemes as > >>> mentioned >>> >> in GPS, then we will have a powerful means to exercise traffic >>> control, >>> >> shaping and delivery which are the fundamental aspects of any >>> network. > >>> >> A source of complexity we may need to handle is to be able to allow >>> for >>> >> multiple instances of such distributed control and distribution of >>> >> > control working together. >>> >>   Such segmentation between distributed control and distribution of >>> >> control also could yield to a scalable solutionů >>> >>  Sitaraman > >>> >> >>> >> >>> >> > >>> >> > These bring up interesting global-local distinctions. >>> >> > >>> >> > The scope of a flow definition is clearly local to the aggregation > >>> >> point: >>> >> > IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a >>> connection >>> >> > ..depends. >>> >> > >>> >> > The context of handling a flow in a specific point is clearly has > >>> >> global >>> >> > user-app considerations. >>> >> > Distributing control logic is therefore according to global > context >>> >> > mapping not aggregation topology. This is different then control >>> >> > distribution considerations for packet forwarding. >>> >> > >>> >> > The touch point between control and forwarding is therefore a > >>> >> practical >>> >> > choice. >>> >> > The control has to be both locally (scope & mechanics) and >>> globally >>> >> > (user-app) aware. >>> >> > > >>> >> > Overlays work quite well in that sense, global awareness by >>> >> distributed >>> >> > clustering, >>> >> > local touch point splits, or merges encapsulates flows based on > >>> global >>> >> > pipeline need. >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > > >>> >> > On Jan 14, 2013, at 17:49, "sitaraman@nmsworks.co.in" >>> >> > wrote: > >>> >> > >>> >> > Hi, >>> >> > Some thoughts. >>> >> >  1. Does the separation of control plane from the forwarding >>> >> necessarily >>> >> > mean the control now is to be centralized? It likely is not. >>> Though > >>> >> the >>> >> > network device itself need not implment the control plane and can >>> be >>> >> > interacted via an OpenFlow interface, the control funcationality > >>> can >>> >> be >>> >> > a separate > distributed system. >>> >> >  2. Model to represent Network >>> >> >     Network and traffic flows are fundamentally flows in >>> capacitated >>> >> > graphs.  Could we look at using Stanford Graph Processing System > >>> >> > (GPS) for SDN based networks. The periodic communication amongst >>> >> > nodes seem to naturally map to a traffic and information flow in a >>> >> > network? >>> >> > > >>> >> >  3. Model to repsresent capacities of network resources and >>> logical >>> >> > abstractions of physical resources. >>> >> >     SDN dosent and probably should not change anything fundamental > >>> in >>> >> the >>> >> > traffic flow itself. This means that here SDN must look into >>> > reusing >>> >> > existing models.  TMF models is a likely candidate. >>> >> >  4. Model to represent faults. >>> >> >     Same as above. New type of faults related to the decoupled > >>> >> (possibly >>> >> > yet distributed) control plane to be harmonized with model for >>> >> > existing faults. Again TMF is a source. >>> >> >  5. Model to respresent Business aspects (Products, Orders such as > >>> >> time >>> >> > to delivery commitments) >>> >> >     Same as above and again TMF is a source for this model. The >>> new >>> >> SDN >>> >> > network could leverage by being able to be invoked or referred to > >>> in >>> >> > the existing TMF business model aspects. After all these are >>> > directly >>> >> > related to revenue and Customer Experience Management. >>> >> >  6. Is it distributed control, distribution of control or >>> soemwhere >>> in >>> >> > between that is preferable. Distributed control can be a >>> conceptual > >>> >> > centralized control which is implemented in a distribued manner. >>> Can >>> >> > this nature be adaptively changed. Any aspects of learning in >>> control >>> >> > plane in SDN networks. > >>> >> >  7. Layers of control Ethernet Layer, MPLS layer, IP layer. >>> >> >  8. Service Providers' bottom line is business and this means the >>> TMF >>> >> FAB > >>> >> > Fulfilment, Assurance and Billing. SDN models must leverage the >>> >> existing >>> >> > model as transparently as is > practically feasibile. >>> >> > Sitaraman >>> >> > >>> >> > Possibly of interest. >>> >> >> >>> >> >> Begin forwarded message: > >>> >> >> >>> >> >>> From: "Eggert, Lars" >>> >> >>> Subject: [irtf-discuss] New: Software-Defined Networking >>> Research > >>> >> Group >>> >> >>> (SDNRG) >>> >> >>> Date: January 14, 2013 10:24:57 GMT+01:00 >>> >> >>> To: "" , > >>> >> > >>> "" > >>> >> >>> Cc: "sdn@irtf.org" >>> >> >>> Reply-To: "irtf-discuss@irtf.org" > >>> >> >>> >>> >> >>> A new IRTF research group on Software-Defined Networking has >>> been >>> >> >>> chartered: >>> >> > >>> >>> >> >>> The Software-Defined Networking Research Group (SDNRG) >>> investigates >>> >> SDN >>> >> >>> from various perspectives with the goal of identifying the > >>> >> approaches >>> >> >>> that >>> >> >>> can be defined, deployed and used in the near term as well >>> >> identifying >>> >> >>> future research challenges. In particular, key areas of interest > >>> >> >>> include >>> >> >>> solution scalability, abstractions, and programming languages >>> and >>> >> >>> paradigms >>> >> >>> particularly useful in the context of SDN. In addition, it is an > >>> >> >>> explicit >>> >> >>> goal of the SDNRG to provide a forum for researchers > to >>> investigate >>> >> key >>> >> >>> and interesting problems in the Software-Defined Networking >>> field. >>> >> >>> >>> >> >>> Charter and participation information can be found at > >>> >> >>> http://irtf.org/sdnrg >>> >> >>> >>> >> >>> Lars Eggert >>> >> >>> IRTF Chair > >>> >> >> >>> >> >> _______________________________________________ >>> >> >> openflow-discuss mailing list >>> >> >> openflow-discuss@lists.stanford.edu > >>> >> >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>> >> >> >>> >> >> -- > >>> >> >> This message has been scanned for viruses and >>> >> >> dangerous content by MailScanner, and is >>> >> >> believed to be clean. >>> >> > > >>> >> > >>> >> > >>> >> > -- >>> >> > This message has been scanned for viruses and >>> >> > dangerous content by MailScanner, and is >>> >> > believed to be clean. > >>> >> > >>> >> > _______________________________________________ >>> >> > sdn mailing list >>> >> > sdn@irtf.org > >>> >> > https://www.irtf.org/mailman/listinfo/sdn >>> >> > >>> >> > >>> >> > _______________________________________________ > >>> >> > sdn mailing list >>> >> > sdn@irtf.org >>> >> > https://www.irtf.org/mailman/listinfo/sdn > >>> >> > >>> >> > -- >>> >> > This message has been scanned for viruses and >>> >> > dangerous content by MailScanner, and is >>> >> > believed to be clean. > >>> >> > >>> >> >>> >> >>> >> >>> >> > -- >>> >> This message has been scanned for viruses and >>> >> dangerous content by MailScanner, and is >>> >> believed to be clean. >>> >> >>> >> _______________________________________________ > >>> >> sdn mailing list >>> >> sdn@irtf.org >>> >> https://www.irtf.org/mailman/listinfo/sdn > >>> >> >>> > >>> > -- >>> > This message has been scanned for viruses and >>> > dangerous content by MailScanner, and is >>> > believed to be clean. >>> > > >>> > >>> >>> >>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and > is >>> believed to be clean. >>> >>> >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> > >> > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > > > _______________________________________________ > > sdn mailing list > > sdn@irtf.org > > https://www.irtf.org/mailman/listinfo/sdn > > > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From yulei.frank.wu@gmail.com Tue Jan 15 19:05:55 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D16811E80AD for ; Tue, 15 Jan 2013 19:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.012 X-Spam-Level: X-Spam-Status: No, score=-3.012 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAACDYfKQsQW for ; Tue, 15 Jan 2013 19:05:54 -0800 (PST) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE4D11E80A2 for ; Tue, 15 Jan 2013 19:05:54 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id wz17so440638pbc.34 for ; Tue, 15 Jan 2013 19:05:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:reply-to:subject:x-priority:x-guid :x-has-attach:x-mailer:mime-version:message-id:content-type; bh=0Ax54cO05NRwl1wPzA/NtsIK70nkHirKV1ynX73QDyk=; b=Jlz07d/aabylixkjPysz2ZDF23+Is/aw6AhcBVwsL3Su3muNNPx5OaTpm7BZ21arSQ aBOuouJv//Quyvbi1l8/C9SUy8yj6+v7q3zgd7SXXXomB9pj1Y0S9bvpvIXMR2gVHAvL lXAXhAVUlmM12rqXctaQGjIZQO1Ne7a5Mq5L4C/PcAfAKVHFntbtWv2i1Ui6AuicT/rC IHi0hSPWMR7MPjPV4/c7AEu7wR7Z/YaNlQ9UE92NV9WnEG6VO6Q422auW9DbWf5cFpS9 uBJJ1mhwkzkXYVPU3pvQ1RwfKZz5AnuG2uB/xYvELw/y0KWs0WJDcD329OYTHjexSPsL zH4A== X-Received: by 10.66.89.132 with SMTP id bo4mr18083860pab.62.1358305553756; Tue, 15 Jan 2013 19:05:53 -0800 (PST) Received: from ylwu-THINK ([159.226.58.202]) by mx.google.com with ESMTPS id wg3sm11350131pbc.28.2013.01.15.19.05.52 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 15 Jan 2013 19:05:53 -0800 (PST) Date: Wed, 16 Jan 2013 11:05:44 +0800 From: "Yulei Wu" To: sdn X-Priority: 3 X-GUID: 1F501BB3-75A8-485C-BB73-EC3A0948E7CA X-Has-Attach: no X-Mailer: Foxmail 7.0.1.87[cn] Mime-Version: 1.0 Message-ID: <2013011611054307316346@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart774681654544_=----" Subject: [Sdn] CFP: EURASIP Journal on Wireless Communications and Networking - SI on "Advances in Trust, Security and Privacy for Wireless Network" - DEADLINE EXTENDED X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "yulei.frank.wu" List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 03:05:55 -0000 This is a multi-part message in MIME format. ------=_001_NextPart774681654544_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBDb2xsZWFndWVzLA0KDQpJIHdvdWxkIGxpa2UgdG8gaW52aXRlIHlvdSB0byBjb25zaWRl ciB0aGlzIFNJIGFzIGEgcG90ZW50aWFsIHRhcmdldCBmb3IgeW91ciByZXNlYXJjaCB3b3JrIG9y IHRoZSBvbmUgb2YgeW91ciB0ZWFtLiBJZiB5b3UgZG8gaXQsIHBsZWFzZSBsZXQgbWUga25vdy4N Cg0KaHR0cDovL2p3Y24uZXVyYXNpcGpvdXJuYWxzLmNvbS9zaXRlcy8xMDIzNC9wZGYvaDkzMjNf cGZfY2ZwX3NwcmluZ2Vyb3Blbl9zcGVjaWFsX2lzc3VlX2V1cmFzaXBfandjX2dsb2JhbF8yLnBk Zg0KDQpTdWJtaXNzaW9uIFNjaGVkdWxlDQotIFBhcGVyIFN1Ym1pc3Npb24gRGVhZGxpbmU6IDMx IEphbnVhcnksIDIwMTM7ICAoRVhURU5ERUQpDQoNCkVVUkFTSVAgSm91cm5hbCBvbiBXaXJlbGVz cyBDb21tdW5pY2F0aW9ucyBhbmQgTmV0d29ya2luZw0KU3BlY2lhbCBJc3N1ZSBvbiANCkFkdmFu Y2VzIGluIFRydXN0LCBTZWN1cml0eSBhbmQgUHJpdmFjeSBmb3IgV2lyZWxlc3MgTmV0d29ya3MN Cg0KDQpJbiByZWNlbnQgeWVhcnMsIHdpcmVsZXNzIG5ldHdvcmtzIGhhdmUgYmVjb21lIG9uZSBv ZiB0aGUgbW9zdCBpbmZsdWVudGlhbCB0ZWNobm9sb2dpY2FsIGFjY29tcGxpc2htZW50cyBhbmQg cGVydmFkZWQgb3VyIGRhaWx5IGxpdmVzIGluIGZvcm1zIG9mIG1vYmlsZSB0ZWxlcGhvbnkgYW5k IHdpcmVsZXNzIGNvbXB1dGluZy4gRHVlIHRvIGl0cyByYXBpZCBkZXZlbG9wbWVudCBhbmQgd2lk ZS1zcHJlYWQgYXBwbGljYXRpb25zLCB0cnVzdCwgc2VjdXJpdHkgYW5kIHByaXZhY3kgaXNzdWVz IGluIHdpcmVsZXNzIG5ldHdvcmtzIGhhdmUgYmVjb21lIHZlcnkgaW1wb3J0YW50IHRvcGljcy4g QXMgYSByZXN1bHQsIHdlIG5lZWQgdG8gYnVpbGQgd2lyZWxlc3Mgc3lzdGVtcyBhbmQgbmV0d29y a3MgaW4gd2hpY2ggdmFyaW91cyBhcHBsaWNhdGlvbnMgYWxsb3cgdXNlcnMgdG8gZW5qb3kgbW9y ZSBjb21wcmVoZW5zaXZlIHNlcnZpY2VzIHdoaWxlIHByZXNlcnZpbmcgdHJ1c3QsIHNlY3VyaXR5 IGFuZCBwcml2YWN5IGF0IHRoZSBzYW1lIHRpbWUuDQoNClRoZSBtYWluIG9iamVjdGl2ZSBvZiB0 aGUgc3BlY2lhbCBpc3N1ZSBpcyB0byBwcm92aWRlIGFuIGlkZWFsIGludGVybmF0aW9uYWwgY29t bXVuaWNhdGlvbiBtZWRpdW0gZm9yIHRoZSByZXNlYXJjaCBjb21tdW5pdHkgYW5kIGZhY2lsaXRh dGUgdGhlIGVuaGFuY2VtZW50IG9mIHRoZSBmaW5kaW5ncyBvZiB0aGUgcmFwaWRseSBkZXZlbG9w ZWQgZmllbGQgb2YgdHJ1c3QsIHNlY3VyaXR5IGFuZCBwcml2YWN5IGZvciB3aXJlbGVzcyBuZXR3 b3Jrcy4gDQoNClRvcGljcyBvZiBwYXJ0aWN1bGFyIGludGVyZXN0cyBpbmNsdWRlOiANCi0gVHJ1 c3QsIHNlY3VyaXR5IGFuZCBwcml2YWN5IG1vZGVscyBmb3Igd2lyZWxlc3MgbmV0d29ya3MNCi0g VHJ1c3QsIHNlY3VyaXR5IGFuZCBwcml2YWN5IGFsZ29yaXRobXMgZm9yIHdpcmVsZXNzIG5ldHdv cmtzDQotIFRydXN0LCBzZWN1cml0eSBhbmQgcHJpdmFjeSBtYW5hZ2VtZW50IGZvciB3aXJlbGVz cyBuZXR3b3Jrcw0KLSBDcm9zcy1sYXllciBkZXNpZ24gZm9yIHRydXN0LCBzZWN1cml0eSBhbmQg cHJpdmFjeSBpbiB3aXJlbGVzcyBuZXR3b3Jrcw0KLSBUcnVzdCwgc2VjdXJpdHkgYW5kIHByaXZh Y3kgb2YgbWVzaCBuZXR3b3Jrcw0KLSBUcnVzdCwgc2VjdXJpdHkgYW5kIHByaXZhY3kgb2Ygc2Vu c29yIG5ldHdvcmtzDQotIFRydXN0LCBzZWN1cml0eSBhbmQgcHJpdmFjeSBvZiBtb2JpbGUgYWQg aG9jIG5ldHdvcmtzDQotIFRydXN0LCBzZWN1cml0eSBhbmQgcHJpdmFjeSBvZiB2ZWhpY3VsYXIg YWQgaG9jIG5ldHdvcmtzDQotIFRydXN0LCBzZWN1cml0eSBhbmQgcHJpdmFjeSBvZiBtb2JpbGUg bXVsdGltZWRpYSB0cmFuc21pc3Npb24NCi0gRWNvbm9taWNzIG9mIHdpcmVsZXNzIG5ldHdvcmsg c2VjdXJpdHkNCi0gS2V5IG1hbmFnZW1lbnQgaW4gd2lyZWxlc3MgbmV0d29ya3MNCi0gVGhyZWF0 IGFuZCB2dWxuZXJhYmlsaXR5IGFuYWx5c2lzIGZvciBtb2JpbGUgY29tbXVuaWNhdGlvbg0KDQoN ClN1Ym1pc3Npb24gSW5zdHJ1Y3Rpb25zOg0KDQpCZWZvcmUgc3VibWlzc2lvbiBhdXRob3JzIHNo b3VsZCBjYXJlZnVsbHkgcmVhZCBvdmVyIHRoZSBJbnN0cnVjdGlvbnMgZm9yIEF1dGhvcnMsIHdo aWNoIGFyZSBsb2NhdGVkIGF0IGh0dHA6Ly9qd2NuLmV1cmFzaXBqb3VybmFscy5jb20vYXV0aG9y cy9pbnN0cnVjdGlvbnMuIFByb3NwZWN0aXZlIGF1dGhvcnMgc2hvdWxkIHN1Ym1pdCBhbiBlbGVj dHJvbmljIGNvcHkgb2YgdGhlaXIgY29tcGxldGUgbWFudXNjcmlwdCB0aHJvdWdoIHRoZSBTcHJp bmdlck9wZW4gc3VibWlzc2lvbiBzeXN0ZW0gYXQgaHR0cDovL2p3Y24uZXVyYXNpcGpvdXJuYWxz LmNvbS9tYW51c2NyaXB0IGFjY29yZGluZyB0byB0aGUgc3VibWlzc2lvbiBzY2hlZHVsZS4gVGhl eSBzaG91bGQgc3BlY2lmeSB0aGUgbWFudXNjcmlwdCBhcyBhIHN1Ym1pc3Npb24gdG8gdGhlIKGw U3BlY2lhbCBJc3N1ZSBvbiBBZHZhbmNlcyBpbiBUcnVzdCwgU2VjdXJpdHkgYW5kIFByaXZhY3kg Zm9yIFdpcmVsZXNzIE5ldHdvcmtzobEgaW4gdGhlIGNvdmVyIGxldHRlci4gQWxsIHN1Ym1pc3Np b25zIHdpbGwgdW5kZXJnbyBpbml0aWFsIHNjcmVlbmluZyBieSB0aGUgR3Vlc3QgRWRpdG9ycyBm b3IgZml0IHRvIHRoZSB0aGVtZSBvZiB0aGUgU3BlY2lhbCBJc3N1ZSBhbmQgcHJvc3BlY3RzIGZv ciBzdWNjZXNzZnVsbHkgbmVnb3RpYXRpbmcgdGhlIHBlZXItcmV2aWV3IHByb2Nlc3MuDQoNCg0K QmVzdCByZWdhcmRzLA0KDQpHdWVzdCBFZGl0b3JzDQpZdWxlaSBXdSwgQ29tcHV0ZXIgTmV0d29y ayBJbmZvcm1hdGlvbiBDZW50ZXIsIENoaW5lc2UgQWNhZGVteSBvZiBTY2llbmNlcywgQ2hpbmEN CkdleW9uZyBNaW4sIFVuaXZlcnNpdHkgb2YgQnJhZGZvcmQsIFVLDQpGZWxpeCBHb21leiBNYXJt b2wsIE5FQyBFdXJvcGUsIEdlcm1hbnkNCkFobWVkIEFsLUR1YmFpLCBFZGluYnVyZ2ggTmFwaWVy IFVuaXZlcnNpdHksIFVL ------=_001_NextPart774681654544_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Dear Colleagues,
 
I would like to invite you to cons= ider this SI as a potential target for&= nbsp;your research work or the one of y= our team. If you do it, please let = ;me know.
 
http://jwcn.eurasipjournals.com/sites/10234/pdf/h9323_pf_cfp_springer= open_special_issue_eurasip_jwc_global_2.pdf
 
Submission Schedule
- Paper Submission Deadline: 31 January,&nbs= p;2013;  (EXTENDED)
 
EURASIP Journal on Wireless Communications a= nd Networking
Special Issue on 
Advances in Trust, Security and Privacy = ;for Wireless Networks
 
 
In recent years, wireless networks have = ;become one of the most influential technolo= gical accomplishments and pervaded our daily = ;lives in forms of mobile telephony and = ;wireless computing. Due to its rapid develo= pment and wide-spread applications, trust, securi= ty and privacy issues in wireless networks&n= bsp;have become very important topics. As a&= nbsp;result, we need to build wireless syste= ms and networks in which various application= s allow users to enjoy more comprehensive&nb= sp;services while preserving trust, security and&= nbsp;privacy at the same time.
 
The main objective of the special issue=  is to provide an ideal international c= ommunication medium for the research community&nb= sp;and facilitate the enhancement of the fin= dings of the rapidly developed field of = ;trust, security and privacy for wireless ne= tworks. 
 
Topics of particular interests include: 
- Trust, security and privacy models fo= r wireless networks
- Trust, security and privacy algorithms&nbs= p;for wireless networks
- Trust, security and privacy management&nbs= p;for wireless networks
- Cross-layer design for trust, security&nbs= p;and privacy in wireless networks
- Trust, security and privacy of mesh&n= bsp;networks
- Trust, security and privacy of sensor=  networks
- Trust, security and privacy of mobile=  ad hoc networks
- Trust, security and privacy of vehicu= lar ad hoc networks
- Trust, security and privacy of mobile=  multimedia transmission
- Economics of wireless network security
- Key management in wireless networks
- Threat and vulnerability analysis for = ;mobile communication
 
 
Submission Instructions:
 
Before submission authors should carefully r= ead over the Instructions for Authors, which=  are located at http://jwcn.eurasipjournals.com/author= s/instructions. Prospective authors should submit = ;an electronic copy of their complete manusc= ript through the SpringerOpen submission system&n= bsp;at http://jwcn.eurasipjournals.com/manuscript according = ;to the submission schedule. They should spe= cify the manuscript as a submission to = the =A1=B0Special Issue on Advances in Trust= , Security and Privacy for Wireless Networks= =A1=B1 in the cover letter. All submissions&= nbsp;will undergo initial screening by the G= uest Editors for fit to the theme of&nb= sp;the Special Issue and prospects for succe= ssfully negotiating the peer-review process.
 
 
Best regards,
 
Guest Editors
Yulei Wu, Computer Network Information Cente= r, Chinese Academy of Sciences, China
Geyong Min, University of Bradford, UK
Felix Gomez Marmol, NEC Europe, Germany
Ahmed Al-Dubai, Edinburgh Napier University, = ;UK
------=_001_NextPart774681654544_=------ From Sharon@Contextream.com Tue Jan 15 20:08:05 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F5C21F8319 for ; Tue, 15 Jan 2013 20:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsciQorsIt2z for ; Tue, 15 Jan 2013 20:08:04 -0800 (PST) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7B32221F8200 for ; Tue, 15 Jan 2013 20:08:01 -0800 (PST) Received: from mail49-db3-R.bigfish.com (10.3.81.254) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 16 Jan 2013 04:08:00 +0000 Received: from mail49-db3 (localhost [127.0.0.1]) by mail49-db3-R.bigfish.com (Postfix) with ESMTP id 6361730025B; Wed, 16 Jan 2013 04:08:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.213; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0610HT003.eurprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -2 X-BigFish: VPS-2(zf7Iz98dI9371Ic3f2I1432I1447I9a6kzz1ee6h1de0h1202h1e76h1d1ah1d2ahzz177df4h17326ah8275dh8275bhz32i2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h1155h) Received: from mail49-db3 (localhost.localdomain [127.0.0.1]) by mail49-db3 (MessageSwitch) id 1358309272648076_24510; Wed, 16 Jan 2013 04:07:52 +0000 (UTC) Received: from DB3EHSMHS017.bigfish.com (unknown [10.3.81.238]) by mail49-db3.bigfish.com (Postfix) with ESMTP id 9ABBF340235; Wed, 16 Jan 2013 04:07:52 +0000 (UTC) Received: from AMXPRD0610HT003.eurprd06.prod.outlook.com (157.56.248.213) by DB3EHSMHS017.bigfish.com (10.3.87.117) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 16 Jan 2013 04:07:52 +0000 Received: from AMXPRD0610MB378.eurprd06.prod.outlook.com ([169.254.3.8]) by AMXPRD0610HT003.eurprd06.prod.outlook.com ([10.255.58.38]) with mapi id 14.16.0257.004; Wed, 16 Jan 2013 04:07:51 +0000 From: Sharon Barkai To: "sitaraman@nmsworks.co.in" Thread-Topic: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG) Thread-Index: AQHN8vof/9C+QPIk3EqK8Qpnj9IMXJhLWCau Date: Wed, 16 Jan 2013 04:07:51 +0000 Message-ID: <90F9CFD5-508E-448E-8080-ADD7D952212E@Contextream.com> References: , <50265.117.193.212.120.1358182063.squirrel@www.nmsworks.co.in> <92F03B02-83C1-4BA2-8212-FD50D22FC6FD@Contextream.com>, <63510.192.168.9.56.1358227480.squirrel@www.nmsworks.co.in> , <39063.14.140.238.4.1358230663.squirrel@www.nmsworks.co.in> <07EEE1C0-6D3F-4885-9F77-F317ACA076B1@Contextream.com>, <53502.192.168.9.56.1358238307.squirrel@www.nmsworks.co.in> In-Reply-To: <53502.192.168.9.56.1358238307.squirrel@www.nmsworks.co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.147.114.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Contextream.com Cc: "Eggert, Lars" , "openflow-discuss@mailman.stanford.edu" , "sdn@irtf.org" Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New: Software-Defined Networking Research Group (SDNRG) X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 04:08:05 -0000 Yes, but not exactly. In the first example we want to achieve basic packet delivery service that = works under the worst possible conditions. After all the Internet was first designed to withstand a nuclear strike. =20 In the second example we ask for much more. Essentially we ask the network = to perform global balancing or global map-reduce on behalf of applications.= Instead of each app doing its own. This level of network programmability is possible IFF there is a basic unde= rlying connectivity because its based on distributed SDN control software. This is a bootstrap sequence. Hence the complementary aspect of traditional and software defined networki= ng and the overlay models SDN models converge towards. Based on this basic reachability you can also apply sophisticate traffic en= gineering for certain flows on graphs, facilitate mobility and workflows et= c. Additional driver is security and the ability to account for each and every= packet. This is virtually impossible under the autonomous control models, = but again without that foundation you can not build these next levels of fu= nctionality. Hope this makes sense - it's supposed to simplify network management as wel= l - because sophisticated configuration need not be scattered into interfac= e configuration - end points are moving between those. Instead, all SDN pro= gramable policies should be available in a similar to database programming = mode vs manager-agents mode, for the complex and massive things at least. = =20 Sent from my iPhone 650 492 0794 On Jan 15, 2013, at 9:27 AM, "sitaraman@nmsworks.co.in" wrote: Thanks Sharon, Looking at the examples, I seem to think the second one has a strong reach component to it, only the reach is not for the traffic that is carried but metadata about the traffic? Sitaraman > Happy to but don't want to bear on the list - > Can you take two simple examples and can extrapolate: >=20 > One: get a ping across to multiple locations, with different gear from > different generations of hardware and different administrative domains > that have no reason to trust one another as an example ISPs from > conflicting nations or competing vendors. >=20 > Two: globally balance a function instantiated using the same address in > multiple locations with global awareness in each location of the exact > health state load and affinity associated with each of the resources. >=20 >=20 >=20 > On Jan 15, 2013, at 7:19, "sitaraman@nmsworks.co.in" > wrote: >=20 > Hi Sharon, > Would appreciate if you could elaborate on the extended network > functionality and the conflict between the reach and > functionality...Thanks > Sitaraman >> depends on what you try to achieve- >>=20 >> if you try to extend network reach then back-comp interoperable control >> is >> key, therefore a "need to know basis" distribution (topo) makes that >> feasible. >>=20 >> If you try to extended network functionality, your control distribution >> emphasis changes significantly, and you still have to consider the touch >> point of the control application with the wire - tcams, scope, aging, >> etc >>=20 >> Since non of these reach & function needs are going away it looks like >> SDN >> overlays on IP can be used to sandbox the conflicting requirements. I >> haven't seen a hammer other then layers that can handle such different >> nails. >>=20 >>=20 >>=20 >> On Jan 15, 2013, at 6:26 AM, "sitaraman@nmsworks.co.in" >> wrote: >>=20 >> Hi Sharon, >> Thanks for these valuable insights. >> In the preSDN networking world, due to practicality of evolution and >> backward compatibility needs there arose multiple ways of doing the same >> thing..i.e gather and use graph reachability information. >> SDN is our chance to begin with a clean slate, while we need not throw >> the interoperation with existing networks totally out the window, we >> must also be careful not to avoid falling into the trap of restricting >> the capabilities and flexibility due to its need, even at first as >> options in isolation, for SDN. >> What we could consider in IRTF is standardizing a single way to gather >> reachability information (in a capacitated graph, typically). Indeed as >> you point out very aptly, such reachability information can be of >> varying geographical spans and varying aggregation level spans and these >> can have causal connections. If I understand you correctly, an >> Aggregration pivot has implications on the geographic spans that need to >> considered, and such aggregation pivots serve to segment/split the >> geographic expanse (conceptually in the graph model of the network that >> is) that the control has to deal with. >> It appears then if only we have a control of a control that based on the >> specified aggregation pivots redistribute the division between >> distributed control and distribution of control that when combined with >> operations on Graph model with scalable algorithmic schemes as mentioned >> in GPS, then we will have a powerful means to exercise traffic control, >> shaping and delivery which are the fundamental aspects of any network. >> A source of complexity we may need to handle is to be able to allow for >> multiple instances of such distributed control and distribution of >> control working together. >> Such segmentation between distributed control and distribution of >> control also could yield to a scalable solution. >> Sitaraman >>=20 >>=20 >>>=20 >>> These bring up interesting global-local distinctions. >>>=20 >>> The scope of a flow definition is clearly local to the aggregation >>> point: >>> IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a connection >>> ..depends. >>>=20 >>> The context of handling a flow in a specific point clearly has global >>> user-app considerations. >>> Distributing control logic is therefore according to global context >>> mapping not aggregation topology. This is different then control >>> distribution considerations for packet forwarding. >>>=20 >>> The touch point between control and forwarding is therefore a practical >>> choice. >>> The control has to be both locally (scope & mechanics) and globally >>> (user-app) aware. >>>=20 >>> Overlays work quite well in that sense, global awareness by distributed >>> clustering, >>> local touch point splits, or merges encapsulates flows based on global >>> pipeline need. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Jan 14, 2013, at 17:49, "sitaraman@nmsworks.co.in" >>> wrote: >>>=20 >>> Hi, >>> Some thoughts. >>> 1. Does the separation of control plane from the forwarding necessarily >>> mean the control now is to be centralized? It likely is not. Though the >>> network device itself need not implment the control plane and can be >>> interacted via an OpenFlow interface, the control funcationality can be >>> a separate distributed system. >>> 2. Model to represent Network >>> Network and traffic flows are fundamentally flows in capacitated >>> graphs. Could we look at using Stanford Graph Processing System >>> (GPS) for SDN based networks. The periodic communication amongst >>> nodes seem to naturally map to a traffic and information flow in a >>> network? >>>=20 >>> 3. Model to repsresent capacities of network resources and logical >>> abstractions of physical resources. >>> SDN dosent and probably should not change anything fundamental in the >>> traffic flow itself. This means that here SDN must look into reusing >>> existing models. TMF models is a likely candidate. >>> 4. Model to represent faults. >>> Same as above. New type of faults related to the decoupled (possibly >>> yet distributed) control plane to be harmonized with model for >>> existing faults. Again TMF is a source. >>> 5. Model to respresent Business aspects (Products, Orders such as time >>> to delivery commitments) >>> Same as above and again TMF is a source for this model. The new SDN >>> network could leverage by being able to be invoked or referred to in >>> the existing TMF business model aspects. After all these are directly >>> related to revenue and Customer Experience Management. >>> 6. Is it distributed control, distribution of control or soemwhere in >>> between that is preferable. Distributed control can be a conceptual >>> centralized control which is implemented in a distribued manner. Can >>> this nature be adaptively changed. Any aspects of learning in control >>> plane in SDN networks. >>> 7. Layers of control Ethernet Layer, MPLS layer, IP layer. >>> 8. Service Providers' bottom line is business and this means the TMF >>> FAB >>> Fulfilment, Assurance and Billing. SDN models must leverage the >>> existing >>> model as transparently as is practically feasibile. >>> Sitaraman >>>=20 >>> Possibly of interest. >>>>=20 >>>> Begin forwarded message: >>>>=20 >>>>> From: "Eggert, Lars" >>>>> Subject: [irtf-discuss] New: Software-Defined Networking Research >>>>> Group >>>>> (SDNRG) >>>>> Date: January 14, 2013 10:24:57 GMT+01:00 >>>>> To: "" , >>>>> "" >>>>> Cc: "sdn@irtf.org" >>>>> Reply-To: "irtf-discuss@irtf.org" >>>>>=20 >>>>> A new IRTF research group on Software-Defined Networking has been >>>>> chartered: >>>>>=20 >>>>> The Software-Defined Networking Research Group (SDNRG) investigates >>>>> SDN >>>>> from various perspectives with the goal of identifying the approaches >>>>> that >>>>> can be defined, deployed and used in the near term as well >>>>> identifying >>>>> future research challenges. In particular, key areas of interest >>>>> include >>>>> solution scalability, abstractions, and programming languages and >>>>> paradigms >>>>> particularly useful in the context of SDN. In addition, it is an >>>>> explicit >>>>> goal of the SDNRG to provide a forum for researchers to investigate >>>>> key >>>>> and interesting problems in the Software-Defined Networking field. >>>>>=20 >>>>> Charter and participation information can be found at >>>>> http://irtf.org/sdnrg >>>>>=20 >>>>> Lars Eggert >>>>> IRTF Chair >>>>=20 >>>> _______________________________________________ >>>> openflow-discuss mailing list >>>> openflow-discuss@lists.stanford.edu >>>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>>>=20 >>>> -- >>>> This message has been scanned for viruses and >>>> dangerous content by MailScanner, and is >>>> believed to be clean. >>>=20 >>>=20 >>>=20 >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >>>=20 >>> _______________________________________________ >>> sdn mailing list >>> sdn@irtf.org >>> https://www.irtf.org/mailman/listinfo/sdn >>>=20 >>>=20 >>> _______________________________________________ >>> sdn mailing list >>> sdn@irtf.org >>> https://www.irtf.org/mailman/listinfo/sdn >>>=20 >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >>=20 >>=20 >>=20 >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >>=20 >>=20 >>=20 >>=20 >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >=20 >=20 >=20 > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. >=20 >=20 >=20 >=20 > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From sitaraman@nmsworks.co.in Tue Jan 15 20:43:45 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5B911E8103 for ; Tue, 15 Jan 2013 20:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVh97Z2U4xD0 for ; Tue, 15 Jan 2013 20:43:43 -0800 (PST) Received: from indlocal.nmsworks.co.in (indus.nmsworks.co.in [14.140.238.3]) by ietfa.amsl.com (Postfix) with ESMTP id E96C011E8102 for ; Tue, 15 Jan 2013 20:43:42 -0800 (PST) Received: from www.nmsworks.co.in (localhost [127.0.0.1]) by indlocal.nmsworks.co.in (8.13.8/8.13.8) with ESMTP id r0G4fdS3008941; Wed, 16 Jan 2013 10:11:43 +0530 Received: from 115.184.122.32 (SquirrelMail authenticated user sitaraman) by www.nmsworks.co.in with HTTP; Wed, 16 Jan 2013 10:11:45 +0530 (IST) Message-ID: <50052.115.184.122.32.1358311305.squirrel@www.nmsworks.co.in> In-Reply-To: <90F9CFD5-508E-448E-8080-ADD7D952212E@Contextream.com> References: , <50265.117.193.212.120.1358182063.squirrel@www.nmsworks.co.in> <92F03B02-83C1-4BA2-8212-FD50D22FC6FD@Contextream.com>, <63510.192.168.9.56.1358227480.squirrel@www.nmsworks.co.in> , <39063.14.140.238.4.1358230663.squirrel@www.nmsworks.co.in> <07EEE1C0-6D3F-4885-9F77-F317ACA076B1@Contextream.com>, <53502.192.168.9.56.1358238307.squirrel@www.nmsworks.co.in> <90F9CFD5-508E-448E-8080-ADD7D952212E@Contextream.com> Date: Wed, 16 Jan 2013 10:11:45 +0530 (IST) From: sitaraman@nmsworks.co.in To: "Sharon Barkai" User-Agent: SquirrelMail/1.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-NMSWorks-MailScanner-Information: Please contact the ISP for more information X-NMSWorks-MailScanner-ID: r0G4fdS3008941 X-NMSWorks-MailScanner: Found to be clean X-NMSWorks-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.9, required 4, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-NMSWorks-MailScanner-From: sitaraman@nmsworks.co.in Cc: "Eggert, Lars" , "sdn@irtf.org" , "openflow-discuss@mailman.stanford.edu" , "sitaraman@nmsworks.co.in" Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New:Software-Defined Networking Research Group (SDNRG) X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 04:43:45 -0000 Thanks Sharon for the engaging discussion...you throw insightful perspectives... I will get back to the below shortly, but i have an overall feeling as follows. SDN must create a paradigm shift in Networking that it is designed to do. SDN network will have truly lived up to its promise and potential if one day the networks dont look at all like todays. SDN folks should have this freedom so that the concept can be exploited to the fullest. Granted, this may take a while, quite a while even. But this potential must be kept in mind until realization and kind of avoid throwing the baby with the bathwater. I do agree that the delay/evolutionary as opposed to revolutionary pace could be necessary for criterias other than technical such as economic interests of a complex meshed network of businesses that have heavy sunken production, research and strategic investments and interrelationships. Ironically it could be these very businesses that have the muscle to see this technology to fruition. Slow gradual transition is necessary but perhaps necessary evil :-) The key is to have an architecture that allows for a smooth transition from overlays with traditional network but i would like to stress that it could be very important to factor in the need to not limit the complete decoupling when the time is right. This is why i was discussing the possibility of defining the SDN control (network, application and all) hierarchically on top of existing controls therefore allowing for a neat removal of the traditional control when time arises and slide in the SDN control purely without having to go back to the drawing board or worse having to lock in with it for any longer than necessary... Sitaraman > Yes, but not exactly. > > In the first example we want to achieve basic packet delivery service that > works under the worst possible conditions. > After all the Internet was first designed to withstand a nuclear strike. > > In the second example we ask for much more. Essentially we ask the network > to perform global balancing or global map-reduce on behalf of > applications. Instead of each app doing its own. > > This level of network programmability is possible IFF there is a basic > underlying connectivity because its based on distributed SDN control > software. > This is a bootstrap sequence. > > Hence the complementary aspect of traditional and software defined > networking and the overlay models SDN models converge towards. > > Based on this basic reachability you can also apply sophisticate traffic > engineering for certain flows on graphs, facilitate mobility and workflows > etc. > Additional driver is security and the ability to account for each and > every packet. This is virtually impossible under the autonomous control > models, but again without that foundation you can not build these next > levels of functionality. > > Hope this makes sense - it's supposed to simplify network management as > well - because sophisticated configuration need not be scattered into > interface configuration - end points are moving between those. Instead, > all SDN programable policies should be available in a similar to database > programming mode vs manager-agents mode, for the complex and massive > things at least. > > Sent from my iPhone 650 492 0794 > > On Jan 15, 2013, at 9:27 AM, "sitaraman@nmsworks.co.in" > wrote: > > Thanks Sharon, Looking at the examples, I seem to think the second one > has a strong reach component to it, only the reach is not for the traffic > that is carried but metadata about the traffic? > Sitaraman >> Happy to but don't want to bear on the list - >> Can you take two simple examples and can extrapolate: >> >> One: get a ping across to multiple locations, with different gear from >> different generations of hardware and different administrative domains >> that have no reason to trust one another as an example ISPs from >> conflicting nations or competing vendors. >> >> Two: globally balance a function instantiated using the same address in >> multiple locations with global awareness in each location of the exact >> health state load and affinity associated with each of the resources. >> >> >> >> On Jan 15, 2013, at 7:19, "sitaraman@nmsworks.co.in" >> wrote: >> >> Hi Sharon, >> Would appreciate if you could elaborate on the extended network >> functionality and the conflict between the reach and >> functionality...Thanks >> Sitaraman >>> depends on what you try to achieve- >>> >>> if you try to extend network reach then back-comp interoperable control >>> is >>> key, therefore a "need to know basis" distribution (topo) makes that >>> feasible. >>> >>> If you try to extended network functionality, your control distribution >>> emphasis changes significantly, and you still have to consider the >>> touch >>> point of the control application with the wire - tcams, scope, aging, >>> etc >>> >>> Since non of these reach & function needs are going away it looks like >>> SDN >>> overlays on IP can be used to sandbox the conflicting requirements. I >>> haven't seen a hammer other then layers that can handle such different >>> nails. >>> >>> >>> >>> On Jan 15, 2013, at 6:26 AM, "sitaraman@nmsworks.co.in" >>> wrote: >>> >>> Hi Sharon, >>> Thanks for these valuable insights. >>> In the preSDN networking world, due to practicality of evolution and >>> backward compatibility needs there arose multiple ways of doing the >>> same >>> thing..i.e gather and use graph reachability information. >>> SDN is our chance to begin with a clean slate, while we need not throw >>> the interoperation with existing networks totally out the window, we >>> must also be careful not to avoid falling into the trap of restricting >>> the capabilities and flexibility due to its need, even at first as >>> options in isolation, for SDN. >>> What we could consider in IRTF is standardizing a single way to gather >>> reachability information (in a capacitated graph, typically). Indeed as >>> you point out very aptly, such reachability information can be of >>> varying geographical spans and varying aggregation level spans and >>> these >>> can have causal connections. If I understand you correctly, an >>> Aggregration pivot has implications on the geographic spans that need >>> to >>> considered, and such aggregation pivots serve to segment/split the >>> geographic expanse (conceptually in the graph model of the network that >>> is) that the control has to deal with. >>> It appears then if only we have a control of a control that based on >>> the >>> specified aggregation pivots redistribute the division between >>> distributed control and distribution of control that when combined with >>> operations on Graph model with scalable algorithmic schemes as >>> mentioned >>> in GPS, then we will have a powerful means to exercise traffic control, >>> shaping and delivery which are the fundamental aspects of any network. >>> A source of complexity we may need to handle is to be able to allow for >>> multiple instances of such distributed control and distribution of >>> control working together. >>> Such segmentation between distributed control and distribution of >>> control also could yield to a scalable solution. >>> Sitaraman >>> >>> >>>> >>>> These bring up interesting global-local distinctions. >>>> >>>> The scope of a flow definition is clearly local to the aggregation >>>> point: >>>> IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a connection >>>> ..depends. >>>> >>>> The context of handling a flow in a specific point clearly has global >>>> user-app considerations. >>>> Distributing control logic is therefore according to global context >>>> mapping not aggregation topology. This is different then control >>>> distribution considerations for packet forwarding. >>>> >>>> The touch point between control and forwarding is therefore a >>>> practical >>>> choice. >>>> The control has to be both locally (scope & mechanics) and globally >>>> (user-app) aware. >>>> >>>> Overlays work quite well in that sense, global awareness by >>>> distributed >>>> clustering, >>>> local touch point splits, or merges encapsulates flows based on global >>>> pipeline need. >>>> >>>> >>>> >>>> >>>> >>>> On Jan 14, 2013, at 17:49, "sitaraman@nmsworks.co.in" >>>> wrote: >>>> >>>> Hi, >>>> Some thoughts. >>>> 1. Does the separation of control plane from the forwarding >>>> necessarily >>>> mean the control now is to be centralized? It likely is not. Though >>>> the >>>> network device itself need not implment the control plane and can be >>>> interacted via an OpenFlow interface, the control funcationality can >>>> be >>>> a separate distributed system. >>>> 2. Model to represent Network >>>> Network and traffic flows are fundamentally flows in capacitated >>>> graphs. Could we look at using Stanford Graph Processing System >>>> (GPS) for SDN based networks. The periodic communication amongst >>>> nodes seem to naturally map to a traffic and information flow in a >>>> network? >>>> >>>> 3. Model to repsresent capacities of network resources and logical >>>> abstractions of physical resources. >>>> SDN dosent and probably should not change anything fundamental in the >>>> traffic flow itself. This means that here SDN must look into reusing >>>> existing models. TMF models is a likely candidate. >>>> 4. Model to represent faults. >>>> Same as above. New type of faults related to the decoupled (possibly >>>> yet distributed) control plane to be harmonized with model for >>>> existing faults. Again TMF is a source. >>>> 5. Model to respresent Business aspects (Products, Orders such as time >>>> to delivery commitments) >>>> Same as above and again TMF is a source for this model. The new SDN >>>> network could leverage by being able to be invoked or referred to in >>>> the existing TMF business model aspects. After all these are directly >>>> related to revenue and Customer Experience Management. >>>> 6. Is it distributed control, distribution of control or soemwhere in >>>> between that is preferable. Distributed control can be a conceptual >>>> centralized control which is implemented in a distribued manner. Can >>>> this nature be adaptively changed. Any aspects of learning in control >>>> plane in SDN networks. >>>> 7. Layers of control Ethernet Layer, MPLS layer, IP layer. >>>> 8. Service Providers' bottom line is business and this means the TMF >>>> FAB >>>> Fulfilment, Assurance and Billing. SDN models must leverage the >>>> existing >>>> model as transparently as is practically feasibile. >>>> Sitaraman >>>> >>>> Possibly of interest. >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: "Eggert, Lars" >>>>>> Subject: [irtf-discuss] New: Software-Defined Networking Research >>>>>> Group >>>>>> (SDNRG) >>>>>> Date: January 14, 2013 10:24:57 GMT+01:00 >>>>>> To: "" , >>>>>> "" >>>>>> Cc: "sdn@irtf.org" >>>>>> Reply-To: "irtf-discuss@irtf.org" >>>>>> >>>>>> A new IRTF research group on Software-Defined Networking has been >>>>>> chartered: >>>>>> >>>>>> The Software-Defined Networking Research Group (SDNRG) investigates >>>>>> SDN >>>>>> from various perspectives with the goal of identifying the >>>>>> approaches >>>>>> that >>>>>> can be defined, deployed and used in the near term as well >>>>>> identifying >>>>>> future research challenges. In particular, key areas of interest >>>>>> include >>>>>> solution scalability, abstractions, and programming languages and >>>>>> paradigms >>>>>> particularly useful in the context of SDN. In addition, it is an >>>>>> explicit >>>>>> goal of the SDNRG to provide a forum for researchers to investigate >>>>>> key >>>>>> and interesting problems in the Software-Defined Networking field. >>>>>> >>>>>> Charter and participation information can be found at >>>>>> http://irtf.org/sdnrg >>>>>> >>>>>> Lars Eggert >>>>>> IRTF Chair >>>>> >>>>> _______________________________________________ >>>>> openflow-discuss mailing list >>>>> openflow-discuss@lists.stanford.edu >>>>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>>>> >>>>> -- >>>>> This message has been scanned for viruses and >>>>> dangerous content by MailScanner, and is >>>>> believed to be clean. >>>> >>>> >>>> >>>> -- >>>> This message has been scanned for viruses and >>>> dangerous content by MailScanner, and is >>>> believed to be clean. >>>> >>>> _______________________________________________ >>>> sdn mailing list >>>> sdn@irtf.org >>>> https://www.irtf.org/mailman/listinfo/sdn >>>> >>>> >>>> _______________________________________________ >>>> sdn mailing list >>>> sdn@irtf.org >>>> https://www.irtf.org/mailman/listinfo/sdn >>>> >>>> -- >>>> This message has been scanned for viruses and >>>> dangerous content by MailScanner, and is >>>> believed to be clean. >>> >>> >>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >>> >>> >>> >>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >> >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> >> >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From yulei.frank.wu@gmail.com Tue Jan 15 21:59:09 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39C621F86D4 for ; Tue, 15 Jan 2013 21:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgT4XWqJb4Zl for ; Tue, 15 Jan 2013 21:59:08 -0800 (PST) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id D951C21F86CE for ; Tue, 15 Jan 2013 21:59:08 -0800 (PST) Received: by mail-pb0-f48.google.com with SMTP id rq13so529013pbb.7 for ; Tue, 15 Jan 2013 21:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:reply-to:subject:x-priority:x-guid :x-has-attach:x-mailer:mime-version:message-id:content-type; bh=mTuGUOcngFMOOGQWP9FvNYIAnxd/8CHNHwd5Nj4YBlg=; b=RzTcVl2noQ2EVRFOJbWZN/ym2ivlf3mnsQJQb80DDowkTqjoPxaS4JqkH4hhw6L5xg OwRpoY7SvJfVXItIj4+hNapVYRd9kx5I0ZDsF6Y/Qw9Y3ZIaX0ny94Ct/TbfIQXrnRkp 3vAVCKHYTTJNtU6XbMplPAbjZjURPWgfuR1v1MGxvXnvluvHf97mPY39aSQPq22dsFHP 1HByOADl+ijW+O52wU8qIMfn6qLSeEiZwKG5gBW+Mv2i5PfefBAqjlhrdUdSLUJLHYe0 HsBuLTv6F99wvxjhbUwdJcRKKwRO3hF7KVlBWq0aSW1McKZAOsb0WtJ6GkPjGuK7fe6U KQ7A== X-Received: by 10.68.237.42 with SMTP id uz10mr37366144pbc.118.1358315948617; Tue, 15 Jan 2013 21:59:08 -0800 (PST) Received: from ylwu-THINK ([159.226.58.202]) by mx.google.com with ESMTPS id gl5sm11636373pbc.51.2013.01.15.21.59.07 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 15 Jan 2013 21:59:07 -0800 (PST) Date: Wed, 16 Jan 2013 13:59:08 +0800 From: "Yulei Wu" To: sdn X-Priority: 3 X-GUID: C7E3BBF8-0BE6-47AA-80C7-DB3E87FE07C3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.87[cn] Mime-Version: 1.0 Message-ID: <2013011613590720627863@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart634510803768_=----" Subject: [Sdn] The impact factor of flow table size in openflow X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "yulei.frank.wu" List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 05:59:09 -0000 This is a multi-part message in MIME format. ------=_001_NextPart634510803768_=---- Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 RGVhciBDb2xsZWFndWVzLA0KDQpUaGUgZmxvdyB0YWJsZSBpbiBvcGVuZmxvdyBpcyBzaW1pbGFy IHRvIHJvdXRpbmcgdGFibGUsIG9yIGFjY2VzcyBjb250cm9sIGxpc3QuIEkganVzdCB3b25kZXJl ZCB0aGF0IHRoZSBpbXBhY3QgZmFjdG9yIG9mIGZsb3cgdGFibGUgc2l6ZSwgaS5lLiwgd2hpY2gg ZmFjdG9yIGFmZmVjdHMgdGhlIHNpemUgb2YgdGhlIGZsb3cgdGFibGU/IElzIHRoZXJlIGFueW9u ZSBoYXZpbmcgdGhlIGV4cGVyaWVuY2Ugb24gdGhpcyBpc3N1ZT8NCg0KSW4gbXkgb3Bpbmlvbiwg dGhlIG1hdGNoIGdyYW51bGFyaXR5LCBjb250cm9sIGdyYW51bGFyaXR5IG9mIHRoZSBzd2l0Y2gg d2lsbCBhZmZlY3QgdGhlIGZsb3cgdGFibGUgc2l6ZS4gQW55IG90aGVyIGZhY3RvcnM/DQoNClRo YW5rIHlvdSB2ZXJ5IG11Y2guDQoNCkJlc3QgUmVnYXJkcy4NCg0KWXVsZWk= ------=_001_NextPart634510803768_=---- Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear=20 Colleagues,
 
The flow table = in=20 openflow is similar to routing table, or access control list. I just wonde= red=20 that the impact factor of flow table size, i.e., which factor affects the = size=20 of the flow table? Is there anyone having the experience on this=20 issue?
 
In my opinion, = the=20 match granularity, control granularity of the switch will affect the flow = table=20 size. Any other factors?
 
Thank you very=20 much.
 
Best=20 Regards.
  Yulei
------=_001_NextPart634510803768_=------ From sitaraman@nmsworks.co.in Tue Jan 15 22:11:10 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDA221F876E for ; Tue, 15 Jan 2013 22:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIYCcbnUkw27 for ; Tue, 15 Jan 2013 22:11:09 -0800 (PST) Received: from indlocal.nmsworks.co.in (indus.nmsworks.co.in [14.140.238.3]) by ietfa.amsl.com (Postfix) with ESMTP id 3070921F8754 for ; Tue, 15 Jan 2013 22:11:06 -0800 (PST) Received: from www.nmsworks.co.in (localhost [127.0.0.1]) by indlocal.nmsworks.co.in (8.13.8/8.13.8) with ESMTP id r0G68X1n022053; Wed, 16 Jan 2013 11:38:35 +0530 Received: from 115.184.122.32 (SquirrelMail authenticated user sitaraman) by www.nmsworks.co.in with HTTP; Wed, 16 Jan 2013 11:38:36 +0530 (IST) Message-ID: <50821.115.184.122.32.1358316516.squirrel@www.nmsworks.co.in> Date: Wed, 16 Jan 2013 11:38:36 +0530 (IST) From: sitaraman@nmsworks.co.in To: "Sharon Barkai" User-Agent: SquirrelMail/1.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-NMSWorks-MailScanner-Information: Please contact the ISP for more information X-NMSWorks-MailScanner-ID: r0G68X1n022053 X-NMSWorks-MailScanner: Found to be clean X-NMSWorks-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.9, required 4, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-NMSWorks-MailScanner-From: sitaraman@nmsworks.co.in Cc: "Eggert, Lars" , "openflow-discuss@mailman.stanford.edu" , "sdn@irtf.org" Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New:Software-Defined Networking Research Group (SDNRG) X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 06:11:10 -0000 Hi Sharon, It is interesting that you earlier mentioned aggregation points and split points. As you mention below, the semantics of the term reachability could be looked at in a wider sense going beyond the network traffic reachability, which is likely what you mean by the terminology of basic reachability. In ITU-T and TMF model there is an important architectural component called the adaptation. A Termination Point could be associated, in addition to a termination component, to also an adapatation component. The global policies that you have given as illustrations to the problem can be fundamentally viwed as Adaptations. Adaptations and Terminations together therefore could serve as a unifying generalization of the aggregation abstraction. What strikes me is the relationship of adapations to the generalized reachability alluded to earlier. Once you have the physical network infrastructure in place (relatively long lived, slowly changing characterstic of the network ) your universe set of the relationship between the adapataions and the associated generalized reach could get significantltly narrowed. A case then for programmability of the same. Here we are now closer to making the problem of relating the architecture of the system to it programmability more tractable. Could we explore any existing programming language that can handle graphs and operations on it well..ie a language for graphs? Also the levels of control (Network Device level, Protocol level, Control Plane level, User App level) needs to be factored in. The concept underlying IEEEs OAM Standardization based on MEPs/MIPs come to mind.. Is there value in adapting those in a unified framework? SDN is to networks it appears as Reconfigurable Computing is to the Computing industry.... Sitaraman > Yes, but not exactly. > > In the first example we want to achieve basic packet delivery service that > works under the worst possible conditions. > After all the Internet was first designed to withstand a nuclear strike. > > In the second example we ask for much more. Essentially we ask the network > to perform global balancing or global map-reduce on behalf of > applications. Instead of each app doing its own. > > This level of network programmability is possible IFF there is a basic > underlying connectivity because its based on distributed SDN control > software. > This is a bootstrap sequence. > > Hence the complementary aspect of traditional and software defined > networking and the overlay models SDN models converge towards. > > Based on this basic reachability you can also apply sophisticate traffic > engineering for certain flows on graphs, facilitate mobility and workflows > etc. > Additional driver is security and the ability to account for each and > every packet. This is virtually impossible under the autonomous control > models, but again without that foundation you can not build these next > levels of functionality. > > Hope this makes sense - it's supposed to simplify network management as > well - because sophisticated configuration need not be scattered into > interface configuration - end points are moving between those. Instead, > all SDN programable policies should be available in a similar to database > programming mode vs manager-agents mode, for the complex and massive > things at least. > > Sent from my iPhone 650 492 0794 > > On Jan 15, 2013, at 9:27 AM, "sitaraman@nmsworks.co.in" > wrote: > > Thanks Sharon, Looking at the examples, I seem to think the second one > has a strong reach component to it, only the reach is not for the traffic > that is carried but metadata about the traffic? > Sitaraman >> Happy to but don't want to bear on the list - >> Can you take two simple examples and can extrapolate: >> >> One: get a ping across to multiple locations, with different gear from >> different generations of hardware and different administrative domains >> that have no reason to trust one another as an example ISPs from >> conflicting nations or competing vendors. >> >> Two: globally balance a function instantiated using the same address in >> multiple locations with global awareness in each location of the exact >> health state load and affinity associated with each of the resources. >> >> >> >> On Jan 15, 2013, at 7:19, "sitaraman@nmsworks.co.in" >> wrote: >> >> Hi Sharon, >> Would appreciate if you could elaborate on the extended network >> functionality and the conflict between the reach and >> functionality...Thanks >> Sitaraman >>> depends on what you try to achieve- >>> >>> if you try to extend network reach then back-comp interoperable control >>> is >>> key, therefore a "need to know basis" distribution (topo) makes that >>> feasible. >>> >>> If you try to extended network functionality, your control distribution >>> emphasis changes significantly, and you still have to consider the >>> touch >>> point of the control application with the wire - tcams, scope, aging, >>> etc >>> >>> Since non of these reach & function needs are going away it looks like >>> SDN >>> overlays on IP can be used to sandbox the conflicting requirements. I >>> haven't seen a hammer other then layers that can handle such different >>> nails. >>> >>> >>> >>> On Jan 15, 2013, at 6:26 AM, "sitaraman@nmsworks.co.in" >>> wrote: >>> >>> Hi Sharon, >>> Thanks for these valuable insights. >>> In the preSDN networking world, due to practicality of evolution and >>> backward compatibility needs there arose multiple ways of doing the >>> same >>> thing..i.e gather and use graph reachability information. >>> SDN is our chance to begin with a clean slate, while we need not throw >>> the interoperation with existing networks totally out the window, we >>> must also be careful not to avoid falling into the trap of restricting >>> the capabilities and flexibility due to its need, even at first as >>> options in isolation, for SDN. >>> What we could consider in IRTF is standardizing a single way to gather >>> reachability information (in a capacitated graph, typically). Indeed as >>> you point out very aptly, such reachability information can be of >>> varying geographical spans and varying aggregation level spans and >>> these >>> can have causal connections. If I understand you correctly, an >>> Aggregration pivot has implications on the geographic spans that need >>> to >>> considered, and such aggregation pivots serve to segment/split the >>> geographic expanse (conceptually in the graph model of the network that >>> is) that the control has to deal with. >>> It appears then if only we have a control of a control that based on >>> the >>> specified aggregation pivots redistribute the division between >>> distributed control and distribution of control that when combined with >>> operations on Graph model with scalable algorithmic schemes as >>> mentioned >>> in GPS, then we will have a powerful means to exercise traffic control, >>> shaping and delivery which are the fundamental aspects of any network. >>> A source of complexity we may need to handle is to be able to allow for >>> multiple instances of such distributed control and distribution of >>> control working together. >>> Such segmentation between distributed control and distribution of >>> control also could yield to a scalable solution. >>> Sitaraman >>> >>> >>>> >>>> These bring up interesting global-local distinctions. >>>> >>>> The scope of a flow definition is clearly local to the aggregation >>>> point: >>>> IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a connection >>>> ..depends. >>>> >>>> The context of handling a flow in a specific point clearly has global >>>> user-app considerations. >>>> Distributing control logic is therefore according to global context >>>> mapping not aggregation topology. This is different then control >>>> distribution considerations for packet forwarding. >>>> >>>> The touch point between control and forwarding is therefore a >>>> practical >>>> choice. >>>> The control has to be both locally (scope & mechanics) and globally >>>> (user-app) aware. >>>> >>>> Overlays work quite well in that sense, global awareness by >>>> distributed >>>> clustering, >>>> local touch point splits, or merges encapsulates flows based on global >>>> pipeline need. >>>> >>>> >>>> >>>> >>>> >>>> On Jan 14, 2013, at 17:49, "sitaraman@nmsworks.co.in" >>>> wrote: >>>> >>>> Hi, >>>> Some thoughts. >>>> 1. Does the separation of control plane from the forwarding >>>> necessarily >>>> mean the control now is to be centralized? It likely is not. Though >>>> the >>>> network device itself need not implment the control plane and can be >>>> interacted via an OpenFlow interface, the control funcationality can >>>> be >>>> a separate distributed system. >>>> 2. Model to represent Network >>>> Network and traffic flows are fundamentally flows in capacitated >>>> graphs. Could we look at using Stanford Graph Processing System >>>> (GPS) for SDN based networks. The periodic communication amongst >>>> nodes seem to naturally map to a traffic and information flow in a >>>> network? >>>> >>>> 3. Model to repsresent capacities of network resources and logical >>>> abstractions of physical resources. >>>> SDN dosent and probably should not change anything fundamental in the >>>> traffic flow itself. This means that here SDN must look into reusing >>>> existing models. TMF models is a likely candidate. >>>> 4. Model to represent faults. >>>> Same as above. New type of faults related to the decoupled (possibly >>>> yet distributed) control plane to be harmonized with model for >>>> existing faults. Again TMF is a source. >>>> 5. Model to respresent Business aspects (Products, Orders such as time >>>> to delivery commitments) >>>> Same as above and again TMF is a source for this model. The new SDN >>>> network could leverage by being able to be invoked or referred to in >>>> the existing TMF business model aspects. After all these are directly >>>> related to revenue and Customer Experience Management. >>>> 6. Is it distributed control, distribution of control or soemwhere in >>>> between that is preferable. Distributed control can be a conceptual >>>> centralized control which is implemented in a distribued manner. Can >>>> this nature be adaptively changed. Any aspects of learning in control >>>> plane in SDN networks. >>>> 7. Layers of control Ethernet Layer, MPLS layer, IP layer. >>>> 8. Service Providers' bottom line is business and this means the TMF >>>> FAB >>>> Fulfilment, Assurance and Billing. SDN models must leverage the >>>> existing >>>> model as transparently as is practically feasibile. >>>> Sitaraman >>>> >>>> Possibly of interest. >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: "Eggert, Lars" >>>>>> Subject: [irtf-discuss] New: Software-Defined Networking Research >>>>>> Group >>>>>> (SDNRG) >>>>>> Date: January 14, 2013 10:24:57 GMT+01:00 >>>>>> To: "" , >>>>>> "" >>>>>> Cc: "sdn@irtf.org" >>>>>> Reply-To: "irtf-discuss@irtf.org" >>>>>> >>>>>> A new IRTF research group on Software-Defined Networking has been >>>>>> chartered: >>>>>> >>>>>> The Software-Defined Networking Research Group (SDNRG) investigates >>>>>> SDN >>>>>> from various perspectives with the goal of identifying the >>>>>> approaches >>>>>> that >>>>>> can be defined, deployed and used in the near term as well >>>>>> identifying >>>>>> future research challenges. In particular, key areas of interest >>>>>> include >>>>>> solution scalability, abstractions, and programming languages and >>>>>> paradigms >>>>>> particularly useful in the context of SDN. In addition, it is an >>>>>> explicit >>>>>> goal of the SDNRG to provide a forum for researchers to investigate >>>>>> key >>>>>> and interesting problems in the Software-Defined Networking field. >>>>>> >>>>>> Charter and participation information can be found at >>>>>> http://irtf.org/sdnrg >>>>>> >>>>>> Lars Eggert >>>>>> IRTF Chair >>>>> >>>>> _______________________________________________ >>>>> openflow-discuss mailing list >>>>> openflow-discuss@lists.stanford.edu >>>>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>>>> >>>>> -- >>>>> This message has been scanned for viruses and >>>>> dangerous content by MailScanner, and is >>>>> believed to be clean. >>>> >>>> >>>> >>>> -- >>>> This message has been scanned for viruses and >>>> dangerous content by MailScanner, and is >>>> believed to be clean. >>>> >>>> _______________________________________________ >>>> sdn mailing list >>>> sdn@irtf.org >>>> https://www.irtf.org/mailman/listinfo/sdn >>>> >>>> >>>> _______________________________________________ >>>> sdn mailing list >>>> sdn@irtf.org >>>> https://www.irtf.org/mailman/listinfo/sdn >>>> >>>> -- >>>> This message has been scanned for viruses and >>>> dangerous content by MailScanner, and is >>>> believed to be clean. >>> >>> >>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >>> >>> >>> >>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >> >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> >> >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From yulei.frank.wu@gmail.com Thu Jan 17 23:06:49 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF13A21F8A52 for ; Thu, 17 Jan 2013 23:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.796 X-Spam-Level: X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[AWL=-1.239, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpHu46LgmouE for ; Thu, 17 Jan 2013 23:06:48 -0800 (PST) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4332B21F8A6B for ; Thu, 17 Jan 2013 23:06:47 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id fb11so1951193pad.24 for ; Thu, 17 Jan 2013 23:06:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:reply-to:subject:x-priority:x-guid :x-has-attach:x-mailer:mime-version:message-id:content-type; bh=iURZi/64I2AQEO3TwLNvTaC4LjKw/IJyNGFgdtsSsuc=; b=BVtUh8cCpqPH+Xyvb2AT7fsXnhhXQAc2u+OQPZD37brFoeNSPEpkO+edDa2/V9B9uW J622k/4bq0Wu8fOZUeHIh630ZzTVQjYZTGgi/zx0zuK5r4WQkZa2adt/PABJ2ZevLKyd sKcrWtQ3fPkV0sTieJ4kpUKQphczcClM4sK18HMNwWdsyiSKN4eFYa3gCoe21CPl9plp zT+Q6i9i590NSnNhFTpvRe7bMfwADJpLPsu6t9Tl5gC4NoFyd8AudHp9GV/o5+LwTivl QuDMhaRHgjSIDwT/zQNagNzR0qQzHUFoc7PBfIsZfiEeDSJ2sfT5Lm2y+TqPvMnt5ve+ XLFg== X-Received: by 10.68.235.200 with SMTP id uo8mr2329788pbc.29.1358492803106; Thu, 17 Jan 2013 23:06:43 -0800 (PST) Received: from ylwu-THINK ([159.226.58.202]) by mx.google.com with ESMTPS id f5sm2878539pav.22.2013.01.17.23.06.42 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 17 Jan 2013 23:06:42 -0800 (PST) Date: Fri, 18 Jan 2013 15:05:14 +0800 From: "Yulei Wu" To: sdn X-Priority: 3 X-GUID: 62688DFC-0A8A-4CE0-AEE4-181ABD350995 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.87[cn] Mime-Version: 1.0 Message-ID: <2013011815051217407415@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart135381386565_=----" Subject: [Sdn] (Two weeks left) CFP: WNM-2013 (4th Intl Workshop on Wireless Networks and Multimedia), Melbourne, Australia, 16-18 July, 2013 X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "yulei.frank.wu" List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 07:06:49 -0000 This is a multi-part message in MIME format. ------=_001_NextPart135381386565_=---- Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 QXBwb2xvZ2llcyBpZiB5b3UgcmVjZWl2ZWQgbXVsdGlwbGUgY29waWVzIG9mIHRoaXMgV05NLTIw MTMgQ0ZQLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpDQUxMIEZPUiBQQVBFUlMNCg0KVGhlIDR0aCBJbnRlcm5hdGlvbmFs IFdvcmtzaG9wIG9uIFdpcmVsZXNzIE5ldHdvcmtzIGFuZCBNdWx0aW1lZGlhIChXTk0tMjAxMyks IE1lbGJvdXJuZSwgQXVzdHJhbGlhLCAxNi0xOCBKdWx5LCAyMDEzDQoNCmh0dHA6Ly93bm0yMDEz LmNzcC5lc2NpZW5jZS5jbi8NCg0KVG8gYmUgaGVsZCBpbiBjb25qdW5jdGlvbiB3aXRoIFRoZSAx MXRoIElFRUUgSVNQQS0yMDEzDQpUaGUgYWNjZXB0ZWQgcGFwZXJzIGZyb20gdGhpcyB3b3Jrc2hv cCB3aWxsIGJlIGluY2x1ZGVkIGludG8gdGhlIElFRUUgY29uZmVyZW5jZSBwcm9jZWVkaW5ncyBw dWJsaXNoZWQgYnkgSUVFRSBDb21wdXRlciBTb2NpZXR5LCBhbmQgd2lsbCBiZSBpbmRleGVkIGJ5 IEVJDQoNCg0KSU5UUk9EVUNUSU9ODQpUaGUgd2lyZWxlc3MgY29tbXVuaWNhdGlvbiB0ZWNobm9s b2dpZXMgaGF2ZSBldm9sdmVkIHF1aWNrbHkgb3ZlciB0aGUgcGFzdCB5ZWFycy4gQXMgdGhlIGV4 cGxvc2l2ZSBncm93dGggaW4gYnJvYWRiYW5kIHdpcmVsZXNzIG5ldHdvcmtzLCBtdWx0aW1lZGlh IGFwcGxpY2F0aW9ucyB3aWxsIGRvbWluYXRlIHRoZSBmdXR1cmUgd2lyZWxlc3MgY29tbXVuaWNh dGlvbiBzb2NpZXR5LCByZXN1bHRpbmcgaW4gbm9uLXRyaXZpYWwgcHJvYmxlbXMgaW4gdGVybXMg b2YgYXZhaWxhYmxlIGNhcGFjaXR5LCByZWxpYWJpbGl0eSwgcXVhbGl0eS1vZi1zZXJ2aWNlLCBk ZWxheSwgYW5kIHRocm91Z2hwdXQuDQoNClRvIHN1Y2Nlc3NmdWxseSBzdXBwb3J0IHdpcmVsZXNz IG11bHRpbWVkaWEgYXBwbGljYXRpb25zLCBpdCBpcyBuZWNlc3NhcnkgdG8gaW1wcm92ZSB0aGUg c3RhdGUtb2YtdGhlLWFydCB0ZWNobmlxdWVzIChzdWNoIGFzIHJhZGlvIHJlc291cmNlIG1hbmFn ZW1lbnQsIG1vYmlsaXR5LCBoYW5kb2ZmLCBhbmQgbG9jYXRpb24gbWFuYWdlbWVudCwgZXRjLikg aW4gdGhlIG11bHRpbWVkaWEgdHJhbnNtaXNzaW9uIG92ZXIgd2lyZWxlc3MgbmV0d29ya3MgaW4g b3JkZXIgdG8gcHJvdmlkZSBxdWFsaXR5LW9mLXNlcnZpY2UgZ3VhcmFudGVlcyBiZXR3ZWVuIHRo ZSBlbmQtdXNlcnMgYW5kIGFjaGlldmUgYSBoaWdoIHF1YWxpdHktb2YtZXhwZXJpZW5jZSBmb3Ig ZW5kLXVzZXJzLg0KDQpUaGlzIHdvcmtzaG9wIHdpbGwgYWRkcmVzcyB0aGUgaW1wb3J0YW50IHBy b2JsZW1zIGFuZCBjaGFsbGVuZ2VzIGNhdXNlZCBieSB0aGUgdHJhbnNtaXNzaW9uIG9mIG11bHRp bWVkaWEgYXBwbGljYXRpb25zIG92ZXIgd2lyZWxlc3MgbmV0d29ya3MuIFRoZSB3b3Jrc2hvcCBh aW1zIHRvIGJyaW5nIHRvZ2V0aGVyIGNvbXB1dGVyIHNjaWVudGlzdHMgYW5kIGVuZ2luZWVycyBp biBkaWZmZXJlbnQgZGlzY2lwbGluZXMgdG8gc2hhcmUgYW5kIGV4Y2hhbmdlIHRoZWlyIGV4cGVy aWVuY2UgYW5kIGlkZWFzIGFuZCBkaXNjdXNzIHN0YXRlLW9mLXRoZS1hcnQgYW5kIGluLXByb2dy ZXNzIHJlc2VhcmNoIG9uIGFsbCBhc3BlY3RzIG9mIHdpcmVsZXNzIG5ldHdvcmtzIGFuZCBtdWx0 aW1lZGlhIGFwcGxpY2F0aW9ucy4NCg0KVGhlIHRvcGljcyBvZiBwYXJ0aWN1bGFyIGludGVyZXN0 IGluY2x1ZGUsIGJ1dCBhcmUgbm90IGxpbWl0ZWQgdG86DQoxLiBVbHRyYS1XaWRlYmFuZCBOZXR3 b3Jrcw0KMi4gV2lyZWxlc3MgQWQgSG9jIGFuZCBNZXNoIE5ldHdvcmtzDQozLiBXaXJlbGVzcyBQ ZXJzb25hbCBBcmVhIE5ldHdvcmtzDQo0LiBXaXJlbGVzcyBMb2NhbCBBcmVhIE5ldHdvcmtzDQo1 LiBXaXJlbGVzcyBTZW5zb3IgTmV0d29ya3MNCjYuIFdpcmVsZXNzIE1ldHJvcG9saXRhbiBBcmVh IE5ldHdvcmtzDQo3LiBDZWxsdWxhciBOZXR3b3Jrcw0KOC4gV2lNQVgNCjkuIE9wdGljYWwgV2ly ZWxlc3MgQWNjZXNzIE5ldHdvcmtzDQoxMC4gTW9iaWxlIENvbXB1dGluZyBhbmQgV2lyZWxlc3Mg Q29tbXVuaWNhdGlvbnMNCjExLiBGdXR1cmUgV2lyZWxlc3MgTmV0d29ya3MgYW5kIFByb3RvY29s cw0KMTIuIE11bHRpbWVkaWEgQ29tbXVuaWNhdGlvbnMgYW5kIFNlcnZpY2VzDQoxMy4gQ29uZ2Vz dGlvbiBhbmQgQWRtaXNzaW9uIENvbnRyb2wNCjE0LiBXaXJlbGVzcyBNQUMgUHJvdG9jb2xzOiBE ZXNpZ24gYW5kIEFuYWx5c2lzDQoxNS4gUXVhbGl0eSBvZiBTZXJ2aWNlIFByb3Zpc2lvbmluZw0K MTYuIFdpcmVsZXNzIE5ldHdvcmsgVHJ1c3QsIFByaXZhY3kgYW5kIFNlY3VyaXR5DQoxNy4gU29m dHdhcmUgRGVmaW5lZCBSYWRpbyAmIFNvZnR3YXJlIERlZmluZWQgTmV0d29ya2luZw0KMTguIENy b3NzLUxheWVyIERlc2lnbiBhbmQgQWRhcHRhdGlvbg0KMTkuIFJhZGlvIFJlc291cmNlIE1hbmFn ZW1lbnQNCjIwLiBNb2JpbGl0eSwgSGFuZG9mZiBhbmQgTG9jYXRpb24gTWFuYWdlbWVudA0KMjEu IFBlcmZvcm1hbmNlIE1vZGVsaW5nIGFuZCBFdmFsdWF0aW9uDQoyMi4gV2lyZWxlc3MgYW5kIE1v YmlsZSBOZXR3b3JrIEFyY2hpdGVjdHVyZQ0KDQoNCklNUE9SVEFOVCBEQVRFUyANClN1Ym1pc3Np b24gRGVhZGxpbmU6IDEgRmVicnVhcnksIDIwMTMNCkF1dGhvcnMgTm90aWZpY2F0aW9uOiAxIEFw cmlsLCAyMDEzDQpGaW5hbCBNYW51c2NyaXB0IER1ZTogMSBNYXksIDIwMTMNCkNvbmZlcmVuY2Ug RGF0ZTogMTYtMTggSnVseSwgMjAxMw0KDQoNClBBUEVSIFNVQk1JU1NJT04gR1VJREVMSU5FDQpQ cm9zcGVjdGl2ZSBhdXRob3JzIGFyZSBpbnZpdGVkIHRvIHN1Ym1pdCBtYW51c2NyaXB0cyByZXBv cnRpbmcgb3JpZ2luYWwgdW5wdWJsaXNoZWQgcmVzZWFyY2ggYW5kIHJlY2VudCBkZXZlbG9wbWVu dHMgaW4gdGhlIHRvcGljcyByZWxhdGVkIHRvIHRoZSB3b3Jrc2hvcC4gVGhlIGxlbmd0aCBvZiB0 aGUgcGFwZXJzIHNob3VsZCBub3QgZXhjZWVkIDYgcGFnZXMgKyAyIHBhZ2VzIGZvciBvdmVybGVu Z3RoIGNoYXJnZXMgKElFRUUgQ29tcHV0ZXIgU29jaWV0eSBQcm9jZWVkaW5ncyBNYW51c2NyaXB0 cyBzdHlsZTogdHdvIGNvbHVtbnMsIHNpbmdsZS1zcGFjZWQsIDEwLXBvaW50IGZvbnQpLCBpbmNs dWRpbmcgZmlndXJlcyBhbmQgcmVmZXJlbmNlcy4NCg0KWW91IGNhbiBjb25maXJtIHRoZSBJRUVF IENvbXB1dGVyIFNvY2lldHkgUHJvY2VlZGluZ3MgQXV0aG9yIEd1aWRlbGluZXMgYXQgdGhlIGZv bGxvd2luZyB3ZWIgcGFnZTogVVJMOiBodHRwOi8vd3d3LmNvbXB1dGVyLm9yZy9wb3J0YWwvd2Vi L2NzY3BzL2Zvcm1hdHRpbmcuDQoNClBhcGVycyBzaG91bGQgYmUgc3VibWl0dGVkIHRocm91Z2gg dGhlIEVhc3lDaGFpciBwYXBlciBzdWJtaXNzaW9uIHN5c3RlbSAoaHR0cHM6Ly93d3cuZWFzeWNo YWlyLm9yZy9hY2NvdW50L3NpZ25pbi5jZ2k/Y29uZj13bm0yMDEzKS4NCg0KQWxsIHBhcGVycyB3 aWxsIGJlIHBlZXIgcmV2aWV3ZWQgYW5kIHRoZSBjb21tZW50cyB3aWxsIGJlIHByb3ZpZGVkIHRv IHRoZSBhdXRob3JzLiBPbmNlIGFjY2VwdGVkLCB0aGUgcGFwZXIgd2lsbCBiZSBpbmNsdWRlZCBp bnRvIHRoZSBJRUVFIGNvbmZlcmVuY2UgcHJvY2VlZGluZ3MgcHVibGlzaGVkIGJ5IElFRUUgQ29t cHV0ZXIgU29jaWV0eSBQcmVzcyAoaW5kZXhlZCBieSBFSSkuIEF1dGhvcnMgKGF0IGxlYXN0IG9u ZSkgb2YgYW55IGFjY2VwdGVkIHBhcGVyIGFyZSByZXF1ZXN0ZWQgdG8gcmVnaXN0ZXIgYXQgdGhl IGNvbmZlcmVuY2UuDQoNCg0KV09SS1NIT1AgQ0hBSVJTDQpZdWxlaSBXdSwgQ2hpbmVzZSBBY2Fk ZW15IG9mIFNjaWVuY2VzLCBDaGluYQ0KR2V5b25nIE1pbiwgVW5pdmVyc2l0eSBvZiBCcmFkZm9y ZCwgVUsNCkFobWVkIEFsLUR1YmFpLCBFZGluYnVyZ2ggTmFwaWVyIFVuaXZlcnNpdHksIFVLDQoN Cg0KQ09OVEFDVA0KUGxlYXNlIGVtYWlsIGlucXVpcmllcyBjb25jZXJuaW5nIFdOTS0yMDEzIHRv OiBEci4gWXVsZWkgV3UgKHl1bGVpIERPVCBmcmFuayBET1Qgd3UgQVQgZ21haWwgRE9UIGNvbSkg YW5kIHRoZSBjb25mZXJlbmNlIG9yZ2FuaXplcnMgKHdubSBET1QgbWVsYm91cm5lIERPVCAyMDEz IEFUIGdtYWlsIERPVCBjb20pLg== ------=_001_NextPart135381386565_=---- Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Appologies if you received multiple copies&n= bsp;of this WNM-2013 CFP.
---------------------------------------------------------------
CALL FOR PAPERS
 
The 4th International Workshop on Wireless&n= bsp;Networks and Multimedia (WNM-2013), Melbourne,&nbs= p;Australia, 16-18 July, 2013
 
http://wnm2013.csp.escience.cn/
 
To be held in conjunction with The = ;11th IEEE ISPA-2013
The accepted papers from this workshop = will be included into the IEEE conference&nb= sp;proceedings published by IEEE Computer Society= , and will be indexed by EI
 
 
INTRODUCTION
The wireless communication technologies have = ;evolved quickly over the past years. As&nbs= p;the explosive growth in broadband wireless = ;networks, multimedia applications will dominate = the future wireless communication society, result= ing in non-trivial problems in terms of = ;available capacity, reliability, quality-of-service, = delay, and throughput.
 
To successfully support wireless multimedia = applications, it is necessary to improve the=  state-of-the-art techniques (such as radio = resource management, mobility, handoff, and locat= ion management, etc.) in the multimedia tran= smission over wireless networks in order to&= nbsp;provide quality-of-service guarantees between the=  end-users and achieve a high quality-of-exp= erience for end-users.
 
This workshop will address the important&nbs= p;problems and challenges caused by the tran= smission of multimedia applications over wireless=  networks. The workshop aims to bring t= ogether computer scientists and engineers in = ;different disciplines to share and exchange = ;their experience and ideas and discuss stat= e-of-the-art and in-progress research on all = ;aspects of wireless networks and multimedia = ;applications.
 
The topics of particular interest include,&n= bsp;but are not limited to:
1. Ultra-Wideband Networks
2. Wireless Ad Hoc and Mesh Networks
3. Wireless Personal Area Networks
4. Wireless Local Area Networks
5. Wireless Sensor Networks
6. Wireless Metropolitan Area Networks
7. Cellular Networks
8. WiMAX
9. Optical Wireless Access Networks
10. Mobile Computing and Wireless Communicat= ions
11. Future Wireless Networks and Protocols
12. Multimedia Communications and Services
13. Congestion and Admission Control
14. Wireless MAC Protocols: Design and = Analysis
15. Quality of Service Provisioning
16. Wireless Network Trust, Privacy and = ;Security
17. Software Defined Radio & Software&nb= sp;Defined Networking
18. Cross-Layer Design and Adaptation
19. Radio Resource Management
20. Mobility, Handoff and Location Managemen= t
21. Performance Modeling and Evaluation
22. Wireless and Mobile Network Architecture=
 
 
IMPORTANT DATES 
Submission Deadline: 1 February, 2013
Authors Notification: 1 April, 2013
Final Manuscript Due: 1 May, 2013
Conference Date: 16-18 July, 2013
 
 
PAPER SUBMISSION GUIDELINE
Prospective authors are invited to submit&nb= sp;manuscripts reporting original unpublished research=  and recent developments in the topics = related to the workshop. The length of = the papers should not exceed 6 pages +&= nbsp;2 pages for overlength charges (IEEE Co= mputer Society Proceedings Manuscripts style: two=  columns, single-spaced, 10-point font), includin= g figures and references.
 
You can confirm the IEEE Computer Socie= ty Proceedings Author Guidelines at the foll= owing web page: URL: http://www.computer.org/portal/we= b/cscps/formatting.
 
Papers should be submitted through the = EasyChair paper submission system (https://www.easycha= ir.org/account/signin.cgi?conf=3Dwnm2013).
 
All papers will be peer reviewed and&nb= sp;the comments will be provided to the = ;authors. Once accepted, the paper will be&n= bsp;included into the IEEE conference proceedings=  published by IEEE Computer Society Press&nb= sp;(indexed by EI). Authors (at least one)&n= bsp;of any accepted paper are requested to&n= bsp;register at the conference.
 
 
WORKSHOP CHAIRS
Yulei Wu, Chinese Academy of Sciences, = China
Geyong Min, University of Bradford, UK
Ahmed Al-Dubai, Edinburgh Napier University, = ;UK
 
 
CONTACT
Please email inquiries concerning WNM-2013 t= o: Dr. Yulei Wu (yulei DOT frank DOT&nb= sp;wu AT gmail DOT com) and the confere= nce organizers (wnm DOT melbourne DOT 2013&n= bsp;AT gmail DOT com).
------=_001_NextPart135381386565_=------ From sbarkai@gmail.com Sun Jan 20 20:32:08 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEAAA21F8777 for ; Sun, 20 Jan 2013 20:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.404 X-Spam-Level: X-Spam-Status: No, score=-1.404 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SP1xKMFOnM+R for ; Sun, 20 Jan 2013 20:32:07 -0800 (PST) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id 780B921F8775 for ; Sun, 20 Jan 2013 20:32:04 -0800 (PST) Received: by mail-oa0-f42.google.com with SMTP id j1so5705974oag.15 for ; Sun, 20 Jan 2013 20:32:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=IUJ36exaF55Txu7WcqB7nCLRza82pUHp8jDqqu83k6s=; b=jRw6Gv8DjqKss3wv4C8Hx8n16t3VVYmbzbjUIc6BdhOZ5VwFa1ROYd02vCISg4pFDX c9+zPg1B7JFTXY+r1YMuJHZ+d7mWLCzWxCrkxCDXF8j5+nIqXkQQCRYt4fub1IsdNY+b wQhW6Z7q4oqR/2W399U+9NgvTieOWbnX9nSe30+6XVwFKS0CSG+e+jEVgupHwp9C2jHs +JHqBShcIGXU5npZpO6kXvgrWVRt20R7z32NUIlGbhaFoE7oT3L1nyn2c1DBmEO8q7iH mmpfomzP3pBTQzYQ6mca98TCVrGKv77yrcYm/Bm2Wu5P8n9FPKVJP4tTTvmcLcChI48G ZjLA== X-Received: by 10.60.3.1 with SMTP id 1mr12813055oey.138.1358742723886; Sun, 20 Jan 2013 20:32:03 -0800 (PST) Received: from [192.168.1.73] (108-214-96-27.lightspeed.sntcca.sbcglobal.net. [108.214.96.27]) by mx.google.com with ESMTPS id m3sm9861193obm.21.2013.01.20.20.31.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Jan 2013 20:32:03 -0800 (PST) References: <50821.115.184.122.32.1358316516.squirrel@www.nmsworks.co.in> In-Reply-To: <50821.115.184.122.32.1358316516.squirrel@www.nmsworks.co.in> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <263CC879-1035-4BC0-9194-38FB44E25D16@gmail.com> X-Mailer: iPad Mail (10A550) From: Sharon Date: Sun, 20 Jan 2013 20:31:55 -0800 To: "sitaraman@nmsworks.co.in" Cc: "Eggert, Lars" , Sharon Barkai , "sdn@irtf.org" , "openflow-discuss@mailman.stanford.edu" Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New:Software-Defined Networking Research Group (SDNRG) X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 04:32:09 -0000 Most of what you say corresponds to the basic notion of layers. In this case network virtualization SDN layer that the end points do not see= . Just like application software doesn't see the HyperVisor layer inserted bet= ween the OS and the machine in order to virtualize computers. As for a language and programming model above the open flow "assembly" - For many usage examples its more or less a matter of declarative Schema: - The identities: location state and logical containers (big table) - The policies catalogs of much smaller size user-defined tables=20 For traffic engineering you probably need SDN layer control points presence i= n core junctions. This is more tricky because the graph you want to handle is an overlay graph= . It's very hard to keep track of every physical underlying hop - But the overlay graph can be measurement based .. For such Overlay graphs Most likely a structured CLOS or Valiant topology ca= n be used. This can map to a logical Schema of intermediate points as well. What I think you want to avoid is a situation where a trivial physical topol= ogy change or re-patching of ports triggering a massive recalculation of tra= veling salesman flows. It's better if the network heals autonomously with fading side effects away f= rom the "fault-line", Followed by gradual reintroduction of programmed control points. This is worth further examination. On Jan 15, 2013, at 22:08, sitaraman@nmsworks.co.in wrote: Hi Sharon, It is interesting that you earlier mentioned aggregation points and split points. As you mention below, the semantics of the term reachability could be looked at in a wider sense going beyond the network traffic reachability, which is likely what you mean by the terminology of basic reachability. In ITU-T and TMF model there is an important architectural component called the adaptation. A Termination Point could be associated, in addition to a termination component, to also an adapatation component. The global policies that you have given as illustrations to the problem can be fundamentally viwed as Adaptations. Adaptations and Terminations together therefore could serve as a unifying generalization of the aggregation abstraction. What strikes me is the relationship of adapations to the generalized reachability alluded to earlier. Once you have the physical network infrastructure in place (relatively long lived, slowly changing characterstic of the network ) your universe set of the relationship between the adapataions and the associated generalized reach could get significantltly narrowed. A case then for programmability of the same. Here we are now closer to making the problem of relating the architecture of the system to it programmability more tractable. Could we explore any existing programming language that can handle graphs and operations on it well..ie a language for graphs? Also the levels of control (Network Device level, Protocol level, Control Plane level, User App level) needs to be factored in. The concept underlying IEEEs OAM Standardization based on MEPs/MIPs come to mind.. Is there value in adapting those in a unified framework? SDN is to networks it appears as Reconfigurable Computing is to the Computing industry.... Sitaraman > Yes, but not exactly. >=20 > In the first example we want to achieve basic packet delivery service that= > works under the worst possible conditions. > After all the Internet was first designed to withstand a nuclear strike. >=20 > In the second example we ask for much more. Essentially we ask the network= > to perform global balancing or global map-reduce on behalf of > applications. Instead of each app doing its own. >=20 > This level of network programmability is possible IFF there is a basic > underlying connectivity because its based on distributed SDN control > software. > This is a bootstrap sequence. >=20 > Hence the complementary aspect of traditional and software defined > networking and the overlay models SDN models converge towards. >=20 > Based on this basic reachability you can also apply sophisticate traffic > engineering for certain flows on graphs, facilitate mobility and workflows= > etc. > Additional driver is security and the ability to account for each and > every packet. This is virtually impossible under the autonomous control > models, but again without that foundation you can not build these next > levels of functionality. >=20 > Hope this makes sense - it's supposed to simplify network management as > well - because sophisticated configuration need not be scattered into > interface configuration - end points are moving between those. Instead, > all SDN programable policies should be available in a similar to database > programming mode vs manager-agents mode, for the complex and massive > things at least. >=20 > Sent from my iPhone 650 492 0794 >=20 > On Jan 15, 2013, at 9:27 AM, "sitaraman@nmsworks.co.in" > wrote: >=20 > Thanks Sharon, Looking at the examples, I seem to think the second one > has a strong reach component to it, only the reach is not for the traffic > that is carried but metadata about the traffic? > Sitaraman >> Happy to but don't want to bear on the list - >> Can you take two simple examples and can extrapolate: >>=20 >> One: get a ping across to multiple locations, with different gear from >> different generations of hardware and different administrative domains >> that have no reason to trust one another as an example ISPs from >> conflicting nations or competing vendors. >>=20 >> Two: globally balance a function instantiated using the same address in >> multiple locations with global awareness in each location of the exact >> health state load and affinity associated with each of the resources. >>=20 >>=20 >>=20 >> On Jan 15, 2013, at 7:19, "sitaraman@nmsworks.co.in" >> wrote: >>=20 >> Hi Sharon, >> Would appreciate if you could elaborate on the extended network >> functionality and the conflict between the reach and >> functionality...Thanks >> Sitaraman >>> depends on what you try to achieve- >>>=20 >>> if you try to extend network reach then back-comp interoperable control >>> is >>> key, therefore a "need to know basis" distribution (topo) makes that >>> feasible. >>>=20 >>> If you try to extended network functionality, your control distribution >>> emphasis changes significantly, and you still have to consider the >>> touch >>> point of the control application with the wire - tcams, scope, aging, >>> etc >>>=20 >>> Since non of these reach & function needs are going away it looks like >>> SDN >>> overlays on IP can be used to sandbox the conflicting requirements. I >>> haven't seen a hammer other then layers that can handle such different >>> nails. >>>=20 >>>=20 >>>=20 >>> On Jan 15, 2013, at 6:26 AM, "sitaraman@nmsworks.co.in" >>> wrote: >>>=20 >>> Hi Sharon, >>> Thanks for these valuable insights. >>> In the preSDN networking world, due to practicality of evolution and >>> backward compatibility needs there arose multiple ways of doing the >>> same >>> thing..i.e gather and use graph reachability information. >>> SDN is our chance to begin with a clean slate, while we need not throw >>> the interoperation with existing networks totally out the window, we >>> must also be careful not to avoid falling into the trap of restricting >>> the capabilities and flexibility due to its need, even at first as >>> options in isolation, for SDN. >>> What we could consider in IRTF is standardizing a single way to gather >>> reachability information (in a capacitated graph, typically). Indeed as >>> you point out very aptly, such reachability information can be of >>> varying geographical spans and varying aggregation level spans and >>> these >>> can have causal connections. If I understand you correctly, an >>> Aggregration pivot has implications on the geographic spans that need >>> to >>> considered, and such aggregation pivots serve to segment/split the >>> geographic expanse (conceptually in the graph model of the network that >>> is) that the control has to deal with. >>> It appears then if only we have a control of a control that based on >>> the >>> specified aggregation pivots redistribute the division between >>> distributed control and distribution of control that when combined with >>> operations on Graph model with scalable algorithmic schemes as >>> mentioned >>> in GPS, then we will have a powerful means to exercise traffic control, >>> shaping and delivery which are the fundamental aspects of any network. >>> A source of complexity we may need to handle is to be able to allow for >>> multiple instances of such distributed control and distribution of >>> control working together. >>> Such segmentation between distributed control and distribution of >>> control also could yield to a scalable solution. >>> Sitaraman >>>=20 >>>=20 >>>>=20 >>>> These bring up interesting global-local distinctions. >>>>=20 >>>> The scope of a flow definition is clearly local to the aggregation >>>> point: >>>> IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a connection >>>> ..depends. >>>>=20 >>>> The context of handling a flow in a specific point clearly has global >>>> user-app considerations. >>>> Distributing control logic is therefore according to global context >>>> mapping not aggregation topology. This is different then control >>>> distribution considerations for packet forwarding. >>>>=20 >>>> The touch point between control and forwarding is therefore a >>>> practical >>>> choice. >>>> The control has to be both locally (scope & mechanics) and globally >>>> (user-app) aware. >>>>=20 >>>> Overlays work quite well in that sense, global awareness by >>>> distributed >>>> clustering, >>>> local touch point splits, or merges encapsulates flows based on global >>>> pipeline need. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Jan 14, 2013, at 17:49, "sitaraman@nmsworks.co.in" >>>> wrote: >>>>=20 >>>> Hi, >>>> Some thoughts. >>>> 1. Does the separation of control plane from the forwarding >>>> necessarily >>>> mean the control now is to be centralized? It likely is not. Though >>>> the >>>> network device itself need not implment the control plane and can be >>>> interacted via an OpenFlow interface, the control funcationality can >>>> be >>>> a separate distributed system. >>>> 2. Model to represent Network >>>> Network and traffic flows are fundamentally flows in capacitated >>>> graphs. Could we look at using Stanford Graph Processing System >>>> (GPS) for SDN based networks. The periodic communication amongst >>>> nodes seem to naturally map to a traffic and information flow in a >>>> network? >>>>=20 >>>> 3. Model to repsresent capacities of network resources and logical >>>> abstractions of physical resources. >>>> SDN dosent and probably should not change anything fundamental in the >>>> traffic flow itself. This means that here SDN must look into reusing >>>> existing models. TMF models is a likely candidate. >>>> 4. Model to represent faults. >>>> Same as above. New type of faults related to the decoupled (possibly >>>> yet distributed) control plane to be harmonized with model for >>>> existing faults. Again TMF is a source. >>>> 5. Model to respresent Business aspects (Products, Orders such as time >>>> to delivery commitments) >>>> Same as above and again TMF is a source for this model. The new SDN >>>> network could leverage by being able to be invoked or referred to in >>>> the existing TMF business model aspects. After all these are directly >>>> related to revenue and Customer Experience Management. >>>> 6. Is it distributed control, distribution of control or soemwhere in >>>> between that is preferable. Distributed control can be a conceptual >>>> centralized control which is implemented in a distribued manner. Can >>>> this nature be adaptively changed. Any aspects of learning in control >>>> plane in SDN networks. >>>> 7. Layers of control Ethernet Layer, MPLS layer, IP layer. >>>> 8. Service Providers' bottom line is business and this means the TMF >>>> FAB >>>> Fulfilment, Assurance and Billing. SDN models must leverage the >>>> existing >>>> model as transparently as is practically feasibile. >>>> Sitaraman >>>>=20 >>>> Possibly of interest. >>>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>>> From: "Eggert, Lars" >>>>>> Subject: [irtf-discuss] New: Software-Defined Networking Research >>>>>> Group >>>>>> (SDNRG) >>>>>> Date: January 14, 2013 10:24:57 GMT+01:00 >>>>>> To: "" , >>>>>> "" >>>>>> Cc: "sdn@irtf.org" >>>>>> Reply-To: "irtf-discuss@irtf.org" >>>>>>=20 >>>>>> A new IRTF research group on Software-Defined Networking has been >>>>>> chartered: >>>>>>=20 >>>>>> The Software-Defined Networking Research Group (SDNRG) investigates >>>>>> SDN >>>>>> from various perspectives with the goal of identifying the >>>>>> approaches >>>>>> that >>>>>> can be defined, deployed and used in the near term as well >>>>>> identifying >>>>>> future research challenges. In particular, key areas of interest >>>>>> include >>>>>> solution scalability, abstractions, and programming languages and >>>>>> paradigms >>>>>> particularly useful in the context of SDN. In addition, it is an >>>>>> explicit >>>>>> goal of the SDNRG to provide a forum for researchers to investigate >>>>>> key >>>>>> and interesting problems in the Software-Defined Networking field. >>>>>>=20 >>>>>> Charter and participation information can be found at >>>>>> http://irtf.org/sdnrg >>>>>>=20 >>>>>> Lars Eggert >>>>>> IRTF Chair >>>>>=20 >>>>> _______________________________________________ >>>>> openflow-discuss mailing list >>>>> openflow-discuss@lists.stanford.edu >>>>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>>>>=20 >>>>> -- >>>>> This message has been scanned for viruses and >>>>> dangerous content by MailScanner, and is >>>>> believed to be clean. >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> This message has been scanned for viruses and >>>> dangerous content by MailScanner, and is >>>> believed to be clean. >>>>=20 >>>> _______________________________________________ >>>> sdn mailing list >>>> sdn@irtf.org >>>> https://www.irtf.org/mailman/listinfo/sdn >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> sdn mailing list >>>> sdn@irtf.org >>>> https://www.irtf.org/mailman/listinfo/sdn >>>>=20 >>>> -- >>>> This message has been scanned for viruses and >>>> dangerous content by MailScanner, and is >>>> believed to be clean. >>>=20 >>>=20 >>>=20 >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >>=20 >>=20 >>=20 >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >>=20 >>=20 >>=20 >>=20 >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >=20 >=20 >=20 > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. >=20 >=20 >=20 >=20 > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ sdn mailing list sdn@irtf.org https://www.irtf.org/mailman/listinfo/sdn From sitaraman@nmsworks.co.in Mon Jan 21 02:25:57 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9FF921F8507 for ; Mon, 21 Jan 2013 02:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FW7oxmppo50j for ; Mon, 21 Jan 2013 02:25:56 -0800 (PST) Received: from indlocal.nmsworks.co.in (nmsworks.co.in [14.140.238.3]) by ietfa.amsl.com (Postfix) with ESMTP id DDE5A21F84C8 for ; Mon, 21 Jan 2013 02:25:54 -0800 (PST) Received: from www.nmsworks.co.in (localhost [127.0.0.1]) by indlocal.nmsworks.co.in (8.13.8/8.13.8) with ESMTP id r0LALY1k010043; Mon, 21 Jan 2013 15:51:34 +0530 Received: from 192.168.9.56 (SquirrelMail authenticated user sitaraman) by www.nmsworks.co.in with HTTP; Mon, 21 Jan 2013 15:51:41 +0530 (IST) Message-ID: <50967.192.168.9.56.1358763701.squirrel@www.nmsworks.co.in> In-Reply-To: <263CC879-1035-4BC0-9194-38FB44E25D16@gmail.com> References: <50821.115.184.122.32.1358316516.squirrel@www.nmsworks.co.in> <263CC879-1035-4BC0-9194-38FB44E25D16@gmail.com> Date: Mon, 21 Jan 2013 15:51:41 +0530 (IST) From: sitaraman@nmsworks.co.in To: "Sharon" User-Agent: SquirrelMail/1.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-NMSWorks-MailScanner-Information: Please contact the ISP for more information X-NMSWorks-MailScanner-ID: r0LALY1k010043 X-NMSWorks-MailScanner: Found to be clean X-NMSWorks-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.9, required 4, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-NMSWorks-MailScanner-From: sitaraman@nmsworks.co.in Cc: Sharon Barkai , "Eggert, Lars" , "sdn@irtf.org" , "openflow-discuss@mailman.stanford.edu" Subject: Re: [Sdn] [openflow-discuss] Fwd: [irtf-discuss] New:Software-Defined Networking Research Group (SDNRG) X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 10:25:57 -0000 Though you have raised a very important distinct aspect, storage schemes needed for the problem, i will for now set that aspect aside for now. Layer transparency is indeed very useful. But we need to be careful to distinguish between traffic, control, application (and others?) layering. Visibility in and across layers in one category may actually be needed to ensure transparency in others. I have a feeling when we talk of network design and optimization we may risk mixing things up here. For the best architecture to evolve, network design must (to the extent possible) assume the worst Protocol and Control architecture and vice versa, must likely not assume the best... What we were earlier discussing is more closer to Network Control and Protocol design for SDN and layers above it. This must not assume or must be minimally aware of the network design in itself which occurs on top of the Network. Layering of various categories and the coordination of them (the split points that you mentioned) has the potential to allievate some of the massive recalculation...partly aided by the transparency afforded and not needing a global re-optimization a sort of a "convexity" characteristic to the problem, as the Optimization folks seem to call it for something similar. Sitaraman > Most of what you say corresponds to the basic notion of layers. > In this case network virtualization SDN layer that the end points do not > see. > Just like application software doesn't see the HyperVisor layer inserted > between the OS and the machine in order to virtualize computers. > > As for a language and programming model above the open flow "assembly" - > > For many usage examples its more or less a matter of declarative Schema: > - The identities: location state and logical containers (big table) > - The policies catalogs of much smaller size user-defined tables > > For traffic engineering you probably need SDN layer control points > presence in core junctions. > This is more tricky because the graph you want to handle is an overlay > graph. > It's very hard to keep track of every physical underlying hop - > But the overlay graph can be measurement based .. > > For such Overlay graphs Most likely a structured CLOS or Valiant topology > can be used. > This can map to a logical Schema of intermediate points as well. > > What I think you want to avoid is a situation where a trivial physical > topology change or re-patching of ports triggering a massive recalculation > of traveling salesman flows. > It's better if the network heals autonomously with fading side effects > away from the "fault-line", > Followed by gradual reintroduction of programmed control points. > > This is worth further examination. > > On Jan 15, 2013, at 22:08, sitaraman@nmsworks.co.in wrote: > > Hi Sharon, > It is interesting that you earlier mentioned aggregation points and split > points. As you mention below, the semantics of the term reachability > could be looked at in a wider sense going beyond the network traffic > reachability, which is likely what you mean by the terminology of basic > reachability. > In ITU-T and TMF model there is an important architectural component > called the adaptation. A Termination Point could be associated, in > addition to a termination component, to also an adapatation component. > The global policies that you have given as illustrations to the problem > can be fundamentally viwed as Adaptations. Adaptations and Terminations > together therefore could serve as a unifying generalization of the > aggregation abstraction. > What strikes me is the relationship of adapations to the generalized > reachability alluded to earlier. Once you have the physical network > infrastructure in place (relatively long lived, slowly changing > characterstic of the network ) your universe set of the relationship > between the adapataions and the associated generalized reach could get > significantltly narrowed. A case then for programmability of the same. > Here we are now closer to making the problem of relating the architecture > of the system to it programmability more tractable. > Could we explore any existing programming language that can handle graphs > and operations on it well..ie a language for graphs? > Also the levels of control (Network Device level, Protocol level, Control > Plane level, User App level) needs to be factored in. > The concept underlying IEEEs OAM Standardization based on MEPs/MIPs come > to mind.. Is there value in adapting those in a unified framework? > SDN is to networks it appears as Reconfigurable Computing is to the > Computing industry.... > Sitaraman > >> Yes, but not exactly. >> >> In the first example we want to achieve basic packet delivery service >> that >> works under the worst possible conditions. >> After all the Internet was first designed to withstand a nuclear strike. >> >> In the second example we ask for much more. Essentially we ask the >> network >> to perform global balancing or global map-reduce on behalf of >> applications. Instead of each app doing its own. >> >> This level of network programmability is possible IFF there is a basic >> underlying connectivity because its based on distributed SDN control >> software. >> This is a bootstrap sequence. >> >> Hence the complementary aspect of traditional and software defined >> networking and the overlay models SDN models converge towards. >> >> Based on this basic reachability you can also apply sophisticate traffic >> engineering for certain flows on graphs, facilitate mobility and >> workflows >> etc. >> Additional driver is security and the ability to account for each and >> every packet. This is virtually impossible under the autonomous control >> models, but again without that foundation you can not build these next >> levels of functionality. >> >> Hope this makes sense - it's supposed to simplify network management as >> well - because sophisticated configuration need not be scattered into >> interface configuration - end points are moving between those. Instead, >> all SDN programable policies should be available in a similar to >> database >> programming mode vs manager-agents mode, for the complex and massive >> things at least. >> >> Sent from my iPhone 650 492 0794 >> >> On Jan 15, 2013, at 9:27 AM, "sitaraman@nmsworks.co.in" >> wrote: >> >> Thanks Sharon, Looking at the examples, I seem to think the second one >> has a strong reach component to it, only the reach is not for the >> traffic >> that is carried but metadata about the traffic? >> Sitaraman >>> Happy to but don't want to bear on the list - >>> Can you take two simple examples and can extrapolate: >>> >>> One: get a ping across to multiple locations, with different gear from >>> different generations of hardware and different administrative domains >>> that have no reason to trust one another as an example ISPs from >>> conflicting nations or competing vendors. >>> >>> Two: globally balance a function instantiated using the same address in >>> multiple locations with global awareness in each location of the exact >>> health state load and affinity associated with each of the resources. >>> >>> >>> >>> On Jan 15, 2013, at 7:19, "sitaraman@nmsworks.co.in" >>> wrote: >>> >>> Hi Sharon, >>> Would appreciate if you could elaborate on the extended network >>> functionality and the conflict between the reach and >>> functionality...Thanks >>> Sitaraman >>>> depends on what you try to achieve- >>>> >>>> if you try to extend network reach then back-comp interoperable >>>> control >>>> is >>>> key, therefore a "need to know basis" distribution (topo) makes that >>>> feasible. >>>> >>>> If you try to extended network functionality, your control >>>> distribution >>>> emphasis changes significantly, and you still have to consider the >>>> touch >>>> point of the control application with the wire - tcams, scope, aging, >>>> etc >>>> >>>> Since non of these reach & function needs are going away it looks like >>>> SDN >>>> overlays on IP can be used to sandbox the conflicting requirements. I >>>> haven't seen a hammer other then layers that can handle such different >>>> nails. >>>> >>>> >>>> >>>> On Jan 15, 2013, at 6:26 AM, "sitaraman@nmsworks.co.in" >>>> wrote: >>>> >>>> Hi Sharon, >>>> Thanks for these valuable insights. >>>> In the preSDN networking world, due to practicality of evolution and >>>> backward compatibility needs there arose multiple ways of doing the >>>> same >>>> thing..i.e gather and use graph reachability information. >>>> SDN is our chance to begin with a clean slate, while we need not throw >>>> the interoperation with existing networks totally out the window, we >>>> must also be careful not to avoid falling into the trap of restricting >>>> the capabilities and flexibility due to its need, even at first as >>>> options in isolation, for SDN. >>>> What we could consider in IRTF is standardizing a single way to gather >>>> reachability information (in a capacitated graph, typically). Indeed >>>> as >>>> you point out very aptly, such reachability information can be of >>>> varying geographical spans and varying aggregation level spans and >>>> these >>>> can have causal connections. If I understand you correctly, an >>>> Aggregration pivot has implications on the geographic spans that need >>>> to >>>> considered, and such aggregation pivots serve to segment/split the >>>> geographic expanse (conceptually in the graph model of the network >>>> that >>>> is) that the control has to deal with. >>>> It appears then if only we have a control of a control that based on >>>> the >>>> specified aggregation pivots redistribute the division between >>>> distributed control and distribution of control that when combined >>>> with >>>> operations on Graph model with scalable algorithmic schemes as >>>> mentioned >>>> in GPS, then we will have a powerful means to exercise traffic >>>> control, >>>> shaping and delivery which are the fundamental aspects of any network. >>>> A source of complexity we may need to handle is to be able to allow >>>> for >>>> multiple instances of such distributed control and distribution of >>>> control working together. >>>> Such segmentation between distributed control and distribution of >>>> control also could yield to a scalable solution. >>>> Sitaraman >>>> >>>> >>>>> >>>>> These bring up interesting global-local distinctions. >>>>> >>>>> The scope of a flow definition is clearly local to the aggregation >>>>> point: >>>>> IP, IP-Port (NAT etc), TCP connection, HTTP pipeline with a >>>>> connection >>>>> ..depends. >>>>> >>>>> The context of handling a flow in a specific point clearly has global >>>>> user-app considerations. >>>>> Distributing control logic is therefore according to global context >>>>> mapping not aggregation topology. This is different then control >>>>> distribution considerations for packet forwarding. >>>>> >>>>> The touch point between control and forwarding is therefore a >>>>> practical >>>>> choice. >>>>> The control has to be both locally (scope & mechanics) and globally >>>>> (user-app) aware. >>>>> >>>>> Overlays work quite well in that sense, global awareness by >>>>> distributed >>>>> clustering, >>>>> local touch point splits, or merges encapsulates flows based on >>>>> global >>>>> pipeline need. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Jan 14, 2013, at 17:49, "sitaraman@nmsworks.co.in" >>>>> wrote: >>>>> >>>>> Hi, >>>>> Some thoughts. >>>>> 1. Does the separation of control plane from the forwarding >>>>> necessarily >>>>> mean the control now is to be centralized? It likely is not. Though >>>>> the >>>>> network device itself need not implment the control plane and can be >>>>> interacted via an OpenFlow interface, the control funcationality can >>>>> be >>>>> a separate distributed system. >>>>> 2. Model to represent Network >>>>> Network and traffic flows are fundamentally flows in capacitated >>>>> graphs. Could we look at using Stanford Graph Processing System >>>>> (GPS) for SDN based networks. The periodic communication amongst >>>>> nodes seem to naturally map to a traffic and information flow in a >>>>> network? >>>>> >>>>> 3. Model to repsresent capacities of network resources and logical >>>>> abstractions of physical resources. >>>>> SDN dosent and probably should not change anything fundamental in the >>>>> traffic flow itself. This means that here SDN must look into reusing >>>>> existing models. TMF models is a likely candidate. >>>>> 4. Model to represent faults. >>>>> Same as above. New type of faults related to the decoupled (possibly >>>>> yet distributed) control plane to be harmonized with model for >>>>> existing faults. Again TMF is a source. >>>>> 5. Model to respresent Business aspects (Products, Orders such as >>>>> time >>>>> to delivery commitments) >>>>> Same as above and again TMF is a source for this model. The new SDN >>>>> network could leverage by being able to be invoked or referred to in >>>>> the existing TMF business model aspects. After all these are directly >>>>> related to revenue and Customer Experience Management. >>>>> 6. Is it distributed control, distribution of control or soemwhere in >>>>> between that is preferable. Distributed control can be a conceptual >>>>> centralized control which is implemented in a distribued manner. Can >>>>> this nature be adaptively changed. Any aspects of learning in control >>>>> plane in SDN networks. >>>>> 7. Layers of control Ethernet Layer, MPLS layer, IP layer. >>>>> 8. Service Providers' bottom line is business and this means the TMF >>>>> FAB >>>>> Fulfilment, Assurance and Billing. SDN models must leverage the >>>>> existing >>>>> model as transparently as is practically feasibile. >>>>> Sitaraman >>>>> >>>>> Possibly of interest. >>>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>>> From: "Eggert, Lars" >>>>>>> Subject: [irtf-discuss] New: Software-Defined Networking Research >>>>>>> Group >>>>>>> (SDNRG) >>>>>>> Date: January 14, 2013 10:24:57 GMT+01:00 >>>>>>> To: "" , >>>>>>> "" >>>>>>> Cc: "sdn@irtf.org" >>>>>>> Reply-To: "irtf-discuss@irtf.org" >>>>>>> >>>>>>> A new IRTF research group on Software-Defined Networking has been >>>>>>> chartered: >>>>>>> >>>>>>> The Software-Defined Networking Research Group (SDNRG) investigates >>>>>>> SDN >>>>>>> from various perspectives with the goal of identifying the >>>>>>> approaches >>>>>>> that >>>>>>> can be defined, deployed and used in the near term as well >>>>>>> identifying >>>>>>> future research challenges. In particular, key areas of interest >>>>>>> include >>>>>>> solution scalability, abstractions, and programming languages and >>>>>>> paradigms >>>>>>> particularly useful in the context of SDN. In addition, it is an >>>>>>> explicit >>>>>>> goal of the SDNRG to provide a forum for researchers to investigate >>>>>>> key >>>>>>> and interesting problems in the Software-Defined Networking field. >>>>>>> >>>>>>> Charter and participation information can be found at >>>>>>> http://irtf.org/sdnrg >>>>>>> >>>>>>> Lars Eggert >>>>>>> IRTF Chair >>>>>> >>>>>> _______________________________________________ >>>>>> openflow-discuss mailing list >>>>>> openflow-discuss@lists.stanford.edu >>>>>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>>>>> >>>>>> -- >>>>>> This message has been scanned for viruses and >>>>>> dangerous content by MailScanner, and is >>>>>> believed to be clean. >>>>> >>>>> >>>>> >>>>> -- >>>>> This message has been scanned for viruses and >>>>> dangerous content by MailScanner, and is >>>>> believed to be clean. >>>>> >>>>> _______________________________________________ >>>>> sdn mailing list >>>>> sdn@irtf.org >>>>> https://www.irtf.org/mailman/listinfo/sdn >>>>> >>>>> >>>>> _______________________________________________ >>>>> sdn mailing list >>>>> sdn@irtf.org >>>>> https://www.irtf.org/mailman/listinfo/sdn >>>>> >>>>> -- >>>>> This message has been scanned for viruses and >>>>> dangerous content by MailScanner, and is >>>>> believed to be clean. >>>> >>>> >>>> >>>> -- >>>> This message has been scanned for viruses and >>>> dangerous content by MailScanner, and is >>>> believed to be clean. >>>> >>>> >>>> >>>> >>>> -- >>>> This message has been scanned for viruses and >>>> dangerous content by MailScanner, and is >>>> believed to be clean. >>> >>> >>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >>> >>> >>> >>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >> >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> >> >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From sitaraman@nmsworks.co.in Wed Jan 23 02:24:01 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAE121F86A1 for ; Wed, 23 Jan 2013 02:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.27 X-Spam-Level: X-Spam-Status: No, score=-1.27 tagged_above=-999 required=5 tests=[AWL=-0.530, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W26DCbJSmtcm for ; Wed, 23 Jan 2013 02:24:00 -0800 (PST) Received: from indlocal.nmsworks.co.in (indus.nmsworks.co.in [14.140.238.3]) by ietfa.amsl.com (Postfix) with ESMTP id 548C621F868F for ; Wed, 23 Jan 2013 02:23:59 -0800 (PST) Received: from www.nmsworks.co.in (localhost [127.0.0.1]) by indlocal.nmsworks.co.in (8.13.8/8.13.8) with ESMTP id r0NALsWF012699; Wed, 23 Jan 2013 15:51:55 +0530 Received: from 192.168.9.56 (SquirrelMail authenticated user sitaraman) by www.nmsworks.co.in with HTTP; Wed, 23 Jan 2013 15:51:56 +0530 (IST) Message-ID: <51321.192.168.9.56.1358936516.squirrel@www.nmsworks.co.in> Date: Wed, 23 Jan 2013 15:51:56 +0530 (IST) From: sitaraman@nmsworks.co.in To: "sdn@irtf.org" , "openflow-discuss@mailman.stanford.edu" User-Agent: SquirrelMail/1.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-NMSWorks-MailScanner-Information: Please contact the ISP for more information X-NMSWorks-MailScanner-ID: r0NALsWF012699 X-NMSWorks-MailScanner: Found to be clean X-NMSWorks-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.9, required 4, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-NMSWorks-MailScanner-From: sitaraman@nmsworks.co.in Subject: [Sdn] SDN and Reinforced Concrete X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 10:24:01 -0000 The industry has always been toying around with connection oriented and connectionless. IP - Connectionless, TCP - Connection, MPLS/IP Connection, Optical Networks - Connection, ASON - Connectionless Nature. While IP moves towards connectionless Optical is moving towards a connection oriented nature. It is sort of like the uncertainty principle, if you are sure you are going to be able to deliver a given traffic matrix, you are not sure when and if you hit a problem, you are going to completely loose the ability to delvier (Connection), on the other hand, if your network is best effort and connectionless you are not sure of the traffic demand matrix that can be met more sure of delivery of what is possible when something goes wrong. Connectionless enables sophisticated control that makes it easier to (re)configure reachability for traffic, the control, [from the operations perspective], but the forwarding itself is more more complex (ip routing table lookups). In the Connection oriented the control [from the network operations perspective] is more involved (there are less automated algorithmic protocols doing the work for you) but the forwarding is easier. Perhaps it is no wonder each is looking at the other side as a greener pasture. SDN it appears could be the sweet spot. The decoupling of the control from the forwarding means that the connectionless-connection oriented nature of the network itself could be configurabile! We have configurability at the higher order....We now have configurability of the configurability of the network. Does this have implications in the kind of optimizations that are possible, surely, optimization possibilities could be more powerful in a dynamic graph as opposed to a less dynamic graph for any given traffic demand graph. This is something similar to Composites in the Materials world, SDN is perhaps the Reinforced Concrete of the Civil Engineering world! Sitaraman -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From sircar.rana@gmail.com Wed Jan 23 04:00:20 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D2821F8A67 for ; Wed, 23 Jan 2013 04:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QC3Tr+y6-z9a for ; Wed, 23 Jan 2013 04:00:19 -0800 (PST) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by ietfa.amsl.com (Postfix) with ESMTP id D173F21F8A3D for ; Wed, 23 Jan 2013 04:00:19 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id wz17so4637399pbc.34 for ; Wed, 23 Jan 2013 04:00:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=9b26OG/B2Gzz0zKX1OACp4uqzJnEx7LGzFvy3DTgII0=; b=OdcLGU2t+lDkDAOS2z7Z51YrJD8bW85bRs95kuWoUHjU9/EPKBS40MPiX8vx9k7L0L uL8qGwFSQ7gtnUb/5wj0JZtyNwiLYeWlhC6TyCKKIBWbKDmAlKiQt4SjOqtqNsVQGW1G Khv0kXFg2aJK7IzmHNrfrrNa8jHyiOh/lWHaPO8Ufh47Ovl53qPT1zIpVW2H2OqGY7vD VELDNUbEY3lQVdO0Y6f25l0gouutNoqBl4JqTd+IbS5tJGGGxJDLBkvpDU85FuD3pr60 1icsIPlJDs/uQk32B3u64w7UbcgLgZmMBJ6/08z881Nd0Zz2mTqFQZeX+MTkEGdBFipU EXeA== X-Received: by 10.66.73.105 with SMTP id k9mr3944891pav.37.1358942419520; Wed, 23 Jan 2013 04:00:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.73.167 with HTTP; Wed, 23 Jan 2013 03:59:58 -0800 (PST) In-Reply-To: <51321.192.168.9.56.1358936516.squirrel@www.nmsworks.co.in> References: <51321.192.168.9.56.1358936516.squirrel@www.nmsworks.co.in> From: Rana Sircar Date: Wed, 23 Jan 2013 17:29:58 +0530 Message-ID: To: sitaraman@nmsworks.co.in Content-Type: multipart/alternative; boundary=f46d042f9f9a2f8e9204d3f37067 Cc: "openflow-discuss@mailman.stanford.edu" , "sdn@irtf.org" Subject: Re: [Sdn] SDN and Reinforced Concrete X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 12:00:20 -0000 --f46d042f9f9a2f8e9204d3f37067 Content-Type: text/plain; charset=ISO-8859-1 Dear Sitaraman, You have written so many things and drawn so many analogies, but somehow I could not understand - call it my ignorance. I read your mail a couple of times. I am sorry to say that I could not get the point you are trying to make. Can you summarize and be a bit more specific? Best Regards, Rana Pratap Sircar GSM+919899003705| On 23 January 2013 15:51, wrote: > The industry has always been toying around with connection oriented and > connectionless. IP - Connectionless, TCP - Connection, MPLS/IP Connection, > Optical Networks - Connection, ASON - Connectionless Nature. > While IP moves towards connectionless Optical is moving towards a > connection oriented nature. > It is sort of like the uncertainty principle, if you are sure you are > going to be able to deliver a given traffic matrix, you are not sure when > and if you hit a problem, you are going to completely loose the ability > to delvier (Connection), on the other hand, if your network is best > effort and connectionless you are not sure of the traffic demand matrix > that can be met more sure of delivery of what is possible when something > goes wrong. > Connectionless enables sophisticated control that makes it easier to > (re)configure reachability for traffic, the control, [from the > operations perspective], but the forwarding itself is more more complex > (ip routing table lookups). In the Connection oriented the control [from > the network operations perspective] is more involved (there are less > automated algorithmic protocols doing the work for you) but the > forwarding is easier. Perhaps it is no wonder each is looking at the > other side as a greener pasture. > SDN it appears could be the sweet spot. The decoupling of the control > from the forwarding means that the connectionless-connection oriented > nature of the network itself could be configurabile! We have > configurability at the higher order....We now have configurability of > the configurability of the network. Does this have implications in the > kind of optimizations that are possible, surely, optimization > possibilities could be more powerful in a dynamic graph as opposed to a > less dynamic graph for any given traffic demand graph. This is > something similar to Composites in the Materials world, SDN is perhaps > the Reinforced Concrete of the Civil Engineering world! > Sitaraman > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > --f46d042f9f9a2f8e9204d3f37067 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Sitaram= an,

You have written so many things and drawn so many analogies, but= somehow I could not understand - call it my ignorance. I read your mail = a couple of times. I am sorry to say that I could not get the point you are= trying to make.

Can you summarize and be a bit more specific?
=A0
Best Regards,
Rana Pratap Sircar
GSM+919899003705= |


On 23 January 2013 15:51, <sita= raman@nmsworks.co.in> wrote:


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
sdn mailing list
sdn@irtf.org
htt= ps://www.irtf.org/mailman/listinfo/sdn

--f46d042f9f9a2f8e9204d3f37067-- From sitaraman@nmsworks.co.in Wed Jan 23 04:10:15 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A67621F868B for ; Wed, 23 Jan 2013 04:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrLPli3bH4DB for ; Wed, 23 Jan 2013 04:10:14 -0800 (PST) Received: from indlocal.nmsworks.co.in (indus.nmsworks.co.in [14.140.238.3]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB5D21F8673 for ; Wed, 23 Jan 2013 04:10:14 -0800 (PST) Received: from www.nmsworks.co.in (localhost [127.0.0.1]) by indlocal.nmsworks.co.in (8.13.8/8.13.8) with ESMTP id r0NC8BeA027117; Wed, 23 Jan 2013 17:38:11 +0530 Received: from 192.168.9.56 (SquirrelMail authenticated user sitaraman) by www.nmsworks.co.in with HTTP; Wed, 23 Jan 2013 17:38:11 +0530 (IST) Message-ID: <51990.192.168.9.56.1358942891.squirrel@www.nmsworks.co.in> In-Reply-To: References: <51321.192.168.9.56.1358936516.squirrel@www.nmsworks.co.in> Date: Wed, 23 Jan 2013 17:38:11 +0530 (IST) From: sitaraman@nmsworks.co.in To: "Rana Sircar" User-Agent: SquirrelMail/1.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-NMSWorks-MailScanner-Information: Please contact the ISP for more information X-NMSWorks-MailScanner-ID: r0NC8BeA027117 X-NMSWorks-MailScanner: Found to be clean X-NMSWorks-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.9, required 4, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-NMSWorks-MailScanner-From: sitaraman@nmsworks.co.in Cc: "openflow-discuss@mailman.stanford.edu" , "sdn@irtf.org" Subject: Re: [Sdn] SDN and Reinforced Concrete X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 12:10:15 -0000 Hi Rana, Sorry about the confusion created...but i must admit cant help but be fascinated by the interrelationships and the opportunties to potentially borrow work done in one field to the other where possible. I was trying to bounce the thought that SDN architecture could potentially be used to impart configurability of the connection/connectionless nature of the network. To be specific let us say that a typically well behaved area of a network is undergoing a weather turmoil or something similar, what was connection oriented could temporarily be made connectionless, there may be other such scenarios where this could be warranted. Sitaraman > Dear Sitaraman, > > You have written so many things and drawn so many analogies, but somehow I > could not understand - call it my ignorance. I read your mail a couple of > times. I am sorry to say that I could not get the point you are trying to > make. > > Can you summarize and be a bit more specific? > > Best Regards, > Rana Pratap Sircar > GSM+919899003705| > > > On 23 January 2013 15:51, wrote: > >> The industry has always been toying around with connection oriented and >> connectionless. IP - Connectionless, TCP - Connection, MPLS/IP >> Connection, >> Optical Networks - Connection, ASON - Connectionless Nature. >> While IP moves towards connectionless Optical is moving towards a >> connection oriented nature. >> It is sort of like the uncertainty principle, if you are sure you are >> going to be able to deliver a given traffic matrix, you are not sure >> when >> and if you hit a problem, you are going to completely loose the ability >> to delvier (Connection), on the other hand, if your network is best >> effort and connectionless you are not sure of the traffic demand matrix >> that can be met more sure of delivery of what is possible when something >> goes wrong. >> Connectionless enables sophisticated control that makes it easier to >> (re)configure reachability for traffic, the control, [from the >> operations perspective], but the forwarding itself is more more complex >> (ip routing table lookups). In the Connection oriented the control [from >> the network operations perspective] is more involved (there are less >> automated algorithmic protocols doing the work for you) but the >> forwarding is easier. Perhaps it is no wonder each is looking at the >> other side as a greener pasture. >> SDN it appears could be the sweet spot. The decoupling of the control >> from the forwarding means that the connectionless-connection oriented >> nature of the network itself could be configurabile! We have >> configurability at the higher order....We now have configurability of >> the configurability of the network. Does this have implications in the >> kind of optimizations that are possible, surely, optimization >> possibilities could be more powerful in a dynamic graph as opposed to a >> less dynamic graph for any given traffic demand graph. This is >> something similar to Composites in the Materials world, SDN is perhaps >> the Reinforced Concrete of the Civil Engineering world! >> Sitaraman >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> >> _______________________________________________ >> sdn mailing list >> sdn@irtf.org >> https://www.irtf.org/mailman/listinfo/sdn >> > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From sitaraman@nmsworks.co.in Fri Jan 25 10:18:16 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56AE21F8462 for ; Fri, 25 Jan 2013 10:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPIvA-CIw9xv for ; Fri, 25 Jan 2013 10:18:16 -0800 (PST) Received: from indlocal.nmsworks.co.in (nmsworks.co.in [14.140.238.3]) by ietfa.amsl.com (Postfix) with ESMTP id B760321F8445 for ; Fri, 25 Jan 2013 10:18:05 -0800 (PST) Received: from www.nmsworks.co.in (localhost [127.0.0.1]) by indlocal.nmsworks.co.in (8.13.8/8.13.8) with ESMTP id r0PIG0QV006601 for ; Fri, 25 Jan 2013 23:46:01 +0530 Received: from 117.193.197.199 (SquirrelMail authenticated user sitaraman) by www.nmsworks.co.in with HTTP; Fri, 25 Jan 2013 23:46:01 +0530 (IST) Message-ID: <54214.117.193.197.199.1359137761.squirrel@www.nmsworks.co.in> Date: Fri, 25 Jan 2013 23:46:01 +0530 (IST) From: sitaraman@nmsworks.co.in To: sdn@irtf.org User-Agent: SquirrelMail/1.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-NMSWorks-MailScanner-Information: Please contact the ISP for more information X-NMSWorks-MailScanner-ID: r0PIG0QV006601 X-NMSWorks-MailScanner: Found to be clean X-NMSWorks-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.9, required 4, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-NMSWorks-MailScanner-From: sitaraman@nmsworks.co.in Subject: [Sdn] Semantic Stnadardization X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 18:18:16 -0000 We had Vint Cerf himself visit and talk to us today evening. Amongst others, he highlighted to us Openflow and SDN allowing routing based on content in addition to headers. My immediate reaction was question that this being an antithesis to standardization.....then Vint mentioned an example about routing based on charactersitics of the data and routers selectively choosing to listen (per my understanding of what Vint said, not certain i got it entirely.) Could we say that the conventional protocols are more leaning towards syntactic standardization (Bits in header fields have tightly defined ranges and constructs). Has Semantic standardization, pattern matching been done before at IETF/IRTF? Any relationship to Ontologies? ARe the implications to correctness, convergence, routing loops and such of algorithms in this context been formally studied? Would it make sense to start halfway and have two header components, one decided by the protocol and the other header components contents decided by the application itself (this will form a special part of the data). yet this part of the data being in a well defined restricted area of the data..is this beginning to look like optical network framing where frame at one layer is data for the other? Combine this with NMS based routing, (decoupled control of SDN) SDN is beginning to get a lot of the charactersitics of Optical then? Sitaraman -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From dmm@1-4-5.net Fri Jan 25 10:24:20 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9C921F8445 for ; Fri, 25 Jan 2013 10:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTIKGq5Jn+li for ; Fri, 25 Jan 2013 10:24:13 -0800 (PST) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE9A21F8570 for ; Fri, 25 Jan 2013 10:24:12 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id j14so1197189lbo.24 for ; Fri, 25 Jan 2013 10:24:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=+6yuat+vx2hK26u7zkaUexYqjIGxAXzoW3ysk7LEAXg=; b=k2X2yZ9v2nlCXyu58cZRSfjqF9Ihh3CVDzwfJdQ/4W42Kkbk6mEgNY/UNS6Qs0MFm0 lCtib/J+rO3QV5FZ8rg9SxsIXyh8yJc/jGCeWYTnf5yV4aiExRHeE1nzq5hu3RI354qt rxWFKU5qRTL1pu9SWyYB0LJe03+WheSpnfWKB4beTr2HQc4HBrHTdwMuczUqC2YDN+ti yvsX9Wz/1JQxJKrXOdfqfANhVhDCTpSfRYuNQv6zDU4MydnXBFtMfuBg4SI1rBH+RPZQ cU/9PU0hvGLhXUtGQPCxoAA8Y3xPjcePefoW0qkRsL5Dyg5gztqcS+Lr0PVQBNl4NnpG V0wQ== MIME-Version: 1.0 X-Received: by 10.152.131.137 with SMTP id om9mr5915424lab.18.1359138251727; Fri, 25 Jan 2013 10:24:11 -0800 (PST) Received: by 10.112.2.4 with HTTP; Fri, 25 Jan 2013 10:24:11 -0800 (PST) X-Originating-IP: [98.234.99.22] In-Reply-To: <53935.117.193.197.199.1359137334.squirrel@www.nmsworks.co.in> References: <53935.117.193.197.199.1359137334.squirrel@www.nmsworks.co.in> Date: Fri, 25 Jan 2013 10:24:11 -0800 Message-ID: From: David Meyer To: sitaraman@nmsworks.co.in Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkpqJviQ6OoAbshsZ7yz7m0k/MqWh1T/TDmZFvxwY+LUfLtySSJslKqQMW/fcQBDyx4DJ3j Cc: SDN IRTF list , "sdn@irtf.org openflow-discuss@mailman.stanford.edu" Subject: Re: [Sdn] [openflow-discuss] Semantic Stnadardization X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 18:24:20 -0000 [not sure which lists you were trying to post to, so I added sdn@irtf.org] I'll just note here as a general comment that part of the success (and really, beauty) of the IP architecture is its inherent simplicity. If SDN becomes a dumping ground for *gratuitous* complexity (as we are currently seeing in many venues) then it will fail. --dmm On Fri, Jan 25, 2013 at 10:08 AM, wrote: > We had Vint Cerf himself visit and talk to us today evening. > Amongst others, he highlighted to us Openflow and SDN allowing routing > based on content in addition to headers. > My immediate reaction was question that this being an antithesis to > standardization.....then Vint mentioned an example about routing based on > charactersitics of the data and routers selectively choosing to listen > (per my understanding of what Vint said, not certain i got it entirely.) > Could we say that the conventional protocols are more leaning towards > syntactic standardization (Bits in header fields have tightly defined > ranges and constructs). > Has Semantic standardization, pattern matching been done before at > IETF/IRTF? > Any relationship to Ontologies? > ARe the implications to correctness, convergence, routing loops and such > of algorithms in this context been formally studied? > Would it make sense to start halfway and have two header components, one > decided by the protocol and the other header components contents decided > by the application itself (this will form a special part of the data). > yet this part of the data being in a well defined restricted area of the > data..is this beginning to look like optical network framing where frame > at one layer is data for the other? Combine this with NMS based routing, > (decoupled control of SDN) SDN is beginning to get a lot of the > charactersitics of Optical then? > Sitaraman > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > openflow-discuss mailing list > openflow-discuss@lists.stanford.edu > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss From sitaraman@nmsworks.co.in Fri Jan 25 10:34:58 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C67F21F8432 for ; Fri, 25 Jan 2013 10:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzPdEeMgZOnQ for ; Fri, 25 Jan 2013 10:34:57 -0800 (PST) Received: from indlocal.nmsworks.co.in (nmsworks.co.in [14.140.238.3]) by ietfa.amsl.com (Postfix) with ESMTP id DD64821F88CA for ; Fri, 25 Jan 2013 10:34:56 -0800 (PST) Received: from www.nmsworks.co.in (localhost [127.0.0.1]) by indlocal.nmsworks.co.in (8.13.8/8.13.8) with ESMTP id r0PIWlVW006914; Sat, 26 Jan 2013 00:02:48 +0530 Received: from 117.193.197.199 (SquirrelMail authenticated user sitaraman) by www.nmsworks.co.in with HTTP; Sat, 26 Jan 2013 00:02:49 +0530 (IST) Message-ID: <54508.117.193.197.199.1359138769.squirrel@www.nmsworks.co.in> In-Reply-To: References: <53935.117.193.197.199.1359137334.squirrel@www.nmsworks.co.in> Date: Sat, 26 Jan 2013 00:02:49 +0530 (IST) From: sitaraman@nmsworks.co.in To: "David Meyer" User-Agent: SquirrelMail/1.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-NMSWorks-MailScanner-Information: Please contact the ISP for more information X-NMSWorks-MailScanner-ID: r0PIWlVW006914 X-NMSWorks-MailScanner: Found to be clean X-NMSWorks-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.9, required 4, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-NMSWorks-MailScanner-From: sitaraman@nmsworks.co.in Cc: SDN IRTF list , "sdn@irtf.org openflow-discuss@mailman.stanford.edu" , sitaraman@nmsworks.co.in Subject: Re: [Sdn] [openflow-discuss] Semantic Stnadardization X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 18:34:58 -0000 I believe in one thing... simplicity must always occur as a result of addressing and hiding complexity, there is no free lunch as they say, simplicity in itself without someone somewhere identifying, addressing and hiding for the clients, the complexity...well simply will have true little true value addition is what i feel...simplicity is for the users complexity is for the designers....the more the complexity is identified and addressed, the more the world will enjoy simplicity as a result.... Sitaraman > [not sure which lists you were trying to post to, so I added sdn@irtf.org] > > > I'll just note here as a general comment that part of the success (and > really, beauty) of the IP architecture is its inherent simplicity. If > SDN becomes a dumping ground for *gratuitous* complexity (as we are > currently seeing in many venues) then it will fail. > > --dmm > > > On Fri, Jan 25, 2013 at 10:08 AM, wrote: >> We had Vint Cerf himself visit and talk to us today evening. >> Amongst others, he highlighted to us Openflow and SDN allowing routing >> based on content in addition to headers. >> My immediate reaction was question that this being an antithesis to >> standardization.....then Vint mentioned an example about routing based >> on >> charactersitics of the data and routers selectively choosing to listen >> (per my understanding of what Vint said, not certain i got it entirely.) >> Could we say that the conventional protocols are more leaning towards >> syntactic standardization (Bits in header fields have tightly defined >> ranges and constructs). >> Has Semantic standardization, pattern matching been done before at >> IETF/IRTF? >> Any relationship to Ontologies? >> ARe the implications to correctness, convergence, routing loops and >> such >> of algorithms in this context been formally studied? >> Would it make sense to start halfway and have two header components, >> one >> decided by the protocol and the other header components contents decided >> by the application itself (this will form a special part of the data). >> yet this part of the data being in a well defined restricted area of the >> data..is this beginning to look like optical network framing where frame >> at one layer is data for the other? Combine this with NMS based routing, >> (decoupled control of SDN) SDN is beginning to get a lot of the >> charactersitics of Optical then? >> Sitaraman >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> >> _______________________________________________ >> openflow-discuss mailing list >> openflow-discuss@lists.stanford.edu >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From sbarkai@gmail.com Fri Jan 25 11:34:11 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B5621F853C for ; Fri, 25 Jan 2013 11:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.804 X-Spam-Level: X-Spam-Status: No, score=-1.804 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTvSQPbbhkuI for ; Fri, 25 Jan 2013 11:34:10 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id C0E3121F841A for ; Fri, 25 Jan 2013 11:34:10 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so905968oag.31 for ; Fri, 25 Jan 2013 11:34:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=hsxPZ/QcyVryPmud4GmQ5mmqrOrMSadyIX71PHI8QDI=; b=on6mV2vO25LA7ab9ZGspA+AGZ6AiKJ4/qWmedDoWqWvOovUJuCxjeVcftBFUjXq1AY anytWQgB3NKPNpyFdoxBFCXnkmBijc72loy96znwFSKDWkSfohZLG+P5n3wy7MW/+lka odgw5dGcc2u7pTmrv0MsuGNFza4H6hoCRhJal7cHWabzIQJ4UHx/gzWs7m5dV3E/hhuL CSkK8ov0y8qU4gg7FlUSQRGs9nZdXvw28waQopF6+JTywiCMQrBg2srDQJPQ3D4fIYi0 IzkNzAOHYaE1ttZllNM3J3/uevOAY7MEcjJMmicmOrdjfYrzrmbgHjkOFmyT8QpFhukk FzQw== X-Received: by 10.60.31.39 with SMTP id x7mr5510078oeh.45.1359142450188; Fri, 25 Jan 2013 11:34:10 -0800 (PST) Received: from [192.168.1.73] (108-214-96-27.lightspeed.sntcca.sbcglobal.net. [108.214.96.27]) by mx.google.com with ESMTPS id oj8sm1307395obb.3.2013.01.25.11.34.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jan 2013 11:34:09 -0800 (PST) References: <53935.117.193.197.199.1359137334.squirrel@www.nmsworks.co.in> <54508.117.193.197.199.1359138769.squirrel@www.nmsworks.co.in> In-Reply-To: <54508.117.193.197.199.1359138769.squirrel@www.nmsworks.co.in> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (10A550) From: Sharon Date: Fri, 25 Jan 2013 11:34:06 -0800 To: "sitaraman@nmsworks.co.in" Cc: David Meyer , "sdn@irtf.org openflow-discuss@mailman.stanford.edu" , SDN IRTF list , "sitaraman@nmsworks.co.in" Subject: Re: [Sdn] [openflow-discuss] Semantic Stnadardization X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 19:34:11 -0000 Right, but designers (there's lots) could use a few simple ground rules. Flows - have always been a part of switch-router designs, time to open them up for programming, in itself not a trivial task - as can be seen from the various bug queries in this list. Overlays - well, at least you know they don't break basic connectivity, rather they use it and interject additional logic in well defined edge point= s. Global awareness - that's the most tricky part, it could use a simple definition and a resilient structure of how it's used and how it works. "Controller" isn't such a definition. On Jan 25, 2013, at 10:32, sitaraman@nmsworks.co.in wrote: I believe in one thing... simplicity must always occur as a result of addressing and hiding complexity, there is no free lunch as they say, simplicity in itself without someone somewhere identifying, addressing and hiding for the clients, the complexity...well simply will have true little true value addition is what i feel...simplicity is for the users complexity is for the designers....the more the complexity is identified and addressed, the more the world will enjoy simplicity as a result.... Sitaraman > [not sure which lists you were trying to post to, so I added sdn@irtf.org]= >=20 >=20 > I'll just note here as a general comment that part of the success (and > really, beauty) of the IP architecture is its inherent simplicity. If > SDN becomes a dumping ground for *gratuitous* complexity (as we are > currently seeing in many venues) then it will fail. >=20 > --dmm >=20 >=20 > On Fri, Jan 25, 2013 at 10:08 AM, wrote: >> We had Vint Cerf himself visit and talk to us today evening. >> Amongst others, he highlighted to us Openflow and SDN allowing routing >> based on content in addition to headers. >> My immediate reaction was question that this being an antithesis to >> standardization.....then Vint mentioned an example about routing based >> on >> charactersitics of the data and routers selectively choosing to listen >> (per my understanding of what Vint said, not certain i got it entirely.) >> Could we say that the conventional protocols are more leaning towards >> syntactic standardization (Bits in header fields have tightly defined >> ranges and constructs). >> Has Semantic standardization, pattern matching been done before at >> IETF/IRTF? >> Any relationship to Ontologies? >> ARe the implications to correctness, convergence, routing loops and >> such >> of algorithms in this context been formally studied? >> Would it make sense to start halfway and have two header components, >> one >> decided by the protocol and the other header components contents decided >> by the application itself (this will form a special part of the data). >> yet this part of the data being in a well defined restricted area of the >> data..is this beginning to look like optical network framing where frame >> at one layer is data for the other? Combine this with NMS based routing, >> (decoupled control of SDN) SDN is beginning to get a lot of the >> charactersitics of Optical then? >> Sitaraman >>=20 >>=20 >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >>=20 >> _______________________________________________ >> openflow-discuss mailing list >> openflow-discuss@lists.stanford.edu >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >=20 > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ sdn mailing list sdn@irtf.org https://www.irtf.org/mailman/listinfo/sdn From sitaraman@nmsworks.co.in Fri Jan 25 19:14:06 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B514721F84F9 for ; Fri, 25 Jan 2013 19:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62iDPBLc61nQ for ; Fri, 25 Jan 2013 19:14:05 -0800 (PST) Received: from indlocal.nmsworks.co.in (indus.nmsworks.co.in [14.140.238.3]) by ietfa.amsl.com (Postfix) with ESMTP id 3C18A21F845F for ; Fri, 25 Jan 2013 19:14:05 -0800 (PST) Received: from www.nmsworks.co.in (localhost [127.0.0.1]) by indlocal.nmsworks.co.in (8.13.8/8.13.8) with ESMTP id r0Q3Bn5G015209; Sat, 26 Jan 2013 08:41:49 +0530 Received: from 115.242.129.156 (SquirrelMail authenticated user sitaraman) by www.nmsworks.co.in with HTTP; Sat, 26 Jan 2013 08:41:51 +0530 (IST) Message-ID: <49426.115.242.129.156.1359169911.squirrel@www.nmsworks.co.in> In-Reply-To: References: <53935.117.193.197.199.1359137334.squirrel@www.nmsworks.co.in> <54508.117.193.197.199.1359138769.squirrel@www.nmsworks.co.in> Date: Sat, 26 Jan 2013 08:41:51 +0530 (IST) From: sitaraman@nmsworks.co.in To: "Sharon" User-Agent: SquirrelMail/1.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-NMSWorks-MailScanner-Information: Please contact the ISP for more information X-NMSWorks-MailScanner-ID: r0Q3Bn5G015209 X-NMSWorks-MailScanner: Found to be clean X-NMSWorks-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.9, required 4, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-NMSWorks-MailScanner-From: sitaraman@nmsworks.co.in Cc: David Meyer , "sdn@irtf.org openflow-discuss@mailman.stanford.edu" , SDN IRTF list , "sitaraman@nmsworks.co.in" Subject: Re: [Sdn] [openflow-discuss] Semantic Stnadardization X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 03:14:06 -0000 Agreed, By programmable flows, if i understand correctly what you are referring to is applications programmable flows (else flows have always been programmed...). This pushes complexity up into the application layer, which challenges if identified and adrressed could result in powerful paradigms in networking and its operations (self -*?) IRTF could address these... What are flow decisions applications would like to make an OSS system specould be one eager candidate for the same (maybe work with TMF on it...)s? Overlays can be good and bad, good for backward compatibility, scaling, bad for the certain rigidity it brings to the architecture...yes, overlays in one aspect (control) could lead to a homogenization in the other (flows) and possible vice versa. Related to global awareness, Vint gave a couple of examples yesterday, dealing with context awareness...in making speech recongintion tractable, and wearable computers....This is a powerful concept indeed...and application controlled flows allows precisely this, to bring context awareness into routing decisions...it is like the applications are walking around wearing routers on their heads! Wearable routers for applications! I wonder if defintion should come before conceptualization or the other way around...maybe it should be overlayed, when and at what point....? Sitaraman > Right, but designers (there's lots) could use a few simplec grorund rules. > > Flows have always been a part of switch-router designs, > time to open them up for programming, in itself not a trivial task - > as can be seen from the various bug queries in this list. > > Overlays - well, at least youi know they don't break basic connectivity, > rather they use it and interject additional logic in well defined edge > points. > > Global awareness - that's the most tricky part, it could use a simple > definition and a resilient structure of how it's used and how it works. > "Controller" isn't such a definition. > > > On Jan 25, 2013, at 10:32, sitaraman@nmsworks.co.in wrote: > > I believe in one thing... > simplicity must always occur as a result of addressing and hiding > complexity, there is no free lunch as they say, simplicity in itself > without someone somewhere identifying, addressing and hiding for the > clients, the complexity...well simply will have true little true value > addition is what i feel...simplicity is for the users complexity is for > the designers....the more the complexity is identified and addressed, the > more the world will enjoy simplicity as a result.... > Sitaraman >> [not sure which lists you were trying to post to, so I added >> sdn@irtf.org] >> >> >> I'll just note here as a general comment that part of the success (and >> really, beauty) of the IP architecture is its inherent simplicity. If >> SDN becomes a dumping ground for *gratuitous* complexity (as we are >> currently seeing in many venues) then it will fail. >> >> --dmm >> >> >> On Fri, Jan 25, 2013 at 10:08 AM, wrote: >>> We had Vint Cerf himself visit and talk to us today evening. >>> Amongst others, he highlighted to us Openflow and SDN allowing routing >>> based on content in addition to headers. >>> My immediate reaction was question that this being an antithesis to >>> standardization.....then Vint mentioned an example about routing based >>> on >>> charactersitics of the data and routers selectively choosing to listen >>> (per my understanding of what Vint said, not certain i got it >>> entirely.) >>> Could we say that the conventional protocols are more leaning towards >>> syntactic standardization (Bits in header fields have tightly defined >>> ranges and constructs). >>> Has Semantic standardization, pattern matching been done before at >>> IETF/IRTF? >>> Any relationship to Ontologies? >>> ARe the implications to correctness, convergence, routing loops and >>> such >>> of algorithms in this context been formally studied? >>> Would it make sense to start halfway and have two header components, >>> one >>> decided by the protocol and the other header components contents >>> decided >>> by the application itself (this will form a special part of the data). >>> yet this part of the data being in a well defined restricted area of >>> the >>> data..is this beginning to look like optical network framing where >>> frame >>> at one layer is data for the other? Combine this with NMS based >>> routing, >>> (decoupled control of SDN) SDN is beginning to get a lot of the >>> charactersitics of Optical then? >>> Sitaraman >>> >>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >>> >>> _______________________________________________ >>> openflow-discuss mailing list >>> openflow-discuss@lists.stanford.edu >>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From sitaraman@nmsworks.co.in Fri Jan 25 21:45:33 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B8721F8319 for ; Fri, 25 Jan 2013 21:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[AWL=-1.234, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDfEYue0V4JV for ; Fri, 25 Jan 2013 21:45:31 -0800 (PST) Received: from indlocal.nmsworks.co.in (indus.nmsworks.co.in [14.140.238.3]) by ietfa.amsl.com (Postfix) with ESMTP id 9997521F8233 for ; Fri, 25 Jan 2013 21:45:30 -0800 (PST) Received: from www.nmsworks.co.in (localhost [127.0.0.1]) by indlocal.nmsworks.co.in (8.13.8/8.13.8) with ESMTP id r0Q5hJEa018626; Sat, 26 Jan 2013 11:13:19 +0530 Received: from 117.193.217.245 (SquirrelMail authenticated user sitaraman) by www.nmsworks.co.in with HTTP; Sat, 26 Jan 2013 11:13:21 +0530 (IST) Message-ID: <49892.117.193.217.245.1359179001.squirrel@www.nmsworks.co.in> In-Reply-To: References: <53935.117.193.197.199.1359137334.squirrel@www.nmsworks.co.in> Date: Sat, 26 Jan 2013 11:13:21 +0530 (IST) From: sitaraman@nmsworks.co.in To: "David Meyer" User-Agent: SquirrelMail/1.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-NMSWorks-MailScanner-Information: Please contact the ISP for more information X-NMSWorks-MailScanner-ID: r0Q5hJEa018626 X-NMSWorks-MailScanner: Found to be clean X-NMSWorks-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.327, required 4, ALL_TRUSTED -1.00, BAYES_00 -1.90, URG_BIZ 0.57) X-NMSWorks-MailScanner-From: sitaraman@nmsworks.co.in Cc: "sdn@irtf.org openflow-discuss@mailman.stanford.edu" , SDN IRTF list Subject: Re: [Sdn] [openflow-discuss] Semantic Stnadardization X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 05:45:33 -0000 On the content based routing...we could look at standardizing things like for example, content fields where data or downloads are requested or scheduled. OSS applications can go more real time and perform traffic engineering based on this by rerouting, reallocaiton of resources. Vint was mentioning to us yesterday that it is not so much the amount of data requested but the temporal nature of the same. This means of temporal nature of requests could also be standardized for benefit (scheduled interchange of data in organizations, relatively long on demand downloads...) Would you consider this as a reasonable benefit for an application that warrants study of the possible complexities involved. Another aspect that was discussed was charging based on the rate not the absolute bandwidth used. Facilities such as the above will allow service providers a means to provide subscirbers automated optimizations to schedule non urgent requests at lean times to a) reduce the cost to customers, b)optimize their own use of network to increase customer base. Would this warrant identifying, addressing and study of the complexities involved as opposed to being "gratuitous" Sitaraman > [not sure which lists you were trying to post to, so I added sdn@irtf.org] > > > I'll just note here as a general comment that part of the success (and > really, beauty) of the IP architecture is its inherent simplicity. If > SDN becomes a dumping ground for *gratuitous* complexity (as we are > currently seeing in many venues) then it will fail. > > --dmm > > > On Fri, Jan 25, 2013 at 10:08 AM, wrote: >> We had Vint Cerf himself visit and talk to us today evening. >> Amongst others, he highlighted to us Openflow and SDN allowing routing >> based on content in addition to headers. >> My immediate reaction was question that this being an antithesis to >> standardization.....then Vint mentioned an example about routing based >> on >> charactersitics of the data and routers selectively choosing to listen >> (per my understanding of what Vint said, not certain i got it entirely.) >> Could we say that the conventional protocols are more leaning towards >> syntactic standardization (Bits in header fields have tightly defined >> ranges and constructs). >> Has Semantic standardization, pattern matching been done before at >> IETF/IRTF? >> Any relationship to Ontologies? >> ARe the implications to correctness, convergence, routing loops and >> such >> of algorithms in this context been formally studied? >> Would it make sense to start halfway and have two header components, >> one >> decided by the protocol and the other header components contents decided >> by the application itself (this will form a special part of the data). >> yet this part of the data being in a well defined restricted area of the >> data..is this beginning to look like optical network framing where frame >> at one layer is data for the other? Combine this with NMS based routing, >> (decoupled control of SDN) SDN is beginning to get a lot of the >> charactersitics of Optical then? >> Sitaraman >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> >> _______________________________________________ >> openflow-discuss mailing list >> openflow-discuss@lists.stanford.edu >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From dmm@1-4-5.net Mon Jan 28 10:32:50 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A244621F8717 for ; Mon, 28 Jan 2013 10:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcL5T0byJpuT for ; Mon, 28 Jan 2013 10:32:49 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFE321F85B2 for ; Mon, 28 Jan 2013 10:32:49 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id go11so4238246lbb.8 for ; Mon, 28 Jan 2013 10:32:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:content-type:x-gm-message-state; bh=CryBwPLUbjYxd/cekvXaM2JKH9z6WqVzYPRNyvvFvzY=; b=GWjX7rM/mHPqys1S194HHBicOvjUHQgYZIK6vX2bCNA6CXhP2TrPGVunoPlNvmknUw w/mIX/RsiMHbEc8boK1+mJFl499OcGtFju9a58WcdNgPQliIwa+SE8cFbcKDaLO904md c6CrE4D0ugsVKdM1W1zhfcBeHgjoQkPNRqBff2FrbbLIVVHA16IXEGcwpNjS0Nq6ChMf wzj/K5TQKiSBegUVya2tWjL3uX2DwLnPIozeN0X0mHEXAnPelhucjM48anRiplhP9HgI 5/5BBYG3Hdh/n7IMQFbQ9oRWMVxId7+Vc+hD73Aqh3bfUk14FUKDfRi6Slp5LwLlneTD 40lA== MIME-Version: 1.0 X-Received: by 10.152.105.17 with SMTP id gi17mr13880815lab.46.1359397968168; Mon, 28 Jan 2013 10:32:48 -0800 (PST) Received: by 10.112.2.4 with HTTP; Mon, 28 Jan 2013 10:32:48 -0800 (PST) X-Originating-IP: [144.49.132.3] In-Reply-To: References: Date: Mon, 28 Jan 2013 10:32:48 -0800 Message-ID: From: David Meyer To: SDN IRTF list Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk5Pj1Z7KvhTAus2iVJ0bfybPk2iaDvgDlDN0SXHbagziGiecSapuEHvCa6Jr9TYEzfC/E3 Subject: [Sdn] HotSDN 2013 - Call for Papers X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 18:32:50 -0000 [http://conferences.sigcomm.org/sigcomm/2013/hotsdn.php] ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking (HotSDN) Co-located with ACM SIGCOMM'13 August 16th, 2013 Hong Kong, China Introduction Software defined networking (SDN) refactors the relationship between network devices and the software that controls them. Opening up the interfaces to programming network hardware enables more flexible and predictable network control, and makes it easier to extend the network with new functionality. In recent years, a number of vendors have introduced development kits for programming their devices, and several commercial switches now support the OpenFlow standard. Researchers have proposed new applications that execute on top of a software defined network, including dynamic access control, server load balancing, energy-efficient networking, seamless client mobility, and virtual-machine migration. And deployments of software defined networks have appeared in experimental and production environments. But despite the recent progress in this area, many important research questions remain: How do we design switches and programming interfaces that offer greater flexibility without compromising performance? How do we design software platforms for managing software defined networks? How do we design new applications that capitalize on the programmability of the network? How do we lower the barrier to creating, testing, and evaluating new applications? How do we transition existing networks? How can a software defined network interoperate with existing protocols and devices? The goal of the HotSDN workshop is to explore recent research and developments related to software defined networks, to encourage broad interaction between industry and academia, and to help build a wider community to explore and realize the potential of software defined networks. Topics We encourage submission of both position papers and work-in-progress papers on software defined networking. We solicit previously unpublished work on topics including, but not limited to the following: * Applications of software defined networking to home, wireless, cellular, enterprise, data-center, and backbone networks * Applications of software defined networking to network management, monitoring, security, etc. * Virtual appliances (e.g., firewalls, intrusion detection systems, load balancers, etc.) built using software-defined networks * Virtualization in software defined networks * Switch designs for software defined networks * Application programming interfaces for software defined networks * Control and management software for software defined networks * Programming languages, verification techniques, and tools for software defined networks * Performance evaluation of switches and controllers for software defined networks * Experiences deploying software defined networking technology and applications in operational networks * Hybrid software defined networking approaches * Transitioning existing networks to software defined networking * Placement and factoring of software defined networking control logic * Distributed systems abstractions for managing switches and controllers in software defined networks Submission Instructions Each submission must be a single PDF file no longer than six (6) pages in length (in two-column, 10-point format) including references, following the alternate ACM SIG LaTeX style file. Papers should be submitted electronically via the submission site: http://hotsdn2013.cs.cornell.edu Papers must include the author name and affiliation for single-blind peer reviewing by the program committee. Accepted papers will be published in the ACM Digital Library. Publication at HotSDN is not intended to preclude later publication. Authors of accepted papers are expected to present their papers at the workshop. Important Dates Abstract registration: March 18, 2013 Submissions due: March 25, 2013 Notification: April 29, 2013 Camera ready versions due: May 31, 2013 Workshop date: August 16, 2013 PC Co-chairs Nate Foster (Cornell) Rob Sherwood (Big Switch Networks) PC Members Aditya Akella (Wisconsin) Marco Canini (TU Berlin & Telekom Innovation Laboratories) Martin Cascado (VMware) Matt Davy (Indiana) Nick Feamster (Georgia Tech) Anja Feldmann (TU Berlin & Telekom Innovation Laboratories) Nate Foster (Cornell) Yashar Ganjali (Toronto) Brighten Godfrey (Illinois) Nikhil Handigol (Stanford) Brandon Heller (Stanford) Sachin Katti (Stanford) Eric Keller (Colorado) Dejan Kostic (IMDEA Networks) Anil Madhavapeddy (Cambridge) Nick McKeown (Stanford) David Meyer (Brocade) Jennifer Rexford (Princeton) Christian Esteve Rothenberg (CPqD & Unicamp) Rob Sherwood (Big Switch) Ruslan Smeliansky (Moscow State) Dave Ward (Cisco) Minlan Yu (USC) From sitaraman@nmsworks.co.in Wed Jan 30 01:07:23 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B911821F8457 for ; Wed, 30 Jan 2013 01:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.687 X-Spam-Level: X-Spam-Status: No, score=-0.687 tagged_above=-999 required=5 tests=[AWL=-0.998, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VS0aUk0hJCqp for ; Wed, 30 Jan 2013 01:07:22 -0800 (PST) Received: from indlocal.nmsworks.co.in (indus.nmsworks.co.in [14.140.238.3]) by ietfa.amsl.com (Postfix) with ESMTP id EEB3421F844A for ; Wed, 30 Jan 2013 01:07:07 -0800 (PST) Received: from www.nmsworks.co.in (localhost [127.0.0.1]) by indlocal.nmsworks.co.in (8.13.8/8.13.8) with ESMTP id r0U92pTu013487; Wed, 30 Jan 2013 14:32:51 +0530 Received: from 192.168.9.56 (SquirrelMail authenticated user sitaraman) by www.nmsworks.co.in with HTTP; Wed, 30 Jan 2013 14:32:52 +0530 (IST) Message-ID: <50173.192.168.9.56.1359536572.squirrel@www.nmsworks.co.in> In-Reply-To: <49892.117.193.217.245.1359179001.squirrel@www.nmsworks.co.in> References: <53935.117.193.197.199.1359137334.squirrel@www.nmsworks.co.in> <49892.117.193.217.245.1359179001.squirrel@www.nmsworks.co.in> Date: Wed, 30 Jan 2013 14:32:52 +0530 (IST) From: sitaraman@nmsworks.co.in To: sitaraman@nmsworks.co.in User-Agent: SquirrelMail/1.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-NMSWorks-MailScanner-Information: Please contact the ISP for more information X-NMSWorks-MailScanner-ID: r0U92pTu013487 X-NMSWorks-MailScanner: Found to be clean X-NMSWorks-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.327, required 4, ALL_TRUSTED -1.00, BAYES_00 -1.90, URG_BIZ 0.57) X-NMSWorks-MailScanner-From: sitaraman@nmsworks.co.in Cc: David Meyer , "sdn@irtf.org openflow-discuss@mailman.stanford.edu" , SDN IRTF list Subject: Re: [Sdn] [openflow-discuss] Semantic Stnadardization X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 09:07:23 -0000 What SDN buys us, due to its ability fo mess with forwarding directly at the applicaiton layer is to bring in the possibility of Context Awareness of application data for tweaking forwarding decisions. Fundamentally one difference between connection oriented and connectionless is the preemptibility of the paths. Here again, MPLS-TE's LSP set up and hold priority kinds of reaches out to each other. LSPs are connection oriented while giving connectionless like preremiptibiliy to these LSPs. With SDN with its application controlled routing would allow is, therefore, we could consider "Context Aware Premebility" which could be a mix of Connectionless and Connection oriented nature. I see some literature (one of them by John Strassner, i recolect some time ago there was a long thread of discussion on Context Awareness involving John too) on relating Context Awareness to Ontologies too... We could look at IRTF on defining such application controlled dynamic preemptibility configuration while cross technology expression of this capability using Policies perhaps or Policy independent Interfaces is something we could consider at jointly with TMF. Sitaraman > On the content based routing...we could look at standardizing things like > for example, content fields where data or downloads are requested or > scheduled. > > OSS applications can go more real time and perform traffic engineering > based on this by rerouting, reallocaiton of resources. Vint was mentioning > to us yesterday that it is not so much the amount of data requested but > the temporal nature of the same. This means of temporal nature of requests > could also be standardized for benefit (scheduled interchange of data in > organizations, relatively long on demand downloads...) Would you consider > this as a reasonable benefit for an application that warrants study of the > possible complexities involved. > Another aspect that was discussed was charging based on the rate not the > absolute bandwidth used. Facilities such as the above will allow service > providers a means to provide subscirbers automated optimizations to > schedule non urgent requests at lean times to a) reduce the cost to > customers, b)optimize their own use of network to increase customer base. > Would this warrant identifying, addressing and study of the complexities > involved as opposed to being "gratuitous" > > Sitaraman > > >> [not sure which lists you were trying to post to, so I added >> sdn@irtf.org] >> >> >> I'll just note here as a general comment that part of the success (and >> really, beauty) of the IP architecture is its inherent simplicity. If >> SDN becomes a dumping ground for *gratuitous* complexity (as we are >> currently seeing in many venues) then it will fail. >> >> --dmm >> >> >> On Fri, Jan 25, 2013 at 10:08 AM, wrote: >>> We had Vint Cerf himself visit and talk to us today evening. >>> Amongst others, he highlighted to us Openflow and SDN allowing routing >>> based on content in addition to headers. >>> My immediate reaction was question that this being an antithesis to >>> standardization.....then Vint mentioned an example about routing based >>> on >>> charactersitics of the data and routers selectively choosing to listen >>> (per my understanding of what Vint said, not certain i got it >>> entirely.) >>> Could we say that the conventional protocols are more leaning towards >>> syntactic standardization (Bits in header fields have tightly defined >>> ranges and constructs). >>> Has Semantic standardization, pattern matching been done before at >>> IETF/IRTF? >>> Any relationship to Ontologies? >>> ARe the implications to correctness, convergence, routing loops and >>> such >>> of algorithms in this context been formally studied? >>> Would it make sense to start halfway and have two header components, >>> one >>> decided by the protocol and the other header components contents >>> decided >>> by the application itself (this will form a special part of the data). >>> yet this part of the data being in a well defined restricted area of >>> the >>> data..is this beginning to look like optical network framing where >>> frame >>> at one layer is data for the other? Combine this with NMS based >>> routing, >>> (decoupled control of SDN) SDN is beginning to get a lot of the >>> charactersitics of Optical then? >>> Sitaraman >>> >>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >>> >>> _______________________________________________ >>> openflow-discuss mailing list >>> openflow-discuss@lists.stanford.edu >>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >> _______________________________________________ >> sdn mailing list >> sdn@irtf.org >> https://www.irtf.org/mailman/listinfo/sdn >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From stuart.venters@adtran.com Wed Jan 30 08:10:27 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07AE21F88E2 for ; Wed, 30 Jan 2013 08:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.689 X-Spam-Level: X-Spam-Status: No, score=-3.689 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOJR2sClyiWG for ; Wed, 30 Jan 2013 08:10:26 -0800 (PST) Received: from p02c12o149.mxlogic.net (p02c12o149.mxlogic.net [208.65.145.82]) by ietfa.amsl.com (Postfix) with ESMTP id 437AB21F88CC for ; Wed, 30 Jan 2013 08:10:25 -0800 (PST) Received: from unknown [76.164.174.83] (EHLO p02c12o149.mxlogic.net) by p02c12o149.mxlogic.net(mxl_mta-6.16.0-0) with ESMTP id 2f549015.5f600940.107192.00-518.255653.p02c12o149.mxlogic.net (envelope-from ); Wed, 30 Jan 2013 09:10:26 -0700 (MST) X-MXL-Hash: 510945f20e4f9985-1e02f5234b73e891d97ba34b63147e0544ccce22 Received: from unknown [76.164.174.83] by p02c12o149.mxlogic.net(mxl_mta-6.16.0-0) with SMTP id 5e549015.0.107091.00-281.255384.p02c12o149.mxlogic.net (envelope-from ); Wed, 30 Jan 2013 09:10:23 -0700 (MST) X-MXL-Hash: 510945ef4c440544-bba0ca88462ad18ba64031c2402b14f5f367a4ce Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc2.corp.adtran.com ([fe80::d50f:ceda:4e38:ebf0%14]) with mapi id 14.01.0438.000; Wed, 30 Jan 2013 10:10:12 -0600 From: STUART VENTERS To: "sitaraman@nmsworks.co.in" Thread-Topic: [Sdn] [openflow-discuss] Semantic Stnadardization Thread-Index: AQHN+yk1PBDe/AXxaESlaxZZIJTWBZhbflyAgAaBEQCAAAh40A== Date: Wed, 30 Jan 2013 16:10:12 +0000 Message-ID: <1220E2C537595D439C5D026E83751866220E18D3@ex-mb1.corp.adtran.com> References: <53935.117.193.197.199.1359137334.squirrel@www.nmsworks.co.in> <49892.117.193.217.245.1359179001.squirrel@www.nmsworks.co.in> <50173.192.168.9.56.1359536572.squirrel@www.nmsworks.co.in> In-Reply-To: <50173.192.168.9.56.1359536572.squirrel@www.nmsworks.co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.113.98] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.0 cv=I+zSsqcg c=1 sm=1 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a] X-AnalysisOut: [=ruWq0YzyRmIA:10 a=qOnlvQC0eOUA:10 a=qZHQZMT3apYA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=eJNrpio] X-AnalysisOut: [GAAAA:8 a=57ZKyp9pAVIA:10 a=YlDpyLmHAAAA:8 a=O9LQIBu0AAAA:] X-AnalysisOut: [8 a=cqvmlmxeAAAA:8 a=b19dvbW44PzqAezmVUAA:9 a=CjuIK1q_8ugA] X-AnalysisOut: [:10 a=WZiKUSCcF5cA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] Cc: SDN IRTF list Subject: Re: [Sdn] [openflow-discuss] Semantic Stnadardization X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 16:10:27 -0000 Sitarman, I'm confused/bugged by the statement 'Fundamentally one difference between = connection oriented and connectionless is the preemptibility of the paths' I wonder if we are mixing (or redefining?) two concepts I thought I knew. 1) The concept of connection versus connection-less. An example is the di= fference between TCP and UDP, which is more about protocols at the edge tha= n things in the middle. 2) The concept of dedicated versus statistical (shared) bandwidth. An ex= ample is the difference between CBR and UBR or between a leased tdm circuit= and an Internet route. These are more about things in the middle like rou= ting or who gets to use the tx port when. SDN seems likely to be about managing the middle for the benefit of stuff a= t the edge so I assume you are thinking more about the middle. Perhaps I s= hould read your statement 'Fundamentally one difference between is the preemptibility of the paths'? Regards, Stuart -----Original Message----- From: sdn-bounces@irtf.org [mailto:sdn-bounces@irtf.org] On Behalf Of sitar= aman@nmsworks.co.in Sent: Wednesday, January 30, 2013 3:03 AM To: sitaraman@nmsworks.co.in Cc: David Meyer; sdn@irtf.org openflow-discuss@mailman.stanford.edu; SDN IR= TF list Subject: Re: [Sdn] [openflow-discuss] Semantic Stnadardization What SDN buys us, due to its ability fo mess with forwarding directly at th= e applicaiton layer is to bring in the possibility of Context Awareness of = application data for tweaking forwarding decisions. Fundamentally one difference between connection oriented and connectionles= s is the preemptibility of the paths. Here again, MPLS-TE's LSP set up and = hold priority kinds of reaches out to each other. LSPs are connection orien= ted while giving connectionless like preremiptibiliy to these LSPs. With SDN with its application controlled routing would allow is, therefore,= we could consider "Context Aware Premebility" which could be a mix of Conn= ectionless and Connection oriented nature. I see some literature (one of them by John Strassner, i recolect some time = ago there was a long thread of discussion on Context Awareness involving Jo= hn too) on relating Context Awareness to Ontologies too... We could look at IRTF on defining such application controlled dynamic preem= ptibility configuration while cross technology expression of this capabilit= y using Policies perhaps or Policy independent Interfaces is something we c= ould consider at jointly with TMF. Sitaraman > On the content based routing...we could look at standardizing things > like for example, content fields where data or downloads are requested > or scheduled. > > OSS applications can go more real time and perform traffic engineering > based on this by rerouting, reallocaiton of resources. Vint was > mentioning to us yesterday that it is not so much the amount of data > requested but the temporal nature of the same. This means of temporal > nature of requests could also be standardized for benefit (scheduled > interchange of data in organizations, relatively long on demand > downloads...) Would you consider this as a reasonable benefit for an > application that warrants study of the possible complexities involved. > Another aspect that was discussed was charging based on the rate not > the absolute bandwidth used. Facilities such as the above will allow > service providers a means to provide subscirbers automated > optimizations to schedule non urgent requests at lean times to a) > reduce the cost to customers, b)optimize their own use of network to incr= ease customer base. > Would this warrant identifying, addressing and study of the > complexities involved as opposed to being "gratuitous" > > Sitaraman > > >> [not sure which lists you were trying to post to, so I added >> sdn@irtf.org] >> >> >> I'll just note here as a general comment that part of the success >> (and really, beauty) of the IP architecture is its inherent >> simplicity. If SDN becomes a dumping ground for *gratuitous* >> complexity (as we are currently seeing in many venues) then it will fail= . >> >> --dmm >> >> >> On Fri, Jan 25, 2013 at 10:08 AM, wrote: >>> We had Vint Cerf himself visit and talk to us today evening. >>> Amongst others, he highlighted to us Openflow and SDN allowing >>> routing based on content in addition to headers. >>> My immediate reaction was question that this being an antithesis to >>> standardization.....then Vint mentioned an example about routing >>> based on charactersitics of the data and routers selectively >>> choosing to listen (per my understanding of what Vint said, not >>> certain i got it >>> entirely.) >>> Could we say that the conventional protocols are more leaning >>> towards syntactic standardization (Bits in header fields have >>> tightly defined ranges and constructs). >>> Has Semantic standardization, pattern matching been done before at >>> IETF/IRTF? >>> Any relationship to Ontologies? >>> ARe the implications to correctness, convergence, routing loops and >>> such of algorithms in this context been formally studied? >>> Would it make sense to start halfway and have two header >>> components, one decided by the protocol and the other header >>> components contents decided by the application itself (this will >>> form a special part of the data). >>> yet this part of the data being in a well defined restricted area of >>> the data..is this beginning to look like optical network framing >>> where frame at one layer is data for the other? Combine this with >>> NMS based routing, (decoupled control of SDN) SDN is beginning to >>> get a lot of the charactersitics of Optical then? >>> Sitaraman >>> >>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >>> >>> _______________________________________________ >>> openflow-discuss mailing list >>> openflow-discuss@lists.stanford.edu >>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >> _______________________________________________ >> sdn mailing list >> sdn@irtf.org >> https://www.irtf.org/mailman/listinfo/sdn >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ sdn mailing list sdn@irtf.org https://www.irtf.org/mailman/listinfo/sdn From Dirk.Kutscher@neclab.eu Wed Jan 30 08:23:05 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C597E21F8821; Wed, 30 Jan 2013 08:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.689 X-Spam-Level: X-Spam-Status: No, score=-0.689 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExC2EiMTlMPH; Wed, 30 Jan 2013 08:23:03 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0EA21F86F6; Wed, 30 Jan 2013 08:23:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id C1FC9102FA0; Wed, 30 Jan 2013 17:23:01 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzx4vJ8js+ko; Wed, 30 Jan 2013 17:23:01 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id A71C6101B1E; Wed, 30 Jan 2013 17:22:41 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.175]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 30 Jan 2013 17:22:20 +0100 From: Dirk Kutscher To: STUART VENTERS , "sitaraman@nmsworks.co.in" Thread-Topic: [Sdn] [openflow-discuss] Semantic Stnadardization Thread-Index: AQHN+ylEhIxk4BtSVUa3Gxydv+Xi0ZhbCQOAgAaBEgCAAHdlAIAAE4DQ Date: Wed, 30 Jan 2013 16:22:19 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F5249551EC4AD@DAPHNIS.office.hd> References: <53935.117.193.197.199.1359137334.squirrel@www.nmsworks.co.in> <49892.117.193.217.245.1359179001.squirrel@www.nmsworks.co.in> <50173.192.168.9.56.1359536572.squirrel@www.nmsworks.co.in> <1220E2C537595D439C5D026E83751866220E18D3@ex-mb1.corp.adtran.com> In-Reply-To: <1220E2C537595D439C5D026E83751866220E18D3@ex-mb1.corp.adtran.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.99.203] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "icnrg@irtf.org" , SDN IRTF list Subject: Re: [Sdn] [openflow-discuss] Semantic Stnadardization X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 16:23:05 -0000 Hi folks, (including icnrg) "content" (for example name based routing) is a topic in Information-Centri= c Networking (ICN). I agree it's an interesting application for SDN. One interesting question might be what kind of SDN abstraction would be req= uired to better support this -- as it is a bit different compared to flow-b= ased communication. Best regards, Dirk > -----Original Message----- > From: sdn-bounces@irtf.org [mailto:sdn-bounces@irtf.org] On Behalf Of > STUART VENTERS > Sent: Mittwoch, 30. Januar 2013 17:10 > To: sitaraman@nmsworks.co.in > Cc: SDN IRTF list > Subject: Re: [Sdn] [openflow-discuss] Semantic Stnadardization >=20 > Sitarman, >=20 > I'm confused/bugged by the statement 'Fundamentally one difference > between connection oriented and connectionless is the preemptibility of t= he > paths' >=20 > I wonder if we are mixing (or redefining?) two concepts I thought I knew. > 1) The concept of connection versus connection-less. An example is the > difference between TCP and UDP, which is more about protocols at the edge > than things in the middle. > 2) The concept of dedicated versus statistical (shared) bandwidth. An > example is the difference between CBR and UBR or between a leased tdm > circuit and an Internet route. These are more about things in the middle= like > routing or who gets to use the tx port when. >=20 > SDN seems likely to be about managing the middle for the benefit of stuff= at > the edge so I assume you are thinking more about the middle. Perhaps I > should read your statement 'Fundamentally one difference between > is the preemptibility of the paths'? >=20 >=20 > Regards, >=20 > Stuart >=20 >=20 >=20 > -----Original Message----- > From: sdn-bounces@irtf.org [mailto:sdn-bounces@irtf.org] On Behalf Of > sitaraman@nmsworks.co.in > Sent: Wednesday, January 30, 2013 3:03 AM > To: sitaraman@nmsworks.co.in > Cc: David Meyer; sdn@irtf.org openflow-discuss@mailman.stanford.edu; > SDN IRTF list > Subject: Re: [Sdn] [openflow-discuss] Semantic Stnadardization >=20 > What SDN buys us, due to its ability fo mess with forwarding directly at = the > applicaiton layer is to bring in the possibility of Context Awareness of > application data for tweaking forwarding decisions. > Fundamentally one difference between connection oriented and > connectionless is the preemptibility of the paths. Here again, MPLS-TE's = LSP > set up and hold priority kinds of reaches out to each other. LSPs are > connection oriented while giving connectionless like preremiptibiliy to t= hese > LSPs. > With SDN with its application controlled routing would allow is, therefor= e, we > could consider "Context Aware Premebility" which could be a mix of > Connectionless and Connection oriented nature. > I see some literature (one of them by John Strassner, i recolect some tim= e > ago there was a long thread of discussion on Context Awareness involving > John too) on relating Context Awareness to Ontologies too... > We could look at IRTF on defining such application controlled dynamic > preemptibility configuration while cross technology expression of this > capability using Policies perhaps or Policy independent Interfaces is > something we could consider at jointly with TMF. > Sitaraman >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > > On the content based routing...we could look at standardizing things > > like for example, content fields where data or downloads are requested > > or scheduled. > > > > OSS applications can go more real time and perform traffic engineering > > based on this by rerouting, reallocaiton of resources. Vint was > > mentioning to us yesterday that it is not so much the amount of data > > requested but the temporal nature of the same. This means of temporal > > nature of requests could also be standardized for benefit (scheduled > > interchange of data in organizations, relatively long on demand > > downloads...) Would you consider this as a reasonable benefit for an > > application that warrants study of the possible complexities involved. > > Another aspect that was discussed was charging based on the rate not > > the absolute bandwidth used. Facilities such as the above will allow > > service providers a means to provide subscirbers automated > > optimizations to schedule non urgent requests at lean times to a) > > reduce the cost to customers, b)optimize their own use of network to > increase customer base. > > Would this warrant identifying, addressing and study of the > > complexities involved as opposed to being "gratuitous" > > > > Sitaraman > > > > > >> [not sure which lists you were trying to post to, so I added > >> sdn@irtf.org] > >> > >> > >> I'll just note here as a general comment that part of the success > >> (and really, beauty) of the IP architecture is its inherent > >> simplicity. If SDN becomes a dumping ground for *gratuitous* > >> complexity (as we are currently seeing in many venues) then it will fa= il. > >> > >> --dmm > >> > >> > >> On Fri, Jan 25, 2013 at 10:08 AM, wrote: > >>> We had Vint Cerf himself visit and talk to us today evening. > >>> Amongst others, he highlighted to us Openflow and SDN allowing > >>> routing based on content in addition to headers. > >>> My immediate reaction was question that this being an antithesis to > >>> standardization.....then Vint mentioned an example about routing > >>> based on charactersitics of the data and routers selectively > >>> choosing to listen (per my understanding of what Vint said, not > >>> certain i got it > >>> entirely.) > >>> Could we say that the conventional protocols are more leaning > >>> towards syntactic standardization (Bits in header fields have > >>> tightly defined ranges and constructs). > >>> Has Semantic standardization, pattern matching been done before at > >>> IETF/IRTF? > >>> Any relationship to Ontologies? > >>> ARe the implications to correctness, convergence, routing loops and > >>> such of algorithms in this context been formally studied? > >>> Would it make sense to start halfway and have two header > >>> components, one decided by the protocol and the other header > >>> components contents decided by the application itself (this will > >>> form a special part of the data). > >>> yet this part of the data being in a well defined restricted area of > >>> the data..is this beginning to look like optical network framing > >>> where frame at one layer is data for the other? Combine this with > >>> NMS based routing, (decoupled control of SDN) SDN is beginning to > >>> get a lot of the charactersitics of Optical then? > >>> Sitaraman > >>> > >>> > >>> -- > >>> This message has been scanned for viruses and dangerous content by > >>> MailScanner, and is believed to be clean. > >>> > >>> _______________________________________________ > >>> openflow-discuss mailing list > >>> openflow-discuss@lists.stanford.edu > >>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > >> _______________________________________________ > >> sdn mailing list > >> sdn@irtf.org > >> https://www.irtf.org/mailman/listinfo/sdn > >> > >> -- > >> This message has been scanned for viruses and dangerous content by > >> MailScanner, and is believed to be clean. > >> > > > > >=20 >=20 >=20 > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. >=20 > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn From sitaraman@nmsworks.co.in Wed Jan 30 08:26:38 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328D321F8928 for ; Wed, 30 Jan 2013 08:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.64 X-Spam-Level: X-Spam-Status: No, score=-0.64 tagged_above=-999 required=5 tests=[AWL=-0.951, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VBfiYhxtSdi for ; Wed, 30 Jan 2013 08:26:37 -0800 (PST) Received: from indlocal.nmsworks.co.in (indus.nmsworks.co.in [14.140.238.3]) by ietfa.amsl.com (Postfix) with ESMTP id 7951321F8903 for ; Wed, 30 Jan 2013 08:26:36 -0800 (PST) Received: from www.nmsworks.co.in (localhost [127.0.0.1]) by indlocal.nmsworks.co.in (8.13.8/8.13.8) with ESMTP id r0UGOGiU026360; Wed, 30 Jan 2013 21:54:16 +0530 Received: from 101.63.148.194 (SquirrelMail authenticated user sitaraman) by www.nmsworks.co.in with HTTP; Wed, 30 Jan 2013 21:54:16 +0530 (IST) Message-ID: <50390.101.63.148.194.1359563056.squirrel@www.nmsworks.co.in> In-Reply-To: <1220E2C537595D439C5D026E83751866220E18D3@ex-mb1.corp.adtran.com> References: <53935.117.193.197.199.1359137334.squirrel@www.nmsworks.co.in> <49892.117.193.217.245.1359179001.squirrel@www.nmsworks.co.in> <50173.192.168.9.56.1359536572.squirrel@www.nmsworks.co.in> <1220E2C537595D439C5D026E83751866220E18D3@ex-mb1.corp.adtran.com> Date: Wed, 30 Jan 2013 21:54:16 +0530 (IST) From: sitaraman@nmsworks.co.in To: "STUART VENTERS" User-Agent: SquirrelMail/1.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-NMSWorks-MailScanner-Information: Please contact the ISP for more information X-NMSWorks-MailScanner-ID: r0UGOGiU026360 X-NMSWorks-MailScanner: Found to be clean X-NMSWorks-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.327, required 4, ALL_TRUSTED -1.00, BAYES_00 -1.90, URG_BIZ 0.57) X-NMSWorks-MailScanner-From: sitaraman@nmsworks.co.in Cc: SDN IRTF list Subject: Re: [Sdn] [openflow-discuss] Semantic Stnadardization X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 16:26:38 -0000 Hi Stuart, Indeed, you make a valid point here, thanks for bringing this out. Please give me some time..i need to clarify my thoughts more...thanks again Sitaraman > Sitarman, > > I'm confused/bugged by the statement 'Fundamentally one difference between > connection oriented and connectionless is the preemptibility of the paths' > > I wonder if we are mixing (or redefining?) two concepts I thought I knew. > 1) The concept of connection versus connection-less. An example is the > difference between TCP and UDP, which is more about protocols at the > edge than things in the middle. > 2) The concept of dedicated versus statistical (shared) bandwidth. An > example is the difference between CBR and UBR or between a leased tdm > circuit and an Internet route. These are more about things in the > middle like routing or who gets to use the tx port when. > > SDN seems likely to be about managing the middle for the benefit of stuff > at the edge so I assume you are thinking more about the middle. Perhaps I > should read your statement 'Fundamentally one difference between > is the preemptibility of the paths'? > > > Regards, > > Stuart > > > > -----Original Message----- > From: sdn-bounces@irtf.org [mailto:sdn-bounces@irtf.org] On Behalf Of > sitaraman@nmsworks.co.in > Sent: Wednesday, January 30, 2013 3:03 AM > To: sitaraman@nmsworks.co.in > Cc: David Meyer; sdn@irtf.org openflow-discuss@mailman.stanford.edu; SDN > IRTF list > Subject: Re: [Sdn] [openflow-discuss] Semantic Stnadardization > > What SDN buys us, due to its ability fo mess with forwarding directly at > the applicaiton layer is to bring in the possibility of Context Awareness > of application data for tweaking forwarding decisions. > Fundamentally one difference between connection oriented and > connectionless is the preemptibility of the paths. Here again, MPLS-TE's > LSP set up and hold priority kinds of reaches out to each other. LSPs are > connection oriented while giving connectionless like preremiptibiliy to > these LSPs. > With SDN with its application controlled routing would allow is, > therefore, we could consider "Context Aware Premebility" which could be a > mix of Connectionless and Connection oriented nature. > I see some literature (one of them by John Strassner, i recolect some time > ago there was a long thread of discussion on Context Awareness involving > John too) on relating Context Awareness to Ontologies too... > We could look at IRTF on defining such application controlled dynamic > preemptibility configuration while cross technology expression of this > capability using Policies perhaps or Policy independent Interfaces is > something we could consider at jointly with TMF. > Sitaraman > > > > > > > > >> On the content based routing...we could look at standardizing things >> like for example, content fields where data or downloads are requested >> or scheduled. >> >> OSS applications can go more real time and perform traffic engineering >> based on this by rerouting, reallocaiton of resources. Vint was >> mentioning to us yesterday that it is not so much the amount of data >> requested but the temporal nature of the same. This means of temporal >> nature of requests could also be standardized for benefit (scheduled >> interchange of data in organizations, relatively long on demand >> downloads...) Would you consider this as a reasonable benefit for an >> application that warrants study of the possible complexities involved. >> Another aspect that was discussed was charging based on the rate not >> the absolute bandwidth used. Facilities such as the above will allow >> service providers a means to provide subscirbers automated >> optimizations to schedule non urgent requests at lean times to a) >> reduce the cost to customers, b)optimize their own use of network to >> increase customer base. >> Would this warrant identifying, addressing and study of the >> complexities involved as opposed to being "gratuitous" >> >> Sitaraman >> >> >>> [not sure which lists you were trying to post to, so I added >>> sdn@irtf.org] >>> >>> >>> I'll just note here as a general comment that part of the success >>> (and really, beauty) of the IP architecture is its inherent >>> simplicity. If SDN becomes a dumping ground for *gratuitous* >>> complexity (as we are currently seeing in many venues) then it will >>> fail. >>> >>> --dmm >>> >>> >>> On Fri, Jan 25, 2013 at 10:08 AM, wrote: >>>> We had Vint Cerf himself visit and talk to us today evening. >>>> Amongst others, he highlighted to us Openflow and SDN allowing >>>> routing based on content in addition to headers. >>>> My immediate reaction was question that this being an antithesis to >>>> standardization.....then Vint mentioned an example about routing >>>> based on charactersitics of the data and routers selectively >>>> choosing to listen (per my understanding of what Vint said, not >>>> certain i got it >>>> entirely.) >>>> Could we say that the conventional protocols are more leaning >>>> towards syntactic standardization (Bits in header fields have >>>> tightly defined ranges and constructs). >>>> Has Semantic standardization, pattern matching been done before at >>>> IETF/IRTF? >>>> Any relationship to Ontologies? >>>> ARe the implications to correctness, convergence, routing loops and >>>> such of algorithms in this context been formally studied? >>>> Would it make sense to start halfway and have two header >>>> components, one decided by the protocol and the other header >>>> components contents decided by the application itself (this will >>>> form a special part of the data). >>>> yet this part of the data being in a well defined restricted area of >>>> the data..is this beginning to look like optical network framing >>>> where frame at one layer is data for the other? Combine this with >>>> NMS based routing, (decoupled control of SDN) SDN is beginning to >>>> get a lot of the charactersitics of Optical then? >>>> Sitaraman >>>> >>>> >>>> -- >>>> This message has been scanned for viruses and >>>> dangerous content by MailScanner, and is >>>> believed to be clean. >>>> >>>> _______________________________________________ >>>> openflow-discuss mailing list >>>> openflow-discuss@lists.stanford.edu >>>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>> _______________________________________________ >>> sdn mailing list >>> sdn@irtf.org >>> https://www.irtf.org/mailman/listinfo/sdn >>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >>> >> >> > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From pedromj@um.es Wed Jan 30 08:34:03 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFE121F8956; Wed, 30 Jan 2013 08:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 225sweOFI8cK; Wed, 30 Jan 2013 08:34:02 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD7A21F846E; Wed, 30 Jan 2013 08:34:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 820675D568; Wed, 30 Jan 2013 17:34:01 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3GoI43LDUl2D; Wed, 30 Jan 2013 17:34:01 +0100 (CET) Received: from [155.54.194.22] (vpn_um-194-22.inf.um.es [155.54.194.22]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pedromj) by xenon13.um.es (Postfix) with ESMTPSA id 4E7E05D566; Wed, 30 Jan 2013 17:33:55 +0100 (CET) Message-ID: <51094B71.40907@um.es> Date: Wed, 30 Jan 2013 17:33:53 +0100 From: =?UTF-8?B?UGVkcm8gTWFydMOtbmV6IEp1bGnDoQ==?= Organization: Universidad de Murcia User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130109 Thunderbird/17.0.2 MIME-Version: 1.0 To: Dirk Kutscher References: <53935.117.193.197.199.1359137334.squirrel@www.nmsworks.co.in> <49892.117.193.217.245.1359179001.squirrel@www.nmsworks.co.in> <50173.192.168.9.56.1359536572.squirrel@www.nmsworks.co.in> <1220E2C537595D439C5D026E83751866220E18D3@ex-mb1.corp.adtran.com> <82AB329A76E2484D934BBCA77E9F5249551EC4AD@DAPHNIS.office.hd> In-Reply-To: <82AB329A76E2484D934BBCA77E9F5249551EC4AD@DAPHNIS.office.hd> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "icnrg@irtf.org" , SDN IRTF list , STUART VENTERS , "sitaraman@nmsworks.co.in" Subject: Re: [Sdn] [icnrg] [openflow-discuss] Semantic Stnadardization X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 16:34:03 -0000 30/01/13 17:22, Dirk Kutscher: > Hi folks, > Hi, > (including icnrg) > > "content" (for example name based routing) is a topic in > Information-Centric Networking (ICN). I agree it's an interesting > application for SDN. > > One interesting question might be what kind of SDN abstraction would be > required to better support this -- as it is a bit different compared to > flow-based communication. > The typical ICN data-plane function can be modeled as a (m)any-to-one flow, a flow with multiple possible sources and one sink. The SDN controller should be able to manage the "(m)any" concept to decide/determine the flow source and thus construct the flow between one specific information/content source and the client that asks for it. On the other hand, to provide the caching function, a SDN should include the concept of data stores. Thus, a controller may set an element to introduce or get a flow-unit (packet/message) to/from such its store. > Best regards, > Dirk > Regards, Pedro -- Pedro Martinez-Julia Department of Communication and Information Engineering Faculty of Computer Science University of Murcia Email: pedromj@um.es --------------------------------------------------------- *** Entia non sunt multiplicanda praeter necessitatem *** From swb@internet2.edu Wed Jan 30 09:08:00 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B68821F8472; Wed, 30 Jan 2013 09:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXyZRh2POQNO; Wed, 30 Jan 2013 09:07:53 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4666321F86D4; Wed, 30 Jan 2013 09:07:52 -0800 (PST) Received: from mail176-tx2-R.bigfish.com (10.9.14.243) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Wed, 30 Jan 2013 17:07:52 +0000 Received: from mail176-tx2 (localhost [127.0.0.1]) by mail176-tx2-R.bigfish.com (Postfix) with ESMTP id F00FC2E020D; Wed, 30 Jan 2013 17:07:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.149; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0810HT003.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: S0(zzbb2dI98dIc89bh1432Izz1d77h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzzz2dh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h1155h) Received: from mail176-tx2 (localhost.localdomain [127.0.0.1]) by mail176-tx2 (MessageSwitch) id 1359565669972412_7608; Wed, 30 Jan 2013 17:07:49 +0000 (UTC) Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.250]) by mail176-tx2.bigfish.com (Postfix) with ESMTP id E4BE72600B2; Wed, 30 Jan 2013 17:07:49 +0000 (UTC) Received: from CH1PRD0810HT003.namprd08.prod.outlook.com (157.56.245.149) by TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 30 Jan 2013 17:07:44 +0000 Received: from CH1PRD0810MB395.namprd08.prod.outlook.com ([169.254.11.166]) by CH1PRD0810HT003.namprd08.prod.outlook.com ([10.255.145.166]) with mapi id 14.16.0263.000; Wed, 30 Jan 2013 17:07:44 +0000 From: Scott Brim To: =?utf-8?B?UGVkcm8gTWFydMOtbmV6IEp1bGnDoQ==?= , Dirk Kutscher Thread-Topic: [icnrg] [Sdn] [openflow-discuss] Semantic Stnadardization Thread-Index: AQHN/sk8H9DgqqoZc0yJonpig4HVkJhiCv0AgAADY4CAAAM7gP//taOA Date: Wed, 30 Jan 2013 17:07:44 +0000 Message-ID: <824CBBAF26EC8E428BE32C12F75F936901724FAD@CH1PRD0810MB395.namprd08.prod.outlook.com> In-Reply-To: <51094B71.40907@um.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.145.132] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: internet2.edu Cc: STUART VENTERS , SDN IRTF list , "icnrg@irtf.org" , "sitaraman@nmsworks.co.in" Subject: Re: [Sdn] [icnrg] [openflow-discuss] Semantic Stnadardization X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 17:08:01 -0000 T24gMDEvMzAvMTMgMTE6MzMsICJQZWRybyBNYXJ0w61uZXogSnVsacOhIiA8cGVkcm9takB1bS5l cz4gYWxsZWdlZGx5IHdyb3RlOg0KDQo+VGhlIHR5cGljYWwgSUNOIGRhdGEtcGxhbmUgZnVuY3Rp b24gY2FuIGJlIG1vZGVsZWQgYXMgYSAobSlhbnktdG8tb25lDQo+ZmxvdywgYQ0KPmZsb3cgd2l0 aCBtdWx0aXBsZSBwb3NzaWJsZSBzb3VyY2VzIGFuZCBvbmUgc2luay4gVGhlIFNETiBjb250cm9s bGVyDQo+c2hvdWxkIGJlIA0KPmFibGUgdG8gbWFuYWdlIHRoZSAiKG0pYW55IiBjb25jZXB0IHRv IGRlY2lkZS9kZXRlcm1pbmUgdGhlIGZsb3cgc291cmNlDQo+YW5kIA0KPnRodXMgY29uc3RydWN0 IHRoZSBmbG93IGJldHdlZW4gb25lIHNwZWNpZmljIGluZm9ybWF0aW9uL2NvbnRlbnQgc291cmNl DQo+YW5kIA0KPnRoZSBjbGllbnQgdGhhdCBhc2tzIGZvciBpdC4NCj4NCj5PbiB0aGUgb3RoZXIg aGFuZCwgdG8gcHJvdmlkZSB0aGUgY2FjaGluZyBmdW5jdGlvbiwgYSBTRE4gc2hvdWxkIGluY2x1 ZGUNCj50aGUgDQo+Y29uY2VwdCBvZiBkYXRhIHN0b3Jlcy4gVGh1cywgYSBjb250cm9sbGVyIG1h eSBzZXQgYW4gZWxlbWVudCB0bw0KPmludHJvZHVjZSBvciANCj5nZXQgYSBmbG93LXVuaXQgKHBh Y2tldC9tZXNzYWdlKSB0by9mcm9tIHN1Y2ggaXRzIHN0b3JlLg0KDQpCdXQgdGhlIElDTiBkYXRh IHBsYW5lIGlzIGludGVudGlvbmFsbHkgY29ubmVjdGlvbmxlc3MgYW5kIGhpZ2hseSBkeW5hbWlj DQp3aXRoIHJlc3BlY3QgdG8gc291cmNlcy4gIFlvdSB3YW50IG5vbmUgb2YgdGhlIHBsYW5uZWQg Y29uZmlndXJhdGlvbiBvZg0KU0ROIGZvcndhcmRpbmcuICANCg0K From pedromj@um.es Wed Jan 30 09:17:52 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E52F21F8639; Wed, 30 Jan 2013 09:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twIFF-RUFcbo; Wed, 30 Jan 2013 09:17:51 -0800 (PST) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 505E321F85B6; Wed, 30 Jan 2013 09:17:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 5470F4BEC1; Wed, 30 Jan 2013 18:17:50 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NrwhpHaFxCWW; Wed, 30 Jan 2013 18:17:50 +0100 (CET) Received: from [155.54.194.22] (vpn_um-194-22.inf.um.es [155.54.194.22]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pedromj) by xenon12.um.es (Postfix) with ESMTPSA id 110544BEAD; Wed, 30 Jan 2013 18:17:44 +0100 (CET) Message-ID: <510955B6.10608@um.es> Date: Wed, 30 Jan 2013 18:17:42 +0100 From: =?UTF-8?B?UGVkcm8gTWFydMOtbmV6IEp1bGnDoQ==?= Organization: Universidad de Murcia User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130109 Thunderbird/17.0.2 MIME-Version: 1.0 To: Scott Brim References: <824CBBAF26EC8E428BE32C12F75F936901724FAD@CH1PRD0810MB395.namprd08.prod.outlook.com> In-Reply-To: <824CBBAF26EC8E428BE32C12F75F936901724FAD@CH1PRD0810MB395.namprd08.prod.outlook.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: STUART VENTERS , SDN IRTF list , "icnrg@irtf.org" , "sitaraman@nmsworks.co.in" , Dirk Kutscher Subject: Re: [Sdn] [icnrg] [openflow-discuss] Semantic Stnadardization X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 17:17:52 -0000 30/01/13 18:07, Scott Brim: > On 01/30/13 11:33, "Pedro Martínez Juliá" allegedly wrote: > > But the ICN data plane is intentionally connectionless and highly dynamic > with respect to sources. You want none of the planned configuration of > SDN forwarding. > Flows are different than connections. I get your point about high dynamics but you will have a flow as soon as a ICN "source" is sending data to a ICN "sink". The key question is in determining which source can and will respond to the content requests and SDN controllers *should* be able to do it. Regards, Pedro -- Pedro Martinez-Julia Department of Communication and Information Engineering Faculty of Computer Science University of Murcia Email: pedromj@um.es --------------------------------------------------------- *** Entia non sunt multiplicanda praeter necessitatem *** From dt355@hermes.cam.ac.uk Wed Jan 30 08:31:25 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030CE21F8903; Wed, 30 Jan 2013 08:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-2.010, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAFJPI23aAF8; Wed, 30 Jan 2013 08:31:23 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEE221F87F5; Wed, 30 Jan 2013 08:31:23 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from 5acd6564.bb.sky.com ([90.205.101.100]:53476 helo=[192.168.1.54]) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:587) with esmtpsa (PLAIN:dt355) (TLSv1:AES128-SHA:128) id 1U0aZ6-0004QC-XL (Exim 4.72) (return-path ); Wed, 30 Jan 2013 16:31:12 +0000 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Dirk Trossen In-Reply-To: <82AB329A76E2484D934BBCA77E9F5249551EC4AD@DAPHNIS.office.hd> Date: Wed, 30 Jan 2013 16:31:11 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7BD53D72-5FFB-4E0E-BB91-21BE1A57F25F@cl.cam.ac.uk> References: <53935.117.193.197.199.1359137334.squirrel@www.nmsworks.co.in> <49892.117.193.217.245.1359179001.squirrel@www.nmsworks.co.in> <50173.192.168.9.56.1359536572.squirrel@www.nmsworks.co.in> <1220E2C537595D439C5D026E83751866220E18D3@ex-mb1.corp.adtran.com> <82AB329A76E2484D934BBCA77E9F5249551EC4AD@DAPHNIS.office.hd> To: Dirk Kutscher X-Mailer: Apple Mail (2.1085) Sender: Dirk Trossen X-Mailman-Approved-At: Wed, 30 Jan 2013 09:39:24 -0800 Cc: "icnrg@irtf.org" , SDN IRTF list , STUART VENTERS , "sitaraman@nmsworks.co.in" Subject: Re: [Sdn] [icnrg] [openflow-discuss] Semantic Stnadardization X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 16:31:25 -0000 Dirk, all, for an idea of possibly mapping ICN over SDN, please see D. Syrivelis, = G. Parisis, D. Trossen, P. Flegkas, V. Sourlas, T. Korakis, L. = Tassiulas, Pursuing a Software-Defined Information-Centric Network, = EWSDN 2012, IEEE, Darmstad Germany The idea here is to NOT map content relations onto SDN since the scaling = problems are potentially severe (I assert that the dimension of the = 'information space' is significantly larger than that of communication = relations in the network). Hence, the paper takes a different approach = and promises scalability along the dimension of communication relations = in the network. Best, Dirk On 30 Jan 2013, at 16:22, Dirk Kutscher wrote: > Hi folks, >=20 > (including icnrg) >=20 > "content" (for example name based routing) is a topic in = Information-Centric Networking (ICN). I agree it's an interesting = application for SDN. >=20 > One interesting question might be what kind of SDN abstraction would = be required to better support this -- as it is a bit different compared = to flow-based communication. >=20 > Best regards, > Dirk >=20 >=20 >=20 >> -----Original Message----- >> From: sdn-bounces@irtf.org [mailto:sdn-bounces@irtf.org] On Behalf Of >> STUART VENTERS >> Sent: Mittwoch, 30. Januar 2013 17:10 >> To: sitaraman@nmsworks.co.in >> Cc: SDN IRTF list >> Subject: Re: [Sdn] [openflow-discuss] Semantic Stnadardization >>=20 >> Sitarman, >>=20 >> I'm confused/bugged by the statement 'Fundamentally one difference >> between connection oriented and connectionless is the preemptibility = of the >> paths' >>=20 >> I wonder if we are mixing (or redefining?) two concepts I thought I = knew. >> 1) The concept of connection versus connection-less. An example is = the >> difference between TCP and UDP, which is more about protocols at the = edge >> than things in the middle. >> 2) The concept of dedicated versus statistical (shared) bandwidth. = An >> example is the difference between CBR and UBR or between a leased tdm >> circuit and an Internet route. These are more about things in the = middle like >> routing or who gets to use the tx port when. >>=20 >> SDN seems likely to be about managing the middle for the benefit of = stuff at >> the edge so I assume you are thinking more about the middle. Perhaps = I >> should read your statement 'Fundamentally one difference between >> is the preemptibility of the = paths'? >>=20 >>=20 >> Regards, >>=20 >> Stuart >>=20 >>=20 >>=20 >> -----Original Message----- >> From: sdn-bounces@irtf.org [mailto:sdn-bounces@irtf.org] On Behalf Of >> sitaraman@nmsworks.co.in >> Sent: Wednesday, January 30, 2013 3:03 AM >> To: sitaraman@nmsworks.co.in >> Cc: David Meyer; sdn@irtf.org openflow-discuss@mailman.stanford.edu; >> SDN IRTF list >> Subject: Re: [Sdn] [openflow-discuss] Semantic Stnadardization >>=20 >> What SDN buys us, due to its ability fo mess with forwarding directly = at the >> applicaiton layer is to bring in the possibility of Context Awareness = of >> application data for tweaking forwarding decisions. >> Fundamentally one difference between connection oriented and >> connectionless is the preemptibility of the paths. Here again, = MPLS-TE's LSP >> set up and hold priority kinds of reaches out to each other. LSPs are >> connection oriented while giving connectionless like preremiptibiliy = to these >> LSPs. >> With SDN with its application controlled routing would allow is, = therefore, we >> could consider "Context Aware Premebility" which could be a mix of >> Connectionless and Connection oriented nature. >> I see some literature (one of them by John Strassner, i recolect some = time >> ago there was a long thread of discussion on Context Awareness = involving >> John too) on relating Context Awareness to Ontologies too... >> We could look at IRTF on defining such application controlled dynamic >> preemptibility configuration while cross technology expression of = this >> capability using Policies perhaps or Policy independent Interfaces is >> something we could consider at jointly with TMF. >> Sitaraman >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> On the content based routing...we could look at standardizing things >>> like for example, content fields where data or downloads are = requested >>> or scheduled. >>>=20 >>> OSS applications can go more real time and perform traffic = engineering >>> based on this by rerouting, reallocaiton of resources. Vint was >>> mentioning to us yesterday that it is not so much the amount of data >>> requested but the temporal nature of the same. This means of = temporal >>> nature of requests could also be standardized for benefit (scheduled >>> interchange of data in organizations, relatively long on demand >>> downloads...) Would you consider this as a reasonable benefit for an >>> application that warrants study of the possible complexities = involved. >>> Another aspect that was discussed was charging based on the rate not >>> the absolute bandwidth used. Facilities such as the above will = allow >>> service providers a means to provide subscirbers automated >>> optimizations to schedule non urgent requests at lean times to a) >>> reduce the cost to customers, b)optimize their own use of network to >> increase customer base. >>> Would this warrant identifying, addressing and study of the >>> complexities involved as opposed to being "gratuitous" >>>=20 >>> Sitaraman >>>=20 >>>=20 >>>> [not sure which lists you were trying to post to, so I added >>>> sdn@irtf.org] >>>>=20 >>>>=20 >>>> I'll just note here as a general comment that part of the success >>>> (and really, beauty) of the IP architecture is its inherent >>>> simplicity. If SDN becomes a dumping ground for *gratuitous* >>>> complexity (as we are currently seeing in many venues) then it will = fail. >>>>=20 >>>> --dmm >>>>=20 >>>>=20 >>>> On Fri, Jan 25, 2013 at 10:08 AM, = wrote: >>>>> We had Vint Cerf himself visit and talk to us today evening. >>>>> Amongst others, he highlighted to us Openflow and SDN allowing >>>>> routing based on content in addition to headers. >>>>> My immediate reaction was question that this being an antithesis = to >>>>> standardization.....then Vint mentioned an example about routing >>>>> based on charactersitics of the data and routers selectively >>>>> choosing to listen (per my understanding of what Vint said, not >>>>> certain i got it >>>>> entirely.) >>>>> Could we say that the conventional protocols are more leaning >>>>> towards syntactic standardization (Bits in header fields have >>>>> tightly defined ranges and constructs). >>>>> Has Semantic standardization, pattern matching been done before at >>>>> IETF/IRTF? >>>>> Any relationship to Ontologies? >>>>> ARe the implications to correctness, convergence, routing loops = and >>>>> such of algorithms in this context been formally studied? >>>>> Would it make sense to start halfway and have two header >>>>> components, one decided by the protocol and the other header >>>>> components contents decided by the application itself (this will >>>>> form a special part of the data). >>>>> yet this part of the data being in a well defined restricted area = of >>>>> the data..is this beginning to look like optical network framing >>>>> where frame at one layer is data for the other? Combine this with >>>>> NMS based routing, (decoupled control of SDN) SDN is beginning to >>>>> get a lot of the charactersitics of Optical then? >>>>> Sitaraman >>>>>=20 >>>>>=20 >>>>> -- >>>>> This message has been scanned for viruses and dangerous content by >>>>> MailScanner, and is believed to be clean. >>>>>=20 >>>>> _______________________________________________ >>>>> openflow-discuss mailing list >>>>> openflow-discuss@lists.stanford.edu >>>>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>>> _______________________________________________ >>>> sdn mailing list >>>> sdn@irtf.org >>>> https://www.irtf.org/mailman/listinfo/sdn >>>>=20 >>>> -- >>>> This message has been scanned for viruses and dangerous content by >>>> MailScanner, and is believed to be clean. >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >>=20 >> _______________________________________________ >> sdn mailing list >> sdn@irtf.org >> https://www.irtf.org/mailman/listinfo/sdn >> _______________________________________________ >> sdn mailing list >> sdn@irtf.org >> https://www.irtf.org/mailman/listinfo/sdn > _______________________________________________ > icnrg mailing list > icnrg@irtf.org > https://www.irtf.org/mailman/listinfo/icnrg From dt355@hermes.cam.ac.uk Wed Jan 30 09:24:26 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F9821F8886; Wed, 30 Jan 2013 09:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.501 X-Spam-Level: X-Spam-Status: No, score=-6.501 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lw4K-fk1+xoI; Wed, 30 Jan 2013 09:24:26 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 506EC21F8881; Wed, 30 Jan 2013 09:24:26 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from 5acd6564.bb.sky.com ([90.205.101.100]:53625 helo=[192.168.1.54]) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:587) with esmtpsa (PLAIN:dt355) (TLSv1:AES128-SHA:128) id 1U0bOZ-0001bH-WJ (Exim 4.72) (return-path ); Wed, 30 Jan 2013 17:24:23 +0000 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Dirk Trossen In-Reply-To: <510955B6.10608@um.es> Date: Wed, 30 Jan 2013 17:24:22 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <824CBBAF26EC8E428BE32C12F75F936901724FAD@CH1PRD0810MB395.namprd08.prod.outlook.com> <510955B6.10608@um.es> To: =?iso-8859-1?Q?Pedro_Mart=EDnez_Juli=E1?= X-Mailer: Apple Mail (2.1085) Sender: Dirk Trossen X-Mailman-Approved-At: Wed, 30 Jan 2013 09:39:24 -0800 Cc: "icnrg@irtf.org" , Scott Brim , STUART VENTERS , Dirk Kutscher , SDN IRTF list , "sitaraman@nmsworks.co.in" Subject: Re: [Sdn] [icnrg] [openflow-discuss] Semantic Stnadardization X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 17:24:26 -0000 > Flows are different than connections. I get your point about high = dynamics but you will have a flow as soon as a ICN "source" is sending = data to a ICN "sink". The key question is in determining which source = can and will respond to the content requests and SDN controllers = *should* be able to do it. That's well put and I agree. See the provided paper reference in my = email before. It includes a paragraph that outlines what a 'flow' here = is in order to work well (i.e., scale) in SDN. Dirk >=20 > Regards, > Pedro >=20 > --=20 > Pedro Martinez-Julia > Department of Communication and Information Engineering > Faculty of Computer Science > University of Murcia > Email: pedromj@um.es > --------------------------------------------------------- > *** Entia non sunt multiplicanda praeter necessitatem *** > _______________________________________________ > icnrg mailing list > icnrg@irtf.org > https://www.irtf.org/mailman/listinfo/icnrg From sitaraman@nmsworks.co.in Wed Jan 30 09:46:21 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90CCA21F8865; Wed, 30 Jan 2013 09:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[AWL=-1.508, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_93=0.6, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvhDyBEzsg3G; Wed, 30 Jan 2013 09:46:20 -0800 (PST) Received: from indlocal.nmsworks.co.in (nmsworks.co.in [14.140.238.3]) by ietfa.amsl.com (Postfix) with ESMTP id A211221F8867; Wed, 30 Jan 2013 09:46:19 -0800 (PST) Received: from www.nmsworks.co.in (localhost [127.0.0.1]) by indlocal.nmsworks.co.in (8.13.8/8.13.8) with ESMTP id r0UHhvcE029383; Wed, 30 Jan 2013 23:13:57 +0530 Received: from 101.63.148.194 (SquirrelMail authenticated user sitaraman) by www.nmsworks.co.in with HTTP; Wed, 30 Jan 2013 23:13:57 +0530 (IST) Message-ID: <50494.101.63.148.194.1359567837.squirrel@www.nmsworks.co.in> In-Reply-To: <1220E2C537595D439C5D026E83751866220E18D3@ex-mb1.corp.adtran.com> References: <53935.117.193.197.199.1359137334.squirrel@www.nmsworks.co.in> <49892.117.193.217.245.1359179001.squirrel@www.nmsworks.co.in> <50173.192.168.9.56.1359536572.squirrel@www.nmsworks.co.in> <1220E2C537595D439C5D026E83751866220E18D3@ex-mb1.corp.adtran.com> Date: Wed, 30 Jan 2013 23:13:57 +0530 (IST) From: sitaraman@nmsworks.co.in To: "STUART VENTERS" User-Agent: SquirrelMail/1.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-NMSWorks-MailScanner-Information: Please contact the ISP for more information X-NMSWorks-MailScanner-ID: r0UHhvcE029383 X-NMSWorks-MailScanner: Found to be clean X-NMSWorks-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.327, required 4, ALL_TRUSTED -1.00, BAYES_00 -1.90, URG_BIZ 0.57) X-NMSWorks-MailScanner-From: sitaraman@nmsworks.co.in Cc: icnrg@irtf.org, SDN IRTF list Subject: Re: [Sdn] [openflow-discuss] Semantic Stnadardization X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 17:46:21 -0000 Hi Stuart, Like George Orwells more equal animals, i guess we can say some are more connection oriented amongst connection oriented beasts.... When i said connection oriented earlier, i had SDH type circuits in mind. Indeed as you say, TCP is an example of a connection that rides on a connectionless layer underneath. I tend to think it has less to do with middle or edge, i.e less to do with location in the typical telecommunication network topology or even functionality (core or edge). For, you do have connectionless IP running in the core (middle) that drives the LSP formation (connection) in the middle. Similarly you have the control protocol for connectionless IP - MPBGP driving a VPN "Connection" in the edge. If you have Carrier Ethernet MAC in MAC you have connectionless in core and with PBB-TE you have connection with the same technology - Ethernet. When i say connection, i simply meant to indicate the charactersitic that the application using this connection simply puts its data on one end with the assurance it comes out at the other end of the connectio(the path). I agree that i must explicitly add "At the layer at which the connection works"...for. like TCP, the connection can ride over a connectionless layer underneath. (The terminology "Layer" admittedly being used a bit loosely here than it should be, as it is used to specify Layer Rates). By Preemptibility, i meant to indicate the preemptibility of this charactersitic itself. When you say shared bandwidth, in the case of TCP/IP, you are talking of sharing of the data pipes that go a couple of layers below. Thats not what i intended to come across as saying, i was more intending to say preempting of the connection itself, and this is important.... at the layer the connection is established. Connections thus far in networks are established before hand, upfront, in Optical an NMS does it and in IP the control plane does it. Then, the application simply uses the connection. An applcation can choose to use a connection or use another, it has no control beyond that. What i was wondering was if SDN paradigm could be exploited to provide preemptibility of the connection, determined by the applicaiton context. This may be done entirely by the application itself, or, perhaps more likely, this is a use case scenario for an NMS(again centralized as opposed to a distributed, in-router protocol) interfacing on behalf of the applications with the controller. This means, that application context can drive preemption of connections which to me appears like it could offer more powerful/flexible/intelligent routing schemes that currently done. It appears to me, that SDN provides a means to exploit data or even networking parameter context (bw used)visibility when made available to management modules, to perform more intelligent routing that takes the context and perhaps even go as far as semantics of data into congnizance. Perhaps what we could do to address the very real scalability concern here is defining semantic patterns, ontological representations and interfaces that would allow quick communcation of the same to the NMS, which would in turn interface with controller to do the inteliigent routing, or reorg of network. Therefore i would say again that one fundamental difference between connection and connectionless (as it exits now) is the preemptibility of paths (i will now add however, at the "layer" at which the connection is established...for connections it is trivial, two well defined end points constituting the path, while for connectionless it is not). Does this sound more resonable? Sitaraman > Sitarman, > > I'm confused/bugged by the statement 'Fundamentally one difference between > connection oriented and connectionless is the preemptibility of the paths' > > I wonder if we are mixing (or redefining?) two concepts I thought I knew. > 1) The concept of connection versus connection-less. An example is the > difference between TCP and UDP, which is more about protocols at the > edge than things in the middle. > 2) The concept of dedicated versus statistical (shared) bandwidth. An > example is the difference between CBR and UBR or between a leased tdm > circuit and an Internet route. These are more about things in the > middle like routing or who gets to use the tx port when. > > SDN seems likely to be about managing the middle for the benefit of stuff > at the edge so I assume you are thinking more about the middle. Perhaps I > should read your statement 'Fundamentally one difference between > is the preemptibility of the paths'? > > > Regards, > > Stuart > > > > -----Original Message----- > From: sdn-bounces@irtf.org [mailto:sdn-bounces@irtf.org] On Behalf Of > sitaraman@nmsworks.co.in > Sent: Wednesday, January 30, 2013 3:03 AM > To: sitaraman@nmsworks.co.in > Cc: David Meyer; sdn@irtf.org openflow-discuss@mailman.stanford.edu; SDN > IRTF list > Subject: Re: [Sdn] [openflow-discuss] Semantic Stnadardization > > What SDN buys us, due to its ability fo mess with forwarding directly at > the applicaiton layer is to bring in the possibility of Context Awareness > of application data for tweaking forwarding decisions. > Fundamentally one difference between connection oriented and > connectionless is the preemptibility of the paths. Here again, MPLS-TE's > LSP set up and hold priority kinds of reaches out to each other. LSPs are > connection oriented while giving connectionless like preremiptibiliy to > these LSPs. > With SDN with its application controlled routing would allow is, > therefore, we could consider "Context Aware Premebility" which could be a > mix of Connectionless and Connection oriented nature. > I see some literature (one of them by John Strassner, i recolect some time > ago there was a long thread of discussion on Context Awareness involving > John too) on relating Context Awareness to Ontologies too... > We could look at IRTF on defining such application controlled dynamic > preemptibility configuration while cross technology expression of this > capability using Policies perhaps or Policy independent Interfaces is > something we could consider at jointly with TMF. > Sitaraman > > > > > > > > >> On the content based routing...we could look at standardizing things >> like for example, content fields where data or downloads are requested >> or scheduled. >> >> OSS applications can go more real time and perform traffic engineering >> based on this by rerouting, reallocaiton of resources. Vint was >> mentioning to us yesterday that it is not so much the amount of data >> requested but the temporal nature of the same. This means of temporal >> nature of requests could also be standardized for benefit (scheduled >> interchange of data in organizations, relatively long on demand >> downloads...) Would you consider this as a reasonable benefit for an >> application that warrants study of the possible complexities involved. >> Another aspect that was discussed was charging based on the rate not >> the absolute bandwidth used. Facilities such as the above will allow >> service providers a means to provide subscirbers automated >> optimizations to schedule non urgent requests at lean times to a) >> reduce the cost to customers, b)optimize their own use of network to >> increase customer base. >> Would this warrant identifying, addressing and study of the >> complexities involved as opposed to being "gratuitous" >> >> Sitaraman >> >> >>> [not sure which lists you were trying to post to, so I added >>> sdn@irtf.org] >>> >>> >>> I'll just note here as a general comment that part of the success >>> (and really, beauty) of the IP architecture is its inherent >>> simplicity. If SDN becomes a dumping ground for *gratuitous* >>> complexity (as we are currently seeing in many venues) then it will >>> fail. >>> >>> --dmm >>> >>> >>> On Fri, Jan 25, 2013 at 10:08 AM, wrote: >>>> We had Vint Cerf himself visit and talk to us today evening. >>>> Amongst others, he highlighted to us Openflow and SDN allowing >>>> routing based on content in addition to headers. >>>> My immediate reaction was question that this being an antithesis to >>>> standardization.....then Vint mentioned an example about routing >>>> based on charactersitics of the data and routers selectively >>>> choosing to listen (per my understanding of what Vint said, not >>>> certain i got it >>>> entirely.) >>>> Could we say that the conventional protocols are more leaning >>>> towards syntactic standardization (Bits in header fields have >>>> tightly defined ranges and constructs). >>>> Has Semantic standardization, pattern matching been done before at >>>> IETF/IRTF? >>>> Any relationship to Ontologies? >>>> ARe the implications to correctness, convergence, routing loops and >>>> such of algorithms in this context been formally studied? >>>> Would it make sense to start halfway and have two header >>>> components, one decided by the protocol and the other header >>>> components contents decided by the application itself (this will >>>> form a special part of the data). >>>> yet this part of the data being in a well defined restricted area of >>>> the data..is this beginning to look like optical network framing >>>> where frame at one layer is data for the other? Combine this with >>>> NMS based routing, (decoupled control of SDN) SDN is beginning to >>>> get a lot of the charactersitics of Optical then? >>>> Sitaraman >>>> >>>> >>>> -- >>>> This message has been scanned for viruses and >>>> dangerous content by MailScanner, and is >>>> believed to be clean. >>>> >>>> _______________________________________________ >>>> openflow-discuss mailing list >>>> openflow-discuss@lists.stanford.edu >>>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>> _______________________________________________ >>> sdn mailing list >>> sdn@irtf.org >>> https://www.irtf.org/mailman/listinfo/sdn >>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >>> >> >> > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > sdn mailing list > sdn@irtf.org > https://www.irtf.org/mailman/listinfo/sdn > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From sitaraman@nmsworks.co.in Wed Jan 30 18:19:47 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3185221F8794; Wed, 30 Jan 2013 18:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.757 X-Spam-Level: X-Spam-Status: No, score=-1.757 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+fV8REyBgUp; Wed, 30 Jan 2013 18:19:45 -0800 (PST) Received: from indlocal.nmsworks.co.in (nmsworks.co.in [14.140.238.3]) by ietfa.amsl.com (Postfix) with ESMTP id ED48821F878F; Wed, 30 Jan 2013 18:19:44 -0800 (PST) Received: from www.nmsworks.co.in (localhost [127.0.0.1]) by indlocal.nmsworks.co.in (8.13.8/8.13.8) with ESMTP id r0V2HCAY008520; Thu, 31 Jan 2013 07:47:13 +0530 Received: from 101.63.148.194 (SquirrelMail authenticated user sitaraman) by www.nmsworks.co.in with HTTP; Thu, 31 Jan 2013 07:47:17 +0530 (IST) Message-ID: <51742.101.63.148.194.1359598637.squirrel@www.nmsworks.co.in> In-Reply-To: <51095DDB.9000501@uniroma2.it> References: <824CBBAF26EC8E428BE32C12F75F936901724FAD@CH1PRD0810MB395.namprd08.prod.outlook.com> <510955B6.10608@um.es> <51095DDB.9000501@uniroma2.it> Date: Thu, 31 Jan 2013 07:47:17 +0530 (IST) From: sitaraman@nmsworks.co.in To: "Stefano Salsano" User-Agent: SquirrelMail/1.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-NMSWorks-MailScanner-Information: Please contact the ISP for more information X-NMSWorks-MailScanner-ID: r0V2HCAY008520 X-NMSWorks-MailScanner: Found to be clean X-NMSWorks-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.9, required 4, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-NMSWorks-MailScanner-From: sitaraman@nmsworks.co.in Cc: "icnrg@irtf.org" , Scott Brim , STUART VENTERS , Pedro =?iso-8859-1?Q?Mart=C3=ADnez_Juli=C3=A1?= , Dirk Kutscher , SDN IRTF list , "sitaraman@nmsworks.co.in" Subject: Re: [Sdn] [icnrg] [openflow-discuss] Semantic Stnadardization X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 02:19:47 -0000 Hi Stefano, Yes indeed, i agree with this approach of exploiting the decoupling of the control as is provided by SDN to make routing aware of the contexts that can be carried by the content. Two things. The terminology NBI appears to me a vestige of legacy. With SDN, i would say the lines between devices, NMS, EMS and OSS begins to blur. Decoupling and centralization of control in terms of topology, leads to a flatness in the interface semantics needed for operation. This is like impulse response and time-frequency domain relation. The more distributed the control domain is, the more hiearchical the semantics that need to transferred for network operations and in this context the NBI terminology makes sense. The converse is also true, the more centralized the control becomes (centralized conceptually that is)the more homogeneous the information semantics becomes. I tend to think the "Northbound" terminology could be a tad misleading suggestive. This also means that we need no longer look at IP packet headers to support Semantic routing. This is for the hardware folks there, would it be feasible to incorporate exchange of meta rules, that the NRS, or even the OSS can come up with that is then conveyed to Openflow which abstracts away the information and just directs the forwarding to inspect a given area and route accordingly. The hardware neednt do the abstraction itself, which could be too much to ask, but the latter functionality, if given an "address" in the packet the address being able to point to any area including data, and a rule to match the contents of the same to determine forwarding....the forwarding can then take place based on this rule? Sitaraman > Il 30/01/2013 18:17, Pedro Martínez Juliá ha scritto: >> 30/01/13 18:07, Scott Brim: >> Flows are different than connections. I get your point about high >> dynamics but you will have a flow as soon as a ICN "source" is sending >> data to a ICN "sink". The key question is in determining which source >> can and will respond to the content requests and SDN controllers >> *should* be able to do it. > > Hi all, > > FYI we have been working on ICN support with SDN/OpenFlow and recently > submitted the paper > > Information Centric Networking over SDN and OpenFlow: Architectural > Aspects and Experiments on the OFELIA Testbed > > available at http://arxiv.org/abs/1301.5933 > > regards, > Stefano > >> >> Regards, >> Pedro >> > > > -- > ******************************************************************* > Stefano Salsano > Dipartimento Ingegneria Elettronica > Universita' di Roma "Tor Vergata" > Via del Politecnico, 1 - 00133 Roma - ITALY > > http://netgroup.uniroma2.it/Stefano_Salsano/ > > E-mail : stefano.salsano@uniroma2.it > Cell. : +39 320 4307310 > Office : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435 > ******************************************************************* > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From sitaraman@nmsworks.co.in Wed Jan 30 22:30:26 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D224D21F856E; Wed, 30 Jan 2013 22:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5ePfgmp1pZS; Wed, 30 Jan 2013 22:30:24 -0800 (PST) Received: from indlocal.nmsworks.co.in (nmsworks.co.in [14.140.238.3]) by ietfa.amsl.com (Postfix) with ESMTP id 3750421F8503; Wed, 30 Jan 2013 22:30:23 -0800 (PST) Received: from www.nmsworks.co.in (localhost [127.0.0.1]) by indlocal.nmsworks.co.in (8.13.8/8.13.8) with ESMTP id r0V6R69b028945; Thu, 31 Jan 2013 11:57:06 +0530 Received: from 192.168.9.56 (SquirrelMail authenticated user sitaraman) by www.nmsworks.co.in with HTTP; Thu, 31 Jan 2013 11:57:06 +0530 (IST) Message-ID: <50435.192.168.9.56.1359613626.squirrel@www.nmsworks.co.in> Date: Thu, 31 Jan 2013 11:57:06 +0530 (IST) From: sitaraman@nmsworks.co.in To: icnrg@irtf.org User-Agent: SquirrelMail/1.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-NMSWorks-MailScanner-Information: Please contact the ISP for more information X-NMSWorks-MailScanner-ID: r0V6R69b028945 X-NMSWorks-MailScanner: Found to be clean X-NMSWorks-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.9, required 4, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-NMSWorks-MailScanner-From: sitaraman@nmsworks.co.in Cc: sdn@irtf.org Subject: [Sdn] Mereotopology. X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 06:30:26 -0000 Hi, The ICNRG intro says the following "Moving the focus from nodes to information objects raises scalability issues to a new level. Currently, the Internet is addressing on the order of 10^9 nodes, whereas the number of addressable ICN objects is expected to be several orders of magnitude higher." However, i feel there could be a fundamental difference arising out of the differences in the inherent nature of network device nodes and ICN nodes. The Network device nodes are transport devices that at best uses knowledge, ICN nodes are knowledges themselves. This means that connectivity requirements differ for them. While in network nodes, given the absence (or presence in relatively very little)knowledge, we would need maximum connectivity between the nodes, when the ICN nodes encapsulate knowledge, we could do with a lot less connectivty between them. Ontologies came to mind and i wondered if Ontologies have been related to Topologies....google reveals that indeed yes, there is a branch of Ontology called Mereotopology. Incorporating this formalism could make the scalability problem less onereous than it sounds....these mathematicians, you can count on them to always have something up their sleeves it appears.... Now, once the scalability is addressed, it is perhaps only natural that the entities that have knowledge of the domain as opposed entities that only transport, be able to have better control of the routes which is what SDN allows? Sitaraman -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From guillaume.fortaine@devopspace.com Thu Jan 31 13:19:28 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF69C21F86A9 for ; Thu, 31 Jan 2013 13:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtxRGKA1c2jI for ; Thu, 31 Jan 2013 13:19:27 -0800 (PST) Received: from eu1sys200aog110.obsmtp.com (eu1sys200aog110.obsmtp.com [207.126.144.129]) by ietfa.amsl.com (Postfix) with SMTP id C87BC21F84E8 for ; Thu, 31 Jan 2013 13:19:26 -0800 (PST) Received: from mail-oa0-f71.google.com ([209.85.219.71]) (using TLSv1) by eu1sys200aob110.postini.com ([207.126.147.11]) with SMTP ID DSNKUQrf1ywJZ3q8+dhg3IxeYuWKR+SusptY@postini.com; Thu, 31 Jan 2013 21:19:27 UTC Received: by mail-oa0-f71.google.com with SMTP id o6so3096050oag.10 for ; Thu, 31 Jan 2013 13:19:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=0zSfMs3+msnRP2hnSnyGwK9b4VMhozJIWbaoN+I8/qs=; b=i5/90mw3yKA33YJC2rgYW4vsYkq/7rfRrlnukSFvU54INKHuEloIfd85Wct4qdfXU1 8Gj9iNnpCHHzX0P50D3QMpypRQNsKfOW1lFCSrNqb6tWWk36P4qar5ZIKdaqIPhR4Jly tIjU+Jr+th85zWAbez3yMUXDBIx383+dD3tr/heO+ja+Sv9HlRvpUosfx4GkoJ274R6Y GXcaphT/aaxzrWf4kcdPgm8i7SKekqz05qe3d4D0hJiWjWOCUhJhRYCvvSrOQ8NtJA35 17TjH5y/gQDVkIej6hmngSGx/htTnGMGCA0l+L9BFlAF8ouv8yEz7A+/B9K/0sA9ADLh OuDA== X-Received: by 10.60.1.73 with SMTP id 9mr7570919oek.130.1359667158390; Thu, 31 Jan 2013 13:19:18 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.1.73 with SMTP id 9mr7570914oek.130.1359667158231; Thu, 31 Jan 2013 13:19:18 -0800 (PST) Received: by 10.60.142.35 with HTTP; Thu, 31 Jan 2013 13:19:18 -0800 (PST) Date: Thu, 31 Jan 2013 22:19:18 +0100 Message-ID: From: Guillaume Fortaine To: sdn@irtf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkJZKDR6msqc3HAZsLX+3iUprhX0kAgU+8Mf3z6mRe6PYg+3M63cjt8Ngi0hzuWuGXAxYvDm8y1+Q+P+VgEKBtvORJLqQ7+IRRVKc8sUAza0kppJmb3ZiMgjIlLOoHkCSaoiaJ8 Subject: [Sdn] Deeply Programmable Network X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List to Discuss SDN Research Group in the IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 21:19:28 -0000 Hello, For your information : http://netseminar.stanford.edu/seminars/10_18_12.pdf Best Regards, Guillaume FORTAINE