RADIUS Control

This chapter explains the subscriber and service-related RBFS extensions and RtBrick VSA related to RADIUS services.

RADIUS Session and Idle Timeout

The session and idle timeout values are initialized with zero, which means infinity or disabled. Those values will be optionally overwritten with the values in AAA configuration profile and RADIUS access-accept if present. The priority is RADIUS attributes over AAA configuration profile.

The session (attribute 27) and idle (attribute 28) timeout RADIUS attributes are defined in RFC 2865.

RFC and draft compliance are partial except as specified.

The idle timeout is based on outgoing logical interface statistics (OutLIF) for the subscriber-ifl to determine subscriber inactivity.

RADIUS Routing Instance

VSA 26-50058-137 - RtBrick-Instance

This attribute is applicable to non-IPoE subscribers only. It allows to change the routing instance through a RADIUS access-accept message.

For IPoE subscribers, the routing instance is automatically determined based on the gateway IFL.

RADIUS Gateay-Ifl

VSA 26-50058-138 - RtBrick-Gateway-Ifl

This attribute is applicable to IPoE subscribers only. It allows to change the actual gateway IFL. Consequently, this also indirectly modifies the routing instance through a RADIUS Access-Accept message.

RADIUS DNS Server

VSA 26-50058-131 - RtBrick-DNS-Primary

VSA 26-50058-132 - RtBrick-DNS-Secondary

VSA 26-50058-134 - RtBrick-DNS-Primary-IPv6

VSA 26-50058-135 - RtBrick-DNS-Secondary-IPv6

Those attributes allow to set the primary and secondary IPv4 and IPv6 DNS servers via RADIUS access-accept. DNS servers already set via access configuration profile will be overwritten by RADIUS.

RADIUS Service Profile

VSA 26-50058-70 - RtBrick-Service-Profile

Subscribers can be associated with a service-profile which defines the actual service properties like QoS or IGMP profiles and configuration settings. The service profile can be assigned or changed using the RtBrick-Service-Profile VSA.

RtBrick-Service-Profile = <service-profile>

This attribute is supported via RADIUS access-accept and CoA requests.

All dynamic QoS settings like shaper and policer rates will be reset if the new service-profile includes a qos-profile attribute also if active qos-profile and old qos-profile is equal. All QoS settings remain unchanged if the referenced service profile does not include the qos-profile attribute. If the referenced service profile updates the qos-profile attribute and additional shaper or policer rates are included in the same CoA request which updates the service-profile, those shaper and policer settings will be applied to the new QoS configuration profile after reset. This means that we reset all incremental changes done before. In example if Voice shaper rate has changed to another value, after profile change the default value from profile is used.

RADIUS CoA requests referencing a service profile which is not found on device will be rejected with CoA-NAK (invalid-request) but without changing any subscriber QoS settings. This behavior is different for RADIUS access-accept where service profiles are just ignored if not found. In both cases a warning is generated in subscriber daemon log if a referenced service profile is not found.

RADIUS AAA Profile

VSA 26-50058-69 - RtBrick-AAA-Profile

This attribute allows to change the associated AAA profile from RADIUS access-accept. This is primarily used to change the accounting adjustment values which are defined in this profile. Simple example here is to use different adjustment values for L2TP and local terminated PPPoE sessions. Another valid use case is to assign different RADIUS accounting servers for in example L2TP sessions or wholesale customers.

RtBrick-AAA-Profile = <aaa-profile>

This attribute is supported via RADIUS access-accept only.

RADIUS QoS Profile

VSA 26-50058-62 - RtBrick-QoS-Profile

RtBrick-QoS-Profile = <qos-profile>

This attribute is supported by RADIUS access-accept and CoA request. The QoS configuration profile can be either selected via service-profile or directly using this attribute which has priority of the service-profile.

All dynamic QoS settings like MFC, queue sizes, shaper and policer rates will be reset if this attribute is present in a CoA request also if new qos-profile and old qos-profile is equal. If additional shaper or policer rates are included in the same CoA request which updates the service-profile, those shaper and policer settings will be applied to the new QoS configuration after reset.

The subscriber management infrastructure does not check if a referenced QoS profile exists or not. This is handled by forwarding infrastructure which continues processing the subscriber QoS settings as soon as the profile was added. In the meantime there is no QoS configuration applied.

RADIUS QoS Parent Scheduler

VSA 26-50058-64 - RtBrick-QoS-Parent-Scheduler

The parent scheduler element of the scheduler-map assigned to the subscriber can be selected with this attribute. If not present, the scheduler-map will be directly bound to the local IFP where the session is established.

This attribute is supported in RADIUS access-accept only (no CoA support) and will set the parent scheduler element of the subscriber.

Providing a QoS parent scheduler which is not present on the corresponding IFP will lead to black howling of all egress data traffic. Control traffic is not impacted and therefore the session will remain.

RADIUS QoS Shaper

VSA 26-50058-63 - RtBrick-QoS-Shaper

Subscribers can be associated with a QoS profile which is assigned via service-profile or directly via corresponding VSA (RtBrick-QoS-Profile). This profile is used to instantiate the QoS resources for the subscriber including schedulers, queues and shapers. The assigned shaper instances can be updated using the RtBrick-QoS-Shaper VSA (attribute 26-50058-63) which will apply to the QoS instance of the corresponding subscriber only, but not to the other subscribers using the same QoS profile. It is only possible to update existing shapers dynamically but it is not possible to create a new shaper via RADIUS.

