draft-ietf-mpls-tp-oam-framework-10.txt | draft-ietf-mpls-tp-oam-framework-11.txt | |||
---|---|---|---|---|
MPLS Working Group I. Busi (Ed) | MPLS Working Group I. Busi (Ed) | |||
Internet Draft Alcatel-Lucent | Internet Draft Alcatel-Lucent | |||
Intended status: Informational D. Allan (Ed) | Intended status: Informational D. Allan (Ed) | |||
Ericsson | Ericsson | |||
Expires: June 16, 2011 December 16, 2010 | Expires: August 11, 2011 February 11, 2011 | |||
Operations, Administration and Maintenance Framework for MPLS- | Operations, Administration and Maintenance Framework for | |||
based Transport Networks | MPLS-based Transport Networks | |||
draft-ietf-mpls-tp-oam-framework-10.txt | draft-ietf-mpls-tp-oam-framework-11.txt | |||
Abstract | Abstract | |||
The Transport Profile of Multi-Protocol Label Switching | The Transport Profile of Multi-Protocol Label Switching | |||
(MPLS-TP) is a packet-based transport technology based on the | (MPLS-TP) is a packet-based transport technology based on the | |||
MPLS Traffic Engineering (MPLS-TE) and Pseudowire (PW) data | MPLS Traffic Engineering (MPLS-TE) and Pseudowire (PW) data | |||
plane architectures. | plane architectures. | |||
This document describes a framework to support a comprehensive | This document describes a framework to support a comprehensive | |||
set of Operations, Administration and Maintenance (OAM) | set of Operations, Administration and Maintenance (OAM) | |||
skipping to change at page 2, line 11 | skipping to change at page 2, line 11 | |||
documents at any time. It is inappropriate to use Internet- | documents at any time. It is inappropriate to use Internet- | |||
Drafts as reference material or to cite them other than as "work | Drafts as reference material or to cite them other than as "work | |||
in progress". | in progress". | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on June 16, 2011. | This Internet-Draft will expire on August 11, 2011. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2011 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 | carefully, as they describe your rights and restrictions with | |||
respect to this document. Code Components extracted from this | respect to this document. Code Components extracted from this | |||
document must include Simplified BSD License text as described | document must include Simplified BSD License text as described | |||
in Section 4.e of the Trust Legal Provisions and are provided | in Section 4.e of the Trust Legal Provisions and are provided | |||
without warranty as described in the Simplified BSD License. | without warranty as described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction..................................................5 | 1. Introduction..................................................5 | |||
1.1. Contributing Authors.....................................6 | 1.1. Contributing Authors.....................................7 | |||
2. Conventions used in this document.............................7 | 2. Conventions used in this document.............................7 | |||
2.1. Terminology..............................................7 | 2.1. Terminology..............................................7 | |||
2.2. Definitions..............................................8 | 2.2. Definitions..............................................9 | |||
3. Functional Components........................................12 | 3. Functional Components........................................12 | |||
3.1. Maintenance Entity and Maintenance Entity Group.........12 | 3.1. Maintenance Entity and Maintenance Entity Group.........12 | |||
3.2. Nested MEGs: SPMEs and Tandem Connection Monitoring.....14 | 3.2. MEG Nesting: SPMEs and Tandem Connection Monitoring.....14 | |||
3.3. MEG End Points (MEPs)...................................16 | 3.3. MEG End Points (MEPs)...................................16 | |||
3.4. MEG Intermediate Points (MIPs)..........................19 | 3.4. MEG Intermediate Points (MIPs)..........................20 | |||
3.5. Server MEPs.............................................21 | 3.5. Server MEPs.............................................22 | |||
3.6. Configuration Considerations............................22 | 3.6. Configuration Considerations............................23 | |||
3.7. P2MP considerations.....................................22 | 3.7. P2MP considerations.....................................23 | |||
3.8. Further considerations of enhanced segment monitoring...23 | 3.8. Further considerations of enhanced segment monitoring...24 | |||
4. Reference Model..............................................25 | 4. Reference Model..............................................26 | |||
4.1. MPLS-TP Section Monitoring (SMEG).......................27 | 4.1. MPLS-TP Section Monitoring (SMEG).......................28 | |||
4.2. MPLS-TP LSP End-to-End Monitoring Group (LMEG)..........28 | 4.2. MPLS-TP LSP End-to-End Monitoring Group (LMEG)..........29 | |||
4.3. MPLS-TP PW Monitoring (PMEG)............................28 | 4.3. MPLS-TP PW Monitoring (PMEG)............................29 | |||
4.4. MPLS-TP LSP SPME Monitoring (LSMEG).....................29 | 4.4. MPLS-TP LSP SPME Monitoring (LSMEG).....................30 | |||
4.5. MPLS-TP MS-PW SPME Monitoring (PSMEG)...................30 | 4.5. MPLS-TP MS-PW SPME Monitoring (PSMEG)...................31 | |||
4.6. Fate sharing considerations for multilink...............32 | 4.6. Fate sharing considerations for multilink...............33 | |||
5. OAM Functions for proactive monitoring.......................32 | 5. OAM Functions for proactive monitoring.......................33 | |||
5.1. Continuity Check and Connectivity Verification..........33 | 5.1. Continuity Check and Connectivity Verification..........34 | |||
5.1.1. Defects identified by CC-V.........................36 | 5.1.1. Defects identified by CC-V.........................37 | |||
5.1.2. Consequent action..................................37 | 5.1.2. Consequent action..................................39 | |||
5.1.3. Configuration considerations.......................38 | 5.1.3. Configuration considerations.......................40 | |||
5.2. Remote Defect Indication................................40 | 5.2. Remote Defect Indication................................42 | |||
5.2.1. Configuration considerations.......................40 | 5.2.1. Configuration considerations.......................43 | |||
5.3. Alarm Reporting.........................................41 | 5.3. Alarm Reporting.........................................43 | |||
5.4. Lock Reporting..........................................42 | 5.4. Lock Reporting..........................................44 | |||
5.5. Packet Loss Measurement.................................44 | 5.5. Packet Loss Measurement.................................46 | |||
5.5.1. Configuration considerations.......................45 | 5.5.1. Configuration considerations.......................47 | |||
5.5.2. Sampling skew......................................45 | 5.5.2. Sampling skew......................................48 | |||
5.5.3. Multilink issues...................................45 | 5.5.3. Multilink issues...................................48 | |||
5.6. Packet Delay Measurement................................46 | 5.6. Packet Delay Measurement................................48 | |||
5.6.1. Configuration considerations.......................46 | 5.6.1. Configuration considerations.......................49 | |||
5.7. Client Failure Indication...............................47 | 5.7. Client Failure Indication...............................49 | |||
5.7.1. Configuration considerations.......................47 | 5.7.1. Configuration considerations.......................50 | |||
6. OAM Functions for on-demand monitoring.......................48 | 6. OAM Functions for on-demand monitoring.......................50 | |||
6.1. Connectivity Verification...............................48 | 6.1. Connectivity Verification...............................51 | |||
6.1.1. Configuration considerations.......................49 | 6.1.1. Configuration considerations.......................52 | |||
6.2. Packet Loss Measurement.................................50 | 6.2. Packet Loss Measurement.................................52 | |||
6.2.1. Configuration considerations.......................50 | 6.2.1. Configuration considerations.......................53 | |||
6.2.2. Sampling skew......................................51 | 6.2.2. Sampling skew......................................53 | |||
6.2.3. Multilink issues...................................51 | 6.2.3. Multilink issues...................................53 | |||
6.3. Diagnostic Tests........................................51 | 6.3. Diagnostic Tests........................................53 | |||
6.3.1. Throughput Estimation.............................51 | 6.3.1. Throughput Estimation..............................53 | |||
6.3.2. Data plane Loopback...............................52 | 6.3.2. Data plane Loopback................................55 | |||
6.4. Route Tracing..........................................54 | 6.4. Route Tracing...........................................57 | |||
6.4.1. Configuration considerations......................54 | 6.4.1. Configuration considerations.......................57 | |||
6.5. Packet Delay Measurement...............................54 | 6.5. Packet Delay Measurement................................57 | |||
6.5.1. Configuration considerations......................55 | 6.5.1. Configuration considerations.......................58 | |||
7. OAM Functions for administration control....................55 | 7. OAM Functions for administration control.....................58 | |||
7.1. Lock Instruct..........................................55 | 7.1. Lock Instruct...........................................58 | |||
7.1.1. Locking a transport path..........................56 | 7.1.1. Locking a transport path...........................59 | |||
7.1.2. Unlocking a transport path........................56 | 7.1.2. Unlocking a transport path.........................59 | |||
8. Security Considerations.....................................57 | 8. Security Considerations......................................60 | |||
9. IANA Considerations.........................................58 | 9. IANA Considerations..........................................61 | |||
10. Acknowledgments............................................58 | 10. Acknowledgments.............................................61 | |||
11. References.................................................59 | 11. References..................................................62 | |||
11.1. Normative References..................................59 | 11.1. Normative References...................................62 | |||
11.2. Informative References................................60 | 11.2. Informative References.................................63 | |||
Editors' Note: | Editors' Note: | |||
This Informational Internet-Draft is aimed at achieving IETF | This Informational Internet-Draft is aimed at achieving IETF | |||
Consensus before publication as an RFC and will be subject to an | Consensus before publication as an RFC and will be subject to an | |||
IETF Last Call. | IETF Last Call. | |||
[RFC Editor, please remove this note before publication as an | [RFC Editor, please remove this note before publication as an | |||
RFC and insert the correct Streams Boilerplate to indicate that | RFC and insert the correct Streams Boilerplate to indicate that | |||
the published RFC has IETF Consensus.] | the published RFC has IETF Consensus.] | |||
skipping to change at page 5, line 28 | skipping to change at page 5, line 28 | |||
RFCs (RFC 5921 [8] and [9]), MPLS-TP is a packet-based transport | RFCs (RFC 5921 [8] and [9]), MPLS-TP is a packet-based transport | |||
technology based on the MPLS Traffic Engineering (MPLS-TE) and Pseudo | technology based on the MPLS Traffic Engineering (MPLS-TE) and Pseudo | |||
Wire (PW) data plane architectures defined in RFC 3031 [1], RFC 3985 | Wire (PW) data plane architectures defined in RFC 3031 [1], RFC 3985 | |||
[2] and RFC 5659 [4]. | [2] and RFC 5659 [4]. | |||
MPLS-TP supports a comprehensive set of Operations, | MPLS-TP supports a comprehensive set of Operations, | |||
Administration and Maintenance (OAM) procedures for fault, | Administration and Maintenance (OAM) procedures for fault, | |||
performance and protection-switching management that do not rely | performance and protection-switching management that do not rely | |||
on the presence of a control plane. | on the presence of a control plane. | |||
In line with [14], existing MPLS OAM mechanisms will be used | In line with [15], existing MPLS OAM mechanisms will be used | |||
wherever possible and extensions or new OAM mechanisms will be | wherever possible and extensions or new OAM mechanisms will be | |||
defined only where existing mechanisms are not sufficient to | defined only where existing mechanisms are not sufficient to | |||
meet the requirements. Some extensions discussed in this | meet the requirements. Some extensions discussed in this | |||
framework may end up as aspirational capabilities and may be | framework may end up as aspirational capabilities and may be | |||
determined to be not tractably realizable in some | determined to be not tractably realizable in some | |||
implementations. Extensions do not deprecate support for | implementations. Extensions do not deprecate support for | |||
existing MPLS OAM capabilities. | existing MPLS OAM capabilities. | |||
The MPLS-TP OAM framework defined in this document provides a | The MPLS-TP OAM framework defined in this document provides a | |||
protocol neutral description of the required OAM functions and | protocol neutral description of the required OAM functions and | |||
of the data plane OAM architecture to support a comprehensive | of the data plane OAM architecture to support a comprehensive | |||
set of OAM procedures that satisfy the MPLS-TP OAM requirements | set of OAM procedures that satisfy the MPLS-TP OAM requirements | |||
of RFC 5860 [11]. In this regard, it defines similar OAM | of RFC 5860 [11]. In this regard, it defines similar OAM | |||
functionality as for existing SONET/SDH and OTN OAM mechanisms | functionality as for existing SONET/SDH and OTN OAM mechanisms | |||
(e.g. [18]). | (e.g. [19]). | |||
The MPLS-TP OAM framework is applicable to sections, Label | The MPLS-TP OAM framework is applicable to sections, Label | |||
Switched Paths (LSPs), Multi-Segment Pseudowires (MS-)PWs and | Switched Paths (LSPs), Multi-Segment Pseudowires (MS-)PWs and | |||
Sub Path Maintenance Entities (SPMEs). It supports co-routed and | Sub Path Maintenance Entities (SPMEs). It supports co-routed and | |||
associated bidirectional p2p transport paths as well as | associated bidirectional p2p transport paths as well as | |||
unidirectional p2p and p2mp transport paths. | unidirectional p2p and p2mp transport paths. | |||
OAM packets that instrument a particular direction of a | OAM packets that instrument a particular direction of a | |||
transport path are subject to the same forwarding treatment | transport path are subject to the same forwarding treatment | |||
(i.e. fate share) as the data traffic and in some cases, where | (i.e. fate-share) as the user data packets and in some cases, | |||
Explicitly TC-encoded-PSC LSPs (E-LSPs) are employed, may be | where Explicitly TC-encoded-PSC LSPs (E-LSPs) are employed, may | |||
required to have common Per-hop Behavior (PHB) scheduling class | be required to have common Per-hop Behavior (PHB) scheduling | |||
(PSC) E2E with the class of traffic monitored. In case of | class (PSC) E2E with the class of traffic monitored. In case of | |||
Label-Only-Inferred-PSC LSP (L-LSP), only one class of traffic | Label-Only-Inferred-PSC LSP (L-LSP), only one class of traffic | |||
needs to be monitored and therefore the OAM packets have common | needs to be monitored and therefore the OAM packets have common | |||
PSC with the monitored traffic class. | PSC with the monitored traffic class. | |||
OAM packets can be distinguished from the data traffic using the | OAM packets can be distinguished from the used data packets | |||
GAL and ACH constructs of RFC 5586 [7] for LSP, SPME and Section | using the GAL and ACH constructs of RFC 5586 [7] for LSP, SPME | |||
or the ACH construct of RFC 5085 [3]and RFC 5586 [7] for | and Section or the ACH construct of RFC 5085 [3] and RFC 5586 | |||
(MS-)PW. | [7] for (MS-)PW. OAM packets are never fragmented and are not | |||
combined with user data in the same packet payload. | ||||
This framework makes certain assumptions as to the utility and | This framework makes certain assumptions as to the utility and | |||
frequency of different classes of measurement that naturally | frequency of different classes of measurement that naturally | |||
suggest different functions are implemented as distinct OAM | suggest different functions are implemented as distinct OAM | |||
flows or messages. This is dictated by the combination of the | flows or packets. This is dictated by the combination of the | |||
class of problem being detected and the need for timeliness of | class of problem being detected and the need for timeliness of | |||
network response to the problem. For example fault detection is | network response to the problem. For example fault detection is | |||
expected to operate on an entirely different time base than | expected to operate on an entirely different time base than | |||
performance monitoring which is also expected to operate on an | performance monitoring which is also expected to operate on an | |||
entirely different time base than in band management | entirely different time base than in-band management | |||
transactions. | transactions. | |||
The remainder of this memo is structured as follow: | ||||
Section 2 covers the definitions and terminology used in this | ||||
memo. | ||||
Section 3 describes the functional component that generates and | Section 3 describes the functional component that generates and | |||
processes OAM packets. | processes OAM packets. | |||
Section 4 describes the reference models for applying OAM | Section 4 describes the reference models for applying OAM | |||
functions to Sections, LSP, MS-PW and their SPMEs. | functions to Sections, LSP, MS-PW and their SPMEs. | |||
Sections 5, 6 and 7 provide a protocol-neutral description of | Sections 5, 6 and 7 provide a protocol-neutral description of | |||
the OAM functions, defined in RFC 5860 [11], aimed at clarifying | the OAM functions, defined in RFC 5860 [11], aimed at clarifying | |||
how the OAM protocol solutions will behave to achieve their | how the OAM protocol solutions will behave to achieve their | |||
functional objectives. | functional objectives. | |||
Section 8 discusses the security implications of OAM protocol | ||||
design in the MPLS-TP context. | ||||
The OAM protocol solutions designed as a consequence of this | ||||
document are expected to comply with the functional behavior | ||||
described in sections 5, 6 and 7. Alternative solutions to | ||||
required functional behaviors may also be defined. | ||||
OAM specifications following this OAM framework may be provided | ||||
in different documents to cover distinct OAM functions. | ||||
This document is a product of a joint Internet Engineering Task | This document is a product of a joint Internet Engineering Task | |||
Force (IETF) / International Telecommunication Union | Force (IETF) / International Telecommunication Union | |||
Telecommunication Standardization Sector (ITU-T) effort to | Telecommunication Standardization Sector (ITU-T) effort to | |||
include an MPLS Transport Profile within the IETF MPLS and PWE3 | include an MPLS Transport Profile within the IETF MPLS and PWE3 | |||
architectures to support the capabilities and functionalities of | architectures to support the capabilities and functionalities of | |||
a packet transport network as defined by the ITU-T. | a packet transport network as defined by the ITU-T. | |||
1.1. Contributing Authors | 1.1. Contributing Authors | |||
Dave Allan, Italo Busi, Ben Niven-Jenkins, Annamaria Fulignoli, | Dave Allan, Italo Busi, Ben Niven-Jenkins, Annamaria Fulignoli, | |||
Enrique Hernandez-Valencia, Lieven Levrau, Vincenzo Sestito, | Enrique Hernandez-Valencia, Lieven Levrau, Vincenzo Sestito, | |||
Nurit Sprecher, Huub van Helvoort, Martin Vigoureux, Yaacov | Nurit Sprecher, Huub van Helvoort, Martin Vigoureux, Yaacov | |||
Weingarten, Rolf Winter | Weingarten, Rolf Winter | |||
2. Conventions used in this document | 2. Conventions used in this document | |||
2.1. Terminology | 2.1. Terminology | |||
AC Attachment Circuit | AC Attachment Circuit | |||
AIS Alarm indication signal | AIS Alarm indication signal | |||
CC Continuity Check | CC Continuity Check | |||
CC-V Continuity Check and Connectivity Verification | CC-V Continuity Check and/or Connectivity Verification | |||
CV Connectivity Verification | CV Connectivity Verification | |||
DBN Domain Border Node | DBN Domain Border Node | |||
E-LSP Explicitly TC-encoded-PSC LSP | E-LSP Explicitly TC-encoded-PSC LSP | |||
ICC ITU Carrier Code | ICC ITU Carrier Code | |||
LER Label Edge Router | LER Label Edge Router | |||
LKR Lock Report | LKR Lock Report | |||
L-LSP Label-Only-Inferred-PSC LSP | L-LSP Label-Only-Inferred-PSC LSP | |||
LM Loss Measurement | LM Loss Measurement | |||
LME LSP Maintenance Entity | ||||
LMEG LSP ME Group | LME LSP Maintenance Entity | |||
LSP Label Switched Path | LMEG LSP ME Group | |||
LSP Label Switched Path | ||||
LSR Label Switching Router | LSR Label Switching Router | |||
LSME LSP SPME ME | LSME LSP SPME ME | |||
LSMEG LSP SPME ME Group | LSMEG LSP SPME ME Group | |||
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 | |||
NMS Network Management System | ||||
PE Provider Edge | NMS Network Management System | |||
PHB Per-hop Behavior | PE Provider Edge | |||
PM Performance Monitoring | PHB Per-hop Behavior | |||
PME PW Maintenance Entity | PM Performance Monitoring | |||
PMEG PW ME Group | PME PW Maintenance Entity | |||
PSC PHB Scheduling Class | PMEG PW ME Group | |||
PSME PW SPME ME | PSC PHB Scheduling Class | |||
PSMEG PW SPME ME Group | PSME PW SPME ME | |||
PW Pseudowire | PSMEG PW SPME ME Group | |||
SLA Service Level Agreement | PW Pseudowire | |||
SME Section Maintenance Entity | SLA Service Level Agreement | |||
SMEG Section ME Group | SME Section Maintenance Entity | |||
SPME Sub-path Maintenance Element | SMEG Section ME Group | |||
S-PE Switching Provider Edge | SPME Sub-path Maintenance Element | |||
TC Traffic Class | S-PE Switching Provider Edge | |||
T-PE Terminating Provider Edge | TC Traffic Class | |||
T-PE Terminating Provider Edge | ||||
2.2. Definitions | 2.2. Definitions | |||
This document uses the terms defined in RFC 5654 [5]. | This document uses the terms defined in RFC 5654 [5]. | |||
This document uses the term 'Per-hop Behavior' as defined in RFC | This document uses the term 'Per-hop Behavior' as defined in RFC | |||
2474 [15]. | 2474 [16]. | |||
This document uses the term LSP to indicate either a service LSP | This document uses the term LSP to indicate either a service LSP | |||
or a transport LSP (as defined in RFC 5921 [8]). | or a transport LSP (as defined in RFC 5921 [8]). | |||
This document uses the term Sub Path Maintenance Element (SPME) | This document uses the term Sub Path Maintenance Element (SPME) | |||
as defined in RFC 5921 [8]. | as defined in RFC 5921 [8]. | |||
This document uses the term traffic profile as defined in RFC | ||||
2475 [13]. | ||||
Where appropriate, the following definitions are aligned with | Where appropriate, the following definitions are aligned with | |||
ITU-T recommendation Y.1731 [20] in order to have a common, | ITU-T recommendation Y.1731 [21] in order to have a common, | |||
unambiguous terminology. They do not however intend to imply a | unambiguous terminology. They do not however intend to imply a | |||
certain implementation but rather serve as a framework to | certain implementation but rather serve as a framework to | |||
describe the necessary OAM functions for MPLS-TP. | describe the necessary OAM functions for MPLS-TP. | |||
Adaptation function: The adaptation function is the interface | Adaptation function: The adaptation function is the interface | |||
between the client (sub)-layer and the server (sub-)layer. | between the client (sub)-layer and the server (sub-)layer. | |||
Branch Node: A node along a point-to-multipoint transport path | Branch Node: A node along a point-to-multipoint transport path | |||
that is connected to more than one downstream node. | that is connected to more than one downstream node. | |||
skipping to change at page 9, line 41 | skipping to change at page 10, line 10 | |||
Domain Border Node (DBN): An intermediate node in an MPLS-TP LSP | Domain Border Node (DBN): An intermediate node in an MPLS-TP LSP | |||
that is at the boundary between two MPLS-TP OAM domains. Such a | that is at the boundary between two MPLS-TP OAM domains. Such a | |||
node may be present on the edge of two domains or may be | node may be present on the edge of two domains or may be | |||
connected by a link to the DBN at the edge of another OAM | connected by a link to the DBN at the edge of another OAM | |||
domain. | domain. | |||
Down MEP: A MEP that receives OAM packets from, and transmits | Down MEP: A MEP that receives OAM packets from, and transmits | |||
them towards, the direction of a server layer. | them towards, the direction of a server layer. | |||
Forwarding Engine: An abstract functional component, residing in | ||||
an LSR, that forwards the packets from an ingress interface | ||||
toward the egress interface(s). | ||||
In-Service: The administrative status of a transport path when | In-Service: The administrative status of a transport path when | |||
it is unlocked. | it is unlocked. | |||
Interface: An interface is the attachment point to a server | Interface: An interface is the attachment point to a server | |||
(sub-)layer e.g., MPLS-TP section or MPLS-TP tunnel. | (sub-)layer e.g., MPLS-TP section or MPLS-TP tunnel. | |||
Intermediate Node: An intermediate node transits traffic for an | Intermediate Node: An intermediate node transits traffic for an | |||
LSP or a PW. An intermediate node may originate OAM flows | LSP or a PW. An intermediate node may originate OAM flows | |||
directed to downstream intermediate nodes or MEPs. | directed to downstream intermediate nodes or MEPs. | |||
skipping to change at page 10, line 15 | skipping to change at page 10, line 36 | |||
Maintenance Entity (ME): Some portion of a transport path that | Maintenance Entity (ME): Some portion of a transport path that | |||
requires management bounded by two points (called MEPs), and the | requires management bounded by two points (called MEPs), and the | |||
relationship between those points to which maintenance and | relationship between those points to which maintenance and | |||
monitoring operations apply (details in section 3.1). | monitoring operations apply (details in section 3.1). | |||
Maintenance Entity Group (MEG): The set of one or more | Maintenance Entity Group (MEG): The set of one or more | |||
maintenance entities that maintain and monitor a section or a | maintenance entities that maintain and monitor a section or a | |||
transport path in an OAM domain. | transport path in an OAM domain. | |||
MEP: A MEG end point (MEP) is capable of initiating (Source MEP) | MEP: A MEG end point (MEP) is capable of initiating (Source MEP) | |||
and terminating (sink MEP) OAM messages for fault management and | and terminating (sink MEP) OAM packets for fault management and | |||
performance monitoring. MEPs define the boundaries of an ME | performance monitoring. MEPs define the boundaries of an ME | |||
(details in section 3.3). | (details in section 3.3). | |||
MIP: A MEG intermediate point (MIP) terminates and processes OAM | MIP: A MEG intermediate point (MIP) terminates and processes OAM | |||
messages that are sent to this particular MIP and may generate | packets that are sent to this particular MIP and may generate | |||
OAM messages in reaction to received OAM messages. It never | OAM packets in reaction to received OAM packets. It never | |||
generates unsolicited OAM messages itself. A MIP resides within | generates unsolicited OAM packets itself. A MIP resides within a | |||
a MEG between MEPs (details in section 3.3). | MEG between MEPs (details in section 3.3). | |||
MPLS-TP Section: As defined in [8], it is a link that can be | MPLS-TP Section: As defined in [8], it is a link that can be | |||
traversed by one or more MPLS-TP LSPs. | traversed by one or more MPLS-TP LSPs. | |||
OAM domain: A domain, as defined in [5], whose entities are | OAM domain: A domain, as defined in [5], whose entities are | |||
grouped for the purpose of keeping the OAM confined within that | grouped for the purpose of keeping the OAM confined within that | |||
domain. An OAM domain contains zero or more MEGs. | domain. An OAM domain contains zero or more MEGs. | |||
Note - within the rest of this document the term "domain" is | Note - within the rest of this document the term "domain" is | |||
used to indicate an "OAM domain" | used to indicate an "OAM domain" | |||
OAM flow: Is the set of all OAM messages originating with a | OAM flow: Is the set of all OAM packets originating with a | |||
specific source MEP that instrument one direction of a MEG (or | specific source MEP that instrument one direction of a MEG (or | |||
possibly both in the special case of dataplane loopback). | possibly both in the special case of data plane loopback). | |||
OAM information element: An atomic piece of information | ||||
exchanged between MEPs and/or MIPs in MEG used by an OAM | ||||
application. | ||||
OAM loopback: The capability of a node to be directed by a | OAM loopback: The capability of a node to be directed by a | |||
received OAM message to generate a reply back to the sender. OAM | received OAM packet to generate a reply back to the sender. OAM | |||
loopback can work in-service and can support different OAM | loopback can work in-service and can support different OAM | |||
functions (e.g., bidirectional on-demand connectivity | functions (e.g., bidirectional on-demand connectivity | |||
verification). | verification). | |||
OAM Message: One or more OAM information elements that when | OAM Packet: A packet that carries OAM information between MEPs | |||
exchanged between MEPs or between MEPs and MIPs performs some | and/or MIPs in MEG to perform some OAM functionality (e.g. | |||
OAM functionality (e.g. connectivity verification) | connectivity verification). | |||
OAM Packet: A packet that carries one or more OAM messages (i.e. | ||||
OAM information elements). | ||||
Originating MEP: A MEP that originates an OAM transaction | Originating MEP: A MEP that originates an OAM transaction packet | |||
message (toward a target MIP/MEP) and expects a reply, either | (toward a target MIP/MEP) and expects a reply, either in-band or | |||
in-band or out-of-band, from that target MIP/MEP. The | out-of-band, from that target MIP/MEP. The originating MEP | |||
originating source MEP function always generates the OAM request | always generates the OAM request packets in-band and expects and | |||
packets in-band while the originating sink MEP function expects | processes only OAM reply packets returned by the target MIP/MEP. | |||
and processes only OAM reply packets that are sent in-band by | ||||
the target MIP/MEP. | ||||
Out-of-Service: The administrative status of a transport path | Out-of-Service: The administrative status of a transport path | |||
when it is locked. When a path is in a locked condition, it is | when it is locked. When a path is in a locked condition, it is | |||
blocked from carrying client traffic. | blocked from carrying client traffic. | |||
Path Segment: It is either a segment or a concatenated segment, | Path Segment: It is either a segment or a concatenated segment, | |||
as defined in RFC 5654 [5]. | as defined in RFC 5654 [5]. | |||
Signal Degrade: A condition declared by a MEP when the data | Signal Degrade: A condition declared by a MEP when the data | |||
forwarding capability associated with a transport path has | forwarding capability associated with a transport path has | |||
deteriorated, as determined by performance monitoring (PM). See also | deteriorated, as determined by performance monitoring (PM). See also | |||
ITU-T recommendation G.806 [13]. | ITU-T recommendation G.806 [14]. | |||
Signal Fail: A condition declared by a MEP when the data | Signal Fail: A condition declared by a MEP when the data | |||
forwarding capability associated with a transport path has | forwarding capability associated with a transport path has | |||
failed, e.g. loss of continuity. See also ITU-T recommendation | failed, e.g. loss of continuity. See also ITU-T recommendation | |||
G.806 [13]. | G.806 [14]. | |||
Sink MEP: A MEP acts as a sink MEP for an OAM message when it | Sink MEP: A MEP acts as a sink MEP for an OAM packet when it | |||
terminates and processes the messages received from its | terminates and processes the packets received from its | |||
associated MEG. | associated MEG. | |||
Source MEP: A MEP acts as source MEP for an OAM message when it | Source MEP: A MEP acts as source MEP for an OAM packet when it | |||
originates and inserts the message into the transport path for | originates and inserts the packet into the transport path for | |||
its associated MEG. | its associated MEG. | |||
Tandem Connection: A tandem connection is an arbitrary part of a | Tandem Connection: A tandem connection is an arbitrary part of a | |||
transport path that can be monitored (via OAM) independent of | transport path that can be monitored (via OAM) independent of | |||
the end-to-end monitoring (OAM). The tandem connection may also | the end-to-end monitoring (OAM). The tandem connection may also | |||
include the forwarding engine(s) of the node(s) at the | include the forwarding engine(s) of the node(s) at the | |||
boundaries of the tandem connection. Tandem connections may be | boundaries of the tandem connection. Tandem connections may be | |||
nested but cannot overlap. See also ITU-T recommendation G.805 | nested but cannot overlap. See also ITU-T recommendation G.805 | |||
[19]. | [20]. | |||
Target MEP/MIP: A MEP or a MIP that is targeted by OAM | Target MEP/MIP: A MEP or a MIP that is targeted by OAM | |||
transaction messages and that replies to the originating MEP | transaction packets and that replies to the originating MEP that | |||
that initiated the OAM transactions. The Target MEP or MIP can | initiated the OAM transactions. The target MEP or MIP can reply | |||
reply either in-band or out-of-band. The target sink MEP | either in-band or out-of-band. The target sink MEP function | |||
function always receives the OAM request packets in-band while | always receives the OAM request packets in-band while the target | |||
the target source MEP function only generates the OAM reply | source MEP function only generates the OAM reply packets that | |||
packets that are sent in-band. | are sent in-band. | |||
Up MEP: A MEP that transmits OAM packets towards, and receives | Up MEP: A MEP that transmits OAM packets towards, and receives | |||
them from, the direction of the forwarding engine. | them from, the direction of the forwarding engine. | |||
3. Functional Components | 3. Functional Components | |||
MPLS-TP is a packet-based transport technology based on the MPLS | MPLS-TP is a packet-based transport technology based on the MPLS | |||
and PW data plane architectures ([1], [2] and [4]) and is | and PW data plane architectures ([1], [2] and [4]) and is | |||
capable of transporting service traffic where the | capable of transporting service traffic where the | |||
characteristics of information transfer between the transport | characteristics of information transfer between the transport | |||
skipping to change at page 14, line 31 | skipping to change at page 14, line 45 | |||
o Fault conditions - some faults may impact more than one ME | o Fault conditions - some faults may impact more than one ME | |||
depending from where the failure is located; | depending from where the failure is located; | |||
o Packet loss - packet dropping may impact more than one ME | o Packet loss - packet dropping may impact more than one ME | |||
depending from where the packets are lost; | depending from where the packets are lost; | |||
o Packet delay - will be unique per ME. | o Packet delay - will be unique per ME. | |||
Each leaf (i.e. D, E and F) terminates OAM flows to monitor the | Each leaf (i.e. D, E and F) terminates OAM flows to monitor the | |||
ME between itself and the root while the root (i.e. A) generates | ME between itself and the root while the root (i.e. A) generates | |||
OAM messages common to all the MEs of the p2mp MEG. All nodes | OAM packets common to all the MEs of the p2mp MEG. All nodes may | |||
may implement a MIP in the corresponding MEG. | implement a MIP in the corresponding MEG. | |||
3.2. Nested MEGs: SPMEs and Tandem Connection Monitoring | 3.2. MEG Nesting: SPMEs and Tandem Connection Monitoring | |||
In order to verify and maintain performance and quality | In order to verify and maintain performance and quality | |||
guarantees, there is a need to not only apply OAM functionality | guarantees, there is a need to not only apply OAM functionality | |||
on a transport path granularity (e.g. LSP or MS-PW), but also on | on a transport path granularity (e.g. LSP or MS-PW), but also on | |||
arbitrary parts of transport paths, defined as Tandem | arbitrary parts of transport paths, defined as Tandem | |||
Connections, between any two arbitrary points along a transport | Connections, between any two arbitrary points along a transport | |||
path. | path. | |||
Sub-path Maintenance Elements (SPMEs), as defined in [8], are | Sub-path Maintenance Elements (SPMEs), as defined in [8], are | |||
hierarchical LSPs instantiated to provide monitoring of a | hierarchical LSPs instantiated to provide monitoring of a | |||
portion of a set of transport paths (LSPs or MS-PWs) that are | portion of a set of transport paths (LSPs or MS-PWs) that follow | |||
co-routed within the OAM domain. The operational aspects of | the same path between the ingress and the egress of the SPME. | |||
instantiating SPMEs are out of scope of this memo. | The operational aspects of instantiating SPMEs are out of scope | |||
of this memo. | ||||
SPMEs can also be employed to meet the requirement to provide | SPMEs can also be employed to meet the requirement to provide | |||
tandem connection monitoring (TCM), as defined by ITU-T | tandem connection monitoring (TCM), as defined by ITU-T | |||
Recommendation G.805 [19]. | Recommendation G.805 [20]. | |||
TCM for a given path segment of a transport path is implemented | TCM for a given path segment of a transport path is implemented | |||
by creating an SPME that has a 1:1 association with the path | by creating an SPME that has a 1:1 association with the path | |||
segment of the transport path that is to be monitored. | segment of the transport path that is to be monitored. | |||
In the TCM case, this means that the SPME used to provide TCM | In the TCM case, this means that the SPME used to provide TCM | |||
can carry one and only one transport path thus allowing direct | can carry one and only one transport path thus allowing direct | |||
correlation between all fault management and performance | correlation between all fault management and performance | |||
monitoring information gathered for the SPME and the monitored | monitoring information gathered for the SPME and the monitored | |||
path segment of the end-to-end transport path. | path segment of the end-to-end transport path. | |||
There are a number of implications to this approach: | There are a number of implications to this approach: | |||
1) The SPME would use the uniform model [22] of Traffic Class | 1) The SPME would use the uniform model [23] of Traffic Class | |||
(TC) code point copying between sub-layers for diffserv such | (TC) code point copying between sub-layers for diffserv such | |||
that the E2E markings and PHB treatment for the transport | that the E2E markings and PHB treatment for the transport | |||
path was preserved by the SPMEs. | path was preserved by the SPMEs. | |||
2) The SPME normally would use the short-pipe model for TTL | 2) The SPME normally would use the short-pipe model for TTL | |||
handling [6] (no TTL copying between sub-layer) such that the | handling [6] (no TTL copying between sub-layer) such that the | |||
TTL distance to the MIPs for the E2E entity would be not be | TTL distance to the MIPs for the E2E entity would not be | |||
impacted by the presence of the SPME, but it should be | impacted by the presence of the SPME, but it should be | |||
possible for an operator to specify use of the uniform model. | possible for an operator to specify use of the uniform model. | |||
Note that points 1 and 2 above assume that the TTL copying mode | Note that points 1 and 2 above assume that the TTL copying mode | |||
and TC copying modes are independently configurable for an LSP. | and TC copying modes are independently configurable for an LSP. | |||
The TTL distance to the MIPs plays a critical role for | ||||
delivering packets to these MIPs as described in section 3.4. | ||||
There are specific issues with the use of the uniform model of | There are specific issues with the use of the uniform model of | |||
TTL copying for an SPME: | TTL copying for an SPME: | |||
1. A MIP in the SPME sub-layer is not part of the transport path MEG, | 1. A MIP in the SPME sub-layer is not part of the transport path MEG, | |||
hence only an out of band return path for OAM originating in the | hence only an out of band return path for OAM originating in the | |||
transport path MEG that addressed an SPME MIP might be available. | transport path MEG that addressed an SPME MIP might be available. | |||
2. The instantiation of a lower level MEG or protection switching | 2. The instantiation of a lower level MEG or protection switching | |||
actions within a lower level MEG may change the TTL distances to | actions within a lower level MEG may change the TTL distances to | |||
MIPs in the higher level MEGs. | MIPs in the higher level MEGs. | |||
The endpoints of the SPME are MEPs and limit the scope of an OAM | The endpoints of the SPME are MEPs and limit the scope of an OAM | |||
flow within the MEG that the MEPs belong to (i.e. within the | flow within the MEG that the MEPs belong to (i.e. within the | |||
domain of the SPME that is being monitored and managed). | domain of the SPME that is being monitored and managed). | |||
When considering SPMEs, it is important to consider that the | When considering SPMEs, it is important to consider that the | |||
following properties apply to all MPLS-TP MEGs (regardless of | following properties apply to all MPLS-TP MEGs (regardless of | |||
whether they instrument LSPs, SPMEs or MS-PWs): | whether they instrument LSPs, SPMEs or MS-PWs): | |||
o They can be nested but not overlapped, e.g. a MEG may cover a | o They can be nested but not overlapped, e.g. a MEG may cover a | |||
path segment of another MEG, and may also include the | path segment of another MEG, and may also include the | |||
forwarding engine(s) of the node(s) at the edge(s) of the | forwarding engine(s) of the node(s) at the edge(s) of the | |||
path segment. However when MEGs are nested, the MEPs and MIPs | path segment. However when MEGs are nested, the MEPs and MIPs | |||
in the nested MEG are no longer part of the encompassing MEG. | in the SPME are no longer part of the encompassing MEG. | |||
o It is possible that MEPs of nested MEGs reside on a single | o It is possible that MEPs of MEGs that are nested reside on a | |||
node but again implemented in such a way that they do not | single node but again implemented in such a way that they do | |||
overlap. | not overlap. | |||
o Each OAM flow is associated with a single MEG | o Each OAM flow is associated with a single MEG | |||
o When a SPME is instantiated after the transport path has been | o When a SPME is instantiated after the transport path has been | |||
instantiated the TTL distance to the MIPs will change for the | instantiated the TTL distance to the MIPs may change for the | |||
pipe model of TTL copying, and will change for the uniform | short-pipe model of TTL copying, and may change for the | |||
model if the SPME is not co-routed with the original path. | uniform model if the SPME is not co-routed with the original | |||
path. | ||||
3.3. MEG End Points (MEPs) | 3.3. MEG End Points (MEPs) | |||
MEG End Points (MEPs) are the source and sink points of a MEG. | MEG End Points (MEPs) are the source and sink points of a MEG. | |||
In the context of an MPLS-TP LSP, only LERs can implement MEPs | In the context of an MPLS-TP LSP, only LERs can implement MEPs | |||
while in the context of an SPME, any LSR of the MPLS-TP LSP can | while in the context of an SPME, any LSR of the MPLS-TP LSP can | |||
be an LER of SPMEs that contributes to the overall monitoring | be an LER of SPMEs that contributes to the overall monitoring | |||
infrastructure of the transport path. Regarding PWs, only T-PEs | infrastructure of the transport path. Regarding PWs, only T-PEs | |||
can implement MEPs while for SPMEs supporting one or more PWs | can implement MEPs while for SPMEs supporting one or more PWs | |||
both T-PEs and S-PEs can implement SPME MEPs. Any MPLS-TP LSR | both T-PEs and S-PEs can implement SPME MEPs. Any MPLS-TP LSR | |||
can implement a MEP for an MPLS-TP Section. | can implement a MEP for an MPLS-TP Section. | |||
MEPs are responsible for originating all of the proactive and | MEPs are responsible for originating almost all of the proactive | |||
on-demand monitoring OAM functionality for the MEG. There is a | and on-demand monitoring OAM functionality for the MEG. There is | |||
separate class of notifications (such as Lock report (LKR) and | a separate class of notifications (such as Lock report (LKR) and | |||
Alarm indication signal (AIS)) that are originated by | Alarm indication signal (AIS)) that are originated by | |||
intermediate nodes and triggered by server layer events. A MEP | intermediate nodes and triggered by server layer events. A MEP | |||
is capable of originating and terminating OAM messages for fault | is capable of originating and terminating OAM packets for fault | |||
management and performance monitoring. These OAM messages are | management and performance monitoring. These OAM packets are | |||
encapsulated into an OAM packet using the G-ACh with an | carried within the G-ACh with the proper encapsulation and an | |||
appropriate channel type as defined in RFC 5586 [7]. A MEP | appropriate channel type as defined in RFC 5586 [7]. A MEP | |||
terminates all the OAM packets it receives from the MEG it | terminates all the OAM packets it receives from the MEG it | |||
belongs to and silently discards those that do not (note in the | belongs to and silently discards those that do not (note in the | |||
particular case of Connectivity Verification (CV) processing a | particular case of Connectivity Verification (CV) processing a | |||
CV message from an incorrect MEG will result in a mis- | CV packet from an incorrect MEG will result in a | |||
connectivity defect and there are further actions taken). The | mis-connectivity defect and there are further actions taken). | |||
MEG the OAM packet belongs to is inferred from the MPLS or PW | The MEG the OAM packet belongs to is associated with the MPLS or | |||
label or, in case of an MPLS-TP section, the MEG is inferred | PW label. Whether the label is used to infer the MEG or the | |||
from the port on which an OAM packet was received with the GAL | content of the OAM packet is an implementation choice. In the | |||
at the top of the label stack. | case of an MPLS-TP section, the MEG is inferred from the port on | |||
which an OAM packet was received with the GAL at the top of the | ||||
label stack. | ||||
OAM packets may require the use of an available "out-of-band" | OAM packets may require the use of an available "out-of-band" | |||
return path (as defined in [8]). In such cases sufficient | return path (as defined in [8]). In such cases sufficient | |||
information is required in the originating transaction such that | information is required in the originating transaction such that | |||
the OAM reply packet can be constructed (e.g. IP address). | the OAM reply packet can be constructed and properly forwarded | |||
to the originating MEP (e.g. IP address). | ||||
Each OAM solution document will further detail the applicability | Each OAM solution document will further detail the applicability | |||
of the tools it defines as a pro-active or on-demand mechanism | of the tools it defines as a pro-active or on-demand mechanism | |||
as well as its usage when: | as well as its usage when: | |||
o The "in-band" return path exists and it is used; | o The "in-band" return path exists and it is used; | |||
o An "out-of-band" return path exists and it is used; | o An "out-of-band" return path exists and it is used; | |||
o Any return path does not exist or is not used. | o Any return path does not exist or is not used. | |||
Once a MEG is configured, the operator can configure which | Once a MEG is configured, the operator can configure which | |||
proactive OAM functions to use on the MEG but the MEPs are | proactive OAM functions to use on the MEG but the MEPs are | |||
always enabled. A node at the edge of a MEG always supports a | always enabled. | |||
MEP. | ||||
MEPs terminate all OAM packets received from the associated MEG. | MEPs terminate all OAM packets received from the associated MEG. | |||
As the MEP corresponds to the termination of the forwarding path | As the MEP corresponds to the termination of the forwarding path | |||
for a MEG at the given (sub-)layer, OAM packets never leak | for a MEG at the given (sub-)layer, OAM packets never leak | |||
outside of a MEG in a properly configured fault-free | outside of a MEG in a properly configured fault-free | |||
implementation. | implementation. | |||
A MEP of an MPLS-TP transport path coincides with transport path | A MEP of an MPLS-TP transport path coincides with transport path | |||
termination and monitors it for failures or performance | termination and monitors it for failures or performance | |||
degradation (e.g. based on packet counts) in an end-to-end | degradation (e.g. based on packet counts) in an end-to-end | |||
skipping to change at page 17, line 49 | skipping to change at page 18, line 19 | |||
monitor a path segment of the transport path for failures or | monitor a path segment of the transport path for failures or | |||
performance degradation (e.g. based on packet counts) only | performance degradation (e.g. based on packet counts) only | |||
within the boundary of the MEG for the SPME. | within the boundary of the MEG for the SPME. | |||
An MPLS-TP sink MEP passes a fault indication to its client | An MPLS-TP sink MEP passes a fault indication to its client | |||
(sub-)layer network as a consequent action of fault detection. | (sub-)layer network as a consequent action of fault detection. | |||
When the client layer is not MPLS TP, the consequent actions in | When the client layer is not MPLS TP, the consequent actions in | |||
the client layer (e.g., ignore or generate client layer specific | the client layer (e.g., ignore or generate client layer specific | |||
OAM notifications) are outside the scope of this document. | OAM notifications) are outside the scope of this document. | |||
A node at the edge of a MEG can either support per-node MEP or | A node hosting a MEP can either support per-node MEP or per- | |||
per-interface MEP(s). A per-node MEP resides in an unspecified | interface MEP(s). A per-node MEP resides in an unspecified | |||
location within the node while a per-interface MEP resides on a | location within the node while a per-interface MEP resides on a | |||
specific side of the forwarding engine. In particular a per- | specific side of the forwarding engine. In particular a per- | |||
interface MEP is called "Up MEP" or "Down MEP" depending on its | interface MEP is called "Up MEP" or "Down MEP" depending on its | |||
location relative to the forwarding engine. An "Up MEP" | location relative to the forwarding engine. An "Up MEP" | |||
transmits OAM packets towards, and receives them from, the | transmits OAM packets towards, and receives them from, the | |||
direction of the forwarding engine, while a "Down MEP" receives | direction of the forwarding engine, while a "Down MEP" receives | |||
OAM packets from, and transmits them towards, the direction of a | OAM packets from, and transmits them towards, the direction of a | |||
server layer. | server layer. | |||
Conceptually these "per interface" MIP locations can be mapped | ||||
to the MPLS architecture by associating the MIP points with | ||||
FTN/ILM/NHLFE processing, such that the MIP positioning within a | ||||
node logically bookends the NHLFE processing step of how a | ||||
packet is handled by an LSR/LER (either prior to or post label | ||||
processing and packet forwarding). A nodal MIP makes no | ||||
representation as to where in a nodes packet handling process a | ||||
MIP is located. | ||||
Source node Up MEP Destination node Up MEP | Source node Up MEP Destination node Up MEP | |||
------------------------ ------------------------ | ------------------------ ------------------------ | |||
| | | | | | | | | | |||
|----- -----| |----- -----| | |----- -----| |----- -----| | |||
| MEP | | | | | | MEP | | | MEP | | | | | | MEP | | |||
| | ---- | | | | ---- | | | | | ---- | | | | ---- | | | |||
| In |->-| FW |->-| Out |->- ->-| In |->-| FW |->-| Out | | | In |->-| FW |->-| Out |->- ->-| In |->-| FW |->-| Out | | |||
| i/f | ---- | i/f | | i/f | ---- | i/f | | | i/f | ---- | i/f | | i/f | ---- | i/f | | |||
|----- -----| |----- -----| | |----- -----| |----- -----| | |||
| | | | | | | | | | |||
skipping to change at page 19, line 30 | skipping to change at page 20, line 16 | |||
node MEPs and per-interface MEPs. This guarantees backward | node MEPs and per-interface MEPs. This guarantees backward | |||
compatibility with most of the existing LSRs that can implement | compatibility with most of the existing LSRs that can implement | |||
only a per-node MEP as in current implementations label | only a per-node MEP as in current implementations label | |||
operations are largely performed on the ingress interface, hence | operations are largely performed on the ingress interface, hence | |||
the exposure of the GAL as top label will occur at the ingress | the exposure of the GAL as top label will occur at the ingress | |||
interface. | interface. | |||
Note that a MEP can only exist at the beginning and end of a | Note that a MEP can only exist at the beginning and end of a | |||
(sub-)layer in MPLS-TP. If there is a need to monitor some | (sub-)layer in MPLS-TP. If there is a need to monitor some | |||
portion of that LSP or PW, a new sub-layer in the form of an | portion of that LSP or PW, a new sub-layer in the form of an | |||
SPME is created which permits MEPs and associated MEGs to be | SPME must be created which permits MEPs and associated MEGs to | |||
created. | be created. | |||
In the case where an intermediate node sends a message to a MEP, | In the case where an intermediate node sends an OAM packet to a | |||
it uses the top label of the stack at that point. | MEP, it uses the top label of the stack at that point. | |||
3.4. MEG Intermediate Points (MIPs) | 3.4. MEG Intermediate Points (MIPs) | |||
A MEG Intermediate Point (MIP) is a function located at a point | A MEG Intermediate Point (MIP) is a function located at a point | |||
between the MEPs of a MEG for a PW, LSP or SPME. | between the MEPs of a MEG for a PW, LSP or SPME. | |||
A MIP is capable of reacting to some OAM packets and forwarding all | A MIP is capable of reacting to some OAM packets and forwarding all | |||
the other OAM packets while ensuring fate sharing with data plane | the other OAM packets while ensuring fate sharing with user data | |||
packets. However, a MIP does not initiate unsolicited OAM packets, | packets. However, a MIP does not initiate unsolicited OAM packets, | |||
but may be addressed by OAM packets initiated by one of the MEPs of | but may be addressed by OAM packets initiated by one of the MEPs of | |||
the MEG. A MIP can generate OAM packets only in response to OAM | the MEG. A MIP can generate OAM packets only in response to OAM | |||
packets that it receives from the MEG it belongs to. The OAM messages | packets that it receives from the MEG it belongs to. The OAM packets | |||
generated by the MIP are sent to the originating MEP. | generated by the MIP are sent to the originating MEP. | |||
An intermediate node within a MEG can either: | An intermediate node within a MEG can either: | |||
o Support per-node MIP (i.e. a single MIP per node in an | o Support per-node MIP (i.e. a single MIP per node in an | |||
unspecified location within the node); | unspecified location within the node); | |||
o Support per-interface MIP (i.e. two or more MIPs per node on | o Support per-interface MIP (i.e. two or more MIPs per node on | |||
both sides of the forwarding engine). | both sides of the forwarding engine). | |||
Support of per-interface of per-node MIPs is an implementation | ||||
choice. It is also possible that a node support per-interface | ||||
MIPs on some MEGs and per-node MIPs on other MEGs for which it | ||||
is a transit node. | ||||
Intermediate node | Intermediate node | |||
------------------------ | ------------------------ | |||
| | | | | | |||
|----- -----| | |----- -----| | |||
| MIP | | MIP | | | MIP | | MIP | | |||
| | ---- | | | | | ---- | | | |||
->-| In |->-| FW |->-| Out |->- | ->-| In |->-| FW |->-| Out |->- | |||
| i/f | ---- | i/f | | | i/f | ---- | i/f | | |||
|----- -----| | |----- -----| | |||
skipping to change at page 20, line 32 | skipping to change at page 21, line 29 | |||
intermediate node of a point-to-point MEG. | intermediate node of a point-to-point MEG. | |||
The usage of per-interface MIPs allows the isolation of failures | The usage of per-interface MIPs allows the isolation of failures | |||
or performance degradation to being within a node or either the | or performance degradation to being within a node or either the | |||
link or interfaces. | link or interfaces. | |||
When sending an OAM packet to a MIP, the source MEP should set | When sending an OAM packet to a MIP, the source MEP should set | |||
the TTL field to indicate the number of hops necessary to reach | the TTL field to indicate the number of hops necessary to reach | |||
the node where the MIP resides. | the node where the MIP resides. | |||
The source MEP should also include Target MIP information in the | The source MEP should also include target MIP information in the | |||
OAM packets sent to a MIP to allow proper identification of the | OAM packets sent to a MIP to allow proper identification of the | |||
MIP within the node. The MEG the OAM packet is associated with | MIP within the node. The MEG the OAM packet belongs to is | |||
is inferred from the MPLS label. | associated with the MPLS label. Whether the label is used to | |||
infer the MEG or the content of the OAM packet is an | ||||
implementation choice. In the latter, the MPLS label is checked | ||||
to be the expected one. | ||||
The use of TTL expiry to deliver OAM packets to a specific MIP | The use of TTL expiry to deliver OAM packets to a specific MIP | |||
is not a fully reliable delivery mechanism because the TTL | is not a fully reliable delivery mechanism because the TTL | |||
distance of a MIP from a MEP can change. Any MPLS-TP node | distance of a MIP from a MEP can change. Any MPLS-TP node | |||
silently discards any OAM packet received with an expired TTL | silently discards any OAM packet received with an expired TTL | |||
and that it is not addressed to any of its MIPs or MEPs. An | and that it is not addressed to any of its MIPs or MEPs. An | |||
MPLS-TP node that does not support OAM is also expected to | MPLS-TP node that does not support OAM is also expected to | |||
silently discard any received OAM packet. | silently discard any received OAM packet. | |||
Messages directed to a MIP may not necessarily carry specific | Packets directed to a MIP may not necessarily carry specific MIP | |||
MIP identification information beyond that of TTL distance. In | identification information beyond that of TTL distance. In this | |||
this case a MIP would promiscuously respond to all MEP queries | case a MIP would promiscuously respond to all MEP queries on its | |||
with the correct MEG. This capability could be used for | MEG. This capability could be used for discovery functions | |||
discovery functions (e.g., route tracing as defined in section | (e.g., route tracing as defined in section 6.4) or when it is | |||
6.4) or when it is desirable to leave to the originating MEP the | desirable to leave to the originating MEP the job of correlating | |||
job of correlating TTL and MIP identifiers and noting changes or | TTL and MIP identifiers and noting changes or irregularities | |||
irregularities (via comparison with information previously | (via comparison with information previously extracted from the | |||
extracted from the network). | network). | |||
MIPs are associated to the MEG they belong to and their identity | MIPs are associated to the MEG they belong to and their identity | |||
is unique within the MEG. However, their identity is not | is unique within the MEG. However, their identity is not | |||
necessarily unique to the MEG: e.g. all nodal MIPs in a node can | necessarily unique to the MEG: e.g. all nodal MIPs in a node can | |||
have a common identity. | have a common identity. | |||
A node at the edge of a MEG can also support per-interface Up | A node hosting a MEP can also support per-interface Up MEPs and | |||
MEPs and per-interface MIPs on either side of the forwarding | per-interface MIPs on either side of the forwarding engine. | |||
engine. | ||||
Once a MEG is configured, the operator can enable/disable the | Once a MEG is configured, the operator can enable/disable the | |||
MIPs on the nodes within the MEG. All the intermediate nodes and | MIPs on the nodes within the MEG. All the intermediate nodes and | |||
possibly the end nodes host MIP(s). Local policy allows them to | possibly the end nodes host MIP(s). Local policy allows them to | |||
be enabled per function and per MEG. The local policy is | be enabled per function and per MEG. The local policy is | |||
controlled by the management system, which may delegate it to | controlled by the management system, which may delegate it to | |||
the control plane. A disabled MIP silently discards any received | the control plane. A disabled MIP silently discards any received | |||
OAM packets. | OAM packets. | |||
3.5. Server MEPs | 3.5. Server MEPs | |||
A server MEP is a MEP of a MEG that is either: | A server MEP is a MEP of a MEG that is either: | |||
o Defined in a layer network that is "below", which is to say | o Defined in a layer network that is "below", which is to say | |||
encapsulates and transports the MPLS-TP layer network being | encapsulates and transports the MPLS-TP layer network being | |||
referenced, or | referenced, or | |||
o Defined in a sub-layer of the MPLS-TP layer network that is | o Defined in a sub-layer of the MPLS-TP layer network that is | |||
"below" which is to say encapsulates and transports the | "below" which is to say encapsulates and transports the | |||
sub-layer being referenced. | sub-layer being referenced. | |||
A server MEP can coincide with a MIP or a MEP in the client | A server MEP can coincide with a MIP or a MEP in the client | |||
(MPLS-TP) (sub-)layer network. | (MPLS-TP) (sub-)layer network. | |||
A server MEP also provides server layer OAM indications to the | A server MEP also provides server layer OAM indications to the | |||
client/server adaptation function between the client (MPLS-TP) | client/server adaptation function between the client (MPLS-TP) | |||
(sub-)layer network and the server (sub-)layer network. The | (sub-)layer network and the server (sub-)layer network. The | |||
adaptation function maintains state on the mapping of MPLS-TP | adaptation function maintains state on the mapping of MPLS-TP | |||
transport paths that are setup over that server (sub-)layer's | transport paths that are setup over that server (sub-)layer's | |||
transport path. | transport path. | |||
For example, a server MEP can be either: | For example, a server MEP can be either: | |||
o A termination point of a physical link (e.g. 802.3), an SDH | o A termination point of a physical link (e.g. 802.3), an SDH | |||
VC or OTN ODU, for the MPLS-TP Section layer network, defined | VC or OTN ODU, for the MPLS-TP Section layer network, defined | |||
in section 4.1; | in section 4.1; | |||
o An MPLS-TP Section MEP for MPLS-TP LSPs, defined in section | o An MPLS-TP Section MEP for MPLS-TP LSPs, defined in section | |||
4.2; | 4.2; | |||
o An MPLS-TP LSP MEP for MPLS-TP PWs, defined in section 4.3; | o An MPLS-TP LSP MEP for MPLS-TP PWs, defined in section 4.3; | |||
o An MPLS-TP SPME MEP used for LSP path segment monitoring, as | o An MPLS-TP SPME MEP used for LSP path segment monitoring, as | |||
defined in section 4.4, for MPLS-TP LSPs or higher-level | defined in section 4.4, for MPLS-TP LSPs or higher-level | |||
SPMEs providing LSP path segment monitoring; | SPMEs providing LSP path segment monitoring; | |||
o An MPLS-TP SPME MEP used for PW path segment monitoring, as | o An MPLS-TP SPME MEP used for PW path segment monitoring, as | |||
defined in section 4.5, for MPLS-TP PWs or higher-level SPMEs | defined in section 4.5, for MPLS-TP PWs or higher-level SPMEs | |||
providing PW path segment monitoring. | providing PW path segment monitoring. | |||
The server MEP can run appropriate OAM functions for fault detection | The server MEP can run appropriate OAM functions for fault detection | |||
within the server (sub-)layer network, and provides a fault | within the server (sub-)layer network, and provides a fault | |||
indication to its client MPLS-TP layer network via the client/server | indication to its client MPLS-TP layer network via the client/server | |||
adaptation function. When the server layer is not MPLS-TP, server MEP | adaptation function. When the server layer is not MPLS-TP, server MEP | |||
OAM functions are outside the scope of this document. | OAM functions are simply assumed to exist but are outside the scope | |||
of this document. | ||||
3.6. Configuration Considerations | 3.6. Configuration Considerations | |||
When a control plane is not present, the management plane configures | When a control plane is not present, the management plane configures | |||
these functional components. Otherwise they can be configured either | these functional components. Otherwise they can be configured either | |||
by the management plane or by the control plane. | by the management plane or by the control plane. | |||
Local policy allows disabling the usage of any available "out- | Local policy allows disabling the usage of any available "out- | |||
of-band" return path, as defined in [8], irrespective of what is | of-band" return path, as defined in [8], irrespective of what is | |||
requested by the node originating the OAM packet. | requested by the node originating the OAM packet. | |||
skipping to change at page 23, line 15 | skipping to change at page 24, line 18 | |||
information to identify a target leaf, and therefore is | information to identify a target leaf, and therefore is | |||
processed only by the target leaf and ignored by the other | processed only by the target leaf and ignored by the other | |||
leaves. | leaves. | |||
o To send an OAM packet to a single MIP, the source MEP sends | o To send an OAM packet to a single MIP, the source MEP sends | |||
a single OAM packet with the TTL field indicating the | a single OAM packet with the TTL field indicating the | |||
number of hops necessary to reach the node where the MIP | number of hops necessary to reach the node where the MIP | |||
resides. This packet will be delivered by the forwarding | resides. This packet will be delivered by the forwarding | |||
plane to all intermediate nodes at the same TTL distance of | plane to all intermediate nodes at the same TTL distance of | |||
the target MIP and to any leaf that is located at a shorter | the target MIP and to any leaf that is located at a shorter | |||
distance. The OAM message must contain sufficient | distance. The OAM packet must contain sufficient | |||
information to identify the target MIP and therefore is | information to identify the target MIP and therefore is | |||
processed only by the target MIP. | processed only by the target MIP. | |||
o In order to send an OAM packet to M leaves (i.e., a subset | o In order to send an OAM packet to M leaves (i.e., a subset | |||
of all the leaves), the source MEP sends M different OAM | of all the leaves), the source MEP sends M different OAM | |||
packets targeted to each individual leaf in the group of M | packets targeted to each individual leaf in the group of M | |||
leaves. Aggregated or sub setting mechanisms are outside | leaves. Aggregated or sub setting mechanisms are outside | |||
the scope of this document. | the scope of this document. | |||
A bud node with a Down MEP or a per-node MEP will both terminate | A bud node with a Down MEP or a per-node MEP will both terminate | |||
skipping to change at page 25, line 7 | skipping to change at page 26, line 7 | |||
A further issue that would need to be considered is events that | A further issue that would need to be considered is events that | |||
result in changing the TTL distance to the peer monitoring | result in changing the TTL distance to the peer monitoring | |||
entity such as protection events that may temporarily invalidate | entity such as protection events that may temporarily invalidate | |||
OAM information gleaned from the use of this technique. | OAM information gleaned from the use of this technique. | |||
Further considerations on this technique are outside the scope | Further considerations on this technique are outside the scope | |||
of this document. | of this document. | |||
4. Reference Model | 4. Reference Model | |||
The reference model for the MPLS-TP framework builds upon the | The reference model for the MPLS-TP OAM framework builds upon | |||
concept of a MEG, and its associated MEPs and MIPs, to support | the concept of a MEG, and its associated MEPs and MIPs, to | |||
the functional requirements specified in RFC 5860 [11]. | support the functional requirements specified in RFC 5860 [11]. | |||
The following MPLS-TP MEGs are specified in this document: | The following MPLS-TP MEGs are specified in this document: | |||
o A Section Maintenance Entity Group (SMEG), allowing | o A Section Maintenance Entity Group (SMEG), allowing | |||
monitoring and management of MPLS-TP Sections (between MPLS | monitoring and management of MPLS-TP Sections (between MPLS | |||
LSRs). | LSRs). | |||
o An LSP Maintenance Entity Group (LMEG), allowing monitoring | o An LSP Maintenance Entity Group (LMEG), allowing monitoring | |||
and management of an end-to-end LSP (between LERs). | and management of an end-to-end LSP (between LERs). | |||
o A PW Maintenance Entity Group (PMEG), allowing monitoring and | o A PW Maintenance Entity Group (PMEG), allowing monitoring and | |||
management of an end-to-end SS/MS-PWs (between T-PEs). | management of an end-to-end SS/MS-PWs (between T-PEs). | |||
o An LSP SPME ME Group (LSMEG), allowing monitoring and | o An LSP SPME ME Group (LSMEG), allowing monitoring and | |||
management of an SPME (between a given pair of LERs and/or | management of an SPME (between a given pair of LERs and/or | |||
LSRs along an LSP). | LSRs along an LSP). | |||
o A PW SPME ME Group (PSMEG), allowing monitoring and | o A PW SPME ME Group (PSMEG), allowing monitoring and | |||
management of an SPME (between a given pair of T-PEs and/or | management of an SPME (between a given pair of T-PEs and/or | |||
S-PEs along an (MS-)PW). | S-PEs along an (MS-)PW). | |||
The MEGs specified in this MPLS-TP OAM framework are compliant | The MEGs specified in this MPLS-TP OAM framework are compliant | |||
with the architecture framework for MPLS-TP [8] that includes | with the architecture framework for MPLS-TP [8] that includes | |||
both MS-PWs [4] and LSPs [1]. | both MS-PWs [4] and LSPs [1]. | |||
Hierarchical LSPs are also supported in the form of SPMEs. In | Hierarchical LSPs are also supported in the form of SPMEs. In | |||
this case, each LSP in the hierarchy is a different sub-layer | this case, each LSP in the hierarchy is a different sub-layer | |||
network that can be monitored, independently from higher and | network that can be monitored, independently from higher and | |||
lower level LSPs in the hierarchy, on an end-to-end basis (from | lower level LSPs in the hierarchy, on an end-to-end basis (from | |||
LER to LER) by a SPME. It is possible to monitor a portion of a | LER to LER) by a SPME. It is possible to monitor a portion of a | |||
hierarchical LSP by instantiating a hierarchical SPME between | hierarchical LSP by instantiating a hierarchical SPME between | |||
any LERs/LSRs along the hierarchical LSP. | any LERs/LSRs along the hierarchical LSP. | |||
Native |<------------------ MS-PW1Z ---------------->| Native | Native |<------------------ MS-PW1Z ---------------->| Native | |||
Layer | | Layer | Layer | | Layer | |||
Service | |<LSP13>| |<-LSP3X->| |<LSPXZ>| | Service | Service | |<LSP13>| |<-LSP3X->| |<LSPXZ>| | Service | |||
(AC1) V V V V V V V V (AC2) | (AC1) V V V V V V V V (AC2) | |||
+----+ +---+ +----+ +----+ +---+ +----+ | +----+ +---+ +----+ +----+ +---+ +----+ | |||
+----+ |T-PE| |LSR| |S-PE| |S-PE| |LSR| |T-PE| +----+ | +----+ |T-PE| |LSR| |S-PE| |S-PE| |LSR| |T-PE| +----+ | |||
| | | 1 | | 2 | | 3 | | X | | Y | | Z | | | | ||||
| | | |=======| |=========| |=======| | | | | | | | |=======| |=========| |=======| | | | | |||
| CE1|--|.......PW13......|...PW3X..|......PWXZ.......|---|CE2 | | | CE1|--|.......PW13......|...PW3X..|......PWXZ.......|---|CE2 | | |||
| | | |=======| |=========| |=======| | | | | | | | |=======| |=========| |=======| | | | | |||
+----+ | 1 | | 2 | | 3 | | X | | Y | | Z | +----+ | | | | | | | | | | | | | | | | | | |||
+----+ | | | | | | | | | | | | +----+ | ||||
+----+ +---+ +----+ +----+ +---+ +----+ | +----+ +---+ +----+ +----+ +---+ +----+ | |||
. . . . | . . . . | |||
| | | | | | | | | | |||
|<--- Domain 1 -->| |<--- Domain Z -->| | |<--- Domain 1 -->| |<--- Domain Z -->| | |||
^----------------- PW1Z PME -----------------^ | ^----------------- PW1Z PMEG ----------------^ | |||
^--- PW13 PSMEG---^ ^--- PWXZ PSMEG---^ | ^--- PW13 PSMEG --^ ^--- PWXZ PSMEG --^ | |||
^-------^ ^-------^ | ^-------^ ^-------^ | |||
LSP13 LMEG LSPXZ LMEG | LSP13 LMEG LSPXZ LMEG | |||
^--^ ^--^ ^---------^ ^--^ ^--^ | ^--^ ^--^ ^---------^ ^--^ ^--^ | |||
Sec12 Sec23 Sec3X SecXY SecYZ | Sec12 Sec23 Sec3X SecXY SecYZ | |||
SMEG SMEG SMEG SMEG SMEG | SMEG SMEG SMEG SMEG SMEG | |||
^---^ ME | ^---^ ME | |||
^ MEP | ^ MEP | |||
==== LSP | ==== LSP | |||
.... PW | .... PW | |||
T-PE1: Terminating Provider Edge 1 | T-PE1: Terminating Provider Edge 1 | |||
skipping to change at page 26, line 51 | skipping to change at page 28, line 6 | |||
Figure 5 depicts a high-level reference model for the MPLS-TP | Figure 5 depicts a high-level reference model for the MPLS-TP | |||
OAM framework. The figure depicts portions of two MPLS-TP | OAM framework. The figure depicts portions of two MPLS-TP | |||
enabled network domains, Domain 1 and Domain Z. In Domain 1, | enabled network domains, Domain 1 and Domain Z. In Domain 1, | |||
LSR1 is adjacent to LSR2 via the MPLS-TP Section Sec12 and LSR2 | LSR1 is adjacent to LSR2 via the MPLS-TP Section Sec12 and LSR2 | |||
is adjacent to LSR3 via the MPLS-TP Section Sec23. Similarly, in | is adjacent to LSR3 via the MPLS-TP Section Sec23. Similarly, in | |||
Domain Z, LSRX is adjacent to LSRY via the MPLS-TP Section SecXY | Domain Z, LSRX is adjacent to LSRY via the MPLS-TP Section SecXY | |||
and LSRY is adjacent to LSRZ via the MPLS-TP Section SecYZ. In | and LSRY is adjacent to LSRZ via the MPLS-TP Section SecYZ. In | |||
addition, LSR3 is adjacent to LSRX via the MPLS-TP Section 3X. | addition, LSR3 is adjacent to LSRX via the MPLS-TP Section 3X. | |||
Figure 5 also shows a bi-directional MS-PW (PW1Z) between AC1 on | Figure 5 also shows a bi-directional MS-PW (PW1Z) between AC1 on | |||
T-PE1 and AC2 on T-PEZ. The MS-PW consists of three | T-PE1 and AC2 on T-PEZ. The MS-PW consists of three | |||
bi-directional PW path segments: 1) PW13 path segment between T- | bi-directional PW path segments: 1) PW13 path segment between | |||
PE1 and S-PE3 via the bi-directional LSP13 LSP, 2) PW3X path | T-PE1 and S-PE3 via the bi-directional LSP13 LSP, 2) PW3X path | |||
segment between S-PE3 and S-PEX, via the bi-directional LSP3X | segment between S-PE3 and S-PEX, via the bi-directional LSP3X | |||
LSP, and 3) PWXZ path segment between S-PEX and T-PEZ via the | LSP, and 3) PWXZ path segment between S-PEX and T-PEZ via the | |||
bi-directional LSPXZ LSP. | bi-directional LSPXZ LSP. | |||
The MPLS-TP OAM procedures that apply to a MEG are expected to | The MPLS-TP OAM procedures that apply to a MEG are expected to | |||
operate independently from procedures on other MEGs. Yet, this | operate independently from procedures on other MEGs. Yet, this | |||
does not preclude that multiple MEGs may be affected | does not preclude that multiple MEGs may be affected | |||
simultaneously by the same network condition, for example, a | simultaneously by the same network condition, for example, a | |||
fiber cut event. | fiber cut event. | |||
skipping to change at page 27, line 40 | skipping to change at page 28, line 43 | |||
OAM architecture framework document. Unless otherwise stated, | OAM architecture framework document. Unless otherwise stated, | |||
all references to domains, LSRs, MPLS-TP Sections, LSPs, | all references to domains, LSRs, MPLS-TP Sections, LSPs, | |||
pseudowires and MEGs in this section are made in relation to | pseudowires and MEGs in this section are made in relation to | |||
those shown in Figure 5. | those shown in Figure 5. | |||
4.1. MPLS-TP Section Monitoring (SMEG) | 4.1. MPLS-TP Section Monitoring (SMEG) | |||
An MPLS-TP Section MEG (SMEG) is an MPLS-TP maintenance entity | An MPLS-TP Section MEG (SMEG) is an MPLS-TP maintenance entity | |||
intended to monitor an MPLS-TP Section as defined in RFC 5654 | intended to monitor an MPLS-TP Section as defined in RFC 5654 | |||
[5]. An SMEG may be configured on any MPLS-TP section. SMEG OAM | [5]. An SMEG may be configured on any MPLS-TP section. SMEG OAM | |||
packets must fate share with the user data packets sent over the | packets must fate-share with the user data packets sent over the | |||
monitored MPLS-TP Section. | monitored MPLS-TP Section. | |||
An SMEG is intended to be deployed for applications where it is | An SMEG is intended to be deployed for applications where it is | |||
preferable to monitor the link between topologically adjacent | preferable to monitor the link between topologically adjacent | |||
(next hop in this layer network) MPLS-TP LSRs rather than | (next hop in this layer network) MPLS-TP LSRs rather than | |||
monitoring the individual LSP or PW path segments traversing the | monitoring the individual LSP or PW path segments traversing the | |||
MPLS-TP Section and the server layer technology does not provide | MPLS-TP Section and the server layer technology does not provide | |||
adequate OAM capabilities. | adequate OAM capabilities. | |||
Figure 5 shows five Section MEGs configured in the network | Figure 5 shows five Section MEGs configured in the network | |||
skipping to change at page 28, line 24 | skipping to change at page 29, line 27 | |||
4. SecXY MEG associated with the MPLS-TP Section between LSR X | 4. SecXY MEG associated with the MPLS-TP Section between LSR X | |||
and LSR Y, and | and LSR Y, and | |||
5. SecYZ MEG associated with the MPLS-TP Section between LSR Y | 5. SecYZ MEG associated with the MPLS-TP Section between LSR Y | |||
and LSR Z. | and LSR Z. | |||
4.2. MPLS-TP LSP End-to-End Monitoring Group (LMEG) | 4.2. MPLS-TP LSP End-to-End Monitoring Group (LMEG) | |||
An MPLS-TP LSP MEG (LMEG) is an MPLS-TP maintenance entity group | An MPLS-TP LSP MEG (LMEG) is an MPLS-TP maintenance entity group | |||
intended to monitor an end-to-end LSP between its LERs. An LMEG | intended to monitor an end-to-end LSP between its LERs. An LMEG | |||
may be configured on any MPLS LSP. LMEG OAM packets must fate | may be configured on any MPLS LSP. LMEG OAM packets must | |||
share with user data packets sent over the monitored MPLS-TP | fate-share with user data packets sent over the monitored MPLS- | |||
LSP. | TP LSP. | |||
An LMEG is intended to be deployed in scenarios where it is | An LMEG is intended to be deployed in scenarios where it is | |||
desirable to monitor an entire LSP between its LERs, rather | desirable to monitor an entire LSP between its LERs, rather | |||
than, say, monitoring individual PWs. | than, say, monitoring individual PWs. | |||
Figure 5 depicts two LMEGs configured in the network between AC1 | Figure 5 depicts two LMEGs configured in the network between AC1 | |||
and AC2: 1) the LSP13 LMEG between LER 1 and LER 3, and 2) the | and AC2: 1) the LSP13 LMEG between LER 1 and LER 3, and 2) the | |||
LSPXZ LMEG between LER X and LER Y. Note that the presence of a | LSPXZ LMEG between LER X and LER Y. Note that the presence of a | |||
LSP3X LMEG in such a configuration is optional, hence, not | LSP3X LMEG in such a configuration is optional, hence, not | |||
precluded by this framework. For instance, the SPs may prefer to | precluded by this framework. For instance, the SPs may prefer to | |||
monitor the MPLS-TP Section between the two LSRs rather than the | monitor the MPLS-TP Section between the two LSRs rather than the | |||
individual LSPs. | individual LSPs. | |||
4.3. MPLS-TP PW Monitoring (PMEG) | 4.3. MPLS-TP PW Monitoring (PMEG) | |||
An MPLS-TP PW MEG (PMEG) is an MPLS-TP maintenance entity | An MPLS-TP PW MEG (PMEG) is an MPLS-TP maintenance entity | |||
intended to monitor a SS-PW or MS-PW between its T-PEs. A PMEG | intended to monitor a SS-PW or MS-PW between its T-PEs. A PMEG | |||
can be configured on any SS-PW or MS-PW. PMEG OAM packets must | can be configured on any SS-PW or MS-PW. PMEG OAM packets must | |||
fate share with the user data packets sent over the monitored | fate-share with the user data packets sent over the monitored | |||
PW. | PW. | |||
A PMEG is intended to be deployed in scenarios where it is | A PMEG is intended to be deployed in scenarios where it is | |||
desirable to monitor an entire PW between a pair of MPLS-TP | desirable to monitor an entire PW between a pair of MPLS-TP | |||
enabled T-PEs rather than monitoring the LSP aggregating | enabled T-PEs rather than monitoring the LSP aggregating | |||
multiple PWs between PEs. | multiple PWs between PEs. | |||
Figure 5 depicts a MS-PW (MS-PW1Z) consisting of three path | Figure 5 depicts a MS-PW (MS-PW1Z) consisting of three path | |||
segments: PW13, PW3X and PWXZ and its associated end-to-end PMEG | segments: PW13, PW3X and PWXZ and its associated end-to-end PMEG | |||
(PW1Z PMEG). | (PW1Z PMEG). | |||
skipping to change at page 29, line 24 | skipping to change at page 30, line 26 | |||
SPME independent from the end-to-end monitoring (LMEG). An LSMEG | SPME independent from the end-to-end monitoring (LMEG). An LSMEG | |||
can monitor an LSP path segment and it may also include the | can monitor an LSP path segment and it may also include the | |||
forwarding engine(s) of the node(s) at the edge(s) of the path | forwarding engine(s) of the node(s) at the edge(s) of the path | |||
segment. | segment. | |||
When SPME is established between non-adjacent LSRs, the edges of | When SPME is established between non-adjacent LSRs, the edges of | |||
the SPME becomes adjacent at the LSP sub-layer network and any | the SPME becomes adjacent at the LSP sub-layer network and any | |||
LSR that were previously in between becomes an LSR for the SPME. | LSR that were previously in between becomes an LSR for the SPME. | |||
Multiple hierarchical LSMEGs can be configured on any LSP. LSMEG | Multiple hierarchical LSMEGs can be configured on any LSP. LSMEG | |||
OAM packets must fate share with the user data packets sent over | OAM packets must fate-share with the user data packets sent over | |||
the monitored LSP path segment. | the monitored LSP path segment. | |||
A LSME can be defined between the following entities: | A LSME can be defined between the following entities: | |||
o The LER and LSR of a given LSP. | o The LER and LSR of a given LSP. | |||
o Any two LSRs of a given LSP. | o Any two LSRs of a given LSP. | |||
An LSMEG is intended to be deployed in scenarios where it is | An LSMEG is intended to be deployed in scenarios where it is | |||
preferable to monitor the behavior of a part of an LSP or set of | preferable to monitor the behavior of a part of an LSP or set of | |||
skipping to change at page 30, line 12 | skipping to change at page 31, line 12 | |||
administrative boundaries of an MPLS-TP enabled administrative | administrative boundaries of an MPLS-TP enabled administrative | |||
domain. | domain. | |||
|<-------------------- PW1Z ------------------->| | |<-------------------- PW1Z ------------------->| | |||
| | | | | | |||
| |<-------------LSP1Z LSP------------->| | | | |<-------------LSP1Z LSP------------->| | | |||
| |<-LSP13->| |<LSP3X>| |<-LSPXZ->| | | | |<-LSP13->| |<LSP3X>| |<-LSPXZ->| | | |||
V V V V V V V V | V V V V V V V V | |||
+----+ +---+ +----+ +----+ +---+ +----+ | +----+ +---+ +----+ +----+ +---+ +----+ | |||
+----+ | PE | |LSR| |DBN | |DBN | |LSR| | PE | +----+ | +----+ | PE | |LSR| |DBN | |DBN | |LSR| | PE | +----+ | |||
| | | 1 | | 2 | | 3 | | X | | Y | | Z | | | | ||||
| |AC1| |=====================================| |AC2| | | | |AC1| |=====================================| |AC2| | | |||
| CE1|---|.....................PW1Z......................|---|CE2 | | | CE1|---|.....................PW1Z......................|---|CE2 | | |||
| | | |=====================================| | | | | | | | |=====================================| | | | | |||
+----+ | 1 | | 2 | | 3 | | X | | Y | | Z | +----+ | | | | | | | | | | | | | | | | | | |||
+----+ | | | | | | | | | | | | +----+ | ||||
+----+ +---+ +----+ +----+ +---+ +----+ | +----+ +---+ +----+ +----+ +---+ +----+ | |||
----+ | | | | | | | | | | | | +----+ | ||||
. . . . | . . . . | |||
| | | | | | | | | | |||
|<---- Domain 1 --->| |<---- Domain Z --->| | |<---- Domain 1 --->| |<---- Domain Z --->| | |||
^---------^ ^---------^ | ^---------^ ^---------^ | |||
LSP13 LSMEG LSPXZ LSMEG | LSP13 LSMEG LSPXZ LSMEG | |||
^-------------------------------------^ | ^-------------------------------------^ | |||
LSP1Z LMEG | LSP1Z LMEG | |||
DBN: Domain Border Node | DBN: Domain Border Node | |||
Figure 6 MPLS-TP LSP SPME MEG (LSMEG) | Figure 6 MPLS-TP LSP SPME MEG (LSMEG) | |||
Figure 6 depicts a variation of the reference model in Figure 5 | Figure 6 depicts a variation of the reference model in Figure 5 | |||
where there is an end-to-end LSP (LSP1Z) between PE1 and PEZ. | where there is an end-to-end LSP (LSP1Z) between PE1 and PEZ. | |||
LSP1Z consists of, at least, three LSP Concatenated Segments: | LSP1Z consists of, at least, three LSP Concatenated Segments: | |||
skipping to change at page 31, line 22 | skipping to change at page 32, line 24 | |||
S-PE placement is typically dictated by considerations other | S-PE placement is typically dictated by considerations other | |||
than OAM. S-PEs will frequently reside at operational boundaries | than OAM. S-PEs will frequently reside at operational boundaries | |||
such as the transition from distributed control plane (CP) to | such as the transition from distributed control plane (CP) to | |||
centralized Network Management System (NMS) control or at a | centralized Network Management System (NMS) control or at a | |||
routing area boundary. As such the architecture would appear not | routing area boundary. As such the architecture would appear not | |||
to have the flexibility that arbitrary placement of SPME | to have the flexibility that arbitrary placement of SPME | |||
segments would imply. Support for an arbitrary placement of | segments would imply. Support for an arbitrary placement of | |||
PSMEG would require the definition of additional PW | PSMEG would require the definition of additional PW | |||
sub-layering. | sub-layering. | |||
Multiple hierarchical PSMEGs can be configured on any MS-PW. | Multiple hierarchical PSMEGs can be configured on any MS-PW. | |||
PSMEG OAM packets fate share with the user data packets sent | PSMEG OAM packets fate-share with the user data packets sent | |||
over the monitored PW path Segment. | over the monitored PW path Segment. | |||
A PSMEG does not add hierarchical components to the MPLS | A PSMEG does not add hierarchical components to the MPLS | |||
architecture, it defines the role of existing components for the | architecture, it defines the role of existing components for the | |||
purposes of discussing OAM functionality. | purposes of discussing OAM functionality. | |||
A PSME can be defined between the following entities: | A PSME can be defined between the following entities: | |||
o T-PE and any S-PE of a given MS-PW | o T-PE and any S-PE of a given MS-PW | |||
o Any two S-PEs of a given MS-PW. | o Any two S-PEs of a given MS-PW. | |||
Note that, in line with the SPME description in section 3.2, when a | Note that, in line with the SPME description in section 3.2, when a | |||
PW SPME is instantiated after the MS-PW has been instantiated, the | PW SPME is instantiated after the MS-PW has been instantiated, the | |||
TTL distance of the MIPs may change and MIPs in the nested MEG are no | TTL distance of the MIPs may change and MIPs in the PW SPME are no | |||
longer part of the encompassing MEG. This means that the S-PE nodes | longer part of the encompassing MEG. This means that the S-PE nodes | |||
hosting these MIPs are no longer S-PEs but P nodes at the SPME LSP | hosting these MIPs are no longer S-PEs but P nodes at the SPME LSP | |||
level. The consequences are that the S-PEs hosting the PSMEG MEPs | level. The consequences are that the S-PEs hosting the PSMEG MEPs | |||
become adjacent S-PEs. This is no different than the operation of | become adjacent S-PEs. This is no different than the operation of | |||
SPMEs in general. | SPMEs in general. | |||
A PSMEG is intended to be deployed in scenarios where it is | A PSMEG is intended to be deployed in scenarios where it is | |||
preferable to monitor the behavior of a part of a MS-PW rather | preferable to monitor the behavior of a part of a MS-PW rather | |||
than the entire end-to-end PW itself, for example to monitor an | than the entire end-to-end PW itself, for example to monitor an | |||
MS-PW path segment within a given network domain of an inter- | MS-PW path segment within a given network domain of an inter- | |||
skipping to change at page 32, line 20 | skipping to change at page 33, line 20 | |||
It is worth noticing that PSMEGs can coexist with the PMEG | It is worth noticing that PSMEGs can coexist with the PMEG | |||
monitoring the end-to-end MS-PW and that PSMEG MEPs and PMEG | monitoring the end-to-end MS-PW and that PSMEG MEPs and PMEG | |||
MEPs can be coincident in the same node (e.g. T-PE1 node | MEPs can be coincident in the same node (e.g. T-PE1 node | |||
supports both the PW1Z PMEG MEP and the PW13 PSMEG MEP). | supports both the PW1Z PMEG MEP and the PW13 PSMEG MEP). | |||
4.6. Fate sharing considerations for multilink | 4.6. Fate sharing considerations for multilink | |||
Multilink techniques are in use today and are expected to | Multilink techniques are in use today and are expected to | |||
continue to be used in future deployments. These techniques | continue to be used in future deployments. These techniques | |||
include Ethernet Link Aggregations [21], the use of Link | include Ethernet Link Aggregation [22] and the use of Link | |||
Bundling for MPLS [17] where the option to spread traffic over | Bundling for MPLS [18] where the option to spread traffic over | |||
component links is supported and enabled. While the use of Link | component links is supported and enabled. While the use of Link | |||
Bundling can be controlled at the MPLS-TP layer, use of Link | Bundling can be controlled at the MPLS-TP layer, use of Link | |||
Aggregation (or any server layer specific multilink) is not | Aggregation (or any server layer specific multilink) is not | |||
necessarily under control of the MPLS-TP layer. Other techniques | necessarily under control of the MPLS-TP layer. Other techniques | |||
may emerge in the future. These techniques share the | may emerge in the future. These techniques frequently share the | |||
characteristic that an LSP may be spread over a set of component | characteristic that an LSP may be spread over a set of component | |||
links and therefore be reordered but no flow within the LSP is | links and therefore be reordered but no flow within the LSP is | |||
reordered (except when very infrequent and minimally disruptive | reordered (except when very infrequent and minimally disruptive | |||
load rebalancing occurs). | load rebalancing occurs). | |||
The use of multilink techniques may be prohibited or permitted | The use of multilink techniques may be prohibited or permitted | |||
in any particular deployment. If multilink techniques are used, | in any particular deployment. If multilink techniques are used, | |||
the deployment can be considered to be only partially MPLS-TP | the deployment can be considered to be only partially MPLS-TP | |||
compliant, however this is unlikely to prevent its use. | compliant, however this is unlikely to prevent its use. | |||
The implications for OAM is that not all components of a | The implications for OAM are that not all components of a | |||
multilink will be exercised, independent server layer OAM being | multilink will be exercised, independent server layer OAM being | |||
required to exercise the aggregated link components. This has | required to exercise the aggregated link components. This has | |||
further implications for MIP and MEP placement, as per-interface | further implications for MIP and MEP placement, as per-interface | |||
MIPs or "down" MEPs on a multilink interface are akin to a layer | MIPs or "down" MEPs on a multilink interface are akin to a layer | |||
violation, as they instrument at the granularity of the server | violation, as they instrument at the granularity of the server | |||
layer. The implications for reduced OAM loss measurement | layer. The implications for reduced OAM loss measurement | |||
functionality are documented in sections 5.5.3 and 6.2.3. | functionality are documented in sections 5.5.3 and 6.2.3. | |||
5. OAM Functions for proactive monitoring | 5. OAM Functions for proactive monitoring | |||
skipping to change at page 33, line 18 | skipping to change at page 34, line 18 | |||
or node to MEPs (e.g., AIS). The control and measurement | or node to MEPs (e.g., AIS). The control and measurement | |||
considerations are: | considerations are: | |||
1. Proactive monitoring for a MEG is typically configured at | 1. Proactive monitoring for a MEG is typically configured at | |||
transport path creation time. | transport path creation time. | |||
2. The operational characteristics of in-band measurement | 2. The operational characteristics of in-band measurement | |||
transactions (e.g., CV, Loss Measurement (LM) etc.) are | transactions (e.g., CV, Loss Measurement (LM) etc.) are | |||
configured at the MEPs. | configured at the MEPs. | |||
3. Server layer events are reported by OAM messages originating | 3. Server layer events are reported by OAM packets originating | |||
at intermediate nodes. | at intermediate nodes. | |||
4. The measurements resulting from proactive monitoring are | 4. The measurements resulting from proactive monitoring are | |||
typically reported outside of the MEG (e.g. to a management | typically reported outside of the MEG (e.g. to a management | |||
system) as notifications events such as faults or indications | system) as notifications events such as faults or indications | |||
of performance degradations (such as excessive packet loss). | of performance degradations (such as signal degrade | |||
conditions). | ||||
5. The measurements resulting from proactive monitoring may be | 5. The measurements resulting from proactive monitoring may be | |||
periodically harvested by an NMS. | periodically harvested by an NMS. | |||
Pro-active fault reporting is assumed to be subject to | ||||
unreliable delivery, soft-state and need to operate also in | ||||
cases where a return path is not available or faulty. Therefore | ||||
periodic repetition is assumed to be used for reliability, | ||||
instead of handshaking. | ||||
Delay measurement requires periodic repetition also to allow | ||||
estimation of the packet delay variation for the MEG. | ||||
For statically provisioned transport paths the above information | For statically provisioned transport paths the above information | |||
is statically configured; for dynamically established transport | is statically configured; for dynamically established transport | |||
paths the configuration information is signaled via the control | paths the configuration information is signaled via the control | |||
plane or configured via the management plane. | plane or configured via the management plane. | |||
The operator may enable/disable some of the consequent actions | The operator may enable/disable some of the consequent actions | |||
defined in section 5.1.1.4. | defined in section 5.1.2. | |||
5.1. Continuity Check and Connectivity Verification | 5.1. Continuity Check and Connectivity Verification | |||
Proactive Continuity Check functions, as required in section | Proactive Continuity Check functions, as required in section | |||
2.2.2 of RFC 5860 [11], are used to detect a loss of continuity | 2.2.2 of RFC 5860 [11], are used to detect a loss of continuity | |||
defect (LOC) between two MEPs in a MEG. | defect (LOC) between two MEPs in a MEG. | |||
Proactive Connectivity Verification functions, as required in | Proactive Connectivity Verification functions, as required in | |||
section 2.2.3 of RFC 5860 [11], are used to detect an unexpected | section 2.2.3 of RFC 5860 [11], are used to detect an unexpected | |||
connectivity defect between two MEGs (e.g. mismerging or | connectivity defect between two MEGs (e.g. mismerging or | |||
misconnection), as well as unexpected connectivity within the | misconnection), as well as unexpected connectivity within the | |||
MEG with an unexpected MEP. | MEG with an unexpected MEP. | |||
Both functions are based on the (proactive) generation of OAM | Both functions are based on the (proactive) generation, at the | |||
packets by the source MEP that are processed by the peer sink | same rate, of OAM packets by the source MEP that are processed | |||
MEP(s). As a consequence these two functions are grouped | by the peer sink MEP(s). As a consequence, in order to save OAM | |||
together into Continuity Check and Connectivity Verification | bandwidth consumption, CV, when used, is linked with CC into | |||
(CC-V) OAM packets. | Continuity Check and Connectivity Verification (CC-V) OAM | |||
packets. | ||||
In order to perform pro-active Connectivity Verification, each | In order to perform pro-active Connectivity Verification, each | |||
CC-V OAM packet also includes a globally unique Source MEP | CC-V OAM packet also includes a globally unique Source MEP | |||
identifier. When used to perform only pro-active Continuity | identifier, whose value needs to be configured on the source MEP | |||
Check, the CC-V OAM packet will not include any globally unique | and on the peer sink MEP(s). In some cases, to avoid the need to | |||
Source MEP identifier. Different formats of MEP identifiers are | configure the globally unique Source MEP identifier, it is | |||
defined in [10] to address different environments. When MPLS-TP | preferable to perform only pro-active Continuity Check. In this | |||
is deployed in transport network environments where IP | case, the CC-V OAM packet does not need to include any globally | |||
addressing is not used in the forwarding plane, the ITU Carrier | unique Source MEP identifier. Therefore, an MEG can be monitored | |||
Code (ICC)-based format for MEP identification is used. When | only for CC or for both CC and CV. CC-V OAM packets used for CC- | |||
MPLS-TP is deployed in an IP-based environment, the IP-based MEP | only monitoring are called CC OAM packets while CC-V OAM packets | |||
identification is used. | used for both CC and CV are called CV OAM packets. | |||
As a consequence, it is not possible to detect misconnections | As a consequence, it is not possible to detect misconnections | |||
between two MEGs monitored only for continuity as neither the | between two MEGs monitored only for continuity as neither the | |||
OAM message type nor OAM message content provides sufficient | OAM packet type nor the OAM packet content provides sufficient | |||
information to disambiguate an invalid source. To expand: | information to disambiguate an invalid source. To expand: | |||
o For CC leaking into a CC monitored MEG - undetectable | o For CC OAM packet leaking into a CC monitored MEG - | |||
undetectable. | ||||
o For CV leaking into a CC monitored MEG - presence of | o For CV OAM packet leaking into a CC monitored MEG - reception | |||
additional Source MEP identifier allows detecting the fault | of CV OAM packets instead of a CC OAM packets (e.g., with the | |||
additional Source MEP identifier) allows detecting the fault. | ||||
o For CC leaking into a CV monitored MEG - lack of additional | o For CC OAM packet leaking into a CV monitored MEG - reception | |||
Source MEP identifier allows detecting the fault. | of CC OAM packets instead of CV OAM packets (e.g., lack of | |||
additional Source MEP identifier) allows detecting the fault. | ||||
o For CV leaking into a CV monitored MEG - different Source MEP | o For CV OAM packet leaking into a CV monitored MEG - reception | |||
identifier permits fault to be identified. | of CV OAM packets with different Source MEP identifier | |||
permits fault to be identified. | ||||
Having a common packet format for CC-V OAM packets would | ||||
simplify parsing in a sink MEP to properly detect all the | ||||
mis-configuration cases described above. | ||||
Different formats of MEP identifiers are defined in [10] to | ||||
address different environments. When an alternative to IP | ||||
addressing is desired (e.g., MPLS-TP is deployed in transport | ||||
network environments where consistent operations with other | ||||
transport technologies defined by the ITU-T are required), the | ||||
ITU Carrier Code (ICC)-based format for MEP identification is | ||||
used. When MPLS-TP is deployed in an environment where IP | ||||
capabilities are available and desired for OAM, the IP-based MEP | ||||
identification is used. | ||||
CC-V OAM packets are transmitted at a regular, operator | CC-V OAM packets are transmitted at a regular, operator | |||
configurable, rate. The default CC-V transmission periods are | configurable, rate. The default CC-V transmission periods are | |||
application dependent (see section 5.1.3). | application dependent (see section 5.1.3). | |||
Proactive CC-V OAM packets are transmitted with the "minimum | Proactive CC-V OAM packets are transmitted with the "minimum | |||
loss probability PHB" within the transport path (LSP, PW) they | loss probability PHB" within the transport path (LSP, PW) they | |||
are monitoring. For E-LSPs, this PHB is configurable on network | are monitoring. For E-LSPs, this PHB is configurable on network | |||
operator's basis while for L-LSPs this is determined as per RFC | operator's basis while for L-LSPs this is determined as per RFC | |||
3270 [22]. PHBs can be translated at the network borders by the | 3270 [23]. PHBs can be translated at the network borders by the | |||
same function that translates it for user data traffic. The | same function that translates it for user data traffic. The | |||
implication is that CC-V fate shares with much of the forwarding | implication is that CC-V fate-shares with much of the forwarding | |||
implementation, but not all aspects of PHB processing are | implementation, but not all aspects of PHB processing are | |||
exercised. Either on-demand tools are used for finer grained | exercised. Either on-demand tools are used for finer grained | |||
fault finding or an implementation may utilize a CC-V flow per | fault finding or an implementation may utilize a CC-V flow per | |||
PHB to ensure a CC-V flow fate shares with each individual PHB. | PHB to ensure a CC-V flow fate-shares with each individual PHB. | |||
In a co-routed or associated, bidirectional point-to-point | In a co-routed or associated, bidirectional point-to-point | |||
transport path, when a MEP is enabled to generate pro-active | transport path, when a MEP is enabled to generate pro-active | |||
CC-V OAM packets with a configured transmission rate, it also | CC-V OAM packets with a configured transmission rate, it also | |||
expects to receive pro-active CC-V OAM packets from its peer MEP | expects to receive pro-active CC-V OAM packets from its peer MEP | |||
at the same transmission rate as a common SLA applies to all | at the same transmission rate as a common SLA applies to all | |||
components of the transport path. In a unidirectional transport | components of the transport path. In a unidirectional transport | |||
path (either point-to-point or point-to-multipoint), the source | path (either point-to-point or point-to-multipoint), the source | |||
MEP is enabled only to generate CC-V OAM packets while each sink | MEP is enabled only to generate CC-V OAM packets while each sink | |||
MEP is configured to expect these packets at the configured | MEP is configured to expect these packets at the configured | |||
skipping to change at page 35, line 42 | skipping to change at page 37, line 19 | |||
mis-configurations or mis-connectivity, CC-V packets are | mis-configurations or mis-connectivity, CC-V packets are | |||
received with an unexpected encapsulation. | received with an unexpected encapsulation. | |||
There are practical limitations to detecting unexpected | There are practical limitations to detecting unexpected | |||
encapsulation. It is possible that there are mis-configuration | encapsulation. It is possible that there are mis-configuration | |||
or mis-connectivity scenarios where OAM packets can alias as | or mis-connectivity scenarios where OAM packets can alias as | |||
payload, e.g., when a transport path can carry an arbitrary | payload, e.g., when a transport path can carry an arbitrary | |||
payload without a pseudo wire. | payload without a pseudo wire. | |||
When CC-V packets are received with an unexpected encapsulation | When CC-V packets are received with an unexpected encapsulation | |||
that can be parsed by the sink MEP, the CC-V packet is processed | that can be parsed by a sink MEP, the CC-V packet is processed | |||
as it were received with the correct encapsulation and if it is | as it were received with the correct encapsulation and if it is | |||
not a manifestation of a mis-connectivity defect a warning is | not a manifestation of a mis-connectivity defect a warning is | |||
raised (see section 5.1.1.4). Otherwise the CC-V packet may be | raised (see section 5.1.1.4). Otherwise the CC-V packet may be | |||
silently discarded as unrecognized and a LOC defect may be | silently discarded as unrecognized and a LOC defect may be | |||
detected (see section 5.1.1.1). | detected (see section 5.1.1.1). | |||
The defect conditions are described in no specific order. | The defect conditions are described in no specific order. | |||
5.1.1. Defects identified by CC-V | 5.1.1. Defects identified by CC-V | |||
Pro-active CC-V functions allow a sink MEP to detect the defect | Pro-active CC-V functions allow a sink MEP to detect the defect | |||
conditions described in the following sub-sections. For all of | conditions described in the following sub-sections. For all of | |||
the described defect cases, the sink MEP should notify the | the described defect cases, a sink MEP should notify the | |||
equipment fault management process of the detected defect. | equipment fault management process of the detected defect. | |||
Sequential consecutive loss of CC-V packets is considered | ||||
indicative of an actual break and not congestive loss or | ||||
physical layer degradation. The loss of 3 packets in a row | ||||
(implying a 3.5 insertion time detection interval) is | ||||
interpreted as a true break and a condition that will not clear | ||||
by itself. | ||||
A CC-V OAM packet is considered to carry an unexpected globally | ||||
unique Source MEP identifier if it is a CC OAM packet received | ||||
by a sink MEP monitoring the MEG for CV; it is a CV OAM packet | ||||
received by a sink MEP monitoring the MEG for CC or it is a CV | ||||
OAM packet received by a sink MEP monitoring the MEG for CV but | ||||
carrying a unique Source MEP identifier that is different that | ||||
the expected one. Conversely, the CC-V packet is considered to | ||||
have an expected globally unique Source MEP identifier where it | ||||
is a CC OAM packet received by a sink MEP monitoring the MEG for | ||||
CC or it is a it is a CV OAM packet received by a sink MEP | ||||
monitoring the MEG for CV and carrying a unique Source MEP | ||||
identifier that is equal to the expected one. | ||||
5.1.1.1. Loss Of Continuity defect | 5.1.1.1. Loss Of Continuity defect | |||
When proactive CC-V is enabled, a sink MEP detects a loss of | When proactive CC-V is enabled, a sink MEP detects a loss of | |||
continuity (LOC) defect when it fails to receive pro-active CC-V | continuity (LOC) defect when it fails to receive pro-active CC-V | |||
OAM packets from the source MEP. | OAM packets from the source MEP. | |||
o Entry criteria: If no pro-active CC-V OAM packets from the | o Entry criteria: If no pro-active CC-V OAM packets from the | |||
source MEP (and in the case of CV, this includes the | source MEP (and in the case of CV, this includes the | |||
requirement to have the expected globally unique Source MEP | requirement to have the expected globally unique Source MEP | |||
identifier) are received within the interval equal to 3.5 | identifier) are received within the interval equal to 3.5 | |||
times the receiving MEP's configured CC-V reception period. | times the receiving MEP's configured CC-V reception period. | |||
o Exit criteria: A pro-active CC-V OAM packet from the source | o Exit criteria: A pro-active CC-V OAM packet from the source | |||
MEP (and again in the case of CV, with the expected globally | MEP (and again in the case of CV, with the expected globally | |||
unique Source MEP identifier) is received. | unique Source MEP identifier) is received. | |||
5.1.1.2. Mis-connectivity defect | 5.1.1.2. Mis-connectivity defect | |||
When a pro-active CC-V OAM packet is received, a sink MEP | When a pro-active CC-V OAM packet is received, a sink MEP | |||
identifies a mis-connectivity defect (e.g. mismerge, | identifies a mis-connectivity defect (e.g. mismerge, | |||
misconnection or unintended looping) when the received packet | misconnection or unintended looping) when the received packet | |||
carries an unexpected globally unique Source MEP identifier. | carries an unexpected globally unique Source MEP identifier. | |||
o Entry criteria: The sink MEP receives a pro-active CC-V OAM | o Entry criteria: The sink MEP receives a pro-active CC-V OAM | |||
packet with an unexpected globally unique Source MEP | packet with an unexpected globally unique Source MEP | |||
identifier or with an unexpected encapsulation. | identifier or with an unexpected encapsulation. | |||
o Exit criteria: The sink MEP does not receive any pro-active | o Exit criteria: The sink MEP does not receive any pro-active | |||
CC-V OAM packet with an unexpected globally unique Source MEP | CC-V OAM packet with an unexpected globally unique Source MEP | |||
identifier for an interval equal at least to 3.5 times the | identifier for an interval equal at least to 3.5 times the | |||
longest transmission period of the pro-active CC-V OAM | longest transmission period of the pro-active CC-V OAM | |||
packets received with an unexpected globally unique Source | packets received with an unexpected globally unique Source | |||
MEP identifier since this defect has been raised. This | MEP identifier since this defect has been raised. This | |||
requires the OAM message to self identify the CC-V | requires the OAM packet to self identify the CC-V periodicity | |||
periodicity as not all MEPs can be expected to have knowledge | as not all MEPs can be expected to have knowledge of all | |||
of all MEGs. | MEGs. | |||
5.1.1.3. Period Misconfiguration defect | 5.1.1.3. Period Misconfiguration defect | |||
If pro-active CC-V OAM packets are received with the expected | If pro-active CC-V OAM packets are received with the expected | |||
globally unique Source MEP identifier but with a transmission | globally unique Source MEP identifier but with a transmission | |||
period different than the locally configured reception period, | period different than the locally configured reception period, | |||
then a CV period mis-configuration defect is detected. | then a CC-V period mis-configuration defect is detected. | |||
o Entry criteria: A MEP receives a CC-V pro-active packet with | o Entry criteria: A MEP receives a CC-V pro-active packet with | |||
the expected globally unique Source MEP identifier but with a | the expected globally unique Source MEP identifier but with a | |||
Period field value different than its own CC-V configured | transmission period different than its own CC-V configured | |||
transmission period. | transmission period. | |||
o Exit criteria: The sink MEP does not receive any pro-active | o Exit criteria: The sink MEP does not receive any pro-active | |||
CC-V OAM packet with the expected globally unique Source MEP | CC-V OAM packet with the expected globally unique Source MEP | |||
identifier and an incorrect transmission period for an | identifier and an incorrect transmission period for an | |||
interval equal at least to 3.5 times the longest transmission | interval equal at least to 3.5 times the longest transmission | |||
period of the pro-active CC-V OAM packets received with the | period of the pro-active CC-V OAM packets received with the | |||
expected globally unique Source MEP identifier and an | expected globally unique Source MEP identifier and an | |||
incorrect transmission period since this defect has been | incorrect transmission period since this defect has been | |||
raised. | raised. | |||
5.1.1.4. Unexpected encapsulation defect | 5.1.1.4. Unexpected encapsulation defect | |||
If pro-active CC-V OAM packets are received with the expected | If pro-active CC-V OAM packets are received with the expected | |||
globally unique Source MEP identifier but with an unexpected | globally unique Source MEP identifier but with an unexpected | |||
encapsulation, then a CV unexpected encapsulation defect is | encapsulation, then a CC-V unexpected encapsulation defect is | |||
detected. | detected. | |||
It should be noted that there are practical limitations to | It should be noted that there are practical limitations to | |||
detecting unexpected encapsulation (see section 5.1.1). | detecting unexpected encapsulation (see section 5.1.1). | |||
o Entry criteria: A MEP receives a CC-V pro-active packet with | o Entry criteria: A MEP receives a CC-V pro-active packet with | |||
the expected globally unique Source MEP identifier but with | the expected globally unique Source MEP identifier but with | |||
an unexpected encapsulation. | an unexpected encapsulation. | |||
o Exit criteria: The sink MEP does not receive any pro-active | o Exit criteria: The sink MEP does not receive any pro-active | |||
CC-V OAM packet with the expected globally unique Source MEP | CC-V OAM packet with the expected globally unique Source MEP | |||
identifier and an unexpected encapsulation for an interval | identifier and an unexpected encapsulation for an interval | |||
equal at least to 3.5 times the longest transmission period | equal at least to 3.5 times the longest transmission period | |||
of the pro-active CC-V OAM packets received with the expected | of the pro-active CC-V OAM packets received with the expected | |||
globally unique Source MEP identifier and an unexpected | globally unique Source MEP identifier and an unexpected | |||
encapsulation since this defect has been raised. | encapsulation since this defect has been raised. | |||
5.1.2. Consequent action | 5.1.2. Consequent action | |||
A sink MEP that detects any of the defect conditions defined in | A sink MEP that detects any of the defect conditions defined in | |||
section 5.1.1 declares a defect condition and performs the | section 5.1.1 declares a defect condition and performs the | |||
following consequent actions. | following consequent actions. | |||
If a MEP detects a mis-connectivity defect, it blocks all the | If a MEP detects a mis-connectivity defect, it blocks all the | |||
traffic (including also the user data packets) that it receives | traffic (including also the user data packets) that it receives | |||
from the misconnected transport path. | from the misconnected transport path. | |||
skipping to change at page 39, line 4 | skipping to change at page 41, line 4 | |||
5.1.3. Configuration considerations | 5.1.3. Configuration considerations | |||
At all MEPs inside a MEG, the following configuration | At all MEPs inside a MEG, the following configuration | |||
information needs to be configured when a proactive CC-V | information needs to be configured when a proactive CC-V | |||
function is enabled: | function is enabled: | |||
o MEG ID; the MEG identifier to which the MEP belongs; | o MEG ID; the MEG identifier to which the MEP belongs; | |||
o MEP-ID; the MEP's own identity inside the MEG; | o MEP-ID; the MEP's own identity inside the MEG; | |||
o list of the other MEPs in the MEG. For a point-to-point MEG | o list of the other MEPs in the MEG. For a point-to-point MEG | |||
the list would consist of the single MEP ID from which the | the list would consist of the single MEP ID from which the | |||
OAM packets are expected. In case of the root MEP of a p2mp | OAM packets are expected. In case of the root MEP of a p2mp | |||
MEG, the list is composed by all the leaf MEP IDs inside the | MEG, the list is composed by all the leaf MEP IDs inside the | |||
MEG. In case of the leaf MEP of a p2mp MEG, the list is | MEG. In case of the leaf MEP of a p2mp MEG, the list is | |||
composed by the root MEP ID (i.e. each leaf needs to know the | composed by the root MEP ID (i.e. each leaf needs to know the | |||
root MEP ID from which it expect to receive the CC-V OAM | root MEP ID from which it expect to receive the CC-V OAM | |||
packets). | packets). | |||
o PHB for E-LSPs; it identifies the per-hop behavior of CC-V | o PHB for E-LSPs; it identifies the per-hop behavior of CC-V | |||
packet. Proactive CC-V packets are transmitted with the | packet. Proactive CC-V packets are transmitted with the | |||
"minimum loss probability PHB" previously configured within a | "minimum loss probability PHB" previously configured within a | |||
single network operator. This PHB is configurable on network | single network operator. This PHB is configurable on network | |||
operator's basis. PHBs can be translated at the network | operator's basis. PHBs can be translated at the network | |||
borders. | borders. | |||
o transmission rate; the default CC-V transmission periods are | o transmission rate; the default CC-V transmission periods are | |||
application dependent (depending on whether they are used to | application dependent (depending on whether they are used to | |||
support fault management, performance monitoring, or | support fault management, performance monitoring, or | |||
protection switching applications): | protection switching applications): | |||
o Fault Management: default transmission period is 1s (i.e. | o Fault Management: default transmission period is 1s (i.e. | |||
transmission rate of 1 packet/second). | transmission rate of 1 packet/second). | |||
o Performance Monitoring: default transmission period is | o Performance Management: default transmission period is | |||
100ms (i.e. transmission rate of 10 packets/second). | 100ms (i.e. transmission rate of 10 packets/second). CC-V | |||
Performance monitoring is only relevant when the | contributes to the accuracy of performance monitoring | |||
transport path is defect free. CC-V contributes to the | (PM) statistics by permitting the defect free periods to | |||
accuracy of PM statistics by permitting the defect free | be properly distinguished as described in sections 5.5.1 | |||
periods to be properly distinguished. | and 5.6.1. | |||
o Protection Switching: default transmission period is | o Protection Switching: If protection switching with CC-V | |||
3.33ms (i.e. transmission rate of 300 packets/second). | defect entry criteria of 12ms is required (for example, | |||
CC-V defect entry criteria can resolve in less than 12ms, | in conjunction with the requirement to support 50ms | |||
and a protection switch can complete within a subsequent | recovery time as indicated in RFC 5654 [5]), then an | |||
period of 50 ms. | implementation should use a default transmission period | |||
It is also possible to lengthen the transmission period | of 3.33ms (i.e., transmission rate of 300 | |||
to 10ms (i.e. transmission rate of 100 packets/second): | packets/second). Sometimes, the requirement of 50ms | |||
in this case the CC-V defect entry criteria is reached | recovery time is associated with the requirement for a | |||
later (i.e. 35ms). | CC-V defect entry criteria period of 35 ms: in these | |||
cases a transmission period of 10ms (i.e., transmission | ||||
rate of 100 packets/second) can be used. Furthermore, | ||||
when there is no need for so small CC-V defect entry | ||||
criteria periods, larger transmission period can be used. | ||||
It should be possible for the operator to configure these | It should be possible for the operator to configure these | |||
transmission rates for all applications, to satisfy his internal | transmission rates for all applications, to satisfy specific | |||
requirements. | network requirements. | |||
Note that the reception period is the same as the configured | Note that the reception period is the same as the configured | |||
transmission rate. | transmission rate. | |||
For management provisioned transport paths the above parameters | For management provisioned transport paths the above parameters | |||
are statically configured; for dynamically signalled transport | are statically configured; for dynamically signaled transport | |||
paths the configuration information are distributed via the | paths the configuration information are distributed via the | |||
control plane. | control plane. | |||
The operator should be able to enable/disable some of the | The operator should be able to enable/disable some of the | |||
consequent actions. Which consequent action can be | consequent actions. Which consequent action can be | |||
enabled/disabled are described in section 5.1.1.4. | enabled/disabled are described in section 5.1.2. | |||
5.2. Remote Defect Indication | 5.2. Remote Defect Indication | |||
The Remote Defect Indication (RDI) function, as required in | The Remote Defect Indication (RDI) function, as required in | |||
section 2.2.9 of RFC 5860 [11], is an indicator that is | section 2.2.9 of RFC 5860 [11], is an indicator that is | |||
transmitted by a sink MEP to communicate to its source MEP that | transmitted by a sink MEP to communicate to its source MEP that | |||
a signal fail condition exists. In case of co-routed and | a signal fail condition exists. In case of co-routed and | |||
associated bidirectional transport paths, RDI is associated with | associated bidirectional transport paths, RDI is associated with | |||
proactive CC-V and the RDI indicator can be piggy-backed onto | proactive CC-V and the RDI indicator can be piggy-backed onto | |||
the CC-V packet. In case of unidirectional transport paths, the | the CC-V packet. In case of unidirectional transport paths, the | |||
skipping to change at page 40, line 51 | skipping to change at page 43, line 7 | |||
When the signal fail condition clears, the MEP should stop | When the signal fail condition clears, the MEP should stop | |||
transmitting the RDI indicator to its peer MEP. When | transmitting the RDI indicator to its peer MEP. When | |||
incorporated into CC-V, the RDI indicator will be cleared from | incorporated into CC-V, the RDI indicator will be cleared from | |||
subsequent transmission of pro-active CC-V packets. A MEP | subsequent transmission of pro-active CC-V packets. A MEP | |||
should clear the RDI defect upon reception of an RDI indicator | should clear the RDI defect upon reception of an RDI indicator | |||
cleared. | cleared. | |||
5.2.1. Configuration considerations | 5.2.1. Configuration considerations | |||
In order to support RDI indication, the indication may be a | In order to support RDI indication, the indication may be | |||
unique OAM message or an OAM information element embedded in a | carried in a unique OAM packet or may be embedded in a CC-V | |||
CV message. The in-band RDI transmission rate and PHB of the OAM | packet. The in-band RDI transmission rate and PHB of the OAM | |||
packets carrying RDI should be the same as that configured for | packets carrying RDI should be the same as that configured for | |||
CC-V. Methods of the out-of-band return paths will dictate how | CC-V to allow both far-end and near-end defect conditions being | |||
resolved in a timeframe that has the same order of magnitude. | ||||
This timeframe is application specific as described in section | ||||
5.1.3. Methods of the out-of-band return paths will dictate how | ||||
out-of-band RDI indications are transmitted. | out-of-band RDI indications are transmitted. | |||
5.3. Alarm Reporting | 5.3. Alarm Reporting | |||
The Alarm Reporting function, as required in section 2.2.8 of | The Alarm Reporting function, as required in section 2.2.8 of | |||
RFC 5860 [11], relies upon an Alarm Indication Signal (AIS) | RFC 5860 [11], relies upon an Alarm Indication Signal (AIS) | |||
message to suppress alarms following detection of defect | packet to suppress alarms following detection of defect | |||
conditions at the server (sub-)layer. | conditions at the server (sub-)layer. | |||
When a server MEP asserts a signal fail condition, it notifies | When a server MEP asserts a signal fail condition, it notifies | |||
that to the co-located MPLS-TP client/server adaptation function | that to the co-located MPLS-TP client/server adaptation function | |||
which then generates OAM packets with AIS information in the | which then generates OAM packets with AIS information in the | |||
downstream direction to allow the suppression of secondary | downstream direction to allow the suppression of secondary | |||
alarms at the MPLS-TP MEP in the client (sub-)layer. | alarms at the MPLS-TP MEP in the client (sub-)layer. | |||
The generation of packets with AIS information starts | The generation of packets with AIS information starts | |||
immediately when the server MEP asserts a signal fail condition. | immediately when the server MEP asserts a signal fail condition. | |||
These periodic OAM packets, with AIS information, continue to be | These periodic OAM packets, with AIS information, continue to be | |||
transmitted until the signal fail condition is cleared. | transmitted until the signal fail condition is cleared. | |||
It is assumed that to avoid spurious alarm generation a MEP | It is assumed that to avoid spurious alarm generation a MEP | |||
detecting a loss of continuity defect (see section 5.1.1.1) will | detecting a loss of continuity defect (see section 5.1.1.1) will | |||
wait for a hold off interval prior to asserting an alarm to the | wait for a hold off interval prior to asserting an alarm to the | |||
management system. Therefore, upon receiving an OAM packet with | management system. Therefore, upon receiving an OAM packet with | |||
AIS information an MPLS-TP MEP enters an AIS defect condition | AIS information an MPLS-TP MEP enters an AIS defect condition | |||
and suppresses loss of continuity alarms associated with its | and suppresses reporting of alarms to the NMS on the loss of | |||
peer MEP but does not block traffic received from the transport | continuity with its peer MEP but does not block traffic received | |||
path. A MEP resumes loss of continuity alarm generation upon | from the transport path. A MEP resumes loss of continuity alarm | |||
detecting loss of continuity defect conditions in the absence of | generation upon detecting loss of continuity defect conditions | |||
AIS condition. | in the absence of AIS condition. | |||
MIPs, as well as intermediate nodes, do not process AIS | MIPs, as well as intermediate nodes, do not process AIS | |||
information and forward these AIS OAM packets as regular data | information and forward these AIS OAM packets as regular data | |||
packets. | packets. | |||
For example, let's consider a fiber cut between LSR 1 and LSR 2 | For example, let's consider a fiber cut between LSR 1 and LSR 2 | |||
in the reference network of Figure 5. Assuming that all of the | in the reference network of Figure 5. Assuming that all of the | |||
MEGs described in Figure 5 have pro-active CC-V enabled, a LOC | MEGs described in Figure 5 have pro-active CC-V enabled, a LOC | |||
defect is detected by the MEPs of Sec12 SMEG LSP13 LMEG, PW1 | defect is detected by the MEPs of Sec12 SMEG LSP13 LMEG, PW1 | |||
PSMEG and PW1Z PMEG, however in a transport network only the | PSMEG and PW1Z PMEG, however in a transport network only the | |||
skipping to change at page 42, line 37 | skipping to change at page 44, line 33 | |||
alarm on PW13 PSMEG because the MEP of PW13 PSMEG resides within | alarm on PW13 PSMEG because the MEP of PW13 PSMEG resides within | |||
the same node as the MEP of LSP13 LMEG. The MEP of PW13 PSMEG in | the same node as the MEP of LSP13 LMEG. The MEP of PW13 PSMEG in | |||
LSR3 also notifies the adaptation function for PW1Z PMEG that | LSR3 also notifies the adaptation function for PW1Z PMEG that | |||
then generates AIS packets on PW1Z PMEG in order to allow its | then generates AIS packets on PW1Z PMEG in order to allow its | |||
MEP in LSRZ to suppress the LOC alarm. | MEP in LSRZ to suppress the LOC alarm. | |||
The generation of AIS packets for each MEG in the MPLS-TP client | The generation of AIS packets for each MEG in the MPLS-TP client | |||
(sub-)layer is configurable (i.e. the operator can | (sub-)layer is configurable (i.e. the operator can | |||
enable/disable the AIS generation). | enable/disable the AIS generation). | |||
AIS condition is cleared if no AIS packet has been received in | ||||
3.5 times the AIS transmission period. | ||||
The AIS transmission period is traditionally one per second but | ||||
an option to configure longer periods would be also desirable. | ||||
As a consequence, OAM packets need to self-identify the | ||||
transmission period such that proper exit criteria can be | ||||
established. | ||||
AIS packets are transmitted with the "minimum loss probability | AIS packets are transmitted with the "minimum loss probability | |||
PHB" within a single network operator. For E-LSPs, this PHB is | PHB" within a single network operator. For E-LSPs, this PHB is | |||
configurable on network operator's basis, while for L-LSPs, this | configurable on network operator's basis, while for L-LSPs, this | |||
is determined as per RFC 3270 [22]. | is determined as per RFC 3270 [23]. | |||
AIS condition is cleared if no AIS message has been received in | ||||
3.5 times the AIS transmission period. | ||||
5.4. Lock Reporting | 5.4. Lock Reporting | |||
The Lock Reporting function, as required in section 2.2.7 of RFC | The Lock Reporting function, as required in section 2.2.7 of RFC | |||
5860 [11], relies upon a Locked Report (LKR) message used to | 5860 [11], relies upon a Locked Report (LKR) packet used to | |||
suppress alarms following administrative locking action in the | suppress alarms following administrative locking action in the | |||
server (sub-)layer. | server (sub-)layer. | |||
When a server MEP is locked, the MPLS-TP client (sub-)layer | When a server MEP is locked, the MPLS-TP client (sub-)layer | |||
adaptation function generates packets with LKR information to | adaptation function generates packets with LKR information to | |||
allow the suppression of secondary alarms at the MEPs in the | allow the suppression of secondary alarms at the MEPs in the | |||
client (sub-)layer. Again it is assumed that there is a hold off | client (sub-)layer. Again it is assumed that there is a hold off | |||
for any loss of continuity alarms in the client layer MEPs | for any loss of continuity alarms in the client layer MEPs | |||
downstream of the node originating the locked report. In case of | downstream of the node originating the locked report. In case of | |||
client (sub-)layer co-routed bidirectional transport paths, the | client (sub-)layer co-routed bidirectional transport paths, the | |||
skipping to change at page 44, line 15 | skipping to change at page 46, line 29 | |||
because the MEP of PW13 PSMEG resides within the same node as | because the MEP of PW13 PSMEG resides within the same node as | |||
the MEP of LSP13 LMEG. The MEP of PW13 PSMEG in LSR3 also | the MEP of LSP13 LMEG. The MEP of PW13 PSMEG in LSR3 also | |||
notifies the adaptation function for PW1Z PMEG that then | notifies the adaptation function for PW1Z PMEG that then | |||
generates AIS packets on PW1Z PMEG in order to allow its MEP in | generates AIS packets on PW1Z PMEG in order to allow its MEP in | |||
LSRZ to suppress the LOC alarm. | LSRZ to suppress the LOC alarm. | |||
The generation of LKR packets for each MEG in the MPLS-TP client | The generation of LKR packets for each MEG in the MPLS-TP client | |||
(sub-)layer is configurable (i.e. the operator can | (sub-)layer is configurable (i.e. the operator can | |||
enable/disable the LKR generation). | enable/disable the LKR generation). | |||
Locked condition is cleared if no LKR packet has been received | ||||
for 3.5 times the transmission period. | ||||
The LKR transmission period is traditionally one per second but | ||||
an option to configure longer periods would be also desirable. | ||||
As a consequence, OAM packets need to self-identify the | ||||
transmission period such that proper exit criteria can be | ||||
established. | ||||
LKR packets are transmitted with the "minimum loss probability | LKR packets are transmitted with the "minimum loss probability | |||
PHB" within a single network operator. For E-LSPs, this PHB is | PHB" within a single network operator. For E-LSPs, this PHB is | |||
configurable on network operator's basis, while for L-LSPs, this | configurable on network operator's basis, while for L-LSPs, this | |||
is determined as per RFC 3270 [22]. | is determined as per RFC 3270 [23]. | |||
Locked condition is cleared if no LKR packet has been received | ||||
for 3.5 times the transmission period. | ||||
5.5. Packet Loss Measurement | 5.5. Packet Loss Measurement | |||
Packet Loss Measurement (LM) is one of the capabilities | Packet Loss Measurement (LM) is one of the capabilities | |||
supported by the MPLS-TP Performance Monitoring (PM) function in | supported by the MPLS-TP Performance Monitoring (PM) function in | |||
order to facilitate reporting of QoS information for a transport | order to facilitate reporting of QoS information for a transport | |||
path as required in section 2.2.11 of RFC 5860 [11]. LM is used | path as required in section 2.2.11 of RFC 5860 [11]. LM is used | |||
to exchange counter values for the number of ingress and egress | to exchange counter values for the number of ingress and egress | |||
packets transmitted and received by the transport path monitored | packets transmitted and received by the transport path monitored | |||
by a pair of MEPs. | by a pair of MEPs. | |||
Proactive LM is performed by periodically sending LM OAM packets | Proactive LM is performed by periodically sending LM OAM packets | |||
from a MEP to a peer MEP and by receiving LM OAM packets from | from a MEP to a peer MEP and by receiving LM OAM packets from | |||
the peer MEP (if a co-routed or associated bidirectional | the peer MEP (if a co-routed or associated bidirectional | |||
transport path) during the life time of the transport path. Each | transport path) during the life time of the transport path. Each | |||
MEP performs measurements of its transmitted and received | MEP performs measurements of its transmitted and received user | |||
packets. These measurements are then correlated in real time | data packets. These measurements are then correlated in real | |||
with the peer MEP in the ME to derive the impact of packet loss | time with the peer MEP in the ME to derive the impact of packet | |||
on a number of performance metrics for the ME in the MEG. The LM | loss on a number of performance metrics for the ME in the MEG. | |||
transactions are issued such that the OAM packets will | The LM transactions are issued such that the OAM packets will | |||
experience the same PHB scheduling class as the measured traffic | experience the same PHB scheduling class as the measured traffic | |||
while transiting between the MEPs in the ME. | while transiting between the MEPs in the ME. | |||
For a MEP, near-end packet loss refers to packet loss associated | For a MEP, near-end packet loss refers to packet loss associated | |||
with incoming data packets (from the far-end MEP) while far-end | with incoming data packets (from the far-end MEP) while far-end | |||
packet loss refers to packet loss associated with egress data | packet loss refers to packet loss associated with egress data | |||
packets (towards the far-end MEP). | packets (towards the far-end MEP). | |||
Pro-active LM can be operated in two ways: | Pro-active LM can be operated in two ways: | |||
o One-way: a MEP sends LM OAM packet to its peer MEP containing | o One-way: a MEP sends LM OAM packet to its peer MEP containing | |||
all the required information to facilitate near-end packet | all the required information to facilitate near-end packet | |||
loss measurements at the peer MEP. | loss measurements at the peer MEP. | |||
o Two-way: a MEP sends LM OAM packet with a LM request to its | o Two-way: a MEP sends LM OAM packet with a LM request to its | |||
peer MEP, which replies with a LM OAM packet as a LM | peer MEP, which replies with a LM OAM packet as a LM | |||
response. The request/response LM OAM packets containing all | response. The request/response LM OAM packets containing all | |||
the required information to facilitate both near-end and | the required information to facilitate both near-end and | |||
far-end packet loss measurements from the viewpoint of the | far-end packet loss measurements from the viewpoint of the | |||
originating MEP. | originating MEP. | |||
One-way LM is applicable to both unidirectional and | One-way LM is applicable to both unidirectional and | |||
bidirectional (co-routed or associated) transport paths while | bidirectional (co-routed or associated) transport paths while | |||
two-way LM is applicable only to bidirectional (co-routed or | two-way LM is applicable only to bidirectional (co-routed or | |||
associated) transport paths. | associated) transport paths. | |||
MIPs, as well as intermediate nodes, do not process the LM | MIPs, as well as intermediate nodes, do not process the LM | |||
information and forward these pro-active LM OAM packets as | information and forward these pro-active LM OAM packets as | |||
regular data packets. | regular data packets. | |||
5.5.1. Configuration considerations | 5.5.1. Configuration considerations | |||
In order to support proactive LM, the transmission rate and PHB | In order to support proactive LM, the transmission rate and, for | |||
class associated with the LM OAM packets originating from a MEP | E-LSPs, the PHB class associated with the LM OAM packets | |||
need be configured as part of the LM provisioning. LM OAM | originating from a MEP need be configured as part of the LM | |||
packets should be transmitted with the PHB that yields the | provisioning. LM OAM packets should be transmitted with the PHB | |||
lowest drop precedence within the measured PHB Scheduling Class | that yields the lowest drop precedence within the measured PHB | |||
(see RFC 3260 [16]). | Scheduling Class (see RFC 3260 [17]), in order to maximize | |||
reliability of measurement within the traffic class. | ||||
If that PHB class is not an ordered aggregate where the ordering | If that PHB class is not an ordered aggregate where the ordering | |||
constraint is all packets with the PHB class being delivered in | constraint is all packets with the PHB class being delivered in | |||
order, LM can produce inconsistent results. | order, LM can produce inconsistent results. | |||
Performance monitoring (e.g., LM) is only relevant when the | ||||
transport path is defect free. CC-V contributes to the accuracy | ||||
of PM statistics by permitting the defect free periods to be | ||||
properly distinguished. Therefore support of pro-active LM has | ||||
implications on the CC-V transmission period (see section | ||||
5.1.3). | ||||
5.5.2. Sampling skew | 5.5.2. Sampling skew | |||
If an implementation makes use of a hardware forwarding path | If an implementation makes use of a hardware forwarding path | |||
which operates in parallel with an OAM processing path, whether | which operates in parallel with an OAM processing path, whether | |||
hardware or software based, the packet and byte counts may be | hardware or software based, the packet and byte counts may be | |||
skewed if one or more packets can be processed before the OAM | skewed if one or more packets can be processed before the OAM | |||
processing samples counters. If OAM is implemented in software | processing samples counters. If OAM is implemented in software | |||
this error can be quite large. | this error can be quite large. | |||
5.5.3. Multilink issues | 5.5.3. Multilink issues | |||
skipping to change at page 46, line 25 | skipping to change at page 49, line 5 | |||
used to measure the long-term packet delay and packet delay | used to measure the long-term packet delay and packet delay | |||
variation in the transport path monitored by a pair of MEPs. | variation in the transport path monitored by a pair of MEPs. | |||
Proactive DM is performed by sending periodic DM OAM packets | Proactive DM is performed by sending periodic DM OAM packets | |||
from a MEP to a peer MEP and by receiving DM OAM packets from | from a MEP to a peer MEP and by receiving DM OAM packets from | |||
the peer MEP (if a co-routed or associated bidirectional | the peer MEP (if a co-routed or associated bidirectional | |||
transport path) during a configurable time interval. | transport path) during a configurable time interval. | |||
Pro-active DM can be operated in two ways: | Pro-active DM can be operated in two ways: | |||
o One-way: a MEP sends DM OAM packet to its peer MEP containing | o One-way: a MEP sends DM OAM packet to its peer MEP containing | |||
all the required information to facilitate one-way packet | all the required information to facilitate one-way packet | |||
delay and/or one-way packet delay variation measurements at | delay and/or one-way packet delay variation measurements at | |||
the peer MEP. Note that this requires precise time | the peer MEP. Note that this requires precise time | |||
synchronisation at either MEP by means outside the scope of | synchronisation at either MEP by means outside the scope of | |||
this framework. | this framework. | |||
o Two-way: a MEP sends DM OAM packet with a DM request to its | o Two-way: a MEP sends DM OAM packet with a DM request to its | |||
peer MEP, which replies with a DM OAM packet as a DM | peer MEP, which replies with a DM OAM packet as a DM | |||
response. The request/response DM OAM packets containing all | response. The request/response DM OAM packets containing all | |||
the required information to facilitate two-way packet delay | the required information to facilitate two-way packet delay | |||
and/or two-way packet delay variation measurements from the | and/or two-way packet delay variation measurements from the | |||
viewpoint of the originating MEP. | viewpoint of the originating MEP. | |||
One-way DM is applicable to both unidirectional and | One-way DM is applicable to both unidirectional and | |||
bidirectional (co-routed or associated) transport paths while | bidirectional (co-routed or associated) transport paths while | |||
two-way DM is applicable only to bidirectional (co-routed or | two-way DM is applicable only to bidirectional (co-routed or | |||
associated) transport paths. | associated) transport paths. | |||
MIPs, as well as intermediate nodes, do not process the DM | MIPs, as well as intermediate nodes, do not process the DM | |||
information and forward these pro-active DM OAM packets as | information and forward these pro-active DM OAM packets as | |||
regular data packets. | regular data packets. | |||
5.6.1. Configuration considerations | 5.6.1. Configuration considerations | |||
In order to support pro-active DM, the transmission rate and, | In order to support pro-active DM, the transmission rate and, | |||
for E-LSPs, the PHB associated with the DM OAM packets | for E-LSPs, the PHB associated with the DM OAM packets | |||
originating from a MEP need be configured as part of the DM | originating from a MEP need be configured as part of the DM | |||
provisioning. DM OAM packets should be transmitted with the PHB | provisioning. DM OAM packets should be transmitted with the PHB | |||
that yields the lowest drop precedence within the measured PHB | that yields the lowest drop precedence within the measured PHB | |||
Scheduling Class (see RFC 3260 [16]). | Scheduling Class (see RFC 3260 [17]). | |||
Performance monitoring (e.g., DM) is only relevant when the | ||||
transport path is defect free. CC-V contributes to the accuracy | ||||
of PM statistics by permitting the defect free periods to be | ||||
properly distinguished. Therefore support of pro-active DM has | ||||
implications on the CC-V transmission period (see section | ||||
5.1.3). | ||||
5.7. Client Failure Indication | 5.7. Client Failure Indication | |||
The Client Failure Indication (CFI) function, as required in | The Client Failure Indication (CFI) function, as required in | |||
section 2.2.10 of RFC 5860 [11], is used to help process client | section 2.2.10 of RFC 5860 [11], is used to help process client | |||
defects and propagate a client signal defect condition from the | defects and propagate a client signal defect condition from the | |||
process associated with the local attachment circuit where the | process associated with the local attachment circuit where the | |||
defect was detected (typically the source adaptation function | defect was detected (typically the source adaptation function | |||
for the local client interface) to the process associated with | for the local client interface) to the process associated with | |||
the far-end attachment circuit (typically the source adaptation | the far-end attachment circuit (typically the source adaptation | |||
skipping to change at page 47, line 36 | skipping to change at page 50, line 23 | |||
mechanisms to determine when to cease originating client signal | mechanisms to determine when to cease originating client signal | |||
fail indication are also technology specific. | fail indication are also technology specific. | |||
A sink MEP that has received a CFI indication report this | A sink MEP that has received a CFI indication report this | |||
condition to its associated client process via its local CFI | condition to its associated client process via its local CFI | |||
function. Consequent actions toward the client attachment | function. Consequent actions toward the client attachment | |||
circuit are technology specific. | circuit are technology specific. | |||
Either there needs to be a 1:1 correspondence between the client | Either there needs to be a 1:1 correspondence between the client | |||
and the MEG, or when multiple clients are multiplexed over a | and the MEG, or when multiple clients are multiplexed over a | |||
transport path, the CFI message requires additional information | transport path, the CFI packet requires additional information | |||
to permit the client instance to be identified. | to permit the client instance to be identified. | |||
MIPs, as well as intermediate nodes, do not process the CFI | MIPs, as well as intermediate nodes, do not process the CFI | |||
information and forward these pro-active CFI OAM packets as | information and forward these pro-active CFI OAM packets as | |||
regular data packets. | regular data packets. | |||
5.7.1. Configuration considerations | 5.7.1. Configuration considerations | |||
In order to support CFI indication, the CFI transmission rate | In order to support CFI indication, the CFI transmission rate | |||
and, for E-LSPs, the PHB of the CFI OAM message/information | and, for E-LSPs, the PHB of the CFI OAM packets should be | |||
element should be configured as part of the CFI configuration. | configured as part of the CFI configuration. | |||
6. OAM Functions for on-demand monitoring | 6. OAM Functions for on-demand monitoring | |||
In contrast to proactive monitoring, on-demand monitoring is | In contrast to proactive monitoring, on-demand monitoring is | |||
initiated manually and for a limited amount of time, usually for | initiated manually and for a limited amount of time, usually for | |||
operations such as diagnostics to investigate a defect | operations such as diagnostics to investigate a defect | |||
condition. | condition. | |||
On-demand monitoring covers a combination of "in-service" and | On-demand monitoring covers a combination of "in-service" and | |||
"out-of-service" monitoring functions. The control and | "out-of-service" monitoring functions. The control and | |||
skipping to change at page 48, line 48 | skipping to change at page 51, line 34 | |||
section 2.2.3 of RFC 5860 [11], is a transaction that flows from | section 2.2.3 of RFC 5860 [11], is a transaction that flows from | |||
the originating MEP to a target MIP or MEP to verify the | the originating MEP to a target MIP or MEP to verify the | |||
connectivity between these points. | connectivity between these points. | |||
Use of on-demand CV is dependent on the existence of either a | Use of on-demand CV is dependent on the existence of either a | |||
bi-directional ME, or an associated return ME, or the | bi-directional ME, or an associated return ME, or the | |||
availability of an out-of-band return path because it requires | availability of an out-of-band return path because it requires | |||
the ability for target MIPs and MEPs to direct responses to the | the ability for target MIPs and MEPs to direct responses to the | |||
originating MEPs. | originating MEPs. | |||
In order to preserve network resources, e.g. bandwidth, | One possible use of on-demand CV would be to perform fault | |||
processing time at switches, it may be preferable to not use | management without using proactive CC-V, in order to preserve | |||
proactive CC-V. In order to perform fault management functions, | network resources, e.g. bandwidth, processing time at switches. | |||
network management may invoke periodic on-demand bursts of on- | In this case, network management periodically invokes on-demand | |||
demand CV packets. | CV. | |||
An additional use of on-demand CV would be to detect and locate | An additional use of on-demand CV would be to detect and locate | |||
a problem of connectivity when a problem is suspected or known | a problem of connectivity when a problem is suspected or known | |||
based on other tools. In this case the functionality will be | based on other tools. In this case the functionality will be | |||
triggered by the network management in response to a status | triggered by the network management in response to a status | |||
signal or alarm indication. | signal or alarm indication. | |||
On-demand CV is based upon generation of on-demand CV packets | On-demand CV is based upon generation of on-demand CV packets | |||
that should uniquely identify the MEG that is being checked. | that should uniquely identify the MEG that is being checked. | |||
The on-demand functionality may be used to check either an | The on-demand functionality may be used to check either an | |||
entire MEG (end-to-end) or between the originating MEP and a | entire MEG (end-to-end) or between the originating MEP and a | |||
specific MIP. This functionality may not be available for | specific MIP. This functionality may not be available for | |||
associated bidirectional transport paths or unidirectional | associated bidirectional transport paths or unidirectional | |||
paths, as the MIP may not have a return path to the originating | paths, as the MIP may not have a return path to the originating | |||
MEP for the on-demand CV transaction. | MEP for the on-demand CV transaction. | |||
On-demand CV may generate a one-time burst of on-demand CV | When on-demand CV is invoked, the originating MEP issues a | |||
packets, or be used to invoke periodic, non-continuous, bursts | sequence of on-demand CV packets that uniquely identifies the | |||
of on-demand CV packets. The number of packets generated in | MEG being verified. The number of packets and their | |||
each burst is configurable at the MEPs, and should take into | transmission rate should be pre-configured at the originating | |||
account normal packet-loss conditions. | MEP, to take into account normal packet-loss conditions. The | |||
source MEP should use the mechanisms defined in sections 3.3 and | ||||
When invoking a periodic check of the MEG, the originating MEP | 3.4 when sending an on-demand CV packet to a target MEP or | |||
should issue a burst of on-demand CV packets that uniquely | target MIP respectively. The target MEP/MIP shall return a reply | |||
identifies the MEG being verified. The number of packets and | on-demand CV packet for each packet received. If the expected | |||
their transmission rate should be pre-configured at the | number of on-demand CV reply packets is not received at | |||
originating MEP. The source MEP should use the mechanisms | originating MEP, this is an indication that a connectivity | |||
defined in sections 3.3 and 3.4 when sending an on-demand CV | problem may exist. | |||
packet to a target MEP or target MIP respectively. The target | ||||
MEP/MIP shall return a reply on-demand CV packet for each packet | ||||
received. If the expected number of on-demand CV reply packets | ||||
is not received at originating MEP, this is an indication that a | ||||
connectivity problem may exist. | ||||
On-demand CV should have the ability to carry padding such that | On-demand CV should have the ability to carry padding such that | |||
a variety of MTU sizes can be originated to verify the MTU | a variety of MTU sizes can be originated to verify the MTU | |||
transport capability of the transport path. | transport capability of the transport path. | |||
MIPs that are not targeted by on-demand CV packets, as well as | MIPs that are not targeted by on-demand CV packets, as well as | |||
intermediate nodes, do not process the CV information and | intermediate nodes, do not process the CV information and | |||
forward these on-demand CV OAM packets as regular data packets. | forward these on-demand CV OAM packets as regular data packets. | |||
6.1.1. Configuration considerations | 6.1.1. Configuration considerations | |||
For on-demand CV the originating MEP should support the | For on-demand CV the originating MEP should support the | |||
configuration of the number of packets to be | configuration of the number of packets to be | |||
transmitted/received in each burst of transmissions and their | transmitted/received in each sequence of transmissions and their | |||
packet size. | packet size. | |||
In addition, when the CV packet is used to check connectivity | In addition, when the CV packet is used to check connectivity | |||
toward a target MIP, the number of hops to reach the target MIP | toward a target MIP, the number of hops to reach the target MIP | |||
should be configured. | should be configured. | |||
For E-LSPs, the PHB of the on-demand CV packets should be | For E-LSPs, the PHB of the on-demand CV packets should be | |||
configured as well. This permits the verification of correct | configured as well. This permits the verification of correct | |||
operation of QoS queuing as well as connectivity. | operation of QoS queuing as well as connectivity. | |||
6.2. Packet Loss Measurement | 6.2. Packet Loss Measurement | |||
On-demand Packet Loss Measurement (LM) is one of the | On-demand Packet Loss Measurement (LM) is one of the | |||
capabilities supported by the MPLS-TP Performance Monitoring | capabilities supported by the MPLS-TP Performance Monitoring | |||
function in order to facilitate the diagnosis of QoS | function in order to facilitate the diagnosis of QoS | |||
performances for a transport path, as required in section 2.2.11 | performances for a transport path, as required in section 2.2.11 | |||
of RFC 5860 [11]. As proactive LM, on-demand LM is used to | of RFC 5860 [11]. | |||
exchange counter values for the number of ingress and egress | ||||
packets transmitted and received by the transport path monitored | On-demand LM is very similar to pro-active LM described in | |||
by a pair of MEPs. LM is only performed between a pair of MEPs. | section 5.5. This section focuses on the differences between on- | |||
demand and pro-active LM. | ||||
On-demand LM is performed by periodically sending LM OAM packets | On-demand LM is performed by periodically sending LM OAM packets | |||
from a MEP to a peer MEP and by receiving LM OAM packets from | from a MEP to a peer MEP and by receiving LM OAM packets from | |||
the peer MEP (if a co-routed or associated bidirectional | the peer MEP (if a co-routed or associated bidirectional | |||
transport path) during a pre-defined monitoring period. Each MEP | transport path) during a pre-defined monitoring period. Each MEP | |||
performs measurements of its transmitted and received packets. | performs measurements of its transmitted and received user data | |||
These measurements are then correlated to evaluate the packet | packets. These measurements are then correlated to evaluate the | |||
loss performance metrics of the transport path. | packet loss performance metrics of the transport path. | |||
Use of packet loss measurement in an out-of-service transport | Use of packet loss measurement in an out-of-service transport | |||
path requires a traffic source such as a tester. | path requires a traffic source such as a test device that can | |||
inject synthetic traffic. | ||||
MIPs, as well as intermediate nodes, do not process the LM | ||||
information and forward these on-demand LM OAM packets as | ||||
regular data packets. | ||||
6.2.1. Configuration considerations | 6.2.1. Configuration considerations | |||
In order to support on-demand LM, the beginning and duration of | In order to support on-demand LM, the beginning and duration of | |||
the LM procedures, the transmission rate and, for E-LSPs, the | the LM procedures, the transmission rate and, for E-LSPs, the | |||
PHB associated with the LM OAM packets originating from a MEP | PHB class associated with the LM OAM packets originating from a | |||
must be configured as part of the on-demand LM provisioning. LM | MEP must be configured as part of the on-demand LM provisioning. | |||
OAM packets should be transmitted with the PHB that yields the | LM OAM packets should be transmitted with the PHB that yields | |||
lowest drop precedence within the measured PHB Scheduling Class | the lowest drop precedence as described in section 5.5.1. | |||
(see RFC 3260 [16]). | ||||
6.2.2. Sampling skew | 6.2.2. Sampling skew | |||
The same considerations described in section 5.5.2 for the | The same considerations described in section 5.5.2 for the | |||
pro-active LM are also applicable to on-demand LM | pro-active LM are also applicable to on-demand LM | |||
implementations. | implementations. | |||
6.2.3. Multilink issues | 6.2.3. Multilink issues | |||
Multi-link Issues are as described in section 5.5.3. | Multi-link Issues are as described in section 5.5.3. | |||
skipping to change at page 51, line 40 | skipping to change at page 54, line 18 | |||
According to RFC 2544 [12], this test is performed by sending | According to RFC 2544 [12], this test is performed by sending | |||
OAM test packets at increasing rate (up to the theoretical | OAM test packets at increasing rate (up to the theoretical | |||
maximum), computing the percentage of OAM test packets received | maximum), computing the percentage of OAM test packets received | |||
and reporting the rate at which OAM test packets begin to drop. | and reporting the rate at which OAM test packets begin to drop. | |||
In general, this rate is dependent on the OAM test packet size. | In general, this rate is dependent on the OAM test packet size. | |||
When configured to perform such tests, a source MEP inserts OAM | When configured to perform such tests, a source MEP inserts OAM | |||
test packets with a specified packet size and transmission | test packets with a specified packet size and transmission | |||
pattern at a rate to exercise the throughput. | pattern at a rate to exercise the throughput. | |||
The throughput test can create congestion within the network | ||||
impacting other transport paths. However, the test traffic | ||||
should comply with the traffic profile of the transport path | ||||
under test, so the impact of the test will not be worst than the | ||||
impact caused by the customers, whose traffic would be sent over | ||||
that transport path, sending the traffic at the maximum rate | ||||
allowed by their traffic profiles. Therefore, throughput tests | ||||
are not applicable to transport paths that do not have a defined | ||||
traffic profile, such as for instance, LSPs in a context where | ||||
statistical multiplexing is leveraged for network capacity | ||||
dimensioning. | ||||
For a one-way test, the remote sink MEP receives the OAM test | For a one-way test, the remote sink MEP receives the OAM test | |||
packets and calculates the packet loss. For a two-way test, the | packets and calculates the packet loss. For a two-way test, the | |||
remote MEP loopbacks the OAM test packets back to original MEP | remote MEP loopbacks the OAM test packets back to original MEP | |||
and the local sink MEP calculates the packet loss. | and the local sink MEP calculates the packet loss. | |||
It is worth noting that two-way throughput estimation is only | It is worth noting that two-way throughput estimation is only | |||
applicable to bidirectional (co-routed or associated) transport | applicable to bidirectional (co-routed or associated) transport | |||
paths and can only evaluate the minimum of available throughput | paths and can only evaluate the minimum of available throughput | |||
of the two directions. In order to estimate the throughput of | of the two directions. In order to estimate the throughput of | |||
each direction uniquely, two one-way throughput estimation | each direction uniquely, two one-way throughput estimation | |||
sessions have to be setup. | sessions have to be setup. One-way throughput estimation | |||
requires coordination between the transmitting and receiving | ||||
test devices as described in section 6 of RFC 2544 [12]. | ||||
It is also worth noting that if throughput estimation is | It is also worth noting that if throughput estimation is | |||
performed on transport paths that transit oversubscribed links, | performed on transport paths that transit oversubscribed links, | |||
the test may not produce comprehensive results if viewed in | the test may not produce comprehensive results if viewed in | |||
isolation because the impact of the test on the surrounding | isolation because the impact of the test on the surrounding | |||
traffic needs to also be considered. Moreover, the estimation | traffic needs to also be considered. Moreover, the estimation | |||
will only reflect the bandwidth available at the moment when the | will only reflect the bandwidth available at the moment when the | |||
measure is made. | measure is made. | |||
MIPs that are not target by on-demand test OAM packets, as well | MIPs that are not target by on-demand test OAM packets, as well | |||
skipping to change at page 52, line 32 | skipping to change at page 55, line 24 | |||
is started. | is started. | |||
A MEG can be put into a Lock status either via an NMS action or | A MEG can be put into a Lock status either via an NMS action or | |||
using the Lock Instruct OAM tool as defined in section 7. | using the Lock Instruct OAM tool as defined in section 7. | |||
At the transmitting MEP, provisioning is required for a test | At the transmitting MEP, provisioning is required for a test | |||
signal generator, which is associated with the MEP. At a | signal generator, which is associated with the MEP. At a | |||
receiving MEP, provisioning is required for a test signal | receiving MEP, provisioning is required for a test signal | |||
detector which is associated with the MEP. | detector which is associated with the MEP. | |||
In order to ensure accurate measurement, care needs to be taken | ||||
to enable throughput estimation only if all the MEPs within the | ||||
MEG can process OAM test packets at the same rate as the payload | ||||
data rates (see section 6.3.1.2). | ||||
6.3.1.2. Limited OAM processing rate | 6.3.1.2. Limited OAM processing rate | |||
If an implementation is able to process payload at much higher | If an implementation is able to process payload at much higher | |||
data rates than OAM test packets, then accurate measurement of | data rates than OAM test packets, then accurate measurement of | |||
throughput using OAM test packets is not achievable. Whether | throughput using OAM test packets is not achievable. Whether | |||
OAM packets can be processed at the same rate as payload is | OAM packets can be processed at the same rate as payload is | |||
implementation dependent. | implementation dependent. | |||
6.3.1.3. Multilink considerations | 6.3.1.3. Multilink considerations | |||
skipping to change at page 53, line 17 | skipping to change at page 56, line 15 | |||
normal per hop processing such as TTL decrement. | normal per hop processing such as TTL decrement. | |||
The data plane loopback function requires that the MEG is locked | The data plane loopback function requires that the MEG is locked | |||
such that user data traffic is prevented from entering/exiting | such that user data traffic is prevented from entering/exiting | |||
that MEG. Instead, test traffic is inserted at the ingress of | that MEG. Instead, test traffic is inserted at the ingress of | |||
the MEG. This test traffic can be generated from an internal | the MEG. This test traffic can be generated from an internal | |||
process residing within the ingress node or injected by external | process residing within the ingress node or injected by external | |||
test equipment connected to the ingress node. | test equipment connected to the ingress node. | |||
It is also normal to disable proactive monitoring of the path as | It is also normal to disable proactive monitoring of the path as | |||
the sink MEP will see all the OAM messages, originated by the | the MEP located upstream with respect to the node set in the | |||
associated source MEP, returned to it. | data plane loopback mode will see all the OAM packets, | |||
originated by itself and this may interfere with other | ||||
measurements. | ||||
The only way to send an OAM packet (e.g., to remove the data | The only way to send an OAM packet (e.g., to remove the data | |||
plane loopback state) to the MIPs or MEPs hosted by a node set | plane loopback state) to the MIPs or MEPs hosted by a node set | |||
in the data plane loopback mode is via TTL expiry. It should | in the data plane loopback mode is via TTL expiry. It should | |||
also be noted that MIPs can be addressed with more than one TTL | also be noted that MIPs can be addressed with more than one TTL | |||
value on a co-routed bi-directional path set into dataplane | value on a co-routed bi-directional path set into data plane | |||
loopback. | loopback. | |||
If the loopback function is to be performed at an intermediate | If the loopback function is to be performed at an intermediate | |||
node it is only applicable to co-routed bi-directional paths. If | node it is only applicable to co-routed bi-directional paths. If | |||
the loopback is to be performed end to end, it is applicable to | the loopback is to be performed end to end, it is applicable to | |||
both co-routed bi-directional or associated bi-directional | both co-routed bi-directional or associated bi-directional | |||
paths. | paths. | |||
It should be noted that data plane loopback function itself is | It should be noted that data plane loopback function itself is | |||
applied to data-plane loopback points that can resides on | applied to data plane loopback points that can resides on | |||
different interfaces from MIPs/MEPs. Where a node implements | different interfaces from MIPs/MEPs. Where a node implements | |||
data plane loopback capability and whether it implements it in | data plane loopback capability and whether it implements it in | |||
more than one point is implementation dependent. | more than one point is implementation dependent. | |||
6.3.2.1. Configuration considerations | 6.3.2.1. Configuration considerations | |||
Data plane loopback is an out-of-service tool. The MEG which | Data plane loopback is an out-of-service tool. The MEG which | |||
defines a diagnosed transport path should be put into a locked | defines a diagnosed transport path should be put into a locked | |||
state before the diagnostic test is started. However, a means is | state before the diagnostic test is started. However, a means is | |||
required to permit the originated test traffic to be inserted at | required to permit the originated test traffic to be inserted at | |||
skipping to change at page 55, line 9 | skipping to change at page 58, line 9 | |||
the transport path monitored by a pair of MEPs during a pre- | the transport path monitored by a pair of MEPs during a pre- | |||
defined monitoring period. | defined monitoring period. | |||
On-Demand DM is performed by sending periodic DM OAM packets | On-Demand DM is performed by sending periodic DM OAM packets | |||
from a MEP to a peer MEP and by receiving DM OAM packets from | from a MEP to a peer MEP and by receiving DM OAM packets from | |||
the peer MEP (if a co-routed or associated bidirectional | the peer MEP (if a co-routed or associated bidirectional | |||
transport path) during a configurable time interval. | transport path) during a configurable time interval. | |||
On-demand DM can be operated in two modes: | On-demand DM can be operated in two modes: | |||
o One-way: a MEP sends DM OAM packet to its peer MEP containing | o One-way: a MEP sends DM OAM packet to its peer MEP containing | |||
all the required information to facilitate one-way packet | all the required information to facilitate one-way packet | |||
delay and/or one-way packet delay variation measurements at | delay and/or one-way packet delay variation measurements at | |||
the peer MEP. Note that this requires precise time | the peer MEP. Note that this requires precise time | |||
synchronisation at either MEP by means outside the scope of | synchronisation at either MEP by means outside the scope of | |||
this framework. | this framework. | |||
o Two-way: a MEP sends DM OAM packet with a DM request to its | o Two-way: a MEP sends DM OAM packet with a DM request to its | |||
peer MEP, which replies with an DM OAM packet as a DM | peer MEP, which replies with an DM OAM packet as a DM | |||
response. The request/response DM OAM packets containing all | response. The request/response DM OAM packets containing all | |||
the required information to facilitate two-way packet delay | the required information to facilitate two-way packet delay | |||
and/or two-way packet delay variation measurements from the | and/or two-way packet delay variation measurements from the | |||
viewpoint of the originating MEP. | viewpoint of the originating MEP. | |||
MIPs, as well as intermediate nodes, do not process the DM | MIPs, as well as intermediate nodes, do not process the DM | |||
information and forward these on-demand DM OAM packets as | information and forward these on-demand DM OAM packets as | |||
regular data packets. | regular data packets. | |||
6.5.1. Configuration considerations | 6.5.1. Configuration considerations | |||
In order to support on-demand DM, the beginning and duration of | In order to support on-demand DM, the beginning and duration of | |||
the DM procedures, the transmission rate and, for E-LSPs, the | the DM procedures, the transmission rate and, for E-LSPs, the | |||
PHB associated with the DM OAM packets originating from a MEP | PHB associated with the DM OAM packets originating from a MEP | |||
need be configured as part of the DM provisioning. DM OAM | need be configured as part of the DM provisioning. DM OAM | |||
packets should be transmitted with the PHB that yields the | packets should be transmitted with the PHB that yields the | |||
lowest drop precedence within the measured PHB Scheduling Class | lowest drop precedence within the measured PHB Scheduling Class | |||
(see RFC 3260 [16]). | (see RFC 3260 [17]). | |||
In order to verify different performances between long and short | In order to verify different performances between long and short | |||
packets (e.g., due to the processing time), it should be | packets (e.g., due to the processing time), it should be | |||
possible for the operator to configure the packet size of the | possible for the operator to configure the packet size of the | |||
on-demand OAM DM packet. | on-demand OAM DM packet. | |||
7. OAM Functions for administration control | 7. OAM Functions for administration control | |||
7.1. Lock Instruct | 7.1. Lock Instruct | |||
skipping to change at page 56, line 31 | skipping to change at page 59, line 31 | |||
A MEP, upon receiving a single-side administrative lock command | A MEP, upon receiving a single-side administrative lock command | |||
from an NMS, sends an LKI request OAM packet to its peer MEP(s). | from an NMS, sends an LKI request OAM packet to its peer MEP(s). | |||
It also puts the MPLS-TP transport path into a locked state and | It also puts the MPLS-TP transport path into a locked state and | |||
notifies its client (sub-)layer adaptation function upon the | notifies its client (sub-)layer adaptation function upon the | |||
locked condition. | locked condition. | |||
A MEP, upon receiving an LKI request from its peer MEP, can | A MEP, upon receiving an LKI request from its peer MEP, can | |||
either accept or reject the instruction and replies to the peer | either accept or reject the instruction and replies to the peer | |||
MEP with an LKI reply OAM packet indicating whether or not it | MEP with an LKI reply OAM packet indicating whether or not it | |||
has accepted the instruction. This requires either an in-band or | has accepted the instruction. This requires either an in-band or | |||
out-of-band return path. | out-of-band return path. The LKI reply is needed to allow the | |||
MEP to properly report to the NMS the actual result of the | ||||
single-side administrative lock command. | ||||
If the lock instruction has been accepted, it also puts the | If the lock instruction has been accepted, it also puts the | |||
MPLS-TP transport path into a locked state and notifies its | MPLS-TP transport path into a locked state and notifies its | |||
client (sub-)layer adaptation function upon the locked | client (sub-)layer adaptation function upon the locked | |||
condition. | condition. | |||
Note that if the client (sub-)layer is also MPLS-TP, Lock | Note that if the client (sub-)layer is also MPLS-TP, Lock | |||
Reporting (LKR) generation at the client MPLS-TP (sub-)layer is | Reporting (LKR) generation at the client MPLS-TP (sub-)layer is | |||
started, as described in section 5.4. | started, as described in section 5.4. | |||
7.1.2. Unlocking a transport path | 7.1.2. Unlocking a transport path | |||
A MEP, upon receiving a single-side administrative unlock | A MEP, upon receiving a single-side administrative unlock | |||
command from NMS, sends an LKI removal request OAM packet to its | command from NMS, sends an LKI removal request OAM packet to its | |||
peer MEP(s). | peer MEP(s). | |||
The peer MEP, upon receiving an LKI removal request, can either | The peer MEP, upon receiving an LKI removal request, can either | |||
accept or reject the removal instruction and replies with an LKI | accept or reject the removal instruction and replies with an LKI | |||
removal reply OAM packet indicating whether or not it has | removal reply OAM packet indicating whether or not it has | |||
accepted the instruction. | accepted the instruction. The LKI removal reply is needed to | |||
allow the MEP to properly report to the NMS the actual result of | ||||
the single-side administrative unlock command. | ||||
If the lock removal instruction has been accepted, it also | If the lock removal instruction has been accepted, it also | |||
clears the locked condition on the MPLS-TP transport path and | clears the locked condition on the MPLS-TP transport path and | |||
notifies this event to its client (sub-)layer adaptation | notifies this event to its client (sub-)layer adaptation | |||
function. | function. | |||
The MEP that has initiated the LKI clear procedure, upon | The MEP that has initiated the LKI clear procedure, upon | |||
receiving a positive LKI removal reply, also clears the locked | receiving a positive LKI removal reply, also clears the locked | |||
condition on the MPLS-TP transport path and notifies this event | condition on the MPLS-TP transport path and notifies this event | |||
to its client (sub-)layer adaptation function. | to its client (sub-)layer adaptation function. | |||
skipping to change at page 57, line 28 | skipping to change at page 60, line 31 | |||
8. Security Considerations | 8. Security Considerations | |||
A number of security considerations are important in the context | A number of security considerations are important in the context | |||
of OAM applications. | of OAM applications. | |||
OAM traffic can reveal sensitive information such as performance | OAM traffic can reveal sensitive information such as performance | |||
data and details about the current state of the network. | data and details about the current state of the network. | |||
Insertion of, or modifications to OAM transactions can mask the | Insertion of, or modifications to OAM transactions can mask the | |||
true operational state of the network and in the case of | true operational state of the network and in the case of | |||
transactions for administration control, such as Lock or | transactions for administration control, such as Lock or data | |||
dataplane loopback instructions, these can be used for explicit | plane loopback instructions, these can be used for explicit | |||
denial of service attacks. The effect of such attacks is | denial of service attacks. The effect of such attacks is | |||
mitigated only by the fact that the managed entities whose state | mitigated only by the fact that, for in-band messaging, the | |||
can be masked is limited to those that transit the point of | managed entities whose state can be masked is limited to those | |||
malicious access to the network internals due to the fate | that transit the point of malicious access to the network | |||
sharing nature of OAM messaging. | internals due to the fate sharing nature of OAM messaging. This | |||
is not true when an out of band return path is employed. | ||||
The sensitivity of OAM data therefore suggests that one solution | The sensitivity of OAM data therefore suggests that one solution | |||
is that some form of authentication, authorization and | is that some form of authentication, authorization and | |||
encryption is in place. This will prevent unauthorized access to | encryption is in place. This will prevent unauthorized access to | |||
vital equipment and it will prevent third parties from learning | vital equipment and it will prevent third parties from learning | |||
about sensitive information about the transport network. However | about sensitive information about the transport network. However | |||
it should be observed that the combination of the need for | it should be observed that the combination of the frequency of | |||
timeliness of OAM transaction exchange and all permutations of | some OAM transactions, the need for timeliness of OAM | |||
unique MEP to MEP, MEP to MIP, and intermediate system | transaction exchange and all permutations of unique MEP to MEP, | |||
originated transactions mitigates against the practical | MEP to MIP, and intermediate system originated transactions | |||
establishment and maintenance of a large number of security | mitigates against the practical establishment and maintenance of | |||
associations per MEG either in advance or as required. | a large number of security associations per MEG either in | |||
advance or as required. | ||||
For this reason it is assumed that the internal links of the | For this reason it is assumed that the internal links of the | |||
network is physically secured from malicious access such that | network is physically secured from malicious access such that | |||
OAM transactions scoped to fault and performance management of | OAM transactions scoped to fault and performance management of | |||
individual MEGs are not encumbered with additional security. | individual MEGs are not encumbered with additional security. | |||
Further it is assumed in multi-provider cases where OAM | ||||
transactions originate outside of an individual providers | ||||
trusted domain that filtering mechanisms or further | ||||
encapsulation will need to constrain the potential impact of | ||||
malicious transactions. Mechanisms that the framework does not | ||||
specify might be subject to additional security considerations. | ||||
Mechanisms that the framework does not specify might be subject | In case of mis-configuration, some nodes can receive OAM packets | |||
to additional security considerations. | that they cannot recognize. In such a case, these OAM packets | |||
should be silently discarded in order to avoid malfunctions | ||||
whose effect may be similar to malicious attacks (e.g., degraded | ||||
performance or even failure). Further considerations about data | ||||
plane attacks via G-ACh are provided in RFC 5921 [8]. | ||||
9. IANA Considerations | 9. IANA Considerations | |||
No new IANA considerations. | This memo does not have any IANA considerations. | |||
10. Acknowledgments | 10. Acknowledgments | |||
The authors would like to thank all members of the teams (the | The authors would like to thank all members of the teams (the | |||
Joint Working Team, the MPLS Interoperability Design Team in | Joint Working Team, the MPLS Interoperability Design Team in | |||
IETF and the Ad Hoc Group on MPLS-TP in ITU-T) involved in the | IETF and the Ad Hoc Group on MPLS-TP in ITU-T) involved in the | |||
definition and specification of MPLS Transport Profile. | definition and specification of MPLS Transport Profile. | |||
The editors gratefully acknowledge the contributions of Adrian | The editors gratefully acknowledge the contributions of Adrian | |||
Farrel, Yoshinori Koike, Luca Martini, Yuji Tochio and Manuel | Farrel, Yoshinori Koike, Luca Martini, Yuji Tochio and Manuel | |||
Paul for the definition of per-interface MIPs and MEPs. | Paul for the definition of per-interface MIPs and MEPs. | |||
The editors gratefully acknowledge the contributions of Malcolm | The editors gratefully acknowledge the contributions of Malcolm | |||
Betts, Yoshinori Koike, Xiao Min, and Maarten Vissers for the | Betts, Yoshinori Koike, Xiao Min, and Maarten Vissers for the | |||
lock report and lock instruction description. | lock report and lock instruction description. | |||
The authors would also like to thank Alessandro D'Alessandro, | The authors would also like to thank Alessandro D'Alessandro, | |||
Loa Andersson, Malcolm Betts, Stewart Bryant, Rui Costa, Xuehui | Loa Andersson, Malcolm Betts, Dave Black, Stewart Bryant, Rui | |||
Dai, John Drake, Adrian Farrel, Dan Frost, Xia Liang, Liu | Costa, Xuehui Dai, John Drake, Adrian Farrel, Dan Frost, Xia | |||
Gouman, Peng He, Feng Huang, Su Hui, Yoshionori Koike, George | Liang, Liu Gouman, Peng He, Russ Housley, Feng Huang, Su Hui, | |||
Swallow, Yuji Tochio, Curtis Villamizar, Maarten Vissers and | Yoshionori Koike, Thomas Morin, George Swallow, Yuji Tochio, | |||
Xuequin Wei for their comments and enhancements to the text. | Curtis Villamizar, Maarten Vissers and Xuequin Wei for their | |||
comments and enhancements to the text. | ||||
This document was prepared using 2-Word-v2.0.template.dot. | This document was prepared using 2-Word-v2.0.template.dot. | |||
11. References | 11. References | |||
11.1. Normative References | 11.1. Normative References | |||
[1] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol | [1] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol | |||
Label Switching Architecture", RFC 3031, January 2001 | Label Switching Architecture", RFC 3031, January 2001 | |||
[2] Bryant, S., Pate, P., "Pseudo Wire Emulation Edge-to-Edge | [2] Bryant, S., Pate, P., "Pseudo Wire Emulation Edge-to-Edge | |||
(PWE3) Architecture", RFC 3985, March 2005 | (PWE3) Architecture", RFC 3985, March 2005 | |||
[3] Nadeau, T., Pignataro, S., "Pseudowire Virtual Circuit | [3] Nadeau, T., Pignataro, S., "Pseudowire Virtual Circuit | |||
Connectivity Verification (VCCV): A Control Channel for | Connectivity Verification (VCCV): A Control Channel for | |||
Pseudowires", RFC 5085, December 2007 | Pseudowires", RFC 5085, December 2007 | |||
[4] Bocci, M., Bryant, S., "An Architecture for Multi-Segment | [4] Bocci, M., Bryant, S., "An Architecture for Multi-Segment | |||
Pseudo Wire Emulation Edge-to-Edge", RFC 5659, October | Pseudo Wire Emulation Edge-to-Edge", RFC 5659, October | |||
2009 | 2009 | |||
[5] Niven-Jenkins, B., Brungard, D., Betts, M., sprecher, N., | [5] Niven-Jenkins, B., Brungard, D., Betts, M., sprecher, N., | |||
Ueno, S., "MPLS-TP Requirements", RFC 5654, September 2009 | Ueno, S., "MPLS-TP Requirements", RFC 5654, September 2009 | |||
[6] Agarwal, P., Akyol, B., "Time To Live (TTL) Processing in | [6] Agarwal, P., Akyol, B., "Time To Live (TTL) Processing in | |||
Multiprotocol Label Switching (MPLS) Networks", RFC 3443, | Multiprotocol Label Switching (MPLS) Networks", RFC 3443, | |||
January 2003 | January 2003 | |||
[7] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, | [7] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, | |||
R., "MPLS Generic Associated Channel", RFC 5586, June 2009 | R., "MPLS Generic Associated Channel", RFC 5586, June 2009 | |||
[8] Bocci, M., et al., "A Framework for MPLS in Transport | [8] Bocci, M., et al., "A Framework for MPLS in Transport | |||
Networks", RFC 5921, July 2010 | Networks", RFC 5921, July 2010 | |||
[9] Bocci, M., et al., " MPLS Transport Profile User-to-Network and | [9] Bocci, M., et al., " MPLS Transport Profile User-to-Network and | |||
Network-to-Network Interfaces", draft-ietf-mpls-tp-uni-nni-02 | Network-to-Network Interfaces", draft-ietf-mpls-tp-uni-nni-03 | |||
(work in progress), December 2010 | (work in progress), January 2011 | |||
[10] Swallow, G., Bocci, M., "MPLS-TP Identifiers", draft-ietf- | [10] Swallow, G., Bocci, M., "MPLS-TP Identifiers", draft-ietf- | |||
mpls-tp-identifiers-03 (work in progress), December 2010 | mpls-tp-identifiers-03 (work in progress), October 2010 | |||
[11] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM | [11] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM | |||
in MPLS Transport Networks", RFC 5860, May 2010 | in MPLS Transport Networks", RFC 5860, May 2010 | |||
[12] Bradner, S., McQuaid, J., "Benchmarking Methodology for | [12] Bradner, S., McQuaid, J., "Benchmarking Methodology for | |||
Network Interconnect Devices", RFC 2544, March 1999 | Network Interconnect Devices", RFC 2544, March 1999 | |||
[13] ITU-T Recommendation G.806 (01/09), "Characteristics of | [13] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., | |||
transport equipment - Description methodology and generic | Weiss, W., "An Architecture for Differentiated Services", | |||
functionality ", January 2009 | RFC 2475, December 1998 | |||
[14] ITU-T Recommendation G.806 (01/09), "Characteristics of | ||||
transport equipment - Description methodology and generic | ||||
functionality ", January 2009 | ||||
11.2. Informative References | 11.2. Informative References | |||
[14] Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten, | [15] Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten, | |||
Y., "MPLS-TP OAM Analysis", draft-ietf-mpls-tp-oam- | Y., "MPLS-TP OAM Analysis", draft-ietf-mpls-tp-oam- | |||
analysis-02 (work in progress), July 2010 | analysis-03 (work in progress), January 2011 | |||
[15] Nichols, K., Blake, S., Baker, F., Black, D., "Definition | [16] Nichols, K., Blake, S., Baker, F., Black, D., "Definition | |||
of the Differentiated Services Field (DS Field) in the | of the Differentiated Services Field (DS Field) in the | |||
IPv4 and IPv6 Headers", RFC 2474, December 1998 | IPv4 and IPv6 Headers", RFC 2474, December 1998 | |||
[16] Grossman, D., "New terminology and clarifications for | [17] Grossman, D., "New terminology and clarifications for | |||
Diffserv", RFC 3260, April 2002. | Diffserv", RFC 3260, April 2002. | |||
[17] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in | [18] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in | |||
MPLS Traffic Engineering (TE)", RFC 4201, October 2005 | MPLS Traffic Engineering (TE)", RFC 4201, October 2005 | |||
[18] ITU-T Recommendation G.707/Y.1322 (01/07), "Network node | [19] ITU-T Recommendation G.707/Y.1322 (01/07), "Network node | |||
interface for the synchronous digital hierarchy (SDH)", | interface for the synchronous digital hierarchy (SDH)", | |||
January 2007 | January 2007 | |||
[19] ITU-T Recommendation G.805 (03/00), "Generic functional | [20] ITU-T Recommendation G.805 (03/00), "Generic functional | |||
architecture of transport networks", March 2000 | architecture of transport networks", March 2000 | |||
[20] ITU-T Recommendation Y.1731 (02/08), "OAM functions and | [21] ITU-T Recommendation Y.1731 (02/08), "OAM functions and | |||
mechanisms for Ethernet based networks", February 2008 | mechanisms for Ethernet based networks", February 2008 | |||
[21] IEEE Standard 802.1AX-2008, "IEEE Standard for Local and | [22] IEEE Standard 802.1AX-2008, "IEEE Standard for Local and | |||
Metropolitan Area Networks - Link Aggregation", November | Metropolitan Area Networks - Link Aggregation", November | |||
2008 | 2008 | |||
[22] Le Faucheur et.al. " Multi-Protocol Label Switching (MPLS) | [23] Le Faucheur et.al., "Multi-Protocol Label Switching (MPLS) | |||
Support of Differentiated Services", RFC 3270, May 2002. | Support of Differentiated Services", RFC 3270, May 2002. | |||
Authors' Addresses | Authors' Addresses | |||
Dave Allan | Dave Allan | |||
Ericsson | Ericsson | |||
Email: david.i.allan@ericsson.com | Email: david.i.allan@ericsson.com | |||
Italo Busi | Italo Busi | |||
Alcatel-Lucent | Alcatel-Lucent | |||
Email: Italo.Busi@alcatel-lucent.com | Email: Italo.Busi@alcatel-lucent.com | |||
Ben Niven-Jenkins | Ben Niven-Jenkins | |||
Velocix | Velocix | |||
Email: ben@niven-jenkins.co.uk | Email: ben@niven-jenkins.co.uk | |||
Annamaria Fulignoli | Annamaria Fulignoli | |||
Ericsson | Ericsson | |||
Email: annamaria.fulignoli@ericsson.com | Email: annamaria.fulignoli@ericsson.com | |||
End of changes. 232 change blocks. | ||||
569 lines changed or deleted | 712 lines changed or added | |||
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |