CCAMP Working Group E. Bellagamba, Ed.
CCAMP Working Group E. Bellagamba, Ed.
Internet-Draft L. Andersson, Ed.
Internet-Draft L. Andersson, Ed.
Intended status: Standards Track Ericsson
Intended status: Standards Track Ericsson
Expires: April 14, 2013 P. Skoldstrom, Ed.
Expires: April 14, 2013 P. Skoldstrom, Ed.
Acreo AB
Acreo AB
D. Ward
D. Ward
Juniper
Juniper
A. Takacs
A. Takacs
Ericsson
Ericsson
October 11, 2012
October 11, 2012
Configuration of Pro-Active Operations, Administration, and Maintenance
Configuration of Pro-Active Operations, Administration, and Maintenance
(OAM) Functions for MPLS-based Transport Networks using RSVP-TE
(OAM) Functions for MPLS-based Transport Networks using RSVP-TE
draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-10
draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-11
Abstract
Abstract
This specification describes the configuration of pro-active MPLS-TP
This specification describes the configuration of pro-active MPLS-TP
Operations, Administration, and Maintenance (OAM) Functions for a
Operations, Administration, and Maintenance (OAM) Functions for a
given LSP using a set of TLVs that are carried by the RSVP-TE
given LSP using a set of TLVs that are carried by the RSVP-TE
protocol.
protocol.
This document is a product of a joint Internet Engineering Task Force
This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication
(IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network.
capabilities and functionalities of a packet transport network.
Status of this Memo
Status of this Memo
This Internet-Draft is submitted in full conformance with the
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 14, 2013.
This Internet-Draft will expire on April 14, 2013.
Copyright Notice
Copyright Notice
Bellagamba, et al. Expires April 14, 2013 [Page 1]
Bellagamba, et al. Expires April 14, 2013 [Page 1]
Internet-Draft Extensions for MPLS-TP OAM Conf October 2012
Internet-Draft Extensions for MPLS-TP OAM Conf October 2012
Copyright (c) 2012 IETF Trust and the persons identified as the
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 4
1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Overview of MPLS OAM for Transport Applications . . . . . . . 4
2. Overview of MPLS OAM for Transport Applications . . . . . . . 4
3. Theory of Operations . . . . . . . . . . . . . . . . . . . . . 5
3. Theory of Operations . . . . . . . . . . . . . . . . . . . . . 5
3.1. MPLS OAM Configuration Operation Overview . . . . . . . . 5
3.1. MPLS OAM Configuration Operation Overview . . . . . . . . 5
3.1.1. Configuration of BFD sessions . . . . . . . . . . . . 5
3.1.1. Configuration of BFD sessions . . . . . . . . . . . . 5
3.1.2. Configuration of Performance Monitoring . . . . . . . 6
3.1.2. Configuration of Performance Monitoring . . . . . . . 6
3.1.3. Configuration of Fault Management Signals . . . . . . 7
3.1.3. Configuration of Fault Management Signals . . . . . . 7
3.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 7
3.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 7
3.3. BFD Configuration sub-TLV . . . . . . . . . . . . . . . . 9
3.3. BFD Configuration sub-TLV . . . . . . . . . . . . . . . . 9
3.3.1. Local Discriminator sub-TLV . . . . . . . . . . . . . 11
3.3.1. Local Discriminator sub-TLV . . . . . . . . . . . . . 11
3.3.2. Negotiation Timer Parameters sub-TLV . . . . . . . . . 11
3.3.2. Negotiation Timer Parameters sub-TLV . . . . . . . . . 11
3.3.3. BFD Authentication sub-TLV . . . . . . . . . . . . . . 13
3.3.3. BFD Authentication sub-TLV . . . . . . . . . . . . . . 13
3.4. Performance Monitoring sub-TLV . . . . . . . . . . . . . . 13
3.4. Performance Monitoring sub-TLV . . . . . . . . . . . . . . 13
3.4.1. MPLS OAM PM Loss sub-TLV . . . . . . . . . . . . . . . 14
3.4.1. MPLS OAM PM Loss sub-TLV . . . . . . . . . . . . . . . 14
3.4.2. MPLS OAM PM Delay sub-TLV . . . . . . . . . . . . . . 16
3.4.2. MPLS OAM PM Delay sub-TLV . . . . . . . . . . . . . . 16
3.5. MPLS OAM FMS sub-TLV . . . . . . . . . . . . . . . . . . . 17
3.5. MPLS OAM FMS sub-TLV . . . . . . . . . . . . . . . . . . . 17
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
5. BFD OAM configuration errors . . . . . . . . . . . . . . . . . 18
5. BFD OAM configuration errors . . . . . . . . . . . . . . . . . 18
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Bellagamba, et al. Expires April 14, 2013 [Page 2]
Bellagamba, et al. Expires April 14, 2013 [Page 2]
Internet-Draft Extensions for MPLS-TP OAM Conf October 2012
Internet-Draft Extensions for MPLS-TP OAM Conf October 2012
1. Introduction
1. Introduction
This document describes the configuration of pro-active MPLS-TP
This document describes the configuration of pro-active MPLS-TP
Operations, Administration, and Maintenance (OAM) Functions for a
Operations, Administration, and Maintenance (OAM) Functions for a
given LSP using TLVs carried by RSVP-TE [RFC3209]. In particular it
given LSP using TLVs carried by RSVP-TE [RFC3209]. In particular it
specifies the mechanisms necessary to establish MPLS-TP OAM entities
specifies the mechanisms necessary to establish MPLS-TP OAM entities
at the maintenance points for monitoring and performing measurements
at the maintenance points for monitoring and performing measurements
on an LSP, as well as defining information elements and procedures to
on an LSP, as well as defining information elements and procedures to
configure pro-active MPLS OAM functions running between LERs.
configure pro-active MPLS OAM functions running between LERs.
Initialization and control of on-demand MPLS OAM functions are
Initialization and control of on-demand MPLS OAM functions are
expected to be carried out by directly accessing network nodes via a
expected to be carried out by directly accessing network nodes via a
management interface; hence configuration and control of on-demand
management interface; hence configuration and control of on-demand
OAM functions are out-of-scope for this document.
OAM functions are out-of-scope for this document.
The Transport Profile of MPLS must, by definition [RFC5654], be
The Transport Profile of MPLS must, by definition [RFC5654], be
capable of operating without a control plane. Therefore there are
capable of operating without a control plane. Therefore there are
several options for configuring MPLS-TP OAM, without a control plane
several options for configuring MPLS-TP OAM, without a control plane
by either using an NMS or LSP Ping, or with a control plane using
by either using an NMS or LSP Ping, or with a control plane using
signaling protocols RSVP-TE and/or T-LDP. Use of T-LDP for
signaling protocols RSVP-TE and/or T-LDP. Use of T-LDP for
configuration of MPLS-TP OAM is outside of scope of this document.
configuration of MPLS-TP OAM is outside of scope of this document.
Pro-active MPLS OAM is performed by three different protocols,
Pro-active MPLS OAM is performed by three different protocols,
Bidirectional Forwarding Detection (BFD) [RFC6428] for Continuity
Bidirectional Forwarding Detection (BFD) [RFC6428] for Continuity
Check/Connectivity Verification, the delay measurement protocol (DM)
Check/Connectivity Verification, the delay measurement protocol (DM)
[RFC6374] for delay and delay variation (jitter) measurements, and
[RFC6374] for delay and delay variation (jitter) measurements, and
the loss measurement protocol (LM) [RFC6374] for packet loss and
the loss measurement protocol (LM) [RFC6374] for packet loss and
throughput measurements. Additionally there is a number of Fault
throughput measurements. Additionally there is a number of Fault
Management Signals that can be configured.
Management Signals that can be configured.
BFD is a protocol that provides low-overhead, fast detection of
BFD is a protocol that provides low-overhead, fast detection of
failures in the path between two forwarding engines, including the
failures in the path between two forwarding engines, including the
interfaces, data link(s), and to the extent possible the forwarding
interfaces, data link(s), and to the extent possible the forwarding
engines themselves. BFD can be used to track the liveliness and
engines themselves. BFD can be used to track the liveliness and
detect data plane failures of MPLS-TP point-to-point and might also
detect data plane failures of MPLS-TP point-to-point and might also
be extended to support point-to-multipoint connections.
be extended to support point-to-multipoint connections.
The delay and loss measurements protocols [RFC6374] use a simple
The delay and loss measurements protocols [RFC6374] use a simple
query/response model for performing bidirectional measurements that
query/response model for performing bidirectional measurements that
allows the originating node to measure packet loss and delay in both
allows the originating node to measure packet loss and delay in both
directions. By timestamping and/or writing current packet counters
directions. By timestamping and/or writing current packet counters
to the measurement packets at four times (Tx and Rx in both
to the measurement packets at four times (Tx and Rx in both
directions) current delays and packet losses can be calculated. By
directions) current delays and packet losses can be calculated. By
performing successive delay measurements the delay variation (jitter)
performing successive delay measurements the delay variation (jitter)
can be calculated. Current throughput can be calculated from the
can be calculated. Current throughput can be calculated from the
packet loss measurements by dividing the number of packets sent/
packet loss measurements by dividing the number of packets sent/
received with the time it took to perform the measurement, given by
received with the time it took to perform the measurement, given by
the timestamp in LM header. Combined with a packet generator the
the timestamp in LM header. Combined with a packet generator the
throughput measurement can be used to measure the maximum capacity of
throughput measurement can be used to measure the maximum capacity of
Bellagamba, et al. Expires April 14, 2013 [Page 3]
Bellagamba, et al. Expires April 14, 2013 [Page 3]
Internet-Draft Extensions for MPLS-TP OAM Conf October 2012
Internet-Draft Extensions for MPLS-TP OAM Conf October 2012
a particular LSP.
a particular LSP.
MPLS Transport Profile (MPLS-TP) describes a profile of MPLS that
MPLS Transport Profile (MPLS-TP) describes a profile of MPLS that
enables operational models typical in transport networks, while
enables operational models typical in transport networks, while
providing additional OAM, survivability and other maintenance
providing additional OAM, survivability and other maintenance
functions not currently supported by MPLS. [RFC5860] defines the
functions not currently supported by MPLS. [RFC5860] defines the
requirements for the OAM functionality of MPLS-TP.
requirements for the OAM functionality of MPLS-TP.
This document is a product of a joint Internet Engineering Task Force
This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication
(IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network.
capabilities and functionalities of a packet transport network.
1.1. Contributing Authors
1.1. Contributing Authors
This document is the result of a large team of authors and
This document is the result of a large team of authors and
contributors. The following is a list of the co-authors:
contributors. The following is a list of the co-authors:
Gregory Mirsky
Gregory Mirsky
John Drake
John Drake
Benoit Tremblay
Benoit Tremblay
1.2. Requirements Language
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Overview of MPLS OAM for Transport Applications
2. Overview of MPLS OAM for Transport Applications
[MPLS-TP-OAM-FWK] describes how MPLS OAM mechanisms are operated to
[MPLS-TP-OAM-FWK] describes how MPLS OAM mechanisms are operated to
meet transport requirements outlined in [RFC5860].
meet transport requirements outlined in [RFC5860].
[BFD-CCCV] specifies two BFD operation modes: 1) "CC mode", which
[BFD-CCCV] specifies two BFD operation modes: 1) "CC mode", which
uses periodic BFD message exchanges with symmetric timer settings,
uses periodic BFD message exchanges with symmetric timer settings,
supporting Continuity Check, 2) "CV/CC mode" which sends unique
supporting Continuity Check, 2) "CV/CC mode" which sends unique
maintenance entity identifiers in the periodic BFD messages
maintenance entity identifiers in the periodic BFD messages
supporting Connectivity Verification as well as Continuity Check.
supporting Connectivity Verification as well as Continuity Check.
[RFC6374] specifies mechanisms for performance monitoring of LSPs, in
[RFC6374] specifies mechanisms for performance monitoring of LSPs, in
particular it specifies loss and delay measurement OAM functions.
particular it specifies loss and delay measurement OAM functions.
[MPLS-FMS] specifies fault management signals with which a server LSP
[MPLS-FMS] specifies fault management signals with which a server LSP
can notify client LSPs about various fault conditions to suppress
can notify client LSPs about various fault conditions to suppress
Bellagamba, et al. Expires April 14, 2013 [Page 4]
Bellagamba, et al. Expires April 14, 2013 [Page 4]
Internet-Draft Extensions for MPLS-TP OAM Conf October 2012
Internet-Draft Extensions for MPLS-TP OAM Conf October 2012
alarms or to be used as triggers for actions in the client LSPs. The
alarms or to be used as triggers for actions in the client LSPs. The
following signals are defined: Alarm Indication Signal (AIS), Link
following signals are defined: Alarm Indication Signal (AIS), Link
Down Indication (LDI) and Locked Report (LKR). To indicate client
Down Indication (LDI) and Locked Report (LKR). To indicate client
faults associated with the attachment circuits Client Signal Failure
faults associated with the attachment circuits Client Signal Failure
Indication (CSF) can be used. CSF is described in [MPLS-TP-OAM-FWK]
Indication (CSF) can be used. CSF is described in [MPLS-TP-OAM-FWK]
and in the context of this document is for further study.
and in the context of this document is for further study.
[MPLS-TP-OAM-FWK] describes the mapping of fault conditions to
[MPLS-TP-OAM-FWK] describes the mapping of fault conditions to
consequent actions. Some of these mappings may be configured by the
consequent actions. Some of these mappings may be configured by the
operator, depending on the application of the LSP. The following
operator, depending on the application of the LSP. The following
defects are identified: Loss Of Continuity (LOC), Misconnectivity,
defects are identified: Loss Of Continuity (LOC), Misconnectivity,
MEP Misconfiguration and Period Misconfiguration. Out of these
MEP Misconfiguration and Period Misconfiguration. Out of these
defect conditions, the following consequent actions may be
defect conditions, the following consequent actions may be
configurable: 1) whether or not the LOC defect should result in
configurable: 1) whether or not the LOC defect should result in
blocking the outgoing data traffic; 2) whether or not the "Period
blocking the outgoing data traffic; 2) whether or not the "Period
Misconfiguration defect" should result in a signal fail condition.
Misconfiguration defect" should result in a signal fail condition.
3. Theory of Operations
3. Theory of Operations
3.1. MPLS OAM Configuration Operation Overview
3.1. MPLS OAM Configuration Operation Overview
RSVP-TE, or alternatively LSP Ping [LSP-PING CONF], can be used to
RSVP-TE, or alternatively LSP Ping [LSP-PING CONF], can be used to
simply enable the different OAM functions, by setting the
simply enable the different OAM functions, by setting the
corresponding flags in the "OAM Functions TLV". For a more detailed
corresponding flags in the "OAM Functions TLV". For a more detailed
configuration one may include sub-TLVs for the different OAM
configuration one may include sub-TLVs for the different OAM
functions in order to specify various parameters in detail.
functions in order to specify various parameters in detail.
Typically intermediate nodes should not process or modify any of the
Typically intermediate nodes should not process or modify any of the
OAM configuration TLVs but simply forward them to the end-node.
OAM configuration TLVs but simply forward them to the end-node.
There is one exception to this and that is if the "MPLS OAM FMS sub-
There is one exception to this and that is if the "MPLS OAM FMS sub-
TLV" is present. This sub-TLV has to be examined even by
TLV" is present. This sub-TLV has to be examined even by
intermediate nodes. The sub-TLV MAY be present if a flag is set in
intermediate nodes. The sub-TLV MAY be present if a flag is set in
the "Function Flags sub-TLV", see section [3.2. OAM Configuration
the "Function Flags sub-TLV", see section [3.2. OAM Configuration
TLV].
TLV].
3.1.1. Configuration of BFD sessions
3.1.1. Configuration of BFD sessions
For this specification, BFD MUST be run in either one of the two
For this specification, BFD MUST be run in either one of the two
modes:
modes:
- Asynchronous mode, where both sides should be in active mode
- Asynchronous mode, where both sides should be in active mode
- Unidirectional mode
- Unidirectional mode
In the simplest scenario LSP Ping, or alternatively RSVP-TE [RSVP-TE
In the simplest scenario LSP Ping, or alternatively RSVP-TE [RSVP-TE
CONF], is used only to bootstrap a BFD session for an LSP, without
CONF], is used only to bootstrap a BFD session for an LSP, without
any timer negotiation.
any timer negotiation.
Bellagamba, et al. Expires April 14, 2013 [Page 5]
Bellagamba, et al. Expires April 14, 2013 [Page 5]
Internet-Draft Extensions for MPLS-TP OAM Conf October 2012
Internet-Draft Extensions for MPLS-TP OAM Conf October 2012
Timer negotiation can be performed either in subsequent BFD control
Timer negotiation can be performed either in subsequent BFD control
messages (in this case the operation is similar to LSP Ping based
messages (in this case the operation is similar to LSP Ping based
bootstrapping described in [RFC5884]) or directly in the LSP ping
bootstrapping described in [RFC5884]) or directly in the LSP ping
configuration messages.
configuration messages.
When BFD Control packets are transported in the G-ACh they are not
When BFD Control packets are transported in the G-ACh they are not
protected by any end-to-end checksum, only lower-layers are providing
protected by any end-to-end checksum, only lower-layers are providing
error detection/correction. A single bit error, e.g. a flipped bit
error detection/correction. A single bit error, e.g. a flipped bit
in the BFD State field could cause the receiving end to wrongly
in the BFD State field could cause the receiving end to wrongly
conclude that the link is down and in turn trigger protection
conclude that the link is down and in turn trigger protection
switching. To prevent this from happening the "BFD Configuration
switching. To prevent this from happening the "BFD Configuration
sub-TLV" has an Integrity flag that when set enables BFD
sub-TLV" has an Integrity flag that when set enables BFD
Authentication using Keyed SHA1 with an empty key (all 0s) [RFC5880].
Authentication using Keyed SHA1 with an empty key (all 0s) [RFC5880].
This would make every BFD Control packet carry an SHA1 hash of itself
This would make every BFD Control packet carry an SHA1 hash of itself
that can be used to detect errors.
that can be used to detect errors.
If BFD Authentication using a pre-shared key / password is desired
If BFD Authentication using a pre-shared key / password is desired
(i.e. authentication and not only error detection) the "BFD
(i.e. authentication and not only error detection) the "BFD
Authentication sub-TLV" MUST be included in the "BFD Configuration
Authentication sub-TLV" MUST be included in the "BFD Configuration
sub-TLV". The "BFD Authentication sub-TLV" is used to specify which
sub-TLV". The "BFD Authentication sub-TLV" is used to specify which
authentication method that should be used and which pre-shared key /
authentication method that should be used and which pre-shared key /
password that should be used for this particular session. How the
password that should be used for this particular session. How the
key exchange is performed is out of scope of this document.
key exchange is performed is out of scope of this document.
3.1.2. Configuration of Performance Monitoring
3.1.2. Configuration of Performance Monitoring
It is possible to configure Performance Monitoring functionalities
It is possible to configure Performance Monitoring functionalities
such as Loss, Delay and Throughput as described in [RFC6374].
such as Loss, Delay and Throughput as described in [RFC6374].
When configuring Performance monitoring functionalities it is
When configuring Performance monitoring functionalities it is
possible to choose either the default configuration, by only setting
possible to choose either the default configuration, by only setting
the respective flags in the "OAM functions TLV", or a customized
the respective flags in the "OAM functions TLV", or a customized
configuration. To customize the configuration one would set the
configuration. To customize the configuration one would set the
respective flags in the including the respective Loss and/or Delay
respective flags in the including the respective Loss and/or Delay
sub-TLVs).
sub-TLVs).
By setting the PM Loss flag in the "OAM Functions TLV" and including
By setting the PM Loss flag in the "OAM Functions TLV" and including
the "MPLS OAM PM Loss sub-TLV" one can configure the measurement
the "MPLS OAM PM Loss sub-TLV" one can configure the measurement
interval and loss threshold values for triggering protection.
interval and loss threshold values for triggering protection.
Delay measurements are configured by setting PM Delay flag in the
Delay measurements are configured by setting PM Delay flag in the
"OAM Functions TLV" and including the "MPLS OAM PM Loss sub-TLV" one
"OAM Functions TLV" and including the "MPLS OAM PM Loss sub-TLV" one
can configure the measurement interval and the delay threshold values
can configure the measurement interval and the delay threshold values
for triggering protection.
for triggering protection.
Bellagamba, et al. Expires April 14, 2013 [Page 6]
Bellagamba, et al. Expires April 14, 2013 [Page 6]
Internet-Draft Extensions for MPLS-TP OAM Conf October 2012
Internet-Draft Extensions for MPLS-TP OAM Conf October 2012
3.1.3. Configuration of Fault Management Signals
3.1.3. Configuration of Fault Management Signals
To configure Fault Monitoring Signals and their refresh time the FMS
To configure Fault Monitoring Signals and their refresh time the FMS
flag in the "OAM Functions TLV" MUST be set and the "MPLS OAM FMS
flag in the "OAM Functions TLV" MUST be set and the "MPLS OAM FMS
sub-TLV" included. When configuring Fault Monitoring Signals it can
sub-TLV" included. When configuring Fault Monitoring Signals it can
be chosen either the default configuration (by only setting the
be chosen either the default configuration (by only setting the
respective flags in the "OAM functions TLV") or a customized
respective flags in the "OAM functions TLV") or a customized
configuration (by including the "MPLS OAM FMS sub-TLV").
configuration (by including the "MPLS OAM FMS sub-TLV").
If an intermediate point is meant to originate fault management
If an intermediate point is meant to originate fault management
signal messages this means that such an intermediate point is
signal messages this means that such an intermediate point is
associated to a server MEP through a co-located MPLS-TP client/server
associated to a server MEP through a co-located MPLS-TP client/server
adaptation function. Such a server MEP needs to be configured by its
adaptation function. Such a server MEP needs to be configured by its
own RSVP-TE session (or, alternatively, via an NMS or LSP-ping).
own RSVP-TE session (or, alternatively, via an NMS or LSP-ping).
However, by setting the "Fault Management subscription" flag in the
However, by setting the "Fault Management subscription" flag in the
"MPLS OAM FMS sub-TLV" a client LSP can indicate that it would like
"MPLS OAM FMS sub-TLV" a client LSP can indicate that it would like
an association to be created to the server MEP(s) on any intermediate
an association to be created to the server MEP(s) on any intermediate
nodes.
nodes.
3.2. OAM Configuration TLV
3.2. OAM Configuration TLV
The "OAM Configuration TLV" is depicted in the following figure. It
The "OAM Configuration TLV" is depicted in the following figure. It
specifies the OAM functions that are to be used for the LSP and it is
specifies the OAM functions that are to be used for the LSP and it is
defined in [OAM-CONF-FWK]. The "OAM Configuration TLV" is carried in
defined in [OAM-CONF-FWK]. The "OAM Configuration TLV" is carried in
the LSP_ATTRIBUTES object in Path and Resv messages.
the LSP_ATTRIBUTES object in Path and Resv messages.
0 1 2 3
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
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 (2) (IANA) | Length |
| Type (2) (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Type | Reserved |
| OAM Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
~ sub-TLVs ~
~ sub-TLVs ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: indicates the "OAM Configuration TLV" (2) (IANA to assign).
Type: indicates the "OAM Configuration TLV" (2) (IANA to assign).
OAM Type: one octet that specifies the technology specific OAM Type.
OAM Type: one octet that specifies the technology specific OAM Type.
If the requested OAM Type is not supported, an error must be
If the requested OAM Type is not supported, an error must be
generated: "OAM Problem/Unsupported OAM Type".
generated: "OAM Problem/Unsupported OAM Type".
This document defines a new OAM Type: "MPLS OAM" (suggested value 2,
This document defines a new OAM Type: "MPLS OAM" (suggested value 2,
Bellagamba, et al. Expires April 14, 2013 [Page 7]
Bellagamba, et al. Expires April 14, 2013 [Page 7]
Internet-Draft Extensions for MPLS-TP OAM Conf October 2012
Internet-Draft Extensions for MPLS-TP OAM Conf October 2012
IANA to assign) from the "RSVP-TE OAM Configuration Registry". The
IANA to assign) from the "RSVP-TE OAM Configuration Registry". The
"MPLS OAM" type is set to request the establishment of OAM functions
"MPLS OAM" type is set to request the establishment of OAM functions
for MPLS-TP LSPs. The specific OAM functions are specified in the
for MPLS-TP LSPs. The specific OAM functions are specified in the
"Function Flags" sub-TLV as depicted in [OAM-CONF-FWK].
"Function Flags" sub-TLV as depicted in [OAM-CONF-FWK].
The receiving edge LSR when the MPLS-TP OAM Type is requested should
The receiving edge LSR when the MPLS-TP OAM Type is requested should
check which OAM Function Flags are set in the "Function Flags TLV"
check which OAM Function Flags are set in the "Function Flags TLV"
(also defined in [OAM-CONF-FWK]) and look for the corresponding
(also defined in [OAM-CONF-FWK]) and look for the corresponding
technology specific configuration TLVs.
technology specific configuration TLVs.
Additional corresponding sub-TLVs are as follows:
Additional corresponding sub-TLVs are as follows:
- "BFD Configuration sub-TLV", which MUST be included if the CC
- "BFD Configuration sub-TLV", which MUST be included if the CC
and/or the CV OAM Function flag is set. This sub-TLV MUST carry a
and/or the CV OAM Function flag is set. This sub-TLV MUST carry a
"BFD Local Discriminator sub-TLV" and a "Timer Negotiation
"BFD Local Discriminator sub-TLV" and a "Timer Negotiation
Parameters sub-TLV" if the N flag is cleared. If the I flag is
Parameters sub-TLV" if the N flag is cleared. If the I flag is
set, the "BFD Authentication sub-TLV" may be included.
set, the "BFD Authentication sub-TLV" may be included.
- "MPLS OAM PM Loss sub-TLV" within the "Performance Monitoring
- "MPLS OAM PM Loss sub-TLV" within the "Performance Monitoring
sub-TLV", which MAY be included if the PM/Loss OAM Function flag
sub-TLV", which MAY be included if the PM/Loss OAM Function flag
is set. If the "MPLS OAM PM Loss sub-TLV" is not included,
is set. If the "MPLS OAM PM Loss sub-TLV" is not included,
default configuration values are used. Such sub-TLV MAY also be
default configuration values are used. Such sub-TLV MAY also be
included in case the Throughput function flag is set and there is
included in case the Throughput function flag is set and there is
the need to specify measurement interval different from the
the need to specify measurement interval different from the
default ones. In fact the throughput measurement make use of the
default ones. In fact the throughput measurement make use of the
same tool as the loss measurement, hence the same TLV is used.
same tool as the loss measurement, hence the same TLV is used.
- "MPLS OAM PM Delay sub-TLV" within the "Performance Monitoring
- "MPLS OAM PM Delay sub-TLV" within the "Performance Monitoring
sub-TLV", which MAY be included if the PM/Delay OAM Function flag
sub-TLV", which MAY be included if the PM/Delay OAM Function flag
is set. If the "MPLS OAM PM Delay sub-TLV" is not included,
is set. If the "MPLS OAM PM Delay sub-TLV" is not included,
default configuration values are used.
default configuration values are used.
- "MPLS OAM FMS sub-TLV", which MAY be included if the FMS OAM
- "MPLS OAM FMS sub-TLV", which MAY be included if the FMS OAM
Function flag is set. If the "MPLS OAM FMS sub-TLV" is not
Function flag is set. If the "MPLS OAM FMS sub-TLV" is not
included, default configuration values are used.
included, default configuration values are used.
Moreover, if the CV or CC flag is set, the CC flag MUST be set as
Moreover, if the CV or CC flag is set, the CC flag MUST be set as
well. The format of an MPLS-TP CV/CC message is shown in [BFD-CCCV]
well. The format of an MPLS-TP CV/CC message is shown in [BFD-CCCV]
and it requires, together with the BFD control packet information,
and it requires, together with the BFD control packet information,
the "Unique MEP-ID of source of BFD packet". [MPLS-TP-IDENTIF]
the "Unique MEP-ID of source of BFD packet". [MPLS-TP-IDENTIF]
defines the composition of such identifier as:
defines the composition of such identifier as:
<"Unique MEP-ID of source of BFD packet"> ::=
<"Unique MEP-ID of source of BFD packet"> ::=
<src_node_id><src_tunnel_num><lsp_num>
<src_node_id><src_tunnel_num><lsp_num>
Note that support of ITU IDs is out-of-scope.
Note that support of ITU IDs is out-of-scope.
GMPLS signaling [RFC3473] uses a 5-tuple to uniquely identify an LSP
GMPLS signaling [RFC3473] uses a 5-tuple to uniquely identify an LSP
Bellagamba, et al. Expires April 14, 2013 [Page 8]
Bellagamba, et al. Expires April 14, 2013 [Page 8]
Internet-Draft Extensions for MPLS-TP OAM Conf October 2012
Internet-Draft Extensions for MPLS-TP OAM Conf October 2012
within an operator's network. This tuple is composed of a Tunnel
within an operator's network. This tuple is composed of a Tunnel
Endpoint Address, Tunnel_ID, Extended Tunnel ID, and Tunnel Sender
Endpoint Address, Tunnel_ID, Extended Tunnel ID, and Tunnel Sender
Address and (GMPLS) LSP_ID.
Address and (GMPLS) LSP_ID.
Hence, the following mapping is used without the need of redefining a
Hence, the following mapping is used without the need of redefining a
new TLV for MPLS-TP proactive CV purpose.
new TLV for MPLS-TP proactive CV purpose.
- Tunnel ID = src_tunnel_num
- Tunnel ID = src_tunnel_num
- Tunnel Sender Address = src_node_id
- Tunnel Sender Address = src_node_id
- LSP ID = LSP_Num
- LSP ID = LSP_Num
"Tunnel ID" and "Tunnel Sender Address" are included in the "SESSION"
"Tunnel ID" and "Tunnel Sender Address" are included in the "SESSION"
object [RFC3209], which is mandatory in both Path and Resv messages.
object [RFC3209], which is mandatory in both Path and Resv messages.
"LSP ID" will be the same on both directions and it is included in
"LSP ID" will be the same on both directions and it is included in
the "SENDER_TEMPLATE" object [RFC3209] which is mandatory in Path
the "SENDER_TEMPLATE" object [RFC3209] which is mandatory in Path
messages.
messages.
[Author's note: the same "Unique MEP-ID of source" will be likely
[Author's note: the same "Unique MEP-ID of source" will be likely
required for Performance monitoring purposes. This need to be agreed
required for Performance monitoring purposes. This need to be agreed
with [RFC6374] authors.]
with [RFC6374] authors.]
3.3. BFD Configuration sub-TLV
3.3. BFD Configuration sub-TLV
The "BFD Configuration sub-TLV" (depicted below) is defined for BFD
The "BFD Configuration sub-TLV" (depicted below) is defined for BFD
OAM specific configuration parameters. The "BFD Configuration sub-
OAM specific configuration parameters. The "BFD Configuration sub-
TLV" is carried as a sub-TLV of the "OAM Configuration TLV".
TLV" is carried as a sub-TLV of the "OAM Configuration TLV".
This TLV accommodates generic BFD OAM information and carries sub-
This TLV accommodates generic BFD OAM information and carries sub-
TLVs.
TLVs.
0 1 2 3
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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFD Conf. Type (3) (IANA) | Length |
| BFD Conf. Type (3) (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| PHB |N|S|I|G|U|B| Reserved (set to all 0s) |
|Vers.| PHB |N|S|I|G|U|B| Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
~ sub-TLVs ~
~ sub-TLVs ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: indicates a new type, the "BFD Configuration sub-TLV" (IANA to
Type: indicates a new type, the "BFD Configuration sub-TLV" (IANA to
define).
define).
Bellagamba, et al. Expires April 14, 2013 [Page 9]
Bellagamba, et al. Expires April 14, 2013 [Page 9]
Internet-Draft Extensions for MPLS-TP OAM Conf October 2012
Internet-Draft Extensions for MPLS-TP OAM Conf October 2012
Length: indicates the total length including sub-TLVs.
Length: indicates the total length including sub-TLVs.
Version: identifies the BFD protocol version. If a node does not
Version: identifies the BFD protocol version. If a node does not
support a specific BFD version an error must be generated: "OAM
support a specific BFD version an error must be generated: "OAM
Problem/Unsupported OAM Version".
Problem/Unsupported OAM Version".
PHB: Identifies the Per-Hop Behavior (PHB) to be used for periodic
PHB: Identifies the Per-Hop Behavior (PHB) to be used for periodic
continuity monitoring messages.
continuity monitoring messages.
BFD Negotiation (N): If set timer negotiation/re-negotiation via BFD
BFD Negotiation (N): If set timer negotiation/re-negotiation via BFD
Control Messages is enabled, when cleared it is disabled.
Control Messages is enabled, when cleared it is disabled.
Symmetric session (S): If set the BFD session MUST use symmetric
Symmetric session (S): If set the BFD session MUST use symmetric
timing values.
timing values.
Integrity (I): If set BFD Authentication MUST be enabled. If the
Integrity (I): If set BFD Authentication MUST be enabled. If the
"BFD Configuration sub-TLV" does not include a "BFD Authentication
"BFD Configuration sub-TLV" does not include a "BFD Authentication
sub-TLV" the authentication MUST use Keyed SHA1 with an empty pre-
sub-TLV" the authentication MUST use Keyed SHA1 with an empty pre-
shared key (all 0s).
shared key (all 0s).
Encapsulation Capability (G): if set, it shows the capability of
Encapsulation Capability (G): if set, it shows the capability of
encapsulating BFD messages into G-Ach channel. If both the G bit and
encapsulating BFD messages into G-Ach channel. If both the G bit and
U bit are set, configuration gives precedence to the G bit.
U bit are set, configuration gives precedence to the G bit.
Encapsulation Capability (U): if set, it shows the capability of
Encapsulation Capability (U): if set, it shows the capability of
encapsulating BFD messages into UDP packets. If both the G bit and U
encapsulating BFD messages into UDP packets. If both the G bit and U
bit are set, configuration gives precedence to the G bit.
bit are set, configuration gives precedence to the G bit.
Bidirectional (B): if set, it configures BFD in the Bidirectional
Bidirectional (B): if set, it configures BFD in the Bidirectional
mode. If it is not set it configures BFD in unidirectional mode. In
mode. If it is not set it configures BFD in unidirectional mode. In
the second case, the source node does not expect any Discriminator
the second case, the source node does not expect any Discriminator
values back from the destination node.
values back from the destination node.
Reserved: Reserved for future specification and set to 0 on
Reserved: Reserved for future specification and set to 0 on
transmission and ignored when received.
transmission and ignored when received.
The "BFD Configuration sub-TLV" MUST include the following sub-TLVs
The "BFD Configuration sub-TLV" MUST include the following sub-TLVs
in the Path message:
in the Path message:
- "Local Discriminator sub-TLV";
- "Local Discriminator sub-TLV";
- "Negotiation Timer Parameters sub-TLV" if the N flag is cleared.
- "Negotiation Timer Parameters sub-TLV" if the N flag is cleared.
The "BFD Configuration sub-TLV" MUST include the following sub-TLVs
The "BFD Configuration sub-TLV" MUST include the following sub-TLVs
in the Resv message:
in the Resv message:
Bellagamba, et al. Expires April 14, 2013 [Page 10]
Bellagamba, et al. Expires April 14, 2013 [Page 10]
Internet-Draft Extensions for MPLS-TP OAM Conf October 2012
Internet-Draft Extensions for MPLS-TP OAM Conf October 2012
- "Local Discriminator sub-TLV;"
- "Local Discriminator sub-TLV;"
- "Negotiation Timer Parameters sub-TLV" if:
- "Negotiation Timer Parameters sub-TLV" if:
- the N and S flags are cleared, or if:
- the N and S flags are cleared, or if:
- the N flag is cleared and the S flag is set, and the
- the N flag is cleared and the S flag is set, and the
Negotiation Timer Parameters sub-TLV received by the egress
Negotiation Timer Parameters sub-TLV received by the egress
contains unsupported values. In this case an updated
contains unsupported values. In this case an updated
Negotiation Ti
Negotiation Ti
Original Text
Changed Text