From ehalep@gmail.com Thu Dec 5 07:20:21 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92931AE0A3 for ; Thu, 5 Dec 2013 07:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ih9LJWfJjn1w for ; Thu, 5 Dec 2013 07:20:19 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA271AE0A1 for ; Thu, 5 Dec 2013 07:20:19 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id w62so11152135wes.31 for ; Thu, 05 Dec 2013 07:20:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=LNgADYWBNABrSlPo4dfsV68nD52gqLkwcnETwtN3lWs=; b=eh60wPNSyiYzR9FMPKm7a8OSHK6rOiqorqvbK+n7gsyRUnVhFG8W71cmnQhMmcD9xT iv3H9p1MlCtP4NaRdA1KuveGR+z6+O4VQRPyAQ/SWGwBwWEc1RC79k85p8coO7JX3n45 PODDU0GdeZk0uSgCY/g1yh2Pi1+GFnGrGUEI4GpP5Cc5r8FNSrcB41abPu19UrCxCcgP STKZXJq78Nbxe0UNrntYfx/Vgq19NeM0vfwo2Eki6PIMRmOo9lKCvMBjKUiontl+HjvR F9RxoK/a0aX3BYcNSYzpbqEs7PsqFsYXwZMucciiyL4iHbEyj7G/89OEm5FZxeF7jHe5 fsVQ== X-Received: by 10.180.90.37 with SMTP id bt5mr12548977wib.43.1386256815607; Thu, 05 Dec 2013 07:20:15 -0800 (PST) Received: from EhalepXPS (ppp046177089192.access.hol.gr. [46.177.89.192]) by mx.google.com with ESMTPSA id fj8sm7323419wib.1.2013.12.05.07.20.12 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Dec 2013 07:20:13 -0800 (PST) From: "Haleplidis Evangelos" To: Date: Thu, 5 Dec 2013 17:20:12 +0200 Message-ID: <00ee01cef1cd$7f995cf0$7ecc16d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7xzV9QQagOQ9+ARY2KqedeSuxEugAATOiw Content-Language: el Subject: [Sdn] FW: New Version Notification for draft-haleplidis-sdnrg-layer-terminology-03.txt X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2013 15:20:21 -0000 Greetings to the list, After taking into consideration the discussion at the Vancouver meeting = and the extensive discussions in the mailing list we updated our draft. Regards, Evangelos Haleplidis. > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, December 05, 2013 5:08 PM > To: Evangelos Haleplidis; Jamal Hadi Salim; Kostas Pentikousis; Spyros > Denazis; David Meyer; Odysseas Koufopavlou > Subject: New Version Notification for draft-haleplidis-sdnrg-layer- > terminology-03.txt >=20 >=20 > A new version of I-D, draft-haleplidis-sdnrg-layer-terminology-03.txt > has been successfully submitted by Evangelos Haleplidis and posted to > the IETF repository. >=20 > Filename: draft-haleplidis-sdnrg-layer-terminology > Revision: 03 > Title: SDN Layers and Architecture Terminology > Creation date: 2013-12-05 > Group: Individual Submission > Number of pages: 19 > URL: = http://www.ietf.org/internet-drafts/draft-haleplidis-sdnrg-layer-terminol= ogy-03.txt > Status: = http://datatracker.ietf.org/doc/draft-haleplidis-sdnrg-layer-terminology > Htmlized: = http://tools.ietf.org/html/draft-haleplidis-sdnrg-layer-terminology-03 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-haleplidis-sdnrg-layer-terminolo= gy-03 >=20 > Abstract: > Software-Defined Networking (SDN) can in general be defined as a = new > approach for network programmability. Network programmability > refers > to the capacity to initialize, control, change, and manage network > behavior dynamically via open interfaces as opposed to relying on > closed-box solutions and propietary-defined interfaces. SDN > emphasizes the role of software in running networks through the > introduction of an abstraction for the data forwarding plane and, = by > doing so, separates it from the control plane. This separation > allows faster innovation cycles at both planes as experience has > already shown. However, there is increasing confusion as to what > exactly SDN is, what is the layer structure in an SDN architecture > and how do layers interface with each other. This document aims to > answer these questions and provide a concise reference document for > SDNRG, in particular, and the SDN community, in general, based on > relevant peer-reviewed literature and documents in the RFC series. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. >=20 > The IETF Secretariat From lliyanag@ee.oulu.fi Mon Dec 9 01:38:04 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA681AE092 for ; Mon, 9 Dec 2013 01:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYxCM9Ab_4rW for ; Mon, 9 Dec 2013 01:38:01 -0800 (PST) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by ietfa.amsl.com (Postfix) with ESMTP id 731F71ADE86 for ; Mon, 9 Dec 2013 01:38:01 -0800 (PST) Received: from [127.0.0.1] (ee-gw5.oulu.fi [130.231.61.15]) (authenticated bits=0) by ee.oulu.fi (8.14.4/8.14.4) with ESMTP id rB99btf5002959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Dec 2013 11:37:56 +0200 Message-ID: <52A58F74.1080607@ee.oulu.fi> Date: Mon, 09 Dec 2013 11:37:56 +0200 From: Madhusanka Liyanage User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: SDN IRTF list Content-Type: multipart/alternative; boundary="------------010806070506080204090104" X-Antivirus: avast! (VPS 131209-0, 09.12.2013), Outbound message X-Antivirus-Status: Clean Subject: [Sdn] Call for Chapters - Software Defined Mobile Networks (SDMN) X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2013 09:39:18 -0000 This is a multi-part message in MIME format. --------------010806070506080204090104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, We would like to bring your attention to our edited book on "Software Defined Mobile Networks (SDMN): Beyond LTE Network Architecture ". This book would be published by WILEY Publishers and it is anticipated to be in print by late 2014 tentatively. We kindly request you to contribute chapters for the book based on your research area. Also, please feel free to distribute this call among your colleagues. BR Madhusanka Liyanage Center for Wireless Communication, University of Oulu, Finland Mobile: +358 44 916 0857 Mail: msanka@gmail.com/ madhusanka@ee.oulu.fi WWW: http://www.cwc.oulu.fi/~lliyanag/ ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Call for Chapters - Software Defined Mobile Networks (SDMN) : Beyond LTE Network Architecture We would like to bring your attention to the edited book on "Software Defined Mobile Networks (SDMN): Beyond LTE Network Architecture ". This book would be published by WILEY Publishers and it is anticipated to be in print by late 2014 tentatively. We kindly request you to contribute chapters for the book based on your research area. Editors Madhusanka Liyanage (Centre for Wireless Communication, University of Oulu, Finland) Andrei Gurtov (Department of Computer Science and Engineering, Aalto University, Finland) Mika Yliantilla (Centre for Internet Excellence, University of Oulu, Finland) Call for Chapters 21st of March 2014: Proposal Submission Deadline 1st of April 2014: Notification of Acceptance 1st of June 2014: Full Chapter Submission 1st of July 2014: Review Results Returned 1st of August 2014: Final Chapter Submission More information can be found in Call for Chapter web site : Link Objective This book project will present the concept of a Software Defined Mobile Network (SDMN) which would change the network architecture of the current LTE (3GPP) networks. SDN will also open up new opportunities for traffic, resource and mobility management, as well as impose new challenges on network security. It is also foreseen that the investments in the network and operational costs would change. Therefore, this book project will address these main affecting areas such as traffic, resource and mobility management, virtualized traffics transportation, network management, network security and techno economic concepts. Moreover, the complete introduction to SDN and SDMN concepts will be included in the introduction section of the book. In a nutshell, this book project will provide an insight into the feasibility and opportunities of SDMN concept, as well as evaluate the limits of performance and scalability of the new technologies applied on mobile broadband networks. Recommended topics include, but are not limited to, the following: Software Defined Networking (SDN) Concepts o Evolution of SDN o History of SDN o SDN Controllers, Network Programmability o SDN Working Groups/ Research Communities o SDN Applications Mobile Networking Concepts o Evolution of Mobile Networks o Limitations in current mobile technologies o Requirement in future mobile networks o Beyond LTE network architectures Software Defined Mobile Networks (SDMN) SDMN Architectures and Network implementation o State of the art in Software Defined Networks o Architectural options for Software Defined Mobile Networks o Requirements and Scenarios in Software Defined Mobile Networks o Implementation and validation aspects of SDMN o Mobile Network Optimized SDN Controller Functionality; SDMN controller o Standardization aspects of SDMN o Validation setup and open source solutions of SDMN Traffic Transport and Network Management aspects of SDMN o Network virtualization and Virtualized traffic transport Technologies o Optimization of Traffic Transportation o Scalability of SDMNs Mobile Virtual Network Operators (MVNO) Mobile Peer-to-Peer Services Mobile Cloud Services Traffic, Resource and Mobility Management aspects o Mobility Management o Resource selection and Management o Microscopic/Macroscopic Traffic Management o Application supported traffic Management o Optimization of traffic and resource management Security aspects of SDMNs o State of the art in Security challenges in future mobile architectures o Economically viable security techniques for mobile networks o Secure Mobile Network services o Security Management in SDMN Software Defined Radio (SDR) Networks o Introduction to SDRN o Integration aspect of SDRN to SDMN o SDN based interference management o Virtualized Radio Resource Management Techno-economic aspects o State of the art in techno-economic modeling of SDMN o Business Cases in virtualized Mobile Network Environments Submission Procedure Researchers and practitioners are invited to submit on or before 21st of March, 2014, a 2-3 page chapter proposal clearly explaining the mission and concerns of his or her proposed chapter. Authors of accepted proposals will be notified by 01st of April, 2014 about the status of their proposals and sent chapter guidelines. Full chapters are expected to be submitted by 1st of June, 2014. All submitted chapters will be reviewed on a double-blind review basis. Contributors may also be requested to serve as reviewers for this project. More information can be found in Call for Chapter web site : Link Manuscript guidelines: Refer to the link shown: Click here. The preparation of manuscripts submitted for the book must be original and not previously published elsewhere or currently under review. Expected chapter length is between 4,000 to 8,000 words or more (or can be discussed with the editors). The formatting of initial or draft manuscripts should follow: A4 page format, single column with 11 point Times New Roman font with 1.5 line spacing, while submitting your manuscript as Microsoft Office Word document. WILEY follows Harvard Style as the reference style. Refer to manuscript instruction file. Publishing and Indexing: This book is scheduled to be published by CRC Press, Taylor and Francis (New York). For additional information regarding the publisher, please visit WILEY Publishers. This publication is anticipated to be released in late 2014. Publication Cost to Authors: Free of charge Inquiries and submissions can be forwarded electronically (Word document): Madhusanka Liyanage Research Scientist, Centre for Wireless Communication, University of Oulu, Finland. Email : sdmn.book@gmail.com Website : https://sites.google.com/site/callforchapterssdmn/ -- Madhusanka Liyanage Research Scientist, Center for Wireless Communication, University of Oulu, Finland Mobile: +358 44 916 0857 Office: +358 29448 2869 Mail: msanka@gmail.com/ madhusanka@ee.oulu.fi skype: msanka.liyanage WWW: http://www.cwc.oulu.fi/~lliyanag/ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com --------------010806070506080204090104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello,

We would like to bring your attention to our edited book on "Software Defined Mobile Networks (SDMN): Beyond LTE Network Architecture".
This book would be published by WILEY Publishers and it is anticipated to be in print by late 2014 tentatively.
We kindly request you to contribute chapters for the book based on your research area.
Also, please feel free to distribute this call among your colleagues.

BR

Madhusanka Liyanage
Center for Wireless Communication,
University of Oulu,
Finland
Mobile: +358 44 916 0857
Mail: msanka@gmail.com/ madhusanka@ee.oulu.fi
WWW: http://www.cwc.oulu.fi/~lliyanag/

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Call for Chapters - Software Defined Mobile Networks (SDMN) : Beyond LTE Network Architecture

We would like to bring your attention to the edited book on "Software Defined Mobile Networks (SDMN): Beyond LTE Network Architecture". This book would be published by WILEY Publishers and it is anticipated to be in print by late 2014 tentatively. We kindly request you to contribute chapters for the book based on your research area.

Editors

Madhusanka Liyanage (Centre for Wireless Communication, University of Oulu, Finland)
Andrei Gurtov (Department of Computer Science and Engineering, Aalto University, Finland)
Mika Yliantilla  (Centre for Internet Excellence, University of Oulu, Finland)

Call for Chapters

21st of March   2014:  Proposal Submission Deadline
1st of  April       2014:  Notification of Acceptance
1st  of  June      2014:  Full Chapter Submission
1st  of July        2014:  Review Results Returned
1st of  August  2014:  Final Chapter Submission

More information can be found in Call for Chapter web site : Link

Objective

This book project will present the concept of a Software Defined Mobile Network (SDMN) which would change the network architecture of the current LTE (3GPP) networks. SDN will also open up new opportunities for traffic, resource and mobility management, as well as impose new challenges on network security.  It is also foreseen that the investments in the network and operational costs would change.  Therefore, this book project will address these main affecting areas such as traffic, resource and mobility management, virtualized traffics transportation, network management, network security and techno economic concepts. Moreover, the complete introduction to SDN and SDMN concepts will be included in the introduction section of the book. 

In a nutshell, this book project will provide an insight into the feasibility and opportunities of SDMN concept, as well as evaluate the limits of performance and scalability of the new technologies applied on mobile broadband networks.

Recommended topics include, but are not limited to, the following:

Software Defined Networking (SDN) Concepts
o   Evolution of SDN
o   History of SDN
o   SDN Controllers, Network Programmability
o   SDN Working Groups/ Research Communities
o   SDN Applications

Mobile Networking Concepts
o   Evolution of Mobile Networks
o   Limitations in current mobile technologies
o   Requirement in future mobile networks
o   Beyond LTE network architectures

Software Defined Mobile Networks (SDMN)

