Results from the EARNEST Technical Study

Transcription

1 EARNEST Workshop, Amsterdam, 8 May 2007 Results from the EARNEST Technical Study Licia Florio, TERENA florio@terena.org

2 Agenda Technical study Lower layers preliminary results Middleware preliminary results More details on this part of the study

3 Technical Study Transmission technologies Equipment evolution, next-generation standards, transmission protocols & fibre provisioning. Operations and performance End-to-end performance, network management (optical & IP), VPN provisioning & PERT. Control plane technologies Switching & routing matrices (optical & IP), multicasting, IPvX, QoS provisioning. Middleware (new element) Authentication and authorisation infrastructures, identity federations and related technologies, mobility, support for network infrastructure, virtual organisations.

4 Technical Study Panel Lower layers: Lars Fischer (Nordunet) Transmission John Graham (Indiana University) - Transmission Otto Kreiter (DANTE) - Transmission Gigi Karmous-Edwards (MCNC) - Control Plane (Optical) Alexander Gall (SWITCH) - Control Plane (IP routing) Stig Venaas (Uninett) - Control Plane (Multicast) Dimitra Simeonidou (University of Essex) Operations & Performance (Optical) Luca Deri (University of Pisa/Netikos) - Operations & Performance (IP) Simon Leinen (SWITCH) - Operations & Performance (IP) Middleware: Diego Lopez (RedIRIS) - Middleware Milan Sova (CESNET) - Middleware Klaas Wierenga (SURFnet) - Middleware (Mobility)

5 Lower Layers First Results

6 Disclaimer 1. This part of the study was conducted by my colleague, Kevin Meynell > 2. Study conducted via interviews with some major vendors: > So far only router & ethernet switching vendors interviewed. > Some results could different after talking to the network operators

7 Lower Layer First Results Currently only a few OC-768 (40 Gbps) customers, mostly in oil and gas industries Reluctance to upgrade transport network to support 40 Gbps, as expensive (x20 the cost of 4 x 10 GE) and seen as interim step before higher speed standards. SUN seem to move away from 40Gbps Running into problems with n x 10 Gbps, due to link aggregation and load-balancing performance. Cisco, Juniper and Force10 pushing for 100 Gigabit Ethernet standard. 100 GE standard expected by 2009, with implementations by Copper standard for 100 GE being considered.

8 Lower Layers First Results Routing scalability becoming problematic (again) Huge rise in number of hosts, fragmentation of service provider hierarchy, and amount of traffic. Global routing table now >200,000 entries, which is causing memory and processing problems (0.5-1 GB memory required). Other reasons more multihoming, traffic engineering, plus IPv6. Proposed to split IP addresses into identifiers and locators. [Possible implications for AAA as well] Improvements to TCP for sustained high-bandwidth transmissions Juniper pushing (G)MPLS, but Cisco less interested

9 Middleware First Results

10 Why a middleware substudy? It is not just the current buzzword :-) NRENs mission broader: Not only network provisioning, but also services provisioning NRENs more involved in middleware developments/deployment over the last years Federations, eduroam, Grid TERENA EuroCAMPs GEANT2/JRA5 working to create a European middleware framework All NRENs are moving in the same direction Not all NRENs move at the same pace EARNEST will look at how middleware technologies are expected to evolve in the next couple of years

11 What is Identity Management? Identity Management = IdM = Giving each user an electronic identity Set of technologies and policies to control users access to resources

12 IdM Life Cycle Res1

13 IdM Life Cycle basicauthn Res1

14 IdM Life Cycle Res1 Res2 basicauthn

15 IdM Life Cycle Res1 Res2 basicauthn Res1 SSO Res2

16 IdM Life Cycle Res1 basicauthn Res2 SSO Res1 Res2 Resources Resources Resources

17 IdM Life Cycle Res1 basicauthn Res2 SSO Res1 Res2 Resources Resources Resources F e d e r a t i o n

18 IdM Life Cycle Res1 basicauthn Res2 SSO Res1 Res2 Resources Resources Resources F e d e r a t i o n

19 Key Federation Technology SAML, in particular SAML2.0 Security Assertion Markup Language

20 IdM in the European higher education In Europe different technologies used for higher education federations: Liberty Alliance (ID-FF) Norway Shibboleth (SAML-based) UK, Switzerland, Finland, Under development: Denmark, Italy, Germany PAPI Spain A-Select The Netherlands In US: Mainly Shibboleth Many IdM solutions Interoperability one of the key factors SAML (2.0) the way to go

21 Identity Federation Model Trust Identity Provider Service Provider SAML request SAML response redirect

22 IdM from the vendors perspective Identity Management is definitely a big area of interest for vendors Different approaches for SSO: Identity Federations: Liberty Alliance and SUN User centric Identity model Fairly new concept Implemented by Microsoft and OpenID Abstract identity framework (Higgins, IBM) Close to the usercentric identity Some alliances between vendors Probably to compete/cooperate with Microsoft Trust is a big concern for vendors The user centric approach seems to guarantee more privacy to the users

23 User Centric Identity Model User = Identity provider Resource request for user identity information is handled by the user Users decide which credentials and other personal information to present to the resource In the same way users choose which credit card to use for payment Service Provider Identity Provider

24 Middleware Sub-Study Preliminary Findings IBM and Microsoft seem to be working on the same track OpenId has announced cooperation with Microsoft It seems like something will appear on the market in the next ~6 months Shibboleth developers are also talking to Microsoft It is likely that there will be two major tracks: User-centric identity model SAML2-based IdM federations How will these two approaches evolve?

25 Middleware Sub-Study Preliminary Findings Grid Sufficient interest from vendors in what is happening in the Grid space The new user-centric model might fit Grid requirements, but no concrete plans in this direction Middleware to support lightpaths Middleware can be used, for instance, to create lightpaths Different lightpaths for different users

26 Conclusions Some interviews to be finalised on the control-plane and performances side A report will contain all the findings on the technical study Initial report is expected to be available in July 2007