User Managed End-To-End Lightpath Provisioning Over CA*net 4 Jing Wu, Scott Campbell, J. Michel Savoie, Hanxi Zhang, Gregor v. Bochmann, Bill St. Arnaud Presented by: Scott Campbell

Introduction 2 types of customer owned and managed optical networks 1.Metro dark fibre –Control your own connectivity and bandwidth 2.Long-haul wavelength networks –Providers sell or lease point-to-point wavelengths –Customer owns a set of wavelength

Why User Controlled Lightpaths To allow users to share the costs of the optical network but independently manage their own add/drops and cross connects To optimize the overall resource consumption of their network elements More flexibility in network planning and deployment –Can purchase dark fibre/wavelengths from many different independent suppliers

Why cont’d Customers can peer directly with each other and set up bandwidth guaranteed connections. –Can change the peering relationship without having to contact a central management body or pay extra Internet transit fees –Such connections are needed for dedicated QOS and high volume data transfers

Technical Challenges Collaboration among many independent customers without a central manager –Each customer not only receives transport services with other customer domains but also contributes services to other customer domains –A link between two customer domains is controlled equally between them –Policy enforcement, authorization, and authentication must be addressed

Technical Challenges cont’d Managing many independent sources that share the same resources (Condominiums) –Ports on the same switch, Wavelengths on the same fibre –Customer can only view their portions of the network –No central manager has complete view of network Dynamic provisioning of resources to customers –VPN is very static and difficult to make changes

Condominium Example

Creating E2E Connections It may be necessary to concatenate lightpath spans that belong to different parties Peering –The establishment of an E2E connection may involve connecting lightpath spans together that belong to two or more parties Leasing –A party may own a lightpath span between 2 switches that it wishes to make available to others for a fixed period of time

Connecting Light Spans AS 1 AS 2 AS 3 AS 2 can lease its light span to AS 1 to allow it to connect to AS3. Light spans connect at a peering switch in AS 2 that is shared by AS 1 and AS 2.

Advertising Network Resources Resources that are available for peering or leasing should be publicly advertised using service registries –Web Service Directories, I.e. UDDI, WSIL –Jini Lookup Service –JavaSpaces Potential users can query the service registries for available resources or services Resources are advertised as objects allowing meaning full queries to be made to the registries

Advertising Resources AS 1 AS 2 AS 3 AS 1 and AS 2 advertise their available resources in a public registry User in AS 1 can query the registry to find and use resources Light Span Registry Light Span 1 1 2

Distributed Resource Management Connections are being created across several management domains –Each domain has its own database –Even though one party has access to all resources to be connected, It may involve queries to many distributed databases –To ensure concurrency of the data, operations must be mutually exclusive and atomic All Operations must succeed or fail, (Transactions) –The databases must also be persistent and have the ability to recover from a system crash

Distributed Databases AS 1 AS 2 AS 3 Light Span Registry Light Span Light Span Registry 2 AS 1 and AS 2 advertise their available resources to their respective registries Users in AS 1 must query each registry to find available resources

Management Tool for UCLP UCLP – User Controlled Lightpath Provisioning Distributed management system –Uses JavaSpaces to store all system resources –Uses Jini services to manage resources System can be accessed via OGSI Grid methods or by Jini Has an interactive GUI for administering resources and setting up connections

Why use Jini/JavaSpaces Jini hides the underlying complexity of distributed computing from the developer Jini runs on top of Java using RMI The Jini Lookup Service (JLS) provides a distributed service registry –Users can find any service without having any prior knowledge of the location of that service –JLS persists all services registered with it Jini provides mechanisms for distributed events, distributed leases, and transactions

Why Jini/JavaSpaces cont’d JavaSpaces provide a distributed object store for Java objects Objects in a JavaSpace are loosely coupled –Anyone can take an object from a space without knowing or caring about the details of the person who put it there Operations are transactionally secure –Operations on one or many JavaSpaces will either all commit or all fail Like the JLS, JavaSpaces are persistent and support distributed leases

CA*net 4 A shared network interconnecting all provincial Optical Regional Advanced Networks (ORANs) Provides a set of wavelengths that can be shared by all ORANS CA*net 4 is a temporary network (5 years) –It is expected that the provincial ORANs will continue to peer with each other without the help of CA*net 4 –This must be taken into account when designing the UCLP system so it will work without CA*net 4

Life Without CA*net 4 Must design a management and control system that acts as if CA*net 4 does not exist Each ORAN is its own management domain –Provide the resources to interconnect each other –Each switch in CA*net 4 is associated with the ORAN it is directly connected to –The ORAN owns and operates the switch it is connected to, not CA*net 4

Federations A Federation is an administrative domain that has resources to share with others Each ORAN is a member of the same federation as the crossconnect switch that it uses to connect to CA*net 4 –If more than one ORAN connect to CA*net 4 via the same switch, they are members of the same federation –There can be more then one switch in a federation A federation could also be associated with an Autonomous system –Since a single ORAN could have many ASs within it, it is possible to have many federations within an ORAN

UCLP Architecture Each federation has its own set of UCLP services, including its own JavaSpace and JLS CS Interface is a generic interface that allows the Jini services to communicate with any type of switch –CA*net 4 used Cisco ONS SCS can communicate with a single switch or an AS cloud that speaks an optical intra-domain routing protocol –GMPLS, O-UNI

Interfacing With Network Devices GMPLS Input PortsOutput Ports Input Ports Output Ports LPOSCisco makeXC() CS Interface return LPOSAS-GMPLS makeXC() CS Interface return SwitchCloud

Discovering/Advertising Services All Jini services (including JavaSpaces) register with the Jini Lookup Service All Jini Lookup Services register with all other Jini Lookup Services –A client in one federation can access any service in any other federation Grid SAP is accessed via a GUI which the client downloads using Java Web Start –Later implementations will use GIIS to

Distributed Objects Lightpath Object (LPO) –An abstraction of one or more lightpath segments –Has attributes and methods that enable peering with other LPOs at a switch to create an E2E connection Resource Object (RO) –The endpoints of an LPO –Representation of the physical resources on a switch –Shows the cross connection across a switch

Lightpath Management Services User functions –Create and delete connections –Query about the status of their connections –Display user’s resources Admin functions –Create and delete new Lightpath Objects (LPO) –Allocate Resources on the switches –Display all network resources –Perform all user functions

Multiple Access Points Grid SAP –Provides access to the UCLP system via OGSA/OGSI standards To be used by Grid applications –Uses XML/SOAP messaging to allow any type client application to connect and use the system Jini SAP –By-pass the Grid level (for light weight applications) –Can only be used by Jini enabled Java applications –Client downloads Jini SAP directly from the Jini Lookup Service

Path Searching Strategies Standards for inter-domain routing for optical networks do not exist 2 Steps: 1.Find the switches required to crossconnect in order to make the connection (switch path) –Currently using a graph table (much like BGP AS path table) 2.Find resources that are available across the switch path (lightpath objects) –Currently a brute force algorithm that returns all available LPOs along the switch path

Conclusions There is use for customer-managed optical networks in today’s market –Research/education Networks –E-science Web services techniques can be used to setup E2E connections and control optical networks

User Managed End-To-End Lightpath Provisioning Over CA*net 4 Jing Wu Scott Campbell Michel Savoie Hanxi Zhang Gregor v. Bochmann Bill St.Arnaud