Contents
1 Introduction
This document gives Solution Architects guidance on how to deploy the Call Session Control Function (CSCF) Virtual Network Function (VNF) in a cloud environment. The document provides a logical description of the CSCF VNF networking requirements. The final section gives examples of cloud networking infrastructure configurations required to fulfill the networking requirements of the CSCF VNF.
The document describes how to configure the cloud network infrastructure from a CSCF VNF perspective. This document does not specify the exact commands to execute, or Application Programming Interface (API) calls to make, but rather describes the configuration on a logical level.
It is assumed that the cloud framework, including hardware and relevant software components, is already installed. It is also assumed that the user of this document has a deep understanding of the cloud infrastructure on which the CSCF VNF is to be deployed.
It is assumed that the reader of this document has a deep understanding of the CSCF, and the document CSCF Technical Description has been read and fully understood. For detailed information of each CSCF interface/integration-point, refer to the relevant Interwork Description.
It is outside the scope of this document to describe how to configure external router and other routers on the customer site. However, there is a general recommendation on how external router can be configured in the document, without specifying any details. It is also outside the scope of this document to describe any firewall configuration.
This document does not cover dimensioning or scaling aspects of a CSCF VNF deployment.
For more information on scaling, refer to CSCF Scaling Management.
2 CSCF VNF Logical Network Reference Setup
The CSCF VNF is realized by using several logical networks, where each logical network has its own purpose. This document proposes a reference logical network setup, which is realized by the virtual networks that are listed later in this document. The reason for using different logical networks is to enable logic separation between different functions owing to, for example, security reasons.
It is not required that the CSCF VNF is deployed using the reference logical network setup that is described in this document. The logical network setup can be altered depending on deployment-specific requirements. Any logical network setup other than the CSCF reference logical network setup is not elaborated further in this document.
How to set up the CSCF VNF, and how to allocate software components to Virtual Machine (VM) instances is described in CSCF Software and Pool Allocation Guidelines, and is therefore not in the scope of this document.
For more information regarding basic requirements of what is required from a cloud infrastructure, refer to Virtual CSCF Infrastructure Requirements.
2.1 Logical Network Reference Setup
The CSCF VNF exposes several network interfaces. These interfaces expose the CSCF functionality, or are used by the CSCF to access network functions, for example Domain Name System (DNS) and Network Time Protocol (NTP). In the reference network setup of the CSCF VNF, one or more of these network interfaces is allocated to a virtual network.
The following logical networks are part of the CSCF reference network setup. This document assumes that the same logical networks exist in an operator network, and that the operator requires that the CSCF VNF is being connected to these existing logical networks:
- Operation and Maintenance Network
- Signaling Network
- Charging Network
- Internal Network
- Confidential network
Which CSCF VNF interfaces are exposed in each network is described later in the document. It is outside the scope of this document to show how other network entities are connected to the listed logical networks.
- Note:
- There are no External Network entities connected to the Internal Network. The Internal Network only connects the CSCF VNF instances.
Figure 1 shows an overview of the CSCF VNF, the associated pool allocations (profiles), and the logical network included in the reference logical network setup.
Each logical network is realized using one or more virtual networks and optionally a Virtual Routing Function as described later in this document. This document does not describe how virtual networks and Virtual Routing Functions are realized by the cloud infrastructure.
As defined in Virtual CSCF Infrastructure Requirements, the minimum cloud configuration (2+2) is used to illustrate the CSCF network connectivity. Scaling-out can be performed to increase the number of Payload Profile VM instances as described in CSCF Scaling Management.
2.2 IP Routing
Routing towards the CSCF VNF from the external router to the respective Virtual Routing Function is assumed to use Policy Based Routing (PBR). PBR is a technique used to make routing decisions based on polices (source, destination, port, and so on) set by the network administrator. Usually, it can also be read as static routes in a router.
The IP routing logic in the respective Virtual Routing Function (realized by Virtual Routers, see for example, Figure 3) then forwards the IP packet to the correct CSCF VNF VM instance. The following deployment strategy is used to realize the IP routing logic in the Virtual Routing Function:
- Static routing in Virtual Routing Function
This means that static routing is configured in the Virtual Routing Function. This results in that the incoming IP packets are forwarded to one of the VM instances that handles the specific Virtual IP address (VIP). To distribute the IP packets between the different VM instances, and to avoid reordering of IP packets inside the CSCF, flow-based Equal-Cost Multipath (ECMP) is required. ECMP in this context means that all IP packets within the same IP flow (TCP session, SCTP stream, and fragmented UDP packets) are received by the same CSCF VM instance.
In the following sections, routing is described assuming that static routing is used.
2.3 CSCF ALB Configuration
The CSCF software is distributed across the VMs within a VNF using two software profiles – Controller Profile (OAM functionality) and Payload Profile (Charging, Signaling and Traffic functionality). Across the VMs, network connectivity is configured through several defined Abstract Load Balancers (ALB), with each ALB having a defined eVIP Front End (FE), Load Balancer Element (LBE), and Security Element (SE), see Figure 2.
- Note:
- Specific eVIP FEs are not configured for internal CSCF application traffic across CSCF VMs. Internal application traffic is distributed as defined by eVIP target pools. Refer to eVIP Management Guide for more information.
2.4 Logical Network Operation and Maintenance
2.4.1 Purpose
The purpose of this logical network is to enable Simple Network Management Protocol (SNMP) communication between the Business Support System (BSS) or Operations Support System (OSS) and the Controller Profile VM instances. This includes the sending of SNMP traps to the OSS and fetching counter-information from the Controller Profile VM instances. The logical network is also used to configure the CSCF VNF and to connect to the Network License Server (NeLS).
The CSCF VNF exposes the following MIP interface on the logical network Operation and Maintenance (OAM):
The CSCF VNF exposes the following direct IP interface to all Controller Profile VM instances. Direct IP interface in this context means public addressable IP address:
2.4.2 Description
It is assumed that the external router is configured with a set of PBR rules. These rules send IP packets targeted to the MIP address (enumerated in Section 2.4.1 Purpose) to OAM Virtual Routing Function (OAM-VR). It is also assumed that the public routable IP addresses are part of the Virtual Network OAM-Ext, hence it is not required to configure any explicit PBR rules in the external router for these public IP addresses.
The OAM-VR is required to enable Layer 3 routing to and from the CSCF VNF. The CSCF VNF VM instances of type Controller Profile use static routing so that the OAM-VR routes incoming IP packets towards the CSCF OAM MIP. These IP packets are sent to the Controller Profile VM instances.
As it is required to have a Virtual Routing Function to enable Layer 3 routing, it is also required to have two virtual networks to realize Logical Network Operation and Maintenance:
- Virtual Network OAM-Ext – A Virtual Network between external router and OAM-VR.
- Virtual Network OAM – IntMgmt - direct addressing of the VM instances with Controller Profile using public IP addresses.
Figure 3 shows the realization of the logical network setup for operation and maintenance of a 2+2 node system.
2.4.3 Configuration Requirements for Virtual Network OAM-Ext
The following configuration requirements apply to this network:
- Externally accessible
Must be possible to access this network from, for example, the OSS. That is, the CSCF OAM MIP is published to the OSS through this network.
- IP address range
At least one IP address for each of the endpoints is required – external router and OAM-VR.
- Dynamic Host Configuration Protocol (DHCP) Service
DHCP is disabled on this network.
2.4.4 Configuration Requirements for Virtual Network OAM-IntMgmt
The following configuration requirements apply to this network:
- IP address range
IP address range to include at least three endpoints – OAM-VR and two VM instances with Controller Profile.
- DHCP Service
DHCP is disabled on this network.
2.4.5 Configuration Requirements for Virtual Routing Function OAM-VR
The following configuration requirement exists for this virtual routing function:
- Static Routing Rule
PBR rules must be defined that enable routing of IP packets from the CSCF VNF correctly. These PBR rules are CSCF VNF instance-specific and must adhere to the relevant network plan.
2.5 Logical Network Signaling
2.5.1 Purpose
The purpose of the Logical Network is to enable Session Initiation Protocol (SIP) communication between the CSCF and other Internet Protocol Multimedia Subsystem (IMS) network entities. This network also enables Diameter-based communication between the CSCF, PCRF, and Subscriber Location Function (SLF), or Home Subscriber Server (HSS).
The CSCF VNF exposes the following VIP interface on Logical Network Signaling:
- Interrogating Call Session Control Function (I-CSCF) SIP VIP interface
- Serving Call Session Control Function (S-CSCF) SIP VIP interface
- Emergency Call Session Control Function (E-CSCF) SIP VIP interface
- Break-in Control Function (BCF) SIP VIP interface
- Emergency Access Transfer Function (EATF) SIP VIP interface
- Serving Call Session Control Function (S-CSCF) Diameter SLF/HSS VIP interface
- E-CSCF HTTP VIP interface
2.5.2 Description
It is assumed that the external router is configured with a set of PBR rules. These rules send IP packets addressed to the VIP addresses enumerated in Section 2.5.1 Purpose to the Virtual Routing Function Signaling (Sig-VR).
SIG-VR is required to enable Layer 3 routing to and from the CSCF VNF. The VM instances of type Payload Profile use static routing such that the SIG-VR routes incoming IP packets towards the CSCF VIP interfaces, and that these IP packets are sent to the Payload Profile VM instances.
It is required to have a Virtual Routing Function to enable Layer 3 routing, it also implies that Logical Network Signaling is realized by two Virtual Networks:
- Virtual Network Sig-Ext – A virtual network between external router and SIG-VR.
- Virtual Network Sig-IntVIP – A virtual network between SIG-VR and CSCF VNF. CSCF Signaling VIP addresses on these VM instances are configured using static routing with or without BFD.
Figure 4 shows the realization of the logical network setup for signaling of a 2+2 node system.
2.5.3 Configuration Requirements for Virtual Network Sig-Ext
The following configuration requirements apply to this network:
- Externally Accessible
Must be possible to access this network from other IMS network entities such as HSS.
- IP address range
At least one IP address for each of the endpoints is required – external router and SIG-VR.
- DHCP Service
DHCP is disabled on this network.
2.5.4 Configuration Requirements for Virtual Network Sig-IntVIP
The following configuration requirements apply to this network:
- IP address range
At least one IP address for each of the endpoints is required – Virtual Routing Function Signaling ALB having Payload Profile installed.
- DHCP Service
DHCP is disabled on this network.
2.5.5 Configuration Requirements for Virtual Routing Function Sig-VR
The following configuration requirement exists for this Virtual Routing function:
- Static Routing without BFD
- Static Routing with BFD support
PBR rules must be defined that enables routing of IP packets from the CSCF VNF correctly. These PBR rules are CSCF VNF instance-specific and must adhere to relevant network plan.
2.6 Logical Network Charging
2.6.1 Purpose
The purpose of this network is to enable Diameter-based communication between the CSCF and Charging Collection Function.
The CSCF VNF exposes the following VIP interface on Logical Network Charging:
- S-CSCF Offline Charging VIP interface
- S-CSCF Online Charging VIP interface
- E-CSCF Offline Charging VIP interface
2.6.2 Description
It is assumed that the external router is configured with a set of PBR rules. These rules send IP packets targeted to the VIP addresses enumerated in Section 2.6.1 Purpose) to Virtual Routing Function Charging (CHA-VR).
CHA-VR is required to enable Layer 3 routing to and from the CSCF VNF. The CSCF VNF VM instances of type Payload Profile are configured using static routing to communicate with CHA-VR so that incoming IP packets are sent to the VM instances of type Payload Profile.
As it is required to have a Virtual Routing Function to enable Layer 3 routing, it also implies that Logical Network Charging is realized by two Virtual Networks:
- Virtual Network Cha-Ext – A Virtual Network between external router and CHA-VR
- Virtual Network Cha-IntVIP – A Virtual Network between CHA-VR and CSCF VNF. VM instances CSCF Signaling VIP addresses are configured using static routing/BFD.
Figure 5 shows the realization of the logical network setup for charging.
2.6.3 Configuration Requirements for Virtual Network Cha-Ext
The following configuration requirements apply to this network:
- Externally Accessible
Must be possible to access this network from Charging Collection Function and the opposite way.
- IP address range
At least one IP address for each of the endpoints is required – external router and CHA-VR.
- DHCP Service
DHCP is disabled on this network.
2.6.4 Configuration Requirements for Virtual Network Cha-IntVIP
The following configuration requirements apply to this network:
- IP address range
IP address range to include at least three endpoints – CHA-VR and at least two VM instances with Payload Profile.
- DHCP Service
DHCP is disabled on this network.
2.6.5 Configuration Requirements for Virtual Routing Function Cha-VR
The following configuration requirement exists for this Virtual Routing function:
- Static Routing without BFD
- Static Routing with BFD support
PBR rules must be defined that enables routing of IP packets from the CSCF VNF correctly. These PBR rules are CSCF VNF instance-specific and must adhere to the relevant network plan.
2.7 Logical Network Internal
2.7.1 Purpose
The purpose of this network is to enable communication between the VM instances that form CSCF VNF. Internal communication, among others, includes communication based on the protocols Transparent Inter-Process Communication (TIPC), Dynamic Host Configuration Protocol (DHCP), Bootstrap Protocol (BOOTP), Trivial File Transfer Protocol (TFTP), and Network File System (NFS).
2.7.2 Description
As the purpose of this Logical Network is to enable intra-CSCF VNF communication, Logical Network Internal does not have any external IP connectivity.
- Note:
- The Logical Network Internal is unique per CSCF VNF instance. That is, if it is required to deploy two CSCF VNF instances then it is required to create two Logical Network Internal instances.
The communication between VM instances is done by using Layer 2 routing. The result: no Virtual Routing function required and Logical Network Internal can be realized by one Virtual Network (Virtual Network Internal).
Figure 6 shows the realization of the Logical Network Internal setup.
2.7.3 Configuration Requirements for Virtual Network Internal
The following configuration requirements apply to this network:
- IP address range
IP address range to include all VM instances that forms CSCF VNF. IP range must be the same as in cluster.conf file.
- DHCP Service
DHCP is disabled on this network. VM instances receive their IP addresses from cluster.conf file.
2.8 Logical Network Setup in Multiple CSCF VNF Instance Deployment
It is possible to deploy the CSCF VNF multiple times in the same cloud infrastructure, resulting in multiple CSCF VNF instances. Having multiple CSCF VNF instances deployed in the same cloud infrastructure has some networking implications that must be noted.
It is required that Logical Network Internal and its underlying Virtual Network Internal are unique per CSCF VNF instance. If each CSCF VNF instance is not paired with a unique internal network instance, CSCF VNF instances will malfunction.
For the other Logical Networks, it is more on-site specific networking requirements from the operator and security requirements that apply. It is possible to create dedicated network instances (Virtual Networks and Virtual Routing Functions) per CSCF VNF instance. It is also possible to reuse Virtual Network instances – except for Virtual Network Internal. Another variant is to reuse Virtual Routing Functions and create CSCF VNF instance-specific Virtual Networks.
Create CSCF VNF instance-specific Virtual Networks and Virtual Routing Function. The reason for doing this is to separate the CSCF VNF instances, networking-wise, for security reasons. In this way, there is no logical IP connectivity between the CSCF VNF instances. However, depending on how CSCF VNF instances are deployed, it is possibly not a physical separation between the two instances.
Figure 7 shows CSCF VNF and its logical network setup in multiple CSCF VNF- instance deployment and when full separation is required.
Figure 7 CSCF VNF and Logical Network Setup for Multiple CSCF VNF Instance Deployment When Full Separation Is Required
Figure 8 shows logical network setup signaling combined with deployment of multiple CSCF VNF instances when full separation is required.
Figure 8 Logical Network Setup Signaling Combined with Deployment of Multiple CSCF VNF Instances When Full Separation Is Required
For the other Logical Networks Operation and Maintenance plus Charging, the same pattern as for Signaling applies.
The drawback of these recommendations is that CSCF VNF instances require more Virtual Networks instances. If it is not required to separate the CSCF VNF instances from each other, reuse the network entities between the CSCF VNF instances. However, it is required to have CSCF VNF instance unique Virtual Networks for internal communication. The other networking entities are reused between CSCF VNF entities.
Figure 9 shows CSCF VNF and its logical network setup for multiple CSCF VNF instance deployment and when full separation is not required.
Figure 9 CSCF VNF and Its Logical Network Setup in Case of Multiple CSCF VNF Instance Deployment and When Full Separation Is Not Required
Figure 10 shows logical network setup signaling combined with deployment of multiple CSCF VNF instances when full separation is not required.
Figure 10 Logical Network Setup Signaling Combined with Deployment of Multiple CSCF VNF Instances When Full Separation Is Not Required
For the other Logical Networks Operation and Maintenance plus Charging, the same pattern as for Signaling applies.
3 Example Configurations
This section describes example Cloud Networking Infrastructure configurations and deployments.
3.1 Static Routing with BFD Configuration
This section gives an example static routing with BFD configuration setup for CSCF VNF, that is when static routing with BFD is enabled in Virtual Routing Function. The actual values used for these parameters can vary depending on the deployment.
In this document, it is assumed that there are two VM instances per VIP address serving as VIP endpoints. Each of these VM instances internally has a VIP FE per VIP address and each VIP FE holds its own static routing with BFD configuration. If there are more than two VM instances per VIP address, the configuration must be adjusted accordingly.
3.1.1 Sig-IntVIP Static Routing with BFD Configuration
This section gives an example Static Routing with BFD configuration for Sig-IntVIP network.
|
Static Routing with BFD Parameter |
Value |
|---|---|
|
Local Address |
192.168.216.3/24 |
|
Remote Gateway |
192.168.216.1 |
|
bfd.RequiredMinEchoRXInterval |
0 |
|
bfd.DesiredMinTxInterval |
300 |
|
bfd.RequiredMinRxInterval |
300 |
|
bfd.DetectMult |
3 |
|
Static Routing with BFD Parameter |
Value |
|---|---|
|
Local Address |
192.168.216.4/24 |
|
Remote Gateway |
192.168.216.1 |
|
bfd.RequiredMinEchoRXInterval |
0 |
|
bfd.DesiredMinTxInterval |
300 |
|
bfd.RequiredMinRxInterval |
300 |
|
bfd.DetectMult |
3 |
3.1.2 Cha-IntVIP Static Routing with BFD Configuration
This section gives an example Static Routing with BFD configuration for Cha-IntVIP network.
|
Static Routing with BFD Parameter |
Value |
|---|---|
|
Local Address |
192.168.217.3/24 |
|
Remote Gateway |
192.168.217.1 |
|
bfd.RequiredMinEchoRXInterval |
0 |
|
bfd.DesiredMinTxInterval |
300 |
|
bfd.RequiredMinRxInterval |
300 |
|
bfd.DetectMult |
3 |
|
Static Routing with BFD Parameter |
Value |
|---|---|
|
Local Address |
192.168.217.4/24 |
|
Remote Gateway |
192.168.217.1 |
|
bfd.RequiredMinEchoRXInterval |
0 |
|
bfd.DesiredMinTxInterval |
300 |
|
bfd.RequiredMinRxInterval |
300 |
|
bfd.DetectMult |
3 |
3.2 Static Routing without BFD Configuration
This section gives an example static routing without BFD configuration setup for CSCF VNF, that is when static routing without BFD is enabled in Virtual Routing Function. The actual values used for these parameters can vary depending on the deployment.
In this document, it is assumed that there are two VM instances per VIP address serving as VIP endpoints. Each of these VM instances internally has a VIP FE per VIP address and each VIP FE holds its own static routing without BFD configuration. If there are more than two VM instances per VIP address, the configuration must be adjusted accordingly.
3.2.1 Sig-IntVIP Static Routing without BFD Configuration
This section gives an example Static Routing without BFD configuration for Sig-IntVIP network.
|
Static Routing without BFD Parameter |
Value |
|---|---|
|
Local Address |
192.168.216.3/24 |
|
Remote Gateway |
192.168.216.252 |
|
Static Routing without BFD Parameter |
Value |
|---|---|
|
Local Address |
192.168.216.4/24 |
|
Remote Gateway |
192.168.216.252 |
3.2.2 Cha-IntVIP Static Routing without BFD Configuration
This section gives an example Static Routing without BFD configuration for Cha-IntVIP network.
|
Static Routing without BFD Parameter |
Value |
|---|---|
|
Local Address |
192.168.217.3/24 |
|
Remote Gateway |
192.168.217.252 |
|
Static Routing without BFD Parameter |
Value |
|---|---|
|
Local Address |
192.168.217.4/24 |
|
Remote Gateway |
192.168.217.252 |
3.3 OpenStack Deployment
This section describes how to configure the different networks in OpenStack context. That is, when CSCF VNF is deployed in an OpenStack cloud, it can be deployed in the Ericsson Cloud System cloud or some other OpenStack based cloud.
- Note:
- In the following sections, it is assumed that only one CSCF VNF instance is deployed in the cloud. That is, the names/identifiers are not denoted with instance identifiers in this document. If multiple CSCF VNF instances are to be deployed into the same cloud, it is recommended to prefix all names/identifiers with the CSCF VNF instance name, for example, Karlstad-City-OAM-Ext.
3.3.1 Example Data Used
In the following sections, the provided example configuration data is based on the following CSCF VNF configuration.
|
CSCF VNF Parameter |
Value |
|---|---|
|
System Management net |
10.50.41.48/29 |
|
10.50.41.50 | |
|
System Management SC-1 |
10.50.41.51 |
|
System Management SC-2 |
10.50.41.52 |
|
10.50.41.202 | |
|
10.50.41.203 | |
|
10.50.41.204 | |
|
10.50.41.205 | |
|
10.50.41.206 | |
|
10.50.41.208 | |
|
OAM-VR IP (Ext) |
172.16.5.6 |
|
External router OAM GW |
172.16.5.5 |
|
192.168.216.3 | |
|
192.168.216.4 | |
|
Sig-VR IP (Int) |
192.168.216.1 |
|
Sig-VR IP (Ext) |
172.16.5.2 |
|
External router Sig GW |
172.16.5.1 |
|
192.168.217.3 | |
|
192.168.217.4 | |
|
Cha-VR IP (Int) |
192.168.246.1 |
|
Cha-VR IP (Ext) |
172.16.5.26 |
|
Site Router Cha GW |
172.16.5.25 |
|
Internal Net (cluster.conf) |
169.254.100.0/24 |
3.3.2 Configuration of Logical Network Operation and Maintenance
Figure 11 shows an overview of the OpenStack/Neutron building blocks that are used to build Logical Network O&M.
3.3.2.1 Configuration of Virtual Network OAM-Ext
The following configuration settings are recommended for OAM-Ext network in OpenStack context.
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
Name |
OAM-Ext |
|
prefix |
As required |
|
shared |
FALSE |
|
tenant_id |
As required |
|
provider:network_type |
Vlan |
|
provider:physical_network |
As required |
|
provider:segmentation_id |
As required |
|
router:external |
TRUE |
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
Name |
OAM-Ext-Sub |
|
Network |
OAM-Ext |
|
CIDR |
As required – for example 172.16.5.4/30 |
|
prefix |
As required |
|
tenant_id |
As required |
|
gateway |
As required – for example 172.16.5.5/32 |
|
allocation-pool |
As required – for example start=172.16.5.6 end=172.16.5.7 |
|
host-route |
Not used |
|
dns-nameserver |
Not used |
|
disable-dhcp |
Used (no parameter value) |
|
ip-version |
As required |
3.3.2.2 Configuration of Virtual Network OAM-IntMgmt
The following configuration settings are recommended for OAM-IntMgmt network in OpenStack context.
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
Name |
OAM-IntMgmt |
|
prefix |
As required |
|
shared |
FALSE |
|
tenant_id |
As required |
|
provider:network_type |
Not used |
|
provider:physical_network |
Not used |
|
provider:segmentation_id |
Not used |
|
router:external |
TRUE |
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
Name |
OAM-IntMgmt-Sub |
|
Network |
OAM-IntMgmt |
|
CIDR |
As required – for example 192.168.0.0/29 |
|
prefix |
As required |
|
tenant_id |
As required |
|
allocation-pool |
As required – for example start=192.168.0.1 end=192.168.0.3 |
|
host-route |
Not used |
|
dns-nameserver |
Not used |
|
disable-dhcp |
Used (no parameter value) |
|
ip-version |
As required |
3.3.2.3 Configuration of Virtual Router OAM-VR
The following configuration settings are recommended for OAM-IntMgmt network in OpenStack context.
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
Name |
OAM-VR |
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
router-id |
OAM-VR |
|
interface |
OAM-Ext |
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
router-id |
OAM-VR |
|
interface |
OAM-IntMgmt |
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
router-id |
OAM-VR |
|
external-network-id |
OAM-Ext |
3.3.3 Configuration of Logical Network Signaling
Figure 12 shows an overview of the OpenStack building blocks that are used to build Logical Network Signaling.
3.3.3.1 Configuration of Virtual Network Sig-Ext
The following configuration settings are recommended for Sig-Ext network in OpenStack context.
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
Name |
Sig-Ext |
|
prefix |
As required |
|
shared |
FALSE |
|
tenant_id |
As required |
|
provider:network_type |
Vlan |
|
provider:physical_network |
As required |
|
provider:segmentation_id |
As required |
|
router:external |
TRUE |
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
Name |
Sig-Ext-Sub |
|
Network |
Sig-Ext |
|
CIDR |
As required – for example 172.16.5.2/30 |
|
prefix |
As required |
|
tenant_id |
As required |
|
gateway |
As required – for example 172.16.5.1/32 |
|
allocation-pool |
As required – for example start=172.16.5.1 end=172.16.5.2 |
|
host-route |
Not used |
|
dns-nameserver |
Not used |
|
disable-dhcp |
Used (no parameter value) |
|
ip-version |
As required |
3.3.3.2 Configuration of Virtual Network Sig-IntVIP
The following configuration settings are recommended for Sig-IntVIP network in OpenStack context.
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
Name |
Sig-IntVIP |
|
prefix |
As required |
|
shared |
FALSE |
|
tenant_id |
As required |
|
provider:network_type |
Not used |
|
provider:physical_network |
Not used |
|
provider:segmentation_id |
Not used |
|
router:external |
TRUE |
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
Name |
Sig-IntVIP-Sub |
|
Network |
Sig-IntVIP |
|
CIDR |
As required – for example 192.168.216.0/29 |
|
prefix |
As required |
|
tenant_id |
As required |
|
allocation-pool |
As required – for example start=192.168.216.3 end=192.168.216.11 |
|
host-route |
Not used |
|
dns-nameserver |
Not used |
|
disable-dhcp |
Used (no parameter value) |
|
ip-version |
As required |
3.3.3.3 Configuration of Virtual Router Sig-VR
The following configuration settings are recommended for Sig-VR in OpenStack context.
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
Name |
Sig-VR |
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
router-id |
Sig-VR |
|
interface |
Sig-Ext |
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
router-id |
Sig-VR |
|
interface |
Sig-IntVIP |
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
router-id |
Sig-VR |
|
external-network-id |
Sig-Ext |
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
ID |
Sig-VR |
|
destination(1) |
10.50.41.201/32 |
|
nexthop |
192.168.216.3 |
|
destination |
10.50.41.201/32 |
|
nexthop |
192.168.216.11 |
|
Destination |
10.50.41.202/32 |
|
nexthop |
192.168.216.3 |
|
destination |
10.50.41.202/32 |
|
nexthop |
192.168.216.11 |
|
destination |
10.50.41.203/32 |
|
nexthop |
192.168.216.3 |
|
destination |
10.50.41.203/32 |
|
nexthop |
192.168.216.11 |
|
destination |
10.50.41.208/32 |
|
nexthop |
192.168.216.3 |
|
destination |
10.50.41.208/32 |
|
nexthop |
192.168.216.11 |
(1) Nexthop and destination
are configured in pairs.
3.3.4 Configuration of Logical Network Charging
Figure 13 shows an overview of the OpenStack building blocks that are used to build Logical Network Charging.
3.3.4.1 Configuration of Virtual Network Cha-Ext
The following configuration settings are recommended for Cha-Ext network in OpenStack context.
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
Name |
Cha-Ext |
|
prefix |
As required |
|
shared |
FALSE |
|
tenant_id |
As required |
|
provider:network_type |
Vlan |
|
provider:physical_network |
As required |
|
provider:segmentation_id |
As required |
|
router:external |
TRUE |
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
Name |
Cha-Ext-Sub |
|
Network |
Cha-Ext |
|
CIDR |
As required – for example 172.16.5.24/30 |
|
prefix |
As required |
|
tenant_id |
As required |
|
gateway |
As required – for example 172.16.5.25/32 |
|
allocation-pool |
As required – for example start=172.16.5.25 end=172.16.5.26 |
|
host-route |
Not used |
|
dns-nameserver |
Not used |
|
disable-dhcp |
Used (no parameter value) |
|
ip-version |
As required |
3.3.4.2 Configuration of Virtual Network Cha-IntVIP
The following configuration settings are recommended for Cha-IntVIP network in OpenStack context.
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
Name |
Cha-IntVIP |
|
prefix |
As required |
|
shared |
FALSE |
|
tenant_id |
As required |
|
provider:network_type |
Not used |
|
provider:physical_network |
Not used |
|
provider:segmentation_id |
Not used |
|
router:external |
TRUE |
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
Name |
Cha-IntVIP-Sub |
|
Network |
Cha-IntVIP |
|
CIDR |
As required – for example 192.168.246.0/29 |
|
prefix |
As required |
|
tenant_id |
As required |
|
allocation-pool |
As required – for example start=192.168.246.3 end=192.168.246.11 |
|
host-route |
Not used |
|
dns-nameserver |
Not used |
|
disable-dhcp |
Used (no parameter value) |
|
ip-version |
As required |
3.3.4.3 Configuration of Virtual Router Cha-VR
The following configuration settings are recommended for Sig-VR in OpenStack context.
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
Name |
Cha-VR |
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
router-id |
Cha-VR |
|
interface |
Cha-Ext |
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
router-id |
Cha-VR |
|
interface |
Cha-IntVIP |
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
router-id |
Cha-VR |
|
external-network-id |
Cha-Ext |
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
ID |
Sig-VR |
|
destination(1) |
10.50.41.205/32 |
|
nexthop |
192.168.246.3 |
|
destination |
10.50.41.205/32 |
|
nexthop |
192.168.246.11 |
|
Destination |
10.50.41.206/32 |
|
nexthop |
192.168.246.3 |
|
destination |
10.50.41.206/32 |
|
nexthop |
192.168.246.11 |
(1) Nexthop and destination
are configured in pairs.
3.3.5 Configuration of Logical Network Internal
Figure 14 shows an overview of the OpenStack building blocks that are used to build Logical Network Internal.
3.3.5.1 Configuration of Virtual Network Internal
The following configuration settings are recommended for Internal network in OpenStack context.
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
Name |
Internal |
|
prefix |
As required |
|
shared |
FALSE |
|
tenant_id |
As required |
|
provider:network_type |
Vlan |
|
provider:physical_network |
As required |
|
provider:segmentation_id |
As required |
|
router:external |
TRUE |
|
OpenStack Parameter |
Recommended Value |
|---|---|
|
Name |
Internal-Sub |
|
Network |
Internal |
|
CIDR |
As required – for example 169.254.100.0/24 |
|
prefix |
As required |
|
tenant_id |
As required |
|
gateway |
Not used |
|
allocation-pool |
As required – for example start=169.254.100.1 end=169.254.100.254 |
|
host-route |
Not used |
|
dns-nameserver |
Not used |
|
disable-dhcp |
Used (no parameter value) |
|
ip-version |
As required |
3.4 Equal-Cost Multipath Considerations
The CSCF VNF requires that flow-based ECMP is applied for TCP sessions, SCTP streams, and for fragmented UDP packets. This is needed as CSCF VNF requires that all IP packets from a TCP packet flow or SCTP packet flow or fragmented UDP packet flow are received on the same CSCF VNF instance (all packets within the flow are sent to the same CSCF VNF instance).
It is assumed in this document, that all networking routing entities support flow-based Equal-Cost Multipath for TCP, as this is a defacto standard for the TCP. The following subsections give some examples of the network configuration when it is not possible to use flow-based ECMP.
- Note:
- This is not required for UDP packets that are not fragmented.
3.4.1 Avoid Fragmented UDP Packets through Using TCP
In the CSCF VNF implementation, the eVIP FE implementation reassembles fragmented UDP packets before passing it on to CSCF application logic. As the eVIP FE runs on multiple VM instances, it is required that all UDP fragments are received by the same VM instance.
If it is not possible to achieve flow-based Equal-Cost Multipath for fragmented UDP packets, it is required to use TCP instead of UDP. This implies that any SIP communication to and from the CSCF VNF that can result in IP fragmentation, must use TCP. The DNS server and other network entities must be configured for TCP. It is also required to change CSCF configuration: set cscfSendRequestUdpOnly to false.
Do not use the DF (Do not Fragment) flag in the IP header to avoid fragmentation. The CSCF VNF is able to receive IP packets of the path MTU size (typically 1500 bytes) and then fragment the IP packets according to an internal MTU size of about 1452 bytes. If the received packet MTU size is larger than internal MTU size of 1452 bytes and the DF bit is set, the CSCF discards the IP packet.
Use TCP if the SIP message size is above 1300 bytes. This is also indicated in RFC3261.
3.4.2 Avoid Fragmented SCTP Packets through Using TCP
The problem for fragmented UDP packets as mentioned in section Section 3.4.1 Avoid Fragmented UDP Packets through Using TCP, also applies to SCTP for the same reason. If it is not possible to use flow-based ECMP for SCTP stream, it is required to use TCP instead of SCTP. This implies that communication between the CSCF VNF and SLF/HSS must use TCP.
3.4.3 Configure Network Routing in a Active/Standby Pattern
An alternative way to solve the fragmentation, is to define one of the CSCF Signaling VMs as primary destination for all IP packets. The other VM instance of the same type is then defined as secondary destination. If there are three instances of this type, define the third instance as tertiary destination. Primary, secondary, and optionally tertiary destinations are in this context defined as PBR in the external router.
The drawback of this type of solution is that, whenever a fault happens (for example an unexpected termination of the VM instance which is the primary destination), it results in the loss of all TCP connections (for example Diameter connections to SLF/HSS). Then the connections must be reestablished and this takes some time. That is why this setup is not the default configuration.