The RtBrick-QoS-Shaper value is a string which contains a list of multiple shaper settings separated by semicolon. Each shaper setting contains a shaper name, high flow rate and low flow rate separated by comma. The actual shaper rate is the sum of high and low flow rate.

RtBrick-QoS-Shaper = <shaper-name>,<high-kbps>,<low-kbps>;<shaper-name>,…​

This attribute can be also used as a key-value list which is automatically recognized by RBFS.

RtBrick-QoS-Shaper = name=<shaper-name>,high=<high-kbps>,low=<low-kbps>;…​

This attribute is supported by RADIUS access-accept and CoA request.

Updating a single shaper (e.g. voice_shaper) via CoA does not require to include other shapers meaning that only the shapers included in the attribute will be updated and all other shapers remain unchanged.

Assume the following example which adapts the session and voice shaper instance of a subscriber.

supervisor@rtbrick: op> show config forwarding-options class-of-service shaper shaper_session
{
  "rtbrick-config:shaper": {
    "shaper-name": "shaper_session",
    "shaping-rate-high": 48000,
    "shaping-rate-low": 2000
  }
}
supervisor@rtbrick: op> show config forwarding-options class-of-service shaper shaper_voice
{
  "rtbrick-config:shaper": {
    "shaper-name": "shaper_voice",
    "shaping-rate-high": 1000,
    "shaping-rate-low": 0
  }
}

RADIUS VSA Change Session Shaper Only

RtBrick-QoS-Shaper: shaper_session,14000,2000

RADIUS VSA Change Session and Voice Shaper

RtBrick-QoS-Shaper: shaper_session,14000,2000;shaper_voice,2000

All active dynamic shapers are stored in the table global.access.1.subscriber.qos.shaper to handover those information to forwarding infrastructure. This table can be used to verify the dynamic shapers which are active for a given subscriber.

The CLI command show subscriber <id> qos displays those information in a nice human readable format.

supervisor@rtbrick: op> show subscriber 72339069014638610 qos
Subscriber-Id: 72339069014638610
    Interface: ifp-0/0/1
    Outer VLAN: 128
    Inner VLAN: 7
    IFL: ppp-0/0/1/72339069014638610
    Profile: qos_profile
    Parent: pon1
    Dynamic Shaper: shaper_voice
        Rate Low: 0 kbps
        Rate High: 2000 kbps
    Dynamic Shaper: shaper_session
        Rate Low: 2000 kbps
        Rate High: 14000 kbps
A shaper rate of 0 means infinity!

RADIUS QoS Policer

VSA 26-50058-65 - RtBrick-QoS-Policer

The RtBrick-QoS-Policer value is a string which contains a list of multiple policer level settings separated by semicolon. Each setting contains a level, cir, cbs, pir, pbs, max-cir and max-pir separated by comma.

RtBrick-QoS-Policer = <level>,<cir>,<cbs>,<pir>,<pbs>,<max-cir>,<max-pir>;<level>…​

Example:
RtBrick-QoS-Policer = 1,2000,200;2,8000,800;3,0,800;4,0,800

  • level: 1 (highest priority) to 4 (lowest priority)

  • cir: Ingress policer committed information rate (kbps)

  • cbs: Ingress policer committed burst size (kbits)

  • pir: Ingress policer peak information rate (kbps)

  • pbs: Ingress policer peak burst size (kbits)

  • max-cir: max ingress policer committed information rate (kbps)

  • max-pir: max ingress policer peak information rate (kbps)

If PIR and PBS are not defined, the values from CIR and CBS are used as PIR and PBS as well. The max CIR and max PIR attributes are optional default set to unlimited.

This attribute can be also used as a key-value list which is automatically recognized by RBFS.

RtBrick-QoS-Policer = level=<level>,cir=<cir>,cbs=<cbs>,pir=<pir>,pbs=<pbs>,max-cir=<max-cir>,max-pir=<max-pir>;…​

Example:
RtBrick-QoS-Policer = level=4,cir=1m,cbs=256;cir=2m,cbs=512,level=3

This attribute is supported by RADIUS access-accept and CoA request.

Updating a single policer level via CoA does not require to include other levels meaning that only the levels included in the attribute will be updated and all other levels remain unchanged. It is only possible to update existing policer levels dynamically but it is not possible to create a new level via RADIUS.

Assume the following example which adapts the just one level as well as all levels of a subscriber.

supervisor@rtbrick: op> show config forwarding-options class-of-service policer policer-residential
{
  "rtbrick-config:policer": {
    "policer-name": "policer-residential",
    "level1-rates": {
      "cir": 1000,
      "cbs": 100,
      "pir": 1000,
      "pbs": 100
    },
    "level2-rates": {
      "cir": 4000,
      "cbs": 400,
      "pir": 4000,
      "pbs": 400
    },
    "level3-rates": {
      "cir": 0,
      "cbs": 800,
      "pir": 0,
      "pbs": 800
    },
    "level4-rates": {
      "cir": 0,
      "cbs": 800,
      "pir": 0,
      "pbs": 800
    },
    "levels": 4,
    "type": "two-rate-three-color"
  }
}

RADIUS VSA Change Level 2 Only

RtBrick-QoS-Policer: 2,12000,1200

RADIUS VSA Change all Levels

RtBrick-QoS-Policer: 1,2000,200;2,8000,800;3,0,800;4,0,800

