Download Monitoring and topology considerations

Monitoring and topology considerations
If the monitoring service has the fault detection capability with the per-domain granularity, then the
topology information that is needed to be able to detect the performance parameters of specific
service instance is the following:
-
Service type (point to point, multipoint,... can be obtained from the service inventory)
Service instance end points (can be obtained from the Service Inventory)
Border points between domains based on the traffic routing pattern (has to be extracted
from the network)
For the network in the example above for service S1 we have to know that:
-
It is a multipoint service
Endpoints are in D1, D4 and D7
Traffic goes via following routes:
o Directly between D1 and D4
o Between D4 and D7 via D6
o Between D1 and D7 via D2 and D3
For service S2 we have to know that:
-
It is a point to point service
Endpoints are in D6 and D3
Traffic goes between D3 and D6 via D7
Based on this information we can define the set of packet capturers which are relevant for these
particular service instances like in the following figure:
In order to be able to extract the proper information from the captured traffic additional information
that is needed is:

Type of service including technology information (L3VPN, VPLS, VPWS, BoD, OSCARS circuit,
SDN circuit, VLAN...) – can be obtained from the service inventory

IP address spaces of the end points of all service instances (Service instances can have
overlapping address spaces) – can be obtained from the service inventory

Special packet identifiers which are needed to properly recognize the particular service
instance (e.g. MPLS labels, VLANid, DSCP, other fields) – can be obtained from the service
inventory

Map of the domain border crossing into a particular physical device and the port which has to
be mirrored (packets captured from it) – can be obtained from the service inventory

Anything else?
However, the network is a live entity and topology can change. In case of the hypothetical failure of
the D3-D7 link, the topology and the set of border crossings and packet capturers relevant for
monitoring these services changes. The new one is shown here:
This means that monitoring solution has to be capable to automatically (and in real time) capture the
actual topology at any moment and to be capable to immediately react to topology changes.
Otherwise, changed topology can be seen as an increased packet loss on the affected service
instances.
Actual topology information can be obtained using the following methods:
-
Entering manually or transfer from a service inventory. Problem is that such data is static –
cannot react to topology changes and is thus not acceptable for dynamic services like MPLS
VPNs.
-
Extracting from the provisioning system which established the path. Applicable only to
those services which have provisioning systems (e.g. BoD and AutoBAHN). What happens if
the segment on a provisioned path is unavailable? Is povisioning system capable to react to
topology changes? However this method is not applicable to services like MDVPN which do
not have provisioning system and will not have one.
Extracting data from the network elements along the path (e.g. reading vrf routing tables,
label tables and so on). This metod highly depends on the type of technology that is used for
the service provisioning, probably also on the equipment vendor and network element
monitoring capabilities (e.g. dedicated SNMP MIBs). Do we have the full set of services we
will have to cover. When is CCS (Consolidated Connection Service – JRA2T1) going to be
defined?
Discovery using active probes (e.g. traceroute like). How to do that for point to point links –
probably not applicable?
Any other idea?
-
-