# Presentation: 530369

## CA*net 4 UCLP Roadmaphttp://www.canarie.ca/canet4/uclp/UCLP_Roadmap.doc

- Bill St. Arnaud
- CANARIE Inc – www.canarie.ca
- Bill.st.arnaud@canarie.ca

## Why do we need optical networks?

**There is urgent requirement to do fundamental rethink of the value of optical networks**
**What constitutes an optical network?**
- Do static fiber and wavelength connections constitute an optical networks?
- Or does an optical network necessarily mean it has to be dynamic and therefore need a optical control plane?
- Is there a genuine need for dynamic or agile optical networks?
**What is advantage of optical networks versus ATM, IP, etc**
- More bandwidth?  Lower cost? Guaranteed Quality of Service?
- Cut through for high bandwidth flows? Better sharing of limited resources?

## What constitutes optical network research & testbeds?

**General agreement we need more research in layer 0/1 technologies**
- Improved fiber, better lasers and modulators, detectors, dispersion control, higher bit rates, better FEC, integrated optics, better high speed interfaces, optical repeaters (EDFA, RAMAN), C.L.S bands etc
- Optical cryptology, optical bit and symbol processing, and eventually optical computation
- Wavelength conversion
**Large questions on value of layer 2/3 optical network research & testbeds**
- Agile and dynamic optical networks
- Automatic restoral & protection
- OOO verus OEO add/drop/switching
- Scheduling or signaling for bandwidth for large data flows
- Traffic engineering for long term flows

## Dynamic optical networks -  ATM reincarnated?

**Many of the same arguments for dynamic and agile optical networks were made for ATM networks**
- Cut through routing/switching (remember Ipsilon?)
- Automatic restoral and protection
- QoS
- Signaling (and or scheduling) for high bandwidth channels
**We demonstrated with ATM that only one network layer should be dynamic otherwise you get conflicts**
- Restoral and protection best done at layer 3 or higher
- Path selection and routing best done at layer 3 or higher
- IP networks can handle huge data flows
**The only value of a somewhat dynamic transport network is to support traffic engineering of IP network and creation of VPNs– hence MPLS-TE**
- This is what we learned from ATM

## Issues with scheduling and reservation of bandwidth

**Call blocking !!!  (nobody seems to mention this when discussing bandwidth reservation)**
**Call blocking will always occur in any circuit oriented architecture**
**Problem is minimal on telephone system where there are millions of circuits and lots of spare capacity**
- Lots of research into call blocking probability – Erlang formulae
**We have no research or body of evidence on probability of call blocking when users are trying to reserve huge chunks of bandwidth**
- If call blocking exceeds a few percent it will be deemed a failure

## CA*net testbed assumptions:

**IP networking will remain the predominant technology**
- Restoral, protection, routing will continue to done at IP layer
**Most high bandwidth applications required sustained on-going bandwidth to a small number of known locations**
- Little need for reservation or scheduling of bandwidth
**There is little demand for infrequent high bandwidth transfers to random locations**
- Best done through IP network
- Will look like a DOS attack if not properly planned for
**The value of optical networking is that it allows the creation of many “fine grained” IP networks for specific communities of interest rather than having a common generic IP network**
**Adapts lessons learned from ATM – and extends concept of traffic engineering to the user and to the topology**

## CA*net 4 design principles

**Occam’s rule of networking: **
-  “The simplest network is the best network”
**Provide users with tools to do their own traffic engineering including changing topology and bandwidth**
- “Articulated Private Networks”
**Allow users to create IP networks for their own community of interest**
- Most importantly allow extension of network into campus to specific servers and bypass campus firewall
**Use Service Oriented Architecture (web services and workflow) to allow users to do their own provisioning and configuration of the network**
- Also allows easy integration of application

## UCLP Objectives

**Allow institutions to integrate wavelengths and fiber from different suppliers and integrate with institution's network management domain**
- And offer VPNs (or APNs) to users
**Create discipline specific re-configurable IP networks**
- Multihomed network which bypasses firewalls with direct connect to servers and routers
**User controlled traffic engineering**
- Active replacement for Sockeye and Route Science
- Use lightpaths as traffic engineering “underlay” versus MPLS-TE “overay”
**Primary purpose is NOT reservation and leasing of wavelength resources**
**Primary purpose is NOT switched optical networks**
**Primary purpose is NOT end-to-end optical VPNs**
**Primary purpose is NOT inter-domain connection of lightpaths**

## Today’s hierarchical IP network

- University

- National or Pan-Nationl IP Network

- Other national networks

- NREN A

- NREN B

- NREN C

- NREN D

## Tomorrow’s peer to peer IP network

- World

- University

- Server

- World

- World

- National DWDM
-  Network

- NREN A

- NREN B

- NREN C

- NREN D

- Child
- Lightpaths

- Child
- Lightpaths

## Creation of application VPNs

**Commodity**
**Internet**

**Bio-informatics**
**Network**

- University

- University

- University

- CERN

- University

- University

**High Energy**
** ****Physics Network**

**eVLBI**
** ****Network**

- Dept

**Research Network**

- Note:  Direct connection to server on campus

## Slide 12

## UCLP intended for projects like Optiputer and CaveWave

## DRAC/UCLP Demo Network

**DRAC/UCLP Demo Network**

**Nortel**
**DRAC**

**Canarie**
**UCLP**

- Halifax

**App**

**App**

- Ottawa

- Toronto

- Montreal

*The Power of Web services*

## Recent UCLP examples

**Over 20 UCLP lightpaths setup across CA*net 4**
**Need to purchase additional wavelength in 2005**
**AARnet used UCLP to setup lightpath for Huygens-Cassini data transfer**
**5 HDTV streams to be switched and controlled through UCLP at APAN in Bangkok**
**3 UCLP lightpaths for restoral/protection by regional networks**
**2 UCLP lightpaths for distributed backplane – e.g. mini TeraGrid**
**7 international UCLP lightpaths – 1G to 2.5 G**
**10G UCLP lightpath shared between Tokyo Data reservoir and HEPnet **

## GENI initiatives vs UCLP

**Possible GENI testbeds:**
- Xbone: http://www.isi.edu/xbone/
- Network Virtualization: http://www.arl.wustl.edu/netv/main.html
- Hypercast: _http://www.cs.virginia.edu/~mngroup/hypercast/_
**GENI initiatives mostly “overlays” on an IP network using various tunnels between routers**
**UCLP is an “underlay” to IP network with lightpaths between switches–  “substrate” in Network Virtualization**
**UCLP uses web services and work flow to create virtual networks and bind virtual (and real) routers/switches to the APN**
**UCLP assigns control over all other network function to the user**
- Multicast, QoS, application binding etc