Requirement Description
The requirement is to
- discover the RAN and Core endpoints at NSMF
- auto-populate the Core and RAN endpoints in the TN Slice Profile Screen (UUI)
- discover the endpoints of CU, DU & RU nodes at NSMF
All these endpoints are required as an input to TN NSSMF to create the logical links that denotes back-haul, front-haul and mid-haul interfaces. Endpoint consists of IPAddress, logicInterfaceID and nexthopinfo.
Note:
a. Core, RAN endpoints for back haul are manually entered in UUI and other RAN nodes endpoints for FH and MH are predefined values in the previous releases.
b. RAN endpoint for back haul will be covered in this release
c. Core endpoint, FH and MH endpoints are stretch goal
| Gliffy Diagram | ||||||
|---|---|---|---|---|---|---|
|
General Information:
RAN and Core NF's IP addresses are assigned as below:
- If the NFs are deployed as VNFs, VNFM takes care of the IP address assignment
- If the NFs are deployed as CNFs, Kubernetes assigns a unique IP address to the pod. If it is a single container, docker daemon itself acts as a DHCP server and assigns an IP address to the container.
In both the above cases, assigning an IP address is taken care by the cloud provider itself.
In Core Slicing, netbox-ip-assign microservice is used by SDNC to assign IP address to the VF modules and VNFs. But this is not used effectively by CDS and the multicloud. Kubernetes itself assigns the IP address, moreover assigning a static IP is not a best practice in Kubernetes.
Back-haul endpoints Discovery:
This involves finding the EP (endpoint) details of RAN (CUCP) and Core (AMF) .
RAN Node (CUCP) EP details:
Sequence Diagram to find the CUCP IP address:IP Address & NexHopInfo
| draw.io Diagram | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
AN endpoint - logicInterfaceID:
AN endpoint - nexthopinfo:
Core Node EP details:
Sequence Diagram to find AMF NF IP address:
Core endpoint - logicInterfaceID:
Core endpoint - nexthopinfo:
Mid-haul endpoints Discovery:
Mid-haul is the connection between the CU and DU network functions.
CUCP & DU EP details:
|
IP Address:
More than one gateway IP ( where NFs are deployed) can be applicable and can be configured for a slice.
The returned IP addresses should be populated in a list box and all the IP addresses should be chosen as an input to TN NSSMF.
UUI should display a warning and should not allow to the next page, if all the IP addresses are not selected.
The details should be populated in UUI on loading the page.
AN endpoint - nexthopinfo:
NextHopInfo is stored in AAI and it is stored at the time of Simulator Registration with ESR. The nexthopinfo information will be retrieved from AAI and populated in UUI.
NextHopinfo is same for more than one network Functions. This value is going to be populated in text box as before.
The value should be populated in UUI on load of the page.
API Details
- UUI - Screen level changes (Stretch goal)
MOCK SCREENS FOR UUI ENHANCEMENTS:
| Jira | ||||||
|---|---|---|---|---|---|---|
|
AutoPopulate nodes for multiple selection in UUI as below,
If all the nodes are not selected it should show the below error message,
Multiple selection of nodes in TN selection page, the selected nodes should be displayed as below,
UUI and SO interaction
API details are documented in SO_impacts
2. SO ↔ CPS(WIP) (Existing APIs are used)
API Reference:
To Fetch coverage Area to coverage Area TA List Mapping:
To Fetch cells based on coverage area TA list:
To Fetch CUCP details wrt to the cell:
3. SO ↔ SDNC (Existing APIs are used)
API used to fetch Network topology:
https://localhost:8086/restconf/config/network-topology:network-topology
Response from SDNC:
Topology
|
4. SO ↔ AAI
API Used:
To Fetch PNF's:
https://<ip-address>:<port>/aai/v23/network/pnfs
Response from AAI:
| JSON Viewer | ||
|---|---|---|
| ||
{
"pnf": [{
"pnf-name": "networkId-providerId-10-clientId-0-topologyId-2-nodeId-10.1.1.3",
"pnf-id": "10.1.1.3",
"in-maint": true,
"spare-equipment-indicator": false,
"resource-version": "1642530553170",
"admin-status": "up",
"operational-status": "up",
"relationship-list": {
"relationship": [{
"related-to": "esr-thirdparty-sdnc",
"relationship-label": "org.onap.relationships.inventory.AppliesTo",
"related-link": "/aai/v23/external-system/esr-thirdparty-sdnc-list/esr-thirdparty-sdnc/7cfa0c7c-0181-4181-8f3b-1edf20a0f47b",
"relationship-data": [{
"relationship-key": "esr-thirdparty-sdnc.thirdparty-sdnc-id",
"relationship-value": "7cfa0c7c-0181-4181-8f3b-1edf20a0f47b"
}]
}, {
"related-to": "network-resource",
"relationship-label": "tosca.relationships.network.LinksTo",
"related-link": "/aai/v23/network/network-resources/network-resource/providerId-10-clientId-0-topologyId-2",
"relationship-data": [{
"relationship-key": "network-resource.network-id",
"relationship-value": "providerId-10-clientId-0-topologyId-2"
}],
"related-to-property": [{
"property-key": "network-resource.network-id",
"property-value": "providerId-10-clientId-0-topologyId-2"
}]
}]
}
}]
} |
To Fetch p-interface from AAI:
https://<ip-address>:<port>/aai/v23/network/pnfs/pnf/networkId-providerId-10-clientId-0-topologyId-2-nodeId-10.1.1.3/p-interfaces
Response from AAI:
| JSON Viewer | ||
|---|---|---|
| ||
{
"p-interface": [{
"interface-name": "networkId-providerId-10-clientId-0-topologyId-2-nodeId-10.1.1.3-ltpId-512",
"speed-value": "10000000",
"resource-version": "1642530553011",
"in-maint": true,
"operational-status": "up"
}, {
"interface-name": "networkId-providerId-10-clientId-0-topologyId-2-nodeId-10.1.1.3-ltpId-1000001",
"speed-value": "10000000",
"resource-version": "1642530553011",
"in-maint": true,
"operational-status": "up"
}]
} |
- The interface name of the fetched p-interface will be the nextHopInfo of the endpoints.
AN endpoint - logicInterfaceID:
As specified in TS 28 541, this field could be a VLAN ID (See IEEE 802.1Q [39]), MPLS Tag or Segment ID. This will be some predefined value in SO to denote the VLAN Id.IP Address: CUCP and DU IP address can be found in the similar way mentioned in the section RAN Node (CUCP) EP details