Circuits provisioning in PIONIER with AutoBAHN system. Radek Krzywania

Transcription

1 Circuits provisioning in PIONIER with AutoBAHN system Radek Krzywania

2 ToC Introduction to PIONIER AutoBAHN deployment in PIONIER network Topology Network abstraction Reservation process Potential usage

3 Introduction to PIONIER

4 PIONIER Infrastructure PIONIER is Polish NREN dedicated to interconnect all research and academicals institutions in Poland The infrastructure interconnects 22 MANs and HPC centers PSNC is the operator of PIONIER

5 PIONIER Infrastructure km of own Fiber Optics Cables DWDM Adva equipment for L1 Foundry Networks NetIron XMR 8000 series switches for L2/L3 in 22 MAN centers Juniper M5 router for L3

6 PIONIER Infrastructure MAN Eth 1 Gb/s SDH 2,5 Gb/s 2x10 Gb/s (2 λ) CBDF 10Gb/s (2 λ)

7 PIONIER place in Europe PIONIER in Europe after 5 years of operating: 4 th place among EU i EFTA countries in core network size (Mb/s x km) 1 st place among EU and EFTA countries in core capacity of the network (Mb/s) (equal to SURFnet) The highest number of CBDF links in EU countries (4 operating + 4 more planned in short time scale) 5 th place in outgoing traffic and 6 th in incoming traffic to the NREN backbone Source: TERENA Compendium 2008

8 AutoBAHN deployment in PIONIER network Topology

9 AutoBAHN in PIONIER PSNC is an active partner in GEANT2 JRA3 activity (AutoBAHN) since its very beginning PIONIER testbed infrastructure was one of the first to deploy AutoBAHN instance for dynamic circuit management Testbed equipment is exactly the same as in parallel operational infrastructure

10 PIONIER topology for AutoBAHN NetIron XMR 8000 switches are interconnected with 10Gb/s interfaces AutoBAHN Technology Proxy has access to each of the boxes with CLI interface The resources are seen as single MPLS cloud

11 PIONIER topology for AutoBAHN Technology Proxy is aware of each piece of equipment in the network (all XMR boxes) DM is provided with limited topology information, where only edge switches are present (those connected with end-points or having external connections to neighbour domains) IDM topology is similar to the one at DM level, however the network equipment details are hidden and information about neighbour and global topology is included

12 AutoBAHN deployment in PIONIER network Network abstraction

13 Topology Abstraction Process MPLS cloud abstraction decreases amount of information about physial network topology Only reachability information between domain edge points are provided with additional links metrics The pathfinding is limited to definition of ingres and egres network node and port The intermediate nodes are selected automatically by MPLS with limited influance of administrator or AutoBAHN system

14 MPLS cloud issues for AutoBAHN AutoBAHN was considered at the beginning of work to have full control over physical network resources MPLS cloud abstraction prevents AutoBAHN to see all particular links in the network The overall capacity of network links must be abstracted, which causes loss of some information The control of booked and used network capacity is limited to heuristic accuracy The pathfinding is limited to defining just source and destination end ports and nodes in topology

15 Alternative link capacity constraints Ingress/Egress links limit the capacity allowed to reserve in the network Core network bandwidth is considered to be infinite Network may refuse reservation in case of insufficient bandwidth available Capacity allowed to reserve is limited with policy rule All domain ingress/egress links are associated with one node All end points are associated with single node Technology Proxy must be able to translate DM port names to physical ones Accurate capacity value in policy may prevent reservation denials Allows improved capacity control by network administrators

16 AutoBAHN deployment in PIONIER network Reservation process

17 How Circuits Are Created A User wants to have circuit from some end point in GARR, terminated at file server in PIONIER network GARR and GEANT2 domains provides their constraints set to PIONIER network with request to schedule reservation to the end point from selected ingress point

18 How Circuits Are Created The request is forwarded to PIONIER DM, where pathfinder process is executed and constraints for local domain are given IDM analyze constraints and defines global path attributes, which are send to DM in order to schedule reservation. Again pathfinding is performed, and a path of two nodes and four links are given as a result Links are validated in Calendar module to confirm resources availability Then the resources are booked and reservation is scheduled IDM is informed about successfully created reservation

19 How Circuits Are Created At reservation start time, DM sends request for a circuit implementation to TP TP transform DM topology into physical one and contact proper edge nodes to configure end ports of the circuit The VLL is routed according to internal MPLS procedures

20 AutoBAHN deployment in PIONIER network Potential usage

21 Potential AutoBAHN users in PIONIER SCARIe project AutoBAHN provides connectivity for SCARIe research activities, interconnecting radiotelescopes at global scale One of the radiotelescopes is located physically next to Toruń city (PL) and is connected directly to PIONIER infrastructure

22 Potential AutoBAHN users in PIONIER itpv Interactive Television may require dedicated circuits between data repositories

