Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
  
[+] Expand All
[-] Collapse All

Sequence and Flow of CoA/DM Requests Through Steel-Belted Radius Carrier

Figure 250 shows the sequence diagram of requests and responses that occur between the initial client request and final client response for a disconnect message.

Figure 250: Example Sequence of a Disconnect Message (DM) Action

Example Sequence of a Disconnect Message
(DM) Action

The XML client request is sent to the CoA/DM subsystem from the management client. The CST is queried for some number of sessions. A session is selected and a RADIUS DM-Request is sent to the various controlled devices (NAS). Finally, a response is sent back to the management client.

Figure 251 shows how multiple device request/responses are created for one disconnect message.

Note: In Figure 251, and in the following discussion the terms client request, session data, session request and device request, are all XML elements in the Steel-Belted Radius Carrier XML interface and deviceModels.xml file.

The action templates shown in Figure 251 equate to the <action> element in the deviceModels.xml file, and the <deviceRequestSpec> element in the API.

The example shown in Figure 251 shows a client request that includes an action called disconnect for User-Name='bob'. The query of the CST finds two active sessions for User-Name='bob' being handled by two different NAS: Session-Id=abcdef012345 is being handled by a NAS with NAS-Identifier=device1, and Session-Id=ffffff010101 is being handled by a NAS with NAS-Identifier=device2.

Figure 251: Example Data Flow for a Disconnect-Request

Example Data Flow for a Disconnect-Request

Data from the client request is merged with the data from each active session found in the CST (session data), to form the two session requests. The data gathered from the device and action lookup in the deviceModels.xml file is combined with the existing session request data to form the action template. The action template specifies the attribute packing list for both device requests. The action template is merged with the session request to form the final request (device request) sent to each NAS.

If not all attributes in the packing list can be populated with the available information, the device request fails and Steel-Belted Radius Carrier returns a detailed response indicating the missing information to the client.

If the packing list is successfully satisfied, the specified RADIUS packet (device request) is sent to the device and Steel-Belted Radius Carrier waits for a successful response, failure response, or timeout, before returning an XML result report to the client.

Defining the same action for all NAS in your network simplifies what you need to specify in client requests. In the example shown in Figure 251, because the action disconnect is defined in the deviceModels.xml file for both NAS (device1 and device2), you simply need to invoke the action disconnect in the client request, with the arguments User-Name='bob', and all user sessions for bob are terminated.

Figure 252 shows the data flow for an example CoA request.

Note: In Figure 252, and in the subsequent discussion the terms client request, session data, session request and device request, are all XML elements in the Steel-Belted Radius Carrier XML interface and deviceModels.xml file.

The action templates shown in Figure 252 equate to the <action> element in the deviceModels.xml file, and the <deviceRequestSpec> element in the API.

Figure 252: Example Data Flow for a CoA-Request

Example Data Flow for a CoA-Request

The example shown in Figure 252 includes a client request with an action called boost for User-Name='bob'. You can name actions anything you want. In this example, the name boost is meant to represent boosting the bandwidth of a session. The query of the CST finds two active sessions for User-Name='bob' being handled by two different NAS: Session-Id=abcdef012345 is being handled by a NAS with NAS-Identifier=device1, and Session-Id=ffffff010101 is being handled by a NAS with NAS-Identifier=device2.

Data from the client request is merged with the data from each active session found in the CST (session data) to form the two session requests. The device and action lookup in the deviceModels.xml file determines that the action called boost is defined for the NAS with NAS-Identifier=device1, but is not defined for the NAS with NAS-Identifier=device2. So, in this example, the action called boost can only be performed on Session-Id=abcdef012345 running on NAS-Identifier=device1. The data gathered from the lookup in the deviceModels.xml file for NAS with NAS-Identifier=device1 is combined with the existing session request data to form the action template. The action template specifies the attribute packing list for the device request. The action template is merged with the session request to form the final device request.

If not all attributes in the packing list can be populated with the available information, the device request fails and Steel-Belted Radius Carrier returns a detailed response indicating the missing information to the client.

If the packing list is successfully satisfied, the specified RADIUS packet (device request) is sent to the device and Steel-Belted Radius Carrier waits for a successful response, failure response, or timeout, before returning an XML result report to the client.

Defining the same action for all NAS in your network simplifies what you need to specify in client requests. In the example shown in Figure 251, because the action disconnect is defined in the deviceModels.xml file for both NAS (device1 and device2), you simply need to invoke the action disconnect in the client request, with the arguments User-Name='bob', and all user sessions for bob are terminated.

Note: When configuring actions in the deviceModels.xml file, we recommend you name each action something generic so that different device models can use the same name for an equivalent action.

Modified: 2018-01-11