1 / 11

Rob Keates Optical Architecture and PLM rkeates@nortel

Implementation Considerations in an On-Demand Switched Lightpath Network Adapting the Network to the Application. Rob Keates Optical Architecture and PLM rkeates@nortel.com. What is SURFnet?. Provides the Dutch National Research Network 150 connected organizations; 800,000 users

nat
Download Presentation

Rob Keates Optical Architecture and PLM rkeates@nortel

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related