Re: [vnrg] way forward on VNRG definitions
Didier Colle <didier.colle@intec.UGent.be> Tue, 13 July 2010 10:28 UTC
Return-Path: <didier.colle@intec.UGent.be>
X-Original-To: vnrg@core3.amsl.com
Delivered-To: vnrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 111963A686A for <vnrg@core3.amsl.com>; Tue, 13 Jul 2010 03:28:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.699
X-Spam-Level:
X-Spam-Status: No, score=-99.699 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1DP0yQBTXam for <vnrg@core3.amsl.com>; Tue, 13 Jul 2010 03:28:46 -0700 (PDT)
Received: from smtp1.UGent.be (smtp1.ugent.be [157.193.71.182]) by core3.amsl.com (Postfix) with ESMTP id 84BEB3A67C3 for <vnrg@irtf.org>; Tue, 13 Jul 2010 03:28:46 -0700 (PDT)
Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp1.UGent.be (Postfix) with ESMTP id 575B93F688C; Tue, 13 Jul 2010 12:28:54 +0200 (CEST)
X-Virus-Scanned: by UGent DICT
Received: from smtp1.UGent.be ([157.193.71.182]) by localhost (mcheck2.ugent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id GqkeNGYnixRl; Tue, 13 Jul 2010 12:28:53 +0200 (CEST)
Received: from mail4.intec.ugent.be (mail4.intec.ugent.be [157.193.214.4]) by smtp1.UGent.be (Postfix) with ESMTP id 930773F6889; Tue, 13 Jul 2010 12:28:53 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail4.intec.ugent.be (Postfix) with ESMTP id 47C7913923; Tue, 13 Jul 2010 12:28:53 +0200 (CEST)
Received: from mail4.intec.ugent.be ([127.0.0.1]) by localhost (mail4.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbwDBxyMPd48; Tue, 13 Jul 2010 12:28:53 +0200 (CEST)
Received: from [157.193.135.65] (dhcp-zdpt-65.intec.ugent.be [157.193.135.65]) by mail4.intec.ugent.be (Postfix) with ESMTP id ED76913922; Tue, 13 Jul 2010 12:28:52 +0200 (CEST)
Message-ID: <4C3C3FE5.7070007@intec.UGent.be>
Date: Tue, 13 Jul 2010 12:28:53 +0200
From: Didier Colle <didier.colle@intec.UGent.be>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Martin Röhricht <roehricht@kit.edu>
References: <547F018265F92642B577B986577D671C014B9959@VENUS.office> <4C0E275D.3020604@intec.UGent.be> <9FA16888AD1BF64ABCE6C2532CCEB98A0A7A8C62@xmb-sjc-219.amer.cisco.com> <4C0E768F.3030703@isi.edu> <4C2B3EDF.30302@kit.edu>
In-Reply-To: <4C2B3EDF.30302@kit.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Miltered: at mcheck2 with ID 4C3C3FE5.002 by Joe's j-chkmail (http://helpdesk.ugent.be/email/)!
X-j-chkmail-Enveloppe: 4C3C3FE5.002/157.193.214.4/mail4.intec.ugent.be/mail4.intec.ugent.be/<didier.colle@intec.UGent.be>
X-j-chkmail-Score: MSGID : 4C3C3FE5.002 on smtp1.UGent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Cc: vnrg@irtf.org
Subject: Re: [vnrg] way forward on VNRG definitions
X-BeenThere: vnrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Virtual Networks Research Group \(VNRG\) discussion list" <vnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/listinfo/vnrg>, <mailto:vnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/vnrg>
List-Post: <mailto:vnrg@irtf.org>
List-Help: <mailto:vnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/vnrg>, <mailto:vnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Jul 2010 10:28:51 -0000
Dear Martin, all, > - Inter-domain-wide operation across multiple administrative domains. > Comparable to the issues in QoS research we may be able to easily > provide dedicated services to users within our domain, but providing > these services inter-domain-wide may have some technical or business > constraints. I tend to disagree with this point. The abstraction as part of the virtualization should hide whether resources belong to one or multiple domain. Scenario I am thinking of: global network service provider X and global network service provider Y obtain guaranteed virtual resources from virtual infrastructure provider P who aggregates and VIRTUALIZES resources (probably also partly virtual resources) obtained from local infrastructure provider A and in another local infrastructure provider B. Those local infrastructure providers might also deliver virtual resources directly to local service providers xa, xb, ya and yb. Having said that, doing is much harder than saying a couple of words. Still I believe the abstraction and aggregation features of virtualization should enable overcoming multi-domain issues. You are right, business constraints can probably not be solved by virtualization (probably not by any technical solution...). Having said that: what is the business scenario in which a provider delivers virtual network instances but putting in place business constraints preventing extensions to other domains? Kind regards, Didier Martin Röhricht wrote: > Dear Joe, > > On 08.06.2010 18:57 Joe Touch wrote: >> As a starting point, we would like to have everyone on the list >> answer the >> following questions. We would prefer short text rather than full >> paragraphs >> extracted from any I-D or other document. >> ----------------------------------------------------- >> >> Starting questions: >> >> 1. how do you define VNs? > > A VN is a network that appears to its users as an ordinary network by > providing ordinary interfaces and services but which is actually > decoupled from the physical substrate. > >> 1.a. what are the key components? > > Virtual nodes, virtual links, management entities > >> 1.b. what is the relationship between these components? > > An arbitrary number of virtual links may be spanned between an > arbitrary number of virtual nodes. A physical node may be equipped > with multiple virtual nodes. Virtual links are controlled by > management entities residing on physical nodes and acting as mediators > between pyhsical and virtual nodes. > >> 1.c. what is the characteristic behavior/capability of the >> resulting system? > > The resulting virtual network provides its users the illusion of using > a dedicated (physical) network with a set of guaranteed resources. It > should provide its services isolated from other virtual or physical > networks that actually run on the same hardware. Network management > operations should be performed transparent for the network's users, > e.g. by migrating nodes or links in the physical substrate. > >> 2. what are VNs used for? > > VNs may be used to provide a dedicated network for its users which > operates isolated from any other network traffic. They may be used to > bring out completely new network architectures and protocols. They > may be used to optimize resource utilization either via aggregating or > via distributing resources used for a virtual network. > >> 3. what are they key challenges? >> >> for each challenge: >> - define the challenge >> - explain why it is hard >> - provide some references to those working on solutions > > - Instantiation of virtual nodes and virtual links. How can we a > priori determine whether a virtual node exists or is actively running? > - Inter-domain-wide operation across multiple administrative domains. > Comparable to the issues in QoS research we may be able to easily > provide dedicated services to users within our domain, but providing > these services inter-domain-wide may have some technical or business > constraints. > - Dynamic and on-demand instantiation of virtual networks. Instead of > using a manual or semi-manual (e.g. script-based) configuration of > virtual networks, it may be desirable to use signaling protocols for a > dynamic and on-demand management of virtual networks. > - Network topologies. Talking about virtual networks, we may wish to > not only control some virtual nodes and virtual links, but also create > virtual network topologies, such as full-meshed networks, rings, > trees, etc. > - Attachment of end-users---are they part of the virtual network? How > do we cope with the mobility of end-users, again inter-domain-wide? > - Aggregation---to what level can we aggregate traffic by still > preserving isolation and by not losing flexibility to migrate virtual > nodes and virtual links to another location? > - Security---how can security be achieved? Is it an integrated part > of the virtual network architecture and transparent to its users? > - AAA---using virtual network resources breaks down to actually using > physical resources of one or more network operators. How do we > provide authentication, authorization, and accountability? How do we > provide these AAA services inter-domain-wide? > - Are Quality-of-Service guarantees an inherent requirement for virtual > networks? If yes, to what extent? > - Providing the users the opportunity to create completely new network > architectures and protocols inside their virtual networks---how do we > cope with interoperability? Or do we run the risk of creating an > »inverse Internet«? > > > That's it for now. > > Martin > _______________________________________________ > vnrg mailing list > vnrg@irtf.org > https://www.irtf.org/mailman/listinfo/vnrg -- Didier Colle Ghent University - IMEC - IBBT Department of Information Technology (INTEC) Gaston Crommenlaan 8 bus 201, B-9050 Gent (Ledeberg) Email: didier.colle@intec.UGent.be MSN: didiercolle@hotmail.com Skype: didiercolle Tel. +32 9 331 4970 Fax. +32 9 331 4899 Mobile: +32 473 295655 WWW: www.ibcn.intec.UGent.be
- [vnrg] Review of draft-shin-virtualization-meta-a… Martin Stiemerling
- Re: [vnrg] Review of draft-shin-virtualization-me… Didier Colle
- Re: [vnrg] Review of draft-shin-virtualization-me… Krishna Sankar (ksankar)
- [vnrg] way forward on VNRG definitions Joe Touch
- Re: [vnrg] Review of draft-shin-virtualization-me… Sangjin Jeong
- Re: [vnrg] Review of draft-shin-virtualization-me… Sangjin Jeong
- Re: [vnrg] Review of draft-shin-virtualization-me… Sangjin Jeong
- Re: [vnrg] Review of draft-shin-virtualization-me… Martin Stiemerling
- Re: [vnrg] way forward on VNRG definitions Didier Colle
- Re: [vnrg] way forward on VNRG definitions Martin Röhricht
- Re: [vnrg] way forward on VNRG definitions Martin Röhricht
- Re: [vnrg] way forward on VNRG definitions Didier Colle
- Re: [vnrg] way forward on VNRG definitions Joe Touch
- Re: [vnrg] way forward on VNRG definitions Sangjin Jeong