RADIUS Chargeable User Identity Farid Adrangi Avi Lior Jouni Korhonen draft-adrangi-radius-chargeable-user-identity-02.txt
Current Issues IssueDescriptionSubmitterResolutionStatus 13 Inconsistencies with Diameter CC David Mariblanca Fix in -01 version Open 14 Review of Chargeable User Identity Bernard Aboba Fix in -01 version Open 15 Editorials comments on chargeable User Identity Greg WeberFix in -02 version Open Backward Compatibility Lothar ReithProposed CUI advertisement Open a better explanation of the problem and its applicability John Loughney open
Next Step Should this be WG item? –Is this a valid problem? If yes, resolve issues by next IETF
RADIUS Redirection Avi Lior Farid Adrangi draft-lior-radius-redirection-01
Need Review No activity in this period. Please review and give us comments.
RADIUS Bandwidth Capability F. Adrangi, Intel P. Congdon and C. Black, Hewlett Packard A. Lior, Bridgewater Systems F. Bari, Cingular Wireless draft-adrangi-radius-bandwidth-capability-01.txt
Slightly new approach Previously the draft reflected a single model for expressing/negotiating bandwidth. Found out that there are many ways to do this. –Lots of different attributes etc… The best approach would be to define a framework that can support these different models.
Bandwidth Attributes Bandwidth attribute –E.g. Ingress-QoS-Blob, Egress-QoS-Blob –Would be encoded as a string –First octet(s) would define the type of information in the blob. We can standardize some methods in this document: –Tell us which? Others can define new approach –IANA registration of “blob-type-codes”
Example Assuming 001 represents IngressQosBlob for RFC2697. String format: 001XXXXXXXXYYYYYYYYZZZZZZZZAAAAAA....., where –XXXX... is unsigned32 Committed Information Rate (CIR) –YYYY... is unsigned32 Committed Burst Size (CBS) –ZZZZ... Is unsigned32 Excess Burst Size (EBS) –AAAA....is action code which expresses what to do in this case with green yellow and red packets For example, a service may discard all red packets, because they exceeded both the committed and excess burst sizes, forward yellow packets as best effort, and forward green packets with a low drop probability..
Bandwidth ID This was missing from previous work Same concept as Filter-Id –Handle to Bandwidth Blob in the NAS ( provisioned statically or available dynamically) If provisioned statically - yes, it does not scale!!! –But it is nevertheless useful. Not every environment needs to scale. –Bandwidth ID can allow for very precise bandwidth control. But Bandwidth-ID can also refer to a Bandwidth Blob provisioned dynamically or that can be retrieved from somewhere and hence it does scale.
Backup Slides ….
Example use of Bandwidth Id in Dynamic Situations UEAF 1: UE and AF negotiate QoSE.g., SIP Policy Decision Function 2: AF request QoS Token NAS Token 3: UE Requests “Flows” Access RequestBandwidth-ID Access AcceptQoS Blob Token placed in Bandwidth-Id and is used as a handle to fetch the QoS Blob