One document matched: draft-geib-spring-oam-usecase-00.txt
spring R. Geib, Ed.
Internet-Draft Deutsche Telekom
Intended status: Informational October 17, 2013
Expires: April 20, 2014
Use case for a scalable and topology aware MPLS data plane monitoring
system
draft-geib-spring-oam-usecase-00
Abstract
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 20, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Geib Expires April 20, 2014 [Page 1]
Internet-Draft Abbreviated Title October 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. A topology aware MPLS path monitoring system . . . . . . . . . 4
3. Applying SR to monitor LDP paths . . . . . . . . . . . . . . . 5
4. PMS monitoring of different Segment ID types . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Geib Expires April 20, 2014 [Page 2]
Internet-Draft Abbreviated Title October 2013
1. Introduction
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.
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.
MPLS OAM offers flexible features to recognise an execute data paths
of an MPLS domain. By utilsing the ECMP related tool set of RFC 4379
[RFC4379], a segment based routing LSP monitoring system may:
o easily detect ECMP functionality and properties of paths at data
level.
o construct monitoring packets executing desired paths also if ECMP
is present.
o limit the MPLS label stack of an OAM packet to a minmum of 3
labels.
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.
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.
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
Geib Expires April 20, 2014 [Page 3]
Internet-Draft Abbreviated Title October 2013
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.
2. A topology aware MPLS path monitoring system
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:
o Top Label: connected LSRs path to LER i.
o Next Label: LER i's path to LER j.
o Next Label or address: Data plane measurement destination at LER j
(this could be a label or an IP address)
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.
+---+ +----+ +-----+
|PMS| |LSR1|-----|LER i|
+---+ +----+ +-----+
| / \ /
| / \__/
+-----+/ /|
|LER m| / |
+-----+\ / \
\ / \
\+----+ +-----+
|LSR2|-----|LER j|
+----+ +-----+
Example of a PMS based LSP dataplane liveness measurement
Figure 1
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
Geib Expires April 20, 2014 [Page 4]
Internet-Draft Abbreviated Title October 2013
the figure: PMS = 10, LER i = 20, LER j = 30.
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.
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).
A few observations on the example:
o The path PMS to LER i must be stable and it must be detectable.
o 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.
o The path LER j to PMS to must be stable and it must be detectable.
To ensure reliable results, the PMS should be aware of any changes in
IGP or MPLS topology.
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).
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.
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.
3. Applying SR to monitor LDP paths
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
Geib Expires April 20, 2014 [Page 5]
Internet-Draft Abbreviated Title October 2013
monitored. In the above example, the label 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 Next: LDP label identifying the path to LER j at LER i.
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
aware of the LER LDP-MPLS topology, the PMS may learn the SR MPLS
topology by IGP and use this information.
4. PMS monitoring of different Segment ID types
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).
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.
5. IANA Considerations
This memo includes no request to IANA.
6. Security Considerations
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.
7. References
7.1. Normative References
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
Geib Expires April 20, 2014 [Page 6]
Internet-Draft Abbreviated Title October 2013
February 2006.
[min_ref] authSurName, authInitials., "Minimal Reference", 2006.
7.2. Informative References
[ID.sr-architecture]
IETF, "Segment Routing Architecture", IETF, https://
datatracker.ietf.org/doc/
draft-filsfils-rtgwg-segment-routing/, 2013.
Author's Address
Ruediger Geib (editor)
Deutsche Telekom
Heinrich Hertz Str. 3-7
Darmstadt, 64295
Germany
Phone: +49 6151 5812747
Email: Ruediger.Geib@telekom.de
| PAFTECH AB 2003-2026 | 2026-04-23 21:04:28 |