Use case for a scalable and topology aware MPLS data plane monitoring system
draft-geib-spring-oam-usecase-05

Abstract

This document describes features and a use case of a path monitoring system. Segment based routing enables a scalable and simple method to monitor data plane liveliness of the complete set of paths belonging to a single domain. Compared with legacy MPLS ping and path trace, MPLS topology awareness reduces management and control plane involvement of OAM measurements while enabling new OAM features.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 2, 2016.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. An MPLS topology aware path monitoring system
• 3. SR based path monitoring use case illustration
• 3.1. Use-case 1 - LSP dataplane monitoring
• 3.2. Use-case 2 - Monitoring a remote bundle
• 3.3. Use-Case 3 - Fault localization
• 4. Failure Notification from PMS to LERi
• 5. Applying SR to monitor LDP paths
• 6. PMS monitoring of different Segment ID types
• 7. Connectivity Verification using PMS
• 8. Extensions of related standards helpful for this use case
• 9. IANA Considerations
• 10. Security Considerations
• 11. Acknowledgement
• 12. References
• 12.1. Normative References
• 12.2. Informative References
• Authors' Addresses

1. Introduction

It is essential for a network operator to monitor all the forwarding paths observed by the transported user packets. The monitoring flow is expected to be forwarded in dataplane in a similar way as user packets. Segment Routing enables forwarding of packets along pre-defined paths and segments and thus a Segment Routed monitoring packet can stay in dataplane while passing along one or more segments to be monitored.

This document describes illustrates use-cases based on data plane path monitoring capabilities. The use case is limited to a single IGP MPLS domain.

The use case applies to monitoring of LDP LSP's as well as to monitoring of Segment Routed LSP's. As compared to LDP, Segment Routing is expected to simplify the use case by enabling MPLS topology detection based on IGP signaled segments as specified by [ID.sr-isis]. Thus a centralised and MPLS topology aware monitoring unit can be realized in a Segment Routed domain. This topology awareness can be used for OAM purposes as described by this use case. The MPLS path monitoring system described by this document can be realised with pre-Segment based Routing (SR) technology. Making such a pre-SR MPLS monitoring system aware of a domains complete MPLS topology requires e.g. management plane access. To avoid the use of stale MPLS label information, IGP must be monitored and MPLS topology must be timely aligned with IGP topology. Obviously, enhancing IGPs to exchange of MPLS topology information as done by SR significantly simplifies and stabilises such an MPLS path monitoring system.

This document adopts the terminology and framework described in [ID.sr-archi]. It further adopts the editorial simplification explained in section 1.2 of the segment routing use-cases [ID.sr-use].

The use case offers several benefits for network monitoring. A single centralized monitoring device is able to monitor the complete set of a domains forwarding paths. Monitoring packets never leave data plane. MPLS path trace function (whose specification and features are not part of this use case) is required, if the actual data plane of a router should be checked against its control plane. SR capabilities allow to direct MPLS OAM packets from a centralized monitoring system to any router within a domain whose path should be traced.

In addition to monitoring paths, problem localization is required. Faults can be localized:

• by IGP LSA analysis.
• correlation between different SR based monitoring probes.
• by any MPLS traceroute method (possibly in combination with SR based path stacks).

Topology awareness is an essential part of link state IGPs. Adding MPLS topology awareness to an IGP speaking device hence enables a simple and scalable data plane based monitoring mechanism.

MPLS OAM offers flexible features to recognise an execute data paths of an MPLS domain. By utilising the ECMP related tool set offered e.g. by RFC 4379 [RFC4379], a segment based routing LSP monitoring system may:

• easily detect ECMP functionality and properties of paths at data level.
• construct monitoring packets executing desired paths also if ECMP is present.
• limit the MPLS label stack of an OAM packet to a minmum of 3 labels.

Alternatively, any path may be executed by building suitable label stacks. This allows path execution without ECMP awareness.

The MPLS path monitoring system may be a any server residing at a single interface of the domain to be monitored. It doesn't have to support any specialised protocol stack, it just should be capable of understanding the topology and building the probe packet with the right segment stack. As long as measurement packets return to this or another interface connecting such a server, the MPLS monitoring servers are the single entities pushing monitoring packet label stacks. If the depth of label stacks to be pushed by a path monitoring system (PMS) are of concern for a domain, a dedicated server based path monitoring architecture allows limiting monitoring related label stack pushes to these servers.

First drafts discussing SR OAM requirements and possible solutions to allow SR usage as described by this document have been submitted already, see [ID.sr-4379ext] and [ID.sr-oam_detect].

2. An MPLS topology aware path monitoring system

An MPLS PMS which is able to learn the IGP LSDB (including the SID's) is able to execute arbitrary chains of label switched paths. It can send pure monitoring packets along such a path chain or it can direct suitable MPLS OAM packets to any node along a path segment. Segment Routing here is used as a means of adding label stacks and hence transport to standard MPLS OAM packets, which then detect correspondence of control and data plane of this (or any other addressed) path. Any node connected to an SR domain is MPLS topology aware (the node knows all related IP addresses, SR SIDs and MPLS labels). Thus a PMS connected to an MPLS SR domain just needs to set up a topology data base for monitoring purposes.

Let us describe how the PMS constructs a labels stack to transport a packet to LER i, monitor the path of it to LER j and then receive the packet back.

The PMS may do so by sending packets carrying the following MPLS label stack infomation:

• Top Label: a path from PMS to LER i, which is expressed as Node SID of LER i.
• Next Label: the path that needs to be monitored from LER i to LER j. If this path is a single physical interface (or a bundle of connected interfaces), it can be expressed by the related AdjSID. If the shortest path from LER i to LER j is supposed to be monitored, the Node-SID (LER j) can be used. Another option is to insert a list of segments expressing the desired path (hop by hop as an extreme case). If LER i pushes a stack of Labels based on a SR policy decision and this stack of LSPs is to be monitored, the PMS needs an interface to collect the information enabling it to address this SR created path.
• Next Label or address: the path back to the PMS. Likely, no further segment/label is required here. Indeed, once the packet reaches LER j, the 'steering' part of the solution is done and the probe just needs to return to the PMS. This is best achieved by popping the MPLS stack and revealing a probe packet with PMS as destination address (note that in this case, the source and destination addresses could be the same). If an IP address is applied, no SID/label has to be assigned to the PMS (if it is a host/server residing in an IP subnet outside the MPLS domain).

Note: if the PMS is an IP host not connected to the MPLS domain, the PMS can send its probe with the list of SIDs/Labels onto a suitable tunnel providing an MPLS access to a router which is part of the monitored MPLS domain.

3. SR based path monitoring use case illustration

3.1. Use-case 1 - LSP dataplane monitoring

                +---+     +----+     +-----+
                |PMS|     |LSR1|-----|LER i| 
                +---+     +----+     +-----+
                   |      /      \    /
                   |     /        \__/ 
                 +-----+/           /|
                 |LER m|           / |
                 +-----+\         /  \
                         \       /    \
                          \+----+     +-----+
                           |LSR2|-----|LER j|
                           +----+     +-----+
           

            +---+    _   +--+                    +-------+
            |   |   { }  |  |---991---L1---662---|       |
            |PMS|--{   }-|R1|---992---L2---663---|R2 (72)|
            |   |   {_}  |  |---993---L3---664---|       |
            +---+        +--+                    +-------+