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

Jing Wu, Scott Campbell, J. Michel Savoie, Hanxi Zhang, Gregor v. Bochmann, Bill St. Arnaud

Presented by: Scott Campbell

IntroductionIntroduction

• 2 types of customer owned and managed optical networks1. 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 LightpathsWhy 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’dWhy 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 ChallengesTechnical 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’dTechnical 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 ExampleCondominium Example

GMPLS

Montreal

Halifax

Fredericton

St. Leonard

Saint John

CA*net 4Optical Network

NB ECN Optical Network

NRC Optical Network

Mirimichi

ASTN

Condominium OXC and OADM

Creating E2E ConnectionsCreating 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 SpansConnecting 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 ResourcesAdvertising 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 ResourcesAdvertising 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

Light Span

1

1

2

Distributed Resource ManagementDistributed 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 DatabasesDistributed Databases

AS 1

AS 2

AS 3

Light Span Registry

Light Span

Light Span

1

1

3

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 UCLPManagement 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/JavaSpacesWhy 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’dWhy 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 4CA*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 4Life 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

FederationsFederations

• 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

JLS

User(OGSI Grid Client)

XML/SOAP

To AS

UCLP Architecture

JiniServices

CS Interface

LPO Service

SwitchCommunication

Service(SCS)

Switch State DBManagement

Switch SpecificFunctions

TL1O-UNI,GMPLS

Jini SAP

User Function Service

Grid Service Access PointAdmin Function Service

LPO DB

Switch State DB

JavaSpace

UCLP ArchitectureUCLP 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

Interfacing With Network DevicesInterfacing With Network Devices

GMPLS

Input Ports Output PortsInput Ports Output Ports

LPOS Cisco 15454

makeXC()

CS Interface

return

LPOS AS-GMPLS

makeXC()

CS Interface

return

Switch Cloud

Discovering/Advertising ServicesDiscovering/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 ObjectsDistributed 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 ServicesLightpath 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 PointsMultiple 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 StrategiesPath 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

ConclusionsConclusions

• 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 User Managed End-To-End Lightpath Provisioning Over CA*net 4Provisioning Over CA*net 4

Jing WuJing Wu jing.wu@crc.ca jing.wu@crc.ca

Scott CampbellScott Campbell scott.campbell@crc.cascott.campbell@crc.ca

Michel Savoie Michel Savoie michel.savoie@crc.ca michel.savoie@crc.ca

Hanxi ZhangHanxi Zhang hanxi.zhang@crc.ca hanxi.zhang@crc.ca

Gregor v. Bochmann bochmann@site.uottawa.caGregor v. Bochmann bochmann@site.uottawa.ca

Bill St.ArnaudBill St.Arnaud bill.st.arnaud@canarie.ca bill.st.arnaud@canarie.ca