User Managed End-To-End Lightpath Provisioning Over CA*net 4

1. 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

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

3. 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

4. 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

5. 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

6. 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

7. Condominium Example

8. 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

9. Connecting Light Spans AS 2 AS 1 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.

10. 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

11. Advertising Resources 2 1 1 Light Span Light Span AS 2 AS 1 AS 3 Light Span Registry • 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

12. 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

13. Distributed Databases 3 1 2 Light Span 1 Light Span AS 2 AS 1 AS 3 Light Span Registry • 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 Light Span Registry

14. Management Tool for UCLP • UCLP – User Controlled Lightpath Provisioning • Distributed management system • Uses JavaSpaces to store all system resources • Uses Jiniservices 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

15. 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

16. 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

17. CA*net 4 • A shared network interconnecting all provincial Optical Regional Advanced Networks (ORANs) • Provides a set of wavelengths that can be sharedby 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

18. 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

19. 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

21. 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 15454 • SCS can communicate with a single switch or an AS cloud that speaks an optical intra-domain routing protocol • GMPLS, O-UNI

22. Interfacing With Network Devices Switch Cloud Output Ports Input Ports Input Ports Output Ports GMPLS CS Interface CS Interface LPOS AS-GMPLS LPOS Cisco 15454 makeXC() makeXC() return return

23. 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

24. 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

25. 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

26. 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

27. Path Searching Strategies • Standards for inter-domain routing for optical networks do not exist • 2 Steps: • 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) • 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

28. 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

29. User Managed End-To-End Lightpath Provisioning Over CA*net 4 Jing Wu jing.wu@crc.ca Scott Campbellscott.campbell@crc.ca Michel Savoie michel.savoie@crc.ca Hanxi Zhang hanxi.zhang@crc.ca Gregor v. Bochmann bochmann@site.uottawa.ca Bill St.Arnaud bill.st.arnaud@canarie.ca