TL;DR: In this article, a method and system for processing a software defined network (SDN) call initiated by a network adjunct platform (NAP) over a Small Scale Adjunct Primary Rate Interface (SSA PRI) in a telecommunications network on a call-by-call basis is disclosed.
Abstract: A method and system for processing a software defined network (SDN) call initiated by a network adjunct platform (NAP) over a Small Scale Adjunct Primary Rate Interface (SSA PRI) in a telecommunications network on a call-by-call basis is disclosed. An SDN subscriber triggers the NAP to initiate the SDN call. The NAP forwards set-up data to an originating toll switch programmed to accept the set-up data from the NAP. After receipt of the set-up data, the originating toll switch determines if the forwarded set-up data classifies the call as an SDN call. If the forwarded set-up data contains SDN parameters, the originating toll switch processes and routes the call initiated by the NAP as an SDN call. The originating toll switch is also able to process and route non-SDN calls utilizing the same SSA PRI used for SDN calls. The need for separate dedicated trunk groups for SDN subscribers is alleviated.
TL;DR: This document describes a mechanism based on the SDN paradigm to support the distribution and monitoring of IPsec information from a SDN controller to one or several flow-based Network Security Function (NSF).
Abstract: This document describes the use case of providing IPsec-based flow
protection by means of a Software-Defined Network (SDN) controller
(aka Security Controller) and establishes the requirements to support
this service It considers two main well-known scenarios in IPsec: (i)
gateway-to-gateway and (ii) host-to-host This document describes a
mechanism based on the SDN paradigm to support the distribution and
monitoring of IPsec information from a SDN controller to one or
several flow-based Network Security Function (NSF) The NSFs implement
IPsec to protect data traffic between network resources with IPsec
The document focuses in the NSF Facing Interface by providing models
for Configuration and State data model required to allow the Security
Controller to configure the IPsec databases (SPD, SAD, PAD) and IKE to
establish security associations with a reduced intervention of the
network administrator NOTE: State data model will be developed as
part of this work but it is still TBD
TL;DR: Bell Communications Research, a research and development facility of the Regional Bell Operating Companies (RBOCs), has proposed three distinct architectural variations (IN/1, IN/1+, and IN/2) to facilitate the orderly evolution of network intelligence in the public domain.
Abstract: In order to facilitate the orderly evolution of network intelligence in the public domain, Bell Communications Research, a research and development facility of the Regional Bell Operating Companies (RBOCs), has proposed three distinct architectural variations (IN/1, IN/1+, and IN/2). Considerable collaboration in the phased introduction of these networks is essential to maintain uniformity and consistency of services throughout the nation. Vendors from all nations participate in supplying the networks components, interfaces, and software modules. To maintain any semblance of order, ITU (formerly CCITT) and ANSI publish stringent standards and well-defined protocol. Most companies follow these standards and implement networks, such as the CCS7 network and packet-switched networks. Based upon signaling and typical architecture, networks evolve, such as the 800 network, software defined network (SDN), and others. These rudimentary networks meet all the basic interface and signaling requirements of the first version of the public domain intelligent network, that is, IN/1.