SDMN Architectures  and Network implementation
o   State of the art in Software Defined Networks
o   Architectural options for Software Defined Mobile Networks
o   Requirements and Scenarios in Software Defined Mobile Networks
o   Implementation and validation aspects of SDMN
o   Mobile Network Optimized SDN Controller Functionality; SDMN controller
o   Standardization aspects of SDMN
o   Validation setup and open source solutions of SDMN


Traffic Transport and Network Management aspects of SDMN
o   Network  virtualization and Virtualized traffic transport Technologies
o   Optimization of Traffic Transportation
o   Scalability of SDMNs

Mobile Virtual Network Operators (MVNO)
Mobile Peer-to-Peer Services
Mobile Cloud Services

Traffic, Resource and Mobility Management  aspects
o   Mobility Management
o   Resource selection and Management
o   Microscopic/Macroscopic Traffic Management
o   Application supported traffic Management
o   Optimization of traffic and resource management

Security aspects of SDMNs
o   State of the art in Security challenges in future mobile architectures
o   Economically viable security techniques for mobile networks
o   Secure Mobile Network services
o   Security Management in SDMN

Software Defined Radio (SDR) Networks
o   Introduction to SDRN
o   Integration aspect of SDRN to SDMN
o   SDN based interference management
o   Virtualized Radio Resource Management

Techno-economic aspects
o   State of the art in techno-economic modeling of SDMN
o   Business Cases in virtualized Mobile Network Environments

Submission Procedure

Researchers and practitioners are invited to submit on or before 21st of March, 2014, a 2-3 page chapter proposal clearly explaining the mission and concerns of his or her proposed chapter. Authors of accepted proposals will be notified by 01st of April, 2014 about the status of their proposals and sent chapter guidelines. Full chapters are expected to be submitted by 1st of June, 2014. All submitted chapters will be reviewed on a double-blind review basis. Contributors may also be requested to serve as reviewers for this project.  More information can be found in Call for Chapter web site : Link

Manuscript guidelines:

Refer to the link shown: Click here. The preparation of manuscripts submitted for the book must be original and not previously published elsewhere or currently under review. Expected chapter length is between 4,000 to 8,000 words or more (or can be discussed with the editors). The formatting of initial or draft manuscripts should follow: A4 page format, single column with 11 point Times New Roman font with 1.5 line spacing, while submitting your manuscript as Microsoft Office Word document. WILEY follows Harvard Style as the reference style. Refer to manuscript instruction file.
Publishing and Indexing:

This book is scheduled to be published by CRC Press, Taylor and Francis (New York). For additional information regarding the publisher, please visit WILEY Publishers. This publication is anticipated to be released in late 2014.

Publication Cost to Authors:

Free of charge

Inquiries and submissions can be forwarded electronically (Word document):

Madhusanka Liyanage
Research Scientist,
Centre for Wireless Communication,
University of Oulu,
Finland.
Email : sdmn.book@gmail.com
Website : https://sites.google.com/site/callforchapterssdmn/
-- 
Madhusanka Liyanage
Research Scientist,
Center for Wireless Communication,
University of Oulu,
Finland                                       
Mobile: +358 44 916 0857 Office: +358 29448 2869
Mail: msanka@gmail.com/ madhusanka@ee.oulu.fi 
skype: msanka.liyanage
WWW: http://www.cwc.oulu.fi/~lliyanag/


This email is free from viruses and malware because avast! Antivirus protection is active.


--------------010806070506080204090104-- From leeyoung@huawei.com Tue Dec 17 08:34:31 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15CBB1AE181 for ; Tue, 17 Dec 2013 08:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.737 X-Spam-Level: X-Spam-Status: No, score=-4.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8I-2UEU__Q4 for ; Tue, 17 Dec 2013 08:34:25 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A5CBD1AE1B6 for ; Tue, 17 Dec 2013 08:34:24 -0800 (PST) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXY74728; Tue, 17 Dec 2013 10:34:23 -0600 (CST) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Dec 2013 08:34:24 -0800 Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Tue, 17 Dec 2013 08:34:20 -0800 From: Leeyoung To: "actn@ietf.org" Thread-Topic: virtual network mapping/embedding (VNM/VNE) problem Thread-Index: Ac77RdTjI/gEkOJNRuyLHsDiwda0eQ== Date: Tue, 17 Dec 2013 16:34:19 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729BA3CFF@dfweml510-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.236] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729BA3CFFdfweml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "sdn@irtf.org" Subject: [Sdn] virtual network mapping/embedding (VNM/VNE) problem X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 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, 17 Dec 2013 16:34:31 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729BA3CFFdfweml510mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Related to the ACTN work, there has been active research termed "virtual ne= twork mapping/embedding (VNM/VNE)": Here's some pointer to key papers: http://www-bcf.usc.edu/~minlanyu/writeup/CCR08.pdf (VNE with path split and= path migration) http://nsm1.cs.uwaterloo.ca/rboutaba/Papers/Conferences/2010/Muntasir10.pdf= (survivable VNE) http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=3D5616527 (Resource Ef= ficient VNE) The focus of ACTN perhaps does not have a direct bearing with these papers = as they are concerned about the VNM/VNE algorithms; however, these bring so= me key issues and constraints for virtual network path computation. These i= ssues and constraints should be of interest of the ACTN work that may impac= t on the design, information models and interface/protocol extensions (if n= ecessary). Some of the issues such as efficiency of algorithm are perhaps = better fit to SDN RG, some of key issues and constraints for virtual netwo= rk path computation related to VNM/VNE are as follows: - Request Processing This is concerned about whether a set of client requests for VN creation ca= n be dealt with simultaneously or not. This depends on the nature of applic= ations the client support. If the client does not require real-time instant= iation of VN creation, the computation engine can process a set of VN creat= ion requests simultaneously to improve network efficiency. - Types of Network Resources When client makes a VN creation request to the substrate network, what kind= of network resources is consumed is of concern of both the client and netw= ork providers. It depends on the application. For transport network virtual= ization, the network resource consumed by the client is primarily network b= andwidth that the paths would occupy on the physical link. However, there m= ay be other resource types such as CPU and memory that need to be considere= d for certain applications. These resource types are a part of the client's= VN request. - Accuracy of Network Resource Representation As the underlying transport network in itself may consists of layered struc= ture, it is a challenge how to represent these underlying physical network = resources and topology into a form that can be reliably used by the computa= tion engine that assigns the client requests into the physical network reso= urce and topology. - Resource Efficiency Related to the accuracy of network resource representation is resource effi= ciency. As a set of independent client VN is created and mapped onto physic= al network resources, the overall network resource utilization is of the pr= imary concern of the infrastructure provider. - Guarantee of Client Isolation While network resource sharing across a set of clients for efficient utiliz= ation is important aspect of network virtualization, client isolation has t= o be guaranteed. Admissions of new client requests or any changes of other = existing clients' VNs must not affect any particular client in terms of res= ource guarantee, security constraints, and other performance constraints. - Computing Time Depending on the nature of applications, how quickly a VN is instantiated f= rom the time of request is an important factor. For dynamic applications th= at require instantaneous VN creation, the computation model/algorithm shoul= d support this constraint. - Admission Control To coordinate the request process of multiple clients, an admission control= will help maximize an overall efficiency. - Path Constraints There may be some factors of path constraints that can affect the overall e= fficiency. Path Split can lower VN request blocking if the underlying netwo= rk can support such capability. Packet-based TE network can support path sp= lit while circuit-based transport may have a limitation. Path migration is= a technique that allows changes of nodes or links assignment of the establ= ished paths in an effort to accommodate new requests which would not be acc= epted without path migration. This can improve overall efficiency, yet addi= tional care needs to be applied to avoid any adverse impacts associated wit= h changing the existing paths. Re-optimization is a global process to re-shuffle all existing path assignm= ent to minimize network resource fragmentation. Again, an extra care needs = to be applied for re-optimization. --_000_7AEB3D6833318045B4AE71C2C87E8E1729BA3CFFdfweml510mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Related to the ACTN work, there has been active rese= arch termed “virtual network mapping/embedding (VNM/VNE)”:=

 

Here’s some pointer to key papers:<= /p>

 

http://www-bcf.usc.edu/~minlanyu/writeup/CCR08.pdf (VNE with= path split and path migration)

http://nsm1.cs.uwaterloo.ca/rboutaba/Pa= pers/Conferences/2010/Muntasir10.pdf (survivable VNE)

http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber= =3D5616527 (Resource Efficient VNE)

 

The focus of ACTN perhaps does not have a direct bea= ring with these papers as they are concerned about the VNM/VNE algorithms; = however, these bring some key issues and constraints for virtual network pa= th computation. These issues and constraints should be of interest of the ACTN work that may impact on the design, info= rmation models and interface/protocol extensions (if necessary).  Some= of the issues such as efficiency of algorithm are perhaps better fit to SD= N RG,  some of key issues and constraints for virtual network path computation related to VNM/VNE are as follows:

 =

<= ![if !supportLists]>-   Request Processing

This is concerned about whether a set of client requ= ests for VN creation can be dealt with simultaneously or not. This depends = on the nature of applications the client support. If the client does not re= quire real-time instantiation of VN creation, the computation engine can process a set of VN creation requests= simultaneously to improve network efficiency.

 

<= a name=3D"_Toc374709104">-   Types of Network Resources

When client makes a VN creation request to the subst= rate network, what kind of network resources is consumed is of concern of b= oth the client and network providers. It depends on the application. For tr= ansport network virtualization, the network resource consumed by the client is primarily network bandwidth tha= t the paths would occupy on the physical link. However, there may be other = resource types such as CPU and memory that need to be considered for certai= n applications. These resource types are a part of the client’s VN request.

 

<= ![if !supportLists]>-   Accuracy of Network Resource Representation

As the underlying transport network in itself may co= nsists of layered structure, it is a challenge how to represent these under= lying physical network resources and topology into a form that can be relia= bly used by the computation engine that assigns the client requests into the physical network resource and to= pology.

 

<= ![if !supportLists]>-   Resource Efficiency

Related to the accuracy of network resource represen= tation is resource efficiency. As a set of independent client VN is created= and mapped onto physical network resources, the overall network resource u= tilization is of the primary concern of the infrastructure provider.

 

<= ![if !supportLists]>-   Guarantee of Client Isolation

While network resource sharing across a set of clien= ts for efficient utilization is important aspect of network virtualization,= client isolation has to be guaranteed. Admissions of new client requests o= r any changes of other existing clients’ VNs must not affect any particular client in terms of resource guarantee, = security constraints, and other performance constraints. 

 

<= ![if !supportLists]>-   Computing Time

Depending on the nature of applications, how quickly= a VN is instantiated from the time of request is an important factor. For = dynamic applications that require instantaneous VN creation, the computatio= n model/algorithm should support this constraint.

 

<= ![if !supportLists]>-   Admission Control

To coordinate the request process of multiple client= s, an admission control will help maximize an overall efficiency.

 

<= a name=3D"_Toc374709110">-   Path Constraints

There may be some factors of path constraints that c= an affect the overall efficiency. Path Split can lower VN request blocking = if the underlying network can support such capability. Packet-based TE netw= ork can support path split while circuit-based transport may have a limitation.  Path migration is a technique that = allows changes of nodes or links assignment of the established paths in an = effort to accommodate new requests which would not be accepted without path= migration. This can improve overall efficiency, yet additional care needs to be applied to avoid any adverse i= mpacts associated with changing the existing paths.

Re-optimization is a global process to re-shuffle al= l existing path assignment to minimize network resource fragmentation. Agai= n, an extra care needs to be applied for re-optimization.

 

 

