RISE 3.0: The Design and Implementation of SDN/OpenFlow Testbed Considering Node Capacity and Inflexible Topology

Transcription

1 RISE 3.0: The Design and Implementation of SDN/OpenFlow Testbed Considering Node Capacity and Inflexible Topology National Institute of Information and Communication Technology Nobuhiko Itoh

2 What is RISE? A large-scale SDN/OpenFlow testbed for researchers, students, engineers, operators, Research Infrastructure for large-scale Experiments overlay network on VLAN-based network (called JGN-X) Controller OFS RISE (SDN Testbed) V 0 V 2 JGN-X (VLAN-based NW) 2

3 Tokyo Bangkok Los Angels Singapore Sapporo Sendai StarBED Kanazawa Okayama Fukuoka Osaka Okinawa APAN 38th To Los Angels Tokyo Nagoya To Bangkok, Singapore th Aug. 3

4 What is JGN? JGN : was originally Japan Gigabit Network Established in 1999 and operated by TAO (an ancestor of NICT) From April 2011, JGN-X(JGN extreme) project has been started ATM Wide-area Ethernet Network Virtualization Future Internet An ICT Global testbed for New-Generation-Network (NWGN) and Future-Internet (FI) Technology Fully funded by the Japanese government 4

5 Brief introduction of OpenFlow One of the implementing technologies for Software Defined Network Separation of data-plane and control-plane Data-plane (OpenFlow Switch) function just forwards packets Control-plane (OpenFlow Controller) controls OFSes Data plane OpenFlow Switch (OFS) Control plane OpenFlow Controller (OFC) 5

6 User example of SDN/ OpenFlow in Japan many use case of SDN/Openflow in many business fields East Japan Railway Company Revenue: 2671 billion yen TV Asahi Corporation Nagoya City University Hospital NS Solution Corporation Nippon Jimuki Co., Ltd. Toyo Seikan Group Holdings, Ltd etc ICON th Dec. 6

7 RISE user example: Snow Festival 1GbE 10GbE 100GbE 4K/HD compressed transmission over SDN multipath (multipoint up to 1Gbps) Okinawa (Nago city) 1GbE SDN SW Video transmitter HD Camera Fukuok a 10GbE 4K camera 8K monitor <Configuration in the experiment> Osaka (Umekita, etc) 100G Router 8K+4K uncompressed transmission (Tokyo-Osaka 36Gbps or more) Video transmitter 100GbE 100G compliant high precision analysis 8K monitor (4Kx4) Tokyo (Otemachi) 100G router Video tramsmitter Hokkaido (Sapporo Odori Park, etc) 4K Camera 10GbE ü 4K/8K uncompressed transmission over IP network (>36Gbps) Sendai 4K Camera 8K Camera Video transmitter SDN SW ü Multipath transmission experiment of HD/4K compressed video streaming between Sapporo-Okinawa over SDN testbed RISE on JGN- X (<1Gbps) ü World s first trial of long-distance 8K video streaming transfer on long-distance IP network 1GbE 4K monitor 7

8 RISE user example: KDDI Lab. ICON th Dec. 8

9 RISE version RISE version 1.0 Single user No VM for users MAC address learning issue 2.0 Current Service Multi user support Prepare VM for users resolving MAC address learning issue but, we faced issues through the actual operation Hot Spot Problem 3.0 Next version resolving issues of RISE 2.0 Today s Topic!! 9

10 Since 2009 to Oct RISE 1.0 Service specification Single user Only one user can use RISE No VM for users Q-in-Q in underlay network cause mac address learning problem OF OF OF OF OF OF OF RISE/Openflow plane VLAN-based Testbed Network 10

11 MAC address learning issue OpenFlow can configure this kind of path. JGN-X switch J receives packet whose MAC address is host A from two ports( ). So, switch J is confused (!) Where is host A? Loop? Host A JGN-X switch J Host B??? 11

