Embed Size (px)
Citation preview
侯自强
2013全球SDN和开放网络高峰会议
狭义的未来网络
后IP网：抛开TCP/IP,“从零开始” Clean state
从FIND 到FIA
广义的未来网络
网络结构的创新：可编程、虚拟化
多种网络并存满足不同业务需求
未来克服互联网在可信赖性、安全性、移动性等方面固有的不足，满足未来网络的需求，美国NSF在2006-2009年安排了未来网络设计‟s Future Internet Design (FIND) 计划。结果并未出现颠覆性创新的方案，而是提出了一批改进方案
2010年在FIND的基础上提出了未来网络体系结构Future Internet Architectures (FIA) 计划。
提出以下要求命名、DNS 功能、寻址、转发、选路、传输、资源分配控制平面与数据平面分开网络测量和管理移动性Mobility情景感知和位置服务可信赖性/安全/隐私演进Evaluation
FIA从20多项建议中选取四项予以支持
• 移动居先Mobility First
– 移动是未来 (蜂窝、无线传感器、机到机、智能电网和车联网将物理世界的感知和控制与互联网应用结合）
• NEBULA
– 24x7 安全通信、计算和存储可用
• 名称数据为Named Data Network (NDN)
– 内容是未来驱动力
• eXpressive Internet Architecture (XIA)
– 设计推动使用（主机-主机，内容检索，服务）和技术（链路、存储、计算）的演进
SDN所倡导的软件化和虚拟化，目前已经成为未来
网络演进发展的重要趋势和特征，相关的技术和协议将被用来构成未来网络基础设施。
SDN可以在一个物理网络基础设施上产生多个虚拟
网络在逻辑上彼此相互隔离，可编程运行不同的协议。
SDN支持现有网络向未来网络演进过渡
SDN为未来网络研究提供实验床
运营商发展SDN应用还是基于正常运行的公共互联网。在保持现有底层传统的拓扑耦合的桥接/路由/交换基本不变的基础上，用SDN在网络上叠加虚拟
化层，用于云架构、智能管道、动态弹性资源分配和流量优化等应用。
在IT业和互联网公司方面，目前SDN主要用于数据中心内部的交换和数据中心之间的互联。SDN以提
升运营效率、提高服务质量、加快业务布放、提高资源利用率等。
建设覆盖全美国的100GE以太网广域网。
混合光-分组基础设施HOPI
引进SDN技术，软件可编程实现
先进的层1服务AL1S-动态电路网DCN
先进的层2服务AL2S
先进的层3服务AL3S
先导实验网NDDI-Openflow实验床
与GENI合作-分片实验网
支持大数据量科学网络ScienceDNZ
开放网络软件堆栈，可编程允许应用创新– 采用软件定义网络SDN推动宽带部署– 采用 OpenFlow作为第一个开放工具，
重点是开放– 提供开放的全国运行环境，欢迎大规模
颠覆性创新技术 倡导推动社区应用开发
Science DMZ支持高性能科学应用包括大块数据移动和数据密集型实验。Science DMZ是校园网的专门部分，位于靠近网络的边缘被设计和配置优化用于高性能科学应用。采用perfSONAR主机，具有特征化和故障排除能力可以快速解决性能问题。
在大楼中设备更新支持SDN
工程、生物、计算机科学教学楼
合作实现全国规模的网络基础设施–分片和深度可编程– 将 OpenFlow/SDN 交换机, GENI Racks,大
学数据中心等结合– 高速(10-100 Gbps 最初)
教员，学生和校园IT组织共享软件 从今天Internet中“原型GENI”骨干网逐步迁移到实际产品系统
正在扩展达到 100-200 GENI校园的预订目标
GENI机柜和校园
• GENI机柜计划扩大可使用的 GENI 基础设施
• 机柜提供可保存的，分片计算和网络资源，使用聚合管理器
• GENI AM API 兼容
目前的 GENI 机柜计划ExoGENI 高端，灵活虚拟联网拓扑解决方案。
包括Openflow和强有力的平台支持多站位晕应用。一般作为校园网络的一部分部署。
InstaGENI 中端，可扩展的GENI机柜解决方案。可以大量部署于校园，提供互联网云应用支持，具有Openflow和YLAN联网能力。
过去的GENI机柜计划 早期低端解决方案Starter Racks 用于“点燃美国T”计划城市
连接到GENI网络，促进实验网络和计算研究及城市应用开发。
EXOGENI
• 14 GPO-funded racks– Partnership between RENCI, Duke and IBM– IBM x3650 M3/M4 servers
• 1x146GB 10K SAS hard drive +1x500GB secondary drive
• 48G RAM• Dual-socket 8-core CPU w/ Sandy Bridge• 10G dual-port Chelseo adapter
– BNT 8264 10G/40G OpenFlow switch– DS3512 6TB sliverable storage
• iSCSI interface for head node image storage as well as experimenter slivering
• Each rack is a small networked cloud– OpenStack-based– EC2 nomenclature for node sizes (m1.small, m1.large etc)– Interconnected by combination of dynamic and static L2
circuits through regionals and national backbones• http://wiki.exogeni.net
Configuration
# Total Hosts 16
# Management Node 1
CPU2 Socket 8 Core E5-2690
2.9GHz
Memory 48GB
HDD1x300GB 15K SAS,
1x500GB 7200 SATA
NIC 2x10GE - vNIC
# Worker Node 15
CPU2 Socket 8 Core E5-2690
2.9GHz
Memory 192GB
HDD1x300GB 15K SAS,
1x500GB 7200 SATA
NIC 2x10GE - vNIC
Management Switch Cat-2960S
OpenFlow Switch Nexus 3064
VPN Appliance ASA5512
UCS 5108 Blade Svr
UCS 6248 Fabric Interconnect x2
ASA 5512 VPN Concentrator
Nexus 3064 OpenFlowswitch
UCS 5108 Blade SvrChassis x2
Cat 2960 Management switch
NOTE: Solution can be scaled down by using just a single UCS B-series shelf* 16 RU excludes the Nexus Switch element & NetApp storage
• Power, cooling, and space efficient, “Wire-once”, policy driven, self-provisioning environment
• UCS B-series uses the Intel e2590 CPU, offering 240 cores for VM hosting in 16RU*• Data-center class solution with flexible expansion options
– ability to scale to thousands of cores
7004
Insta GENI racks
利用SDN实现逻辑上独立的网络分割，与GENI Rack配合形成不同的片slice满足不同的未来互联网实验的需求。
NSF支持的四个未来互联网FIA的实验已经全部放在Internet2/GENI上进行。
MobilityFirst Design: Architecture Features
Routers with IntegratedStorage & ComputingHeterogeneous
Wireless Access
End-Point mobilitywith multi-homing In-network
content cache
Network Mobility &Disconnected Mode
Hop-by-hopfile transport
Edge-awareInter-domainrouting
Named devices, content,and context
11001101011100100…0011Public Key BasedGlobal Identifier (GUID)
Storage-awareIntra-domain
routing
Service API withunicast, multi-homing,mcast, anycast, content query, etc.
Strong authentication, privacy
Ad-hoc p2pmode
Human-readablename
Connectionless Packet Switched Networkwith hybrid name/address routing
MobilityFirst Prototyping: GENI Deployment
OpenFlow Backbones
OpenFlow
WiMAX
ShadowNet
Internet 2
National Lambda Rail
Legend
MobilityFirst Router &GNRS Servers
Mobile Hosts
Static Hosts
Mapping onto GENI Infrastructure (ProtoGENI nodes, OpenFlow switches, GENI Racks, DieselNET buses, WiMAX/outdoor ORBIT nodes)
Deployment Goals
• Large scale, multi-site • Mobility centric• Realistic, live
Potential use of GENI in NEBULA*
26
• GENI Technology:- Enables experiments involving multiple sites- Isolates NEBULA experiments to a single VLAN- Eliminates need for special HW & Address Translation
• Potential Uses:- Multisite student collaboration on Ncore (NEBULA
Core)- Testbed for NDP (NEBULA Data Plane) experiments- Platform for NVENT (NEBULA extensible control plane)- * No GENI-enabled switches on NEBULA campuses-->so
preliminary thoughts
NDN Experimental Infrastructure
Bootstrapping
Lighting Control on N D NC henni Q ian, A lex H orn, A lessandro M arianantoni, Jeff Burke, Paolo G asti, Yanbin Lu
U C L A C enter for R esearch in Engineering, M edia, and Perform ance, U C L A Internet R esearch Lab, N SF C enter for Em bedded N etw orked Sensing, U C I Secure Com puting and N etw orking C enter
Introduction:Secure Building Lighting ControlM otivation & C hallenges
R E M A P
Prelim inary Perform ance A nalysis,A PI Feedback and Future W orkFuture w ork
Automatic enumeration of devices in the NDN network
Interface to traditional dimmers via ArtNet and DMX
ContentObject based control for groups & synchronization
Expand to larger scale and permanent setup in studio
Expand to incorporate dynamic control from other data sources and/or Building Information Modeling
Lighting/Control Synchronization
A pplication Trust/Security A pproach:TrustM odeland K ey M anagem ent
Lighting is an example of a pervasive com puting or Internet of Things application, or more specifically networked-based control systems for
building management. (Others include heating/ventilation/air conditioning;
access control; etc.)
Most modern lighting control systems are transitioning to Ethernet and
incorporating enterprise-wide management for energy management;
Security is most often done by physical network segregation or via VLANs
and firewalls. But, increasing desire to receive over-the-air upgrades
IP-based addressing irrelevant to applications; want to address fixtures by
names that are independent of network topology. IP configurations are
typically brittle for dynamic systems as found in entertainment or other
high-turnover settings.
T Y PIC A l SPATIA L O R G A N IZ ATIO N<campus>/<building>/<floor>/<room>/<fixture>
<campus>/<building::Name_id>/room/<room::Name_id>/lights/fixture/<fixture::Name_id>/rgb-8bit-hex/<fixture::HEX_value>
M IX ED SPA C E-SYST E M O R G A N IZ ATIO N <campus>/<building>/FIXTURE_SYSTEM/<fixture>
<campus>/<building::Name_id>
/lights/fixture/<fixture::Name_id>
/rgb-8bit-hex/<fixture::HEX_value>
N am ing Strategy
G oal: no IP or N D N configuration need to be preconfigured in any fixtures
except for manufacturer supplied:
Asymmetric key pair
Serial number (could simply be a key fingerprint in the future)
Shared secret, which can be transmitted out of band
For now, manufacturer burned-in information is simulated by an https lookup to
a remote table.
1. Standard mechanisms are used for an interface to gain NDN connectivity
on one interface and discover the fixtures on the other. Fixtures start with a
pre-configured name space that is a function of their manufacturer name
(or code) and serial number.
2. After gaining connectivity, devices register the prefix:
/ndn/lighting/<manufacturer>/<serial-number>/key
No IP-like configuration issues
Application-assigned names
Interface on embedded hardware
(For now, Linux on ARM Cortex-7, 500 MHz;
later, try to drive hardware requirements down.)
Secure enough to use on open internet (no replay, injection, etc)
Multiple controlling applications with different capabilities
Scalability (many fixtures)
Quasi-real-time performance (target 50 ms response time)
Demo with LED (by Phillips) and Incandescent (via DMX) lights
Typically addressing unit: the “fixture”
D esign G oals
3. The configuring process (typ. the Configuration Manager) sends
discovery interests in /ndn/lighting to enumerate available fixtures.
4. Once it has located a new fixture, it reads the key data.
5. Out of band, the application possesses the fixture s shared secret and serial
number, as well as a fingerprint of the key if there is a concern about
impersonation on the network.
6. The configuration m anager issues a signed interest that authorizes its public key to configure the light. That interest:
Contains the KeyLocator the configuration manager s public key.
Includes the shared secret of the fixture being addressed, encrypted
by the fixtures public key.
Is signed by the configuring process using a signature concatenated
onto the name.
Signing is after encryption, to allow router verification of packet
signatures.
Applications are identified by their public key, which can be used to sign content and interests; The key is published under one or more prefixes;
Those prefixes also indicate the application’s permissions with respect to
the fixtures
Five application capabilities: nam e, configure, control, read, override. These permissions are being assigned through namespaces.
E.g.
/ucla/facilities/lighting/app/<facnet-app-id>>/name/key
/ucla/facilities/lighting/app/<facnet-app-id>/configure/key
/ucla/facilities/lighting/app/<facnet-app-id>/control/key
/ucla/facilities/lighting/app/<facnet-app-id>/read/key
/ucla/facilities/lighting/app/<facnet-app-id>/override/key
Testbed:L ED Lighting w ith Em bedded Linux Interface
We wish to prevent replay attacks using signed interests, so embed a
counter or timestamp into each message before signing. Maintaining
state, e.g., a 64-bit timestamp or a smaller counter, per fixture per
application key is reasonable.
Sym m etric K ey for H M A C in lieu of signatures
Any application with an authorized public key may choose to use its
public key to obtain a sym m etric key for more computationally
efficient signature verification (using HMACs instead).
That symmetric key is valid for a device-determined amount of time,
and only for the capabilities authorized to the corresponding
application public key.
The interfaces (and thus fixtures and controllers) must support both
asym m etric and sym m etric signatures for any message.
To install a symmetric key, the application should issue a signed interest “com m and”, that has as arguments the symmetric key,
encrypted under the device’s public key, and the requested expiration
date and time.
The device should reply with a ContentO bject, encrypted w ith the sym m etric key, confirming its installation and actual expiration date
and time allowed.
Perm issions
7. After the configuration step, perm issions are granted to newapplications by publishing their keys under nam es thatrepresents their authorized capabilities.They are signed by a
key already authorized for the fixture, thus creating the tuple
<app-key, capability, authorizing-key>.
8. Trust delegation is checked by devices as follows:
1. An application signing key is checked against a cache ofauthorized keys;
2. It is then checked against the built in trust anchor listgenerated through the bootstrapping step above; these areallowed most capabilities.
3. If the signing key is not in the trust anchor list, the fixtureissues an interest for: <path-to-key>/authority/<name-used-to-access-fixture>/<capability> and checks that itis signed by an authorized key.
We explore control of industry-standard LED lighting by Philips Color
Kinetics, which use a proprietary UDP/IP protocol for fixture and power
supply discovery, configuration and control.
Systems consist of an embedded Linux controller (Gumstix Overo, 500 MHz ARM Cortex-A7) that connects to an NDN network on one interface, and an IP network on the other.
Lighting power supplies are on the IP network
Connect to fixtures via a multi-drop serial.
We are developing Python and C software to bootstrap, configure, and
control these fixtures via NDN.
Every entity on the network has an asymmetric key pair: lighting fixtures,
power supplies, embedded interfaces, and applications. Figure 3: NDN Lighting Module
Figure 1: NDN Lighting Control System Overview
Figure 2: NDN Lighting Control Scenario
C C N x C A PI Feedback
API functions seem to work reliably, but coding very common tasks and working with important data structures is quite tedious.
Need an easy to use signing interface for keys that are application-specific, not machine- or user specific.
Name discovery should be the responsibility of the network, or discovery support mechanisms should become libraries in the API.
More documentation and examples would be wonderful.
Roundtrip latency between controlling process and interface code on the Gumstix Overo.
Largest CCNx Experiments So Far
47 CCNx nodes
4 routers
10 switches
60 1 GigE links
Live demo tonight
Experimental results tomorrow
•• SouthfarmSouthfarm : a sensor : a sensor testbedtestbed at a farm south to U IU Cat a farm south to U IU C–– C urrently 9 nodes have been deployed and have been running since 2008C urrently 9 nodes have been deployed and have been running since 2008–– Pow ered by solar energyPow ered by solar energy
•• A pplications:A pplications:–– Bird vocalization recorded by m icrophonesBird vocalization recorded by m icrophones–– Video stream ing from infrared cam erasVideo stream ing from infrared cam eras–– N ode status m onitor: charging current, battery voltageN ode status m onitor: charging current, battery voltage
Solar
Panels
Node Enclosure
Watertight enclosure
WiFi router
ComputerBattery
Deployment Map
Microphone
Wifi Gateway Tower
Camera
♢ Pervasive/mobile computing “infrastructure-less”
testbeds with embedded hardware♢ Real world settings for Internet-of-Things scenarios
♢ Open Network Lab (ONL)♢ Controlled small-scale experiments, especially
forwarding
♢ NDN Overlay Testbed on public Internet♢ Live application testing/use under realistic
conditions
♢ Routing and incremental deployment
♢ PlanetLab♢ Large-scale experiments
♢ Supercharged PlanetLab Platform (SPP) Nodes
♢ High-performance CCNx/NDN forwarding
• Using SPP nodes– Initial software running
on 5 nodes now– Lead: Patrick Crowley
• No other clear needs identified yet
• Possibilities:– Large numbers of nodes
with significant topology control including local broadcast
– Running natively over something other than IP
– NDN “PlanetLab”
NDN and GENI
Kansas City
Houston
NDN Participating Institutions Deployed SPP Nodes
Salt Lake CityWashington DC
Atlanta
Yale
WashUUIUC
Memphis
ColoState
PARC
UCLAUCI
CAIDA/UCSD
Arizona
eXpressive Internet Architecture (XIA) CMU, BU, Wisconsin
Nikhil Handigol et al, Stanford Univ.XIA exploring three concepts to address issues:• Diverse types of end-
points• Intrinsic security• Flexible addressing
Research Infrastructurefor Computer Scientists
Public-Private Partnershipfor Next-Gen Applications
Future commercialofferings
US Ignite is a new organization that will promote advanced applications and infrastructure leveraging GENI research and
technologies.
CS Experiments
Experimental Usage and Demonstrations
Pre-commercial Applications
Regional and backbone networks
Campus and LabApplied Research
Campus networks Municipal andcommercial networks
App creation teams
GENI members, policies, … US Ignite members, policies, …
GEN
I te
chnolo
gy
federation
Service creators
Commercial Applications
GENI US Ignite
CS Research
“点燃美国”计划推动城市下一代宽带应用，GINI与之合作推进成果商业化应用
Internet 2
Brocade MLX Series
Juniper MX SERIES EDGE ROUTERS EX SERIES SWITCH
NEC Programmable Flow UNIVERGE PF5820
GENI RACK
IBM RackSwitch G8264 (BNT8264)
Cisco Nexus 7004 3064
HP E5406
Software-Defined Networking (SDN):
Support for OpenFlow 1.0 in true Layer 3 hybrid-port mode, which enables OpenFlow forwarding and dynamic IPv4/IPv6 routing simultaneously on the same port
• Cisco GENI Rack OpenFlow-capable switches are used in „hybrid‟ mode, offering both traditional „learning‟ switch and OpenFlow 1.0 capabilities at the same time
• Nexus 3064 OpenFlow-capable switch provides high-density 10G ports
• Cisco Nexus 7000 Series Switches provide the foundation for Cisco ® Unified Fabric. They are a modular data center-class product line designed for highly scalable 1/10/40/100 Gigabit Ethernet networks with a fabric architecture that scales beyond 17 terabits per second (Tbps).
EX9200 programmable core switch for 10G, 40G and 100Gbps software-defined networks。 It runs that same 3+-year-old One/Trio ASIC as the MX and form factors are identical, but chassis, line cards, switch fabric, routing engines and software are not 。
EX9200 will be positioned against the Nexus 7000 “M” series in the data center, and against Cisco„s Catalyst 6500E and HP‟s 7500/10500/12500 switches in the campus core with large physical or logical scale, and/or 40/100G requirements
目前在Internet2 中使用
External I/O
ports
6 open module slots; Supports a maximum of 24 10-
GbE ports or 144 autosensing 10/100/1000
ports or 144 mini-GBICs, or a combination
Rack mounting Mounts in an EIA-standard 19 in. telco rack or
equipment cabinet (hardware included);
horizontal surface mounting only
Memory and
processor
Gigabit Module : ARM9 @ 200 MHz, packet buffer size:
144 Mb QDR SDRAM; 10G Module : ARM9 @
200 MHz, packet buffer size: 36 Mb QDR
SDRAM; Management Module : Freescale
PowerPC 8540 @ 666 MHz, 4 MB flash, 128 MB
compact flash, 256 MB DDR SDRAM
Latency 1000 Mb Latency: < 3.7 µs (FIFO 64-byte packets); 10
Gbps Latency: < 2.1 µs (FIFO 64-byte packets)
Routing/switchin
g capacity
322.8 Gbps
Throughput up to 240.2 million pps
S12700内置高速灵活的以太网络处理器ENP，针对• 以太网专属设计。凭借其灵活的报文处理及流量控制能力，深入贴近业务，满足现在及未来的各种挑战，助力客户构建弹性扩展的网络。
在完全覆盖传统交换机能力基础上，S12700通过全可编程开放接口和自定义转发流程，满足企业定制化业务诉求。企业既可以直接利用多层次的开放接口自主开发新的协议、功能，也可以将诉求交由厂商，与厂商共同开发完成，打造企业专属园区网络。
ENP芯片采用全可编程架构，可以完全自定义流量的转发模式、转发行为和查找算法。通过微码编程实现新业务，客户无需更换新的硬件，快速灵活，6个月即可上线。而传统ASIC芯片采用固定的转发架构和转发流程，新业务无法快速部署，需要等待1～3年的硬件支持。
性能优于前述任意一款SDN交换机为我国建设未来网络试验设施提供有力支撑
标准的1RU盒式解决方案高达176Gbps的交换能力，
48X1GE端口和4X10GE端口上实现线速低于65W的功耗
支持cut-through转发，可以获得固定的低传输延迟支持N-FlowTM SDN 创新
支持OpenFlow 1.3.1内嵌2K TCAM流表，支持全域匹配和统计支持32K 12组流表，
内嵌64K基于hash的流表支持 L2 - L4 的全域匹配
支持基于单条流表项的多种动作支持 NvGRE 和 MPLS L2 VPN
支持 QinQ, Meter, Queue 和 Group支持2级流量表
构建支持未来网络体系结构和新协议创新的网络平台-未来网络体系结构创新环境FINE，以期为网络技术创新提供支撑作用。
设计FINE体系结构，研制具有自主知识产权的数据平面
转发抽象技术、开放式网络设备、新型网域操作系统、虚拟化云服务平台等关键技术、新型设备和软件系统
进行多种新网络体系结构和面向安全、移动、新型路由、三网融合等IP新协议的应用示范。
清华大学牵头，中科院计算所、北京邮电大学、东南大学、北京大学、工信部电信研究院、解放军信息工程大学、国防科大和中兴、华为、华三、神州数码、锐捷
三网融合、云计算和物联网发展对现有互联网的可扩展性、安全性、移动性、能耗和服务质量都提出了巨大挑战，基于TCP/IP协议的互联网依靠增加带宽和渐进式改进已经无法满足未来发展的需求。为突破未来网络基础理论和支撑新一代互联网实验，建设未来网络试验设施，主要包括：原创性网络设备系统，资源监控管理系统，涵盖云计算服务、物联网应用、空间信息网络仿真、网络信息安全、高性能集成电路验证以及量子通信网络等开放式网络试验系统。该设施建成后，网络覆盖规模超过10个城市，支撑不少于128个异构网络并行实验，将为空间网络、光网络和量子网络研究提供必要的实验验证条件。
