During normal authentication, access connections can indicate they are part of a common bonding context by specifying a bonding identifier. When the first connect is set up, an additional authentication phase is started for the bonding context itself. Figure: Bonding authentication shows RADIUS-based authentication for bonding of an IPoE and GTP access connection. For simplicity, all access nodes, such as the residential gateway, MSAN, eNodeB, and MME have been identified as a single entity.
All address assignments and Layer 3 parameters are shared between the access connections and are therefore handled in the bonding context. The system supports either Local Address Assignment or AAA-provisioned IP addresses. Access connections cannot use any DHCPv6 relay or client mechanisms.
After the setup is complete, ESM subscriber resources are created for each context as follows.
a unique subscriber with a single internal IPoE session to represent the bonding context
This is the main context for functionality, including QoS, filters, and accounting. This subscriber cannot be reused for any other hosts, regardless if they are bonding or not.
-
a subscriber per access connection with one or more hosts as needed, depending on the access type
This subscriber must be distinct from the bonding subscriber. Other non-bonded hosts or sessions may be present under the same subscriber. A subset of ESM features (for example, QoS, filters, and accounting) are also available in this context; however, it is recommended that the most of the feature be configured in the bonding context.
All access and bonding ESM contexts need to be present in distinct VRFs. The bonding context must be created in a special group interface of type bonding. This group interface is not linked to any SAPs, however, an FPE construct ensures the link between the access and bonding context.