...

{
  "requestId": "3e828de1-c6b9-4782-b028-e2a98b0cce72",
	"commonData":
	[{
			"name": "requestType",
			"value": "VNF Config Update"
	 } 
	],
	"elements": [{
			"elementId": "nodeid1",
			"elementData": [{
					"name": "ticketManagementId",
					"value": "33333-333a-dsfa-dsfadsfadsfdsfdasfdaf"
				}, {
					"name": "id",
					"value": "33333333adsfadsfadsfadsfdsfdasfdaf"
				}
			]
		}
	],
   "policies": [
    {
      "policyName": "vertical",
      "policyDescription": "Vertical topology",
      "policyModifiers": []
    },
    {
      "policyName": "localMaintenanceWindow",
      "policyDescription": "Include only local maintenace window - default midnight to 6AM",
      "policyModifiers": []
    }
  ]
}

This represents a sample request to the Topology Service request. The request is designed to enable providing carrier specific data the the Topology Interface (commonData and elementData) In this example, we are modeling that the carrier is using different IDs (ticketManagementId and id) to identify the same element within the ticket management and topology systems, respectively.  It is up to the carrier's to define the contents of commonData and elementData  to support their individual needs. Since ONAP Dublin is providing sample implementations of both of these interfaces, the same Id will be used in both services and this will be equal to the elementId.

Topology Service Response Example

{
  "requestId": "3e828de1-c6b9-4782-b028-e2a98b0cce72",
  "status": "COMPLETED",
  "elements": [
    {
      "elementId": "nodeid1",
      "elementLocation": {
        "lat": 32.000,
        "lon": -71.000
      },
      "requiredElements": [
        "pserverid1"
      ],
      "constraintElements": [{
		"elementId": "nodeid1",
		"constraintType": "backupElement",
		"constraintTypeMinimum": 1,
		"optimizerAvailabilityMatrixName": "",
		"availabilityMatrixScope": "NONE",
		"elementAvailabilityAggreagation": true,
		"elements": [
			"nodeid1backup"
		  ]
		}
	  ],
	  "elementData":
	  [{
				"name": "ticketManagementId",
				"value": "33333-333a-dsfa-dsfadsfadsfdsfdasfdaf"
			}, {
				"name": "id",
				"value": "33333333adsfadsfadsfadsfdsfdasfdaf"
			}
	  ]
    }
  ],
	"referencedElements":
	[{
			"elementId": "pserverid1",
      "elementLocation": {
        "lat": 32.000,
        "lon": -71.000
      },			"referencingElements": ["nodeid1"],
			"elementData":
			[{
					"name": "ticketManagementId",
					"value": "33333-333a-dsfa"
				}, {
					"name": "id",
					"value": "33333333adsfa"
				}
			]
		}, {
			"elementId": "nodeid1backup",
      "elementLocation": {
			"lat": 44.000,
			"lon": -71.0000
       },
			"referencingElements": ["nodeid1"],
			"elementData":
			[{
					"name": "ticketManagementId",
					"value": "33333-333a-dsfadsfadsfdsbackup"
				}, {
					"name": "id",
					"value": "33333333adsfadsfadsfadsbackup"
				}
			]
		}
	]
}

This represents a response from the Topology Service Note the following attributes

• elementLocation.lat/lon - This is required for determining the time zone that the elements are serving - may be functionally replaced by timezone if available (TBD)
• requiredElements - these elements are required to be available in order to accomplish the requested change
• constraintElements - these represent elements that must be available to avoid a network outage during the requested change
• referencedElements - appearing on new elements returned by the topology server. The referencedElements id will appear in either requiredElements or constraintElements  for the elements to be changed.

These relationships will be important for determining element availability to provide to the Schedule Optimizer Engine.