1 / 14

AAA Design Team Data Modelling Issues & Solutions

AAA Design Team Data Modelling Issues & Solutions. Erik Guttman Sun Microsystems Member of AAA Design Team. Outline. [ 5 mins ] Goals for discussion [ 5 mins ] Issues What we need to do What are the criteria for evaluation of solutions? [ 5 mins ] Diameter.xml - Erik Guttman

tirza
Download Presentation

AAA Design Team Data Modelling Issues & Solutions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. AAA Design TeamData Modelling Issues & Solutions Erik Guttman Sun Microsystems Member of AAA Design Team

  2. Outline • [ 5 mins ] Goals for discussion • [ 5 mins ] Issues • What we need to do • What are the criteria for evaluation of solutions? • [ 5 mins ] Diameter.xml - Erik Guttman • [ 5 mins ] Network Access Data Model - Dave Spence • [ 5 mins ] Mapping of SMIng to Diameter - Juergen Schoenwaelder • [ 5 mins ] Evaluation of solutions

  3. Goals • Big Goal: Address vital concerns in a timely way. Defer work on non-vital issues, avoid solutions which will not deliver rapidly. • Present AAADT Issues and Solutions • Present Formal Data Notation Proposals • For specification • For debuggers, storage, sniffers... • NOT for on-the-wire representation • Evaluate proposals - if time permits

  4. Issues • Read draft-ietf-aaa-issues-04.txt • Separate base protocol and specific messages • Allows proxies, sniffers, receivers, etc to know something, even if the command or extension is unrecognized • Data types • less specific, more types, replace 'Complex' • Formal notation for Diameter AVPs (Cmds?) • verify definitions, automate implementations, aid debugging/sniffing, enhance extensibility • non-goals: universal generality, presentation

  5. Issues, continued • Must AVPs be ordered in a message? • 'M' bit • Should we improve message specifications?

  6. Formal Notation Evaluation Criteria • Is it possible to specify existing DIAMETER messages? • Is the formal notation tied to stable standards (which won't change in near-medium term)? • How much less efficient is the data typing than DIAMETER as specified?

  7. Solution: Message Separation • DIAMETER message header flags field unused. • Assign flag bits: • 0x04 E Expect Reply • 0x02 I Interrogation (otherwise ACTION) • 0x01 R Response • 4 < 'Indication', 4 = Request, 5 = Reply, 6 = Query, 7 = Answer • Examining the flags yields the type of msg.May be useful for logging, security policy...

  8. Solution: Data Types • Was: • Data, String, Address, Integer32, Integer64, Time and Complex. • Change to: • Address, Integer32, Unsigned32, Integer64, Unsigned64, Float32, Float64, Float128, OctetString, Grouped and List.

  9. Solution: Data Type, 2 • Grouped ~= struct, List ~= array • Should these impose order or not? • Is List really needed? Grouped seems to be. • Worst case waste of space of Grouped type: • Complex has 1 AVP header, 2 four byte elts12 bytes header + 8 bytes data = 20 bytes • Grouped has 3 AVP headers, 2 four byte elts36 bytes header + 8 bytes data = 48 bytes • 140% larger is the worst case

  10. Solution: Ordering • Flexibility vs. simplicity (of parsers, etc.) • RADIUS flexibility has been useful • Many commands can only be interpreted after all AVPs have been processed • Recommendation: Do not add a new requirement to impose ordering of AVPs

  11. Solution: Formal Data Notation • 3 presentations • Unfortunately, only one is currently available as an internet draft • Discuss how they meet criteria • Attempt an evaluation

  12. DIAMETER XML • See draft-ietf-aaa-solutions-01.txt, appendix A, other proposals may follow • Specifies DTD for base DIAMETER and extension AVPs. • Includes xml data for all currently specified AVPs. • To do: Add command codes.

  13. DIAMETER XML, 2 • A set of base & extension AVPs • Each AVP has a name and type, and optionally a description and a set of values. • AVP elements specify 'may-encrypt' attribute, and may set additional attributes:printable OctetString is DisplayStringip-address Octetstring is an IP addresstime Unsigned32 is a timestampconstrained Only listed values are legalvendor-flag Allows V flag to be setmandatory-flag Optional, disallowed, req'd

  14. DIAMETER XML, 3 • This approach can represent all existing and forseeable AVPs. • Based on stable and accepted data representation standard - XML • Easily extensible to new AVPs, standard extensions, vendor extensions, etc.

More Related