Photonic TeraStream and ODIN By Jeremy Weinberger

1
Photonic TeraStream and ODINBy Jeremy Weinberger
iCAIR

• 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
iCAIR

• 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
iCAIR

• 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
iCAIR

• 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 xyzw
  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
iCAIR

• 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
iCAIR

• 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/label
  ing, 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
iCAIR

• "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
iCAIR

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