Rob Keates Optical Architecture and PLM rkeates@nortel

1. Implementation Considerations in an On-Demand Switched Lightpath Network Adapting the Network to the Application Rob Keates Optical Architecture and PLM rkeates@nortel.com

2. What is SURFnet? • Provides the Dutch National Research Network • 150 connected organizations; 800,000 users • Production and research foci • Key point is that I have never written foci on a slide before • Similar in scope to US RON • Collaborative partner for ‘practical research’

3. Traffic Characterization • Lightweight users, browsing, mailing, home use • Need full Internet routing, one to many • Business apps, multicast, streaming, VPN’s, mostly LAN • Need VPN services and full Internet routing, several to several + uplink • Special scientific applications, computing, data grids, virtual-presence • Need very fat pipes, limited multiple Virtual Organizations, few to few # u s e r s ΣB ≈ 40 Gb/s ΣC >> 100 Gb/s A ΣA ≈ 20 Gb/s C B GigE ADSL BW requirements Source: C.T. de Laat, University of Amsterdam

4. Dynamic Resource AllocationWhat if we fundamentally changed net eng’g • Change the paradigm of static ‘hard-wired’ networks • An application drives shares of network resources • Resources = {bandwidth, security, acceleration, …} • Within policy-allowed envelopes, end-to-end • No more point-and-click interfaces, no operators’ involved, etc. • Service-enable the network for greater control of such resources • Ex: JIT, TOD-schedulable control of bandwidth • Create alternatives to peak-provisioning across LAN/MAN/WAN • With a continuum of satisfaction vs. utilization fruition points • Tame and exploit network diversity • Heterogeneous and independently managed network clouds, e2e • Ex: Integrated Packet-Optical to best match traffic patterns • Network as a 1st class resource in Grid-like constructs • Joins CPU, DATA resources Adapt the network to the application, not the application to the network

5. Initial Deployment Model Routed IP Network DRAC UNI Control Plane • Packet layer bypass for high bandwidth p2p apps over “virtual l’s” • Service activation initiated by user or app (subject to policy) • GbE services activated over v/c STS paths on a least cost route • Scheduled or on-demand Layer 2/1/0 network (Ethernet over l’s) High-cap user CustomerA network CustomerB network Initial deployment creates an on-demand (or scheduled) GbE service driven by customer or application input

6. Interacting with the service - management • Function 1: Assign nodes, ports and backbone bandwidth to DRAC • DRAC only gets access to selected parts of the network (I-NNI versus NMS) • Clear separation from static production services • Function 2: Access management • Creation of groups, assigning group managers • Policy (allocating ports to groups, resource access limitations) • End users are added to groups by group managers • Function 3: Connection control • Schedule, query, edit, cancel connection • Function 4: Monitoring • State of DRAC-controlled network • Looks at DRAC service only => filtering of “state” • not a replacement for the network management system • Planning view • Usage per link (internal => network dimensioning) • Usage per port, connections • Accounting • Logs of usage

7. Interacting with the service - user • Querying feasibility - before a service is established • Usable UNI and E-NNI ports • List depends on groups user belongs to => AA(A) • Ports and bandwidth available at time of service? • At what cost parameters can I get the service? • Block visibility of the details within the network cloud • Scheduling a service • Query => availability of specific connection • “cost” and other parameters returned • Reserve => confirmation + reference, and guarantee of parameters • Establish=> at requested time service is established automatically • Verifying a reservation • Status request of a reservation (existing, parameters) • Status request of an existing connection (up, down) • Email notification (start, end, failure)

8. End-user GUI snapshot

9. Lessons Learned • Scheduling is important… • And drives a hierarchical architecture • Layered software architecture required to future-proof design • Share the network, but strong isolation required • Allocation and segmentation of network resources • User access and policy management • Secure, simple user access • Flexible resource and group management • Delegate authority where it belongs • Open enough to stimulate initial uptake • Alarms (‘NOC noise’) • Flexibility in required granularity The heavy lifting involves making this stuff deployable into real networks

10. What’s Next? • Extension to other networking technologies • Photonic • Packet (beginning with PBT/PBB) • wireless • Inter-domain • How and what do we standardize? • Workflow integration • Sensors • Compute resource manager interworking • Concept of laxity

11. Summary • Ever-increasing, need to provide network flexibility in addressing diverse applications • Clear role for a mediation device that sits between the network and applications • Nortel is investing in a commercial-grade solution • Targeted at production networks • Architected to evolve to more sophisticated compute/network models via computing partnerships • SURFnet work has proven invaluable in solving the practical deployment issues around user access, security, billing, alarming etc. • Work is being initiated on inter-domain definition • The cool stuff awaits in workflow engagement and cognitive networks