--_000_7AEB3D6833318045B4AE71C2C87E8E1729BA3CFFdfweml510mbxchi_-- From junbi@tsinghua.edu.cn Wed Dec 18 05:07:27 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D845B1AE1D1 for ; Wed, 18 Dec 2013 05:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kOO0VglkhJP for ; Wed, 18 Dec 2013 05:07:24 -0800 (PST) Received: from tsinghua.edu.cn (smtp06.tsinghua.edu.cn [166.111.204.35]) by ietfa.amsl.com (Postfix) with ESMTP id 078A21ADF60 for ; Wed, 18 Dec 2013 05:07:21 -0800 (PST) Received: from junbithinkpadx1 (unknown [59.66.24.195]) by app1 (Coremail) with SMTP id CsxvpgCXnKj7nbFS+xcJAA--.722S2; Wed, 18 Dec 2013 21:07:07 +0800 (CST) From: "Jun Bi" To: References: In-Reply-To: Date: Wed, 18 Dec 2013 21:07:01 +0800 Message-ID: <000901cefbf2$0a46c2b0$1ed44810$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01CEFC35.186AC600" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHjw6hAaRkTwKuwl0xorIBCaDzdoJowXL6w Content-Language: zh-cn X-CM-TRANSID: CsxvpgCXnKj7nbFS+xcJAA--.722S2 X-Coremail-Antispam: 1UD129KBjvJXoWxXryfWr13Gr4xGw48KFWkCrg_yoWruF4DpF WrKw15Ja17JF13Aw4jya1kuryfuFZ3J39xWwn8Jr1DuanxGFyIgFyftayFgFy3Crs5Jr1a vwnFqr1DG3ZYvrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvjb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j 6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40Eb7x2x7xS6r1j6r4UMc02F40E57IF 67AEF4xIwI1l5I8CrVAKz4kIr2xC04v26r1j6r4UMc02F40E42I26xC2a48xMcIj6xIIjx v20xvE14v26r106r15McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1l F7xvr2IYc2Ij64vIr41lc2xSY4AK67AK6ry8MxAIw28IcxkI7VAKI48JMI8I3I0E5I8CrV AFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUJVWUXwCI c40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267 AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Wr1j6rW3Jr1lIxAIcVC2z280aVAFwI0_ Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUgh vKUUUUU X-CM-SenderInfo: xmxquxo6wvx0pjkxthxhgxhubq/ Subject: [Sdn] FW: Announcing the 2014 ONS Research Track X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 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, 18 Dec 2013 13:07:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000A_01CEFC35.186AC600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Nate Foster [mailto:jnfoster@cs.cornell.edu] Sent: Wednesday, December 18, 2013 1:51 AM To: Nate Foster Cc: Rob Sherwood Subject: Announcing the 2014 ONS Research Track [You are receiving this message because you registered for a HotSDN 2013 account.] We are pleased to announce the 2014 Open Networking Summit Research Track. ONS (http://www.opennetsummit.org) is a unique event that provides wonderful opportunities for researchers and industrial practitioners to interact. Please consider submitting a two-page paper! Important notes: * The submission deadline is January 18th, 2014. * This year accepted papers will be published by USENIX. * Concurrent submissions to SIGCOMM '14 are allowed, subject to a few conditions described below (designed to preserve SIGCOMM's double-blind reviewing policy). Best regards, Nate and Rob ONS RESEARCH TRACK CALL FOR PRESENTATIONS The 2014 ONS Research Track will provide researchers with a unique opportunity to present innovative SDN work to a broad community of academic peers and industry leaders. The primary goals of the Research Track are to facilitate an exchange of SDN research ideas; to leverage the strong industry presence at ONS to bring focus to relevant research problems; and to build a community of researchers helping to realize the potential of SDN. By participating in the ONS Research Track, researchers can learn what industry is doing with SDN and discover ways that their work can have direct and lasting impacts. We solicit submissions describing innovative SDN work in the form of two-page extended abstracts. We are particularly interested in early stage work, but also welcome submissions that describe operational experiences or summarize published results. Submissions will be selected according to the following criteria: technical merit, originality, and likelihood of spawning insightful discussion. RELEVANT TOPICS INCLUDE, BUT ARE NOT LIMITED TO, THE FOLLOWING: * Applications of SDN to home, wireless, cellular, enterprise, data-center, and backbone networks * Applications of SDN to network management, performance monitoring, and security. * Virtual appliances (e.g., firewalls, intrusion detection systems, load balancers, etc.) built using SDN * Virtualization in SDN * Switch designs for SDN * Application programming interfaces for SDN * Control and management software stack for SDN * Programming languages, verification techniques, and tools for SDN * Performance evaluation of SDN network elements and controllers * Experiences deploying SDN in operational networks * Hybrid SDN approaches (integration with other control planes) * Experiences transitioning existing networks to SDN * Placement and factoring of SDN control logic * SDN control plane abstractions * Scalability and reliability of SDN platforms * Distributed SDN controller platforms SUBMISSION INSTRUCTIONS Extended abstracts must be submitted as PDF files no longer than two (2) pages in length (in one-column, single-spaced, 10-point format) including appendices and references. Papers must be submitted via the submission site, https://ons2014.cs.cornell.edu. and should include author names and affiliations. Accepted submissions will be published by USENIX. At least one author of each accepted submission is expected to attend ONS to present their paper. ONS will provide one complimentary registration for each accepted paper. Note: concurrent submissions to SIGCOMM 2014 are permitted provided that (i) the submissions use different titles and (ii) all 2014 SIGCOMM PC members are declared as conflicts. This policy will help facilitate double-blind reviewing at SIGCOMM, to the extent possible. IMPORTANT DATES Submission deadline January 18th, 2014 Acceptance notifications February 8th, 2014 Final version due February 22nd, 2014 Research Track dates March 3rd-5th, 2014 PROGRAM COMMITTEE Nate Foster (Cornell University) Rob Sherwood (Big Switch Networks) Dan Daly (Intel) Jun Bi (Tsinghua University) Colin Dixon (IBM) Sachin Katti (Stanford University) Ramana Kompella (Purdue University) Teemu Koponen (VMware) Ratul Mahajan (Microsoft Research) Mooly Sagiv (Tel Aviv University) Stefan Schmid (TU Berlin / T-Labs) Vyas Sekar (Carnegie Mellon University) Joel Sommers (Colgate University) Dan Talayco (Barefoot Networks) Laurent Vanbever (Princeton University) Minlan Yu (University of Southern California) ------=_NextPart_000_000A_01CEFC35.186AC600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: Nate = Foster [mailto:jnfoster@cs.cornell.edu]
Sent: Wednesday, = December 18, 2013 1:51 AM
To: Nate Foster
Cc: Rob = Sherwood
Subject: Announcing the 2014 ONS Research = Track

 

[You are receiving this message because you registered for = a HotSDN 2013 account.]

We are pleased to announce the 2014 Open = Networking Summit Research Track. ONS (http://www.opennetsummit.org) = is a unique event that provides wonderful opportunities for researchers = and industrial practitioners to interact. Please consider submitting a = two-page paper!

Important notes:

* The submission deadline = is January 18th, 2014.

* This year accepted papers will be = published by USENIX.

* Concurrent submissions to SIGCOMM '14 are = allowed, subject to a few conditions described below (designed to = preserve SIGCOMM's double-blind reviewing policy).

Best = regards,
Nate and Rob

ONS RESEARCH TRACK CALL FOR = PRESENTATIONS

The 2014 ONS Research Track will provide = researchers with a unique
opportunity to present innovative SDN work = to a broad community of
academic peers and industry leaders. The = primary goals of the Research
Track are to facilitate an exchange of = SDN research ideas; to leverage
the strong industry presence at ONS = to bring focus to relevant
research problems; and to build a = community of researchers helping to
realize the potential of SDN. By = participating in the ONS Research
Track, researchers can learn what = industry is doing with SDN and
discover ways that their work can have = direct and lasting impacts.

We solicit submissions describing = innovative SDN work in the form of
two-page extended abstracts. We = are particularly interested in early
stage work, but also welcome = submissions that describe operational
experiences or summarize = published results. Submissions will be
selected according to the = following criteria: technical merit,
originality, and likelihood of = spawning insightful discussion.

RELEVANT TOPICS INCLUDE, BUT ARE = NOT LIMITED TO, THE FOLLOWING:

* Applications of SDN to home, = wireless, cellular, enterprise,
  data-center, and backbone = networks

* Applications of SDN to network management, performance = monitoring,
  and security.

* Virtual appliances (e.g., = firewalls, intrusion detection systems,
  load balancers, etc.) = built using SDN

* Virtualization in SDN

* Switch designs = for SDN

* Application programming interfaces for SDN

* = Control and management software stack for SDN

* Programming = languages, verification techniques, and tools for SDN

* = Performance evaluation of SDN network elements and controllers

* = Experiences deploying SDN in operational networks

* Hybrid SDN = approaches (integration with other control planes)

* Experiences = transitioning existing networks to SDN

* Placement and factoring = of SDN control logic

* SDN control plane abstractions

* = Scalability and reliability of SDN platforms

* Distributed SDN = controller platforms

SUBMISSION INSTRUCTIONS

Extended = abstracts must be submitted as PDF files no longer than two
(2) pages = in length (in one-column, single-spaced, 10-point format)
including = appendices and references. Papers must be submitted via = the
submission site,

  https://ons2014.cs.cornell.edu.

and should include author names and affiliations. Accepted = submissions
will be published by USENIX. At least one author of each = accepted
submission is expected to attend ONS to present their paper. = ONS will
provide one complimentary registration for each accepted = paper.

Note: concurrent submissions to SIGCOMM 2014 are permitted = provided
that (i) the submissions use different titles and (ii) all = 2014
SIGCOMM PC members are declared as conflicts. This policy will = help
facilitate double-blind reviewing at SIGCOMM, to the extent = possible.

IMPORTANT DATES

Submission deadline   =      January 18th, 2014
Acceptance notifications = February 8th, 2014
Final version due       =  February 22nd, 2014
Research Track dates       =  March 3rd-5th, 2014

PROGRAM COMMITTEE

Nate Foster = (Cornell University)
Rob Sherwood (Big Switch Networks)

Dan = Daly (Intel)
Jun Bi (Tsinghua University)
Colin Dixon = (IBM)
Sachin Katti (Stanford University)
Ramana Kompella (Purdue = University)
Teemu Koponen (VMware)
Ratul Mahajan (Microsoft = Research)
Mooly Sagiv (Tel Aviv University)
Stefan Schmid (TU = Berlin / T-Labs)
Vyas Sekar (Carnegie Mellon University)
Joel = Sommers (Colgate University)
Dan Talayco (Barefoot = Networks)
Laurent Vanbever (Princeton University)
Minlan Yu = (University of Southern = California)

------=_NextPart_000_000A_01CEFC35.186AC600-- From leeyoung@huawei.com Fri Dec 20 11:12:19 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC871AC448 for ; Fri, 20 Dec 2013 11:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.737 X-Spam-Level: X-Spam-Status: No, score=-4.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaljrKu9qawd for ; Fri, 20 Dec 2013 11:12:13 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D255C1AE0E6 for ; Fri, 20 Dec 2013 11:12:10 -0800 (PST) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id APN99089; Fri, 20 Dec 2013 13:12:07 -0600 (CST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 20 Dec 2013 11:12:05 -0800 Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Fri, 20 Dec 2013 11:12:00 -0800 From: Leeyoung To: Daniele Ceccarelli , "actn@ietf.org" Thread-Topic: [Actn] virtual network mapping/embedding (VNM/VNE) problem Thread-Index: AQHO/W6RDeEpEZPP50m1uop4SSQtEppdaWyQ Date: Fri, 20 Dec 2013 19:11:59 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729BA4A59@dfweml510-mbx.china.huawei.com> References: <7AEB3D6833318045B4AE71C2C87E8E1729BA3CFF@dfweml510-mbx.china.huawei.com> <4A1562797D64E44993C5CBF38CF1BE4812662B06@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE4812662B06@ESESSMB301.ericsson.se> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.142.97] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729BA4A59dfweml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "sdn@irtf.org" Subject: Re: [Sdn] [Actn] virtual network mapping/embedding (VNM/VNE) problem X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 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, 20 Dec 2013 19:12:19 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729BA4A59dfweml510mbxchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Daniele, Thanks for your feedback and comments. Please see inline for my reply. Thanks. Young From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Friday, December 20, 2013 4:30 AM To: Leeyoung; actn@ietf.org Cc: sdn@irtf.org Subject: RE: [Actn] virtual network mapping/embedding (VNM/VNE) problem Hi Young, Thanks for the pointers and the list of issues. Please find in line some loud thinking from my side. BR Daniele From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung Sent: marted=EC 17 dicembre 2013 17:34 To: actn@ietf.org Cc: sdn@irtf.org Subject: [Actn] virtual network mapping/embedding (VNM/VNE) problem Related to the ACTN work, there has been active research termed "virtual ne= twork mapping/embedding (VNM/VNE)": Here's some pointer to key papers: http://www-bcf.usc.edu/~minlanyu/writeup/CCR08.pdf (VNE with path split and= path migration) http://nsm1.cs.uwaterloo.ca/rboutaba/Papers/Conferences/2010/Muntasir10.pdf= (survivable VNE) http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=3D5616527 (Resource Ef= ficient VNE) The focus of ACTN perhaps does not have a direct bearing with these papers = as they are concerned about the VNM/VNE algorithms; however, these bring so= me key issues and constraints for virtual network path computation. These i= ssues and constraints should be of interest of the ACTN work that may impac= t on the design, information models and interface/protocol extensions (if n= ecessary). Some of the issues such as efficiency of algorithm are perhaps = better fit to SDN RG, some of key issues and constraints for virtual netwo= rk path computation related to VNM/VNE are as follows: - Request Processing This is concerned about whether a set of client requests for VN creation ca= n be dealt with simultaneously or not. This depends on the nature of applic= ations the client support. If the client does not require real-time instant= iation of VN creation, the computation engine can process a set of VN creat= ion requests simultaneously to improve network efficiency. [[DC]] I think here we can assume that VN creation requests are non real ti= me. Instantiation of services and bandwidth might be real time (and hence c= oncurrency needs to be managed) but I would say this is not the case of VN = creation. YOUNG>> Good point. I was loose on the term 'VN creation". There are cert= ainly negotiation aspects of VN creation which can be viewed as non-real ti= me as the client endpoints need to be negotiated with network provider(s) b= efore service creation. Yes, in that sense, I agree with you. Here what I m= eant to say was when there are multiple service requests to setup virtual = connections that need not be instantiated real-time, (in other words, if so= me request can be queued for a delay scheduling), then a batch processing o= f multiple requests would be more optimal in general from a network efficie= ncy perspective than sequential processing. - Types of Network Resources When client makes a VN creation request to the substrate network, what kind= of network resources is consumed is of concern of both the client and netw= ork providers. It depends on the application. For transport network virtual= ization, the network resource consumed by the client is primarily network b= andwidth that the paths would occupy on the physical link. However, there m= ay be other resource types such as CPU and memory that need to be considere= d for certain applications. These resource types are a part of the client's= VN request. [[DC]] Here the issue is thorny. The point is: a given resource is dedicate= d to a given VN or shared among different ones? We should start considering= network resources partitioning issues... YOUNG>> A given resource is "virtually" dedicated to a particular client; = yet this does not mean a particular client occupies a particular port (say = ODU port 1 vs 2). As long as resource is guaranteed for use to the client,= it is fine for the Working Path at least; however for 1:N kind of protecti= on case, there is a level of sharing backup path resource for multiple clie= nts. - Accuracy of Network Resource Representation As the underlying transport network in itself may consists of layered struc= ture, it is a challenge how to represent these underlying physical network = resources and topology into a form that can be reliably used by the computa= tion engine that assigns the client requests into the physical network reso= urce and topology. [[DC]] Damnly true - Resource Efficiency Related to the accuracy of network resource representation is resource effi= ciency. As a set of independent client VN is created and mapped onto physic= al network resources, the overall network resource utilization is of the pr= imary concern of the infrastructure provider. [[DC]] This issue is pretty much linked to the one above (types of network = resources) YOUNG>> Yes. - Guarantee of Client Isolation While network resource sharing across a set of clients for efficient utiliz= ation is important aspect of network virtualization, client isolation has t= o be guaranteed. Admissions of new client requests or any changes of other = existing clients' VNs must not affect any particular client in terms of res= ource guarantee, security constraints, and other performance constraints. [[DC]] Again linked to issues above. If network resources are dedicated to = each VN, this is true, but if they (or part of them) are shared, the instan= tiation of a service from a given client would impact the VN seen by others= . On the other side, aspects like security o performances should not be imp= acted in any of the two cases. YOUNG>> Agree. So I guess we need to be clear on resource partitioning and= sharing issue clearly --- I think some application/client requires a hard = dedicated resource while for some others it is fluid. - Computing Time Depending on the nature of applications, how quickly a VN is instantiated f= rom the time of request is an important factor. For dynamic applications th= at require instantaneous VN creation, the computation model/algorithm shoul= d support this constraint. [[DC]] I would say that timing constraints need to be met for service provi= sioning (i.e. upon client requests on a given VN) but I think VN instantiat= ion could be also a non real time procedure. I might be wrong...are there u= se cases for real time and timing constrained VN creation requrests? YOUNG>> Again here what I meant was service request. I need to be clear on= the terminology. If we were to define VN creation as the process of negot= iation (similar to SLA negotiation), the initial VN creation is always off-= line (static and non-real time). Once the initial VN creation negotiation i= s done, then there might be cases where VN can be re-negotiated on the fly = (e.g., changing some b/w or service objectives, or some physical failures s= uch as fiber cut). But this is not VN creation; we need to distinguish this= from VN re-negotiation. - Admission Control To coordinate the request process of multiple clients, an admission control= will help maximize an overall efficiency. [[DC]] Yes. To understand where is the best place to do that. Cline control= ? VNC? YOUNG>> As there are many clients that the VNC needs to support, I assume V= NC has to have admission control module at the least. Client Controller, ho= wever, may have its own admission control for supporting multiple applicati= ons. We need to recognize a recursive client-server relationship. As long a= s controller is a server controller of any sort, then admission control fun= ction would help to coordinate its clients. - Path Constraints There may be some factors of path constraints that can affect the overall e= fficiency. Path Split can lower VN request blocking if the underlying netwo= rk can support such capability. Packet-based TE network can support path sp= lit while circuit-based transport may have a limitation. Path migration is= a technique that allows changes of nodes or links assignment of the establ= ished paths in an effort to accommodate new requests which would not be acc= epted without path migration. This can improve overall efficiency, yet addi= tional care needs to be applied to avoid any adverse impacts associated wit= h changing the existing paths. Re-optimization is a global process to re-shuffle all existing path assignm= ent to minimize network resource fragmentation. Again, an extra care needs = to be applied for re-optimization. [[DC]] True. With path constraints I think we should include something more= . When a client needs to setup a service/LSP there might be TE constraints = associated to the request. Whan the VN needs to include is not only reachab= ility information but in many cases is should be TE-reachability informatio= n. In this case we could leverage on the overlay work being done e.g. in CC= AMP and in (http://tools.ietf.org/html/draft-farrel-interconnected-te-info-= exchange-02). YOUNG>> Yes, if we include non-TE underlying transport as part of the ACTN = scope, then the TE-reacheability needs to be known/advertised by the serve= r network to clients as 'capability' attribute. --_000_7AEB3D6833318045B4AE71C2C87E8E1729BA4A59dfweml510mbxchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Daniele,=

 

