One document matched: draft-ietf-mpls-tp-oam-requirements-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="no"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-mpls-tp-oam-requirements-04"
ipr="trust200902">
<front>
<title abbrev="OAM Requirements for MPLS-TP">Requirements for OAM in MPLS
Transport Networks</title>
<author fullname="Martin Vigoureux" initials="M." role="editor"
surname="Vigoureux">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street>Route de Villejust</street>
<city>Nozay</city>
<region></region>
<code>91620</code>
<country>France</country>
</postal>
<email>martin.vigoureux@alcatel-lucent.com</email>
</address>
</author>
<author fullname="David Ward" initials="D." role="editor" surname="Ward">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 W. Tasman Dr.</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dward@cisco.com</email>
</address>
</author>
<author fullname="Malcolm Betts" initials="M." role="editor"
surname="Betts">
<organization>Huawei</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>malcolm.betts@huawei.com</email>
</address>
</author>
<date day="16" month="December" year="2009" />
<area>Routing</area>
<workgroup>MPLS Working Group</workgroup>
<keyword>MPLS-TP</keyword>
<keyword>OAM</keyword>
<abstract>
<t>This document lists architectural and functional requirements for the
Operations, Administration and Maintenance of MPLS Transport Profile.
These requirements apply to pseudowires, Label Switched Paths, and
Sections.</t>
</abstract>
<?rfc needLines="0"?>
</front>
<middle>
<section title="Introduction">
<t>In the context of MPLS Transport Profile (MPLS-TP, see <xref
target="I-D.ietf-mpls-tp-framework"></xref> and <xref
target="RFC5654"></xref>), the rationales for Operations, Administration
and Maintenance (OAM) are twofold as it can serve:</t>
<t><list style="symbols">
<t>as a network-oriented functionality, used by a transport network
operator to monitor his network infrastructure and to implement
internal mechanisms in order to enhance the general behaviour and
the level of performance of his network (e.g., protection mechanism
in case of node or link failure). As an example, fault localization
is typically associated with this use case.</t>
<t>as a service-oriented functionality, used by a transport service
provider to monitor services offered to end customers in order to be
able to react rapidly in case of a problem and to be able to verify
some of the Service Level Agreements (SLAs) parameters (e.g., using
performance monitoring) negotiated with the end customers. Note that
a transport service could be provided over several networks or
administrative domains that may not all be owned and managed by the
same transport service provider.</t>
</list></t>
<t>More generally, OAM is an important and fundamental functionality in
transport networks as it contributes to:</t>
<t><list style="symbols">
<t>the reduction of operational complexity and costs, by allowing
for efficient and automatic detection, localisation, handling and
diagnosis of defects, as well as by minimizing service interruptions
and operational repair times.</t>
<t>the enhancement of network availability, by ensuring that
defects, for example resulting in misdirected customer traffic, and
faults, are detected, diagnosed and dealt with before a customer
reports the problem.</t>
<t>meeting service and performance objectives, as the OAM
functionality allows for SLA verification in a multi-maintenance
domain environment and allows for the determination of service
degradation due, for example, to packet delay or packet loss.</t>
</list></t>
<section title="Scope of this Document">
<t>This document lists architectural and functional requirements for
the OAM functionality of MPLS-TP. These requirements apply to
pseudowires (PWs), Label Switched Paths (LSPs) and Sections.</t>
<t>These requirements are derived from the set of requirements
specified by ITU-T and published in the ITU-T Supplement Y.Sup4 <xref
target="Y.Sup4"></xref>.</t>
<t>By covering transport specificities, these requirements complement
those identified in RFC 4377 <xref target="RFC4377"></xref>, yet some
requirements may be similar.</t>
<t>This document only lists architectural and functional OAM
requirements. It does not detail the implications of their
applicability to the various types (e.g., point-to-point,
point-to-multipoint, unidirectional, bidirectional ...) of PWs, LSPs
and Sections. Furthermore, this document does not provide requirements
on how the protocol solution(s) should behave to achieve the
functional objectives. Please see <xref
target="I-D.ietf-mpls-tp-oam-framework"></xref> for further
information.</t>
<t>Note that the OAM functions identified in this document may be used
for fault management, performance monitoring and/or protection
switching applications. For example, connectivity verification can be
used for fault management by detecting failure conditions, but may
also be used for performance monitoring through its contribution to
the evaluation of performance metrics (e.g., unavailability time).
Nevertheless, it is outside the scope of this document to specify
which function should be used for which application.</t>
<t>Note also that it is anticipated that implementers may wish to
implement OAM message handling in hardware. Although not a
requirement, this fact could be taken as a design consideration.</t>
</section>
<section title="Requirements Language and Terminology">
<t>Although this document is not a protocol specification, the key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be
interpreted as described in RFC 2119 <xref target="RFC2119"></xref>
and are to be interpreted as instructions to the protocol designers
producing solutions that satisfy the requirements set out in this
document.</t>
<t>In this document we refer to the inability of a function to perform
a required action, as a fault. This does not include an inability due
to preventive maintenance, lack of external resources, or planned
actions. See also ITU-T G.806 <xref target="G.806"></xref>.</t>
<t>In this document we refer to the situation in which the density of
anomalies has reached a level where the ability to perform a required
function has been interrupted, as a defect. See also ITU-T G.806 <xref
target="G.806"></xref>.</t>
<t>In this document we refer to OAM actions which are carried out
continuously or at least on long periods of time, permitting proactive
reporting of fault and/or performance results, as proactive OAM.</t>
<t>In this document we refer to OAM actions which are initiated via
manual intervention for a limited time to carry out troubleshooting,
as on-demand OAM.</t>
<t>In this document we refer to a Label Edge Router (LER), for a given
LSP or Section, and to a PW Terminating Provider Edge (T-PE), for a
given PW, as an End Point. Further, we refer to a Label Switching
Router (LSR), for a given LSP, and to a PW Switching Provider Edge
(S-PE), for a given PW, as an Intermediate Point. This document does
not make a distinction between End Points (e.g., source and
destination) as it can be inferred from the context of the
sentences.</t>
<t>In this document we use the term "node" as a general reference to
End Points and Intermediate Points.</t>
<t>In this document we refer to both segment and concatenated segments
as segments (see <xref target="RFC5654"></xref> for definitions
relating to the term "segment" as well as for other definitions
relating to MPLS-TP).</t>
<t>In this document we refer to both single segment PWs and
multi-segment PWs as PWs.</t>
<t>In this document we refer to both bidirectional associated LSPs and
bidirectional co-routed LSPs as bidirectional LSPs.</t>
</section>
</section>
<section title="OAM Requirements">
<t>This section lists the requirements by which the OAM functionality of
MPLS-TP should abide.</t>
<t>The requirements listed below may be met by one or more OAM
protocols; the definition or selection of these protocols is outside the
scope of this document.</t>
<t>RFC5654 <xref target="RFC5654"></xref> states (Requirement #2) that
the MPLS-TP design SHOULD as far as reasonably possible reuse existing
MPLS standards. This general requirement applies to MPLS-TP OAM. MPLS-TP
OAM is defined in this document through a set of functional
requirements. These requirements will be met by protocol solutions
defined in other documents. The way in which those protocols are
operated and the way in which a network operator can control and use the
MPLS-TP OAM functions SHOULD be as similar as possible to the mechanisms
and techniques used to operate OAM in other transport technologies.</t>
<section title="Architectural Requirements">
<section title="Scope of OAM">
<t>The protocol solution(s) developed to meet the requirements
identified in this document MUST at least be applicable to
point-to-point bidirectional PWs, point-to-point co-routed
bidirectional LSPs, and point-to-point bidirectional Sections. <xref
target="FR"></xref> provides additional information with regards to
the applicability to point-to-point associated bidirectional LSPs,
point-to-point unidirectional LSPs and point-to-multipoint LSPs.</t>
<t>The service emulated by a PW may span multiple domains. An LSP
may also span multiple domains. The protocol solution(s) MUST be
applicable end-to-end and to segments. More generally, it MUST be
possible to operate OAM functions on a per domain basis and across
multiple domains.</t>
<t>Since LSPs may be stacked, the protocol solution(s) MUST be
applicable on any LSP, regardless of the label stack depth.
Furthermore it MUST be possible to estimate OAM fault and
performance metrics of a single PW or LSP segment or of an aggregate
of PWs or LSPs segments.</t>
</section>
<section title="Independence">
<t>The protocol solution(s) SHOULD be independent of the underlying
tunnelling or point-to-point technology or transmission media.</t>
<t>The protocol solution(s) SHOULD be independent of the service a
PW may emulate.</t>
<t>Any OAM function operated on a PW, LSP or Section SHOULD be
independent of the OAM function(s) operated on a different PW, LSP
or Section. In other words, only the OAM functions operated on e.g.,
a given LSP should be used to achieve the OAM objectives for that
LSP.</t>
<t>The protocol solution(s) MUST support the capability to be
concurrently and independently operated end-to-end and on segments.
Therefore, any OAM function applied to segment(s) of a PW or LSP
SHOULD be independent of the OAM function(s) operated on the
end-to-end PW or LSP. It SHOULD also be possible to distinguish an
OAM packet running over a segment of a PW or LSP from another OAM
packet running on the end-to-end PW or LSP.</t>
<t>Furthermore, any OAM function applied to segment(s) of a PW or
LSP SHOULD be independent of the OAM function(s) applied to other
segment(s) of the same PW or LSP.</t>
<t><list style="hanging">
<t hangText="Note:">Independence should not be understood in
terms of isolation as there can be interactions between OAM
functions operated on e.g., an LSP, and on another LSP or a
PW.</t>
</list></t>
</section>
<section anchor="IPcap" title="OAM and IP Capabilities">
<t>The OAM functionality may be deployed in various
environments.<list style="symbols">
<t>In some environments (e.g., IP/MPLS environments), IP routing
and forwarding capabilities are inherently present in the data
plane.</t>
<t>In some environments (e.g., MPLS-TP environments), IP routing
and forwarding capabilities may not necessarily be present in
the data plane.</t>
</list></t>
<t>In the former case, it MUST be possible to operate the OAM
functions by relying on IP routing and forwarding capabilities
(e.g., encapsulation in IP header for (de)multiplexing purposes)
while in the latter case it MUST be possible to operate the OAM
functions without relying on IP routing and forwarding
capabilities.</t>
<t>For certain functions, OAM messages need to incorporate
identification information (e.g., of source and/or destination
nodes). The protocol solution(s) MUST at least support
identification information in the form of an IP addressing structure
and MUST also be extensible to support additional identification
schemes.</t>
</section>
<section title="Interoperability and Interworking">
<t>It is REQUIRED that OAM interoperability is achieved between
distinct domains materializing the environments described in <xref
target="IPcap"></xref>. It is also REQUIRED that the first two
requirements of <xref target="IPcap"></xref> still hold and MUST
still be met when interoperability is achieved.</t>
<t>When MPLS-TP is run with IP routing and forwarding capabilities,
it MUST be possible to operate any of the existing IP/MPLS and PW
OAM protocols (e.g., LSP-Ping <xref target="RFC4379"></xref>,
MPLS-BFD <xref target="I-D.ietf-bfd-mpls"></xref>, VCCV <xref
target="RFC5085"></xref> and VCCV-BFD <xref
target="I-D.ietf-pwe3-vccv-bfd"></xref>).</t>
</section>
<section title="Data Plane">
<t>OAM functions operate in the data plane. OAM packets MUST run
in-band; that is, OAM packets for a specific PW, LSP or Section MUST
follow the exact same data path as user traffic of that PW, LSP or
Section. This is often referred to as fate sharing.</t>
<t>It MUST be possible to discriminate user traffic from OAM
packets. This includes a means to differentiate OAM packets from
user traffic as well as the capability to apply specific treatment
to OAM packets, at the nodes processing these OAM packets.</t>
<t>As part of the design of OAM protocol solution(s) for MPLS-TP, a
mechanism, for enabling the encapsulation and differentiation of OAM
messages on a PW, LSP or Section, MUST be provided. Such mechanism
SHOULD also support the encapsulation and differentiation of
existing IP/MPLS and PW OAM messages.</t>
</section>
<section title="Configuration">
<t>OAM functions MUST operate and be configurable even in the
absence of a control plane. Conversely, it SHOULD be possible to
configure as well as enable/disable the capability to operate OAM
functions as part of connectivity management and it SHOULD also be
possible to configure as well as enable/disable the capability to
operate OAM functions after connectivity has been established.</t>
<t>In the latter case, the customer MUST NOT perceive service
degradation as a result of OAM enabling/disabling. Ideally OAM
enabling/disabling should take place without introducing any
customer impairments (e.g., no customer packet losses). Procedures
aimed to prevent any traffic impairment MUST be defined for the
enabling/disabling of OAM functions.</t>
<t>Means for configuring OAM functions and for connectivity
management are outside the scope of this document.</t>
</section>
</section>
<section anchor="FR" title="Functional Requirements">
<t>Hereafter are listed the required functionalities composing the
MPLS-TP OAM toolset. The list may not be exhaustive and as such the
OAM mechanisms developed in support of the identified requirements
SHALL be extensible and thus SHALL NOT preclude the definition of
additional OAM functionalities, in the future.</t>
<t>The design of OAM mechanisms for MPLS-TP, MUST allow for the
ability to support experimental OAM functions. These functions MUST be
disabled by default.</t>
<t>The use of any OAM function MUST be optional and it MUST be
possible to select the set of OAM function(s) to use on any PW, LSP or
Section.</t>
<t>It is RECOMMENDED that any protocol solution, meeting one or more
functional requirement(s), be the same for PWs, LSPs and Sections.</t>
<t>It is RECOMMENDED that any protocol solution, meeting one or more
functional requirement(s), effectively provides a fully featured
function; that is, a function which is applicable to all the cases
identified for that functionality. In that context, protocol
solution(s) MUST state their applicability.</t>
<t>Unless otherwise stated, the OAM functionalities MUST NOT rely on
user traffic; that is, only OAM messages MUST be used to achieve the
objectives.</t>
<t>For the on-demand OAM functions, the result of which may vary
depending on packet size, it SHOULD be possible to perform these
functions using different packet sizes.</t>
<section title="General Requirements">
<t>If a defect or fault occurs on a PW, LSP or Section, mechanisms
MUST be provided to detect it, diagnose it, localize it, and notify
the appropriate nodes. Mechanisms SHOULD exist such that corrective
actions can be taken.</t>
<t>Furthermore, mechanisms MUST be available for a service provider
to be aware of a fault or defect affecting the service(s) he
provides, even if the fault or defect is located outside of his
domain.</t>
<t>Protocol solution(s) developed to meet these requirements may
rely on information exchange. Information exchange between various
nodes involved in the operation of an OAM function SHOULD be
reliable such that, for example, defects or faults are properly
detected or that state changes are effectively known by the
appropriate nodes.</t>
</section>
<section title="Continuity Checks">
<t>The MPLS-TP OAM toolset MUST provide a function to enable an End
Point to monitor the liveness of a PW, LSP or Section.</t>
<t>This function SHOULD be performed between End Points of PWs, LSPs
and Sections.</t>
<t>This function SHOULD be performed pro-actively.</t>
<t>The protocol solution(s) developed to perform this function MUST
also apply to point-to-point associated bidirectional LSPs,
point-to-point unidirectional LSPs and point-to-multipoint LSPs.</t>
</section>
<section title="Connectivity Verifications">
<t>The MPLS-TP OAM toolset MUST provide a function to enable an End
Point to determine whether or not it is connected to specific End
Point(s) by means of the expected PW, LSP or Section.</t>
<t>This function SHOULD be performed pro-actively between End Points
of PWs, LSPs and Sections.</t>
<t>This function SHOULD be performed on-demand between End Points
and Intermediate Points of PWs and LSPs, and between End Points of
PWs, LSPs and Sections.</t>
<t>The protocol solution(s) developed to perform this function
pro-actively MUST also apply to point-to-point associated
bidirectional LSPs, point-to-point unidirectional LSPs and
point-to-multipoint LSPs.</t>
<t>The protocol solution(s) developed to perform this function
on-demand MAY also apply to point-to-point associated bidirectional
LSPs, to point-to-point unidirectional LSPs and point-to-multipoint
LSPs in case a return path exists.</t>
</section>
<section title="Route Tracing">
<t>The MPLS-TP OAM toolset MUST provide functionality to enable an
End Point to discover the Intermediate (if any) and End Point(s)
along a PW, LSP or Section, and more generally to trace the route of
a PW, LSP or Section. The information collected MUST include
identifiers related to the nodes and interfaces composing that
route.</t>
<t>This function SHOULD be performed on-demand.</t>
<t>This function SHOULD be performed between End Points and
Intermediate Points of PWs and LSPs, and between End Points of PWs,
LSPs and Sections.</t>
<t>The protocol solution(s) developed to perform this function MAY
also apply to point-to-point associated bidirectional LSPs, to
point-to-point unidirectional LSPs and point-to-multipoint LSPs in
case a return path exists.</t>
</section>
<section anchor="DT" title="Diagnostic Tests">
<t>The MPLS-TP OAM toolset MUST provide a function to enable
conducting diagnostic tests on a PW, LSP or Section. An example of
such diagnostic test consists of performing a loop-back function at
a node such that all OAM and data traffic are looped back to the
originating End Point. Another example of such diagnostic test
consists in estimating the bandwidth of e.g., an LSP.</t>
<t>This function SHOULD be performed on-demand.</t>
<t>This function SHOULD be performed between End Points and
Intermediate Points of PWs and LSPs, and between End Points of PWs,
LSPs and Sections.</t>
<t>The protocol solution(s) developed to perform this function MAY
also apply to point-to-point associated bidirectional LSPs, to
point-to-point unidirectional LSPs and point-to-multipoint LSPs in
case a return path exists.</t>
</section>
<section title="Lock Instruct">
<t>The MPLS-TP OAM toolset MUST provide functionality to enable an
End Point of a PW, LSP or Section to instruct its associated End
Point(s) to lock the PW, LSP or Section. Note that lock corresponds
to an administrative status in which it is expected that only test
traffic, if any, and OAM (dedicated to the PW, LSP or Section) can
be mapped on that PW, LSP or Section.</t>
<t>This function SHOULD be performed on-demand.</t>
<t>This function SHOULD be performed between End Points of PWs, LSPs
and Sections.</t>
<t>The protocol solution(s) developed to perform this function MUST
also apply to point-to-point associated bidirectional LSPs,
point-to-point unidirectional LSPs and point-to-multipoint LSPs.</t>
</section>
<section title="Lock Reporting">
<t>Based on the tunnelling capabilities of MPLS, there are cases
where Intermediate Point(s) of a PW or of an LSP coincide with End
Point(s) of another LSP on which the former is mapped/tunnelled.
Further, it may happen that the tunnel LSP be out of service as a
result of a lock action on that tunnel LSP. By means outside of the
scope of this document, the Intermediate Point(s) of the PW or LSP
may be aware of this condition. The MPLS-TP OAM toolset MUST provide
a function to enable an Intermediate Point of a PW or LSP to report,
to an End Point of that same PW or LSP, a lock condition indirectly
affecting that PW or LSP.</t>
<t>This function SHOULD be performed pro-actively.</t>
<t>This function SHOULD be performed between Intermediate Points and
End Points of PWs and LSPs.</t>
<t>The protocol solution(s) developed to perform this function MUST
also apply to point-to-point associated bidirectional LSPs,
point-to-point unidirectional LSPs and point-to-multipoint LSPs.</t>
</section>
<section title="Alarm Reporting">
<t>Based on the tunnelling capabilities of MPLS, there are cases
where Intermediate Point(s) of a PW or of an LSP coincide with End
Point(s) of another LSP on which the former is mapped/tunnelled.
Further, it may happen that the tunnel LSP be out of service as a
result of a fault on that tunnel LSP. By means outside of the scope
of this document, the Intermediate Point(s) of the PW or LSP may be
aware of this condition. The MPLS-TP OAM toolset MUST provide
functionality to enable an Intermediate Point of a PW or LSP to
report, to an End Point of that same PW or LSP, a fault or defect
condition indirectly affecting that PW or LSP.</t>
<t>This function SHOULD be performed pro-actively.</t>
<t>This function SHOULD be performed between Intermediate Points and
End Points of PWs and LSPs.</t>
<t>The protocol solution(s) developed to perform this function MUST
also apply to point-to-point associated bidirectional LSPs,
point-to-point unidirectional LSPs and point-to-multipoint LSPs.</t>
</section>
<section title="Remote Defect Indication">
<t>The MPLS-TP OAM toolset MUST provide a function to enable an End
Point to report, to its associated End Point, a fault or defect
condition that it detects on a PW, LSP or Section for which they are
the End Points.</t>
<t>This function SHOULD be performed pro-actively.</t>
<t>This function SHOULD be performed between End Points of PWs, LSPs
and Sections.</t>
<t>The protocol solution(s) developed to perform this function MUST
also apply to point-to-point associated bidirectional LSPs and MAY
also apply to point-to-point unidirectional LSPs and
point-to-multipoint LSPs in case a return path exists.</t>
</section>
<section title="Client Failure Indication">
<t>The MPLS-TP OAM toolset MUST provide a function to enable the
propagation, from edge to edge of an MPLS-TP network, of information
pertaining to a client (i.e., external to the MPLS-TP network)
defect or fault condition detected at an End Point of a PW or LSP,
if the client layer OAM functionality does not provide an alarm
notification/propagation functionality.</t>
<t>This function SHOULD be performed pro-actively.</t>
<t>This function SHOULD be performed between End Points of PWs and
LSPs.</t>
<t>The protocol solution(s) developed to perform this function MUST
also apply to point-to-point associated bidirectional LSPs,
point-to-point unidirectional LSPs and point-to-multipoint LSPs.</t>
</section>
<section title="Packet Loss Measurement">
<t>The MPLS-TP OAM toolset MUST provide a function to enable the
quantification of packet loss ratio over a PW, LSP or Section.</t>
<t>Note that packet loss ratio is the ratio of the user packets not
delivered to the total number of user packets transmitted during a
defined time interval. The number of user packets not delivered is
the difference between the number of user packets transmitted by an
End Point and the number of user packets received at an End Point.
See also <xref target="RFC2680"></xref>.</t>
<t>This function MAY either be performed pro-actively or
on-demand.</t>
<t>This function SHOULD be performed between End Points of PWs, LSPs
and Sections.</t>
<t>It SHOULD be possible to rely on user traffic to perform that
functionality.</t>
<t>The protocol solution(s) developed to perform this function MUST
also apply to point-to-point associated bidirectional LSPs,
point-to-point unidirectional LSPs and point-to-multipoint LSPs.</t>
</section>
<section title="Packet Delay Measurement">
<t>The MPLS-TP OAM toolset MUST provide a function to enable the
quantification of the one-way, and if appropriate, the two-way,
delay of a PW, LSP or Section.</t>
<t>Note that<list style="symbols">
<t>One-way delay is the time elapsed from the start of
transmission of the first bit of a packet by an End Point until
the reception of the last bit of that packet by the other End
Point. See also <xref target="RFC2679"></xref>.</t>
<t>Two-way delay is the time elapsed from the start of
transmission of the first bit of a packet by a End Point until
the reception of the last bit of that packet by the same End
Point. See also <xref target="RFC2681"></xref>. Two-way delay
may be quantified using data traffic loopback at the remote End
Point of the PW, LSP or Section (see <xref
target="DT"></xref>).</t>
</list></t>
<t>This function SHOULD be performed on-demand and MAY be performed
pro-actively.</t>
<t>This function SHOULD be performed between End Points of PWs, LSPs
and Sections.</t>
<t>The protocol solution(s) developed to perform this function MUST
also apply to point-to-point associated bidirectional LSPs,
point-to-point unidirectional LSPs and point-to-multipoint LSPs but
only to enable the quantification of the one-way delay.</t>
</section>
</section>
</section>
<section title="Congestion Considerations">
<t>A mechanism (e.g., rate limiting) MUST be provided to prevent OAM
packets from causing congestion in the Packet Switched Network.</t>
</section>
<section title="Security Considerations">
<t>This document, in itself, does not imply any security consideration
but OAM, as such, is subject to several security considerations. OAM
messages can reveal sensitive information such as passwords, performance
data and details about e.g., the network topology.</t>
<t>The nature of OAM therefore suggests having some form of
authentication, authorization and encryption in place. This will prevent
unauthorized access to MPLS-TP equipment and it will prevent third
parties from learning about sensitive information about the transport
network.</t>
<t>OAM systems (network management stations) SHOULD be designed such
that OAM functions cannot be accessed without authorization.</t>
<t>OAM protocol solutions MUST include the facility for OAM messages to
authenticated to prove their origin and to make sure that they are
destined for the receiving node. The use of such facilities MUST be
configurable.</t>
<t>An OAM packet received over a PW, LSP or Section MUST NOT be
forwarded beyond the End Point of that PW, LSP or Section, so as to
avoid that the OAM packet leaves the current administrative domain.</t>
</section>
<section title="IANA Considerations">
<t>There are no IANA actions required by this draft.</t>
</section>
<section title="Acknowledgements">
<t>The editors gratefully acknowledge the contributions of Matthew
Bocci, Italo Busi, Thomas Dietz, Annamaria Fulignoli, Huub van Helvoort,
Wataru Imajuku, Marc Lasserre, Lieven Levrau, Han Li, Julien Meuric,
Philippe Niger, Benjamin Niven-Jenkins, Jing Ruiquan, Nurit Sprecher,
Yuji Tochio, Satoshi Ueno and Yaacov Weingarten.</t>
<t>The authors would like to thank all members of the teams (the Joint
Working Team, the MPLS Interoperability Design Team in IETF and the
MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and
specification of MPLS-TP.</t>
</section>
<?rfc needLines="8"?>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2679"?>
<?rfc include="reference.RFC.2680"?>
<?rfc include="reference.RFC.2681"?>
<reference anchor="G.806">
<front>
<title>Characteristics of transport equipment - Description
methodology and generic functionality</title>
<author>
<organization>ITU-T Recommendation G.806</organization>
</author>
<date year="2009" />
</front>
</reference>
<?rfc include="reference.RFC.4379"?>
<?rfc include="reference.RFC.5085"?>
<?rfc include="reference.RFC.5654"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-mpls-tp-framework"?>
<reference anchor="Y.Sup4">
<front>
<title>ITU-T Y.1300-series: Supplement on transport requirements for
T-MPLS OAM and considerations for the application of IETF MPLS
technology</title>
<author>
<organization>ITU-T Supplement Y.Sup4</organization>
</author>
<date year="2008" />
</front>
</reference>
<?rfc include="reference.RFC.4377"?>
<?rfc include="reference.I-D.ietf-mpls-tp-oam-framework"?>
<?rfc include="reference.I-D.ietf-bfd-mpls"?>
<?rfc include="reference.I-D.ietf-pwe3-vccv-bfd"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 07:07:27 |