draft-ietf-mpls-tp-temporal-hitless-psm-14.txt | rfc8256.txt | |||
---|---|---|---|---|
Network Working Group A. D'Alessandro | Internet Engineering Task Force (IETF) A. D'Alessandro | |||
Internet-Draft Telecom Italia | Request for Comments: 8256 Telecom Italia | |||
Intended status: Informational L. Andersson | Category: Informational L. Andersson | |||
Expires: March 5, 2018 Huawei Technologies | ISSN: 2070-1721 Huawei Technologies | |||
S. Ueno | S. Ueno | |||
NTT Communications | NTT Communications | |||
K. Arai | K. Arai | |||
Y. Koike | Y. Koike | |||
NTT | NTT | |||
September 1, 2017 | October 2017 | |||
Requirements for hitless MPLS path segment monitoring | Requirements for Hitless MPLS Path Segment Monitoring | |||
draft-ietf-mpls-tp-temporal-hitless-psm-14.txt | ||||
Abstract | Abstract | |||
One of the most important OAM capabilities for transport network | One of the most important Operations, Administration, and Maintenance | |||
operation is fault localisation. An in-service, on-demand segment | (OAM) capabilities for transport-network operation is fault | |||
monitoring function of a transport path is indispensable, | localization. An in-service, on-demand path segment monitoring | |||
particularly when the service monitoring function is activated only | function of a transport path is indispensable, particularly when the | |||
between end points. However, the current segment monitoring approach | service monitoring function is activated only between endpoints. | |||
defined for MPLS (including the transport profile (MPLS-TP)) in RFC | However, the current segment monitoring approach defined for MPLS | |||
6371 "Operations, Administration, and Maintenance Framework for MPLS- | (including the MPLS Transport Profile (MPLS-TP)) in RFC 6371 | |||
Based Transport Networks" has drawbacks. This document provides an | "Operations, Administration, and Maintenance Framework for MPLS-Based | |||
Transport Networks" has drawbacks. This document provides an | ||||
analysis of the existing MPLS-TP OAM mechanisms for the path segment | analysis of the existing MPLS-TP OAM mechanisms for the path segment | |||
monitoring and provides requirements to guide the development of new | monitoring and provides requirements to guide the development of new | |||
OAM tools to support a Hitless Path Segment Monitoring (HPSM). | OAM tools to support Hitless Path Segment Monitoring (HPSM). | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This document is not an Internet Standards Track specification; it is | |||
provisions of BCP 78 and BCP 79. | published for informational purposes. | |||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at http://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Not all documents | |||
approved by the IESG are a candidate for any level of Internet | ||||
Standard; see Section 2 of RFC 7841. | ||||
This Internet-Draft will expire on March 5, 2018. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
https://www.rfc-editor.org/info/rfc8256. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2017 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 | (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Conventions used in this document . . . . . . . . . . . . . . 3 | 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 | |||
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. Requirements for Hitless Path Segment Monitoring . . . . . . 7 | 4. Requirements for HPSM . . . . . . . . . . . . . . . . . . . . 8 | |||
4.1. Backward compatibility . . . . . . . . . . . . . . . . . 7 | 4.1. Backward Compatibility . . . . . . . . . . . . . . . . . 8 | |||
4.2. Non-intrusive segment monitoring . . . . . . . . . . . . 8 | 4.2. Non-Intrusive Segment Monitoring . . . . . . . . . . . . 8 | |||
4.3. Multiple segments monitoring . . . . . . . . . . . . . . 8 | 4.3. Monitoring Multiple Segments . . . . . . . . . . . . . . 9 | |||
4.4. Single and multiple level monitoring . . . . . . . . . . 8 | 4.4. Monitoring Single and Multiple Levels . . . . . . . . . . 9 | |||
4.5. HPSM and end-to-end proactive monitoring independence . . 9 | 4.5. HPSM and End-to-End Proactive Monitoring Independence . . 10 | |||
4.6. Arbitrary segment monitoring . . . . . . . . . . . . . . 10 | 4.6. Monitoring an Arbitrary Segment . . . . . . . . . . . . . 10 | |||
4.7. Fault while HPSM is operational . . . . . . . . . . . . . 11 | 4.7. Fault while HPSM Is Operational . . . . . . . . . . . . . 11 | |||
4.8. HPSM Manageability . . . . . . . . . . . . . . . . . . . 12 | 4.8. HPSM Manageability . . . . . . . . . . . . . . . . . . . 13 | |||
4.9. Supported OAM functions . . . . . . . . . . . . . . . . . 13 | 4.9. Supported OAM Functions . . . . . . . . . . . . . . . . . 13 | |||
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | |||
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 8.2. Informative References . . . . . . . . . . . . . . . . . 15 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 | Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 15 | Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
1. Introduction | 1. Introduction | |||
According to the MPLS-TP OAM requirements RFC 5860 [RFC5860], | According to the MPLS-TP OAM requirements [RFC5860], mechanisms MUST | |||
mechanisms MUST be available for alerting service providers of faults | be available for alerting service providers of faults or defects that | |||
or defects that affects their services. In addition, to ensure that | affect their services. In addition, to ensure that faults or service | |||
faults or service degradation can be localized, operators need a | degradation can be localized, operators need a function to diagnose | |||
function to diagnose the detected problem. Using end-to-end | the detected problem. Using end-to-end monitoring for this purpose | |||
monitoring for this purpose is insufficient in that an operator will | is insufficient in that an operator will not be able to localize a | |||
not be able to localize a fault or service degradation accurately. | fault or service degradation accurately. | |||
A segment monitoring function that can focus on a specific segment of | A segment monitoring function that can focus on a specific segment of | |||
a transport path and that can provide a detailed analysis is | a transport path and that can provide a detailed analysis is | |||
indispensable to promptly and accurately localize the fault. A path | indispensable to promptly and accurately localize the fault. A | |||
segment monitoring function has been defined to perform this task for | function for monitoring path segments has been defined to perform | |||
MPLS-TP. However, as noted in the MPLS-TP OAM Framework RFC 6371 | this task for MPLS-TP. However, as noted in the MPLS-TP OAM | |||
[RFC6371], the current method for segment monitoring of a transport | Framework [RFC6371], the current method for segment monitoring of a | |||
path has implications that hinder the usage in an operator network. | transport path has implications that hinder the usage in an operator | |||
network. | ||||
This document, after elaborating on the problem statement for the | After elaborating on the problem statement for the path segment | |||
path segment monitoring function as it is currently defined, provides | monitoring function as it is currently defined, this document | |||
requirements for an on-demand segment monitoring function without | provides requirements for an on-demand path segment monitoring | |||
traffic distruption. Further works are required to evaluate how | function without traffic disruption. Further works are required to | |||
proposed requirements match with current MPLS architecture and to | evaluate how proposed requirements match with current MPLS | |||
identify possibile solutions. | architecture and to identify possible solutions. | |||
2. Conventions used in this document | 2. Conventions Used in This Document | |||
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", "NOT RECOMMENDED", "MAY", and | |||
document are to be interpreted as described in RFC 2119 [RFC2119]. | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | ||||
capitals, as shown here. | ||||
2.1. Terminology | 2.1. Terminology | |||
HPSM - Hitless Path Segment Monitoring | HPSM - Hitless Path Segment Monitoring | |||
LSP - Label Switched Path | LSP - Label Switched Path | |||
LSR - Label Switching Router | LSR - Label Switching Router | |||
ME - Maintenance Entity | ME - Maintenance Entity | |||
MEG - Maintenance Entity Group | MEG - Maintenance Entity Group | |||
MEP - Maintenance Entity Group End Point | MEP - Maintenance Entity Group End Point | |||
MIP - Maintenance Entity Group Intermediate Point | MIP - Maintenance Entity Group Intermediate Point | |||
OTN - Optical Transport Network | OTN - Optical Transport Network | |||
TCM - Tandem connection monitoring | TCM - Tandem Connection Monitoring | |||
SPME - Sub-path Maintenance Element | SPME - Sub-Path Maintenance Element | |||
3. Problem Statement | 3. Problem Statement | |||
To monitor (and to protect and/or manage) MPLS-TP network segments a | A Sub-Path Maintenance Element (SPME) function to monitor (and to | |||
Sub-Path Maintenance Element (SPME) function has been defined in RFC | protect and/or manage) MPLS-TP network segments is defined in | |||
5921 [RFC5921]. The SPME is defined between the edges of the segment | [RFC5921]. The SPME is defined between the edges of the segment of a | |||
of a transport path that needs to be monitored, protected, or | transport path that needs to be monitored, protected, or managed. | |||
managed. SPME is created by stacking the shim header (MPLS header) | SPME is created by stacking the shim header (MPLS header), according | |||
according to RFC 3031 [RFC3031] and it is defined as the segment | to [RFC3031]; it is defined as the segment where the header is | |||
where the header is stacked. OAM messages can be initiated at the | stacked. OAM messages can be initiated at the edge of the SPME. | |||
edge of the SPME and sent to the peer edge of the SPME or to a MIP | They can be sent to the peer edge of the SPME or to a MIP along the | |||
along the SPME by setting the TTL value of the label stack entry | SPME by setting the TTL value of the Label Stack Entry (LSE) and | |||
(LSE) and interface identifier value at the corresponding | interface identifier value at the corresponding hierarchical LSP | |||
hierarchical LSP level in case of a per-node model. | level in case of a per-node model. | |||
MPLS-TP segment monitoring should satisfy two network objectives | According to Section 3.8 of [RFC6371], MPLS-TP segment monitoring | |||
according to section 3.8 of RFC 6371 [RFC6371]: | should satisfy two network objectives: | |||
(N1) The monitoring and maintenance of current transport paths has | (N1) The monitoring and maintenance of current transport paths has | |||
to be conducted in-service without traffic disruption. | to be conducted in-service without traffic disruption. | |||
(N2) Segment monitoring must not modify the forwarding of the | (N2) Segment monitoring must not modify the forwarding of the | |||
segment portion of the transport path. | segment portion of the transport path. | |||
The SPME function that has been defined in RFC 5921 [RFC5921] has | The SPME function that is defined in [RFC5921] has the following | |||
the following drawbacks: | drawbacks: | |||
(P1) It increases network management complexity, because a new | (P1) It increases network management complexity, because a new sub- | |||
sublayer and new MEPs and MIPs have to be configured for the SPME. | layer and new MEPs and MIPs have to be configured for the SPME. | |||
(P2) Original conditions of the path change. | (P2) Original conditions of the path change. | |||
(P3) The client traffic over a transport path is disrupted if the | (P3) The client traffic over a transport path is disrupted if the | |||
SPME is configured on-demand. | SPME is configured on-demand. | |||
Problem (P1) is related to the management of each additional sub- | Problem (P1) is related to the management of each additional sub- | |||
layer required for segment monitoring in a MPLS-TP network. When an | layer required for segment monitoring in an MPLS-TP network. When an | |||
SPME is applied to administer on-demand OAM functions in MPLS-TP | SPME is applied to administer on-demand OAM functions in MPLS-TP | |||
networks, a rule for operationally differentiating those SPME will be | networks, a rule for operationally differentiating those SPMEs will | |||
required at least within an administrative domain. This forces | be required at least within an administrative domain. This forces | |||
operators to implement at least an additional layer into the | operators to implement at least an additional layer into the | |||
management systems that will only be used for on-demand path segment | management systems that will only be used for on-demand path segment | |||
monitoring. From the perspective of operation, increasing the number | monitoring. From the perspective of operation, increasing the number | |||
of managed layers and managed addresses/identifiers is not desirable | of managed layers and managed addresses/identifiers is not desirable | |||
in view of keeping the management systems as simple as possible. | in view of keeping the management systems as simple as possible. | |||
Moreover, using the currently defined methods, on-demand setting of | Moreover, using the currently defined methods, on-demand setting of | |||
SPMEs causes problems (P2) and (P3) due to additional label stacking. | SPMEs causes problems (P2) and (P3) due to additional label stacking. | |||
Problem (P2) arises from the fact that MPLS exposed label value and | Problem (P2) arises because the MPLS-exposed label value and MPLS | |||
MPLS frames length changes. The monitoring function should monitor | frame length change. The monitoring function should monitor the | |||
the status without changing any condition of the target, to be | status without changing any condition of the target segment or of the | |||
monitored, segment or transport path. Changing the settings of the | target transport path. Changing the settings of the original shim | |||
original shim header should not be allowed because this change | header should not be allowed, because this change corresponds to | |||
corresponds to creating a new segment of the original transport path | creating a new segment of the original transport path that differs | |||
that differs from the original one. When the conditions of the path | from the original one. When the conditions of the path change, the | |||
change, the measured values or observed data will also change and | measured values or observed data will also change. This may make the | |||
this may make the monitoring meaningless because the result of the | monitoring meaningless because the result of the measurement would no | |||
measurement would no longer reflect the performance of the connection | longer reflect the performance of the connection where the original | |||
where the original fault or degradation occurred. As an example, | fault or degradation occurred. As an example, setting up an on- | |||
setting up an on-demand SPME will result in the LSRs within the | demand SPME will result in the LSRs within the monitoring segment | |||
monitoring segment only looking at the added (stacked) labels and not | only looking at the added (stacked) labels and not at the labels of | |||
at the labels of the original LSP. This means that problems stemming | the original LSP. This means that problems stemming from incorrect | |||
from incorrect (or unexpected) treatment of labels of the original | (or unexpected) treatment of labels of the original LSP by the nodes | |||
LSP by the nodes within the monitored segment cannot be identified | within the monitored segment cannot be identified when setting up | |||
when setting up SPME. This might include hardware problems during | SPME. This might include hardware problems during label lookup, | |||
label look-up, mis-configuration, etc. Therefore operators have to | misconfiguration, etc. Therefore, operators have to pay extra | |||
pay extra attention to correctly setting and checking the label | attention to correctly setting and checking the label values of the | |||
values of the original LSP in the configuration. Of course, the | original LSP in the configuration. Of course, the reverse of this | |||
reverse of this situation is also possible, e.g., an incorrect or | situation is also possible; for example, an incorrect or unexpected | |||
unexpected treatment of SPME labels can result in false detection of | treatment of SPME labels can result in false detection of a fault | |||
a fault where no problem existed originally. | where no problem existed originally. | |||
Figure 1 shows an example of SPME settings. In the figure, "X" is | Figure 1 shows an example of SPME settings. In the figure, "X" is | |||
the label value of the original path expected at the tail-end of node | the label value of the original path expected at the tail end of node | |||
D. "210" and "220" are label values allocated for SPME. The label | D. "210" and "220" are label values allocated for SPME. The label | |||
values of the original path are modified as well as the values of the | values of the original path are modified as are the values of the | |||
stacked labels. As shown in Figure 1, SPME changes both the length | stacked labels. As shown in Figure 1, SPME changes both the length | |||
of MPLS frames and the label value(s). In particular, performance | of MPLS frames and the label value(s). In particular, performance | |||
monitoring measurements (e.g. Delay Measurement and Packet Loss | monitoring measurements (e.g., Delay Measurement and Packet Loss | |||
Measurement) are sensitive to these changes. As an example, | Measurement) are sensitive to these changes. As an example, | |||
increasing the packet lenght may impact on packet loss due to MTU | increasing the packet length may impact packet loss due to MTU | |||
settings, modifying the label stack may introduce packet loss or it | settings; modifying the label stack may introduce packet loss, or it | |||
may fix packet loss depending on the configuration status so | may fix packet loss depending on the configuration status. Such | |||
modifying network conditions. Such changes influence packets delay | changes influence packet delay, too, even if, from a practical point | |||
too even if, from a practical point of view, it is likely that only a | of view, it is likely that only a few services will experience a | |||
few services will experience a practical impact. | practical impact. | |||
(Before SPME settings) | (Before SPME settings) | |||
--- --- --- --- --- | --- --- --- --- --- | |||
| | | | | | | | | | | | | | | | | | | | | | |||
| | | | | | | | | | | | | | | | | | | | | | |||
--- --- --- --- --- | --- --- --- --- --- | |||
A--100--B--110--C--120--D--130--E <= transport path | A--100--B--110--C--120--D--130--E <= transport path | |||
MEP MEP | MEP MEP | |||
(After SPME settings) | (After SPME settings) | |||
--- --- --- --- --- | --- --- --- --- --- | |||
| | | | | | | | | | | | | | | | | | | | | | |||
| | | | | | | | | | | | | | | | | | | | | | |||
--- --- --- --- --- | --- --- --- --- --- | |||
A--100--B-----------X---D--130--E <= transport path | A--100--B-----------X---D--130--E <= transport path | |||
MEP MEP | MEP MEP | |||
210--C--220 <= SPME | 210--C--220 <= SPME | |||
MEP' MEP' | MEP' MEP' | |||
Figure 1: SPME settings example | Figure 1: SPME Settings Example | |||
Problem (P3) can be avoided if the operator sets SPMEs in advance and | Problem (P3) can be avoided if the operator sets SPMEs in advance and | |||
maintains them until the end of life of a transport path. But this | maintains them until the end of life of a transport path: but this | |||
does not support on-demand. Furthermore SMPEs cannot be set | does not support on-demand. Furthermore, SMPEs cannot be set | |||
arbitrarily because overlapping of path segments is limited to | arbitrarily because overlapping of path segments is limited to | |||
nesting relationships. As a result, possible SPME configurations of | nesting relationships. As a result, possible SPME configurations of | |||
segments of an original transport path are limited due to the | segments of an original transport path are limited due to the | |||
characteristic of the SPME shown in Figure 1, even if SPMEs are pre- | characteristic of the SPME shown in Figure 1, even if SPMEs are | |||
configured. | preconfigured. | |||
Although the make-before-break procedure in the survivability | Although the make-before-break procedure in the survivability | |||
document RFC 6372 [RFC6372] supports configuration for monitoring | document [RFC6372] supports configuration for monitoring according to | |||
according to the framework document RFC 5921 [RFC5921], without | the framework document [RFC5921], without traffic disruption the | |||
traffic distruption, the configuration of an SPME is not possible | configuration of an SPME is not possible without violating the | |||
without violating network objective (N2). These concerns are | network objective (N2). These concerns are described in Section 3.8 | |||
described in section 3.8 of RFC 6371 [RFC6371]. | of [RFC6371]. | |||
Additionally, the make-before-break approach typically relies on a | Additionally, the make-before-break approach typically relies on a | |||
control plane and requires additional functionalities for a | control plane and requires additional functionalities for a | |||
management system to properly support SPME creation and traffic | management system to properly support SPME creation and traffic | |||
switching from the original transport path to the SPME. | switching from the original transport path to the SPME. | |||
As an example, the old and new transport resources (e.g. LSP | As an example, the old and new transport resources (e.g., LSP | |||
tunnels) might compete with each other for resources which they have | tunnels) might compete with each other for resources that they have | |||
in common. Depending on availability of resources, this competition | in common. Depending on availability of resources, this competition | |||
can cause admission control to prevent the new LSP tunnel from being | can cause admission control to prevent the new LSP tunnel from being | |||
established as this bandwidth accounting deviates from traditional | established as this bandwidth accounting deviates from the | |||
(non control plane) management system operation. While SPMEs can be | traditional (non-control plane) management-system operation. While | |||
applied in any network context (single domain, multi domain, single | SPMEs can be applied in any network context (single-domain, multi- | |||
carrier, multi carrier, etc.), the main applications are in inter- | domain, single-carrier, multi-carrier, etc.), the main applications | |||
carrier or inter-domain segment monitoring where they are typically | are in inter-carrier or inter-domain segment monitoring where they | |||
pre- configured or pre-instantiated. SPME instantiates a | are typically preconfigured or pre-instantiated. SPME instantiates a | |||
hierarchical path (introducing MPLS label stacking) through which OAM | hierarchical path (introducing MPLS-label stacking) through which OAM | |||
packets can be sent. The SPME monitoring function is also mainly | packets can be sent. The SPME monitoring function is also mainly | |||
important for protecting bundles of transport paths and carriers' | important for protecting bundles of transport paths and the carriers' | |||
carrier solutions within an administrative domain. | carrier solutions within an administrative domain. | |||
The analogy for SPME in other transport technologies is Tandem | The analogy for SPME in other transport technologies is Tandem | |||
Connection Monitoring (TCM), used in Optical Transport Networks (OTN) | Connection Monitoring (TCM). TCM is used in Optical Transport | |||
and Ethernet transport networks, which supports on-demand but does | Networks (OTNs) and Ethernet transport networks. It supports on- | |||
not affect the path. For example in OTN, TCM allows the insertion | demand but does not affect the path. For example, in OTNs, TCM | |||
and removal of performance monitoring overhead within the frame at | allows the insertion and removal of performance monitoring overhead | |||
intermediate points in the network. It is done such that their | within the frame at intermediate points in the network. It is done | |||
insertion and removal do not change the conditions of the path. | such that their insertion and removal do not change the conditions of | |||
Though as the OAM overhead is part of the frame (designated overhead | the path. Though, as the OAM overhead is part of the frame | |||
bytes), it is constrained to a pre-defined number of monitoring | (designated overhead bytes), it is constrained to a predefined number | |||
segments. | of monitoring segments. | |||
To summarize: the problem statement is that the current sub-path | To summarize: the problem statement is that the current sub-path | |||
maintenance based on a hierarchical LSP (SPME) is problematic for | maintenance based on a hierarchical LSP (SPME) is problematic for | |||
pre-configuration in terms of increasing the number of managed | preconfiguration in terms of increasing the number of managed objects | |||
objects by layer stacking and identifiers/addresses. An on-demand | by layer stacking and identifiers/addresses. An on-demand | |||
configuration of SPME is one of the possible approaches for | configuration of SPME is one of the possible approaches for | |||
minimizing the impact of these issues. However, the current | minimizing the impact of these issues. However, the current | |||
procedure is unfavourable because the on-demand configuration for | procedure is unfavorable because the on-demand configuration for | |||
monitoring changes the condition of the original monitored path. To | monitoring changes the condition of the original monitored path. To | |||
avoid or minimize the impact of the drawbacks discussed above, a more | avoid or minimize the impact of the drawbacks discussed above, a more | |||
efficient approach is required for the operation of an MPLS-TP | efficient approach is required for the operation of an MPLS-TP | |||
transport network. A monitoring mechanism, named Hitless Path | transport network. A monitoring mechanism, named "Hitless Path | |||
Segment Monitoring (HPSM), supporting on-demand path segment | Segment Monitoring" (HPSM), supporting on-demand path segment | |||
monitoring without traffic disruption is needed. | monitoring without traffic disruption is needed. | |||
4. Requirements for Hitless Path Segment Monitoring | 4. Requirements for HPSM | |||
In the following sections, mandatory (M) and optional (O) | In the following sections, mandatory (M) and optional (O) | |||
requirements for the Hitless Path Segment Monitoring function are | requirements for the HPSM function are listed. | |||
listed. | ||||
4.1. Backward compatibility | 4.1. Backward Compatibility | |||
HPSM would be an additional OAM tool that would not replace SPME. As | HPSM would be an additional OAM tool that would not replace SPME. As | |||
such: | such: | |||
(M1) HPSM MUST be compatible with the usage of SPME | (M1) HPSM MUST be compatible with the usage of SPME. | |||
(O1) HPSM SHOULD be applicable at the SPME layer too | (O1) HPSM SHOULD be applicable at the SPME layer too. | |||
(M2) HPSM MUST support both the per-node and per-interface model | ||||
as specified in RFC 6371 [RFC6371]. | ||||
4.2. Non-intrusive segment monitoring | (M2) HPSM MUST support both the per-node and per-interface model as | |||
specified in [RFC6371]. | ||||
One of the major problems of legacy SPME highlighted in section 3 is | 4.2. Non-Intrusive Segment Monitoring | |||
One of the major problems of legacy SPME highlighted in Section 3 is | ||||
that it may not monitor the original path and it could disrupt | that it may not monitor the original path and it could disrupt | |||
service traffic when set-up on demand. | service traffic when set up on demand. | |||
(M3) HPSM MUST NOT change the original conditions of transport | (M3) HPSM MUST NOT change the original conditions of the transport | |||
path (e.g. must not change the length of MPLS frames, the exposed | path (e.g., the length of MPLS frames, the exposed label | |||
label values, etc.) | values, etc.). | |||
(M4) HPSM MUST support on-demand provisioning without traffic | (M4) HPSM MUST support on-demand provisioning without traffic | |||
disruption. | disruption. | |||
4.3. Multiple segments monitoring | 4.3. Monitoring Multiple Segments | |||
Along a transport path there may be the need to support | Along a transport path, there may be the need to support monitoring | |||
simultaneously monitoring multiple segments | multiple segments simultaneously. | |||
(M5) HPSM MUST support configuration of multiple monitoring | (M5) HPSM MUST support configuration of multiple monitoring segments | |||
segments along a transport path. | along a transport path. | |||
--- --- --- --- --- | --- --- --- --- --- | |||
| | | | | | | | | | | | | | | | | | | | | | |||
| A | | B | | C | | D | | E | | | A | | B | | C | | D | | E | | |||
--- --- --- --- --- | --- --- --- --- --- | |||
MEP MEP <= ME of a transport path | MEP MEP <= ME of a transport path | |||
*------* *----* *--------------* <=three HPSM monit. instances | *------* *----* *--------------* <=three HPSM monit. instances | |||
Figure 2: Multiple HPSM instances example | Figure 2: Multiple HPSM Instances Example | |||
4.4. Single and multiple level monitoring | 4.4. Monitoring Single and Multiple Levels | |||
HPSM would apply mainly for on-demand diagnostic purposes. With the | HPSM would apply mainly for on-demand diagnostic purposes. With the | |||
currently defined approach, the most serious problem is that there is | currently defined approach, the most serious problem is that there is | |||
no way to locate the degraded segment of a path without changing the | no way to locate the degraded segment of a path without changing the | |||
conditions of the original path. Therefore, as a first step, a | conditions of the original path. Therefore, as a first step, a | |||
single level, single segment monitoring, not affecting the monitored | single-level, single-segment monitoring not affecting the monitored | |||
path, is required for HPSM. A combination of multi-level and | path is required for HPSM. Monitoring simultaneous segments on | |||
simultaneous segments monitoring is the most powerful tool for | multiple levels is the most powerful tool for accurately diagnosing | |||
accurately diagnosing the performance of a transport path. However, | the performance of a transport path. However, in the field, a | |||
in the field, a single level, multiple segments approach would be | single-level, multiple-segment approach would be less complex for | |||
less complex for management and operations. | management and operations. | |||
(M6) HPSM MUST support single-level segment monitoring | ||||
(O2) HPSM MAY support multi-level segment monitoring. | (M6) HPSM MUST support single-level segment monitoring. | |||
Figure 3 shows an example of multi-level HPSM. | (O2) HPSM MAY support multi-level segment monitoring. | |||
--- --- --- --- --- | --- --- --- --- --- | |||
| | | | | | | | | | | | | | | | | | | | | | |||
| A | | B | | C | | D | | E | | | A | | B | | C | | D | | E | | |||
--- --- --- --- --- | --- --- --- --- --- | |||
MEP MEP <= ME of a transport path | MEP MEP <= ME of a transport path | |||
*-----------------* <=On-demand HPSM level 1 | *-----------------* <=On-demand HPSM level 1 | |||
*-------------* <=On-demand HPSM level 2 | *-------------* <=On-demand HPSM level 2 | |||
*-* <=On-demand HPSM level 3 | *-* <=On-demand HPSM level 3 | |||
Figure 3: Multi-level HPSM example | Figure 3: Multi-Level HPSM Example | |||
4.5. HPSM and end-to-end proactive monitoring independence | 4.5. HPSM and End-to-End Proactive Monitoring Independence | |||
There is a need for simultaneously using existing end-to-end | There is a need for simultaneously using existing end-to-end | |||
proactive monitoring and on-demand path segment monitoring. | proactive monitoring and on-demand path segment monitoring. | |||
Normally, the on-demand path segment monitoring is configured on a | Normally, the on-demand path segment monitoring is configured on a | |||
segment of a maintenance entity of a transport path. In such an | segment of a maintenance entity of a transport path. In such an | |||
environment, on-demand single-level monitoring should be performed | environment, on-demand single-level monitoring should be performed | |||
without disrupting the pro-active monitoring of the targeted end-to- | without disrupting the proactive monitoring of the targeted end-to- | |||
end transport path to avoid affecting user traffic performance | end transport path to avoid affecting monitoring of user traffic | |||
monitoring. | performance. | |||
(M7) HPSM MUST support the capability of being operated | (M7) HPSM MUST support the capability of being operated concurrently | |||
concurrently to, and independently of OAM function operated on the | to, and independently of, the OAM function on the end-to-end | |||
end-to-end path | path. | |||
--- --- --- --- --- | --- --- --- --- --- | |||
| | | | | | | | | | | | | | | | | | | | | | |||
| A | | B | | C | | D | | E | | | A | | B | | C | | D | | E | | |||
--- --- --- --- --- | --- --- --- --- --- | |||
MEP MEP <= ME of a transport path | MEP MEP <= ME of a transport path | |||
+-----------------------------+ <= Pro-active end-to-end mon. | +-----------------------------+ <= Proactive end-to-end mon. | |||
*------------------* <= On-demand HPSM | *------------------* <= On-demand HPSM | |||
Figure 4: Independence between proactive end-to-end monitoring and | Figure 4: Independence between Proactive End-to-End Monitoring and | |||
on-demand HPSM | On-Demand HPSM | |||
4.6. Arbitrary segment monitoring | 4.6. Monitoring an Arbitrary Segment | |||
The main objective for on-demand segment monitoring is to diagnose | The main objective for on-demand path segment monitoring is to | |||
the fault locations. A possible realistic diagnostic procedure is to | diagnose the fault locations. A possible realistic diagnostic | |||
fix one end point of a segment at the MEP of the transport path under | procedure is to fix one endpoint of a segment at the MEP of the | |||
observation and change progressively the length of the segments. It | transport path under observation and progressively change the length | |||
is therefore possible to monitoring step by step all the path with a | of the segments. It is, therefore, possible to monitor all the | |||
granularity that depends on equipment implementations. For example, | paths, step-by-step, with a granularity that depends on equipment | |||
Figure 5 shows the case where the granularity is at interface level | implementations. For example, Figure 5 shows the case where the | |||
(i.e. monitoring is at each input interface and output interface of | granularity is at the interface level (i.e., monitoring is at each | |||
each piece of equipment). | input interface and output interface of each piece of equipment). | |||
--- --- --- --- --- | --- --- --- --- --- | |||
| | | | | | | | | | | | | | | | | | | | | | |||
| A | | B | | C | | D | | E | | | A | | B | | C | | D | | E | | |||
--- --- --- --- --- | --- --- --- --- --- | |||
MEP MEP <= ME of a transport path | MEP MEP <= ME of a transport path | |||
+-----------------------------+ <= Pro-active end-to-end mon. | +-----------------------------+ <= Proactive end-to-end mon. | |||
*-----* <= 1st on-demand HPSM | *-----* <= 1st on-demand HPSM | |||
*-------* <= 2nd on-demand HPSM | *-------* <= 2nd on-demand HPSM | |||
| | | | | | |||
| | | | | | |||
*-----------------------* <= 4th on-demand HPSM | *-----------------------* <= 4th on-demand HPSM | |||
*-----------------------------* <= 5th on-demand HPSM | *-----------------------------* <= 5th on-demand HPSM | |||
Figure 5: Localization of a defect by consecutive on-demand segment | Figure 5: Localization of a Defect by Consecutive On-Demand Path | |||
monitoring procedure | Segment Monitoring Procedure | |||
Another possible scenario is depicted in Figure 6. In this case, the | Another possible scenario is depicted in Figure 6. In this case, the | |||
operator wants to diagnose a transport path starting at a transit | operator wants to diagnose a transport path starting at a transit | |||
node, because the end nodes (A and E) are located at customer sites | node because the end nodes (A and E) are located at customer sites | |||
and consist of small boxes supporting only a subset of OAM functions. | and consist of small boxes supporting only a subset of OAM functions. | |||
In this case, where the source entities of the diagnostic packets are | In this case, where the source entities of the diagnostic packets are | |||
limited to the position of MEPs, on-demand segment monitoring will be | limited to the position of MEPs, on-demand path segment monitoring | |||
ineffective because not all the segments can be diagnosed (e.g. | will be ineffective because not all the segments can be diagnosed | |||
segment monitoring HPSM 3 in Figure 6 is not available and it is not | (e.g., segment monitoring HPSM 3 in Figure 6 is not available, and it | |||
possible to determine the fault location exactly). | is not possible to determine the fault location exactly). | |||
(M8) It SHALL be possible to provision HPSM on an arbitrary | (M8) It SHALL be possible to provision HPSM on an arbitrary segment | |||
segment of a transport path. | of a transport path. | |||
--- --- --- | --- --- --- | |||
--- | | | | | | --- | --- | | | | | | --- | |||
| A | | B | | C | | D | | E | | | A | | B | | C | | D | | E | | |||
--- --- --- --- --- | --- --- --- --- --- | |||
MEP MEP <= ME of a transport path | MEP MEP <= ME of a transport path | |||
+-----------------------------+ <= Pro-active end-to-end mon. | +-----------------------------+ <= Proactive end-to-end mon. | |||
*-----* <= On-demand HPSM 1 | *-----* <= On-demand HPSM 1 | |||
*-----------------------* <= On-demand HPSM 2 | *-----------------------* <= On-demand HPSM 2 | |||
*---------* <= On-demand HPSM 3 | *---------* <= On-demand HPSM 3 | |||
Figure 6: HPSM configuration at arbitrary segments | Figure 6: HPSM Configuration at Arbitrary Segments | |||
4.7. Fault while HPSM is operational | 4.7. Fault while HPSM Is Operational | |||
Node or link failures may occur while HPSM is active. In this case, | Node or link failures may occur while HPSM is active. In this case, | |||
if no resiliency mechanism is set-up on the subtended transport path, | if no resiliency mechanism is set up on the subtended transport path, | |||
there is no particular requirement for HPSM. If the transport path | there is no particular requirement for HPSM. If the transport path | |||
is protected, the HPSM function may bring to monitoring unintended | is protected, the HPSM function may monitor unintended segments. The | |||
segments. The following examples are provided for clarification. | following examples are provided for clarification. | |||
Protection scenario A is shown in figure 7. In this scenario a | Protection scenario A is shown in Figure 7. In this scenario, a | |||
working LSP and a protection LSP are set-up. HPSM is activated | working LSP and a protection LSP are set up. HPSM is activated | |||
between nodes A and E. When a fault occurs between nodes B and C, | between nodes A and E. When a fault occurs between nodes B and C, | |||
the operation of HPSM is not affected by the protection switch and | the operation of HPSM is not affected by the protection switch and | |||
continues on the active LSP path. | continues on the active LSP. | |||
A - B - C - D - E - F | A - B - C - D - E - F | |||
\ / | \ / | |||
G - H - I - L | G - H - I - L | |||
Where: | Where: | |||
- end-to-end LSP: A-B-C-D-E-F | - end-to-end LSP: A-B-C-D-E-F | |||
- working LSP: A-B-C-D-E-F | - working LSP: A-B-C-D-E-F | |||
- protection LSP: A-G-H-I-L-F | - protection LSP: A-G-H-I-L-F | |||
- HPSM: A-E | - HPSM: A-E | |||
Figure 7: Protection scenario A | Figure 7: Protection Scenario A | |||
Protection scenario B is shown in figure 8. The difference with | Protection scenario B is shown in Figure 8. The difference with | |||
scenario A is that only a portion of the transport path is protected. | scenario A is that only a portion of the transport path is protected. | |||
In this case, when a fault occurs between nodes B and C on the | In this case, when a fault occurs between nodes B and C on the | |||
working sub-path B-C-D, traffic will be switched to protection sub- | working sub-path B-C-D, traffic will be switched to protection sub- | |||
path B-G-H-D. Assuming that OAM packet termination depends only on | path B-G-H-D. Assuming that OAM packet termination depends only on | |||
the TTL value of the MPLS label header, the target node of the HPSM | the TTL value of the MPLS label header, the target node of the HPSM | |||
changes from E to D due to the difference of hop counts between the | changes from E to D due to the difference of hop counts between the | |||
working path route (A-B-C-D-E: 4 hops) and protection path route | working path route (A-B-C-D-E: 4 hops) and protection path route | |||
(A-B-G-H-D-E: 5 hops). In this case the operation of HPSM is | (A-B-G-H-D-E: 5 hops). In this case, the operation of HPSM is | |||
affected. | affected. | |||
A - B - C - D - E - F | A - B - C - D - E - F | |||
\ / | \ / | |||
G - H | G - H | |||
- end-to-end LSP: A-B-C-D-E-F | - end-to-end LSP: A-B-C-D-E-F | |||
- working sub-path: B-C-D | - working sub-path: B-C-D | |||
- protection sub-path: B-G-H-D | - protection sub-path: B-G-H-D | |||
- HPSM: A-E | - HPSM: A-E | |||
Figure 8: Protection scenario B | Figure 8: Protection Scenario B | |||
(M9) The HPSM SHOULD avoid monitoring an unintended segment when | (M9) The HPSM SHOULD avoid monitoring an unintended segment when one | |||
one or more failures occur | or more failures occur. | |||
There are potentially different solutions to satisfy such a | There are potentially different solutions to satisfy such a | |||
requirement. A possible solution may be to suspend HPSM monitoring | requirement. A possible solution may be to suspend HPSM monitoring | |||
until network restoration takes place. Another possible approach may | until network restoration takes place. Another possible approach may | |||
be to compare the node/interface ID in the OAM packet with that at | be to compare the node/interface ID in the OAM packet with that at | |||
the node reached at TTL termination and if this does not match | the node reached at TTL termination and, if this does not match, a | |||
through some means trigger a suspension of HPSM monitoring. The | suspension of HPSM monitoring should be triggered. The above | |||
above approaches are valid in any circumstance, both for protected | approaches are valid in any circumstance, both for protected and | |||
and unprotected networks LSPs. These examples should not be taken to | unprotected networks LSPs. These examples should not be taken to | |||
limit the design of a solution. | limit the design of a solution. | |||
4.8. HPSM Manageability | 4.8. HPSM Manageability | |||
From managing perspective, increasing the number of managed layers | From a managing perspective, increasing the number of managed layers | |||
and managed addresses/identifiers is not desirable in view of keeping | and managed addresses/identifiers is not desirable in view of keeping | |||
the management systems as simple as possible. | the management systems as simple as possible. | |||
(M10)HPSM SHOULD NOT be based on additional transport layers (e.g. | (M10) HPSM SHOULD NOT be based on additional transport layers (e.g., | |||
hierarchical LSPs) | hierarchical LSPs). | |||
(M11) The same identifiers used for MIPs and/or MEPs SHOULD be | (M11) The same identifiers used for MIPs and/or MEPs SHOULD be | |||
applied to maintenance points for the HPSM when they are | applied to maintenance points for the HPSM when they are | |||
instantiated in the same place along a transport path. | instantiated in the same place along a transport path. | |||
Anyway maintenance points for the HPSM may be different from MIPs | Maintenance points for the HPSM may be different from the | |||
and MEPs functional components as defined in the OAM framework | functional components of MIPs and MEPs as defined in the OAM | |||
document RFC 6371 [RFC6371]. Investigating potential solutions | framework document [RFC6371]. Investigating potential | |||
for satisfying proposed HPSM requirements might lead to propose | solutions for satisfying HPSM requirements may lead to | |||
new functional components that have to be backward compatible with | identifying new functional components; these components need to | |||
MPLS architecture. Solutions are outside the scope of this | be backward compatible with MPLS architecture. Solutions are | |||
document. | outside the scope of this document. | |||
4.9. Supported OAM functions | 4.9. Supported OAM Functions | |||
A maintenance point supporting the HPSM function has to be able to | A maintenance point supporting the HPSM function has to be able to | |||
generate and inject OAM packets. OAM functions that may be | generate and inject OAM packets. OAM functions that may be | |||
applicable for on-demand HPSM are basically the on-demand performance | applicable for on-demand HPSM are basically the on-demand performance | |||
monitoring functions which are defined in the OAM framework document | monitoring functions that are defined in the OAM framework document | |||
RFC 6371 [RFC6371]. The "on-demand" attribute is typically temporary | [RFC6371]. The "on-demand" attribute is typically temporary for | |||
for maintenance operation. | maintenance operation. | |||
(M12) HPSM MUST support Packet Loss and Packet Delay measurement. | (M12) HPSM MUST support Packet Loss and Packet Delay measurement. | |||
That because these functions are normally only supported at the end | These functions are normally only supported at the endpoints of a | |||
points of a transport path. If a defect occurs, it might be quite | transport path. If a defect occurs, it might be quite hard to locate | |||
hard to locate the defect or degradation point without using the | the defect or degradation point without using the segment monitoring | |||
segment monitoring function. If an operator cannot locate or narrow | function. If an operator cannot locate or narrow down the cause of | |||
down the cause of the fault, it is quite difficult to take prompt | the fault, it is quite difficult to take prompt actions to solve the | |||
actions to solve the problem. | problem. | |||
Other on-demand monitoring functions (e.g. Delay Variation | Other on-demand monitoring functions (e.g., Delay Variation | |||
measurement) are desirable but not as necessary as the functions | measurement) are desirable but not as necessary as the functions | |||
mentioned above. | mentioned above. | |||
(O3) HPSM MAY support Packet Delay variation, Throughput | (O3) HPSM MAY support Packet Delay variation, Throughput | |||
measurement and other performance monitoring and fault management | measurement, and other performance monitoring and fault | |||
functions. | management functions. | |||
Support of out-of-service on-demand performance management functions | Support of out-of-service on-demand performance-management functions | |||
(e.g. Throughput measurement) is not required for HPSM. | (e.g., Throughput measurement) is not required for HPSM. | |||
5. Summary | 5. Summary | |||
A new hitless path segment monitoring (HPSM) mechanism is required to | A new HPSM mechanism is required to provide on-demand path segment | |||
provide on-demand segment monitoring without traffic disruption. It | monitoring without traffic disruption. It shall meet the two network | |||
shall meet the two network objectives described in section 3.8 of RFC | objectives described in Section 3.8 of [RFC6371] and summarized in | |||
6371 [RFC6371] and summarized in Section 3 of this document. | Section 3 of this document. | |||
The mechanism should minimize the problems described in Section 3, | The mechanism should minimize the problems described in Section 3, | |||
i.e. (P1), (P2) and (P3). | i.e., (P1), (P2), and (P3). | |||
The solution for the on-demand segment monitoring without traffic | The solution for the on-demand path segment monitoring without | |||
disruption needs to cover both the per-node model and the per- | traffic disruption needs to cover both the per-node model and the | |||
interface model specified in RFC 6371 [RFC6371]. | per-interface model specified in [RFC6371]. | |||
The on-demand segment monitoring without traffic disruption solution | The on-demand path segment monitoring without traffic disruption | |||
needs to support on-demand Packet Loss Measurement and Packet Delay | solution needs to support on-demand Packet Loss Measurement and | |||
Measurement functions and optionally other performance monitoring and | Packet Delay Measurement functions and optionally other performance | |||
fault management functions (e.g. Throughput measurement, Packet | monitoring and fault management functions (e.g., Throughput | |||
Delay variation measurement, Diagnostic test, etc.). | measurement, Packet Delay variation measurement, Diagnostic test, | |||
etc.). | ||||
6. Security Considerations | 6. Security Considerations | |||
Security is a significant requirement of MPLS Transport Profile. The | Security is a significant requirement of the MPLS Transport Profile. | |||
document provides a problem statement and requirements to guide the | This document provides a problem statement and requirements to guide | |||
development of new OAM tools to support Hitless Path Segment | the development of new OAM tools to support HPSM. Such new tools | |||
Monitoring. Such new tools must follow the security considerations | must follow the security considerations provided in OAM Requirements | |||
provided in OAM Requirements for MPLS-TP in RFC5860 [RFC5860]. | for MPLS-TP in [RFC5860]. | |||
7. IANA Considerations | 7. IANA Considerations | |||
There are no requests for IANA actions in this document. | This document does not require any IANA actions. | |||
Note to the RFC Editor - this section can be removed before | ||||
publication. | ||||
8. Contributors | ||||
Manuel Paul | ||||
Deutsche Telekom AG | ||||
Email: manuel.paul@telekom.de | ||||
9. Acknowledgements | ||||
The authors would also like to thank Alexander Vainshtein, Dave | ||||
Allan, Fei Zhang, Huub van Helvoort, Malcolm Betts, Italo Busi, | ||||
Maarten Vissers, Jia He and Nurit Sprecher for their comments and | ||||
enhancements to the text. | ||||
10. References | 8. References | |||
10.1. Normative References | 8.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- | DOI 10.17487/RFC2119, March 1997, | |||
editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol | [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol | |||
Label Switching Architecture", RFC 3031, | Label Switching Architecture", RFC 3031, | |||
DOI 10.17487/RFC3031, January 2001, <https://www.rfc- | DOI 10.17487/RFC3031, January 2001, | |||
editor.org/info/rfc3031>. | <https://www.rfc-editor.org/info/rfc3031>. | |||
[RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., | [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., | |||
"Requirements for Operations, Administration, and | "Requirements for Operations, Administration, and | |||
Maintenance (OAM) in MPLS Transport Networks", RFC 5860, | Maintenance (OAM) in MPLS Transport Networks", RFC 5860, | |||
DOI 10.17487/RFC5860, May 2010, <https://www.rfc- | DOI 10.17487/RFC5860, May 2010, | |||
editor.org/info/rfc5860>. | <https://www.rfc-editor.org/info/rfc5860>. | |||
10.2. Informative References | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | ||||
8.2. Informative References | ||||
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, | [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, | |||
L., and L. Berger, "A Framework for MPLS in Transport | L., and L. Berger, "A Framework for MPLS in Transport | |||
Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, | Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, | |||
<https://www.rfc-editor.org/info/rfc5921>. | <https://www.rfc-editor.org/info/rfc5921>. | |||
[RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, | [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, | |||
Administration, and Maintenance Framework for MPLS-Based | Administration, and Maintenance Framework for MPLS-Based | |||
Transport Networks", RFC 6371, DOI 10.17487/RFC6371, | Transport Networks", RFC 6371, DOI 10.17487/RFC6371, | |||
September 2011, <https://www.rfc-editor.org/info/rfc6371>. | September 2011, <https://www.rfc-editor.org/info/rfc6371>. | |||
[RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport | [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport | |||
Profile (MPLS-TP) Survivability Framework", RFC 6372, | Profile (MPLS-TP) Survivability Framework", RFC 6372, | |||
DOI 10.17487/RFC6372, September 2011, <https://www.rfc- | DOI 10.17487/RFC6372, September 2011, | |||
editor.org/info/rfc6372>. | <https://www.rfc-editor.org/info/rfc6372>. | |||
Contributors | ||||
Manuel Paul | ||||
Deutsche Telekom AG | ||||
Email: manuel.paul@telekom.de | ||||
Acknowledgements | ||||
The authors would also like to thank Alexander Vainshtein, Dave | ||||
Allan, Fei Zhang, Huub van Helvoort, Malcolm Betts, Italo Busi, | ||||
Maarten Vissers, Jia He, and Nurit Sprecher for their comments and | ||||
enhancements to the text. | ||||
Authors' Addresses | Authors' Addresses | |||
Alessandro D'Alessandro | Alessandro D'Alessandro | |||
Telecom Italia | Telecom Italia | |||
Via Reiss Romoli, 274 | Via Reiss Romoli, 274 | |||
Torino 10148 | Torino 10148 | |||
Italy | Italy | |||
Email: alessandro.dalessandro@telecomitalia.it | Email: alessandro.dalessandro@telecomitalia.it | |||
Loa Andersson | Loa Andersson | |||
Huawei Technologies | Huawei Technologies | |||
Email: loa@mail01.huawei.com | Email: loa@pi.nu | |||
Satoshi Ueno | Satoshi Ueno | |||
NTT Communications | NTT Communications | |||
Email: satoshi.ueno@ntt.com | Email: ueno@nttv6.jp | |||
Kaoru Arai | Kaoru Arai | |||
NTT | NTT | |||
Email: arai.kaoru@lab.ntt.co.jp | Email: arai.kaoru@lab.ntt.co.jp | |||
Yoshinori Koike | Yoshinori Koike | |||
NTT | NTT | |||
Email: y.koike@vcd.nttbiz.com | Email: y.koike@vcd.nttbiz.com | |||
End of changes. 115 change blocks. | ||||
328 lines changed or deleted | 330 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |