1. Photonic TeraStream and ODIN By Jeremy Weinberger The iCAIR iGRID2002 Demonstration Shows How Global Applications Can Use Intelligent Signaling to Provision their Own Lightpaths to Optimize network Based Resource Discovery and Performance, for example, To Enable Access To and Dynamic Interaction with Very Large Amounts of Distributed Data. Supported by Innovative Architectural Method that Envisions: Closer Integration Between Applications and Advanced Networks Liberating Applications From Restrictions in Todays Communication Infrastructure Key technologies: – a) Intelligent application signaling, –b) Dynamic lambda provisioning on the OMNInet testbed, –c) Extensions to lightpaths through dynamically provisioned L2 and L3 configurations, in part, to allow for access to multiple types of edge resources.

2. Application Signaling and ODIN Signaling - the request for services by a peer or by a user (LDP/RSVP/SOAP req/TeraAPI message to Optical Service Layer) Control - commands issued by administrator Results may look similar on the fiber, but the first is subject to policy, the second should be always obeyed when valid ODIN = Optical Dynamic Intelligent Network services ODIN - An Architecture for Dynamic Network Service Provisioning Terascale High-Performance Optical Resource Regulator (THOR) the Lambda God + Extensions allowing for others types of path services

3. Architectural Issues What problem is being addressed? - Provisioning of optical paths to application traffic - GMPLS-controlled DWDM is layer one only - layers two and three must be configured or the lambda path is useless - Application requests for premium network service, e.g. protected capacity, jitter tolerances - Single, simple domain of control - no restrictions on hierarchical vs. peer model - Limiting impact of potentially disruptive, resource-intensive traffic on best-effort traffic - Cees DeLaat and others will provide IAAA. This simple architecture could be compounded to address complex architectures, e.g. large domains, multiple domains. (diagram of tree of odins, chain of odins)

4. ODIN ODIN in a Nutshell - A single point of policy control for network service provisioning - Applications talk to the front end, identify themselves and make their request ("I need at least n Mbps of capacity between A and B at xy:zw hours with maximum jitter q.") - ODIN's processes attempt to make a globally optimal provisioning, considering all real-time information available - ODIN's back end controls network hardware, configuring it to fulfill the provisioned request

5. Advantages of Architecture Opportunities for global optimization Opportunities to consider real-time resource state Single master is single point of policy control and single Delphic Oracle of network state Frontends and backends can be modules to support different kinds of requests and different kinds of network equipment and multiple layers of the network Sites can easily provide their own policy for releasing resources (timeouts, billing motivation, flow monitoring) Simple domains can be tied together to manage complex domains Application interface is simple, requiring little detailed network knowledge from app developers Encapsulates network resource discovery for applications Service requests are explicit, out of band Moves logic out of network hardware, more flexibility

6. Provisioning Application Traffic to Lightpaths Can different applications share a lightpath? i.e. are their service profiles compatible? What protections must be put in L2/L3 equipment to enforce provisioning? e.g. classification/labeling, policing, class-based queueing The Comprehensive Vision - ODIN includes dynamic resource discovery of new network resources - ODIN uses real-time monitoring of network hardware or traffic flows to make decisions - ODIN relies on manager-controlled policy engine - ODIN configures access devices to do full classification and admission control - ODIN configures core/distribution devices to provide appropriate QoS to classes.

7. Current Implementation "TeraAPI" is a C interface implementing frontend Discovery: Domain topology is known in advance Frontend: Custom stateless TCP-based request protocol Policy: Each service request receives its own lambda Backends: –1. Optical backend THOR (Terascale High Performance Optical Resource-Regulator), (previously termed "The Lambda God) –2. Ethernet backend DEITI (Dynamic Ethernet Intelligent Transport Interface Higher layers are configured to move traffic to new LAN segment running over the assigned lambda

8. DEITI (DEUS) and AAA - Our goal in the dynamic provisioning of vLANs is to segment traffic to protect other traffic from disruptive, intensive flows. - Bas's goal in the dynamic control of vLANs is to demonstrate the principles of generic AAA in the provisioning of this resource. - Both implementations are seed examples of the extensions that could be implemented to use other methods, eg, enforcing QoS, and establishing full AAA that could protect these methods.