One document matched: draft-geib-spring-oam-usecase-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category='info' docName='draft-geib-spring-oam-usecase-01' ipr='trust200902'>
<!-- category values: std, bcp, info, exp, and historic
ipr values: noModificationTrust200902, noDerivativesTrust200902, pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Abbreviated Title">Use case for a scalable and topology aware MPLS
data plane monitoring system</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Ruediger Geib" initials="R." role="editor"
surname="Geib">
<organization>Deutsche Telekom</organization>
<address>
<postal>
<street>Heinrich Hertz Str. 3-7</street>
<!-- Reorder these if your country does things differently -->
<code>64295</code>
<city>Darmstadt</city>
<region></region>
<country>Germany</country>
</postal>
<phone>+49 6151 5812747</phone>
<email>Ruediger.Geib@telekom.de</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<code></code>
<city>Brussels</city>
<region></region>
<country>Belgium</country>
</postal>
<phone></phone>
<email>cfilsfil@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="February" year="2014" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Routing</area>
<workgroup>spring</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>Segment based Routing, OAM, LSP surveillance, MPLS monitoring</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>It is essential for a network operator to monitor all the forwarding paths
observed by the transported user packets. The monitoring flow must be
forwarded in dataplane in a similar way as user packets. Problem localization
is required.</t>
<t>This document describes a solution to this problem statement and
illustrates it with use-cases.</t>
<t>The solution is described for a single IGP MPLS domain.</t>
<t>The solution applies to monitoring of LDP LSP's as well as to monitoring
of Segment Routed LSP's. Segment Routing simplifies the solution by the use
of IGP-based signalled segments as specified by <xref target="ID.sr-isis"></xref>.</t>
<t>This document adopts the terminology and framework described in <xref target="ID.sr-archi"></xref>.
It further adopts the editorial simplification explained in section 1.2 of
the <xref target="ID.sr-use">segment routing use-cases</xref>.</t>
<t>The proposed solution offers several benefits for network monitoring. A single
monitoring device is able to monitor the complete set of a domains forwarding
paths with OAM packets that never leave data plane. Faults can be localized:</t>
<t><list style="symbols">
<t>by IGP LSA analysis.</t>
<t>by correlation between different probes.</t>
<t>by MPLS traceroute and adapted ping messages.</t>
</list></t>
<t>The proposed solution requires topology awareness
as well as a suitable security architecture. Topology awareness is an essential
part of link state IGPs. Adding MPLS topology awareness to an IGP speaking
device hence enables a simple and scaleable data plane monitoring mechanism.</t>
<t>MPLS OAM offers flexible features to recognise an execute data paths of
an MPLS domain. By utilsing the ECMP related tool set of <xref target="RFC4379">RFC 4379</xref>, a segment
based routing LSP monitoring system may:</t>
<t><list style="symbols">
<t>easily detect ECMP functionality and properties of paths at data level.</t>
<t>construct monitoring packets executing desired paths also if ECMP is present.</t>
<t>limit the MPLS label stack of an OAM packet to a minmum of 3 labels.</t>
</list></t>
<t>MPLS OAM supports detection and execution of ECMP paths quite smart. This
document is foscused on MPLS path monitoring.</t>
<t>The MPLS path monitoring system described by this document can be realised
with pre-Segment based Routing (SR) technology. Making monitoring system aware
of a domains complete MPLS topolfrom utilising 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
significantly simplifies and stabilises such an MPLS path monitoring system.
In addition to IGP extensions, also RFC 4379 may have to be extended to support
detection of SR routed paths.</t>
<t>Note that the MPLS path monitoring system may be a specialised system
residing at a single interface of the domain to be monitored. As long as
measurement packets return to this or another well specified interface, the
MPLS monitoring system is the single entity pushing monitoring packet label stacks.
Concerns about router label stack pushing capabilities don't apply in this case.</t>
<t>First drafts discussing requirements, extensions of RFC4379 and
possible solutions to allow SR usage as described by this document
are at hand, see <xref target="ID.sr-4379ext"></xref> and <xref target="ID.sr-oam_detect"></xref>.</t>
</section>
<section title="A topology aware MPLS path monitoring system">
<t>An MPLS path monitoring system (PMS) which is able to learn the IGP LSDB
(including the SID's) is able to build a measurement packet which
executes any arbitrary chain of paths. Such a monitoring system is
topology aware (all related IP adresses, MPLS SIDs and labels).</t>
<t>Let us describe how the PMS can check the liveliness of the MPLS
transport path between LER i and LER j.</t>
<t> The PMS may do so by sending packets carrying the following minimum
address infomation:</t>
<t><list style="symbols">
<t>Top Label: a path from PMS to LER i This is expressed as Node SID of
LER i.</t>
<t>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.</t>
<t>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). In this case, a no SID/label may be assigned to the PMS (if
it is a host/server residing in an IP subnet outside the MPLS domain).</t>
</list></t>
<t>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 provding an MPLS access to a router which is part of the monitored
MPLS domain.</t>
</section>
<section title="SR based OAM use case illustration">
<section title="Use-case 1 - LSP dataplane liveliness measurement">
<figure anchor="PMS_use_case_1">
<preamble></preamble>
<artwork>
+---+ +----+ +-----+
|PMS| |LSR1|-----|LER i|
+---+ +----+ +-----+
| / \ /
| / \__/
+-----+/ /|
|LER m| / |
+-----+\ / \
\ / \
\+----+ +-----+
|LSR2|-----|LER j|
+----+ +-----+
</artwork>
<postamble>Example of a PMS based LSP dataplane liveness measurement</postamble>
</figure>
<t>For the sake of simplicity, let's assume that all the nodes are
configured with the same <xref target="ID.sr-archi">SRGB</xref>.
as described by section 1.2 of <xref target="ID.sr-use"></xref>.</t>
<t>Let's assign the following Node SIDs to the nodes of the figure:
PMS = 10, LER i = 20, LER j = 30.</t>
<t>The aim is to check liveliness of the path LER i to LER j. The PMS does
this by creating a measurement packet with the following label stack
(top to bottom): 20 - 30 - 10.</t>
<t>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
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 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 (and it
will pass a LSR and LER m).</t>
<t>A few observations on the example:</t>
<t><list style="symbols">
<t>The path PMS to LER i must be stable and it must be
detectable.</t>
<t>If ECMP is deployed, it may be desired to measure along both
possible paths, a packet may use between LER i and LER j. This
may be done by using MPLS OAM coded measurement packets with
suitable IP destination addresses.</t>
<t>The path LER j to PMS to must be stable and it must be
detectable.</t>
</list></t>
<t>To ensure reliable results, the PMS should be aware of any changes
in IGP or MPLS topology.</t>
<t>Determining a path to be executed prior to a measurement may also be
done by setting up a label including all node SIDs along that path (if
LER1 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).</t>
<t>Obviously, the PMS is able to check and monitor data plane liveliness
of all LSPs in the domain. The PMS may be a router, but could also be
dedicated monitoring system. If measurement system reliability is an
issue, more than a single PMS may be connected to the MPLS domain.</t>
<t>Monitoring an MPLS domain by a PMS based on SR offers the option of
monitoring complete MPLS domains with little effort and very excellent
scaleability.</t>
</section>
<section title="Use-case 2 - Monitoring a remote bundle">
<figure anchor="PMS_use_case_2">
<preamble></preamble>
<artwork>
+---+ _ +--+ +-------+
| | { } | |---991---L1---662---| |
|PMS|--{ }-|R1|---992---L2---663---|R2 (72)|
| | {_} | |---993---L3---664---| |
+---+ +--+ +-------+
</artwork>
<postamble>SR based probing of all the links of a remote bundle</postamble>
</figure>
<t>R1 adresses Lx by the Adjacency SID 99x, while R2 adresses
Lx by the Adjacency SID 66(x+1).</t>
<t>In the above figure, the PMS needs to assess the dataplane availability
of all the links within a remote bundle connected to routers R1 and R2.</t>
<t>The monitoring system retrieves the SID/Label information from the IGP
LSDB and appends the following segment list/label stack: {72, 662, 992, 664}
on its IP probe (whose source and destination addresses are the address
of the PMS).</t>
<t>MS sends the probe to its connected router. If the connected router
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
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 R2 over link L2 (Adjacency SID 992). R2 forwards the probe to R1
over link L3 (Adjacency SID 664). R1 then forwards the IP probe to PMS
as per classic IP forwarding.</t>
</section>
<section title="Use-Case 3 - Fault localization">
<t>In the previous example, a uni-directional fault on the middle link
from R1 to R2 would be localized by sending the following two probes
with respective segment lists:</t>
<t><list style="symbols">
<t>72, 662, 992, 664</t>
<t>72, 663, 992, 664</t>
</list></t>
<t>The first probe would fail while the second would succeed. 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 non successful measurement.
Assuming the second probe has been routed correctly, the fault must have
been occurring in R2 which didn't forward the packet to the interface
identified by its Adjacency SID 662.</t>
</section>
</section>
<section title="Applying SR to monitor LDP paths">
<t>A SR based PMS connected to a MPLS domain consisting of LER and LSR
supporting SR and LDP in parrallel in all nodes may use SR paths to
transmit packets to and from start and end points of LDP paths to be
monitored. In the above example, the label stack top to bottom may be
as follows, when sent by the PMS:</t>
<t><list style="symbols">
<t>Top: SR based Node-SID of LER i at LER m.</t>
<t>Next: LDP label identifying the path to LER j at LER i.</t>
<t>Bottom: SR based Node-SID identifying the path to the PMS at
LER j</t>
</list></t>
<t>While the mixed operation shown here still requires the PMS to be aware
of the LER LDP-MPLS topology, the PMS may learn the SR MPLS topology by
IGP and use this information.</t>
</section>
<section title="PMS monitoring of different Segment ID types">
<t>MPLS SR topology awareness should allow the SID to monitor liveliness
of most types of SIDs (this may not be recommendable if a SID identifies
an inter domain interface). </t>
<t>To match control plane information with data palne information, RFC4379
should be enhaced to allow collection of data relevant to check all
relevant types of Segment IDs.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>As mentioned in the introduction, a PMS monitoring packet should never
leave the domain where it originated. It therefore should never use stale
MPLS or IGP routing information. Further, asigning different label ranges
for different purposes may be useful. A well known global service level
range may be excluded for utilisation within PMS measurement packets.
These ideas shoulddn't start a discussion. They rather should point out,
that such a discussion is required when SR based OAM mechanisms like a
SR are standardised.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
<?rfc include='reference.RFC.4379'?>
<!-- the following is the minimum to make xml2rfc happy -->
<!--
<reference anchor="min_ref"
<front>
<title>Minimal Reference</title>
<author initials="authInitials" surname="authSurName">
<organization></organization>
</author>
<date year="2006" />
</front>
</reference>
-->
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<!-- A reference written by by an organization not a person. -->
<reference anchor="ID.sr-archi">
<front>
<title>Segment Routing Architecture
</title>
<author>
<organization>IETF</organization>
</author>
<date year="2013"/>
</front>
<seriesInfo name="IETF, " value="https://datatracker.ietf.org/doc/draft-filsfils-rtgwg-segment-routing/"/>
</reference>
<reference anchor="ID.sr-use">
<front>
<title>Segment Routing Use Cases
</title>
<author>
<organization>IETF</organization>
</author>
<date year="2013"/>
</front>
<seriesInfo name="IETF, " value="http://datatracker.ietf.org/doc/draft-filsfils-rtgwg-segment-routing-use-cases/"/>
</reference>
<reference anchor="ID.sr-isis">
<front>
<title>IS-IS Extensions for Segment Routing
</title>
<author>
<organization>IETF</organization>
</author>
<date year="2013"/>
</front>
<seriesInfo name="IETF, " value="http://datatracker.ietf.org/doc/draft-previdi-isis-segment-routing-extensions/"/>
</reference>
<reference anchor="ID.sr-4379ext">
<front>
<title>Label Switched Path (LSP) Ping/Trace for Segment
Routing Networks Using MPLS Dataplane
</title>
<author>
<organization>IETF</organization>
</author>
<date year="2013"/>
</front>
<seriesInfo name="IETF, " value="http://datatracker.ietf.org/doc/draft-kumar-mpls-spring-lsp-ping/"/>
</reference>
<reference anchor="ID.sr-oam_detect">
<front>
<title>Detecting Multi-Protocol Label Switching (MPLS) Data
Plane Failures in Source Routed LSPs
</title>
<author>
<organization>IETF</organization>
</author>
<date year="2013"/>
</front>
<seriesInfo name="IETF, " value="http://datatracker.ietf.org/doc/draft-kini-spring-mpls-lsp-ping/"/>
</reference>
</references>
<!-- Change Log
v00 2013-10-15 RG Initial version
v01 2013-11-01 RG Included input of Clarence, editorial
changes
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:26:48 |