1. Generic AAA* based Bandwidth on Demand EVL at UIC meeting Leon Gommans
* Authentication Authorization & Accounting
EVL at UIC meeting
Chicago 18/10/2002
Leon Gommans
Advanced Internet Research Group
University of Amsterdam

2. Content Goals and basic list of requirements.
Lightpath and Lightpath control concepts
Generic AAA concepts
High level design and operation of proof of concept.
Example of a simple request message and policy.
- Next work items
Content:
First this presentation will say a few words about the relationship between the DataTAG WP4 description and the associated WP4.2 task description as to validate the context of the work. Recent discussions within the Projects Board have indicated such a need.
Then we will show some light on the underlying concepts and some definitions of what we mean with a Lightpath and Generic AAA.
Based on these concepts we have identified a testbed that allows us to play with one of the models based of these fundamental concepts.
This presentation will also show some of the involved messages and policies including some technical details.
Arie Taal and Bas van Oudenaarde are the guys who handle the design details and technical implementations.

3. Goal
Allow a provisioned Lightpath to by-pass a regular internet connection. Internet connection becomes control channel.
Motivation:
Routed networks are too expensive if requested bandwidth is in the order of the traffic generated by a nations NRN
TCP stack & transport channel needs tailored behavior to make optimal use of a high speed ( GB ), high delay (>100ms) channel
Modifications generates Internet “unfriendly” TCP traffic.
Firewalls do (not yet) statefully inspect 10 GB/S streams without delays or performance implications.
Single Packet drop causes severe performance hits.
Memory buffers in routers/switches are a concern when the
road gets smaller.
Thes considerations have been used to identify the need for this project:
This project deals with lighpathes (definition to follow within the next few slides) that are created to by-pass a regular internet connection. As such it can be considered as a kind of internet worm holes that take you quickly from one side of the internet universe to the other side.
If single/few TCP connections are working across the Atlantic at GB speeds, one needs to pay special attention to the TCP behavior and its equipment that transports the dataflow(s) as otherwise it is highly likely that only a fraction of the available capacity is utilized. A small percentage of packet drops may already have a significant performance implication. These special considerations will typically cause TCP to be unfriendly for the regular Internet: Either a single station emulates multiple sources (such as GridFTP) or the behavior, such as the re-transmission behavior is modified.
Lightpath usage should be allowed in a demand driven fashion where knowledge about the way applications are run is used to –possibly- pre-allocate or reserve network resources. VO’s should be able to discover and monitor available network resources in the same fashion as other resources are discovered and monitored.
Collaboration with the WP2 work is needed to find out more about how network resources could be reserved in advance.
The research at UvA is focussed around the experimental deployment of the Generic AAA concepts as described in RFC2903/2904. The authorization of a lightpath is an area that nicely fits the objectives of WP4 and the objectives of the Research group at UvA.
The research needs to identify the role, messages and policies that generic AAA components need to handle as part of an overall workflow scencario.
The research does not address network problems related to path finding/setup or optimization as several other groups and vendors have been working on these issues in the past.

4. Rough requirements list.
Allow lightpath usage in a “demand driven” fashion.
Allow “hard” or “soft” pre-allocation.
Must support allocation and usage across multiple domains.
Must be integrated into middleware e.g. by allowing
provisioned by-pass model to be supported by GridFTP.
Raised this with GGF Data Transport RG (Bill Allcock).
Allow authorized VO’s or individual users to discover
available lightpaths (e.g. via a OGSA/WS style interface).
Allow authorized users (with a certain role within the VO)
to pre-allocate and use bypass for a limited amount of time
and with limits on the allocated bandwidth.
Must integrate with existing authentication & user (role
based) authorization system: Looking into EDG VOMS.
Thes considerations have been used to identify the need for this project:
This project deals with lighpathes (definition to follow within the next few slides) that are created to by-pass a regular internet connection. As such it can be considered as a kind of internet worm holes that take you quickly from one side of the internet universe to the other side.
If single/few TCP connections are working across the Atlantic at GB speeds, one needs to pay special attention to the TCP behavior and its equipment that transports the dataflow(s) as otherwise it is highly likely that only a fraction of the available capacity is utilized. A small percentage of packet drops may already have a significant performance implication. These special considerations will typically cause TCP to be unfriendly for the regular Internet: Either a single station emulates multiple sources (such as GridFTP) or the behavior, such as the re-transmission behavior is modified.
Lightpath usage should be allowed in a demand driven fashion where knowledge about the way applications are run is used to –possibly- pre-allocate or reserve network resources. VO’s should be able to discover and monitor available network resources in the same fashion as other resources are discovered and monitored.
Collaboration with the WP2 work is needed to find out more about how network resources could be reserved in advance.
The research at UvA is focussed around the experimental deployment of the Generic AAA concepts as described in RFC2903/2904. The authorization of a lightpath is an area that nicely fits the objectives of WP4 and the objectives of the Research group at UvA.
The research needs to identify the role, messages and policies that generic AAA components need to handle as part of an overall workflow scencario.
The research does not address network problems related to path finding/setup or optimization as several other groups and vendors have been working on these issues in the past.

