Transcript PowerPoint-presentatie

Generic AAA* based
Bandwidth on Demand
MB-NG workshop UCL
London 20/02/2003
Leon Gommans
Advanced Internet Research Group
University of Amsterdam
[email protected]
* Authentication Authorization & Accounting
Research funded by
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.
- Technical Design & Implementation: Bas.
Goal of BoD work at UvA.
• Allow application demand to provision a L1/L2 network channel that
does by-pass the regular internet connection. Regular Internet
connection becomes control channel, L1/L2 network the transport
channel.
- Rationale is that above a certain level of:
parallel required bandwidth / number of different destinations
a Layer-3 QoS network will become too expensive.
- I.e. the requested bandwidth is in the order of the traffic
generated by a nations NRN and only a few destinations need such
connectivity. Examples can be found in HEP, radio-astronomy etc.
However AAA concepts can also be used for L3 Diffserv
connections
Other considerations
-TCP stack & transport channel needs tailored behavior to make
optimal use of a high speed ( GB ), high delay (>100ms) channel
- Modifications tend to generate Internet “unfriendly” TCP traffic,
that does not mix well unless routers are aware of the high
bandwidth topology. Topology needs to be management somehow.
-Single Packet drop in standard TCP causes severe performance hits
- Limited memory buffer sizes in routers/switches do cause packet
drops when the road “gets smaller” on long fat pipes. Equipment
designed for MAN operation can not be in the chain.
- Firewalls do not support extreme high bandwidth connections.
- Possible option: Create dedicated channels that are intended to
get utilized 100% for the required time. Cost model will determine
if and when on-demand usage is required v.s. dedicated usage.
Rough requirements list.
-
-
-
Allow L 1, 2, 3 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 applications such as GridFTP.
Allow authorized VO’s or individual users to discover
available lightpath destination (e.g. Via OGSA/WS).
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.
Incorporation of topology awareness is of later concern.
Rough requirements list.
-
-
-
Must hide complexity from user. Conceptually the user
must perform the process in 3 basic steps after login:
1) Pre-allocate thru a discovery and scheduling system ->
BoD system issues authorization.
2) Allow own or delegated job to allocate the network
resource whereby it uses the issued authorization.
3) Once the job is finished, the authorization is handed
back/invalidated 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 or clearing and settlement.
Design considerations.
-
Group in Amsterdam does focus on deploying Generic AAA
(RFC2903/RFC2904) concepts to handle authorization of
mainly L1/L2 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.
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 are already
active in this area.
Could work in parallel to GARA BB efforts to add policies
to handling authorized provisioning of QoS tunnels.
Lightpath
Def*: Any uni-directional point to point connection with
effective guaranteed bandwidth
Examples of LightPaths:
* L1: Analog wavelength on a CWDM or DWDM system
* L1: Gigabit Ethernet over dedicated fiber strand
* L2: STS channel on a SONET or SDH circuit
* L2: ATM CBR circuit
* L2: MPLS VLAN
* L3: Diff serv “gold” service on a packet based network
* Definition by Bill St. Arnoud of Canarie
Control models
In multidomain scenario’s you must have some
awareness of the underlying high-level concept of
the connection.
Must understand what piece of the conceptual
connection the AAA entity is controlling:
• Collector switch at the ingress and its connected
networks or equipment
• The link
• Distributor switch at the egress and its connected
networks or equipment
Full Control model
Selector
Domain X
Switch
Selector
Switch
DomainY
Domain Y
Domain X
Distributor
Switch
Distributor
Switch
Partial control model
Domain A
Domain B
Domain C
Domain D
Hybrid models
Domain A
Domain B
Domain X
Domain C
Domain D
Domain X
DomainY
Domain X
Full control model
Selector
Domain X
Switch
Distributor
Switch
Domain Y
AAA
Domain AAA engine must control
both selector and distributor switch and
Interconnecting network
Partial control model
Selector
Switch
AAA
Domain A
Domain B
Distributor
Switch
AAA
Domain AAA engine must control the selector
or distributor switch and one of the AAA Servers
must control intermediate network
Generic AAA
o 5 years ago a AAA server was known as a server supporting
dail-in boxes thru the RADIUS protocol (at IETF).
o IETF42 (in same hotel as GGF6) held first AAA BOF as it was
recognized AAA could be used in other type of applications.
o Amsterdam group has been participating on defining concepts
for Generic AAA since march 1999 when AAA WG was formed
at IETF-44
o Work became IRTF subject end of 1999 (AAA ARCH RG).
o ID’s that became RFC’s 2903 – 2906 were submitted after
the Adelaide IETF march 2000. RFC’s describe framework,
architecture, example applications and requirements.
o Optical Networking within grid environment is a research
application for Generic AAA.
RFC 2904 Generic AAA Framework basic principles
AAA
User
2
1
4
3
Service
1
1
User
AAA
4
3
2
Service
AAA
2
User
3
4
Service
Pull sequence
Agent sequence
Push sequence.
NAS (remote access)
RSVP (network QoS)
Agents, Brokers,
Proxy’s.
Tokens, Tickets,
AC’s etc.
3 fundamentally different user initiated authorization sequences.
Note: RFC2904 does not show step 5 – service access.
Generic AAA Framework
AAA
3
User Home
Organization
4
AAA
User
1
6
2
5
Service
Provider
Service
Separating the User Awareness from the Service
yield Roaming Models: Example roaming pull model.
Generic AAA Framework
AAA
User Home
Organization
AAA
AAA
Service
Service
Service
Provider A
Service
Provider B
User
AAA
Client
Distributed Services Models allow many types
and combination of authorization sequences ..
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.
Generic AAA Architecture – RFC2903
Achieve goal by by separating
the logical decision process from
the application specific parts
within the PDP.
PDP
Rule
Based
Engine
Policy
Repository
Application
Specific
Module
Request
Decision
Policy
Enforcement
Point
Example of Generic AAA Architecture – RFC2903
Rule
Based
Engine
Policy
Repository
User
Application
Specific
Module
Rule
Based
Engine
Application
Specific
Module
AAA
Server
AAA
Server
Purchase Dept.
Bandwidth
Broker
QoS Enabled
Network
Policy
Repository
Contracts
Budgets
Rule
Based
Engine
Policy
Repository
Application
Specific
Module
AAA
Server
Registration Dept.
(Virtual) User Organization
Service
Bandwidth
Provider
Service Organization
Users
Generic AAA (RFC2903) based Bandwidth on Demand
192.168.
1.5
192.168.
2.3
A
802.1Q
VLAN
Switch
1 GB SX
802.1Q
VLAN
Switch
192.168.
2.4
192.168.
1.6
C
Enterasys
Matrix E5
Enterasys
Matrix E5
B
D
Policy DB
AAA
Request
AA
A
iGrid2002
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>192.168.1.5</Source>
<Destination>192.168.1.6</Destination>
<Bandwidth>1000</Bandwidth>
<StartTime>now</StartTime>
<Duration>20</Duration>
</BodData>
</AAARequest>
Policy (significant part) executed by AAA Rule Based Engine
if
(
(
ASM::RM.CheckConnection(
Request::BodData.Source,
Request::BodData.Destination
)
&&
( Request::BodData.Bandwidth <= 1000 )
)
)
then
(
ASM::RM.RequestConnection(
Request::BodData.Source,
Request::BodData.Destination,
Request::BodData.Bandwidth,
Request::BodData.StartTime,
Request::BodData.Duration
)
;
Reply::Answer.Message = "Request successful"
)
else
(
Reply::Error.Message = "Request failed"
)
L2/L3 Setup using GARA based network
provisioning
IP A
IP B
A
B
GARA (multidomain)
QoS network
802.1Q
VLAN
Switch
802.1Q
VLAN
Switch
Enterasys
SS6000
GAR
A
Band
w
Brok
er
VO
MS
AA
A
Bo
DSe
rv
Enterasys
SS6000
C
D
IP C
IP D
Grid
Authentication
VOMS
Auth
DB
Role Request +
Reply Pseudo Cert
GARA
Agent
USER
Advance Reservation
request / reply
A
A
A
Slot
Table
BGP Topology advertisements +
Reservation indications
QoS Path
request / reply
BB
QoS
Networks
Policy
DB
Path Provision
indications
WS + Service Discovery
J2EE, Apache –Axis
Web Services – OGSA
AAA protocol
Standards
Body Liaison
+ Architect.
Managemnt
&
Document.
Management
And
Monitoring
Policy Language
CA, CA policy
Authentication
Devices,
Protocol Security
Run
Time
Env
AAA
Core
Security
Integration
Accounting
WP 2 manpwr
WP 4 manpwr
Billing, Clearing & Settlement
User/
Organization
Integration
Service
Control +
Integration
PKI,
KERBEROS,
VOMS
Layer N networking
Scheduling
Advance Reservation
Service Discovery
and Ontology
Design considerations
o Full control model was chosen for first implementation.
o Single AAA engine controls both ingress and egress switch by
creating 802.1Q VLAN’s using the dot1Q Bridge MIB extentions
via SNMP.
o 1 GB channel between switches carry 802.1Q tagged ethernet
frames. An 802.1Q trunk can carry up to 4096 VLAN’s.
o End stations will register with AAA engine and subsequently
send request to reach other stations (pointed to via its public IP
address).
o By-pass communication channel uses a private IP address
space. Destinations are identified by main IP address.
Related work:
1) Separate ASM and RBE and allow ASM’s to be
loaded/unloaded dynamically using J2EE.
2) Implement pre-allocation mechanisms (based on GARA
slot table)
3) Create ASM for Bandwidth Broker
4) Create ASM to find out high level domain topology
(will be using hard coded info at first).
5) Allow RBE’s to talk to each other (define messages).
6) Integrate BoD AAA client into middleware eg by
allowing integration with GridFTP and integration with
VOMS authentication and user authorization system.
7) Build WS interface abstraction for pre-allocation and
subsequent usage.
Technical Design and
Implementation overview
Bas van Oudenaarde
Thank you !
[email protected]