Thanks for your feedba= ck and comments. Please see inline for my reply.

 

Thanks.

Young

 

From: Daniele = Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Friday, December 20, 2013 4:30 AM
To: Leeyoung; actn@ietf.org
Cc: sdn@irtf.org
Subject: RE: [Actn] virtual network mapping/embedding (VNM/VNE) prob= lem

 

Hi Young,

 

Thanks for the pointer= s and the list of issues.

 

Please find in line so= me loud thinking from my side.

 

BR
Daniele

 

From: ACTN [mailto:actn-bounces@ietf.org] On Behalf Of Leeyoung
Sent: marted=EC 17 dicembre 2013 17:34
To: actn@ietf.org
Cc: sdn@irtf.org
Subject: [Actn] virtual network mapping/embedding (VNM/VNE) problem<= o:p>

 

Related to the ACTN work, there has been active rese= arch termed “virtual network mapping/embedding (VNM/VNE)”:=

 

Here’s some pointer to key papers:<= /p>

 

http://www-bcf.usc.edu/~minlanyu/writeup/CCR08.pdf (VNE with= path split and path migration)

http://nsm1.cs.uwaterloo.ca/rboutaba/Pa= pers/Conferences/2010/Muntasir10.pdf (survivable VNE)

http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber= =3D5616527 (Resource Efficient VNE)

 

The focus of ACTN perhaps does not have a direct bea= ring with these papers as they are concerned about the VNM/VNE algorithms; = however, these bring some key issues and constraints for virtual network pa= th computation. These issues and constraints should be of interest of the ACTN work that may impact on the design, info= rmation models and interface/protocol extensions (if necessary).  Some= of the issues such as efficiency of algorithm are perhaps better fit to SD= N RG,  some of key issues and constraints for virtual network path computation related to VNM/VNE are as follows:

 =

<= ![if !supportLists]>-   Request Processing

This is concerned about whether a set of client requ= ests for VN creation can be dealt with simultaneously or not. This depends = on the nature of applications the client support. If the client does not re= quire real-time instantiation of VN creation, the computation engine can process a set of VN creation requests= simultaneously to improve network efficiency.

[[DC]] I think h= ere we can assume that VN creation requests are non real time. Instantiatio= n of services and bandwidth might be real time (and hence concurrency needs= to be managed) but I would say this is not the case of VN creation.

 

YOUNG>> Good poi= nt.  I was loose on the term ‘VN creation”.  There ar= e certainly negotiation aspects of VN creation which can be viewed as non-r= eal time as the client endpoints need to be negotiated with network provider(s) before service creation. Yes, in that sense, I agree with you.= Here what I meant to say was when there are multiple service requests &nbs= p;to setup virtual connections that need not be instantiated real-time, (in= other words, if some request can be queued for a delay scheduling), then a batch processing of multiple reques= ts would be more optimal in general from a network efficiency perspective t= han sequential processing.

 

 

<= a name=3D"_Toc374709104">-   Types of Network Resources

When client makes a VN creation request to the subst= rate network, what kind of network resources is consumed is of concern of b= oth the client and network providers. It depends on the application. For tr= ansport network virtualization, the network resource consumed by the client is primarily network bandwidth tha= t the paths would occupy on the physical link. However, there may be other = resource types such as CPU and memory that need to be considered for certai= n applications. These resource types are a part of the client’s VN request.

[[DC]] Here the = issue is thorny. The point is: a given resource is dedicated to a given VN = or shared among different ones? We should start considering network resourc= es partitioning issues…

 

YOUNG>>  A = given resource is “virtually” dedicated to a particular client;= yet this does not mean a particular client occupies a particular port (say= ODU port 1 vs 2).  As long as resource is guaranteed for use to the client, it is fine for the Working Path at least; however for 1:N k= ind of protection case, there is a level of sharing backup path resource fo= r multiple clients.

 

<= ![if !supportLists]>-   Accuracy of Network Resource Representation

As the underlying transport network in itself may co= nsists of layered structure, it is a challenge how to represent these under= lying physical network resources and topology into a form that can be relia= bly used by the computation engine that assigns the client requests into the physical network resource and to= pology.

[[DC]] Damnly tr= ue

 

<= ![if !supportLists]>-   Resource Efficiency

Related to the accuracy of network resource represen= tation is resource efficiency. As a set of independent client VN is created= and mapped onto physical network resources, the overall network resource u= tilization is of the primary concern of the infrastructure provider.

[[DC]] This issu= e is pretty much linked to the one above (types of network resources)<= /o:p>

 

YOUNG>> Yes.

 

<= ![if !supportLists]>-   Guarantee of Client Isolation

While network resource sharing across a set of clien= ts for efficient utilization is important aspect of network virtualization,= client isolation has to be guaranteed. Admissions of new client requests o= r any changes of other existing clients’ VNs must not affect any particular client in terms of resource guarantee, = security constraints, and other performance constraints. 

[[DC]] Again lin= ked to issues above. If network resources are dedicated to each VN, this is= true, but if they (or part of them) are shared, the instantiation of a ser= vice from a given client would impact the VN seen by others. On the other side, aspects like security o performa= nces should not be impacted in any of the two cases.<= /b>

 

YOUNG>> Agree.&n= bsp; So I guess we need to be clear on resource partitioning and sharing is= sue clearly --- I think some application/client requires a hard dedicated r= esource while for some others it is fluid. 

 

<= ![if !supportLists]>-   Computing Time

Depending on the nature of applications, how quickly= a VN is instantiated from the time of request is an important factor. For = dynamic applications that require instantaneous VN creation, the computatio= n model/algorithm should support this constraint.

[[DC]] I would s= ay that timing constraints need to be met for service provisioning (i.e. up= on client requests on a given VN) but I think VN instantiation could be als= o a non real time procedure. I might be wrong…are there use cases for real time and timing constrained VN= creation requrests?

 

YOUNG>>  Again here what I meant was service request= . I need to be clear on the terminology.  If we were to define VN crea= tion as the process of negotiation (similar to SLA negotiation), the initial VN= creation is always off-line (static and non-real time). Once the initial V= N creation negotiation is done, then there might be cases where VN can be r= e-negotiated on the fly (e.g., changing some b/w or service objectives, or some physical failures such as fiber cu= t). But this is not VN creation; we need to distinguish this from VN re-neg= otiation.

<= ![if !supportLists]>-   Admission Control

To coordinate the request process of multiple client= s, an admission control will help maximize an overall efficiency.

[[DC]] Yes. To u= nderstand where is the best place to do that. Cline control? VNC?

 

YOUNG>> As there= are many clients that the VNC needs to support, I assume VNC has to have a= dmission control module at the least. Client Controller, however, may have = its own admission control for supporting multiple applications. We need to recognize a recursive client-server relationship.= As long as controller is a server controller of any sort, then admission c= ontrol function would help to coordinate its clients.

 

<= a name=3D"_Toc374709110">-   Path Constraints

There may be some factors of path constraints that c= an affect the overall efficiency. Path Split can lower VN request blocking = if the underlying network can support such capability. Packet-based TE netw= ork can support path split while circuit-based transport may have a limitation.  Path migration is a technique that = allows changes of nodes or links assignment of the established paths in an = effort to accommodate new requests which would not be accepted without path= migration. This can improve overall efficiency, yet additional care needs to be applied to avoid any adverse i= mpacts associated with changing the existing paths.

Re-optimization is a global process to re-shuffle al= l existing path assignment to minimize network resource fragmentation. Agai= n, an extra care needs to be applied for re-optimization.

