Embed Size (px)
Citation preview
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 [email protected] [email protected]
Scott CampbellScott Campbell [email protected]@crc.ca
Michel Savoie Michel Savoie [email protected] [email protected]
Hanxi ZhangHanxi Zhang [email protected] [email protected]
Gregor v. Bochmann [email protected] v. Bochmann [email protected]
Bill St.ArnaudBill St.Arnaud [email protected] [email protected]