All active dynamic policer level settings are stored in the table global.access.1.subscriber.qos to handover those information to forwarding infrastructure. This table can be also used to verify the dynamic policer settings for a given subscriber.

The CLI command show subscriber <id> qos displays those information in a nice human readable format.

supervisor@rtbrick: op> show subscriber 72339069014638610 qos
Subscriber-Id: 72339069014638610
    Interface: ifp-0/0/1
    Outer VLAN: 128
    Inner VLAN: 7
    IFL: ppp-0/0/1/72339069014638610
    Profile: qos_profile
    Parent: pon1
    Dynamic Ingress Policer Level 1:
        CIR: 2000 kbps CBS: 200 kbps
        PIR: 2000 kbps PBS: 200 kbps
    Dynamic Ingress Policer Level 2:
        CIR: 8000 kbps CBS: 800 kbps
        PIR: 8000 kbps PBS: 800 kbps
    Dynamic Ingress Policer Level 3:
        CIR: 0 kbps CBS: 800 kbps
        PIR: 0 kbps PBS: 800 kbps
    Dynamic Ingress Policer Level 4:
        CIR: 0 kbps CBS: 800 kbps
        PIR: 0 kbps PBS: 800 kbps
    Dynamic Shaper: shaper_voice
        Rate Low: 0 kbps
        Rate High: 2000 kbps
    Dynamic Shaper: shaper_session
        Rate Low: 2000 kbps
        Rate High: 14000 kbps

RADIUS QoS MFC

VSA 26-50058-66 - RtBrick-QoS-MFC

The multifield classifier can be either derived from qos-profile or directly using this attribute which has priority of the qos-profile.

RtBrick-QoS-MFC = <mfc-name>

This attribute is supported by RADIUS access-accept and CoA request.

The subscriber management infrastructure does not check if a referenced multifield classifier exists or not. This is handled by forwarding infrastructure which continues processing the subscriber QoS settings as soon as the classifier was added.

The string received in these attributes should be stored as mf_classifier_name in the RADIUS attribute object and as well as in the corresponding subscriber-qos object.

RADIUS QoS Queues

VSA 26-50058-67 - RtBrick-QoS-Queues

Subscribers can be associated with a QoS profile which is assigned via service-profile or directly via corresponding VSA (RtBrick-QoS-Profile). This profile is used to instantiate the QoS resources for the subscriber including schedulers, queues and shapers. The assigned queue instances can be updated using the RtBrick-QoS-Queues VSA (attribute 26-50058-67) which will apply to the QoS instance of the corresponding subscriber only, but not to the other subscribers using the same QoS profile. It is only possible to update existing queues dynamically but it is not possible to add queues via RADIUS.

The RtBrick-QoS-Queues value is a string which contains a list of multiple queue settings separated by semicolon. Each queue setting contains a queue name and queue size in bytes separated by comma.

RtBrick-QoS-Queues = <queue-name>,<size-bytes>;<queue-name>,<size-bytes>;…​

This attribute can be also used as a key-value list which is automatically recognized by RBFS.

RtBrick-QoS-Queues = name=<queue-name>,size=<size-bytes>;name=…​

This attribute is supported by RADIUS access-accept and CoA request.

Updating a single queue (e.g. best-effort) via CoA does not require to include other queues meaning that only the queues included in the attribute will be updated and all other queues remain unchanged.

The subscriber management infrastructure does not check if a referenced queue exists or not. This is handled by forwarding infrastructure which continues processing the subscriber QoS settings as soon as the queue was added.

All active dynamic queues are stored in the table global.access.1.subscriber.qos.queue to handover those information to forwarding infrastructure. This table can be also used to verify the dynamic queues which are active for a given subscriber.

The CLI command show subscriber <id> qos displays those information in a nice human readable format.

supervisor@rtbrick: op> show subscriber 72339069014638610 qos
Subscriber-Id: 72339069014638610
    Interface: ifp-0/0/1
    Outer VLAN: 128
    Inner VLAN: 7
    IFL: ppp-0/0/1/72339069014638610
    Profile: qos_profile
    Parent: pon1
    Dynamic Ingress Policer Level 1:
        CIR: 2000 kbps CBS: 200 kbps
        PIR: 2000 kbps PBS: 200 kbps
    Dynamic Ingress Policer Level 2:
        CIR: 8000 kbps CBS: 800 kbps
        PIR: 8000 kbps PBS: 800 kbps
    Dynamic Ingress Policer Level 3:
        CIR: 0 kbps CBS: 800 kbps
        PIR: 0 kbps PBS: 800 kbps
    Dynamic Ingress Policer Level 4:
        CIR: 0 kbps CBS: 800 kbps
        PIR: 0 kbps PBS: 800 kbps
    Dynamic Shaper: shaper_voice
        Rate Low: 0 kbps
        Rate High: 2000 kbps
    Dynamic Shaper: shaper_session
        Rate Low: 2000 kbps
        Rate High: 14000 kbps
    Dynamic Queue: voice
        Size: 200000 byte

RADIUS IGMP Attributes

IGMP service can be dynamically enabled on a subscriber using Radius IGMP Attributes. These attributes are supported by RADIUS access-accept and CoA requests.

Following IGMP related attributes are supported:

VSA 26-50058-71 - RtBrick-IGMP-Status

This attribute can dynamically enable/disable IGMP for a subscriber

Value Code Description

DISABLED

0

Disable IGMP

ENABLED

1

Enable IGMP

VSA 26-50058-72 - RtBrick-IGMP-Profile

