One document matched: draft-geib-spring-oam-usecase-02.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-02' 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>
<author initials="C." surname="Pignataro" fullname="Carlos Pignataro">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>7200 Kit Creek Road</street>
<city>Research Triangle Park</city> <region>NC</region> <code>27709-4987</code>
<country>US</country>
</postal>
<email>cpignata@cisco.com</email>
</address>
</author>
<author initials="N." surname="Kumar" fullname="Nagendra Kumar">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>7200 Kit Creek Road</street>
<city>Research Triangle Park</city> <region>NC</region> <code>27709</code>
<country>US</country>
</postal>
<email>naikumar@cisco.com</email>
</address>
</author>
<date month="July" 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.
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.</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>.
Thus a centralised monitoring unit is MPLS topology aware in a Segment
Routed domain and this topology awareness is used for OAM purposes. The
MPLS path monitoring system described by this document can be realised
with pre-Segment based Routing (SR) technology. Making such a 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
significantly simplifies and stabilises such an MPLS path monitoring
system. </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
centralized monitoring device is able to monitor the complete set of a domains
forwarding paths. OAM packets never leave data plane. Legacy path trace
is still required. In addition to Segment Routing related IGP extensions, also
RFC 4379 features should be extended to support detection of SR routed paths.
They further should be enhanced to support all deployed IP/MPLS entropy options.
In an IPv6 domain, a MPLS like tree trace functionality is desirable.</t>
<t>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>Alternatively, any path may be executed by building suitable label
stacks. This allows path execution without ECMP awareness.</t>
<t>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 interface to a specialised OAM
system, 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="An MPLS topology aware 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 every arbitrary chain of paths. A node connected to an SR domain is
MPLS topology aware (the node knows 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 and then monitor it.</t>
<t> The PMS may do so by sending packets carrying the following MPLS label
stack 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). 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).</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 detection and monitoring">
<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 detection and monitoring</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 and to monitor
availability of that path afterwards. 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 given in figure 1:</t>
<t><list style="symbols">
<t>The path PMS to LER i must be available. This path must be detectable,
but it is usually sufficient to apply an SPF based path.</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. To do so,
in a first step the PMS sends MPLS OAM packets to execute a so
called tree trace between LER i and LER j and stores the IP destination
addresses required to execute each detected path. This method of
dealing with load balancing paths requires the smallest label stacks
if long term monitoring of paths is applied after the tree trace
completion.</t>
<t>The path LER j to PMS to must be be available. This path must be
detectable, but it is usually sufficient to apply an SPF based path.</t>
</list></t>
<t>Once the MPLS paths (Node SIDs) and the required IP address information
has been detected, the LER i to LER j can be monitored by the PMS.
Monitoring doesn't require MPLS OAM functionality, it is purely based on
forwarding. To ensure reliable results, the PMS should be aware of any changes
in IGP or MPLS topology. Further changes in ECMP functionality at LER i will
impact results. Either the PMS should be notified of such changes or they
should be limited to planned maintenance. After a topology change, MPLS OAM
will be useful to detect the impact of the change.</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). The advantage of
this method is, that it does not involve MPLS OAM functionality and it
is independent of ECMP functionalities. The method still is able to monitor
all link combinations of all paths of an MPLS domain. If correct forwarding
along the desired paths has to be checked, RFC4739 functionality should be
applied also in this case.</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
scalability. Data plane failure detection by circulating monitoring packets
can be executed at any time. The PMS further executes MPLS OAM functions
everywhere in the MPLS domain. It does not require access to LSR/LER
management interfaces to do so. MPLS traceroutes as specified above
should be executed only during off peak times (and then with limited
parallel MPLS ping/trace load).</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="Failure Notification from PMS to LERi">
<t>PMS on detecting any failure in the path liveliness MAY use any out-of-band
mechanism to signal te\he failure to LERi. This document does not not propose any
specific mechanism and Operators can choose any existing or new approach.
</t>
<t>Alternately, the Operator may log the failure in local monitoring system and
take necessary action by manual intervention.
</t>
</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 plane information, RFC4379
should be enhanced to allow collection of data relevant to check all
relevant types of Segment IDs.</t>
</section>
<section title="Connectivity Verification using PMS">
<t>While the PMS based use cases explained in Section 3 is sufficient to provide
Continuity check between LER i and LER j, it may not
help perform connectivity verification. So in some cases like data plane
programming corruption, it is possible that a transit node between LER i and LER j
erroneously remove the top segment ID and forward to PMS based on bottom segment
ID leading to falsified path liveliness to PMS.
</t>
<t>There are various method to perform basic connectivity verification like
intermittely setting the TTL to 1 in bottom label so LER j selectively perform
connectivity verification. A detailed explanation will be added in later version.
</t>
</section>
<section title="Extensions of related standards">
<t>RFC4379 functions should be extended to support Flow- and Entropy Label
based ECMP. Further, an RFC4379 like functionality may be desirable for
IPv6 networks.
</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>
<section title="Acknowledgement">
<t>The authors would like to thank Nobo Akiya for his cotribution.</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
v02 2014-07-02 RG Included input of team, text re-arrangements and explanations
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:25:45 |