Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    SAE Support for Dual-Stack Configuration

    JunosE supports configuration of Internet protocol versions—IPv4 and IPv6—on a single interface. This creates two IP layer interfaces (IPv4 and IPv6), known as dual-stack, that run and report independently.

    To support dual-stack configuration, the functionality of the SAE is configured to create a single subscriber session for a set of IP interfaces. All services activated for a subscriber session impacts the related interfaces. For example, when both IPv4 and IPv6 interfaces exist for a subscriber session, a service activation installs policies on both the interfaces.

    Note: Each dual-stack interface consumes about twice the memory resources than a single interface. The total number of subscriber sessions supported by the SAE for dual-stack interfaces would be cut by half.

    • For C3000, the maximum number of dual-stack subscriber sessions is 150,000 (using two active services per subscriber).
    • For C5000, the maximum number of dual-stack subscriber sessions is 500,000 (using two active services per subscriber).

    The performance in login/logout rate, as well as service activation/deactivation rate of a dual-stack interface would be about 50% when compared to the performance of a single-stack interface.

    Handling of Interface-Up Notification

    In dual-stack configuration, the interfaces are reported by the router independently. The router sends two interface-up notifications that are tied together by their interface name. The default policies for a subscriber session are then applied independently on these interfaces.

    The dual-stack interface-up notification sequence is as follows:

    1. When the router receives the first IP interface-up request, it acquires a lock on the interface.

      For example, if an IPv4 interface is reported first, the router acquires a lock for the interface name and holds on to it until the request is processed.

      The router keeps track of the underlying interfaces (IPv4 and IPv6) and communicates with the SAE to create appropriate policies for each interface.

    2. The router processes the IP interface-up request, creates the user session, and installs default policies.
      • If default policies are not defined, processing for the interface stops and the interface remains unmanaged.
    3. The activate-on-login service session provisions the relevant policies (IPv4 and IPv6) for the interface.
    4. The router releases the lock on the IP interface after the request has been processed.
    5. When the router receives the second IP interface-up request, it attempts to acquire a lock on the IP interface.
      • If the processing for the first IP interface request is not completed, the router handler thread blocks the second IP interface-up notification until the lock is released for the first IP interface.
    6. The router processes the second interface-up request and installs the default policies.
      • If default policies are not defined, processing for the interface stops and the interface remains unmanaged.
    7. The router checks for the user session that is currently associated with the interface name.
      • If a user session already exists, the request is handled in the similar way to an update request and a relogin is triggered. If the relogin does not result in the termination of the existing user session, all active service sessions are notified of the modification.
    8. The activate-on-login service session provisions the relevant policies on the second IP interface.
    9. The router releases the lock on the second IP interface after the request has been processed.

    Handling of Interface-Up Notification with Delay Timer

    The delay timer (dual-stack-delay) is configured to reduce the number of interface-up notifications. This is useful if most of the interfaces are expected to be dual-stack interfaces because it reduces the overhead of relogin and update plug-in events.

    Note: The dual-stack-delay attribute is not enabled by default.

    The sequence of interface-up notifications with delay timer is as follows:

    1. When the router receives the first IP interface-up request, it processes the request and installs the default policies.
    2. The router creates an IP interface context that represents the Common Open Policy Service (COPS) object.
    3. The IP interface context schedules a timer and suspends further processing. This postpones the creation of user sessions.
    4. After provisioning the default policies on the second IP interface, the IP interface context cancels the timer for the first IP interface.
    5. The user session is created for the dual-stack interface.
    6. The activate-on-login service provisions the service policies that are applied to both interfaces of the dual-stack.

    Note: If the first IP interface request is not part of a dual-stack interface, then the creation of the user session is delayed until the timer expires. This causes a delay in the login rate for a single-stack interface.

    If the second IP interface request is received after the expiry of the delay timer, the user session is created and a relogin is triggered and events are updated.

    Handling of Interface-Down Notification

    The sequence of interface-down notifications for dual-stack configuration is as follows:

    1. When the first IP Interface begins to shut down, the router sends a COPS delete request (DRQ) message.
    2. The router stores final accounting for all active policies of the first IP interface to the associated IP interface context and notifies the SAE that the interface is down.

      Because the IP interface is also associated with a second IP interface context, no further action is triggered.

    3. The router sends final accounting for all active polices of the second IP interface to the associated IP interface context.
    4. The router notifies the SAE that the second IP interface is down.
    5. The router driver initiates the logout of the subscriber session because both the interfaces are down.
    6. The subscriber session deactivates all active services and the service session removes the installed policies.
    7. After the subscriber session is logged out, the interface contexts for IPv4 and IPv6 are discarded.
    8. The router driver returns the accounting data for the individual policies.

    Service Activation

    The router keeps track of the underlying interfaces and communicates with the policy engine to create the appropriate policies for each interface. The service session provisions the relevant policies (IPv4 and IPv6) for the interface.

    Service Deactivation

    When the interface is down, the router notifies the SAE and deactivates the service session. The service session passes the stored provisioning sets (IPv4 and IPv6) to the router driver. The router driver removes the policies and returns the accounting data for the individual policies. Accounting data for services contains the sum of IPv4 and IPv6 counters.

    Subscriber Attributes

    The framedIpv6Prefix and delegatedIpv6Prefix attributes are added to the subscriber object and can be queried through the SAEAccess API module.

    • The framedIpv6Prefix attribute contains the IPv6 prefix for the subscriber.

      framedIpv6Prefix is available for JunosE (COPS-PR), Junos OS (JSRC), as well as AAA (COA).

    • Using the delegatedIpv6Prefix attribute, the NAS can receive a set of IPv6 prefixes that are delegated to subscribers.

      An IPv6 subscriber can be identified through multiple prefixes by using the delegatedIpv6Prefix attribute together with the framedIpv6Prefix attribute.

      delegatedIpv6Prefix is available for Junos OS (JSRC), AAA (COA), and DHCPv6 subscribers on the JunosE router.

    SAEAccess API Plug-in Attributes

    The SAEAccess API plug-in is extended to support the following attributes:

    • PA_FRAMED_IPV6_PREFIX—An octet string formatted as specified in RFC3162. The first octet is 0, the second octet contains the length of the prefix in bits (1–128), and the following octet contains the actual prefix.
    • PA_DELEGATED_IPV6_PREFIX—An octet string formatted as specified in RFC4818. The first octet is 0, the second octet contains the length of the prefix in bits (1–128), and the following octet contains the actual prefix.
    • PA_USER_IP_MASK—Number of bits in the subscriber address (PA_USER_INET_ADDRESS). This attribute is available both for IPv4 and IPv6 addresses, if the underlying router driver provides the value, which is presently the case for JunosE (COPS-PR), Junos OS (JSRC), and AAA (COA).

    For dual-stack interfaces, the PA_USER_INET_ADDRESS attribute contains the IPv4 address of the subscriber, whereas PA_FRAMED_IPV6_PREFIX contains the IPv6 address prefix.

    For single-stack interfaces, the PA_USER_INET_ADDRESS attribute contains either the IPv4 or IPv6 address depending on the address family assigned to the subscriber.

    Subscriber Session Lookup

    Subscribers are identified by the set of IPv6 prefixes defined by the device driver. If both framedIpv6Prefix and delegatedIpv6Prefix are present for a subscriber session, then any IPv6 address that matches any one of the prefixes identifies the subscriber session.

    For example, a subscriber session is reported by a device driver with the framedIpv6Prefix = 2001:db8:1:1::/64 and delegatedIpv6Prefix = 2001:db8:2:2::/64 attributes. Any IP address starting with one of these prefixes identifies the subscriber session (2001:db8:1:1:0:1:2:3, 2001:db8:2:2:4:3:2:1, and so on).

    Published: 2014-12-10