RtBrick-IGMP-Profile = <igmp-profile>

This attribute specifies the IGMP-profile to be associated with the subscriber. IGMP profile is configured locally in IGMP with all the IGMP related attributes. This attribute can dynamically associate such a locally configured profile to a subscriber

The subscriber management infrastructure does not check if a referenced IGMP profile exists or not. This is handled by IGMP infrastructure which continues processing the subscriber IGMP settings as soon as the profile was added.

VSA 26-50058-73 - RtBrick-IGMP-Version

This attribute can specify the version of IGMP for a subscriber.

Value Code Description

V1

1

IGMP Version 1 (not supported)

V2

2

IGMP Version 2

V3

3

IGMP Version 3 (Default version if this attribute is not set)

VSA 26-50058-74 - RtBrick-IGMP-Max-Members

This integer attribute can specify the number of parallel streaming (maximum IGMP membership) for a subscriber.

The CLI command show subscriber <id> igmp displays those information.

supervisor@rtbrick: op> show subscriber 72339069014638706 igmp
Subscriber-Id: 72339069014638706
    Interface: ifp-0/0/1
    Outer VLAN: 128
    Inner VLAN: 7
    IFL: ppp-0/0/3/72339069014638706
    State: active
    Version: IGMPv3
    Profile: iptv-basic
    Max Members: 6

The states are active, inactive and disabled. The state is inactive if IGMP is enabled but the IPv4 protocol state is not active.

RADIUS Connection Status Message Attribute

VSA 26-50058-139 - RtBrick-Connection-Status-Message

This attribute allows to send a connection status message string via PPP LCP vendor extension (RFC2513) to the client.

The connection status message is typically used to inform clients about the available bandwidth via RADIUS access-accept or CoA request.

RtBrick-Connection-Status-Message = <string>

Adding or changing the connection status message triggers to send a LCP vendor specific packet with OUI set to f4:1e:5e (RtBrick Inc.) and kind 0x01.

RFC 2513 - Vendor Specific Packet

  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Code      |  Identifier   |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Magic-Number                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                      OUI                      |     Kind      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Value(s) ...
 +-+-+-+-+-+-+-+-+

The value is encoded as TLV with type set to 0x01 and length including type and length field.

The actual status message string is limited to 247 bytes.

Connection-Status-Message Option

  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length     | Connection-Status-Message     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | ...
 +-+-+

PPP clients with support for connection status message will respond with a vendor specific packet of kind 0x02 and the same OUI but no value to acknowledge the packet. All other clients either ignore or reject the message using PPP LCP code reject.

The connection status message will be retried 10 times with an interval of 3 seconds until the client has acknowledged or rejected the packet.

The status of the connection status message can be verified with the following command.

supervisor@leaf1: op> show pppoe session 72339069014638706 detail
Subscriber-Id: 72339069014638706
    State: ESTABLISHED
    Uptime: Mon Sep 13 09:29:42 GMT +0000 2021 (0:14:57.625027)
    Interface: ifp-0/0/1
    Outer VLAN: 128
    Inner VLAN: 7
...
    PPP LCP:
        State: OPENED
        Negotiated Protocols: PAP, IPCP, IP6CP
        Negotiated Parameters: MRU, AUTH, MAGIC
        Magic Number: 130827225 Peer: 2835676915
        MRU: 1492 Peer: 1492
        Echo Interval: 30 seconds
    PPP LCP Connection Status Message:
        State: ACCEPTED
        Message: SRU=10000#SRD=100000#
...

RADIUS Ascend-Data-Filter Attribute

VSA 26-529-242 - Ascend-Data-Filter

The Ascend-Data-Filter attribute describes per subscriber filter terms in a simple binary format as described in the following table. Multiple of those attributes in a single RADIUS access-accept or CoA request message are combined to a dynamic filter where each attribute itself is one filter term. The order of those attributes in the RADIUS message is used to order the corresponding terms in the filter. This means that the first filter in the RADIUS packet has priority over the next and or last filter in the RADIUS packet.

Changes in such a filter via CoA requires that all attributes of the new filter must be sent. Therefore adding a single filter term requires sending the existing filter terms plus the new one or general speaking sending the intended target filter.

This filter is installed as a global packet filter placed before policer in ingress and before scheduler in egress to prevent that traffic dropped here is counted in accounting or consuming rate credits.

Field Bytes Values Comments

Type

1

0 = ignore

1 = IPv4

3 = IPv6

Action

1

0 = discard

1 = accept

0x20 = redirect

Direction

1

0 = egress

1 = ingress

Reserved

1

0

Source

Address

IPv4 = 4

IPv6 = 16

source address

Match on source address is not supported for filters in ingress direction and automatically replaced with the subscriber addresses.

Destination

Address

IPv4 = 4

IPv6 = 16

destination address

Match on destination address is not supported for filters in egress direction and automatically replaced with the subscriber addresses.

Source Prefix Length

1

0 = ignore

prefix length

The number of leading one bits in the source address mask. Specifies the bits of interest.

Destination

Prefix

Length

1

0 = ignore

prefix length

The number of leading one bits in the destination address mask. Specifies the bits of interest.

Protocol

1

0 = ignore

IPv4 protocol number

IPv6 next header

Reserved

1

0

Source

Port

2

port number

UDP/TCP source port in network byte order (big endian)

Destination

Port

2

port number

UDP/TCP destination port in network byte order (big endian)

Source Port Qualifier

1

0 = no compare

1 = less than

2 = equal to