5. Rough requirements list.
Must hide complexity from user. Conceptually the user must perform the process in 3 basic steps after login:
Pre-allocate either manually or automatically thru a scheduling system -> system issues an authorization.
Allow the job to allocate the network resource whereby it uses the authorization.
Once the job is finished, the authorization is handed back so resources can be freed.
User (or scheduling system) must be allowed to change the reservation if the process flow so dictates.
Allocating user may be different from ultimate user.
Allocating user may subdivide capacity amongst users.
Must ultimately support Grid Economic Services Architecture features to allow ad hoc creation.
Must ultimately provide Grid Accounting records for billing in contract situations.
Thes considerations have been used to identify the need for this project:
This project deals with lighpathes (definition to follow within the next few slides) that are created to by-pass a regular internet connection. As such it can be considered as a kind of internet worm holes that take you quickly from one side of the internet universe to the other side.
If single/few TCP connections are working across the Atlantic at GB speeds, one needs to pay special attention to the TCP behavior and its equipment that transports the dataflow(s) as otherwise it is highly likely that only a fraction of the available capacity is utilized. A small percentage of packet drops may already have a significant performance implication. These special considerations will typically cause TCP to be unfriendly for the regular Internet: Either a single station emulates multiple sources (such as GridFTP) or the behavior, such as the re-transmission behavior is modified.
Lightpath usage should be allowed in a demand driven fashion where knowledge about the way applications are run is used to –possibly- pre-allocate or reserve network resources. VO’s should be able to discover and monitor available network resources in the same fashion as other resources are discovered and monitored.
Collaboration with the WP2 work is needed to find out more about how network resources could be reserved in advance.
The research at UvA is focussed around the experimental deployment of the Generic AAA concepts as described in RFC2903/2904. The authorization of a lightpath is an area that nicely fits the objectives of WP4 and the objectives of the Research group at UvA.
The research needs to identify the role, messages and policies that generic AAA components need to handle as part of an overall workflow scencario.
The research does not address network problems related to path finding/setup or optimization as several other groups and vendors have been working on these issues in the past.

6. Design considerations.
Group in Amsterdam does focus on deploying Generic AAA (RFC2903/RFC2904) concepts to handle authorization of lightpath. Group members were authors.
Best suited to handle policy based authorization in a dynamic fashion either to build AuthZ tokens or process requests which contain AuthZ tokens. Note AuthZ may itself also contain policies.
Authorizations between administrative domains must be done at a fairly high-level.
Don’t want to address low level networking problems (path finding/setup) as vendors and researchers like ICAIR are already active in this area
Need to identify role, messages and policies that are handled by Generic AAA components as part of the overall “workflow”.
Thes considerations have been used to identify the need for this project:
This project deals with lighpathes (definition to follow within the next few slides) that are created to by-pass a regular internet connection. As such it can be considered as a kind of internet worm holes that take you quickly from one side of the internet universe to the other side.
If single/few TCP connections are working across the Atlantic at GB speeds, one needs to pay special attention to the TCP behavior and its equipment that transports the dataflow(s) as otherwise it is highly likely that only a fraction of the available capacity is utilized. A small percentage of packet drops may already have a significant performance implication. These special considerations will typically cause TCP to be unfriendly for the regular Internet: Either a single station emulates multiple sources (such as GridFTP) or the behavior, such as the re-transmission behavior is modified.
Lightpath usage should be allowed in a demand driven fashion where knowledge about the way applications are run is used to –possibly- pre-allocate or reserve network resources. VO’s should be able to discover and monitor available network resources in the same fashion as other resources are discovered and monitored.
Collaboration with the WP2 work is needed to find out more about how network resources could be reserved in advance.
The research at UvA is focussed around the experimental deployment of the Generic AAA concepts as described in RFC2903/2904. The authorization of a lightpath is an area that nicely fits the objectives of WP4 and the objectives of the Research group at UvA.
The research needs to identify the role, messages and policies that generic AAA components need to handle as part of an overall workflow scencario.
The research does not address network problems related to path finding/setup or optimization as several other groups and vendors have been working on these issues in the past.

