Child pages
  • Contributions

SUE Projects:1306 ONF Misc:5-Templates:5-21 MS Word - Spec:links:ONF-horiz-med.tif  

 

 

 

 

 

 

 

 

 

Version

Date

Description of Change

00

2018-03-07

Initial draft for discussion at the 12-16 March, 2018 OIMT face to face meeting

 

 

IPR Declaration

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.

 


1        Introduction

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.

2        Hierarchical arrangement of SDN controllers

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):

  • Create client contexts, and server contexts with the associated control construct and port.
  • Assign resources (e.g. LTPs, FDs) to a client context.
  • Enable the port on a control construct and provide the credentials for the controller to authenticate with the corresponding control constructs in the client or server controller
  • Create the required artefacts (control constructs) that represent the G.7701 and G.7702 control components. Assign them to the appropriate constraint domain. Work on the model for these control components and the allocation to the constraint domain should be undertaken in Q14/15.

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:

  • Provide the client with an abstract (e.g. aggregated, name translation, client context specific lifecycle state etc.) view of the resources that have been allocated to that client.
  • Provide an “administrator” interface to allow the client to establish the credentials and access rights of user. (See TR-521 section 6.7)

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:

  • Retrieve information about the resources that have been allocated.
  • Request configuration of those resources
  • Request configuration of user credentials and access rights (in the associated client context).
  • Provide name translation between the server context and the controller.

3        Peer controllers

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.

3.1      Alternate approach for hierarchal controllers

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.

4        Mapping logical ports to the communications infrastructure

4.1      Port associations

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.

4.2      Multiplexing sessions

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.

4.3      Encryption

It’s not clear if encryption should be:

  • A common service for all logical associations; in which case it could be modelled as a part of a common LTP; or:
  • Per session within an association; in which case it could be modelled as a function of the control component or as a separate LTP.

5        Other issues

The following issues have not (yet) been considered.

  • Redundancy: The clients of a controller should not be aware of the implementation of redundancy in the controller.
  • Model of the supporting infrastructure: A SDN controller may be implemented on a COTS sever platform that provides the basic compute, storage and (control) communications infrastructure that can be configured to support a SDN controller.
  • Scalability: The approach described above requires one control construct per client or server context plus one control construct for the controller. i.e. we will have (1 + # client contexts + # server contexts) control constructs. Will the overhead of the control constructs become a burden in an implementation.