23 Potential AutoBAHN users in PIONIER Data storage infrastructures multiple data storage infrastructures distributed in Poland may be connected on demand with dedicated links

24 Potential AutoBAHN users in PIONIER Telemedicine dedicated circuits for high quality video streaming HPC centers interconnectivity in Poland VLAB Virtual Laboratories Interconnectivity dedicated for distributed Projects

25 Q&A Thank you

26 GMPLS/G 2 MPLS in PIONIER network Bartosz Belter bartosz.belter@man.poznan.pl Presented by: Radek Krzywania radek.krzywania@man.poznan.pl Poznan Supercomputing and Networking Center

27 BRIEF INTRODUCTION TO G 2 MLPS

28 What is G 2 MPLS? G 2 MPLS is a Network Control Plane architecture that implements the concept of Grid Network Services o GNS is a service that allows the provisioning of network and Grid resources in a single-step, through a set of seamlessly integrated procedures. expected to expose interfaces specific for Grid services made of a set of extensions to the standard GMPLS o provide enhanced network and Grid services for power users / apps (the Grids) G 2 MPLS is not an application-specific architecture; it aims to o support any kind of end-user applications by providing network transport services and procedures that can fall back to the standard GMPLS ones o provide automatic setup and resiliency of network connections for standard users

29 Why G 2 MPLS? uniform interface for the Grid-user to trigger Grid & network resource actions single-step provisioning of Grid and network resources (w.r.t. the dual approach Grid brokers + NRPS-es) adoption of well-established procedures for traffic engineering, resiliency and crankback possible integration of Grids in operational/commercial networks, by overcoming the limitation of Grids operating on dedicated, stand-alone network infrastructures G.O-UNI G 2 Vsite A G 2 G 2 G 2 G.I-NNI G.E-NNI G 2 MPLS NRPS G.O-UNI Grid nodes can be modelled as network nodes with node-level grid resources to be advertised and configured (this is a native task for GMPLS CP) Vsite B Vsite C

30 G 2 MPLS goals G 2 MPLS will provide part of the functionalities related to the selection and co-allocation of both Grid and network resources Co-allocation functionalities Discovery and Advertisement of Grid + network capabilities and resources of the participating virtual sites (Vsites) Service setup / teardown o coordination with local job scheduler in middleware o configuration of the involved network connections among the participating Vsites o (The network end-point TNA might not be specified, if Grid resources are specified) o resiliency mgmt for the installed network connections and possible recovery escalation to the Grid MW for job recovery o advanced reservations of Grid and network resources Service monitoring o retrieving the status of a job (Grid transaction) and of the related network connections

31 GMPLS/G 2 MLPS DEPLOYMENT IN PIONIER NETWORK

32 G 2 MPLS test-bed Transport Plane [1] ADVA FSP 3000RE-II (Lambda Switch) 15 pass through ports 6 local ports 3 physical units Calient Diamond Wave (Fibre Switch) 60 ports 1 physical unit / 4 logical units (switch virtualization) Foundry XMR NetIron 8000 (Ethernet Switch) 2 x 4-port 10GE modules (XFP) 1 x 24-port 1GE module (SFP) 3 physical units

33 G2MPLS test-bed Transport Plane [2] Three technoloy domains: LSC FSC Ethernet Interconnections to other testbeds via GÉANT2 GRID sites are emulated with the PCs connected to the testbed Successful demonstration of G2MPLS features with Distributed Data Storage System (DDSS)

34 G 2 MPLS test-bed Control Plane [1] The Control Plane implemented by a set of G 2 MPLS node controlers Each of them operates exclusively on a Transport Network element (real or derived from partitioning) Each controller is interfaced to the Transport Network equipment (Southbound Interface) through TL1 (ADVA, CALIENT) and SNMP (Foundry XMR) Node controllers run on i bit platform with Gentoo Linux distribution Signaling Control Network (SCN) To transport signaling messages between the CP components Each G 2 MPLS exposes at least one interface on the Signaling Communication Network (SCN) over which the G 2 MPLS protocol messages flow SCN is IP-based with addresses from the private scope. IP tunnelling is used for out of band connectivity between controllers.

35 G 2 MPLS test-bed Control Plane [2] The configuration of the G 2 MPLS CP requires mapping of actual physical topology into the configuration files associated with each of the G 2 MPLS processes Due to complexity of the whole CP design, the following picture covers only a part of the CP configuration (FSC technology domain):

