Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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? - -