Transcript 20060718-ondemandswlightpath-keats

Implementation Considerations in an
On-Demand Switched Lightpath Network
Adapting the Network to the Application
Rob Keates
Optical Architecture and PLM
[email protected]
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’
2
NORTEL
Traffic Characterization
#
A. Lightweight users, browsing, mailing, home use
u
s
e
r
s
• Need full Internet routing, one to many
B. Business apps, multicast, streaming, VPN’s, mostly LAN
• Need VPN services and full Internet routing, several to several
+ uplink
C. Special scientific applications, computing, data grids,
virtual-presence
• Need very fat pipes, limited multiple Virtual Organizations,
few to few
ΣB ≈ 40 Gb/s
A
ΣC >> 100 Gb/s
ΣA ≈ 20 Gb/s
C
B
GigE
ADSL
3
Source: C.T. de Laat, University of Amsterdam
NORTEL
BW requirements
Dynamic Resource Allocation
What 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
4
NORTEL
Initial Deployment Model
Routed IP
Network
DRAC
UNI
Control
Plane
Layer 2/1/0 network
(Ethernet over l’s)
High-cap user
Customer
A
network
Customer
B
network
• 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 ondemand
Initial deployment creates an on-demand (or scheduled)
GbE service driven by customer or application input
5
NORTEL
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
6
• Logs of usage
NORTEL
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)
7
NORTEL
End-user GUI snapshot
8
NORTEL
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
9
NORTEL
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
10
NORTEL
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
11
NORTEL