One document matched: draft-sprecher-mpls-tp-oam-analysis-01.txt
Differences from draft-sprecher-mpls-tp-oam-analysis-00.txt
Network Working Group N. Sprecher, Ed.
Internet-Draft Nokia Siemens Networks
Intended status: Informational T. Nadeau, Ed.
Expires: January 8, 2009 BT
H. van Helvoort, Ed.
Huawei Technologies Co. Ltd.
Y. Weingarten
Nokia Siemens Networks
July 07, 2008
MPLS-TP OAM Analysis
draft-sprecher-mpls-tp-oam-analysis-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 8, 2009.
Abstract
The intention of this document is to analyze the set of requirements
for OAM in MPLS-TP as defined in [MPLS-TP OAM Requirements], to
verify whether the existing MPLS OAM tools can be applied to these
requirements, identify which of the existing tools need to be
extended, and which new tools should be defined. Eventually, the
purpose of the document is to recommend which of the existing tools
should be extended and what new tools should be defined to support
Sprecher, et al. Expires January 8, 2009 [Page 1]
Internet-Draft MPLS-TP OAM Analysis July 2008
the set of OAM requirements for MPLS-TP.
Requirements Language
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 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. MPLS BFD . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. PW VCCV . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Organization of the document . . . . . . . . . . . . . . . 6
2. Architectural requirements and general principles of
operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Recommendations and Guidelines . . . . . . . . . . . . . . 8
3. MPLS-TP OAM Functions . . . . . . . . . . . . . . . . . . . . 9
3.1. Continuity Check . . . . . . . . . . . . . . . . . . . . . 9
3.1.1. Existing tools . . . . . . . . . . . . . . . . . . . . 9
3.1.2. Gaps . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.3. Recommendations and Guidelines . . . . . . . . . . . . 10
3.2. Connectivity Verification . . . . . . . . . . . . . . . . 10
3.2.1. Existing tools . . . . . . . . . . . . . . . . . . . . 10
3.2.2. Gaps . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.3. Recommendations and Guidelines . . . . . . . . . . . . 10
3.3. Alarm Suppression . . . . . . . . . . . . . . . . . . . . 11
3.3.1. Existing tools . . . . . . . . . . . . . . . . . . . . 11
3.3.2. Recommendations and Guidelines . . . . . . . . . . . . 11
3.4. Lock Indication . . . . . . . . . . . . . . . . . . . . . 11
3.4.1. Existing tools . . . . . . . . . . . . . . . . . . . . 11
3.4.2. Recommendations and Guidelines . . . . . . . . . . . . 11
3.5. Packet Loss Measurement . . . . . . . . . . . . . . . . . 11
3.5.1. Existing tools . . . . . . . . . . . . . . . . . . . . 11
3.5.2. Recommendations and Guidelines . . . . . . . . . . . . 11
3.6. Diagnostic Test . . . . . . . . . . . . . . . . . . . . . 12
3.6.1. Existing tools . . . . . . . . . . . . . . . . . . . . 12
3.6.2. Recommendations and Guidelines . . . . . . . . . . . . 12
3.7. Trace Route . . . . . . . . . . . . . . . . . . . . . . . 12
3.7.1. Existing tools . . . . . . . . . . . . . . . . . . . . 12
3.7.2. Recommendations and Guidelines . . . . . . . . . . . . 12
3.8. Delay Measurement . . . . . . . . . . . . . . . . . . . . 12
3.8.1. Existing tools . . . . . . . . . . . . . . . . . . . . 13
3.8.2. Recommendations and Guidelines . . . . . . . . . . . . 13
3.9. Remote Defect Indication . . . . . . . . . . . . . . . . . 13
3.9.1. Existing tools . . . . . . . . . . . . . . . . . . . . 13
Sprecher, et al. Expires January 8, 2009 [Page 2]
Internet-Draft MPLS-TP OAM Analysis July 2008
3.9.2. Recommendations and Guidelines . . . . . . . . . . . . 13
3.10. Client Signal Fail . . . . . . . . . . . . . . . . . . . . 13
3.10.1. Existing tools . . . . . . . . . . . . . . . . . . . . 13
3.10.2. Recommendations and Guidelines . . . . . . . . . . . . 13
4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
8. Informative References . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Sprecher, et al. Expires January 8, 2009 [Page 3]
Internet-Draft MPLS-TP OAM Analysis July 2008
1. Introduction
OAM (Operations, Administration, and Maintenance) plays a significant
and fundamental role in carrier networks, providing methods for fault
management and performance monitoring in both the transport and the
service layers on order to improve their ability to support services
with guaranteed and strict SLAs while reducing their operational
costs.
[MPLS-TP Requirements] in general and [MPLS-TP OAM Requirements] in
particular define a set of requirements on OAM functionality in
MPLS-TP for MPLS-TP LSPs (network infrastructure) and PWs (services).
The purpose of this document is to analyze the OAM requirements and
verify whether the existing OAM tools defined for MPLS can be used to
fulfill the requirements, identify which tools need to be extended to
comply with the requirements, and which new tools need to be defined.
The existing tools that are evaluated include LSP Ping (defined in
[LSP Ping]), MPLS BFD (defined in [ MPLS BFD ]) and Virtual Circuit
Connectivity Verification (defined in [PW VCCV] and [VCCV BFD]).
1.1. LSP Ping
LSP Ping is a variation of ICMP Ping and Traceroute [ICMP] that is
adapted to MPLS LSP. Addressing is based upon the LSP Label and
label stack in order to guarantee that the echo messages are switched
in-band of the LSP. The messages are transmitted using IP/UDP
encapsulation and IP addresses in the 127/8 (loopback) range. The
use of the loopback range guarantees that the LSP Ping messages will
not be transmitted outside the LSP.
LSP Ping extends the basic ICMP Ping operation (of data-plane
connectivity and continuity check) with functionality to verify data-
plane vs. control-plane consistency for a FEC and also MTU problems.
The traceroute functionality is used to isolate and localize the MPLS
faults, using the TTL to incrementally verify the path. While LSP
Ping is dependent upon the label propogation that may be performed
over the control-plane via LDP, there is no direct dependence of LSP
Ping on the control-plane.
LSP Ping can be activated both in on-demand and pro-active
(asynchronous) modes.
[P2MP LSP Ping] clarifies the applicability of LSP Ping to MPLS P2MP
LSPs, and extends the techniques and mechanisms of LSP Ping to the
MPLS P2MP environment.
[LSP Ping over MPLS Tunnels] extends LSP Ping to operate over MPLS
Sprecher, et al. Expires January 8, 2009 [Page 4]
Internet-Draft MPLS-TP OAM Analysis July 2008
tunnels or for a stitched LSP.
TTL exhaust is the method for terminating flows at intermediate LSRs.
LSP Ping is considered to be computational intensive. In cases of
LSP bundling, there is no guarantee the LSP Ping packets follow the
same path as the data traffic.
1.2. MPLS BFD
BFD (Bidirectional Forwarding Detection) is a mechanism that is
defined for fast fault detection. BFD defines a simple packet that
may be transmitted over any protocol, dependent on the application
that is employing the mechanism. BFD is dependent upon creation of a
session that is agreed upon by both ends of the link (which may be a
single link, LSP, etc.) that is being checked. In addition to the
control packets that BFD defines, BFD supports an echo function to
check the continuity, and verify the reachability of the desired
destination. BFD does not support a discovery mechanism nor support
a traceroute capability for fault localization, these must be
provided by use of other mechanisms. The BFD packets support
authentication between the routers being checked.
[MPLS BFD] defines the use of BFD for P2P LSP end-points and is used
to verify data-plane connectivity and to check continuity. It uses a
simple hello protocol which can be easily implemented in hardware.
The end-points of the LSP exchange hello packets at negotiated
regular intervals and an end-point is declared down when expected
hello packets do not show up. Failures in each direction can
independently be monitored using the same BFD session. The use of
the BFD echo function is outside the scope of the MPLS BFD
specification.
There is a need for a mechanism to bootstrap a BFD session and LSP
Ping is designated by [MPLS BFD] to bootstrap the BFD session in an
MPLS environment. The session BFD messages for MPLS are transmitted
using a IP/UDP encapsulation.
BFD can work in pro-active (asynchronous) and on-demand modes of
operation.
1.3. PW VCCV
PW VCCV provides end-to-end fault detection and diagnostics for PWs
(regardless of the underlying tunneling technology). The VCCV
switching function provides a control channel associated with each PW
(based on the PW Associated Channel Header which is defined in [PW-
ACH], and allows sending OAM packets in-band with PW data (using CC
Sprecher, et al. Expires January 8, 2009 [Page 5]
Internet-Draft MPLS-TP OAM Analysis July 2008
Type 1: In-band VCCV)
VCCV supports the following OAM mechanisms: ICMP Ping, LSP Ping and
BFD. ICMP and LSP Ping are IP encapsulated before being sent over
the PW ACH. BFD for VCCV supports two modes of encapsulation -
either IP/UDP encapsulated (with IP/UDP header) or PW-ACH
encapsulated (with no IP/UDP header) and provides support to signal
the AC status.. The use of the VCCV control channel provides the
context required to bind and bootstrap the BFD session to a
particular pseudo wire (FEC).
VCCV consists of two components: (1) signaled component to
communicate VCCV capabilities as part of VC label, and (2) switching
component to cause the PW payload to be treated as a control packet.
VCCV is not directly dependent upon the presence of a control plane.
The VCCV capability negotiation may be performed as part of the PW
signaling when LDP is used. In case of manual configuration of the
PW, it is the responsibility of the operator to set consistent
options at both ends.
Note: There is a need to prevent confusion between the Connectivity
Verification function defined in [MPLS-TP OAM Requirements], and the
ACH's CV type defined in [PW VCCV], that identifies the protocol that
is being used over the control channel.
1.4. Organization of the document
The analysis of the architectural requirements and the general
principles of operations are discussed first and then the
requirements on the set of OAM functions.
Eventually, the purpose of the document is to recommend which of the
existing tools should be extended and what new tools should be
defined to support the set of OAM requirements in MPLS-TP.
2. Architectural requirements and general principles of operation
[MPLS-TP OAM Requirements] defines a set of requirements on OAM
architecture and general principles of operations which are evaluated
below:
o [MPLS-TP OAM Requirements] requires that OAM mechanisms in MPLS-TP
are independent of the transmission media and of the client
service being emulated by the PW. The existing tools comply with
this requirement.
Sprecher, et al. Expires January 8, 2009 [Page 6]
Internet-Draft MPLS-TP OAM Analysis July 2008
o [MPLS-TP OAM Requirements] requires that MPLS-TP OAM MUST be able
to operate without IP functionality and without relying on control
and/or management planes. It is required that OAM functionality
MUST NOT be dependent on IP routing and forwarding capabilities.
The existing tools do not rely on control and/or management plane,
however the following should be observed regarding the reliance on
IP functionality:
* LSP Ping, VCCV Ping, and MPLS BFD makes use of IP header
(UDP/IP) and do not comply with the requirement. In the on-
demand mode they also use IP forwarding to reply back to the
source router. This dependence on IP, has further implications
concerning the use of LSP Ping as the bootstrap mechanism for
BFD for MPLS.
* VCCV BFD supports the use of PW-ACH encapsulated BFD sessions
for PWs and can comply with the requirement.
o [MPLS-TP OAM Requirements] requires that OAM tools for fault
management do not rely on user traffic, and the existing MPLS OAM
tools already comply with this requirement. It is also required
that OAM packets and the user traffic are congruent (i.e. OAM
packets are transmitted in-band) ad there is a need to
differentiate OAM packets from user-plane ones.
* For PWs, VCCV provides a control channel associated with each
PW which allows sending OAM packets in band of PWs and allow
the receiving end-point to intercept, interpret, and process
them locally as OAM messages. VCCV defines different VCCV
Connectivity Verification Types for MPLS (like ICMP Ping, LSP
Ping and IP/UD encapsulated BFD and PW-ACH encapsulated BFD).
* Currently there is no distinct OAM payload identifier in MPLS
shim. BFD and LSP Ping packets for LSPs are carried over
UDP/IP and are addressed to the loopback address range. The
router at the end-point intercepts, interprets, and processes
the packets.
o [MPLS-TP OAM Requirements] requires that the MPLS-TP OAM mechanism
allows the propagation of AC (Attachment Circuit) failures and
their clearance across a MPLS-TP domain
* BFD for VCCV supports a mechanism for "Fault detection and
AC/PW Fault status signaling." This can be used for both IP/
UDP encapsulated or PW-ACH encapsulated BFD sessions, i.e. by
setting the appropriate VCCV Connectivity Verification
Type.This mechanism could support this requirement.
Sprecher, et al. Expires January 8, 2009 [Page 7]
Internet-Draft MPLS-TP OAM Analysis July 2008
o [MPLS-TP OAM Requirements] defines Maintenance Domain, Maintenance
End Points (MEPs) and Maintenance Intermediate Points (MIPs).
Means should be defined to provision these entities, both by
static configuration (as it is required to operate OAM in the
absence of any control plane or dynamic protocols) and by a
control plane.
o [MPLS-TP OAM Requirements] requires a single OAM technology and
consistent OAM capabilities for LSPs, PWs and Tandem Connections.
There is currently no mechanism in the IETF to support OAM for
Tandem Connections. Also, the existing set of tools defines a
different way of operating the OAM functions (e.g. LSP Ping to
bootstrap MPLS BFD vs. VCCV) and provide incomplete coverage of
OAM capabilities that are defined by [MPLS-TP OAM Requirements].
o [MPLS-TP OAM Requirements] requires allowing OAM packets to be
directed to an intermediate node on a LSP/PW. Technically this
can be supported by the proper setting of the TTL value, but needs
to be examined per OAM function. For details, see below.
o [MPLS-TP OAM Requirements] suggests that OAM messages MAY be
authenticated. BFD has a support for authentication. Other tools
should support this capability as well.
2.1. Recommendations and Guidelines
Based on the requirements analysis above, the following guidelines
should be followed to create an OAM environment that could more fully
comply with the requirements cited:
o Extend the PW Associate Channel Header (ACH) to provide a control
channel at the path level. This could then be associated with a
LSP or a Tandem Connection (TC). The ACH should then become a
common mechanism for PW, LSP, and Tandem Connection.
o Create a VPCV (Virtual Path Connectivity Verification) definition
that would apply the definitions and functionality of VCCV to the
MPLS-TP environment for LSP or Tandem Connection.
o Create or extend the VCCV definition to define a mechanism that
would apply the definitions and functionalityof VCCV to PW Tandem
Connections
o Apply BFD to this new mechanism using the control channel
encapsulation, as defined above - allowing use of BFD for MPLS-TP
independent of IP routing.
Sprecher, et al. Expires January 8, 2009 [Page 8]
Internet-Draft MPLS-TP OAM Analysis July 2008
o A mechanism that be defined to create TCME and allow transmission
of the traffic via the Tandem Connection using label stacking.
Creating these extensions/mechanisms would fulfil the following
requirements, mentioned above:
o Independence of IP forwarding and routing.
o OAM packets should be transmitted in-band.
o Support a single OAM technology for LSP, PW, and TC.
In addition, the following additional requirements are satisfied:
o Provide the ability to carry other types of communications (e.g.,
APS, Management Control Channel (MCC), Signalling Control Channel
(SCC)). New types of communication channels and CV can be defined
for both PWs and LSPs.
o The design of the OAM mechanisms for MPLS-TP MUST allow the
ability to support vendor specific and experimental OAM functions.
3. MPLS-TP OAM Functions
The following sections discuss the required OAM functions that were
identified in [MPLS-TP OAM Requirements].
LSP Ping is not considered a candidate to fulfill the required
functionality, due its failure to comply with the basic requirement
of independence from IP routing and forwarding, as documented in the
Section 4 of this document. However, usage of LSP Ping, in addition
to the MPLS-TP OAM tools, or in MPLS-TP deployments with IP
functionality is not precluded.
3.1. Continuity Check
Continuity Check (CC) is used to detect loss of continuity between
MEPs and is useful for applications like Fault Management,
Performance Monitoring and Protection Switching, etc.
3.1.1. Existing tools
BFD can be used to support the pro-active OAM Continuity Check
function. It can be operated in the asynchronous mode. However, the
current definition is dependent on LSP Ping to bootstrap the BFD
session.
Sprecher, et al. Expires January 8, 2009 [Page 9]
Internet-Draft MPLS-TP OAM Analysis July 2008
VCCV can be used to carry BFD packets that are not IP/UDP
encapsulated for CC on a PW.
3.1.2. Gaps
The following gaps are identified for support of CC in MPLS-TP
environment:
o A mechanism should be defined to bootstrap BFD sessions for MPLS
that is not dependent on UDP.
o Need extensions to BFD to cover P2MP connections.
3.1.3. Recommendations and Guidelines
Extend BFD to resolve the gaps.
Note that [MP BFD] defines a method for using BFD to provide
verification of multipoint or multicast connectivity.
3.2. Connectivity Verification
Connectivity Verification is a function that is used to check
connectivity between MEPs in a maintenance domain. This function may
be activated on-demand in reaction to a fault discovered in CC or for
more thorough testing of the connections.
3.2.1. Existing tools
MPLS BFD supports OAM Connectivity Verification and it can be
operated in both pro-active and on-demand modes.
3.2.2. Gaps
The following gaps are identified:
o A mechanism should be defined to bootstrap BFD sessions
o BFD supports verification MEP to MEP only.
3.2.3. Recommendations and Guidelines
As BFD works on a session basis, it seems complicated to extend it to
work also between MEP and MIP. It is recommended to define a new
simpler tool to support Connectivity Verification.
Sprecher, et al. Expires January 8, 2009 [Page 10]
Internet-Draft MPLS-TP OAM Analysis July 2008
3.3. Alarm Suppression
Alarm Suppression is a function that is used by a server layer MEP to
notify a failure condition to its client layer MEP(s) in order to
suppress alarms that may be generated by maintenance domains of the
client layer as a result of the failure condition in the server
layer.
3.3.1. Existing tools
There is no mechanism defined in the IETF to support this function.
3.3.2. Recommendations and Guidelines
Define a tool to support Alarm Suppression.
3.4. Lock Indication
Lock Indication is a function that is used by a server layer MEP to
indicate an administrative locking of a server layer which may result
in consequential interruption of data traffic forwarding towards the
client layer MEP(s) expecting this traffic. The reception of a Lock
Indication allows a MEP to suppress alarms and to differentiate
between a defect condition and an administrative locking action at
the server layer MEP.
3.4.1. Existing tools
There is no mechanism defined in the IETF to support this function.
3.4.2. Recommendations and Guidelines
Define a tool to support Lock Indication.
3.5. Packet Loss Measurement
Packet Loss Measurement is a function that is used to verify the
quality of the service.
3.5.1. Existing tools
There is no mechanism defined in the IETF to support this function.
3.5.2. Recommendations and Guidelines
Define a tool to support Packet Loss Measurement.
Sprecher, et al. Expires January 8, 2009 [Page 11]
Internet-Draft MPLS-TP OAM Analysis July 2008
3.6. Diagnostic Test
A diagnostic test is a function that is used between MEPs to verify
bandwidth throughput, packet loss, bit errors, etc.
3.6.1. Existing tools
There is no mechanism defined in the IETF to support this function.
3.6.2. Recommendations and Guidelines
Define a tool to support Diagnostic Test.
3.7. Trace Route
Trace route is a function that is used to determine the route of a
connection across the MPLS transport network.
3.7.1. Existing tools
LSP Ping supports trace route but as it does not comply with the
requirement for OAM functions to be independent on IP routing and
forwarding capabilities, it can not be utilized for MPLS-TP
3.7.2. Recommendations and Guidelines
Define a new tool to support Trace Route.
3.8. Delay Measurement
Delay Measurement is a function that is used to measure one-way or
two-way delay of a packet transmission between a pair of MEPs.
Where:
o One-way packet delay is the time elapsed from the start of
transmission of the first bit of the packet by a source node until
the reception of the first bit of that packet by the destination
node.
o Two-way packet delay is the time elapsed from the start of
transmission of the first bit of the packet by a source node until
the reception of the last bit of the loop-backed packet by the
same source node, when the loopback is performed at the packet's
destination node.
Sprecher, et al. Expires January 8, 2009 [Page 12]
Internet-Draft MPLS-TP OAM Analysis July 2008
3.8.1. Existing tools
There is no mechanism defined in the IETF that fulfills all of the
MPLS-TP OAM requirements.
3.8.2. Recommendations and Guidelines
Define a tool to support Delay Measurement.
3.9. Remote Defect Indication
Remote Defect Indication (RDI) is used by a MEP to notify its peer
MEP that a defect is detected on a bi-directional connection between
them.
This function should be supported in pro-active mode.
3.9.1. Existing tools
There is no mechanism defined in the IETF to fully support this
functionality, however BFD supports a mechanism of informing the far-
end that the session has gone down, and the Diagnostic field
indicates the reason.
3.9.2. Recommendations and Guidelines
Either create a dedicated mechanism for this functionality or extend
the BFD session functionality to support the functionality without
disrupting the CC or CV functionality.
3.10. Client Signal Fail
Client Signal Fail function (CSF) is used to propagate a Client
Failure indication to the far-end sink when alarm suppression in the
client layer is not supported.
3.10.1. Existing tools
There is no mechanism defined in the IETF to support this function.
3.10.2. Recommendations and Guidelines
Define a tool to support Client Signal Fail propogation.
4. Recommendation
Sprecher, et al. Expires January 8, 2009 [Page 13]
Internet-Draft MPLS-TP OAM Analysis July 2008
o Define a Tandem Connection entity for both LSPs and PWs and allow
the transmission of traffic by means of label stacking and proper
TTL setting.
o Extend the ACH to provide a control channel for MPLS Sections,
LSPs, and Tandem Connections.
o Define a VPCV mechanism for LSP and Tandem Connection. This
mechanism should reuse, as much as possible, the same principles
of operation as VCCV. The ACH should be extended to support CV
types for each of the tool that are defined below, in a way that
is consistent for PW, LSP and Tandem Connection.
o Extend the control and the management planes to support the
configuration of the OAM maintenance entities and the set of
functions to be supported by these entities.
o The appropriate assignement of network-wide unique identifiers
needed to support connectivity verification should be considered.
o Tools should be defined to support the following functions:
* Connectivity verification
* Alarm suppression
* Lock indication
* Packet loss measurement
* Diagnostic test
* Trace-route
* Delay measurement
* Remote defect indication
* Client signal fail
o The tools may have the capability to authenticate the messages.
Notes:
1. We may consider having a document to define common CC and CV
types of ACH for the use of VCCV and VPCV.
Sprecher, et al. Expires January 8, 2009 [Page 14]
Internet-Draft MPLS-TP OAM Analysis July 2008
2. We may consider changing the name of the ACH "CV Type" to
"Protocol Type" in order to avoid confusion with the CV function
that is defined in [MPLS-TP OAM Requirements]
5. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
6. Security Considerations
This document does not by itself raise any particular security
considerations.
7. Acknowledgements
The authors wish to thank xxxxxxx for his review and proposed
enhancements to the text.
8. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[LSP Ping]
Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[PW ACH] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006.
[PW VCCV] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007.
[MP BFD] Katz, D. and D. Ward, "BFD for Multipoint Networks",
ID draft-katz-ward-bfd-multipoint-01.txt, December 2007.
[VCCV BFD]
Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
Sprecher, et al. Expires January 8, 2009 [Page 15]
Internet-Draft MPLS-TP OAM Analysis July 2008
Detection (BFD) for the Pseudowire Virtual Circuit
Connectivity Verification (VCCV)",
ID draft-ietf-pwe3-vccv-bfd-01.txt, February 2008.
[P2MP LSP Ping]
Nadeau, T. and A. Farrel, "Detecting Data Plane Failures
in Point-to-Multipoint Multiprotocol Label Switching
(MPLS) - Extensions to LSP Ping",
ID draft-ietf-mpls-p2mp-lsp-ping-06.txt, June 2008.
[MPLS LSP Ping]
Bahadur, N. and K. Kompella, "Mechanism for performing
LSP-Ping over MPLS tunnels",
ID draft-ietf-mpls-lsp-ping-enhanced-dsmap-00, June 2008.
[MPLS-TP OAM Requirements]
Vigoreux, M., Betts, M., and D. Ward, "Requirements for
OAM in MPLS Transport Networks",
ID draft-vigoreux-mpls-tp-oam-requirements-00, July 2008.
[MPLS-TP Requirments]
Nadeau, T. and C. Pignataro, "Requirements for the
Trasport Profile of MPLS",
ID draft-jenkins-mpls-mplstp-requirements-00, July 2008.
Authors' Addresses
Nurit Sprecher (editor)
Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241
Israel
Phone: +972 9 775-1229
Email: nurit.sprecher@nsn.com
Tom Nadeau (editor)
BT
United State
Email: tom.nadeau@bt.com
Sprecher, et al. Expires January 8, 2009 [Page 16]
Internet-Draft MPLS-TP OAM Analysis July 2008
Huub van Helvoort (editor)
Huawei Technologies Co. Ltd.
Kolkgriend 38, 1356 BC Almere
The Netherlands
Phone: +31 36 5316076
Email: hhelvoort@huawei.com
Yaacov Weingarten
Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241
Israel
Phone: +972 9 775-1827
Email: yaacov.weingarten@nsn.com
Sprecher, et al. Expires January 8, 2009 [Page 17]
Internet-Draft MPLS-TP OAM Analysis July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Sprecher, et al. Expires January 8, 2009 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-23 06:02:20 |