[[DC]] True. Wit= h path constraints I think we should include something more. When a client = needs to setup a service/LSP there might be TE constraints associated to th= e request. Whan the VN needs to include is not only reachability information but in many cases is should be TE-rea= chability information. In this case we could leverage on the overlay work b= eing done e.g. in CCAMP and in (http://tools.iet= f.org/html/draft-farrel-interconnected-te-info-exchange-02).

 

YOUNG>> Yes, if = we include non-TE underlying transport as part of the ACTN scope, then &nbs= p;the TE-reacheability needs to be known/advertised by the server network t= o clients as ‘capability’ attribute.  

--_000_7AEB3D6833318045B4AE71C2C87E8E1729BA4A59dfweml510mbxchi_-- From diego.caviglia@ericsson.com Mon Dec 23 00:02:02 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD6B1AD8C4 for ; Mon, 23 Dec 2013 00:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNgPF_ic1vBw for ; Mon, 23 Dec 2013 00:01:56 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 705C81AD7C1 for ; Mon, 23 Dec 2013 00:01:55 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-d5-52b7edee3a16 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 07.1D.03802.EEDE7B25; Mon, 23 Dec 2013 09:01:50 +0100 (CET) Received: from ESESSMB103.ericsson.se ([169.254.3.125]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0347.000; Mon, 23 Dec 2013 09:01:48 +0100 From: Diego Caviglia To: Leeyoung , Daniele Ceccarelli , "actn@ietf.org" Thread-Topic: [Sdn] [Actn] virtual network mapping/embedding (VNM/VNE) problem Thread-Index: AQHO/bdeyrxcXYsoskm9e7JN2Y4fJJphautg Date: Mon, 23 Dec 2013 08:01:48 +0000 Message-ID: <4E9BAD336C18BD49A429157A855607F11C52C2A2@ESESSMB103.ericsson.se> References: <7AEB3D6833318045B4AE71C2C87E8E1729BA3CFF@dfweml510-mbx.china.huawei.com> <4A1562797D64E44993C5CBF38CF1BE4812662B06@ESESSMB301.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729BA4A59@dfweml510-mbx.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729BA4A59@dfweml510-mbx.china.huawei.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_4E9BAD336C18BD49A429157A855607F11C52C2A2ESESSMB103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM+Jvre67t9uDDJb2W1ps6bnAZjFtnqvF +QXPWRyYPVqOvGX1WLLkJ5PH5I2H2QKYo7hsUlJzMstSi/TtErgypvXtZy2YMI2pYnXXfKYG xqfvGLsYOTkkBEwkFvX/ZoWwxSQu3FvP1sXIxSEkcIhR4tPcaYwQzhJGiSPvr7ODVLEJGEns 6pjJAmKLCFRLrPpxDaybWUBR4sTzZ0ANHBzCAr4Sm3tcIEoCJP7+m84EYRtJNPVPAWtlEVCV WLZ5JdhIXqDyeVPOMUPsesoosezeRTaQBKdAmMSGhxfA5jMKyEpM2L2IEWKXuMStJ/OZIK4W kFiy5zwzhC0q8fLxP1aQGySA7lneLwdRni+xoOUz1C5BiZMzn7BMYBSdhWTSLCRls5CUQcR1 JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG9lWM7LmJmTnp5UabGIGRdnDLb9UdjHfOiRxilOZg URLn/fDWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY0Pt9nN3up+3cweuPbPKrdfh9KRy K25lyUtfnK2m2546kHxj+fdcvSXiv3gkd3VwPGL20tx4jUlezLO9+4bNZK4NjZtCP09auJ19 q0PMu22N0zcdOOspoXygZMGpuZm3NoX+Xf+Pb5uk+Pvafd/EuTiPudgcWBxj8dVM/JXG3R3y H2tT0uSqbiuxFGckGmoxFxUnAgA4aS9/ggIAAA== Cc: "sdn@irtf.org" Subject: Re: [Sdn] [Actn] virtual network mapping/embedding (VNM/VNE) problem X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 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, 23 Dec 2013 08:02:02 -0000 --_000_4E9BAD336C18BD49A429157A855607F11C52C2A2ESESSMB103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all some more thought with some cleaning BR and Season greetings! D - Request Processing This is concerned about whether a set of client requests for VN creation ca= n be dealt with simultaneously or not. This depends on the nature of applic= ations the client support. If the client does not require real-time instant= iation of VN creation, the computation engine can process a set of VN creat= ion requests simultaneously to improve network efficiency. [[DC]] I think here we can assume that VN creation requests are non real ti= me. Instantiation of services and bandwidth might be real time (and hence c= oncurrency needs to be managed) but I would say this is not the case of VN = creation. YOUNG>> Good point. I was loose on the term 'VN creation". There are cert= ainly negotiation aspects of VN creation which can be viewed as non-real ti= me as the client endpoints need to be negotiated with network provider(s) b= efore service creation. Yes, in that sense, I agree with you. Here what I m= eant to say was when there are multiple service requests to setup virtual = connections that need not be instantiated real-time, (in other words, if so= me request can be queued for a delay scheduling), then a batch processing o= f multiple requests would be more optimal in general from a network efficie= ncy perspective than sequential processing. [DC] yes and this is one of the biggest advantage of a centralized approach= versus a distributed one, that is the possibility to compute the optimal s= olution of a bunch of requests - Types of Network Resources When client makes a VN creation request to the substrate network, what kind= of network resources is consumed is of concern of both the client and netw= ork providers. It depends on the application. For transport network virtual= ization, the network resource consumed by the client is primarily network b= andwidth that the paths would occupy on the physical link. However, there m= ay be other resource types such as CPU and memory that need to be considere= d for certain applications. These resource types are a part of the client's= VN request. [[DC]] Here the issue is thorny. The point is: a given resource is dedicate= d to a given VN or shared among different ones? We should start considering= network resources partitioning issues... YOUNG>> A given resource is "virtually" dedicated to a particular client; = yet this does not mean a particular client occupies a particular port (say = ODU port 1 vs 2). As long as resource is guaranteed for use to the client,= it is fine for the Working Path at least; however for 1:N kind of protecti= on case, there is a level of sharing backup path resource for multiple clie= nts. [DC] well at least tributary port can't be virtual I need to nail it to a p= hysical numbering to physically connect the HW, for the rest I agree. - Accuracy of Network Resource Representation As the underlying transport network in itself may consists of layered struc= ture, it is a challenge how to represent these underlying physical network = resources and topology into a form that can be reliably used by the computa= tion engine that assigns the client requests into the physical network reso= urce and topology. [[DC]] Damnly true [DC] I vote for a KISS approach :) - Resource Efficiency Related to the accuracy of network resource representation is resource effi= ciency. As a set of independent client VN is created and mapped onto physic= al network resources, the overall network resource utilization is of the pr= imary concern of the infrastructure provider. [[DC]] This issue is pretty much linked to the one above (types of network = resources) YOUNG>> Yes. - Guarantee of Client Isolation While network resource sharing across a set of clients for efficient utiliz= ation is important aspect of network virtualization, client isolation has t= o be guaranteed. Admissions of new client requests or any changes of other = existing clients' VNs must not affect any particular client in terms of res= ource guarantee, security constraints, and other performance constraints. [[DC]] Again linked to issues above. If network resources are dedicated to = each VN, this is true, but if they (or part of them) are shared, the instan= tiation of a service from a given client would impact the VN seen by others= . On the other side, aspects like security o performances should not be imp= acted in any of the two cases. YOUNG>> Agree. So I guess we need to be clear on resource partitioning and= sharing issue clearly --- I think some application/client requires a hard = dedicated resource while for some others it is fluid. [DC] yes and this will give to the carriers the possibility to differentiat= e their service offering, do you want guaranteed bandwidth in case of multi= ple failures? Then you have to pay more. - Computing Time Depending on the nature of applications, how quickly a VN is instantiated f= rom the time of request is an important factor. For dynamic applications th= at require instantaneous VN creation, the computation model/algorithm shoul= d support this constraint. [[DC]] I would say that timing constraints need to be met for service provi= sioning (i.e. upon client requests on a given VN) but I think VN instantiat= ion could be also a non real time procedure. I might be wrong...are there u= se cases for real time and timing constrained VN creation requrests? YOUNG>> Again here what I meant was service request. I need to be clear on= the terminology. If we were to define VN creation as the process of negot= iation (similar to SLA negotiation), the initial VN creation is always off-= line (static and non-real time). Once the initial VN creation negotiation i= s done, then there might be cases where VN can be re-negotiated on the fly = (e.g., changing some b/w or service objectives, or some physical failures s= uch as fiber cut). But this is not VN creation; we need to distinguish this= from VN re-negotiation. - Admission Control To coordinate the request process of multiple clients, an admission control= will help maximize an overall efficiency. [[DC]] Yes. To understand where is the best place to do that. Cline control= ? VNC? YOUNG>> As there are many clients that the VNC needs to support, I assume V= NC has to have admission control module at the least. Client Controller, ho= wever, may have its own admission control for supporting multiple applicati= ons. We need to recognize a recursive client-server relationship. As long a= s controller is a server controller of any sort, then admission control fun= ction would help to coordinate its clients. - Path Constraints There may be some factors of path constraints that can affect the overall e= fficiency. Path Split can lower VN request blocking if the underlying netwo= rk can support such capability. Packet-based TE network can support path sp= lit while circuit-based transport may have a limitation. Path migration is= a technique that allows changes of nodes or links assignment of the establ= ished paths in an effort to accommodate new requests which would not be acc= epted without path migration. This can improve overall efficiency, yet addi= tional care needs to be applied to avoid any adverse impacts associated wit= h changing the existing paths. Re-optimization is a global process to re-shuffle all existing path assignm= ent to minimize network resource fragmentation. Again, an extra care needs = to be applied for re-optimization. [[DC]] True. With path constraints I think we should include something more= . When a client needs to setup a service/LSP there might be TE constraints = associated to the request. Whan the VN needs to include is not only reachab= ility information but in many cases is should be TE-reachability informatio= n. In this case we could leverage on the overlay work being done e.g. in CC= AMP and in (http://tools.ietf.org/html/draft-farrel-interconnected-te-info-= exchange-02). YOUNG>> Yes, if we include non-TE underlying transport as part of the ACTN = scope, then the TE-reacheability needs to be known/advertised by the serve= r network to clients as 'capability' attribute. --_000_4E9BAD336C18BD49A429157A855607F11C52C2A2ESESSMB103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all some more thoug= ht with some cleaning

 

BR and Season greeting= s!

 

D

 

 

 =

-   Request Processing

This is concerned about whether a set of client requ= ests for VN creation can be dealt with simultaneously or not. This depends = on the nature of applications the client support. If the client does not re= quire real-time instantiation of VN creation, the computation engine can process a set of VN creation requests= simultaneously to improve network efficiency.

[[DC]] I think h= ere we can assume that VN creation requests are non real time. Instantiatio= n of services and bandwidth might be real time (and hence concurrency needs= to be managed) but I would say this is not the case of VN creation.

 

YOUNG>> Good poi= nt.  I was loose on the term ‘VN creation”.  There ar= e certainly negotiation aspects of VN creation which can be viewed as non-r= eal time as the client endpoints need to be negotiated with network provider(s) before service creation. Yes, in that sense, I agree with you.= Here what I meant to say was when there are multiple service requests &nbs= p;to setup virtual connections that need not be instantiated real-time, (in= other words, if some request can be queued for a delay scheduling), then a batch processing of multiple reques= ts would be more optimal in general from a network efficiency perspective t= han sequential processing.

[DC] yes and thi= s is one of the biggest advantage of a centralized approach versus a distri= buted one, that is the possibility to compute the optimal solution of a bun= ch of requests

 

 

-   Types of Network Resources

When client makes a VN creation request to the subst= rate network, what kind of network resources is consumed is of concern of b= oth the client and network providers. It depends on the application. For tr= ansport network virtualization, the network resource consumed by the client is primarily network bandwidth tha= t the paths would occupy on the physical link. However, there may be other = resource types such as CPU and memory that need to be considered for certai= n applications. These resource types are a part of the client’s VN request.

[[DC]] Here the = issue is thorny. The point is: a given resource is dedicated to a given VN = or shared among different ones? We should start considering network resourc= es partitioning issues…

 

YOUNG>>  A = given resource is “virtually” dedicated to a particular client;= yet this does not mean a particular client occupies a particular port (say= ODU port 1 vs 2).  As long as resource is guaranteed for use to the client, it is fine for the Working Path at least; however for 1:N k= ind of protection case, there is a level of sharing backup path resource fo= r multiple clients.

[DC] well at lea= st tributary port can’t be virtual I need to nail it to a physical nu= mbering to physically connect the HW, for the rest I agree. 

 

-   Accuracy of Network Resource Representation

As the underlying transport network in itself may co= nsists of layered structure, it is a challenge how to represent these under= lying physical network resources and topology into a form that can be relia= bly used by the computation engine that assigns the client requests into the physical network resource and to= pology.

[[DC]] Damnly tr= ue

[DC] I vote for = a KISS approach J<= /span>

 

-   Resource Efficiency

Related to the accuracy of network resource represen= tation is resource efficiency. As a set of independent client VN is created= and mapped onto physical network resources, the overall network resource u= tilization is of the primary concern of the infrastructure provider.

[[DC]] This issu= e is pretty much linked to the one above (types of network resources)<= /o:p>

 

YOUNG>> Yes.

 

-   Guarantee of Client Isolation

While network resource sharing across a set of clien= ts for efficient utilization is important aspect of network virtualization,= client isolation has to be guaranteed. Admissions of new client requests o= r any changes of other existing clients’ VNs must not affect any particular client in terms of resource guarantee, = security constraints, and other performance constraints. 

[[DC]] Again lin= ked to issues above. If network resources are dedicated to each VN, this is= true, but if they (or part of them) are shared, the instantiation of a ser= vice from a given client would impact the VN seen by others. On the other side, aspects like security o performa= nces should not be impacted in any of the two cases.<= /b>

 

YOUNG>> Agree.&n= bsp; So I guess we need to be clear on resource partitioning and sharing is= sue clearly --- I think some application/client requires a hard dedicated r= esource while for some others it is fluid. 

[DC] yes and thi= s will give to the carriers the possibility to differentiate their service = offering, do you want guaranteed bandwidth in case of multiple failures? Th= en you have to pay more.<= /o:p>

 

-   Computing Time

Depending on the nature of applications, how quickly= a VN is instantiated from the time of request is an important factor. For = dynamic applications that require instantaneous VN creation, the computatio= n model/algorithm should support this constraint.

[[DC]] I would s= ay that timing constraints need to be met for service provisioning (i.e. up= on client requests on a given VN) but I think VN instantiation could be als= o a non real time procedure. I might be wrong…are there use cases for real time and timing constrained VN= creation requrests?

 

YOUNG>>  Again here what I meant was service request= . I need to be clear on the terminology.  If we were to define VN crea= tion as the process of negotiation (similar to SLA negotiation), the initial VN= creation is always off-line (static and non-real time). Once the initial V= N creation negotiation is done, then there might be cases where VN can be r= e-negotiated on the fly (e.g., changing some b/w or service objectives, or some physical failures such as fiber cu= t). But this is not VN creation; we need to distinguish this from VN re-neg= otiation.

-   Admission Control

To coordinate the request process of multiple client= s, an admission control will help maximize an overall efficiency.

[[DC]] Yes. To u= nderstand where is the best place to do that. Cline control? VNC?

 

YOUNG>> As there= are many clients that the VNC needs to support, I assume VNC has to have a= dmission control module at the least. Client Controller, however, may have = its own admission control for supporting multiple applications. We need to recognize a recursive client-server relationship.= As long as controller is a server controller of any sort, then admission c= ontrol function would help to coordinate its clients.

 

-   Path Constraints

There may be some factors of path constraints that c= an affect the overall efficiency. Path Split can lower VN request blocking = if the underlying network can support such capability. Packet-based TE netw= ork can support path split while circuit-based transport may have a limitation.  Path migration is a technique that = allows changes of nodes or links assignment of the established paths in an = effort to accommodate new requests which would not be accepted without path= migration. This can improve overall efficiency, yet additional care needs to be applied to avoid any adverse i= mpacts associated with changing the existing paths.

Re-optimization is a global process to re-shuffle al= l existing path assignment to minimize network resource fragmentation. Agai= n, an extra care needs to be applied for re-optimization.

[[DC]] True. Wit= h path constraints I think we should include something more. When a client = needs to setup a service/LSP there might be TE constraints associated to th= e request. Whan the VN needs to include is not only reachability information but in many cases is should be TE-rea= chability information. In this case we could leverage on the overlay work b= eing done e.g. in CCAMP and in (http://tools.iet= f.org/html/draft-farrel-interconnected-te-info-exchange-02).

 

YOUNG>> Yes, if = we include non-TE underlying transport as part of the ACTN scope, then &nbs= p;the TE-reacheability needs to be known/advertised by the server network t= o clients as ‘capability’ attribute.  

--_000_4E9BAD336C18BD49A429157A855607F11C52C2A2ESESSMB103erics_-- From zhang.xian@huawei.com Tue Dec 31 01:02:14 2013 Return-Path: X-Original-To: sdn@ietfa.amsl.com Delivered-To: sdn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4AA1AD6D1 for ; Tue, 31 Dec 2013 01:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.138 X-Spam-Level: X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfnHkLhG2qOX for ; Tue, 31 Dec 2013 01:02:11 -0800 (PST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by ietfa.amsl.com (Postfix) with ESMTP id CC89C1AE145 for ; Tue, 31 Dec 2013 01:02:09 -0800 (PST) Received: from 172.24.2.119 (EHLO szxeml214-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNY88972; Tue, 31 Dec 2013 17:02:01 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 31 Dec 2013 17:01:45 +0800 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by szxeml401-hub.china.huawei.com (10.82.67.31) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 31 Dec 2013 17:01:44 +0800 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.167]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Tue, 31 Dec 2013 17:01:38 +0800 From: "Zhangxian (Xian)" To: Diego Caviglia , Leeyoung , Daniele Ceccarelli , "actn@ietf.org" Thread-Topic: [Sdn] [Actn] virtual network mapping/embedding (VNM/VNE) problem Thread-Index: AQHO/7VO+OStUqH2F06tUPCRN9xKhppuCJqQ Date: Tue, 31 Dec 2013 09:01:37 +0000 Message-ID: References: <7AEB3D6833318045B4AE71C2C87E8E1729BA3CFF@dfweml510-mbx.china.huawei.com> <4A1562797D64E44993C5CBF38CF1BE4812662B06@ESESSMB301.ericsson.se> <7AEB3D6833318045B4AE71C2C87E8E1729BA4A59@dfweml510-mbx.china.huawei.com> <4E9BAD336C18BD49A429157A855607F11C52C2A2@ESESSMB103.ericsson.se> In-Reply-To: <4E9BAD336C18BD49A429157A855607F11C52C2A2@ESESSMB103.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B301F1F98SZXEMA512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Tue, 31 Dec 2013 07:39:05 -0800 Cc: "sdn@irtf.org" Subject: Re: [Sdn] [Actn] virtual network mapping/embedding (VNM/VNE) problem X-BeenThere: sdn@irtf.org X-Mailman-Version: 2.1.15 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, 31 Dec 2013 09:02:15 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B301F1F98SZXEMA512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQogICBTb21lIGZ1cnRoZXIgdGhvdWdodHMgb24gc29tZSBvZiB0aGUgaXNzdWVz Lg0KDQogICBCVFcsIGlmIGFueW9uZSBpcyBpbnRlcmVzdGVkIHRvIHNlZSB0aGUgc3RhdHVzIHF1 byBvZiBWTkUgcmVzZWFyY2gsIHRoZSBmb2xsb3dpbmcgbWlnaHQgYmUgYSBnb29kIHN0YXJ0aW5n IHBvaW50Og0KDQpodHRwOi8vd3d3LmZpbS51bmktcGFzc2F1LmRlL2ZpbGVhZG1pbi9maWxlcy9s ZWhyc3R1aGwvbWVlci9wdWJsaWNhdGlvbnMvcGRmL0Zpc2NoZXIyMDEzYS5wZGYNCg0KSGFwcHkg bmV3IHllYXIsDQoNClhpYW4NCg0KRnJvbTogc2RuIFttYWlsdG86c2RuLWJvdW5jZXNAaXJ0Zi5v cmddIE9uIEJlaGFsZiBPZiBEaWVnbyBDYXZpZ2xpYQ0KU2VudDogMjAxM8TqMTLUwjIzyNUgMTY6 MDINClRvOiBMZWV5b3VuZzsgRGFuaWVsZSBDZWNjYXJlbGxpOyBhY3RuQGlldGYub3JnDQpDYzog c2RuQGlydGYub3JnDQpTdWJqZWN0OiBSZTogW1Nkbl0gW0FjdG5dIHZpcnR1YWwgbmV0d29yayBt YXBwaW5nL2VtYmVkZGluZyAoVk5NL1ZORSkgcHJvYmxlbQ0KDQpIaSBhbGwgc29tZSBtb3JlIHRo b3VnaHQgd2l0aCBzb21lIGNsZWFuaW5nDQoNCkJSIGFuZCBTZWFzb24gZ3JlZXRpbmdzIQ0KDQpE DQoNCg0KDQotICAgUmVxdWVzdCBQcm9jZXNzaW5nDQpUaGlzIGlzIGNvbmNlcm5lZCBhYm91dCB3 aGV0aGVyIGEgc2V0IG9mIGNsaWVudCByZXF1ZXN0cyBmb3IgVk4gY3JlYXRpb24gY2FuIGJlIGRl YWx0IHdpdGggc2ltdWx0YW5lb3VzbHkgb3Igbm90LiBUaGlzIGRlcGVuZHMgb24gdGhlIG5hdHVy ZSBvZiBhcHBsaWNhdGlvbnMgdGhlIGNsaWVudCBzdXBwb3J0LiBJZiB0aGUgY2xpZW50IGRvZXMg bm90IHJlcXVpcmUgcmVhbC10aW1lIGluc3RhbnRpYXRpb24gb2YgVk4gY3JlYXRpb24sIHRoZSBj b21wdXRhdGlvbiBlbmdpbmUgY2FuIHByb2Nlc3MgYSBzZXQgb2YgVk4gY3JlYXRpb24gcmVxdWVz dHMgc2ltdWx0YW5lb3VzbHkgdG8gaW1wcm92ZSBuZXR3b3JrIGVmZmljaWVuY3kuDQpbW0RDXV0g SSB0aGluayBoZXJlIHdlIGNhbiBhc3N1bWUgdGhhdCBWTiBjcmVhdGlvbiByZXF1ZXN0cyBhcmUg bm9uIHJlYWwgdGltZS4gSW5zdGFudGlhdGlvbiBvZiBzZXJ2aWNlcyBhbmQgYmFuZHdpZHRoIG1p Z2h0IGJlIHJlYWwgdGltZSAoYW5kIGhlbmNlIGNvbmN1cnJlbmN5IG5lZWRzIHRvIGJlIG1hbmFn ZWQpIGJ1dCBJIHdvdWxkIHNheSB0aGlzIGlzIG5vdCB0aGUgY2FzZSBvZiBWTiBjcmVhdGlvbi4N Cg0KWU9VTkc+PiBHb29kIHBvaW50LiAgSSB3YXMgbG9vc2Ugb24gdGhlIHRlcm0goa5WTiBjcmVh dGlvbqGxLiAgVGhlcmUgYXJlIGNlcnRhaW5seSBuZWdvdGlhdGlvbiBhc3BlY3RzIG9mIFZOIGNy ZWF0aW9uIHdoaWNoIGNhbiBiZSB2aWV3ZWQgYXMgbm9uLXJlYWwgdGltZSBhcyB0aGUgY2xpZW50 IGVuZHBvaW50cyBuZWVkIHRvIGJlIG5lZ290aWF0ZWQgd2l0aCBuZXR3b3JrIHByb3ZpZGVyKHMp IGJlZm9yZSBzZXJ2aWNlIGNyZWF0aW9uLiBZZXMsIGluIHRoYXQgc2Vuc2UsIEkgYWdyZWUgd2l0 aCB5b3UuIEhlcmUgd2hhdCBJIG1lYW50IHRvIHNheSB3YXMgd2hlbiB0aGVyZSBhcmUgbXVsdGlw bGUgc2VydmljZSByZXF1ZXN0cyAgdG8gc2V0dXAgdmlydHVhbCBjb25uZWN0aW9ucyB0aGF0IG5l ZWQgbm90IGJlIGluc3RhbnRpYXRlZCByZWFsLXRpbWUsIChpbiBvdGhlciB3b3JkcywgaWYgc29t ZSByZXF1ZXN0IGNhbiBiZSBxdWV1ZWQgZm9yIGEgZGVsYXkgc2NoZWR1bGluZyksIHRoZW4gYSBi YXRjaCBwcm9jZXNzaW5nIG9mIG11bHRpcGxlIHJlcXVlc3RzIHdvdWxkIGJlIG1vcmUgb3B0aW1h bCBpbiBnZW5lcmFsIGZyb20gYSBuZXR3b3JrIGVmZmljaWVuY3kgcGVyc3BlY3RpdmUgdGhhbiBz ZXF1ZW50aWFsIHByb2Nlc3NpbmcuDQpbRENdIHllcyBhbmQgdGhpcyBpcyBvbmUgb2YgdGhlIGJp Z2dlc3QgYWR2YW50YWdlIG9mIGEgY2VudHJhbGl6ZWQgYXBwcm9hY2ggdmVyc3VzIGEgZGlzdHJp YnV0ZWQgb25lLCB0aGF0IGlzIHRoZSBwb3NzaWJpbGl0eSB0byBjb21wdXRlIHRoZSBvcHRpbWFs IHNvbHV0aW9uIG9mIGEgYnVuY2ggb2YgcmVxdWVzdHMNCg0KW1hpYW5dIEkgdGhpbmsgd2UgaGF2 ZSBhIHByZXR0eSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBpc3N1ZSBhbmQgYXMgSSB1bmRlcnN0YW5k LCB0aGUgcG9pbnRzIHJlbGF0ZWQgdG8gQUNUTiB3b3VsZCBpbmNsdWRlIGF0IGxlYXN0ICgxKSB3 aGF0IGluZm9ybWF0aW9uIG5lZWRzIHRvIGJlIHBhc3NlZCBmcm9tIGNsaWVudCB0byB2aXJ0dWFs IG5ldHdvcmsgcHJvdmlkZXI/OyAoMikgd2hhdCBjb25zdHJhaW50cyAgdGhlIGNsaWVudCBjYW4g YWNjZXB0ICh0aW1lIG1pZ2h0IGJlIGEgY29uc3RyYWludHMpLiAgSWYgdGhlcmUgaXMgbW9yZSwg cGxlYXNlIGFtZW5kLg0KDQotICAgVHlwZXMgb2YgTmV0d29yayBSZXNvdXJjZXMNCldoZW4gY2xp ZW50IG1ha2VzIGEgVk4gY3JlYXRpb24gcmVxdWVzdCB0byB0aGUgc3Vic3RyYXRlIG5ldHdvcmss IHdoYXQga2luZCBvZiBuZXR3b3JrIHJlc291cmNlcyBpcyBjb25zdW1lZCBpcyBvZiBjb25jZXJu IG9mIGJvdGggdGhlIGNsaWVudCBhbmQgbmV0d29yayBwcm92aWRlcnMuIEl0IGRlcGVuZHMgb24g dGhlIGFwcGxpY2F0aW9uLiBGb3IgdHJhbnNwb3J0IG5ldHdvcmsgdmlydHVhbGl6YXRpb24sIHRo ZSBuZXR3b3JrIHJlc291cmNlIGNvbnN1bWVkIGJ5IHRoZSBjbGllbnQgaXMgcHJpbWFyaWx5IG5l dHdvcmsgYmFuZHdpZHRoIHRoYXQgdGhlIHBhdGhzIHdvdWxkIG9jY3VweSBvbiB0aGUgcGh5c2lj YWwgbGluay4gSG93ZXZlciwgdGhlcmUgbWF5IGJlIG90aGVyIHJlc291cmNlIHR5cGVzIHN1Y2gg YXMgQ1BVIGFuZCBtZW1vcnkgdGhhdCBuZWVkIHRvIGJlIGNvbnNpZGVyZWQgZm9yIGNlcnRhaW4g YXBwbGljYXRpb25zLiBUaGVzZSByZXNvdXJjZSB0eXBlcyBhcmUgYSBwYXJ0IG9mIHRoZSBjbGll bnShr3MgVk4gcmVxdWVzdC4NCltbRENdXSBIZXJlIHRoZSBpc3N1ZSBpcyB0aG9ybnkuIFRoZSBw b2ludCBpczogYSBnaXZlbiByZXNvdXJjZSBpcyBkZWRpY2F0ZWQgdG8gYSBnaXZlbiBWTiBvciBz aGFyZWQgYW1vbmcgZGlmZmVyZW50IG9uZXM/IFdlIHNob3VsZCBzdGFydCBjb25zaWRlcmluZyBu ZXR3b3JrIHJlc291cmNlcyBwYXJ0aXRpb25pbmcgaXNzdWVzoa0NCg0KWU9VTkc+PiAgQSBnaXZl biByZXNvdXJjZSBpcyChsHZpcnR1YWxseaGxIGRlZGljYXRlZCB0byBhIHBhcnRpY3VsYXIgY2xp ZW50OyB5ZXQgdGhpcyBkb2VzIG5vdCBtZWFuIGEgcGFydGljdWxhciBjbGllbnQgb2NjdXBpZXMg YSBwYXJ0aWN1bGFyIHBvcnQgKHNheSBPRFUgcG9ydCAxIHZzIDIpLiAgQXMgbG9uZyBhcyByZXNv dXJjZSBpcyBndWFyYW50ZWVkIGZvciB1c2UgdG8gdGhlIGNsaWVudCwgaXQgaXMgZmluZSBmb3Ig dGhlIFdvcmtpbmcgUGF0aCBhdCBsZWFzdDsgaG93ZXZlciBmb3IgMTpOIGtpbmQgb2YgcHJvdGVj dGlvbiBjYXNlLCB0aGVyZSBpcyBhIGxldmVsIG9mIHNoYXJpbmcgYmFja3VwIHBhdGggcmVzb3Vy Y2UgZm9yIG11bHRpcGxlIGNsaWVudHMuDQpbRENdIHdlbGwgYXQgbGVhc3QgdHJpYnV0YXJ5IHBv cnQgY2Fuoa90IGJlIHZpcnR1YWwgSSBuZWVkIHRvIG5haWwgaXQgdG8gYSBwaHlzaWNhbCBudW1i ZXJpbmcgdG8gcGh5c2ljYWxseSBjb25uZWN0IHRoZSBIVywgZm9yIHRoZSByZXN0IEkgYWdyZWUu DQoNCltYaWFuXSBJIHRoaW5rIFlvdW5nIG1lYW50IHRoZSBwaHlzaWNhbCByZXNvdXJjZSBjYW4g YmUgc2hhcmVkIGJ5IG11bHRpcGxlIGNsaWVudHMsIHByb2JhYmx5IGJ5IGFzc2lnbmluZyB0aGUg c2FtZSBwaHlzaWNhbCBudW1iZXJpbmcgdG8gdGhlIGRpZmZlcmVudCBjbGllbnRzLiBUaGUgcG9p bnQgdGhhdCB3b3J0aCBub3RpbmcgaXMgdGhhdCB3aGV0aGVyIHRoaXMga2luZCBvZiBzaGFyaW5n IGNhbiBtYWtlIHN1cmUgbm8gY29uZmxpY3Qgd291bGQgYXJpc2Ugb3IgaWYgc28sIHdoZXRoZXIg aXQgaXMgYWNjZXB0YWJsZS4NCg0KLSAgIEFjY3VyYWN5IG9mIE5ldHdvcmsgUmVzb3VyY2UgUmVw cmVzZW50YXRpb24NCkFzIHRoZSB1bmRlcmx5aW5nIHRyYW5zcG9ydCBuZXR3b3JrIGluIGl0c2Vs ZiBtYXkgY29uc2lzdHMgb2YgbGF5ZXJlZCBzdHJ1Y3R1cmUsIGl0IGlzIGEgY2hhbGxlbmdlIGhv dyB0byByZXByZXNlbnQgdGhlc2UgdW5kZXJseWluZyBwaHlzaWNhbCBuZXR3b3JrIHJlc291cmNl cyBhbmQgdG9wb2xvZ3kgaW50byBhIGZvcm0gdGhhdCBjYW4gYmUgcmVsaWFibHkgdXNlZCBieSB0 aGUgY29tcHV0YXRpb24gZW5naW5lIHRoYXQgYXNzaWducyB0aGUgY2xpZW50IHJlcXVlc3RzIGlu dG8gdGhlIHBoeXNpY2FsIG5ldHdvcmsgcmVzb3VyY2UgYW5kIHRvcG9sb2d5Lg0KW1tEQ11dIERh bW5seSB0cnVlDQpbRENdIEkgdm90ZSBmb3IgYSBLSVNTIGFwcHJvYWNoIDopDQpbWGlhbl1DYW5u b3QgYWdyZWUgd2l0aCBEaWVnbyBtb3JlLCA6RC4NCg0KLSAgIFJlc291cmNlIEVmZmljaWVuY3kN ClJlbGF0ZWQgdG8gdGhlIGFjY3VyYWN5IG9mIG5ldHdvcmsgcmVzb3VyY2UgcmVwcmVzZW50YXRp b24gaXMgcmVzb3VyY2UgZWZmaWNpZW5jeS4gQXMgYSBzZXQgb2YgaW5kZXBlbmRlbnQgY2xpZW50 IFZOIGlzIGNyZWF0ZWQgYW5kIG1hcHBlZCBvbnRvIHBoeXNpY2FsIG5ldHdvcmsgcmVzb3VyY2Vz LCB0aGUgb3ZlcmFsbCBuZXR3b3JrIHJlc291cmNlIHV0aWxpemF0aW9uIGlzIG9mIHRoZSBwcmlt YXJ5IGNvbmNlcm4gb2YgdGhlIGluZnJhc3RydWN0dXJlIHByb3ZpZGVyLg0KW1tEQ11dIFRoaXMg aXNzdWUgaXMgcHJldHR5IG11Y2ggbGlua2VkIHRvIHRoZSBvbmUgYWJvdmUgKHR5cGVzIG9mIG5l dHdvcmsgcmVzb3VyY2VzKQ0KDQpZT1VORz4+IFllcy4NCltYaWFuXSBUaGlzIHByb2JhYmx5IGlz IG1vcmUgVk5FIGFsZ29yaXRobSByZWxhdGVkLCBpbnN0ZWFkIG9mIEFDVE4sIGJ1dCBmb3Igc3Vy ZSBhbiBpbXBvcnRhbnQgYXNwZWN0IGZvciB0aGUgb3ZlcmFsbCBzb2x1dGlvbi4NCg0KLSAgIEd1 YXJhbnRlZSBvZiBDbGllbnQgSXNvbGF0aW9uDQpXaGlsZSBuZXR3b3JrIHJlc291cmNlIHNoYXJp bmcgYWNyb3NzIGEgc2V0IG9mIGNsaWVudHMgZm9yIGVmZmljaWVudCB1dGlsaXphdGlvbiBpcyBp bXBvcnRhbnQgYXNwZWN0IG9mIG5ldHdvcmsgdmlydHVhbGl6YXRpb24sIGNsaWVudCBpc29sYXRp b24gaGFzIHRvIGJlIGd1YXJhbnRlZWQuIEFkbWlzc2lvbnMgb2YgbmV3IGNsaWVudCByZXF1ZXN0 cyBvciBhbnkgY2hhbmdlcyBvZiBvdGhlciBleGlzdGluZyBjbGllbnRzoa8gVk5zIG11c3Qgbm90 IGFmZmVjdCBhbnkgcGFydGljdWxhciBjbGllbnQgaW4gdGVybXMgb2YgcmVzb3VyY2UgZ3VhcmFu dGVlLCBzZWN1cml0eSBjb25zdHJhaW50cywgYW5kIG90aGVyIHBlcmZvcm1hbmNlIGNvbnN0cmFp bnRzLg0KW1tEQ11dIEFnYWluIGxpbmtlZCB0byBpc3N1ZXMgYWJvdmUuIElmIG5ldHdvcmsgcmVz b3VyY2VzIGFyZSBkZWRpY2F0ZWQgdG8gZWFjaCBWTiwgdGhpcyBpcyB0cnVlLCBidXQgaWYgdGhl eSAob3IgcGFydCBvZiB0aGVtKSBhcmUgc2hhcmVkLCB0aGUgaW5zdGFudGlhdGlvbiBvZiBhIHNl cnZpY2UgZnJvbSBhIGdpdmVuIGNsaWVudCB3b3VsZCBpbXBhY3QgdGhlIFZOIHNlZW4gYnkgb3Ro ZXJzLiBPbiB0aGUgb3RoZXIgc2lkZSwgYXNwZWN0cyBsaWtlIHNlY3VyaXR5IG8gcGVyZm9ybWFu Y2VzIHNob3VsZCBub3QgYmUgaW1wYWN0ZWQgaW4gYW55IG9mIHRoZSB0d28gY2FzZXMuDQoNCllP VU5HPj4gQWdyZWUuICBTbyBJIGd1ZXNzIHdlIG5lZWQgdG8gYmUgY2xlYXIgb24gcmVzb3VyY2Ug cGFydGl0aW9uaW5nIGFuZCBzaGFyaW5nIGlzc3VlIGNsZWFybHkgLS0tIEkgdGhpbmsgc29tZSBh cHBsaWNhdGlvbi9jbGllbnQgcmVxdWlyZXMgYSBoYXJkIGRlZGljYXRlZCByZXNvdXJjZSB3aGls ZSBmb3Igc29tZSBvdGhlcnMgaXQgaXMgZmx1aWQuDQpbRENdIHllcyBhbmQgdGhpcyB3aWxsIGdp dmUgdG8gdGhlIGNhcnJpZXJzIHRoZSBwb3NzaWJpbGl0eSB0byBkaWZmZXJlbnRpYXRlIHRoZWly IHNlcnZpY2Ugb2ZmZXJpbmcsIGRvIHlvdSB3YW50IGd1YXJhbnRlZWQgYmFuZHdpZHRoIGluIGNh c2Ugb2YgbXVsdGlwbGUgZmFpbHVyZXM/IFRoZW4geW91IGhhdmUgdG8gcGF5IG1vcmUuDQoNCi0g ICBDb21wdXRpbmcgVGltZQ0KRGVwZW5kaW5nIG9uIHRoZSBuYXR1cmUgb2YgYXBwbGljYXRpb25z LCBob3cgcXVpY2tseSBhIFZOIGlzIGluc3RhbnRpYXRlZCBmcm9tIHRoZSB0aW1lIG9mIHJlcXVl c3QgaXMgYW4gaW1wb3J0YW50IGZhY3Rvci4gRm9yIGR5bmFtaWMgYXBwbGljYXRpb25zIHRoYXQg cmVxdWlyZSBpbnN0YW50YW5lb3VzIFZOIGNyZWF0aW9uLCB0aGUgY29tcHV0YXRpb24gbW9kZWwv YWxnb3JpdGhtIHNob3VsZCBzdXBwb3J0IHRoaXMgY29uc3RyYWludC4NCltbRENdXSBJIHdvdWxk IHNheSB0aGF0IHRpbWluZyBjb25zdHJhaW50cyBuZWVkIHRvIGJlIG1ldCBmb3Igc2VydmljZSBw cm92aXNpb25pbmcgKGkuZS4gdXBvbiBjbGllbnQgcmVxdWVzdHMgb24gYSBnaXZlbiBWTikgYnV0 IEkgdGhpbmsgVk4gaW5zdGFudGlhdGlvbiBjb3VsZCBiZSBhbHNvIGEgbm9uIHJlYWwgdGltZSBw cm9jZWR1cmUuIEkgbWlnaHQgYmUgd3JvbmehrWFyZSB0aGVyZSB1c2UgY2FzZXMgZm9yIHJlYWwg dGltZSBhbmQgdGltaW5nIGNvbnN0cmFpbmVkIFZOIGNyZWF0aW9uIHJlcXVyZXN0cz8NCg0KWU9V Tkc+PiAgQWdhaW4gaGVyZSB3aGF0IEkgbWVhbnQgd2FzIHNlcnZpY2UgcmVxdWVzdC4gSSBuZWVk IHRvIGJlIGNsZWFyIG9uIHRoZSB0ZXJtaW5vbG9neS4gIElmIHdlIHdlcmUgdG8gZGVmaW5lIFZO IGNyZWF0aW9uIGFzIHRoZSBwcm9jZXNzIG9mIG5lZ290aWF0aW9uIChzaW1pbGFyIHRvIFNMQSBu ZWdvdGlhdGlvbiksIHRoZSBpbml0aWFsIFZOIGNyZWF0aW9uIGlzIGFsd2F5cyBvZmYtbGluZSAo c3RhdGljIGFuZCBub24tcmVhbCB0aW1lKS4gT25jZSB0aGUgaW5pdGlhbCBWTiBjcmVhdGlvbiBu ZWdvdGlhdGlvbiBpcyBkb25lLCB0aGVuIHRoZXJlIG1pZ2h0IGJlIGNhc2VzIHdoZXJlIFZOIGNh biBiZSByZS1uZWdvdGlhdGVkIG9uIHRoZSBmbHkgKGUuZy4sIGNoYW5naW5nIHNvbWUgYi93IG9y IHNlcnZpY2Ugb2JqZWN0aXZlcywgb3Igc29tZSBwaHlzaWNhbCBmYWlsdXJlcyBzdWNoIGFzIGZp YmVyIGN1dCkuIEJ1dCB0aGlzIGlzIG5vdCBWTiBjcmVhdGlvbjsgd2UgbmVlZCB0byBkaXN0aW5n dWlzaCB0aGlzIGZyb20gVk4gcmUtbmVnb3RpYXRpb24uDQotICAgQWRtaXNzaW9uIENvbnRyb2wN ClRvIGNvb3JkaW5hdGUgdGhlIHJlcXVlc3QgcHJvY2VzcyBvZiBtdWx0aXBsZSBjbGllbnRzLCBh biBhZG1pc3Npb24gY29udHJvbCB3aWxsIGhlbHAgbWF4aW1pemUgYW4gb3ZlcmFsbCBlZmZpY2ll bmN5Lg0KW1tEQ11dIFllcy4gVG8gdW5kZXJzdGFuZCB3aGVyZSBpcyB0aGUgYmVzdCBwbGFjZSB0 byBkbyB0aGF0LiBDbGluZSBjb250cm9sPyBWTkM/DQoNCllPVU5HPj4gQXMgdGhlcmUgYXJlIG1h bnkgY2xpZW50cyB0aGF0IHRoZSBWTkMgbmVlZHMgdG8gc3VwcG9ydCwgSSBhc3N1bWUgVk5DIGhh cyB0byBoYXZlIGFkbWlzc2lvbiBjb250cm9sIG1vZHVsZSBhdCB0aGUgbGVhc3QuIENsaWVudCBD b250cm9sbGVyLCBob3dldmVyLCBtYXkgaGF2ZSBpdHMgb3duIGFkbWlzc2lvbiBjb250cm9sIGZv ciBzdXBwb3J0aW5nIG11bHRpcGxlIGFwcGxpY2F0aW9ucy4gV2UgbmVlZCB0byByZWNvZ25pemUg YSByZWN1cnNpdmUgY2xpZW50LXNlcnZlciByZWxhdGlvbnNoaXAuIEFzIGxvbmcgYXMgY29udHJv bGxlciBpcyBhIHNlcnZlciBjb250cm9sbGVyIG9mIGFueSBzb3J0LCB0aGVuIGFkbWlzc2lvbiBj b250cm9sIGZ1bmN0aW9uIHdvdWxkIGhlbHAgdG8gY29vcmRpbmF0ZSBpdHMgY2xpZW50cy4NCg0K LSAgIFBhdGggQ29uc3RyYWludHMNClRoZXJlIG1heSBiZSBzb21lIGZhY3RvcnMgb2YgcGF0aCBj b25zdHJhaW50cyB0aGF0IGNhbiBhZmZlY3QgdGhlIG92ZXJhbGwgZWZmaWNpZW5jeS4gUGF0aCBT cGxpdCBjYW4gbG93ZXIgVk4gcmVxdWVzdCBibG9ja2luZyBpZiB0aGUgdW5kZXJseWluZyBuZXR3 b3JrIGNhbiBzdXBwb3J0IHN1Y2ggY2FwYWJpbGl0eS4gUGFja2V0LWJhc2VkIFRFIG5ldHdvcmsg Y2FuIHN1cHBvcnQgcGF0aCBzcGxpdCB3aGlsZSBjaXJjdWl0LWJhc2VkIHRyYW5zcG9ydCBtYXkg aGF2ZSBhIGxpbWl0YXRpb24uICBQYXRoIG1pZ3JhdGlvbiBpcyBhIHRlY2huaXF1ZSB0aGF0IGFs bG93cyBjaGFuZ2VzIG9mIG5vZGVzIG9yIGxpbmtzIGFzc2lnbm1lbnQgb2YgdGhlIGVzdGFibGlz aGVkIHBhdGhzIGluIGFuIGVmZm9ydCB0byBhY2NvbW1vZGF0ZSBuZXcgcmVxdWVzdHMgd2hpY2gg d291bGQgbm90IGJlIGFjY2VwdGVkIHdpdGhvdXQgcGF0aCBtaWdyYXRpb24uIFRoaXMgY2FuIGlt cHJvdmUgb3ZlcmFsbCBlZmZpY2llbmN5LCB5ZXQgYWRkaXRpb25hbCBjYXJlIG5lZWRzIHRvIGJl IGFwcGxpZWQgdG8gYXZvaWQgYW55IGFkdmVyc2UgaW1wYWN0cyBhc3NvY2lhdGVkIHdpdGggY2hh bmdpbmcgdGhlIGV4aXN0aW5nIHBhdGhzLg0KUmUtb3B0aW1pemF0aW9uIGlzIGEgZ2xvYmFsIHBy b2Nlc3MgdG8gcmUtc2h1ZmZsZSBhbGwgZXhpc3RpbmcgcGF0aCBhc3NpZ25tZW50IHRvIG1pbmlt aXplIG5ldHdvcmsgcmVzb3VyY2UgZnJhZ21lbnRhdGlvbi4gQWdhaW4sIGFuIGV4dHJhIGNhcmUg bmVlZHMgdG8gYmUgYXBwbGllZCBmb3IgcmUtb3B0aW1pemF0aW9uLg0KW1tEQ11dIFRydWUuIFdp dGggcGF0aCBjb25zdHJhaW50cyBJIHRoaW5rIHdlIHNob3VsZCBpbmNsdWRlIHNvbWV0aGluZyBt b3JlLiBXaGVuIGEgY2xpZW50IG5lZWRzIHRvIHNldHVwIGEgc2VydmljZS9MU1AgdGhlcmUgbWln aHQgYmUgVEUgY29uc3RyYWludHMgYXNzb2NpYXRlZCB0byB0aGUgcmVxdWVzdC4gV2hhbiB0aGUg Vk4gbmVlZHMgdG8gaW5jbHVkZSBpcyBub3Qgb25seSByZWFjaGFiaWxpdHkgaW5mb3JtYXRpb24g YnV0IGluIG1hbnkgY2FzZXMgaXMgc2hvdWxkIGJlIFRFLXJlYWNoYWJpbGl0eSBpbmZvcm1hdGlv bi4gSW4gdGhpcyBjYXNlIHdlIGNvdWxkIGxldmVyYWdlIG9uIHRoZSBvdmVybGF5IHdvcmsgYmVp bmcgZG9uZSBlLmcuIGluIENDQU1QIGFuZCBpbiAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtZmFycmVsLWludGVyY29ubmVjdGVkLXRlLWluZm8tZXhjaGFuZ2UtMDIpLg0KDQpZT1VO Rz4+IFllcywgaWYgd2UgaW5jbHVkZSBub24tVEUgdW5kZXJseWluZyB0cmFuc3BvcnQgYXMgcGFy dCBvZiB0aGUgQUNUTiBzY29wZSwgdGhlbiAgdGhlIFRFLXJlYWNoZWFiaWxpdHkgbmVlZHMgdG8g YmUga25vd24vYWR2ZXJ0aXNlZCBieSB0aGUgc2VydmVyIG5ldHdvcmsgdG8gY2xpZW50cyBhcyCh rmNhcGFiaWxpdHmhryBhdHRyaWJ1dGUuDQpbWGlhbl0gSGF2ZSB3ZSBhbHJlYWR5IGNvbmZpbmVk IHRoZSBzY29wZSB0byBURSB0cmFuc3BvcnQgbmV0d29yayBvbmx5Pw0KDQpJIHRoaW5rIHdoZXRo ZXIgdGhlIFRFIGluZm9ybWF0aW9uIGlzIGNvbnZleWVkIHRvIHRoZSBjbGllbnQgZGVwZW5kcyBv biB0aGUgZGV0YWlscyB0aGUgY2xpZW50IHdhbnRzIHRvIGtub3cuIEZyb20gQUNUTiB3b3JrIHBv aW50IG9mIHZpZXcsIGl0IHNob3VsZCBiZSBjb25zaWRlcmVkIGFzIHBhcnQgb2YgdGhlIGNvbnN0 cmFpbnRzIHdvcnRoIGNvbnNpZGVyaW5nLg0K --_000_C636AF2FA540124E9B9ACB5A6BECCE6B301F1F98SZXEMA512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all,

 

   Some further thoughts on some of the issues.

 

   BTW, if anyone is interested to see the status quo o= f VNE research, the following might be a good starting point:

 

http://www.fim.uni-passau.de/filea= dmin/files/lehrstuhl/meer/publications/pdf/Fischer2013a.pdf<= /span>

 

Happy new year,

 

Xian

 

From: sdn [mailto:sdn-bounces@irtf.org] On Behalf Of Diego Caviglia
Sent: 2013=C4=EA12=D4=C223=C8= =D5 16:02
To: Leeyoung; Daniele Ceccarelli; actn@ietf.org
Cc: sdn@irtf.org
Subject: Re: [Sdn] [Actn] virtual network mapping/embedding (VNM/VNE= ) problem

 

Hi all = some more thought with some cleaning

&n= bsp;

BR and = Season greetings!

&n= bsp;

D<= /o:p>

&n= bsp;

&n= bsp;

 

-   Request Processing=

This is concerned about whether= a set of client requests for VN creation can be dealt with simultaneously = or not. This depends on the nature of applications the client support. If t= he client does not require real-time instantiation of VN creation, the computation engine can process a set of = VN creation requests simultaneously to improve network efficiency.

[= [DC]] I think here we can assume that VN creation requests are non real tim= e. Instantiation of services and bandwidth might be real time (and hence co= ncurrency needs to be managed) but I would say this is not the case of VN creation.

&n= bsp;

YOUNG&g= t;> Good point.  I was loose on the term =A1=AEVN creation=A1=B1.&n= bsp; There are certainly negotiation aspects of VN creation which can be vi= ewed as non-real time as the client endpoints need to be negotiated with network provider(s) before service creation. Yes, in that sense, I ag= ree with you. Here what I meant to say was when there are multiple service = requests  to setup virtual connections that need not be instantiated r= eal-time, (in other words, if some request can be queued for a delay scheduling), then a batch processing of multiple= requests would be more optimal in general from a network efficiency perspe= ctive than sequential processing.

[= DC] yes and this is one of the biggest advantage of a centralized approach = versus a distributed one, that is the possibility to compute the optimal so= lution of a bunch of requests

 

[Xian] I think we have a pretty understanding of the issue and as I = understand, the points related to ACTN would include at least (1) what info= rmation needs to be passed from client to virtual network provider?; (2) what constraints  the client can ac= cept (time might be a constraints).  If there is more, please amend.

&n= bsp;

-   Types of Network Resour= ces

When client makes a VN creation= request to the substrate network, what kind of network resources is consum= ed is of concern of both the client and network providers. It depends on th= e application. For transport network virtualization, the network resource consumed by the client is primarily n= etwork bandwidth that the paths would occupy on the physical link. However,= there may be other resource types such as CPU and memory that need to be c= onsidered for certain applications. These resource types are a part of the client=A1=AFs VN request.

[= [DC]] Here the issue is thorny. The point is: a given resource is dedicated= to a given VN or shared among different ones? We should start considering = network resources partitioning issues=A1=AD

&n= bsp;

YOUNG&g= t;>  A given resource is =A1=B0virtually=A1=B1 dedicated to a parti= cular client; yet this does not mean a particular client occupies a particu= lar port (say ODU port 1 vs 2).  As long as resource is guaranteed for use to the client, it is fine for the Working Path at least; however f= or 1:N kind of protection case, there is a level of sharing backup path res= ource for multiple clients.

[= DC] well at least tributary port can=A1=AFt be virtual I need to nail it to= a physical numbering to physically connect the HW, for the rest I agree.&n= bsp;

 

[Xian] I think Young meant the physical resource can be shared by mu= ltiple clients, probably by assigning the same physical numbering to the di= fferent clients. The point that worth noting is that whether this kind of sharing can make sure no conflict woul= d arise or if so, whether it is acceptable.

 

-   Accuracy of Network Res= ource Representation

As the underlying transport net= work in itself may consists of layered structure, it is a challenge how to = represent these underlying physical network resources and topology into a f= orm that can be reliably used by the computation engine that assigns the client requests into the physical netw= ork resource and topology.

[= [DC]] Damnly true

[= DC] I vote for a KISS approach J

[Xian]Cannot agree with Diego more, :D.

 

-   Resource Efficiency

Related to the accuracy of netw= ork resource representation is resource efficiency. As a set of independent= client VN is created and mapped onto physical network resources, the overa= ll network resource utilization is of the primary concern of the infrastructure provider.

[= [DC]] This issue is pretty much linked to the one above (types of network r= esources)

&n= bsp;

YOUNG&g= t;> Yes.

[Xian] This probably is more VNE algorithm related, instead of ACTN,= but for sure an important aspect for the overall solution.

 

-   Guarantee of Client Iso= lation

While network resource sharing = across a set of clients for efficient utilization is important aspect of ne= twork virtualization, client isolation has to be guaranteed. Admissions of = new client requests or any changes of other existing clients=A1=AF VNs must not affect any particular client in = terms of resource guarantee, security constraints, and other performance co= nstraints. 

[= [DC]] Again linked to issues above. If network resources are dedicated to e= ach VN, this is true, but if they (or part of them) are shared, the instant= iation of a service from a given client would impact the VN seen by others. On the other side, aspects like securi= ty o performances should not be impacted in any of the two cases.

&n= bsp;

YOUNG&g= t;> Agree.  So I guess we need to be clear on resource partitioning= and sharing issue clearly --- I think some application/client requires a h= ard dedicated resource while for some others it is fluid. 

[= DC] yes and this will give to the carriers the possibility to differentiate= their service offering, do you want guaranteed bandwidth in case of multip= le failures? Then you have to pay more.

 

-   Computing Time

Depending on the nature of appl= ications, how quickly a VN is instantiated from the time of request is an i= mportant factor. For dynamic applications that require instantaneous VN cre= ation, the computation model/algorithm should support this constraint.

[= [DC]] I would say that timing constraints need to be met for service provis= ioning (i.e. upon client requests on a given VN) but I think VN instantiati= on could be also a non real time procedure. I might be wrong=A1=ADare there use cases for real time and timing constra= ined VN creation requrests?

 

YOUNG>>  Again here what I meant was = service request. I need to be clear on the terminology.  If we were to define VN creation as the process of negotiation (similar to SLA negotiati= on), the initial VN creation is always off-line (static and non-real time).= Once the initial VN creation negotiation is done, then there might be case= s where VN can be re-negotiated on the fly (e.g., changing some b/w or service objectives, or some physica= l failures such as fiber cut). But this is not VN creation; we need to dist= inguish this from VN re-negotiation.

-   Admission Control<= /o:p>

To coordinate the request proce= ss of multiple clients, an admission control will help maximize an overall = efficiency.

[= [DC]] Yes. To understand where is the best place to do that. Cline control?= VNC?

&n= bsp;

YOUNG&g= t;> As there are many clients that the VNC needs to support, I assume VN= C has to have admission control module at the least. Client Controller, how= ever, may have its own admission control for supporting multiple applications. We need to recognize a recursive client-= server relationship. As long as controller is a server controller of any so= rt, then admission control function would help to coordinate its clients.

 

-   Path Constraints=

There may be some factors of pa= th constraints that can affect the overall efficiency. Path Split can lower= VN request blocking if the underlying network can support such capability.= Packet-based TE network can support path split while circuit-based transport may have a limitation.  Path= migration is a technique that allows changes of nodes or links assignment = of the established paths in an effort to accommodate new requests which wou= ld not be accepted without path migration. This can improve overall efficiency, yet additional care needs to be appli= ed to avoid any adverse impacts associated with changing the existing paths= .

Re-optimization is a global pro= cess to re-shuffle all existing path assignment to minimize network resourc= e fragmentation. Again, an extra care needs to be applied for re-optimizati= on.

[= [DC]] True. With path constraints I think we should include something more.= When a client needs to setup a service/LSP there might be TE constraints a= ssociated to the request. Whan the VN needs to include is not only reachability information but in many cases is= should be TE-reachability information. In this case we could leverage on t= he overlay work being done e.g. in CCAMP and in (http://tools.ietf.org/html/draft-farrel-interconnect= ed-te-info-exchange-02).

 

YOUNG&g= t;> Yes, if we include non-TE underlying transport as part of the ACTN s= cope, then  the TE-reacheability needs to be known/advertised by the s= erver network to clients as =A1=AEcapability=A1=AF attribute.  

[Xian] Have we already confined the scope to TE transport network on= ly? 

 

I think whether the TE information is conveyed to the client depends= on the details the client wants to know. From ACTN work point of view, it = should be considered as part of the constraints worth considering.

--_000_C636AF2FA540124E9B9ACB5A6BECCE6B301F1F98SZXEMA512MBSchi_--