7. Lightpath
Def*: Any uni-directional point to point connection with effective guaranteed bandwidth
Examples of LightPaths:
* Analog wavelength on a CWDM or DWDM system
* STS channel on a SONET or SDH circuit
* ATM CBR circuit
* Diff serv “gold” service on a packet based network
* Gigabit Ethernet over dedicated fiber strand
* Definition by Bill St. Arnoud of Canarie
In a recent workshop at Canarie, Bill St. Arnaud introduced a term called a “Lightpath”. The definition most people seem to be happy with is “Any uni-directional point to point connection with effective guaranteed bandwidth.” Bill argued that a Lightpath could be implemented using various network technologies such as CWDM, DWDM, STS channels on a SONET/SDH circuit, ATM CBR circuit, A dedicated Diffserv Gold channel or GBE channels.
Within our group at UvA, research is done into the formal representation of fiberconnections and its associated equipment. A mathematical representation using directed graphs with edges and vertrices are currently investigated as one way to present a network of switches and links.
Some fundamental concepts are important to recognize: We identified 2 different classes of models: the Union and the Daisy Chain model.

8. Onion Lightpath model Domain Y DomainY Domain X Domain X Selector
Switch
Distributor
Switch
Domain X
DomainY
Domain X
Selector
Switch
Distributor
Switch
Domain Y
The Union model is most applicable in situation where a provider offers connections across its domain and possibly use underlying domains to provide connections. To the outside world the model appears to have an ingress and an egress switch with a connection in between. The connection in between may subsequently be formed by another Union model configuration thus from a recursive definition of this type of network. Domain X and Y in above picture each independantly control a set of ingress and egress switches. This observation is the significant differentiator between this model and the Daisy Chain model, explained on the next slide.

9. Daisy Chain Lightpath model
Domain A
Domain B
Domain C
Domain D
The Daisy Chain model is more typical for customers feeding into a network or (facing it in a uni-directional fashion) drain from the network. In this model a domain consist out of one (or more) ingress switches or one (or more) egress switches. Although the physical ownership of the involved fiber may be different, in our model we assume that the “control” ownership of a fiber is attached to the outgoing port of the ingress switch or the incomming port of an egress switch. When a conflict of interest arises, the ingress switch takes precedence as shown in above picture. Note that by doing this, althoug a fiber cable, housing multiple pairs, is typically own by a single party – the control ownership may be from multiple parties.

10. Daisy Chain & Onion Domain A Domain B Domain X Domain C Domain D
DomainY
Domain X

11. Onion control model AAA Domain AAA engine must control
Seector
Switch
Distributor
Switch
Domain X
Domain Y
AAA
Domain AAA engine must control
both selector and distributor switch and
Interconnecting network

12. Daisy chain control model
Selector
Switch
Distributor
Switch
Domain A
Domain B
AAA
AAA
Domain AAA engine must control the selector
or distributor switch and one of the AAA Servers
must control intermediate network

13. Generic AAA
5 years ago a AAA server was known as a server supporting dail-in boxes thru the RADIUS protocol (at IETF).
IETF42 (in same hotel as GGF6) held first AAA BOF as it was
recognized AAA could be used in other type of applications.
Amsterdam group has been participating on defining concepts for Generic AAA since march 1999 when AAA WG was formed at IETF-44
Work became IRTF subject end of 1999 (AAA ARCH RG).
ID’s that became RFC’s 2903 – 2906 were submitted after the Adelaide IETF march RFC’s describe framework, architecture, example applications and requirements.
Optical Networking within grid environment is a research application for Generic AAA.

14. RFC 2904 Generic AAA Framework basic principles1 1
User
User 2
User 4 2 2 1 3 3 3
Service
Service
Service 4 4
Pull sequence
NAS (remote access)
RSVP (network QoS)
Agent sequence
Agents, Brokers,
Proxy’s.
Push sequence.
Tokens, Tickets,
AC’s etc.
3 fundamentally different user initiated authorization sequences.
Note: RFC2904 does not show step 5 – service access.

15. Generic AAA Framework AAA AAA User Service User Home Organization3 4
AAA
User
Service
Provider 2 1 5
Service 6
Separating the User Awareness from the Service
yield Roaming Models: Example roaming pull model.

16. Generic AAA Framework AAA AAA AAA User Service Service User Home
Organization
AAA
AAA
User
Service
Service
AAA
Client
Service
Provider A
Service
Provider B
Distributed Services Models allow many types
and combination of authorization sequences ..

17. Generic AAA Architecture – RFC2903
Fundamental idea’s inspired by
work of the IETF RAP WG that
in RFC 2753 describes a
framework for Policy-based
Admission Control.
Foundation for COPS
Policy
Decision
Point
The point where policy
decisions are made.
Policy
Repository
Request
Decision
Policy
Enforcement
Point
The point where the policy
decisions are actually enforced.
Basic Goal Generic AAA: Allow policy decisions to be made by multiple PDP’s belonging to different administrative domains.

