One document matched: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-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="std" docName="draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-00"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
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="Extensions for MPLS-TP OAM Conf">Configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions Using LSP Ping</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Elisa Bellagamba" initials="E.B." role="editor"
surname="Bellagamba">
<organization>Ericsson</organization>
<address>
<postal>
<street>Farogatan 6</street>
<!-- Reorder these if your country does things differently -->
<city>Kista</city>
<region></region>
<code>164 40</code>
<country>Sweden</country>
</postal>
<phone>+46 761440785</phone>
<email>elisa.bellagamba@ericsson.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Loa Andersson" initials="L.A." role="editor"
surname="Andersson">
<organization>Ericsson</organization>
<address>
<postal>
<street>Farogatan 6</street>
<!-- Reorder these if your country does things differently -->
<city>Kista</city>
<region></region>
<code>164 40</code>
<country>Sweden</country>
</postal>
<phone></phone>
<email>loa.andersson@ericsson.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Pontus Skoldstrom" initials="P.S." role="editor"
surname="Skoldstrom">
<organization>Acreo AB</organization>
<address>
<postal>
<street>Electrum 236</street>
<!-- Reorder these if your country does things differently -->
<city>Kista</city>
<region></region>
<code>164 40</code>
<country>Sweden</country>
</postal>
<phone>+46 8 6327731</phone>
<email>pontus.skoldstrom@acreo.se</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Dave Ward" initials="D.W." role=""
surname="Ward">
<organization>Juniper</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<email>dward@juniper.net</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<!-- 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 -->
<date day="10" month="December" year="2010" />
<area>Signaling</area>
<workgroup>MPLS Working Group</workgroup>
<keyword>LSP-PING</keyword>
<keyword>MPLS</keyword>
<keyword>MPLS-TP</keyword>
<abstract>
<t>This specification describes the configuration of pro-active MPLS-TP Operations,
Administration, and Maintenance (OAM) Functions for a given LSP using a common set
of TLVs that is carried on LSP Ping.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document describes the configuration of pro-active MPLS-TP Operations,
Administration, and Maintenance (OAM) Functions for a given LSP using a common
set of TLVs that can be carried on either RSVP-TE [RFC3209] or LSP Ping [BFD-Ping].
In particular it specifies the mechanisms necessary to establish MPLS-TP OAM
entities monitoring an LSP and defines information elements and procedures to
configure pro-active MPLS OAM functions. Initialization and control of on-demand
MPLS OAM functions are expected to be carried out by directly accessing network nodes
via a management interface; hence configuration and control of on-demand OAM functions
are out-of-scope for this document.</t>
<t>Because the Transport Profile of MPLS, by definition [RFC5654], must be capable
of operating without a control plane, there are two options for in-band OAM: by using
an NMS or by using LSP-Ping if a control plane is not instantiated.</t>
<t>Pro-active MPLS OAM is based on the Bidirectional Forwarding
Detection (BFD) protocol [BFD]. Bidirectional Forwarding Detection
(BFD), as described in [BFD], defines a protocol that provides low-
overhead, short-duration detection of failures in the path between
two forwarding engines, including the interfaces, data link(s), and
to the extent possible the forwarding engines themselves. BFD can be
used to track the liveliness and detect data plane failures of MPLS-TP point-to-point
and might also be extended to p2mp connections.</t>
<t>MPLS Transport Profile (MPLS-TP) describes a profile of MPLS that
enables operational models typical in transport networks, while
providing additional OAM, survivability and other maintenance
functions not currently supported by MPLS. [MPLS-TP-OAM-REQ] defines the requirements
for the OAM functionality of MPLS-TP.</t>
<t>BFD has been chosen to be the basis of pro-active MPLS-TP OAM functions.
MPLS-TP OAM extensions for transport applications, for which this document specifies
the configuration, are specified in [BFD-CCCV], [MPLS-PM], and [MPLS-FMS].</t>
<section title="Contributing Authors">
<t>The editors gratefully acknowledge the contribution of John Drake.</t>
</section>
<section title ="Requirements Language">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.
</t>
</section>
<section title="Overview of BFD OAM operation">
<t>BFD is a simple hello protocol that in many respects is similar to
the detection components of well-known routing protocols. A pair of systems transmits BFD packets periodically over each path between the
two systems, and if a system stops receiving BFD packets for long
enough, some component in that particular bidirectional path to the
neighboring system is assumed to have failed. Systems may also
negotiate to not send periodic BFD packets in order to reduce
overhead.</t>
<t>A path is only declared to be operational when two-way communication
has been established between systems, though this does not preclude
the use of unidirectional links to support bidirectional paths
(co-routed or bidirectional or associated bidirectional).</t>
<t>Each system estimates how quickly it can send and receive BFD packets
in order to come to an agreement with its neighbor about how rapidly
detection of failure will take place. These estimates can be
modified in real time in order to adapt to unusual situations. This
design also allows for fast systems on a shared medium with a slow
system to be able to more rapidly detect failures between the fast
systems while allowing the slow system to participate to the best of
its ability.</t>
<t>The ability of each system to control the BFD packet transmission
rate in both directions provides a mechanism for congestion control,
particularly when BFD is used across multiple network hops.</t>
<t>As recommended in [BFD-CCCV], the BFD tool needs to be extended for the
proactive CV functionality by the addition of an unique identifier in order to meet the requirements. The document in [BFD-CCCV] specifies the BFD
extension and behavior to meet the requirements for MPLS-TP proactive
Continuity Check and Connectivity Verification functionality and the
RDI functionality as defined in [MPLS-TP-OAM-REQ].</t>
</section>
</section>
<section title="Overview of MPLS OAM for Transport Applications">
<t>[MPLS-TP-OAM-FWK] describes how MPLS OAM mechanisms are operated
to meet transport requirements outlined in [MPLS-TP-OAM-REQ].</t>
<t>[BFD-CCCV] specifies two BFD operation modes: 1) "CC mode",
which uses periodic BFD message exchanges with symmetric timer settings,
supporting Continuity Check, 2) "CV/CC mode" which sends unique
maintenance entity identifiers in the periodic BFD messages supporting
Connectivity Verification as well as Continuity Check.</t>
<t>[MPLS-PM] specifies mechanisms for performance monitoring of LSPs,
in particular it specifies loss and delay measurement OAM functions.</t>
<t>[MPLS-FMS] specifies fault management signals with which a server
LSP can notify client LSPs about various fault conditions to suppress
alarms or to be used as triggers for actions in the client LSPs.
The following signals are defined: Alarm Indication Signal (AIS),
Link Down Indication (LDI) and Locked Report (LKR). To indicate client
faults associated with the attachment circuits Client Signal Failure
Indication (CSF) can be used. CSF is described in [MPLS-TP-OAM-FWK]
and in the context of this document is for further study.</t>
<t>[MPLS-TP-OAM-FWK] describes the mapping of fault conditions to
consequent actions. Some of these mappings may be configured by the
operator, depending on the application of the LSP. The following defects
are identified: Loss Of Continuity (LOC), Misconnectivity,
MEP Misconfiguration and Period Misconfiguration. Out of these defect
conditions, the following consequent actions may be configurable:
1) whether or not the LOC defect should result in blocking the outgoing
data traffic; 2) whether or not the "Period Misconfiguration defect"
should result a signal fail condition.</t>
</section>
<section title="Theory of Operations">
<section title="MPLS OAM Configuration Operation Overview">
<t>Refer to section 3.1 of [RSVP-TE CONF] for the applicability scenarios description and their related configurations and mechanisms. In fact, each of them can be completely reused in case of LSP Ping configuration as well as already done for RSVP-TE. </t>
<t>The only exception is that LSP Ping needs an extra TLV to carry the information required for the "CV/CC mode" OAM [BFD-CCCV] and defined in [MPLS-TP-IDENTIF]. Such information is supplied by an additional sub-TLV as defined in section 3.3. </t>
</section>
<section title="TLVs structure">
<t>
LSP Ping follows the same TLV structure defined for RSVP-TE in [RSVP-TE CONF] from section 3.2 to section 3.6.
</t>
<t>
In addition, an extra TLV is defined "MPLS OAM SOURCE MEP-ID TLV" in order to supply the information needed for the Connectivity Verification
functionality. In fact, RSVP-TE does not need such TLV because it already encodes this information in other mandatory objects
already included in its messages.
</t>
<t>
The MPLS OAM SOURCE MEP-ID TLV is intended to be inserted in the scope of the "OAM configuration TLV" together with the othe sub-TLV as defined in
[RSVP-TE CONF] section 3.2.
</t>
</section>
<section title="MPLS OAM SOURCE MEP-ID TLV for LSP Ping">
<t>The "MPLS OAM SOURCE MEP-ID TLV for LSP Ping" depicted below is carried as a sub-TLV of the
"OAM Configuration TLV" in case LSP Ping is used.</t>
<t>
<figure>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (6) (IANA) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRC NODE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TUNNEL ID | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>Type: indicates a new type, the "MPLS OAM SOURCE MEP-ID" (IANA to define).</t>
<t>Length: indicates the TLV total length in octets.</t>
<t>SRC NODE ID: 32-bit node identifier as defined in [MPLS-TP-IDENTIF].</t>
<t>TUNNEL ID: a 16-bit unsigned integer unique to the node as defined in [MPLS-TP-IDENTIF].</t>
<t>LSP ID: a 16-bit unsigned integer unique within the Tunnel_ID as defined in [MPLS-TP-IDENTIF].</t>
</section>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section title="BFD OAM configuration errors">
<t>In addition to error values specified in [OAM-CONF-FWK] and [ETH-OAM]
this document defines the following values for the "OAM Problem" Error Code:</t>
<t><list>
<t>- "MPLS OAM Unsupported Functionality";</t>
<t>- "OAM Problem/Unsupported TX rate interval".</t>
</list>
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The signaling of OAM related parameters and the automatic establishment of OAM
entities introduces additional security
considerations to those discussed in [RFC3473]. In particular, a
network element could be overloaded, if an attacker would request
liveliness monitoring, with frequent periodic messages, for a high
number of LSPs, targeting a single network element.</t>
<t>Security aspects will be covered in more detailed in subsequent
versions of this document.</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.3471"?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.5586"?>
<?rfc include="reference.RFC.5654"?>
<reference anchor="MPLS-TP-OAM-REQ"
target="draft-ietf-mpls-tp-oam-requirements">
<!-- the following is the minimum to make xml2rfc happy -->
<front>
<title>Requirements for OAM in MPLS Transport Networks</title>
<author initials="M" surname="Vigoureux">
<organization></organization>
</author>
<author initials="D" surname="Ward">
<organization></organization>
</author>
<author initials="M" surname="Betts">
<organization></organization>
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="RSVP-TE CONF"
target="draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext">
<!-- the following is the minimum to make xml2rfc happy -->
<front>
<title>Configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions Using RSVP-TE</title>
<author initials="E" surname="Bellagamba">
<organization></organization>
</author>
<author initials="D" surname="Ward">
<organization></organization>
</author>
<author initials="L" surname="Andersson">
<organization></organization>
</author>
<author initials="P" surname="Sköldström">
<organization></organization>
</author>
<date year="2010" />
</front>
</reference>
<reference anchor="BFD"
target="draft-ietf-bfd-base">
<!-- the following is the minimum to make xml2rfc happy -->
<front>
<title>Bidirectional Forwarding Detection</title>
<author initials="D" surname="Katz">
<organization></organization>
</author>
<author initials="D" surname="Ward">
<organization></organization>
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="OAM-CONF-FWK"
target="draft-ietf-ccamp-oam-configuration-fwk">
<!-- the following is the minimum to make xml2rfc happy -->
<front>
<title>OAM Configuration Framework for GMPLS RSVP-TE</title>
<author initials="A" surname="Takacs">
<organization></organization>
</author>
<author initials="D" surname="Fedyk">
<organization></organization>
</author>
<author initials="J" surname="van He">
<organization></organization>
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="MPLS-TP-IDENTIF"
target="draft-swallow-mpls-tp-identifiers">
<!-- the following is the minimum to make xml2rfc happy -->
<front>
<title>MPLS-TP Identifiers</title>
<author initials="M" surname="Bocci">
<organization></organization>
</author>
<author initials="G" surname="Swallow">
<organization></organization>
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="MPLS-PM"
target="draft-frost-mpls-tp-loss-delay">
<!-- the following is the minimum to make xml2rfc happy -->
<front>
<title>Packet Loss and Delay Measurement for the
MPLS Transport Profile</title>
<author initials="S" surname="Bryant">
<organization></organization>
</author>
<author initials="D" surname="Frost">
<organization></organization>
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="MPLS-FMS"
target="draft-sfv-mpls-tp-fault">
<!-- the following is the minimum to make xml2rfc happy -->
<front>
<title>MPLS Fault Management OAM</title>
<author initials="G" surname="Swallow">
<organization></organization>
</author>
<author initials="A" surname="Fulignoli">
<organization></organization>
</author>
<author initials="M" surname="Vigoureux">
<organization></organization>
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="MPLS-CSF"
target="draft-he-mpls-tp-csf">
<!-- the following is the minimum to make xml2rfc happy -->
<front>
<title>Indication of Client Failure in MPLS-TP</title>
<author initials="J" surname="He">
<organization></organization>
</author>
<author initials="H" surname="Li">
<organization></organization>
</author>
<date year="2009" />
</front>
</reference>
</references>
<references title="Informative References">
<reference anchor="BFD-CCCV"
target="draft-asm-mpls-tp-bfd-cc-cv">
<!-- the following is the minimum to make xml2rfc happy -->
<front>
<title>MPLS-TP BFD for Proactive CC-CV and RDI</title>
<author initials="A" surname="Fulignoli">
<organization></organization>
</author>
<author initials="S" surname="Boutros">
<organization></organization>
</author>
<author initials="M" surname="Vigoreux">
<organization></organization>
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="BFD-Ping"
target="draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02">
<!-- the following is the minimum to make xml2rfc happy -->
<front>
<title>LSP-Ping and BFD encapsulation over ACH</title>
<author initials="N" surname="Bahadur">
<organization></organization>
</author>
<author initials="R" surname="Aggarwal">
<organization></organization>
</author>
<author initials="D" surname="Ward">
<organization></organization>
</author>
<author initials="T" surname="Nadeau">
<organization></organization>
</author>
<author initials="N" surname="Sprecher">
<organization></organization>
</author>
<author initials="Y" surname="Weingarten">
<organization></organization>
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="MPLS-TP-OAM-FWK"
target="draft-ietf-mpls-tp-oam-framework">
<!-- the following is the minimum to make xml2rfc happy -->
<front>
<title>MPLS-TP OAM Framework and Overview</title>
<author initials="I" surname="Busi">
<organization></organization>
</author>
<author initials="B" surname="Niven-Jenkins">
<organization></organization>
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="MPLS-TP-FWK"
target="draft-ietf-mpls-tp-framework">
<!-- the following is the minimum to make xml2rfc happy -->
<front>
<title>OAM Configuration Framework for GMPLS RSVP-TE</title>
<author initials="M" surname="Bocci">
<organization></organization>
</author>
<author initials="S" surname="Bryant">
<organization></organization>
</author>
<author initials="D" surname="Frost">
<organization></organization>
</author>
<author initials="L" surname="Levrau">
<organization></organization>
</author>
<date year="2009" />
</front>
</reference>
<?rfc include="reference.RFC.4447"?>
<reference anchor="ETH-OAM"
target="draft-ietf-ccamp-rsvp-te-eth-oam-ext">
<!-- the following is the minimum to make xml2rfc happy -->
<front>
<title>GMPLS RSVP-TE Extensions for Ethernet OAM</title>
<author initials="A" surname="Takacs">
<organization></organization>
</author>
<author initials="B" surname="Gero">
<organization></organization>
</author>
<author initials="D" surname="Fedyk">
<organization></organization>
</author>
<author initials="D" surname="Mohan">
<organization></organization>
</author>
<author initials="D" surname="Long">
<organization></organization>
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="MPLS-TP OAM Analysis"
target="draft-sprecher-mpls-tp-oam-analysis">
<!-- the following is the minimum to make xml2rfc happy -->
<front>
<title>MPLS-TP OAM Analysis</title>
<author initials="N" surname="Sprecher">
<organization></organization>
</author>
<author initials="T" surname="Nadeau">
<organization></organization>
</author>
<author initials="H" surname="van Helvoort">
<organization></organization>
</author>
<author initials="" surname="Weingarten">
<organization></organization>
</author>
<date year="2006" />
</front>
</reference>
<reference anchor="LSP Ping"
target="RFC 3479">
<!-- the following is the minimum to make xml2rfc happy -->
<front>
<title>Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures</title>
<author initials="K" surname="Kompella">
<organization></organization>
</author>
<author initials="G" surname="Swallow">
<organization></organization>
</author>
<date year="2006" />
</front>
</reference>
</references>
<section anchor="app-additional" title="Additional Stuff">
<t>This becomes an Appendix.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 06:49:24 |