3 = greater than

4 = not equal to

The options 1, 3 and 4 are not implemented and mapped to 0 if received.

Destination Port Qualifier

1

0 = no compare

1 = less than

2 = equal to

3 = greater than

4 = not equal to

The options 1, 3 and 4 are not implemented and mapped to 0 if received.

Not Used

0 - N

0

Trailing bytes after destination port qualifier ignored.

The filter can be deleted dynamically by sending a single Ascend-Data-Filter attribute with a zero value.

Example:

Ascend-Data-Filter = 0x01000100000000000a0afffe002000000000000000000000000000000000

    01          IPv4            // type
    00          discard         // action
    01          ingress         // direction
    00          -               // reserved
    00000000    -               // source address
    0a0afffe    198.51.100.101  // destination address
    00          -               // source prefix length
    20          /32             // destination prefix length
    00          -               // protocol
    00          -               // reserved
    0000        -               // source port
    0000        -               // destination port
    00          -               // source port qualifier
    00          -               // destination port qualifier
    00000...    -               // ignored
For ingress filters, it is not permitted to match based on the source address which is automatically replaced with the subscriber addresses. A similar limitation is valid for egress filters matching on destination address which is also replaced with subscriber addresses.
A new proprietary filter action 0x20 (32) is added for the redirect service. This can be used to enable HTTP Redirect for a subscriber using the ADF.

All active subscriber filters are stored in the table global.access.1.subscriber.filter to hand over that information to the forwarding infrastructure. This table can be also used to verify the filters which are active for a given subscriber.

The CLI command show subscriber <id> acl displays those filters in a nice human-readable format.

RADIUS Access Line Attributes

The access line identification and characterization information are defined in the Broadband Forum (BBF) formerly known DSL Forum attributes including Agent-Remote-Id and Agent-Circuit-Id.

See the following references for more information about access line attributes.

  • RFC 4679 DSL Forum Vendor-Specific RADIUS Attributes

  • RFC 6320 ANCP

  • Broadband Forum TR-101

  • draft-lihawi-ancp-protocol-access-extension-04

Those attributes will be sent in RADIUS access and accounting requests to the RADIUS server if learned from the underlying access protocol like PPPoE (BBF TR-101).

RBFS also provides the possibility to set those values via RADIUS by using the same attributes in the RADIUS access-accept or CoA request message.

Access Line Attributes Supported (RADIUS, PPPoE and L2TP):

Attribute Name

26-3561-1

Agent-Circuit-Id

26-3561-2

Agent-Remote-Id

26-3561-18

PON-Access-Line-Attributes

26-3561-129

Actual-Data-Rate-Upstream

26-3561-130

Actual-Data-Rate-Downstream

26-3561-131

Minimum-Data-Rate-Upstream

26-3561-132

Minimum-Data-Rate-Downstream

26-3561-133

Attainable-Data-Rate-Upstream

26-3561-134

Attainable-Data-Rate-Downstream

26-3561-135

Maximum-Data-Rate-Upstream

26-3561-136

Maximum-Data-Rate-Downstream

26-3561-137

Minimum-Data-Rate-Upstream-Low-Power

26-3561-138

Minimum-Data-Rate-Downstream-Low-Power

26-3561-139

Maximum-Interleaving-Delay-Upstream

26-3561-140

Actual-Interleaving-Delay-Upstream

26-3561-141

Maximum-Interleaving-Delay-Downstream

26-3561-142

Actual-Interleaving-Delay-Downstream

26-3561-144

Access-Loop-Encapsulation

26-3561-145

DSL-Type

26-3561-151

PON-Access-Type

26-3561-155

Expected-Throughput-Upstream

26-3561-156

Expected-Throughput-Downstream

26-3561-157

Attainable-Expected-Throughput-Upstream

26-3561-158

Attainable-Expected-Throughput-Downstream

26-3561-159

Gamma-Data-Rate-Upstream

26-3561-160

Gamma-Data-Rate-Downstream

26-3561-161

Attainable-Gamma-Data-Rate-Upstream

26-3561-162

Attainable-Gamma-Data-Rate-Downstream

26-3561-176

ONT-ONU-Average-Data-Rate-Downstream

26-3561-177

ONT-ONU-Peak-Data-Rate-Downstream

26-3561-178

ONT-ONU-Maximum-Data-Rate-Upstream

26-3561-179

ONT-ONU-Assured-Data-Rate-Upstream

26-3561-180

PON-Tree-Maximum-Data-Rate-Upstream

26-3561-181

PON-Tree-Maximum-Data-Rate-Downstream

This table includes already the new attributes defined in draft-lihawi-ancp-protocol-access-extension-04 which results in possible changes in case the draft is updated.

Changes in at least one of those line attributes via CoA trigger a RADIUS interim accounting request with the new values.

Changes in actual data rate upstream/downstream via CoA request may trigger the L2TP LAC to send a CSUN request with updated connection speed to the LNS depending on the actual L2TP configuration.

RADIUS L2TP

Tunneling of PPPoE sessions via L2TPv2 (L2TP LAC) is supported on RBFS and can be controlled via RADIUS as described in RFC 2868 RADIUS Attributes for Tunnel Protocol Support with some limitations:

  • No support of FQDN format for IP addresses

  • No support Tunnel-Medium-Type other than IPv4

To establish a PPPoE session via L2TP, the tunnel-type must be configured as L2TP. This configuration can be achieved either for local users or by utilizing the corresponding tunnel-type attribute through RADIUS.

