Description of Change
Initial draft for discussion at the 12-16 March, 2018 OIMT face to face meeting
Is there any IPR and/or Patentable Interest Declaration associated with this contribution NO
NOTICE: This contribution has been prepared to assist the ONF. This document is offered to the ONF as a basis for discussion and is not a binding proposal on ZTE or any other company. The requirements are subject to change in form and numerical value after more study. ZTE specifically reserves the right to add to, amend, or withdraw statements contained herein.
THE INFORMATION HEREIN IS PROVIDED “AS IS,” WITHOUT ANY WARRANTIES OR REPRESENTATIONS, EXPRESS, IMPLIED OR STATUTORY, INCLUDING WITHOUT LIMITATION, WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The purpose of this contribution is to initiate discussion of using the control construct (CC) and constraint domain (CD) to represent a SDN controller.
The purpose of a SDN controller is to allow the management of resources. This contribution addresses the model that allows management of the SDN controller.
Figure 11 of TR-521 SDN Architecture v1.1:
Figure 1 SDN Architecture showing contexts
The figure 2 below shows a controller with one client context and one server context:
Figure 2: Mapping to CC/CD
In Figure 2 the controller is represented by a constraint domain. The control construct in the controller is accessed via a port. The administrator (see TR521 section 5.2.1) can (via the port and control construct):
The client context is represented by a constraint domain with a control construct. This control construct communicates with the corresponding server control construct in the client controller (via the port) to:
The server context is represented by a constraint domain with a control construct. This control construct represents the resources provided by the server controller to the local controller. The control construct communicates with the corresponding client control construct in the server controller (via the port) to:
Figure 13 in section 8.3 of TR-521 shows a peer relationship between controllers:
Figure 3: SDN architecture peer relationship
The text below figure 13 states:
Figure 13 illustrates two SDN controllers in a peer relationship, in which either may act as client to invoke services from the other as a server. Each requires a client context and a server context for the other. SLA, policy and information hiding are applicable between peers just as between hierarchical provider and customer. The client and server context for a peer may be separate, as shown. But they could also combine certain aspects such as association credentials and security policy.
In the case where the client and server contexts are independent (i.e. they use of separate ports and independent credentials and security policy) the model shown in section 2 can be used.
One approach to address the case where the port, association credentials and security policy is shared is shown in figure 4 below.
Figure 4: Constraint domain for peer associations
The arrangement requires the use of a common port and allows the credentials and security policy to be shared. The control construct accesses the appropriate constraint domain depending on if a message is in the context of a client role or server role.
The model for peer controllers could be used for hierarchical controllers, in this case either the client context or server context would be absent in the instance model. Since the constraint domain for the peer association and the client context would be essentially the same it would be possible to omit the client context (or server context) from the instance model.
In the preceding sections a “simple” view of the logical associations is provided. i.e. the port to port relationship is 1:1.
Even in this “simple” case the port association must support multiple sessions from different users with different access/view/control privileges. E.g. one use may only be able to view status and utilization; another user may be able to request configuration etc.
In a more general case a client may have different users in different (physical) locations, so whilst we have a single logical association it may be implemented by multiple connections (to different locations) which may result in multiple logical associations.
In general, a controller will have multiple (logical) associations each of which support multiple sessions. The multiple sessions will share one (or more) physical ports. In this case the FDs and LTPs that support the logical associations should be within the constraint domain of the controller and be outside the constraint domain of any client or server contexts.
It’s not clear if encryption should be:
The following issues have not (yet) been considered.