One document matched: draft-geib-spring-oam-usecase-00.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-00' 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>
<date month="October" year="2013" />
<!-- 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 scalbale 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>Paths looping packets through a network are not desireable for
network and user data routing. The ability to execute arbitrary path combinations
within a domain 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 never leaving data plane. This 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>The design of such a monitoring system should ensure that OAM packets never
leave the domain they are supposed to monitor. Topology and network state
awareness are useful, careful address-selection may be another one.</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>IPv6 related ECMP path detection and execution for OAM purposes is less
powerful than that offered by MPLS OAM. 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>
</section>
<section title="A topology aware MPLS path monitoring system">
<t>A MPLS path monitoring system (PMS) which is able to learn all labeled paths
of a domain is able to build a measurement packet which executes
an arbitrary chain of paths. Such a monitoring system is aware
of the MPLS topology. The task is to check liveliness of the MPLS
transport path between LER i and LER j. The PMS may do so by sending packets
carrying the following minimum address infomation:</t>
<t><list style="symbols">
<t>Top Label: connected LSRs path to LER i.</t>
<t>Next Label: LER i's path to LER j.</t>
<t>Next Label or address: Data plane measurement destination at LER j
(this could be a label or an IP address)</t>
</list></t>
<t>Note that the label stack could as well address MPLS node after MPLS node
passed by the measurtement packet on it's path from PMS to the packets destination
or any address stack between this maximum and the above minimum address information.
Further, the destination could be the PSM itself. This is shown in figure.</t>
<figure anchor="PMS_example">
<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 a global Node-Segment ID
label space (meaning the value of a label never changes during a
label swap). 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="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'?>
<reference anchor="min_ref">
<!-- the following is the minimum to make xml2rfc happy -->
<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-architecture">
<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>
</references>
<!-- Change Log
v00 2013-10-15 RG Initial version
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:27:44 |