Defining an L2TP configuration profile is essential, which can be referenced through an access configuration profile or by employing the appropriate RADIUS VSA. The actual tunnels may either be defined locally via an L2TP pool configuration or set up dynamically through RADIUS.

# FreeRADIUS
# RADIUS authenticated with local defined tunnels.
"radius@l2tp" Cleartext-Password := "test"
    Service-Type = Framed-User,
    Framed-Protocol = PPP,
    Tunnel-Type:0 = L2TP

# RADIUS authenticated with dynamic tunnels.
"tunnel@rl2tp" Cleartext-Password := "test"
    Service-Type = Framed-User,
    Framed-Protocol = PPP,
    Tunnel-Type:1 = L2TP,
    Tunnel-Client-Endpoint:1 = "192.0.2.1",
    Tunnel-Server-Endpoint:1 = "192.0.2.2",
    Tunnel-Client-Auth-Id:1 = "bng",
    Tunnel-Server-Auth-Id:1 = "lns",
    Tunnel-Preference:1 = 100,
    Tunnel-Password:1 = "test",
    Tunnel-Type:2 += L2TP,
    Tunnel-Client-Endpoint:2 += "192.0.2.3",
    Tunnel-Server-Endpoint:2 += "192.0.2.4",
    Tunnel-Client-Auth-Id:2 += "BNG",
    Tunnel-Server-Auth-Id:2 += "LNS2",
    Tunnel-Preference:2 += 200,
    Tunnel-Password:2 += "test"

In addition to the standard attributes, the following vendor-specific attributes are supported for L2TP.

RFC and draft compliance are partial except as specified.

VSA 26-50058-40 - RtBrick-L2TP-Pool

Instead of RADIUS tunnel attributes it is also possible to configure local L2TP tunnel pools and assign them with this attribute.

VSA 26-50058-41 - RtBrick-L2TP-Profile

The default L2TP configuration profile assigned in the access configuration profile can be changed in RADIUS access-accept to allow different L2TP configurations based on tunnel endpoints. This is typically used to enable or disable L2TP CSUN updates (RFC5515).

VSA 26-50058-42 - RtBrick-L2TP-Tx-Connect-Speed

VSA 26-50058-43 - RtBrick-L2TP-Rx-Connect-Speed

Those attributes are supported in RADIUS access-accept and CoA requests to set the corresponding L2TP to connect speed values directly. Per default, the L2TP connect speed is derived from the actual data rate upstream/downstream of the configured source (PPPoE-IA or RADIUS) if present or set to port speed which can be overridden with the connect speed attributes. Changes in connect speed via CoA request will trigger the L2TP LAC to send a CSUN request to the LNS if enabled.

Those two attributes are defined as 4-byte integers with speed defined in kbits.

RADIUS Lawful Interception

Lawful interception (LI) refers to the facilities in telecommunications and telephone networks that allow law enforcement agencies (LEA) with court orders or other legal authorization to selectively intercept individual subscribers. The term mediation device (MED) used in this document describes the element which receives and optionally converts the intercepted traffic into the format expected by the law enforcement agencies of the corresponding countries.

All of the following attributes must be present in RADIUS access-accept or CoA request to control lawful interception (LI) via RADIUS. Those attributes are salt encrypted using the algorithm described in RFC 2868 for the Tunnel Password. This encryption algorithm is defined for RADIUS access-accept messages only. To support CoA requests the request authenticator should be replaced with 16 zero bytes which is common industry standard.

The LI action NOOP can be used to obfuscate lawful interception requests (fake requests) to prevent just the presence of those attributes indicating that a subscriber is intercepted. LI requests via RADIUS will show up in the same table as requests via REST or HTTP RPC API (global.access.1.li_request).

Failed LI activations are not signaled via RADIUS to prevent that just the presence of CoA response NAK shows that LI request is not fake (action NOOP).

VSA 26-50058-140 - RtBrick-LI-Action (salt encrypted integer)

Value Code Description

NOOP

0

No action / Ignore LI request

ON

1

Start LI / Add LI request

OFF

2

Stop LI / Delete LI request

VSA 26-50058-141 - RtBrick-LI-Identifier (salt encrypted integer)

Device unique lawful interception identifier (LIID) within the range from 1 to 4194303.

VSA 26-50058-142 - RtBrick-LI-Direction (salt encrypted integer)

Value Code Description

INGRESS

1

Ingress mirroring only (from subscriber)

EGRESS

2

Egress mirroring only (to subscriber)

BOTH

3

Bidirectional mirroring (from and to subscriber)

VSA 26-50058-143 - RtBrick-LI-MED-Instance (salt encrypted string)

Routing instance through which the mediation device is reachable.

VSA 26-50058-144 - RtBrick-LI-MED-IP (salt encrypted IPv4 address)

IPv4 address of the mediation device.

VSA 26-50058-145 - RtBrick-LI-MED-Port (salt encrypted integer)

UDP port between 49152 and 65535 are set in the mirrored traffic.

RADIUS Framed Routes

The framed-route attributes are used by the RADIUS to install specific routes for a given subscriber. The corresponding next-hop information is automatically derived from the subscriber context. This functionality is typically used to route additional customer networks through the client device (CPE).

Those attributes are supported via RADIUS access-accept only. Each of those attributes may occur multiple times to install various routes. The actual amount of routes supported is limited by the maximum RADIUS packet size only.