12 RISE 2.0 Resolving MAC address learning issue Multi user support Using OFS s virtualization function Virtual Switch Instance Prepare VM servers for users Users don t need to bring physical server into Testbed. We have started since Nov as public service 12

13 Resolving MAC address Encapsulate user packets between JGN-X switches to hide MAC address Pseudo Wire(PW), EoMPLS: RFC4448 learning issue So, JGN-X switches are not confused about MAC address learning L L L L L L Resolving MAC address learning issue!! Pseudo Wire 13

14 RISE 2.0: Using Virtual Switch Instance (VSI) function Virtual Switch Instance can treat one physical switch as multi switch up to 16 VSI / OFS NEC IP8800/PF5240 s original function Not OpenFlow standard User VSI Resolving single user Multi User support!! OFS 14

15 RISE 2.0 Architecture Feature Multi-user support with VSI!! Max 16 user / OFS Controller Slice for User#2 Controller Slice for User#1 User VSI Controller RISE (SDN Testbed) OFS Resource Allocation V 0 V 2 JGN-X (VLAN-based NW) 15

16 Problems of RISE 2.0 Hot spot problem consuming VSI resource of partial OFSes because of not full-mesh hot spot VSI relay node e.g. loop topology with four sites, please Fukuoka StarBED Okayama Sapporo Sendai Kanazawa Tokyo Osaka Nagoya Okinawa 16

17 Problems of RISE 2.0 We d like to create topology using vacant node such as Sapporo, Okayama, etc However, we can t create the topology with vacant node because of going through hot spot!! Okinawa Fukuoka Sapporo Sendai Kanazawa StarBED Okayama Tokyo Nagoya Osaka Of course, we can configure additional link (e.g. between Okayama and Sendai) But, it s not easy because of high impact of under layer Okayama Additional link Osaka Nagoya Tokyo Lack of resource Sendai 17

18 Design of RISE 3.0 Target Resolving hot spot problem Design Layered OpenFlow NW Upper layer (U-land) for User restriction max 16 user/ofs Middle layer (K-land) for Operator Non-restriction Under layer (JGN-X-land) U-land User VSI OFS K-land JGN-X-land 18

19 Effect of RISE 3.0 Desirable topology: connecting Okayama and Sendai RISE 2.0 Operator can t create topology with Okayama and Sendai sites without additional link RISE 3.0 Operator can create topology with Okayama and Sendai sites without additional link U-land Okayama Sendai Additional link Osaka Nagoya Tokyo Lack of resource Okayama Osaka Nagoya Tokyo Lack of resource Sendai K-land Okayama Osaka Nagoya Tokyo Sendai JGN-X-land Okayama Sendai Osaka Nagoya Tokyo 19

20 RISE 3.0: Definitions Definitions Logical path: links between User OFSes ID: RISE ID Physical path: links between RISE OFSes ID: VLAN ID User ID: VLAN ID for each user s packet Ua User OFS RISE OFS JGN-X switch Ra Rb Rc vlan id as user id vlan id as physical path L M 20

21 Implementation by rewriting MAC addresses Treat MAC source and destination address as label (RISE ID) Logical path is identified by MAC source and destination address Ua S D L S D S D Ra Rb Rc a 0 b 0 c 0 L Ua M Ua S D M S D Points of K-land routing Ingress rewrite RISE ID into mac fields rewrite physical path id into vlan field Core RISE ID based routing rewrite physical path id into vlan field Egress rewrite original mac address into mac field rewrite vlan id for user into vlan field 21

22 Conclusion Through actual operation using RISE 2.0, we faced the following problem Hot spot problem consuming VSI resource of partial OFSes RISE 3.0 resolving hot spot problem Layered OpenFlow network U-land User OpenFlow network with VSI K-land for Operator without VSI JGN-X-land Future We launch RISE 3.0 Operation within this year 22

23 Thank you! 23