36 G 2 MPLS in PIONIER functional tests 25 test-cards divided into three main areas: LSP signalling o Validate the components of the stack involved in the LSP signalling: G 2.RSVP-TE, LRM, TNRC, SCNGW G 2 MPLS call signalling o Validate the components of the stack involved in the call signalling: Intra-domain scope: G 2.NCC, RC and G 2.RSVP-TE Inter-domain scope: G 2.NCC and G.ENNI-RSVP G 2 MPLS routing o Validate the components of the stack involved in routing: Intra-domain scope: G 2.OSPF-INNI, G 2.OSP-UNI, LRM, SCNGW Inter-domain scope: G 2.OSPF-INNI, G 2.OSPF.ENNI, G 2.OSPF-UNI, LRM, SCNGW Multi-domain test-bed required to validate some of the features achieved by interconnecting local test-beds of PIONIER (Poland) and University of Essex (UK) via GÉANT2 network

37 LSP signalling tests All tests have been done on the LSC/FSC/Ethernet nodes LSP signalling tests No Test Card Test name Status 1 G 2 MPLS-TC-1.1 Network node initialization Passed 2 G 2 MPLS-TC-1.2 Transport Plane notifications from the network node Passed 3 G 2 MPLS-TC-1.3 Setup of one bidirectional LSP Passed 4 G 2 MPLS-TC-1.4 Tear down of one bidirectional LSP from HEAD node Passed 5 G 2 MPLS-TC-1.5 Tear down of one bidirectional LSP from TAIL node Passed 6 G 2 MPLS-TC-1.6 Unsuccessful bidirectional LSP setup (failure in HEAD node) Passed 7 G 2 MPLS-TC-1.7 Unsuccessful bidirectional LSP setup (failure in intermediate node) Passed 8 G 2 MPLS-TC-1.8 Unsuccessful bidirectional LSP setup (failure in TAIL node) Passed 9 G 2 MPLS-TC-1.9 Setup of one bidirectional LSP with advance reservation Passed 10 G 2 MPLS-TC-1.10 Tear down of one bidirectional LSP with advance reservation from HEAD node Passed

38 G 2 MPLS call signalling tests All tests have been done on the LSC/FSC/Ethernet nodes Intra-domain G2MPLS call signalling tests No Test Card Test name Status 11 G 2 MPLS-TC-2.1 Setup of one bidirectional single-domain LSP by G 2.NCC module Passed 12 G 2 MPLS-TC-2.2 Teardown of the one bidirectional single-domain LSP by G 2.NCC module Passed 13 G 2 MPLS-TC-2.3 Setup of one bidirectional single-domain LSP by G 2.CCC module Passed 14 G 2 MPLS-TC-2.4 Teardown of the one bidirectional single-domain LSP by G 2.CCC module Passed 15 G 2 MPLS-TC-2.5 Setup of one bidirectional single-domain LSP by G.UNI-GW module Passed 16 G 2 MPLS-TC-2.6 Teardown of the one bidirectional single-domain LSP by G.UNI-GW module Passed 17 G 2 MPLS-TC-2.7 Setup of one bidirectional single-domain LSP by Middleware Passed WS-Agreement client 18 G 2 MPLS-TC-2.8 Teardown of the one bidirectional single-domain LSP by Middleware WS-Agreement client Passed Inter-domain G2MPLS call signalling tests No Test Card Test name Status 19 G 2 MPLS-TC-2.9 Setup of one bidirectional inter-domain LSP by G 2.CCC Passed 20 G 2 MPLS-TC-2.10 Teardown of the one bidirectional single-domain LSP by G 2.CCC Passed

39 G 2 MPLS routing tests All tests have been done on the LSC/FSC/Ethernet nodes Intra-domain G 2 MPLS routing tests No Test Card Test name Status 21 G 2 MPLS-TC-3.1 I-NNI G 2.OSPF-TE instance initialization Passed 22 G 2 MPLS-TC-3.2 Distribution of TE information through the G.I-NNI interfaces Passed 23 G 2 MPLS-TC-3.3 Distribution of Grid information through the G.UNI and G.I-NNI interfaces Passed Inter-domain G 2 MPLS routing tests No Test Card Test name Status 24 G 2 MPLS-TC-3.4 Routing information exchange between adjacent RAs Passed 25 G 2 MPLS-TC-3.5 Grid information exchange between adjacent RAs Passed

40 Summary Currently, the Open Source G 2 MPLS protocol stack supports the representatives from three main technology areas: LSC, FSC and Ethernet The stack is extendable: quick and simple development of the extensions in support of different vendors and equipment Extensions for cheap Ethernet switches expected soon G 2 MPLS is developed to support UNICORE, but GLOBUS extensions are expected soon

41 Summary G 2 MPLS allows to run any kind of applications, even not bridged by Grid Middleware. It is possible to connect the application directly to the network through G.OUNI, bypassing existing gateways developed for UNICORE Corba interfaces allow easy plug&play of external applications in the G 2 MPLS framework PHOSPHORUS G 2 MPLS is backward compatible with ASON/GMPLS Provides legacy ASON/GMPLS transport services and procedures This compliance fosters the possible integration of Grids in operational and/or commercial networks

42 Q&A Thank you