Page 155 - 5G Basics - Core Network Aspects

Core network aspects 1

Appendix I

Areas for further considerations in SDN standardization
(This appendix does not form an integral part of this Recommendation.)

In this appendix, technical areas for further considerations in SDN are described.

I.1 Interworking
A network in one administrative domain is usually controlled and managed by the service policy applied by
one network provider. However, integrated network services among multiple administrative domains need
to be composed of relevant network services in each administrative domain. It is important that SDN provides
interworking functionality for such integrated network services among multiple administrative domains
taking into account the following points:
– It is important that SDN exchange available network parameters (e.g., bandwidth, latency, label or
id information) for automating the control and/or management of the network services among
different administrative domains. These network parameters may be screened or abstracted
because such network parameters contain sensitive information in many cases. This functionality
may also need to configure a part of other administrative domain networks and get statistics about
the domain.

The following points are not specific to SDN, but need consideration.
– In forwarding packets across multiple administrative domains, packet formats may be different, and
it is important to support converting the format of packets and/or adjusting the network properties
(e.g., bandwidth and latency) before or after packets enter another network;

– It is also important to support authentication, authorization, and accounting (AAA) features because
interworking operations usually need computational resources from other administrative domains.

I.2 Verification of SDN applications

With SDN technologies, network providers, service providers, and customers can customize the network
resources by writing an SDN application. However, incomplete or malicious SDN applications could cause a
breakdown of underlying networks shared by heterogeneous network elements and stakeholders. Thus, it is
desirable that SDN applications be formally specified and verified (i.e., formal method) to prevent them from
misinterpreting their intentions on network operations and to avoid inconsistency within the network.
Formal methods are software engineering techniques based on mathematical representation and analysis of
software programs [b-FM Clarke]. Such formal methods can be used for analysis of specification and
verification of software behaviour.

Using the formal methods for SDN applications can minimize the risk of misuse or malfunction of SDN
applications because the formal method serves to remove ambiguity, inconsistency, and possible conflicts of
SDN applications in the networks. Furthermore, network operators can use the formal methods to check
consistency and safety of their network configurations, virtual/physical topologies and networking resources.
This enables confirmation of their configurations and behaviours of various networking properties. Some
examples of these properties are:
– no routing loops or unreachable points in the network;
– no rule or behaviour conflicts between multiple SDN applications;

– no conflicts on physical network resource assignments between different SDN applications;
– no conflicts in dynamic network update where new or updated network configurations conform to
properties of the network and do not break consistency of existing networks.

145