draft-ietf-spring-oam-usecase-04.txt   draft-ietf-spring-oam-usecase-05.txt 
spring R. Geib, Ed. spring R. Geib, Ed.
Internet-Draft Deutsche Telekom Internet-Draft Deutsche Telekom
Intended status: Informational C. Filsfils Intended status: Informational C. Filsfils
Expires: April 23, 2017 C. Pignataro, Ed. Expires: August 11, 2017 C. Pignataro, Ed.
N. Kumar N. Kumar
Cisco Cisco Systems, Inc.
October 20, 2016 February 7, 2017
A Scalable and Topology-Aware MPLS Dataplane Monitoring System A Scalable and Topology-Aware MPLS Dataplane Monitoring System
draft-ietf-spring-oam-usecase-04 draft-ietf-spring-oam-usecase-05
Abstract Abstract
This document describes features of a path monitoring system and This document describes features of a path monitoring system and
related use cases. Segment based routing enables a scalable and related use cases. Segment based routing enables a scalable and
simple method to monitor data plane liveliness of the complete set of simple method to monitor data plane liveliness of the complete set of
paths belonging to a single domain. The MPLS monitoring system adds paths belonging to a single domain. The MPLS monitoring system adds
features to the traditional MPLS ping and LSP trace, in a very features to the traditional MPLS ping and LSP path trace, in a very
complementary way. MPLS topology awareness reduces management and complementary way. MPLS topology awareness reduces management and
control plane involvement of OAM measurements while enabling new OAM control plane involvement of OAM measurements while enabling new OAM
features. features.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 23, 2017. This Internet-Draft will expire on August 7, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. An MPLS Topology-Aware Path Monitoring System . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. SR-based Path Monitoring Use Case Illustration . . . . . . . 6 4. An MPLS Topology-Aware Path Monitoring System . . . . . . . . 6
4.1. Use Case 1 - LSP Dataplane Monitoring . . . . . . . . . . 6 5. SR-based Path Monitoring Use Case Illustration . . . . . . . 7
4.2. Use Case 2 - Monitoring a Remote Bundle . . . . . . . . . 8 5.1. Use Case 1 - LSP Dataplane Monitoring . . . . . . . . . . 7
4.3. Use Case 3 - Fault Localization . . . . . . . . . . . . . 9 5.2. Use Case 2 - Monitoring a Remote Bundle . . . . . . . . . 10
5. Failure Notification from PMS to LERi . . . . . . . . . . . . 9 5.3. Use Case 3 - Fault Localization . . . . . . . . . . . . . 11
6. Applying SR to Monitoring non-SR based LSPs (LDP and possibly 6. Failure Notification from PMS to LERi . . . . . . . . . . . . 11
RSVP-TE) . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Applying SR to Monitoring non-SR based LSPs (LDP and possibly
7. PMS Monitoring of Different Segment ID Types . . . . . . . . 10 RSVP-TE) . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Connectivity Verification Using PMS . . . . . . . . . . . . . 10 8. PMS Monitoring of Different Segment ID Types . . . . . . . . 13
9. Extensions of Specifications Relevant to this Use Case . . . 10 9. Connectivity Verification Using PMS . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. Extensions of Specifications Relevant to this Use Case . . . 13
11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 12. Security Considerations . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . 11 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . 11 14.1. Normative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 14.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Acronyms 1. Acronyms
ECMP Equal-Cost Multi-Path ECMP Equal-Cost Multi-Path
IGP Interionr Gateway Protocol
LER Label Edge Router IGP Interior Gateway Protocol
LSP Label Switched Path
LSR Label Switching Router LER Label Edge Router
OAM Operations, Administration, and Maintenance
PMS Path Monitoring System LSP Label Switched Path
SID Segment Identifier
SR Segment Routing LSR Label Switching Router
SRGB Segment Routing Global Block
OAM Operations, Administration, and Maintenance
PMS Path Monitoring System
RSVP-TE Resource ReserVation Protocol-Traffic Engineering
SID Segment Identifier
SR Segment Routing
SRGB Segment Routing Global Block
2. Introduction 2. Introduction
It is essential for a network operator to monitor all the forwarding It is essential for a network operator to monitor all the forwarding
paths observed by the transported user packets. The monitoring paths observed by the transported user packets. Monitoring packets
packet is expected to be forwarded in dataplane in a similar way as are expected to be forwarded in dataplane in a similar way as user
user packets. Segment Routing enables forwarding of packets along packets. Segment Routing enables forwarding of packets along pre-
pre-defined paths and segments and thus a Segment Routed monitoring defined paths and segments and thus a Segment Routed monitoring
packet can stay in dataplane while passing along one or more segments packet can stay in dataplane while passing along one or more segments
to be monitored. to be monitored.
This document describes a system using MPLS data plane path This document describes illustrates a system using MPLS data plane
monitoring capabilities. The use cases introduced here is limited to path monitoring capabilities. The use cases introduced here are
a single IGP MPLS domain. limited to a single Interior Gateway Protocol (IGP) MPLS domain.
The system applies to monitoring of LDP LSP's as well as to The system applies to monitoring of pre Segment Routing LSP's ( like
monitoring of Segment Routed LSP's. As compared to LDP, Segment LDP) as well as to monitoring of Segment Routed LSP's (section 7
Routing is expected to simplify the system by enabling MPLS topology offers some more information). As compared to pre Segment Routing
detection based on IGP signaled segments as specified at approaches, Segment Routing is expected to simplify such a monitoring
[I-D.ietf-isis-segment-routing-extensions] and system by enabling MPLS topology detection based on IGP signaled
[I-D.ietf-ospf-segment-routing-extensions]. Thus a centralised and segments as specified by specified by
[I-D.ietf-isis-segment-routing-extensions],
[I-D.ietf-ospf-segment-routing-extensions] and
[I-D.ietf-idr-bgp-ls-segment-routing-ext]. Thus a centralised and
MPLS topology aware monitoring unit can be realized in a Segment MPLS topology aware monitoring unit can be realized in a Segment
Routed domain. This topology awareness can be used for OAM purposes Routed domain. This topology awareness can be used for OAM purposes
as described by this document. as described by this document.
The MPLS path monitoring system described by this document can be The system offers several benefits for network monitoring:
realised with pre-Segment Routing (SR) based technology. Making such
a pre-SR MPLS monitoring system aware of a domain's 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 o A single centralized MPLS monitoring system which is able to
[I-D.ietf-spring-segment-routing]. perform a continuity check (ping) along all Label Switched Paths
of the SR domain. Monitoring packets never leave data plane.
The system offers several benefits for network monitoring. A single o The MPLS ping (or continuity check) packets never leave the MPLS
centralized monitoring device is able to monitor the complete set of data plane.
a domain's forwarding paths. Monitoring packets never leave data
plane. MPLS path trace function (whose specification and features o SR allows to transport MPLS path trace or connectivity validation
are not part of this use case) is required, if the actual data plane packets for any existing Label Switched Path to all nodes of an SR
of a router should be checked against its control plane. SR domain. This use case doesn't describe any new path trace
capabilities allow to direct MPLS OAM packets from a centralized features, but the system described here allows to set up an SR
monitoring system to any router within a domain whose path should be domain wide centralised connectivity validation.
traced.
o An MPLS monitoring system, maybe several ones if redundancy is
desired, which apply SR for OAM purposes as described, offer the
possibilty to scale and design a flexible MPLS OAM platform as
suitable for a provider.
In addition to monitoring paths, problem localization is required. In addition to monitoring paths, problem localization is required.
Faults can be localized: Faults can be localized:
o by IGP LSA analysis. o by capturing the Interior Gateway Protocol (IGP) topology and
analysing IGP messages indicating changes of it.
o correlation between different SR based monitoring probes. o by correlation between different SR based monitoring probes.
o by any MPLS traceroute method (possibly in combination with SR o by setting up an MPLS traceroute packet for a path (or Segment) to
based path stacks). be tested and transporting it to a node to validate path
connectivity from that node on.
Topology awareness is an essential part of link state IGPs. Adding Topology awareness is an essential part of link state IGPs. Adding
MPLS topology awareness to an IGP speaking device hence enables a MPLS topology awareness to an IGP speaking device hence enables a
simple and scalable data plane based monitoring mechanism. simple and scalable data plane based monitoring mechanism.
MPLS OAM offers flexible features to recognise and execute data paths MPLS OAM offers flexible traceroute (connectivity verification)
of an MPLS domain. By utilising the ECMP related tool set offered features to recognise and execute data paths of an MPLS domain. By
e.g. by RFC 4379 [RFC4379], a segment based routing LSP monitoring utilising the ECMP related tool set offered, e.g., by RFC 4379
system may: [RFC4379], a SR based MPLS monitoring system can be enabled to:
o easily detect ECMP functionality and properties of paths at data o detect how to route packets along different ECMP routed paths.
level.
o construct monitoring packets executing desired paths also if ECMP o construct ping packets respectively, which can be precisely
steered to paths whose connectivity is to be checked, also if ECMP
is present. is present.
o limit the MPLS label stack of an OAM packet to a minmum of 3 o limit the MPLS label stack of such a ping packet checking
labels. continuity of every single IGP-Segment to the maximum number of 3
labels. A smaller label stack may also be helpful, if any router
interprets a limited number of packet header bytes to determine an
ECMP path along which to route a packet.
Alternatively, any path may be executed by building suitable label Alternatively, any path may be executed by building suitable label
stacks. This allows path execution without ECMP awareness. stacks. This allows path execution without ECMP awareness.
The MPLS Path Monitoring System (PMS) may be any server residing at a The MPLS Path Monitoring System may be any server residing at a
single interface of the domain to be monitored. It doesn't have to single interface of the domain to be monitored. The PMS doesn't need
support any specialised protocol stack, it just should be capable of to support the complete MPLS routing or control plane. It needs to
understanding the topology and building the monitoring probe packet be capable to learn and maintain an accurate MPLS and IGP topology.
with the right segment stack. The monitoring probe packet could be MPLS ping and traceroute packets need to be set up and sent with the
BFD or LSP Ping packet or any other OAM format that PMS supports. As correct segment stack. The PMS further must be able to receive and
long as the monitoring packet returns back to the server, the path decode returning ping or traceroute packets. Packets used to check
can be considered as validated. The MPLS monitoring servers are the continuity could have BFD or LSP Ping format, or have any other OAM
single entities pushing monitoring packet label stacks. If the depth format supported by the PMS. As long as the packet used to check
of label stacks to be pushed by a path monitoring system (PMS) are of continuity returns back to the server while no IGP change is
concern for a domain, a dedicated server based path monitoring detected, the monitored path can be considered as validated. If the
architecture allows limiting monitoring related label stack pushes to depth of label stacks to be pushed for the purpose of path monitoring
these servers. is of concern for a domain, a dedicated PMS server allows to push
monitoring related label stacks of arbitrary depth on this server.
Hence router label stack limitations don't limit MPLS OAM choices.
Documents discussing SR OAM requirements and possible solutions to Documents discussing SR OAM requirements and MPLS traceroute
allow SR usage as described by this document have been submitted enhancements adding functionality to the use cases described by this
already, see [I-D.ietf-spring-sr-oam-requirement] and document are in work within IETF, see
[I-D.ietf-mpls-spring-lsp-ping]. [I-D.ietf-spring-sr-oam-requirement] and
[I-D.draft-ietf-mpls-spring-lsp-ping].
3. An MPLS Topology-Aware Path Monitoring System 3. Terminology
An MPLS PMS which is able to learn the IGP LSDB (including the SID's) Continuity Check
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 RFC 7276 [RFC7276] defines Continuity Checks to be used to verify
suitable MPLS OAM packets to any node along a path segment. Segment that a destination is reachable, and are typically sent
Routing here is used as a means of adding label stacks and hence proactively, though they can be invoked on-demand as well.
transport to standard MPLS OAM packets, which then detect Segment Routing allows to realise a continuity check along any
correspondence of control and data plane of this (or any other given SR domain path within data plane.
addressed) path. Any node connected to an SR domain is MPLS topology
aware (the node knows all related IP addresses, SR SIDs and MPLS Connectivity Verification
labels). Thus a PMS connected to an MPLS SR domain just needs to set
up a topology data base for monitoring purposes. RFC 7276 [RFC7276] defines Connectivity Verification as a
mechanism to check connectivity between two nodes by checking
whether a path between both can be used. RFC 4379 [RFC7276]
specifies a Connectivity Verification for MPLS domains. As RFC
7276 sates, Connectivity Verification and Continuity Checks are
considered complementary mechanisms and are often used in
conjunction with each other. The use cases following merely
treat SR based network monitoring as adding a new method to
realise a Continuity Check. In special cases, the SR based
Continuity Check offers limited Connectivity Verification
properties. This will be in the use case descriptions, if
applicable.
RFC 7276 [RFC7276] defines Connectivity Verification as a
mechanism to check connectivity between two nodes by checking
whether a path between both can be used. RFC 4379 [RFC7276]
specifies a Connectivity Verification for MPLS domains. As RFC
7276 sates, Connectivity Verification and Continuity Checks are
considered complementary mechanisms and are often used in
conjunction with each other. The use cases following merely
treat SR based network monitoring as adding a new method to
realise a Continuity Check. In special cases, the SR based
Continuity Check offers limited Connectivity Verification
properties. This will be in the use case descriptions, if
applicable.
MPLS topology
The MPLS topology of an MPLS domain is the complete set of MPLS-
and IP-address information and all routing and data plane
information required to address and utilise every MPLS path
within this domain from an MPLS Path Monitoring System attached
to this MPLS domain at an arbitrary access. This document
assumes availability of the MPLS topology (which can be detected
with available protocols and interfaces). None of the use cases
will describe how to set it up.
This document further adopts the terminology and framework described
in [I-D.ietf-spring-segment-routing].
4. An MPLS Topology-Aware Path Monitoring System
Any node at least listening to the IGP of an SR domain is MPLS
topology aware (the node knows all related IP addresses, SR SIDs and
MPLS labels). 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. To monitor an MPLS SR domain, a PMS needs to set up
a topology data base of MPLS SR domain to be monitored. It may be
used to send ping type packets to only check continuity along such a
path chain based on the topology information only. In addition, the
PMS can be used to trace MPLS Label Switched Path and thus verify
their connectivity and correspondance between control and data plane,
respectively. The PMS can direct suitable MPLS traceroute packets to
any node along a path segment.
Let us describe how the PMS constructs a labels stack to transport a Let us describe how the PMS constructs a labels stack to transport a
packet to LER i, monitor its path to LER j and then receive the packet to LER i, monitor its path to LER j and then receive the
packet back. packet back.
The PMS may do so by sending packets carrying the following MPLS The PMS may do so by sending packets carrying the following MPLS
label stack infomation: label stack information:
o Top Label: a path from PMS to LER i, which is expressed as Node o Top Label: a path from PMS to LER i, which is expressed as Node
SID of LER i. SID of LER i.
o Next Label: the path that needs to be monitored from LER i to LER o 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 j. If this path is a single physical interface (or a bundle of
connected interfaces), it can be expressed by the related AdjSID. connected interfaces), it can be expressed by the related
If the shortest path from LER i to LER j is supposed to be Adjacency-SID. If the shortest path from LER i to LER j is
monitored, the Node-SID (LER j) can be used. Another option is to supposed to be monitored, the Node-SID (LER j) can be used.
insert a list of segments expressing the desired path (hop by hop Another option is to insert a list of segments expressing the
as an extreme case). If LER i pushes a stack of Labels based on a desired path (hop by hop as an extreme case). If LER i pushes a
SR policy decision and this stack of LSPs is to be monitored, the stack of Labels based on a SR policy decision and this stack of
PMS needs an interface to collect the information enabling it to LSPs is to be monitored, the PMS needs an interface to collect the
address this SR created path. information enabling it to address this SR created path.
o Next Label or address: the path back to the PMS. Likely, no o Next Label or address: the path back to the PMS. Likely, no
further segment/label is required here. Indeed, once the packet further segment/label is required here. Indeed, once the packet
reaches LER j, the 'steering' part of the solution is done and the 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 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 popping the MPLS stack and revealing a probe packet with PMS as
destination address (note that in this case, the source and destination address (note that in this case, the source and
destination addresses could be the same). If an IP address is 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 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). host/server residing in an IP subnet outside the MPLS domain).
Note: a deployment might prefer not to connect the PMS to the MPLS The PMS should be physically connected to a router which is part of
domain. if the PMS is an IP host not connected to the MPLS domain, the SR domain. It must be able to send and receive MPLS packets via
the PMS can send its probe with the list of SIDs/Labels onto a this interface. As mentioned above, routing protocol support isn't
suitable tunnel providing an MPLS access to a router which is part of required and the PMS itself doesn't have to be involved in IGP or
the monitored MPLS domain. MPLS routing. A static route will do. Further options, like
deployment of a PMS connecting to the MPLS domain by a tunnel only
require more thought, as this implies security aspects. MPLS so far
separates networks securely by avoiding tunnel access to MPLS
domains.
4. SR-based Path Monitoring Use Case Illustration 5. SR-based Path Monitoring Use Case Illustration
4.1. Use Case 1 - LSP Dataplane Monitoring 5.1. Use Case 1 - LSP Dataplane Monitoring
+---+ +----+ +-----+ +---+ +----+ +-----+
|PMS| |LSR1|-----|LER i| |PMS| |LSR1|-----|LER i|
+---+ +----+ +-----+ +---+ +----+ +-----+
| / \ / | / \ /
| / \__/ | / \__/
+-----+/ /| +-----+/ /|
|LER m| / | |LER m| / |
+-----+\ / \ +-----+\ / \
\ / \ \ / \
skipping to change at page 6, line 32 skipping to change at page 8, line 11
Example of a PMS based LSP dataplane monitoring Example of a PMS based LSP dataplane monitoring
Figure 1 Figure 1
For the sake of simplicity, let's assume that all the nodes are For the sake of simplicity, let's assume that all the nodes are
configured with the same SRGB [I-D.ietf-spring-segment-routing]. configured with the same SRGB [I-D.ietf-spring-segment-routing].
Let's assign the following Node SIDs to the nodes of the figure: PMS Let's assign the following Node SIDs to the nodes of the figure: PMS
= 10, LER i = 20, LER j = 30. = 10, LER i = 20, LER j = 30.
To be able to work with the smallest possible SR label stack, first a The aim is to set up a continuity check of the path between LER i and
suitable MPLS OAM method is used to detect the ECMP routed path LER j. As has been said, the monitoring packets are to be sent and
between LER i to LER j which is to be monitored (and the required received by the PMS. Let's assume the design aim is to be able to
address information to direct a packet along it). Afterwards the PMS work with the smallest possible SR label stack. In the given
sets up and sends packets to monitor availability of the detected topology, a fairly simple option is to perform an MPLS path trace, as
path. The PMS does this by creating a measurement packet with the specified by RFC4379. The starting point for the path trace is LER i
following label stack (top to bottom): 20 - 30 - 10. The packet will and the PMS sends the MPLS path trace packet to LER i. The MPLS echo
only reliably use the monitored path, if the label and address reply of LER i should be sent to the PMS. As a result, IP
information used in combination with the MPLS OAM method of choice is destination address choices are detected, which are then used to
identical to that of the monitoring packet. target any one of the ECMP routed paths between LER i and LER j by
the MPLS ping packets to later check path continuity. The Label
stack of these ping packets doesn't need to consist of more than 3
labels. Finally, the PMS sets up and sends packets to monitor
connectivity of the ECMP routed paths. The PMS does this by creating
a measurement packet with the following label stack (top to bottom):
20 - 30 - 10. The ping packets reliably use the monitored path, if
the IP-address information which has been detected by the MPLS trace
route is used as the IP destination address (note that this IP
address isn't used or required for any IP routing).
LER m forwards the packet received from the PMS to LSR1. Assuming LER m forwards the packet received from the PMS to LSR1. Assuming
Pen-ultimate Hop Popping to be deployed, LSR1 pops the top label and Pen-ultimate Hop Popping to be deployed, LSR1 pops the top label and
forwards the packet to LER i. There the top label has a value 30 and forwards the packet to LER i. There the top label has a value 30 and
LER i forwards it to LER j. This will be done transmitting the LER i forwards it to LER j. This will be done transmitting the
packet via LSR1 or LSR2. The LSR will again pop the top label. LER packet via LSR1 or LSR2. The LSR will again pop the top label. LER
j will forward the packet now carrying the top label 10 to the PMS j will forward the packet now carrying the top label 10 to the PMS
(and it will pass a LSR and LER m). (and it will pass a LSR and LER m).
A few observations on the example given in figure 1: A few observations on the example given in figure 1:
o The path PMS to LER i must be available. This path must be o The path PMS to LER i must be available (i.e., a continuity check
detectable, but it is usually sufficient to apply a Shortest Path only along the path to LER i must succeed). If desired, an MPLS
First algorithm based path. trace route may be used to exactly detect the data plane path
taken for this MPLS Segment. It is usually sufficient to just
apply any of the existing Shortest Path routed paths.
o If ECMP is deployed, it may be desired to measure along both o If ECMP is deployed, separate continuity checks monitoring all
possible paths which a packet may use between LER i and LER j. To possible paths which a packet may use between LER i and LER j may
do so, the MPLS OAM mechanism chosen to detect ECMP must reveal be desired. This can be done by applying an MPLS trace route
the required information (an example is a so called tree trace) between LER i and LER j. Another option is to use SR routing, but
between LER i and LER j. This method of dealing with ECMP based this will likely require additional label information within the
load balancing paths requires the smallest SR label stacks if label stack of the ping packet. Further, if multiple links are
monitoring of paths is applied after the tree trace completion. deplyed between two nodes, SR methods to address each individual
path require an Adj-SID to be assigned to each single interface.
This method is based on control plane information - a connectivity
verification based on MPLS traceroute seems to be a fairly good
option to deal with ECMP and validation of control and data plane
correlation.
o The path LER j to PMS must be available. This path must be o The path LER j to PMS must be available (i.e., a continuity check
detectable, but it is usually sufficient to apply an SPF based only along the path from LER j to PMS must succeed). If desired,
path. an MPLS trace route may be used to exactly detect the data plane
path taken for this MPLS Segment. It is usually sufficient to
just apply any of the existing Shortest Path routed paths.
Once the MPLS paths (Node SIDs) and the required information to deal Once the MPLS paths (Node-SIDs) and the required information to deal
with ECMP has been detected, the paths of LER i to LER j can be with ECMP have been detected, the path continuity between LER i and
monitored by the PMS. Monitoring itself does not require MPLS OAM LER j can be monitored by the PMS. Path continuity monitoring by
functionality. All monitoring packets stay on dataplane, hence path ping packets does not require RFC4379 MPLS OAM functionality. All
monitoring does no longer require control plane interaction in any monitoring packets stay on dataplane, hence path continuity
LER or LSR of the domain. To ensure reliable results, the PMS should monitoring does not require control plane interaction in any LER or
be aware of any changes in IGP or MPLS topology. Further changes in LSR of the domain. To ensure consistent interpretation of the
ECMP functionality at LER i will impact results. Either the PMS results, the PMS should be aware of any changes in IGP or MPLS
should be notified of such changes or they should be limited to topology or ECMP routing. While the description given here
planned maintenance. After a topology change, a suitable MPLS OAM pronouncing path connectivity checking as a simple basic application,
mechanism may be useful to detect the impact of the change. others like checking continuity of underlying physical infrastructure
or delay measurements may be desired. In both cases, a change in
ECMP routing which is not caused by an IGP or MPLS topology change
may not be desirable. A PMS therefore should also periodically
verify connectivity of the SR paths which are monitored for
continuity.
Determining a path to be executed prior to a measurement may also be Determining a path to be executed prior to a measurement may also be
done by setting up a label stack including all Node SIDs along that done by setting up a label stack including all Node-SIDs along that
path (if LSR1 has Node SID 40 in the example and it should be passed path (if LSR1 has Node SID 40 in the example and it should be passed
between LER i and LER j, the label stack is 20 - 40 - 30 - 10). The between LER i and LER j, the label stack is 20 - 40 - 30 - 10). The
advantage of this method is, that it does not involve MPLS OAM advantage of this method is, that it does not involve RFC 4379
functionality and it is independent of ECMP functionalities. The connectivity verification and, if there's only one physical
method still is able to monitor all link combinations of all paths of connection between all nodes, the approach is independent of ECMP
an MPLS domain. If correct forwarding along the desired paths has to functionalities. The method still is able to monitor all link
be checked, some suitable MPLS OAM mechanism may be applied also in combinations of all paths of an MPLS domain. If correct forwarding
this case. along the desired paths has to be checked, or multiple physical
connections exist between any two nodes, either additional
information based on an MPLS trace route or additional Adj-SIDs are
required to deal with ECMP.
In theory at least, a single PMS is able to monitor data plane In theory at least, a single PMS is able to monitor data plane
availability of all LSPs in the domain. The PMS may be a router, but availability of all LSPs in the domain. The PMS may be a router, but
could also be dedicated monitoring system. If measurement system could also be dedicated monitoring system. If measurement system
reliability is an issue, more than a single PMS may be connected to reliability is an issue, more than a single PMS may be connected to
the MPLS domain. the MPLS domain.
Monitoring an MPLS domain by a PMS based on SR offers the option of Monitoring an MPLS domain by a PMS based on SR offers the option of
monitoring complete MPLS domains with little effort and very monitoring complete MPLS domains with limited effort and a unique
excellent scalability. Data plane failure detection by circulating possibility to scale a flexible monitoring solution as required by
monitoring packets can be executed at any time. The PMS further the operator (the number of PMS deployed is independent of the
could be enabled to send MPLS OAM packets with the label stacks and locations of the origin and destination of the monitored paths). The
PMS can be enabled to send MPLS OAM packets with the label stacks and
address information identical to those of the monitoring packets to address information identical to those of the monitoring packets to
any node of the MPLS domain. Prior to monitoring a path, MPLS OAM any node of the MPLS domain. The routers of the monitored domain
may be used to detect ECMP dependant forwarding of a packet. A PMS should support RFC 4379 and its standardised extensions to allow for
may be designed to learn the IP address information required to MPLS trace route. Ping based continuity checks don't require router
execute a particular ECMP routed path and interfaces along that path. control plane activity. Prior to monitoring a path, MPLS OAM may be
This allows to monitor these paths with label stacks reduced to a used to detect ECMP dependant forwarding of a packet. A PMS may be
limited number of Node-SIDs resulting from SPF routing. The PMS does designed to learn the IP address information required to execute a
not require access to LSR/LER management interfaces or their control particular ECMP routed path and interfaces along that path. This
plane to do so. allows to monitor these paths with label stacks reduced to a limited
number of Node-SIDs resulting from SPF routing. The PMS does not
require access to LSR / LER management- or data-plane information to
do so.
4.2. Use Case 2 - Monitoring a Remote Bundle 5.2. Use Case 2 - Monitoring a Remote Bundle
+---+ _ +--+ +-------+ +---+ _ +--+ +-------+
| | { } | |---991---L1---662---| | | | { } | |---991---L1---662---| |
|PMS|--{ }-|R1|---992---L2---663---|R2 (72)| |PMS|--{ }-|R1|---992---L2---663---|R2 (72)|
| | {_} | |---993---L3---664---| | | | {_} | |---993---L3---664---| |
+---+ +--+ +-------+ +---+ +--+ +-------+
SR based probing of all the links of a remote bundle SR based probing of all the links of a remote bundle
Figure 2 Figure 2
skipping to change at page 9, line 5 skipping to change at page 11, line 14
PMS sends the probe to its connected router. If the connected router PMS sends the probe to its connected router. If the connected router
is not SR compliant, a tunneling technique can be used to tunnel the is not SR compliant, a tunneling technique can be used to tunnel the
probe and its MPLS stack to the first SR router. The MPLS/SR domain probe and its MPLS stack to the first SR router. The MPLS/SR domain
then forwards the probe to R2 (72 is the Node SID of R2). R2 then forwards the probe to R2 (72 is the Node SID of R2). R2
forwards the probe to R1 over link L1 (Adjacency SID 662). R1 forwards the probe to R1 over link L1 (Adjacency SID 662). R1
forwards the probe to R2 over link L2 (Adjacency SID 992). R2 forwards the probe to R2 over link L2 (Adjacency SID 992). R2
forwards the probe to R1 over link L3 (Adjacency SID 664). R1 then forwards the probe to R1 over link L3 (Adjacency SID 664). R1 then
forwards the IP probe to PMS as per classic IP forwarding. forwards the IP probe to PMS as per classic IP forwarding.
4.3. Use Case 3 - Fault Localization As has been mentioned in section 5.1, the PMS must be able monitor
continuity of the path PMS to R2 (Node-SID 72) as well as continuity
from R1 to the PMS. If both are given and packets are lost,
forwarding on one of the three interfaces connecting R1 to R2 must be
disturbed.
5.3. Use Case 3 - Fault Localization
In the previous example, a uni-directional fault on the middle link In the previous example, a uni-directional fault on the middle link
in direction of R2 to R1 would be localized by sending the following in direction of R2 to R1 would be localized by sending the following
two probes with respective segment lists: two probes with respective segment lists:
o 72, 662, 992, 664 o 72, 662, 992, 664
o 72, 663, 992, 664 o 72, 663, 992, 664
The first probe would fail while the second would succeed. The first probe would succeed while the second would fail.
Correlation of the measurements reveals that the only difference is Correlation of the measurements reveals that the only difference is
using the Adjacency SID 662 of the middle link from R1 to R2 in the using the Adjacency SID 663 of the middle link from R2 to R1 in the
non successful measurement. Assuming the second probe has been non successful measurement. Assuming the second probe has been
routed correctly, the fault must have been occurring in R2 which routed correctly, the fault must have been occurring in R2 which
didn't forward the packet to the interface identified by its didn't forward the packet to the interface identified by its
Adjacency SID 662. Adjacency SID 663.
5. Failure Notification from PMS to LERi The example above only illustrates a method to localise a fault by
correlated continuity checks. Any operational deployment requires a
well designed engineering to allow for the desired non ambiguous
diagnosis on the monitored section of the SR network. 'Section' here
could be a path, a single physical interface, the set of all links of
a bundle or an adjacency of two nodes, just to name a few. Such a
design is not within scope of this document.
6. Failure Notification from PMS to LERi
PMS on detecting any failure in the path liveliness may use any out- PMS on detecting any failure in the path liveliness may use any out-
of-band mechanism to signal the failure to LER i. This document does of-band mechanism to signal the failure to LER i. This document does
not propose any specific mechanism and operators can choose any not propose any specific mechanism and operators can choose any
existing or new approach. existing or new approach.
Alternately, the Operator may log the failure in local monitoring Alternately, the Operator may log the failure in local monitoring
system and take necessary action by manual intervention. system and take necessary action by manual intervention.
6. Applying SR to Monitoring non-SR based LSPs (LDP and possibly RSVP- 7. Applying SR to Monitoring non-SR based LSPs (LDP and possibly RSVP-
TE) TE)
The MPLS path monitoring system described by this document can be
realised with pre-Segment Routing (SR) based technology. Making such
a pre-SR MPLS monitoring system aware of a domain's complete MPLS
topology requires, e.g., management plane access to the routers of
the domain to be monitored or set up of a dedicated T-LDP tunnel per
router to set up an LDP adjacency. To avoid the use of stale MPLS
label information, the 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.
A SR based PMS connected to a MPLS domain consisting of LER and LSR A SR based PMS connected to a MPLS domain consisting of LER and LSR
supporting SR and LDP or RSVP-TE in parallel in all nodes may use SR supporting SR and LDP or RSVP-TE in parallel in all nodes may use SR
paths to transmit packets to and from start and end points of non-SR paths to transmit packets to and from start and end points of non-SR
based LSP paths to be monitored. In the above example, the label based LSP paths to be monitored. In the above example, the label
stack top to bottom may be as follows, when sent by the PMS: stack top to bottom may be as follows, when sent by the PMS:
o Top: SR based Node-SID of LER i at LER m. o Top: SR based Node-SID of LER i at LER m.
o Next: LDP or RSVP-TE label identifying the path to LER j at LER i. o Next: LDP or RSVP-TE label identifying the path or tunnel,
respectively from LER i to LER j (at LER i).
o Bottom: SR based Node-SID identifying the path to the PMS at LER j o Bottom: SR based Node-SID identifying the path to the PMS at LER j
While the mixed operation shown here still requires the PMS to be While the mixed operation shown here still requires the PMS to be
aware of the LER LDP-MPLS or RSVP-TE topology, the PMS may learn the aware of the LER LDP-MPLS topology, the PMS may learn the SR MPLS
SR MPLS topology by IGP and use this information. topology by IGP and use this information.
An implementation report on a PMS operating in an LDP domain is given An implementation report on a PMS operating in an LDP domain is given
in [I-D.leipnitz-spring-pms-implementation-report]. in [I-D.leipnitz-spring-pms-implementation-report]. In addition,
this report compares delays measured with a single PMS to the results
measured by three IP Performance Measurement Work Group (IPPM WG)
standard conformant Measurement Agents (connected to an MPLS domain
at three different sites). The delay measurements of PMS and where
compared based on a statistical test published by the IPPM WG
[RFC6576]. The Anderson Darling k-sample test showed that the PMS
round-trip delay measurements are equal to those captured by an IPPM
conformant IP measurement system for 64 Byte measurement packets with
95% confidence.
7. PMS Monitoring of Different Segment ID Types The authors are not aware of similar deployment for RSVP-TE.
Identification of tunnel entry- and transit-nodes may add complexity.
They are not within scope of this document.
8. PMS Monitoring of Different Segment ID Types
MPLS SR topology awareness should allow the SID to monitor liveliness MPLS SR topology awareness should allow the SID to monitor liveliness
of most types of SIDs (this may not be recommendable if a SID of SIDs related to interfaces within the SR and IGP domain,
identifies an inter domain interface). respectively. Tracing a path where an SR capable node assigns an
Adj-SID for a non-SR-capable node may fail. This and other backward
compatibility with non Segment Routing devices are discussed by
[I-D.draft-ietf-mpls-spring-lsp-ping].
To match control plane information with data plane information, MPLS To match control plane information with data plane information, MPLS
OAM functions as defined for example by RFC 4379 [RFC4379] should be OAM functions as defined for example by RFC4379 [RFC4379] are
enhanced to allow collection of data relevant to check all relevant enhanced to allow collection of data relevant to check all relevant
types of Segment IDs. types of Segment IDs by [I-D.draft-ietf-mpls-spring-lsp-ping].
8. Connectivity Verification Using PMS 9. Connectivity Verification Using PMS
While the PMS based use cases explained in Section 3 are sufficient While the PMS based use cases explained in Section 5 are sufficient
to provide continuity check between LER i and LER j, it may not help to provide continuity check between LER i and LER j, it may not help
perform connectivity verification. So in some cases like data plane perform connectivity verification. So in some cases like data plane
programming corruption, it is possible that a transit node between programming corruption, it is possible that a transit node between
LER i and LER j erroneously removes the top segment ID and forwards a LER i and LER j erroneously removes the top segment ID and forwards a
monitoring packet to the PMS based on the bottom segment ID leading monitoring packet to the PMS based on the bottom segment ID leading
to a falsified path liveliness indication by the PMS. to a falsified path liveliness indication by the PMS.
There are various method to perform basic connectivity verification There are various method to perform basic connectivity verification
like intermittently setting the TTL to 1 in bottom label so LER j like intermittently setting the TTL to 1 in bottom label so LER j
selectively perform connectivity verification. Other methods are selectively perform connectivity verification. Other methods are
possible and may be added when requirements and solutions are possible and may be added when requirements and solutions are
specified. specified.
9. Extensions of Specifications Relevant to this Use Case 10. Extensions of Specifications Relevant to this Use Case
The following activities are welcome enhancements supporting this use The following activities are welcome enhancements supporting this use
case, but they are not part of it: case, but they are not part of it:
RFC 4379 [RFC4379] functions should be extended to support Flow- and RFC4379 [RFC4379] functions should be extended to support Flow- and
Entropy Label based ECMP. Entropy Label based ECMP.
10. IANA Considerations 11. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
11. Security Considerations 12. Security Considerations
As mentioned in the introduction, a PMS monitoring packet should As mentioned in the introduction, a PMS monitoring packet should
never leave the domain where it originated. It therefore should never leave the domain where it originated. It therefore should
never use stale MPLS or IGP routing information. Further, assigning never use stale MPLS or IGP routing information. Further, assigning
different label ranges for different purposes may be useful. A well different label ranges for different purposes may be useful. A well
known global service level range may be excluded for utilisation known global service level range may be excluded for utilisation
within PMS measurement packets. These ideas shouldn't start a within PMS measurement packets. These ideas shouldn't start a
discussion. They rather should point out, that such a discussion is discussion. They rather should point out, that such a discussion is
required when SR based OAM mechanisms like a SR are standardised. required when SR based OAM mechanisms like a SR are standardised.
12. Acknowledgements Should the approach of a PMS connected to an SR domain by a tunnel be
picked up, some fundamental MPLS security properties need to be
discussed. MPLS domains so far allow to separate the MPLS network
from an IP network by allowing no tunneled MPLS access to an MPLS
domain.
13. Acknowledgements
The authors would like to thank Nobo Akiya for his contribution. The authors would like to thank Nobo Akiya for his contribution.
Raik Leipnitz kindly provided an editorial review. The authors would Raik Leipnitz kindly provided an editorial review. The authors would
also like to thank Faisal Iqbal for an insightful review and a useful also like to thank Faisal Iqbal for an insightful review and a useful
set of comments and suggestions. set of comments and suggestions.
13. References 14. References
13.1. Normative References 14.1. Normative References
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379, Label Switched (MPLS) Data Plane Failures", RFC 4379,
DOI 10.17487/RFC4379, February 2006, DOI 10.17487/RFC4379, February 2006,
<http://www.rfc-editor.org/info/rfc4379>. <http://www.rfc-editor.org/info/rfc4379>.
13.2. Informative References [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
Weingarten, "An Overview of Operations, Administration,
and Maintenance (OAM) Tools", RFC 7276,
DOI 10.17487/RFC7276, June 2014,
<http://www.rfc-editor.org/info/rfc7276>.
[I-D.ietf-isis-segment-routing-extensions] 14.2. Informative References
Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
Litkowski, S., Decraene, B., and j. jefftant@gmail.com,
"IS-IS Extensions for Segment Routing", draft-ietf-isis-
segment-routing-extensions-08 (work in progress), October
2016.
[I-D.ietf-mpls-spring-lsp-ping] [I-D.draft-ietf-mpls-spring-lsp-ping]
Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini, IETF, "Label Switched Path (LSP) Ping/Trace for Segment
S., Gredler, H., and M. Chen, "Label Switched Path (LSP) Routing Networks Using MPLS Dataplane", IETF,
Ping/Trace for Segment Routing Networks Using MPLS https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-
Dataplane", draft-ietf-mpls-spring-lsp-ping-00 (work in lsp-ping/, 2016.
progress), May 2016.
[I-D.ietf-idr-bgp-ls-segment-routing-ext]
IETF, "BGP Link-State extensions for Segment Routing",
IETF, https://datatracker.ietf.org/doc/draft-ietf-idr-
bgp-ls-segment-routing-ext/, 2016.
[I-D.ietf-isis-segment-routing-extensions]
IETF, "IS-IS Extensions for Segment Routing", IETF,
https://datatracker.ietf.org/doc/draft-ietf-isis-segment-
routing-extensions/, 2016.
[I-D.ietf-ospf-segment-routing-extensions] [I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., IETF, "OSPF Extensions for Segment Routing", IETF,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-
Extensions for Segment Routing", draft-ietf-ospf-segment- routing-extensions/, 2016.
routing-extensions-09 (work in progress), July 2016.
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., IETF, "Segment Routing Architecture", IETF,
and R. Shakir, "Segment Routing Architecture", draft-ietf- https://datatracker.ietf.org/doc/draft-ietf-spring-
spring-segment-routing-09 (work in progress), July 2016. segment-routing/, 2016.
[I-D.ietf-spring-sr-oam-requirement] [I-D.ietf-spring-sr-oam-requirement]
Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., IETF, "OAM Requirements for Segment Routing Network",
and S. Litkowski, "OAM Requirements for Segment Routing IETF, https://datatracker.ietf.org/doc/draft-ietf-spring-
Network", draft-ietf-spring-sr-oam-requirement-02 (work in sr-oam-requirement/, 2016.
progress), July 2016.
[I-D.leipnitz-spring-pms-implementation-report] [I-D.leipnitz-spring-pms-implementation-report]
Leipnitz, R. and R. Geib, "A scalable and topology aware Leipnitz, R. and R. Geib, "A scalable and topology aware
MPLS data plane monitoring system", draft-leipnitz-spring- MPLS data plane monitoring system", IETF, draft-leipnitz-
pms-implementation-report-00 (work in progress), June spring-pms-implementation-report-00, 2016.
2016.
[RFC6576] Geib, R., Ed., Morton, A., Fardid, R., and A. Steinmitz,
"IP Performance Metrics (IPPM) Standard Advancement
Testing", BCP 176, RFC 6576, DOI 10.17487/RFC6576, March
2012, <http://www.rfc-editor.org/info/rfc6576>.
Authors' Addresses Authors' Addresses
Ruediger Geib (editor) Ruediger Geib (editor)
Deutsche Telekom Deutsche Telekom
Heinrich Hertz Str. 3-7 Heinrich Hertz Str. 3-7
Darmstadt 64295 Darmstadt 64295
Germany Germany
Phone: +49 6151 5812747 Phone: +49 6151 5812747
 End of changes. 70 change blocks. 
231 lines changed or deleted 396 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/