An Inter-domain SDN Testbed and its Fine-grained Routing Application Demonstration

Transcription

1 An Inter-domain SDN Testbed and its Fine-grained Routing Application Demonstration Jun Bi Tsinghua University/CERNET Presenting on behalf of CANS Future Internet WG (FIWG) CANS2014, New York

2 Contributors } Tsinghua Univ./CERNET Prof. Jun Bi Dr. Yangyang Wang (application) Anmin Xu (coding) Yikai Lin (coding) Ze Chen (coding) Pingping Lin Prof. Jilong Wang / Zhonghui Li/Zhiyan Zheng (infrastructure) } CSTNET Dr. Yulei Wu Dr. Yuepeng E (configuration) } BUPT Prof. Yan Ma Prof. Xiaohong Huang Chunbing Zhang (configuration) } Interent2 Steve Wolff John Hicks (configuration) Edward Moynihan Di Lu } SURFnet Ronald van der Pol (configuration)

3 Content Inter-domain SDN: Motivations Inter-domain SDN: Mechanism - WE-Bridge Inter-domain SDN Testbed and Applications (with live demo) Conclusions and Future Work

4 Inter-domain SDN: Motivations

5 Software defined networking (SDN) is one of the hot research topics in networking area Openness decouples the tightly coupled network architecture, and opens up the control plane and the associated protocol Agility Why SDN? SDN enables more flexible network control and management SDN promotes the rapid innovation on networking technologies by programing the network SDN is considered as a promising way to enhance the networks.

6 SDN Architecture Inter-domain SDN APPs North Boundary East-west Boundary Inter-domain control mechanism WE-Bridge South Boundary Inter-domain Infrastructure

7 SDN Research Challenges Inter-domain (Shall we provide real topo., full control to others?) The Internet are managed by owners of different domains, which makes the centralized control doesn t work for inter-domain Scalability Centralized control could not scale to a very large network (may work for a data center or a campus, but not Internet scale) Use cases To improve the feasibility in real world Other Challenges Data plan Security

8 Inter-domain The Internet are managed by owners of different domains, which make the centralized control doesn t work for inter-domain Scalability Centralized control could not scale to a very large network (work for data center, campus, but not Internet scale) Use cases To improve the feasibility in real world Other Challenges Data plan Security SDN Research Challenges Covered by WE-Bridge

9 SDN Peering Design Goals Inter-domain Change centralized resource control by global network view negotiation on inter-domain resource by exchanging domain views Scalability Change logical or physical centralized control distributed mechanism for the Internet scale Use cases We developed Three example use cases and demos Other Challenges Data plain Security

10 WE-Bridge proposed in FINE We proposed a Four-layer FINE (Future Internet innovation Environment) Architecture in China s 863 High-tech R&D project AS-1 (Doman 1) APP-1 APP-2 APP-n AS-2 (Domain 2) APP-1 APP-2 APP-n Logical View API VCP-1 IDN IDN VCP-2 NOS-1 IDN Global Physical View API WE- Bridge IDN NOS-2 Local View API DPA1 DPA2 DPAn DPA1 DPA2 DPAn Open Devices Open Devices

11 Related work Google B4 Google s B4 (SDN for private WAN) is still under one single administrator. Two-level hierarchical centralized control based solution

12 Related work SDX SDX: Software Defined Internet Exchange Center Specific goal: using SDN to connecting traditional BGP domains

13 Inter-domain SDN: Mechanism - WE-Bridge

14 West-East Bridge for SDN Peering Each NOS gathers local network view, then exchange domain view among heterogeneous NOSes by WE-Bridge An APP requires resource in other domains by WE-Bridge NB-API APPs in other domains may accept or deny the request (Negotiation details will be determined by APPs)

15 WE-Bridge: West-East Bridge in SDN Inter-domain Innovation 1 Inter-domain Innovation 2 Inter-domain Innovation N Network view storage North bound API for network view NOS WE-Bridge Network view virtualization Network view distribution West-East Interface Network view learning Network view exchange format

16 Domain View Abstraction: Virtualization Physical view to virtual view (PP: Physical Path; VP: Virtual Path; OF: OpenFlow; S: Switch; bd: bandwidth; t: time; bps: bits per second)

17 Domain View Abstraction: Storage Key Node_ID (physical/virtual) Link_ID (physical/virtual) is_ virtual (first column) is_ virtual (first column) Columns IP_addresses, OF_version, port_numbers, is_edge_node, Vendor_name, MTU Device_type, Device_function Node_ID_src, Port_ID_src, Node_ID_dst, Port_ID_dst, Bandwidth, is_interdomain_link Port_ID (physical/virtual) Node_capbility Reachability Node_table_ID (Flow entity) Link_Utilities Flow_path (Node_ID_src_ Node_ID_dst) is_ virtual (first column) protocol_name, version, port IP_prefixes, length Node_ID, Port_MAC, is_active, is_edge_port, VLAN_ID, throughput Columns names are the same as the fields defined in the flowtable in OpenFlow specification Link_ID, Link utilities Port_ID (in), Node_ID_src, Port_ID (out), Node Series with ingress and egress ports, Port_ID (in), Node_ID_dst, Port_ID (out)

18 Domain View Abstraction: Exchange Format We suggest JSON as a basic implementation, and the XML, YANG, YAML as alternatives. Those languages have the ability to enable WE- Bridge with the following advantages: vendor and application-independent, thus the network view transfer format is independent with the storage systems; allow explicit definition of the inherent structure according to the requirements; such features make the network view message format flexible and easy to extend; they are files and not a data packet format, containing rich content.

19 WE-Bridge Implementation Enable WE-Bridge in all kinds of NOSes by adding three modules: Network Virtualization, East-West Bridge, and LLDP Extension

20 Inter-domain SDN Testbed and Applications (with live demo)

21 CANS13/SuperComputing13/INFOCOM14 Demos for CANS inter-domain SDN testbed TUNOS

22 CANS13/SuperComputing13/INFOCOM14 Demos on Inter-domain SDN APPs

23 CANS Inter-domain SDN testbed today

24 Application demo: Fine-Grained Inter-domain Diff-Serv Routing Traditional differ-serv defines fixed differ-serv bit, and the service action is also fixed In SDN, we can program the networking routing with flexibility: fine granularity inter-domain diff-serv can be achieved by flexiblely defining VIP service by any field in packet header (e.g IP address & UDP port) Installing flow table entries with different service levels (routing actions): when link failure happens, the VIP service could be serve better

25 Demo Introduction NYU Video forwarding VIP Video Conference VOD Cient Ann Arbor Video chat flow selects another path Src = Dst = Udp port =101 VIP Video Conference Addr &UDP Port 5004 Link failure Recover VOD Server Addr & UDP Port 1234

26 Conclusions and Future Work

27 Conclusions To scale SDN to the global level, we need distributed interdomain SDN WE-Bridge is the very first distributed and automatic (Eastwest Boundary APIs) Inter-domain SDN mechanism Distributed domain views exchange NB-APIs provided to APPs to flexibelly define inter-domain routing CANS FIWG deployed the very first inter-domain SDN testbed Among SDN domains in CERNET (Tsinghua, BUPT), INTERNET2, CSTNET, and SURFnet Various inter-domain applications can be easily and quickly deployed Three applications are introduced

28 Future work Plan to extend the inter-domain SDN testbed Japan is interested to join Some universities in China also showed interests to join More APPs and use cases CANS FIWG next demonstrations

29 Thanks!