The framed-route attributes are defined in RFC 2865 for IPv4 and RFC 3162 for IPv6 but the actual content of those attributes is implementation dependent. RBFS is expecting a string with a prefix followed by prefix length. The prefix can be followed by further routing options like costs, metric or even next-hop which are currently ignored.

Attribute 22 - Framed-Route

Framed-Route = "198.51.100.69/24"

Attribute 99 - Framed-IPv6-Route

Framed-IPv6-Route = "2001:db8:0:90::/32"

RADIUS Subscriber ACLs (Filters)

The subscriber ACL attributes are used by the RADIUS server to install a specific ACL, which has already been configured in the BNG, for a subscriber. For information about Subscriber ACL Configuration see 'Subscriber ACLs and HTTP Redirect Service' guide. After the Subscriber ACLs are configured with the name and the rules, use the following RADIUS attributes dynamically for adding or changing those ACLs from RADIUS. These attributes are supported in access-accept and CoA.

The subscriber ACL attributes are used by the RADIUS server to install a specific ACL, which has already been configured in the BNG, for a subscriber. For information about Subscriber ACL Configuration, see the 'Subscriber ACLs and HTTP Redirect Service' guide. After the Subscriber ACLs are configured with the name and the rules, use the following RADIUS attributes to add or change those ACLs from RADIUS. These attributes are supported in access-accept and CoA.

When a CoA is issued with one of those ACL attributes or a service profile, it will always reset all existing filters, even if the new service profile does not define any filters. If there are filters specified within the service profile along with subscriber ACL attributes, these subscriber ACL attributes take precedence. The filters are merged by first applying all the filters from the service profile and then adding or replacing filters using the attributes defined here. The final resulting filter set is then applied to the subscriber.

Filters that were applied first but are not defined in the new set will be deleted. Consequently, adding a single filter via CoA will remove all other existing filters. This approach is designed to provide a more declarative way of defining the desired target state without depending on the existing state.

  • VSA 26-50058-76 - RtBrick-IPv4-ACL-In

    Attach IPv4 subscriber ingress ACL (ACL in upstream direction)
  • VSA 26-50058-77 - RtBrick-IPv4-ACL-Out

    Attach IPv4 subscriber ingress ACL (ACL in downstream direction)
  • VSA 26-50058-78 - RtBrick-IPv6-ACL-In

    Attach IPv6 subscriber ingress ACL (ACL in upstream direction)
  • VSA 26-50058-79 - RtBrick-IPv6-ACL-Out

    Attach IPv6 subscriber egress ACL (ACL in downstream direction)

Example:

RtBrick-IPv4-ACL-In = “ipoe-sub1-http-acl“

To detach any of the preceding ACLs and to delete the ACL associated with a subscriber, null string can be used with the corresponding attribute.

Example:

RtBrick-IPv4-ACL-In = ““

RADIUS HTTP Redirect URL

When HTTP Redirect is enabled for a subscriber either through Ascend-Data-Filter or through the subscriber ACLs, HTTP packets from the subscriber get redirected to the URL set by this attribute:

VSA 26-50058-75 - RtBrick-HTTP-Redirect-URL

This attribute is supported on RADIUS access-accept and CoA requests. This attribute allows the overwriting of the URL.

For example:

RtBrick-HTTP-Redirect-URL = “http://portal.rtbrick.com”

To reset the URL:

RtBrick-HTTP-Redirect-URL = “”

RADIUS Terminate Codes

VSA 26-50058-27 - RtBrick-Terminate-Code

The RtBrick-Terminate-Code is sent along with the standard Acct-Terminate-Cause (attribute 49). The list below shows the RtBrick termination codes with the mapping to the standard cause.

RtBrick- Terminate-Code Acct-Terminate-Cause (RADIUS Attribute 49) Description

0

10 (NAS Request)

NA

1

10 (NAS Request)

Subscriber Management Unknown Error

2

9 (NAS Error)

SubscriberD Internal Error

3

9 (NAS Error)

PPPoED Internal Error

4

9 (NAS Error)

PPPoED Object Deleted
This code is used if an PPPoE session object is deleted which is an indication for a crash or some other issues in PPPoE daemon.

5

9 (NAS Error)

L2TPD Internal Error

6

9 (NAS Error)

L2TPD Object Deleted
This code is used if an L2TP session object is deleted which is an indication for a crash or some other issues in L2TP daemon.

7

9 (NAS Error)

AAA Profile Not Found

8

9 (NAS Error)

RADIUS Profile Not Found

9

9 (NAS Error)

Authentication Type Missing

10

9 (NAS Error)

Authentication Order Missing or Invalid

11

10 (NAS Request)

Authentication Failure

12

10 (NAS Request)

Local Authentication Failed

13

10 (NAS Request)

Accounting-Request-On Wait

14

9 (NAS Error)

No RADIUS Authentication Server Configured

15

10 (NAS Request)

RADIUS Authentication Failed

16

17 (User Error)

Authentication Rejected

17

17 (User Error)

Local Authentication Rejected

18

17 (User Error)

RADIUS Authentication Rejected

19

5 (Session Timeout)

Session Timeout

20

4 (Idle Timeout)

Idle Timeout

21

6 (Admin Reset)

Clear Session

22

6 (Admin Reset)

RADIUS CoA Disconnect

23

9 (NAS Error)

PPPoE Unknown Error

24

1 (User Request)

PPPoE PADT Received

25

9 (NAS Error)

PPPoE LCP Error

26

10 (NAS Request)

PPPoE LCP Generic Error