18. Generic AAA Architecture – RFC2903
PDP
Rule
Based
Engine
Archieve goal by by separating
the logical decision process from
the application specific parts
within the PDP.
Policy
Repository
Application
Specific
Module
Request
Decision
Policy
Enforcement
Point

19. Example of Generic AAA Architecture – RFC2903
Rule
Based
Engine
Rule
Based
Engine
Rule
Based
Engine
Policy
Repository
Policy
Repository
Policy
Repository
Application
Specific
Module
Application
Specific
Module
Application
Specific
Module
Contracts
Budgets
Users
AAA
Server
AAA
Server
AAA
Server
User
Bandwidth
Broker
Purchase Dept.
Registration Dept.
(Virtual) User Organization
QoS Enabled
Network
Service
Bandwidth
Provider
Service Organization

20. A C B D Generic AAA (RFC2903) based Bandwidth on Demand Policy DB A
802.1Q
VLAN
Switch
Enterasys
Matrix E5
802.1Q
VLAN
Switch
Enterasys
Matrix E5 C
1 GB SX B D
Policy DB
AAA
AAA
Request
iGrid2002

21. A C B D Generic AAA (RFC2903) based Bandwidth on Demand Policy DB A
802.1Q
VLAN
Switch
Enterasys
Matrix E5
802.1Q
VLAN
Switch
Enterasys
Matrix E5 C
1 GB SX B D
Policy DB
AAA
AAA
Request
iGrid2002

22. Next Setup using vendor provided network provisioning system
Managed Optical Connection Service
IP A A
802.1Q
VLAN
Switch
Enterasys
SS6000
802.1Q
VLAN
Switch
Enterasys
SS6000 C
IP C
IP B B
Cisco CTM D
IP D
AAA BoDServ
Content:
First this presentation will say a few words about the relationship between the DataTAG WP4 description and the associated WP4.2 task description as to validate the context of the work. Recent discussions within the Projects Board have indicated such a need.
Then we will show some light on the underlying concepts and some definitions of what we mean with a Lightpath and Generic AAA.
Based on these concepts we have identified a testbed that allows us to play with one of the models based of these fundamental concepts.
This presentation will also show some of the involved messages and policies including some technical details.
Arie Taal and Bas van Oudenaarde are the guys who handle the design details and technical implementations.

23. Example XML Lightpath request
<AAARequest version="0.1" type="BoD" >   <Authorization>       <credential>          <credential_type>simple</credential_type>          <credential_ID>JanJansen</credential_ID>          <credential_secret>#f034d</credential_secret>       </credential>   </Authorization>   <BodData>       <Source> </Source>       <Destination> </Destination>       <Bandwidth>1000</Bandwidth>       <StartTime>now</StartTime>       <Duration>20</Duration>   </BodData> </AAARequest>

24. Policy (significant part) executed by AAA Rule Based Engine
ASM::RM.CheckConnection(
Request::BodData.Source,
Request::BodData.Destination )
&&
( Request::BodData.Bandwidth <= 1000 )
then
ASM::RM.RequestConnection(
Request::BodData.Destination,
Request::BodData.Bandwidth,
Request::BodData.StartTime,
Request::BodData.Duration ;
Reply::Answer.Message = "Request successful"
else
Reply::Error.Message = "Request failed"

25. Design Details Onion model was chosen for first implementation.
Single AAA engine controls both ingress and egress switch by creating 802.1Q VLAN’s using the dot1Q Bridge MIB extentions via SNMP.
1 GB channel between switches carry 802.1Q tagged ethernet frames. An 802.1Q trunk can carry up to 4096 VLAN’s.
End stations register with AAA engine and subsequently send request to reach other stations (pointed to via its public IP address).
By-pass communication channel uses a private IP address space. Destinations are identified by main IP address.

26. Technical Implementation
XML/SOAP messages for request/reply (to prepare for a future web services interface)
RBE: JAVA code running as Servlet.
Uses Apache Axis to handle SOAP messages.
ASM: JAVA code currently running in Java
context of RBE. Currently investigating how it
could run separately e.g. as Java Bean or using
CORBA.
More technical details:
Bas van Oudenaarde: and
Arie Taal:

27. Upcomming work:
Separate ASM and RBE and allow ASM’s to be loaded/unloaded dynamically.
Implement pre-allocation mechanisms (based on GARA – collaboration with Volker Sander).
Create ASM for other B/W manager (e.g. Alcatel BonD, Cisco CTM, Level-3 Ontap)
Create ASM to talk to other domain: OMNInet
Allow RBE’s to talk to each other (define messages).
Integrate BoD AAA client into middleware eg by allowing integration with GridFTP and integration with VOMS authentication and user authorization system.
Build WS interface abstraction for pre-allocation and subsequent usage.

28. Thank you !