27

1 (User Request)

PPPoE LCP Terminate Request Received

28

10 (NAS Request)

PPPoE LCP Maximum Reject / NAK Exceeded

29

10 (NAS Request)

PPPoE LCP Negotiation Failed

30

10 (NAS Request)

PPPoE LCP Configuration-Request Exceeded

31

10 (NAS Request)

PPPoE LCP Echo-Request Timeout Exceeded

32

9 (NAS Error)

PPPoE PAP Error

33

9 (NAS Error)

PPPoE CHAP Error

34

9 (NAS Error)

PPPoE IPCP Error

35

9 (NAS Error)

PPPoE IP6CP Error

36

9 (NAS Error)

PPPoE NCP Initialization Failed

37

10 (NAS Request)

PPPoE NCP Down

38

6 (Admin Reset)

PPPoE Clear Session

39

10 (NAS Request)

PPPoE Upper Layer Down

40

8 (Port Error)

PPPoE Interface Down

41

10 (NAS Request)

PPPoE Configuration Deleted

42

9 (NAS Error)

PPPoE Access Configuration Profile Not Found

43

9 (NAS Error)

L2TP Unknown Error

44

10 (NAS Request)

L2TP Tunnel Down

45

10 (NAS Request)

L2TP Tunnel Dead

46

10 (NAS Request)

L2TP Tunnel Deleted

47

10 (NAS Request)

L2TP No Tunnel Available

48

10 (NAS Request)

L2TP CDN Request

49

9 (NAS Error)

L2TP Profile Not Found

50

9 (NAS Error)

L2TP Access Configuration Profile Not Found

51

9 (NAS Error)

L2TP No Tunnel Pool Error

52

9 (NAS Error)

L2TP Local Tunnel Pool Error

53

9 (NAS Error)

L2TP RADIUS Tunnel Pool Error

54

6 (Admin Reset)

L2TP Clear Session

55

9 (NAS Error)

Access Configuration Profile Not Found

56

9 (NAS Error)

Local IPv4 Address Pool Not Found

57

10 (NAS Request)

Local IPv4 Address Pool Exhausted

58

9 (NAS Error)

Local IPv6 Prefix Pool Not Found

59

10 (NAS Request)

Local IPv6 Prefix Pool Exhausted

60

9 (NAS Error)

Local IPv6 Delegated Prefix Pool Not Found

61

10 (NAS Request)

Local IPv6 Delegated Prefix Pool Exhausted

62

10 (NAS Request)

PPPoE CHAP Response Timeout

63

10 (NAS Request)

L2TP Session Deleted

64

10 (NAS Request)

Duplicate IPv4 address detected

65

10 (NAS Request)

Duplicate IPv6 prefix detected

66

10 (NAS Request)

Duplicate delegated IPv6 prefix detected

67

9 (NAS Error)

Routing instance not found

68

6 (Admin Reset)

Clear Session Force

69

6 (Admin Reset)

Test AAA Request Object Deleted

70

9 (NAS Error)

IPoED Object Deleted
This code is used if an IPoE subscriber object is deleted which is an indication for a crash or some other issues in IPoE daemon.

71

9 (NAS Error)

IPoED Internal Error

72

9 (NAS Error)

IPoE Unknown Error

73

10 (NAS Request)

IPoE Upper Layer Down

74

10 (NAS Request)

IPoE Lower Layer Down

75

10 (NAS Request)

IPoE Interface Down

76

10 (NAS Request)

IPoE Configuration Deleted

77

10 (NAS Request)

SubscriberD Request

78

10 (NAS Request)

L2BSA Service Deleted

79

10 (NAS Request)

L2BSA Service Added

80

6 (Admin Reset)

IPoE Clear Subscriber

81

6 (Admin Reset)

PPPoE Clear Session Force

82

9 (NAS Error)

IPoE Invalid Gateway IFL

83

9 (NAS Error)

FWD Invalid

84

9 (NAS Error)

FWD Failed

85

9 (NAS Error)

FWD Deleted

86

10 (NAS Request)

Instance Deleted

87

10 (NAS Request)

Redundancy Switchover

88

10 (NAS Request)

Redundancy Active Node Termination

89

10 (NAS Request)

Redundancy Active Node Down

90

9 (NAS Error)

Redundancy Invalid State

91

9 (NAS Error)

Redundancy Invalid State for Sync

92

9 (NAS Error)

Redundancy Validation Failed

93

10 (NAS Request)

Redundancy Config Deleted

94

9 (NAS Error)

Redundancy Stale Timer Expiry

95

9 (NAS Error)

IPv4 In ACL Validation Failed

96

9 (NAS Error)

IPv4 Out ACL Validation Failed

97

9 (NAS Error)

IPv6 In ACL Validation Failed

98

9 (NAS Error)

IPv6 Out ACL Validation Failed

99

9 (NAS Error)

IP Address Allocation Failed

100

9 (NAS Error)

No IP Address

This code is used if a forwarding subscriber object is deleted which is an indication of a crash or some other issues in the forwarding infrastructure.

It is recommended to raise operational alarms for every termination cause received with a value of 9 (NAS Error) for further investigations.

RADIUS CoA Error Handling

CoA requests should be retried a few times in the unlikely event of CoA NAK with error-cause (RFC 5176 attribute 101) other than session-context-not-found (503) or missing-attribute (402). There is no rollback of failed CoA requests to the former state but retrying the same request is supported because changes are implemented in a more declarative way.