draft-ietf-mpls-tp-oam-framework-09.txt | draft-ietf-mpls-tp-oam-framework-10.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: April 7, 2011 October 7, 2010 | Expires: June 16, 2011 December 16, 2010 | |||
Operations, Administration and Maintenance Framework for MPLS- | Operations, Administration and Maintenance Framework for MPLS- | |||
based Transport Networks | based Transport Networks | |||
draft-ietf-mpls-tp-oam-framework-09.txt | draft-ietf-mpls-tp-oam-framework-10.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 April 7, 2011. | This Internet-Draft will expire on June 16, 2011. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2010 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.....................................6 | |||
2. Conventions used in this document.............................6 | 2. Conventions used in this document.............................7 | |||
2.1. Terminology..............................................6 | 2.1. Terminology..............................................7 | |||
2.2. Definitions..............................................7 | 2.2. Definitions..............................................8 | |||
3. Functional Components........................................10 | 3. Functional Components........................................12 | |||
3.1. Maintenance Entity and Maintenance Entity Group.........10 | 3.1. Maintenance Entity and Maintenance Entity Group.........12 | |||
3.2. Nested MEGs: SPMEs and Tandem Connection Monitoring.....12 | 3.2. Nested MEGs: SPMEs and Tandem Connection Monitoring.....14 | |||
3.3. MEG End Points (MEPs)...................................14 | 3.3. MEG End Points (MEPs)...................................16 | |||
3.4. MEG Intermediate Points (MIPs)..........................17 | 3.4. MEG Intermediate Points (MIPs)..........................19 | |||
3.5. Server MEPs.............................................18 | 3.5. Server MEPs.............................................21 | |||
3.6. Configuration Considerations............................19 | 3.6. Configuration Considerations............................22 | |||
3.7. P2MP considerations.....................................20 | 3.7. P2MP considerations.....................................22 | |||
3.8. Further considerations of enhanced segment monitoring...21 | 3.8. Further considerations of enhanced segment monitoring...23 | |||
4. Reference Model..............................................21 | 4. Reference Model..............................................25 | |||
4.1. MPLS-TP Section Monitoring (SME)........................23 | 4.1. MPLS-TP Section Monitoring (SMEG).......................27 | |||
4.2. MPLS-TP LSP End-to-End Monitoring (LME).................24 | 4.2. MPLS-TP LSP End-to-End Monitoring Group (LMEG)..........28 | |||
4.3. MPLS-TP PW Monitoring (PME).............................25 | 4.3. MPLS-TP PW Monitoring (PMEG)............................28 | |||
4.4. MPLS-TP LSP SPME Monitoring (LSME)......................25 | 4.4. MPLS-TP LSP SPME Monitoring (LSMEG).....................29 | |||
4.5. MPLS-TP MS-PW SPME Monitoring (PSME)....................27 | 4.5. MPLS-TP MS-PW SPME Monitoring (PSMEG)...................30 | |||
4.6. Fate sharing considerations for multilink...............28 | 4.6. Fate sharing considerations for multilink...............32 | |||
5. OAM Functions for proactive monitoring.......................29 | 5. OAM Functions for proactive monitoring.......................32 | |||
5.1. Continuity Check and Connectivity Verification..........30 | 5.1. Continuity Check and Connectivity Verification..........33 | |||
5.1.1. Defects identified by CC-V.........................32 | 5.1.1. Defects identified by CC-V.........................36 | |||
5.1.2. Consequent action..................................34 | 5.1.2. Consequent action..................................37 | |||
5.1.3. Configuration considerations.......................35 | 5.1.3. Configuration considerations.......................38 | |||
5.2. Remote Defect Indication................................36 | 5.2. Remote Defect Indication................................40 | |||
5.2.1. Configuration considerations.......................37 | 5.2.1. Configuration considerations.......................40 | |||
5.3. Alarm Reporting.........................................37 | 5.3. Alarm Reporting.........................................41 | |||
5.4. Lock Reporting..........................................39 | 5.4. Lock Reporting..........................................42 | |||
5.5. Packet Loss Measurement.................................40 | 5.5. Packet Loss Measurement.................................44 | |||
5.5.1. Configuration considerations.......................41 | 5.5.1. Configuration considerations.......................45 | |||
5.5.2. Sampling skew......................................41 | 5.5.2. Sampling skew......................................45 | |||
5.5.3. Multilink issues...................................41 | 5.5.3. Multilink issues...................................45 | |||
5.6. Packet Delay Measurement................................42 | 5.6. Packet Delay Measurement................................46 | |||
5.6.1. Configuration considerations.......................42 | 5.6.1. Configuration considerations.......................46 | |||
5.7. Client Failure Indication...............................42 | 5.7. Client Failure Indication...............................47 | |||
5.7.1. Configuration considerations.......................43 | 5.7.1. Configuration considerations.......................47 | |||
6. OAM Functions for on-demand monitoring.......................43 | 6. OAM Functions for on-demand monitoring.......................48 | |||
6.1. Connectivity Verification...............................44 | 6.1. Connectivity Verification...............................48 | |||
6.1.1. Configuration considerations.......................45 | 6.1.1. Configuration considerations.......................49 | |||
6.2. Packet Loss Measurement.................................45 | 6.2. Packet Loss Measurement.................................50 | |||
6.2.1. Configuration considerations.......................46 | 6.2.1. Configuration considerations.......................50 | |||
6.2.2. Sampling skew......................................46 | 6.2.2. Sampling skew......................................51 | |||
6.2.3. Multilink issues...................................46 | 6.2.3. Multilink issues...................................51 | |||
6.3. Diagnostic Tests........................................47 | 6.3. Diagnostic Tests........................................51 | |||
6.3.1. Throughput Estimation.............................47 | 6.3.1. Throughput Estimation.............................51 | |||
6.3.2. Data plane Loopback...............................48 | 6.3.2. Data plane Loopback...............................52 | |||
6.4. Route Tracing..........................................49 | 6.4. Route Tracing..........................................54 | |||
6.4.1. Configuration considerations......................50 | 6.4.1. Configuration considerations......................54 | |||
6.5. Packet Delay Measurement...............................50 | 6.5. Packet Delay Measurement...............................54 | |||
6.5.1. Configuration considerations......................51 | 6.5.1. Configuration considerations......................55 | |||
7. OAM Functions for administration control....................51 | 7. OAM Functions for administration control....................55 | |||
7.1. Lock Instruct..........................................51 | 7.1. Lock Instruct..........................................55 | |||
7.1.1. Locking a transport path..........................51 | 7.1.1. Locking a transport path..........................56 | |||
7.1.2. Unlocking a transport path........................52 | 7.1.2. Unlocking a transport path........................56 | |||
8. Security Considerations.....................................52 | 8. Security Considerations.....................................57 | |||
9. IANA Considerations.........................................53 | 9. IANA Considerations.........................................58 | |||
10. Acknowledgments............................................53 | 10. Acknowledgments............................................58 | |||
11. References.................................................54 | 11. References.................................................59 | |||
11.1. Normative References..................................54 | 11.1. Normative References..................................59 | |||
11.2. Informative References................................55 | 11.2. Informative References................................60 | |||
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 31 | skipping to change at page 5, line 31 | |||
[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 [14], 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. Extensions do not deprecate support for | meet the requirements. Some extensions discussed in this | |||
framework may end up as aspirational capabilities and may be | ||||
determined to be not tractably realizable in some | ||||
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 | |||
comprehensive set of OAM procedures that satisfy the MPLS-TP OAM | protocol neutral description of the required OAM functions and | |||
requirements of RFC 5860 [11]. In this regard, it defines | of the data plane OAM architecture to support a comprehensive | |||
similar OAM functionality as for existing SONET/SDH and OTN OAM | set of OAM procedures that satisfy the MPLS-TP OAM requirements | |||
mechanisms (e.g. [18]). | of RFC 5860 [11]. In this regard, it defines similar OAM | |||
functionality as for existing SONET/SDH and OTN OAM mechanisms | ||||
(e.g. [18]). | ||||
The MPLS-TP OAM framework is applicable to sections, LSPs and | The MPLS-TP OAM framework is applicable to sections, Label | |||
(MS-)PWs and supports co-routed and associated bidirectional p2p | Switched Paths (LSPs), Multi-Segment Pseudowires (MS-)PWs and | |||
transport paths as well as unidirectional p2p and p2mp transport | Sub Path Maintenance Entities (SPMEs). It supports co-routed and | |||
paths. | associated bidirectional p2p transport paths as well as | |||
unidirectional p2p and p2mp transport paths. | ||||
OAM packets that instrument a particular direction of a | ||||
transport path are subject to the same forwarding treatment | ||||
(i.e. fate share) as the data traffic and in some cases, where | ||||
Explicitly TC-encoded-PSC LSPs (E-LSPs) are employed, may be | ||||
required to have common Per-hop Behavior (PHB) scheduling class | ||||
(PSC) E2E with the class of traffic monitored. In case of | ||||
Label-Only-Inferred-PSC LSP (L-LSP), only one class of traffic | ||||
needs to be monitored and therefore the OAM packets have common | ||||
PSC with the monitored traffic class. | ||||
OAM packets can be distinguished from the data traffic using the | ||||
GAL and ACH constructs of RFC 5586 [7] for LSP, SPME and Section | ||||
or the ACH construct of RFC 5085 [3]and RFC 5586 [7] for | ||||
(MS-)PW. | ||||
This framework makes certain assumptions as to the utility and | ||||
frequency of different classes of measurement that naturally | ||||
suggest different functions are implemented as distinct OAM | ||||
flows or messages. This is dictated by the combination of the | ||||
class of problem being detected and the need for timeliness of | ||||
network response to the problem. For example fault detection is | ||||
expected to operate on an entirely different time base than | ||||
performance monitoring which is also expected to operate on an | ||||
entirely different time base than in band management | ||||
transactions. | ||||
Section 3 describes the functional component that generates and | ||||
processes OAM packets. | ||||
Section 4 describes the reference models for applying OAM | ||||
functions to Sections, LSP, MS-PW and their SPMEs. | ||||
Sections 5, 6 and 7 provide a protocol-neutral description of | ||||
the OAM functions, defined in RFC 5860 [11], aimed at clarifying | ||||
how the OAM protocol solutions will behave to achieve their | ||||
functional objectives. | ||||
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 | |||
CV Connectivity Verification | CC Continuity Check | |||
DBN Domain Border Node | CC-V Continuity Check and Connectivity Verification | |||
LER Label Edge Router | CV Connectivity Verification | |||
LKR Lock Report | DBN Domain Border Node | |||
LM Loss Measurement | E-LSP Explicitly TC-encoded-PSC LSP | |||
LME LSP Maintenance Entity | ICC ITU Carrier Code | |||
LMEG LSP ME Group | LER Label Edge Router | |||
LSP Label Switched Path | LKR Lock Report | |||
LSR Label Switching Router | L-LSP Label-Only-Inferred-PSC LSP | |||
LSME LSP SPME ME | LM Loss Measurement | |||
LME LSP Maintenance Entity | ||||
LMEG LSP ME Group | ||||
LSP Label Switched Path | ||||
LSR Label Switching Router | ||||
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 | ||||
PHB Per-hop Behavior | PE Provider Edge | |||
PM Performance Monitoring | PHB Per-hop Behavior | |||
PME PW Maintenance Entity | ||||
PMEG PW ME Group | PM Performance Monitoring | |||
PSME PW SPME ME | PME PW Maintenance Entity | |||
PMEG PW ME Group | ||||
PSC PHB Scheduling Class | ||||
PSME PW SPME ME | ||||
PSMEG PW SPME ME Group | PSMEG PW SPME ME Group | |||
PW Pseudowire | PW Pseudowire | |||
SLA Service Level Agreement | SLA Service Level Agreement | |||
SME Section Maintenance Entity Group | SME Section Maintenance Entity | |||
SPME Sub-path Maintenance Element | SMEG Section ME Group | |||
SPME Sub-path Maintenance Element | ||||
S-PE Switching 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 [15]. | |||
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 Entity (SPME) | This document uses the term Sub Path Maintenance Element (SPME) | |||
as defined in RFC 5921 [8]. | as defined in RFC 5921 [8]. | |||
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 [20] 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 | ||||
that is connected to more than one downstream node. | ||||
Bud Node: A node along a point-to-multipoint transport path that | ||||
is at the same time a branch node and a leaf node for this | ||||
transport path. | ||||
Data plane loopback: An out-of-service test where a transport | Data plane loopback: An out-of-service test where a transport | |||
path at either an intermediate or terminating node is placed | path at either an intermediate or terminating node is placed | |||
into a data plane loopback state, such that all traffic | into a data plane loopback state, such that all traffic | |||
(including both payload and OAM) received on the looped back | (including both payload and OAM) received on the looped back | |||
interface is sent on the reverse direction of the transport | interface is sent on the reverse direction of the transport | |||
path. | path. | |||
Note - The only way to send an OAM packet to a node that has been put | Note - The only way to send an OAM packet to a node that has been put | |||
into data plane loopback mode is via TTL expiry, irrespective of | into data plane loopback mode is via TTL expiry, irrespective of | |||
whether the node is hosting MIPs or MEPs. | whether the node is hosting MIPs or MEPs. | |||
skipping to change at page 8, line 17 | skipping to change at page 9, line 44 | |||
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. | |||
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 | ||||
(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. | |||
Loopback: See data plane loopback and OAM loopback definitions. | Loopback: See data plane loopback and OAM loopback definitions. | |||
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 (MEP Source) | MEP: A MEG end point (MEP) is capable of initiating (Source MEP) | |||
and terminating (MEP Sink) OAM messages for fault management and | and terminating (sink MEP) OAM messages 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). | |||
MEP Source: A MEP acts as MEP source for an OAM message when it | ||||
originates and inserts the message into the transport path for | ||||
its associated MEG. | ||||
MEP Sink: A MEP acts as a MEP sink for an OAM message when it | ||||
terminates and processes the messages received from its | ||||
associated MEG. | ||||
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 | messages that are sent to this particular MIP and may generate | |||
OAM messages in reaction to received OAM messages. It never | OAM messages in reaction to received OAM messages. It never | |||
generates unsolicited OAM messages itself. A MIP resides within | generates unsolicited OAM messages itself. A MIP resides within | |||
a MEG between MEPs (details in section 3.3). | a 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 messages originating with a | |||
specific MEP source 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 dataplane loopback). | |||
OAM information element: An atomic piece of information | OAM information element: An atomic piece of information | |||
exchanged between MEPs and/or MIPs in MEG used by an OAM | exchanged between MEPs and/or MIPs in MEG used by an OAM | |||
application. | 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 message 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 | |||
skipping to change at page 9, line 29 | skipping to change at page 11, line 4 | |||
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 message 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 Message: One or more OAM information elements that when | |||
exchanged between MEPs or between MEPs and MIPs performs some | exchanged between MEPs or between MEPs and MIPs performs some | |||
OAM functionality (e.g. connectivity verification) | OAM functionality (e.g. connectivity verification) | |||
OAM Packet: A packet that carries one or more OAM messages (i.e. | OAM Packet: A packet that carries one or more OAM messages (i.e. | |||
OAM information elements). | OAM information elements). | |||
Originating MEP: A MEP that originates an OAM transaction | ||||
message (toward a target MIP/MEP) and expects a reply, either | ||||
in-band or out-of-band, from that target MIP/MEP. The | ||||
originating source MEP function always generates the OAM request | ||||
packets in-band while the originating sink MEP function expects | ||||
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 [13]. | |||
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 [13]. | |||
Sink MEP: A MEP acts as a sink MEP for an OAM message when it | ||||
terminates and processes the messages received from its | ||||
associated MEG. | ||||
Source MEP: A MEP acts as source MEP for an OAM message when it | ||||
originates and inserts the message into the transport path for | ||||
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]. | [19]. | |||
Target MEP/MIP: A MEP or a MIP that is targeted by OAM | ||||
transaction messages and that replies to the originating MEP | ||||
that initiated the OAM transactions. The Target MEP or MIP can | ||||
reply either in-band or out-of-band. The target sink MEP | ||||
function always receives the OAM request packets in-band while | ||||
the target source MEP function only generates the OAM reply | ||||
packets that 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 | |||
path endpoints can be demonstrated to comply with certain | path endpoints can be demonstrated to comply with certain | |||
performance and quality guarantees. | performance and quality guarantees. | |||
In order to describe the required OAM functionality, this | In order to describe the required OAM functionality, this | |||
document introduces a set of functional components. | document introduces a set of functional components. | |||
3.1. Maintenance Entity and Maintenance Entity Group | 3.1. Maintenance Entity and Maintenance Entity Group | |||
MPLS-TP OAM operates in the context of Maintenance Entities | MPLS-TP OAM operates in the context of Maintenance Entities | |||
(MEs) that define a relationship between two points of a | (MEs) that define a relationship between two points of a | |||
transport path to which maintenance and monitoring operations | transport path to which maintenance and monitoring operations | |||
apply. The collection of one or more MEs that belongs to the | apply. The two points that define a maintenance entity are | |||
same transport path and that are maintained and monitored as a | called Maintenance Entity Group (MEG) End Points (MEPs). The | |||
group are known as a maintenance entity group (MEG). The two | collection of one or more MEs that belongs to the same transport | |||
points that define a maintenance entity are called Maintenance | path and that are maintained and monitored as a group are known | |||
Entity Group (MEG) End Points (MEPs). In between these two | as a maintenance entity group (MEG). In between MEPs, there are | |||
points zero or more intermediate points, called Maintenance | zero or more intermediate points, called Maintenance Entity | |||
Entity Group Intermediate Points (MIPs). MEPs and MIPs are | Group Intermediate Points (MIPs). MEPs and MIPs are associated | |||
associated with the MEG and can be shared by more than one ME in | with the MEG and can be shared by more than one ME in a MEG. | |||
a MEG. | ||||
An abstract reference model for an ME is illustrated in Figure 1 | An abstract reference model for an ME is illustrated in Figure 1 | |||
below: | below: | |||
+-+ +-+ +-+ +-+ | +-+ +-+ +-+ +-+ | |||
|A|----|B|----|C|----|D| | |A|----|B|----|C|----|D| | |||
+-+ +-+ +-+ +-+ | +-+ +-+ +-+ +-+ | |||
Figure 1 ME Abstract Reference Model | Figure 1 ME Abstract Reference Model | |||
The instantiation of this abstract model to different MPLS-TP | The instantiation of this abstract model to different MPLS-TP | |||
entities is described in section 4. In Figure 1, nodes A and D | entities is described in section 4. In Figure 1, nodes A and D | |||
can be LERs for an LSP or the T-PEs for a MS-PW, nodes B and C | can be LERs for an LSP or the Terminating Provider Edges (T-PEs) | |||
are LSRs for a LSP or S-PEs for a MS-PW. MEPs reside in nodes A | for a MS-PW, nodes B and C are LSRs for a LSP or Switching PEs | |||
and D while MIPs reside in nodes B and C and may reside in A and | (S-PEs) for a MS-PW. MEPs reside in nodes A and D while MIPs | |||
D. The links connecting adjacent nodes can be physical links, | reside in nodes B and C and may reside in A and D. The links | |||
(sub-)layer LSPs/SPMEs, or server layer paths. | connecting adjacent nodes can be physical links, (sub-)layer | |||
LSPs/SPMEs, or server layer paths. | ||||
This functional model defines the relationships between all OAM | This functional model defines the relationships between all OAM | |||
entities from a maintenance perspective and it allows each | entities from a maintenance perspective and it allows each | |||
Maintenance Entity to monitor and manage the (sub-)layer network | Maintenance Entity to provide monitoring and management for the | |||
under its responsibility and to localize problems efficiently. | (sub-)layer network under its responsibility and efficient | |||
localization of problems. | ||||
An MPLS-TP Maintenance Entity Group may be defined to monitor | An MPLS-TP Maintenance Entity Group may be defined to monitor | |||
the transport path for fault and/or performance management. | the transport path for fault and/or performance management. | |||
The MEPs that form a MEG bound the scope of an OAM flow to the | The MEPs that form a MEG bound the scope of an OAM flow to the | |||
MEG (i.e. within the domain of the transport path that is being | MEG (i.e. within the domain of the transport path that is being | |||
monitored and managed). There are two exceptions to this: | monitored and managed). There are two exceptions to this: | |||
1) A misbranching fault may cause OAM packets to be delivered to | 1) A misbranching fault may cause OAM packets to be delivered to | |||
a MEP that is not in the MEG of origin. | a MEP that is not in the MEG of origin. | |||
skipping to change at page 11, line 35 | skipping to change at page 13, line 35 | |||
and the originating MEP. | and the originating MEP. | |||
In case of unidirectional point-to-point transport paths, a | In case of unidirectional point-to-point transport paths, a | |||
single unidirectional Maintenance Entity is defined to monitor | single unidirectional Maintenance Entity is defined to monitor | |||
it. | it. | |||
In case of associated bi-directional point-to-point transport | In case of associated bi-directional point-to-point transport | |||
paths, two independent unidirectional Maintenance Entities are | paths, two independent unidirectional Maintenance Entities are | |||
defined to independently monitor each direction. This has | defined to independently monitor each direction. This has | |||
implications for transactions that terminate at or query a MIP, | implications for transactions that terminate at or query a MIP, | |||
as a return path from MIP to source MEP does not necessarily | as a return path from MIP to originating MEP does not | |||
exist in the MEG. | necessarily exist in the MEG. | |||
In case of co-routed bi-directional point-to-point transport | In case of co-routed bi-directional point-to-point transport | |||
paths, a single bidirectional Maintenance Entity is defined to | paths, a single bidirectional Maintenance Entity is defined to | |||
monitor both directions congruently. | monitor both directions congruently. | |||
In case of unidirectional point-to-multipoint transport paths, a | In case of unidirectional point-to-multipoint transport paths, a | |||
single unidirectional Maintenance entity for each leaf is | single unidirectional Maintenance entity for each leaf is | |||
defined to monitor the transport path from the root to that | defined to monitor the transport path from the root to that | |||
leaf. | leaf. | |||
skipping to change at page 12, line 22 | skipping to change at page 14, line 22 | |||
+-+ +-+\ +-+ +-+ | +-+ +-+\ +-+ +-+ | |||
\--|F| | \--|F| | |||
+-+ | +-+ | |||
Figure 2 Reference Model for p2mp MEG | Figure 2 Reference Model for p2mp MEG | |||
In case of p2mp transport paths, the OAM measurements are | In case of p2mp transport paths, the OAM measurements are | |||
independent for each ME (A-D, A-E and A-F): | independent for each ME (A-D, A-E and A-F): | |||
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 messages common to all the MEs of the p2mp MEG. All nodes | |||
may implement a MIP in the corresponding MEG. | may implement a MIP in the corresponding MEG. | |||
3.2. Nested MEGs: SPMEs and Tandem Connection Monitoring | 3.2. Nested MEGs: 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 | |||
instantiated to provide monitoring of a portion of a set of co- | hierarchical LSPs instantiated to provide monitoring of a | |||
routed transport paths (LSPs or MS-PWs). The operational aspects | portion of a set of transport paths (LSPs or MS-PWs) that are | |||
of instantiating SPMEs are out of scope of this memo. | co-routed within the OAM domain. 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). | tandem connection monitoring (TCM), as defined by ITU-T | |||
Recommendation G.805 [19]. | ||||
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. The SPME is | path segment of the end-to-end transport path. | |||
monitored using normal LSP monitoring. | ||||
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 TC code point | 1) The SPME would use the uniform model [22] of Traffic Class | |||
copying between sub-layers for diffserv such that the E2E | (TC) code point copying between sub-layers for diffserv such | |||
markings and PHB treatment for the transport path was | that the E2E markings and PHB treatment for the transport | |||
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] such that MIP addressing for the E2E entity | handling [6] (no TTL copying between sub-layer) such that the | |||
would be not be impacted by the presence of the SPME, but it | TTL distance to the MIPs for the E2E entity would be not be | |||
should be possible for an operator to specify use of the | impacted by the presence of the SPME, but it should be | |||
uniform model. | possible for an operator to specify use of the uniform model. | |||
3) PM statistics need to be adjusted for the encapsulation | ||||
overhead of the additional SPME sub-layer. | ||||
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. | |||
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. As any MIP in the SPME sub-layer is not part of the transport path | 1. A MIP in the SPME sub-layer is not part of the transport path MEG, | |||
MEG, hence only an out of band return path for OAM originating in | hence only an out of band return path for OAM originating in the | |||
the transport path MEG that addressed an SPME MIP might be | transport path MEG that addressed an SPME MIP might be available. | |||
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: | following properties apply to all MPLS-TP MEGs (regardless of | |||
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 | |||
segment or a concatenated segment of another MEG, and may | path segment of another MEG, and may also include the | |||
also include the forwarding engine(s) of the node(s) at the | forwarding engine(s) of the node(s) at the edge(s) of the | |||
edge(s) of the segment or concatenated segment. However when | path segment. However when MEGs are nested, the MEPs and MIPs | |||
MEGs are nested, the MEPs and MIPs in the nested MEG are no | in the nested MEG are no longer part of the encompassing MEG. | |||
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 nested MEGs reside on a single | |||
node but again implemented in such a way that they do not | node but again implemented in such a way that they do not | |||
overlap. | overlap. | |||
o Each OAM flow is associated with a single MEG | o Each OAM flow is associated with a single MEG | |||
o OAM packets that instrument a particular direction of a | ||||
transport path are subject to the same forwarding treatment | ||||
(i.e. fate share) as the data traffic and in some cases may | ||||
be required to have common queuing discipline E2E with the | ||||
class of traffic monitored. OAM packets can be distinguished | ||||
from the data traffic using the GAL and ACH constructs [7] | ||||
for LSP and Section or the ACH construct [3]and [7] for | ||||
(MS-)PW. | ||||
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 addressing of the MIPs will change for | instantiated the TTL distance to the MIPs will change for the | |||
the pipe model of TTL copying, and will change for the | pipe model of TTL copying, and will change for the uniform | |||
uniform model if the SPME is not co-routed with the original | model if the SPME is not co-routed with the original path. | |||
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 LSRs for the MPLS-TP LSP can be | while in the context of an SPME, any LSR of the MPLS-TP LSP can | |||
LERs for SPMEs that contribute to the overall monitoring | be an LER of SPMEs that contributes to the overall monitoring | |||
infrastructure for 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 activating and controlling all of the | MEPs are responsible for originating all of the proactive and | |||
proactive and on-demand monitoring OAM functionality for the | on-demand monitoring OAM functionality for the MEG. There is a | |||
MEG. There is a separate class of notifications (such as Lock | separate class of notifications (such as Lock report (LKR) and | |||
report (LKR) and Alarm indication signal (AIS)) that are | Alarm indication signal (AIS)) that are originated by | |||
originated by intermediate nodes and triggered by server layer | intermediate nodes and triggered by server layer events. A MEP | |||
events. A MEP is capable of originating and terminating OAM | is capable of originating and terminating OAM messages for fault | |||
messages for fault management and performance monitoring. These | management and performance monitoring. These OAM messages are | |||
OAM messages are encapsulated into an OAM packet using the G-ACh | encapsulated into an OAM packet using the G-ACh with an | |||
with an appropriate channel type as defined in RFC 5586 [7]. A | appropriate channel type as defined in RFC 5586 [7]. A MEP | |||
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 message from an incorrect MEG will result in a mis- | |||
connectivity defect and there are further actions taken). The | connectivity defect and there are further actions taken). The | |||
MEG the OAM packet belongs to is inferred from the MPLS or PW | MEG the OAM packet belongs to is inferred from the MPLS or PW | |||
label or, in case of an MPLS-TP section, the MEG is inferred | label or, in case of an MPLS-TP section, the MEG is inferred | |||
from the port on which an OAM packet was received with the GAL | from the port on which an OAM packet was received with the GAL | |||
at the top of the label stack. | 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 (e.g. IP address). | |||
Each OAM solution will further detail its applicability as a | Each OAM solution document will further detail the applicability | |||
pro-active or on-demand mechanism as well as its usage when: | of the tools it defines as a pro-active or on-demand mechanism | |||
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. A node at the edge of a MEG always supports a | |||
skipping to change at page 15, line 42 | skipping to change at page 17, line 34 | |||
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 | |||
scope. Note that both MEP source and MEP sink coincide with | scope. Note that both source MEP and sink MEP coincide with | |||
transport paths' source and sink terminations. | transport paths' source and sink terminations. | |||
The MEPs of an SPME are not necessarily coincident with the | The MEPs of an SPME are not necessarily coincident with the | |||
termination of the MPLS-TP transport path. They are used to | termination of the MPLS-TP transport path. They are used to | |||
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 MEP sink 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 | ||||
the client layer (e.g., ignore or generate client layer specific | ||||
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 at the edge of a MEG can either support per-node MEP or | |||
per-interface MEP(s). A per-node MEP resides in an unspecified | per-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 as upstream or downstream relative to the forwarding | location relative to the forwarding engine. An "Up MEP" | |||
engine. | transmits OAM packets towards, and receives them from, the | |||
direction of the forwarding engine, while a "Down MEP" receives | ||||
OAM packets from, and transmits them towards, the direction of a | ||||
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 17, line 7 | skipping to change at page 19, line 11 | |||
Source MEP in a source node (case 1), an Up Sink MEP in a | Source MEP in a source node (case 1), an Up Sink MEP in a | |||
destination node (case 2), a Down Source MEP in a source node | destination node (case 2), a Down Source MEP in a source node | |||
(case 3) and a Down Sink MEP in a destination node (case 4). | (case 3) and a Down Sink MEP in a destination node (case 4). | |||
The usage of per-interface Up MEPs extends the coverage of the | The usage of per-interface Up MEPs extends the coverage of the | |||
ME for both fault and performance monitoring closer to the edge | ME for both fault and performance monitoring closer to the edge | |||
of the domain and allows the isolation of failures or | of the domain and allows the isolation of failures or | |||
performance degradation to being within a node or either the | performance degradation to being within a node or either the | |||
link or interfaces. | link or interfaces. | |||
Each OAM solution will further detail the implications when used | Each OAM solution document will further detail the implications | |||
with per-interface or per-node MEPs, if necessary. | of the tools it defines when used with per-interface or per-node | |||
MEPs, if necessary. | ||||
It may occur that the Up MEPs of an SPME are set on both sides | It may occur that multiple MEPs for the same MEG are on the same | |||
of the forwarding engine such that the MEG is entirely internal | node, and are all Up MEPs, each on one side of the forwarding | |||
to the node. | engine, such that the MEG is entirely internal to the node. | |||
It should be noted that a ME may span nodes that implement per | It should be noted that a ME may span nodes that implement per | |||
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 | |||
skipping to change at page 17, line 42 | skipping to change at page 19, line 47 | |||
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 data plane | |||
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 messages | |||
generated by the MIP are sent in the direction of the source MEP and | generated by the MIP are sent to the originating MEP. | |||
not forwarded to the sink 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). | |||
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 18, line 34 | skipping to change at page 20, line 37 | |||
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 is associated with | |||
is inferred from the MPLS label. | is inferred from the MPLS label. | |||
The use of TTL expiry to deliver OAM packets to a specific MIP | ||||
is not a fully reliable delivery mechanism because the TTL | ||||
distance of a MIP from a MEP can change. Any MPLS-TP node | ||||
silently discards any OAM packet received with an expired TTL | ||||
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 | ||||
silently discard any received OAM packet. | ||||
Messages directed to a MIP may not necessarily carry specific | ||||
MIP identification information beyond that of TTL distance. In | ||||
this case a MIP would promiscuously respond to all MEP queries | ||||
with the correct MEG. This capability could be used for | ||||
discovery functions (e.g., route tracing as defined in section | ||||
6.4) or when it is desirable to leave to the originating MEP the | ||||
job of correlating TTL and MIP identifiers and noting changes or | ||||
irregularities (via comparison with information previously | ||||
extracted from the network). | ||||
MIPs are associated to the MEG they belong to and their identity | ||||
is unique within the MEG. However, their identity is not | ||||
necessarily unique to the MEG: e.g. all nodal MIPs in a node can | ||||
have a common identity. | ||||
A node at the edge of a MEG can also support per-interface Up | A node at the edge of a MEG can also support per-interface Up | |||
MEPs and per-interface MIPs on either side of the forwarding | MEPs and 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. | the control plane. A disabled MIP silently discards any received | |||
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 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 | |||
skipping to change at page 20, line 45 | skipping to change at page 23, line 25 | |||
distance. The OAM message must contain sufficient | distance. The OAM message 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. | |||
P2MP paths are unidirectional; therefore any return path to a | A bud node with a Down MEP or a per-node MEP will both terminate | |||
source MEP for on-demand transactions will be out-of-band. A | and relay OAM packets. Similar to how fault coverage is | |||
mechanism to scope the set of MEPs or MIPs expected to respond | maximized by the explicit utilization of Up MEPs, the same is | |||
to a given "on-demand" transaction is useful as it relieves the | true for MEPs on a bud node. | |||
source MEP of the requirement to filter and discard undesired | ||||
responses as normally TTL exhaustion will address all MIPs at a | P2MP paths are unidirectional; therefore any return path to an | |||
given distance from the source, and failure to exhaust TTL will | originating MEP for on-demand transactions will be out-of-band. | |||
address all MEPs. | A mechanism to target "on-demand" transactions to a single MEP | |||
or MIP is required as it relieves the originating MEP of an | ||||
arbitrarily large processing load and of the requirement to | ||||
filter and discard undesired responses as normally TTL | ||||
exhaustion will address all MIPs at a given distance from the | ||||
source, and failure to exhaust TTL will address all MEPs. | ||||
3.8. Further considerations of enhanced segment monitoring | 3.8. Further considerations of enhanced segment monitoring | |||
Segment monitoring in transport network should meet the | Segment monitoring, like any in-service monitoring, in a | |||
following network objectives: | transport network should meet the following network objectives: | |||
1. The monitoring and maintenance of existing transport paths has to | 1. The monitoring and maintenance of existing transport paths has to | |||
be conducted in service without traffic disruption. | be conducted in service without traffic disruption. | |||
2. The monitored or managed transport path condition has to be | 2. Segment monitoring must not modify the forwarding of the segment | |||
exactly the same irrespective of any configurations necessary for | portion of the transport path. | |||
maintenance. | ||||
SPMEs defined in section 3.2 meet the above two objectives, when | SPMEs defined in section 3.2 meet the above two objectives, when | |||
they are pre-configured or pre-instantiated as exemplified in | they are pre-configured or pre-instantiated as exemplified in | |||
section 3.6. However, pre-design and pre-configuration of all | section 3.6. However, pre-design and pre-configuration of all | |||
the considered patterns of SPME are not sometimes preferable in | the considered patterns of SPME are not sometimes preferable in | |||
real operation due to the burden of design works, a number of | real operation due to the burden of design works, a number of | |||
header consumptions, bandwidth consumption and so on. | header consumptions, bandwidth consumption and so on. | |||
When SPMEs are configured or instantiated after the transport | When SPMEs are configured or instantiated after the transport | |||
path has been created, network objective (1) can be met, but | path has been created, network objective (1) can be met: | |||
network objective (2) cannot be met due to new assignment of | application and removal of SPME to a faultless monitored | |||
MPLS labels. | transport entity can be performed in such a way as not to | |||
introduce any loss of traffic, e.g., by using non-disruptive | ||||
"make before break" technique. | ||||
However, network objective (2) cannot be met due to new | ||||
assignment of MPLS labels. As a consequence, generally speaking, | ||||
the results of SPME monitoring are not necessarily correlated | ||||
with the behaviour of traffic in the monitored entity when it | ||||
does not use SPME. For example, application of SPME to a | ||||
problematic/faulty monitoring entity might "fix" the problem | ||||
encountered by the latter - for as long as SPME is applied. And | ||||
vice versa, application of SPME to a faultless monitored entity | ||||
may result in making it faulty - again, as long as SPME is | ||||
applied. | ||||
Support for a more sophisticated segment monitoring mechanism | Support for a more sophisticated segment monitoring mechanism | |||
(temporal and hitless segment monitoring) to efficiently meet | (temporal and hitless segment monitoring) to efficiently meet | |||
the two network objectives may be necessary. | the two network objectives may be necessary. | |||
One possible option to instantiate non-intrusive segment | ||||
monitoring without the use of SPMEs would require the MIPs | ||||
selected as monitoring endpoints to implement enhanced | ||||
functionality and state for the monitored transport path. | ||||
For example the MIPs need to be configured with the TTL distance | ||||
to the peer or with the address of the peer, when out-of-band | ||||
return paths are used. | ||||
A further issue that would need to be considered is events that | ||||
result in changing the TTL distance to the peer monitoring | ||||
entity such as protection events that may temporarily invalidate | ||||
OAM information gleaned from the use of this technique. | ||||
Further considerations on this technique are outside the scope | ||||
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 framework builds upon the | |||
concept of a MEG, and its associated MEPs and MIPs, to support | concept of a MEG, and its associated MEPs and MIPs, to support | |||
the functional requirements specified in RFC 5860 [11]. | 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 (SME), allowing monitoring | o A Section Maintenance Entity Group (SMEG), allowing | |||
and management of MPLS-TP Sections (between MPLS LSRs). | monitoring and management of MPLS-TP Sections (between MPLS | |||
LSRs). | ||||
o An LSP Maintenance Entity Group (LME), 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 (PME), 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 framework are compliant with | The MEGs specified in this MPLS-TP OAM framework are compliant | |||
the architecture framework for MPLS-TP MS-PWs [4] and LSPs [1]. | with the architecture framework for MPLS-TP [8] that includes | |||
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 LSP V V LSP V V LSP V V (AC2) | (AC1) V V V V V V V V (AC2) | |||
+----+ +-+ +----+ +----+ +-+ +----+ | +----+ +---+ +----+ +----+ +---+ +----+ | |||
+----+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +----+ | +----+ |T-PE| |LSR| |S-PE| |S-PE| |LSR| |T-PE| +----+ | |||
| | | |=======| |=========| |=======| | | | | | | | |=======| |=========| |=======| | | | | |||
| CE1|--|.......PW13......|...PW3X..|......PWXZ.......|---|CE2 | | | CE1|--|.......PW13......|...PW3X..|......PWXZ.......|---|CE2 | | |||
| | | |=======| |=========| |=======| | | | | | | | |=======| |=========| |=======| | | | | |||
+----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ | +----+ | 1 | | 2 | | 3 | | X | | Y | | Z | +----+ | |||
+----+ +-+ +----+ +----+ +-+ +----+ | +----+ +---+ +----+ +----+ +---+ +----+ | |||
. . . . | . . . . | |||
| | | | | | | | | | |||
|<--- Domain 1 -->| |<--- Domain Z -->| | |<--- Domain 1 -->| |<--- Domain Z -->| | |||
^----------------- PW1Z PME -----------------^ | ^----------------- PW1Z PME -----------------^ | |||
^--- PW13 PSME ---^ ^--- PWXZ PSME ---^ | ^--- PW13 PSMEG---^ ^--- PWXZ PSMEG---^ | |||
^-------^ ^-------^ | ^-------^ ^-------^ | |||
LSP13 LME LSPXZ LME | LSP13 LMEG LSPXZ LMEG | |||
^--^ ^--^ ^---------^ ^--^ ^--^ | ^--^ ^--^ ^---------^ ^--^ ^--^ | |||
Sec12 Sec23 Sec3X SecXY SecYZ | Sec12 Sec23 Sec3X SecXY SecYZ | |||
SME SME SME SME SME | SMEG SMEG SMEG SMEG SMEG | |||
TPE1: Terminating Provider Edge 1 SPE2: Switching Provider Edge | ^---^ ME | |||
3 | ^ MEP | |||
TPEX: Terminating Provider Edge X SPEZ: Switching Provider Edge | ==== LSP | |||
Z | .... PW | |||
^---^ ME ^ MEP ==== LSP .... PW | T-PE1: Terminating Provider Edge 1 | |||
LSR: Label Switching Router 2 | ||||
S-PE3: Switching Provider Edge 3 | ||||
T-PEX: Terminating Provider Edge X | ||||
LSRY: Label Switching Router Y | ||||
S-PEZ: Switching Provider Edge Z | ||||
Figure 5 Reference Model for the MPLS-TP OAM Framework | Figure 5 Reference Model for the MPLS-TP OAM Framework | |||
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 | |||
TPE1 and AC2 on TPEZ. The MS-PW consists of three bi-directional | T-PE1 and AC2 on T-PEZ. The MS-PW consists of three | |||
PW path segments: 1) PW13 path segment between T-PE1 and S-PE3 | bi-directional PW path segments: 1) PW13 path segment between T- | |||
via the bi-directional LSP13 LSP, 2) PW3X path segment between | PE1 and S-PE3 via the bi-directional LSP13 LSP, 2) PW3X path | |||
S-PE3 and S-PEX, via the bi-directional LSP3X LSP, and 3) PWXZ | segment between S-PE3 and S-PEX, via the bi-directional LSP3X | |||
path segment between S-PEX and T-PEZ via the bi-directional | LSP, and 3) PWXZ path segment between S-PEX and T-PEZ via the | |||
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. | |||
Note that there are no constrains imposed by this OAM framework | Note that there are no constrains imposed by this OAM framework | |||
on the number, or type (p2p, p2mp, LSP or PW), of MEGs that may | on the number, or type (p2p, p2mp, LSP or PW), of MEGs that may | |||
be instantiated on a particular node. In particular, when | be instantiated on a particular node. In particular, when | |||
looking at Figure 5, it should be possible to configure one or | looking at Figure 5, it should be possible to configure one or | |||
more MEPs on the same node if that node is the endpoint of one | more MEPs on the same node if that node is the endpoint of one | |||
or more MEGs. | or more MEGs. | |||
Figure 5 does not describe a PW3X PSME because typically SPMEs | Figure 5 does not describe a PW3X PSMEG because typically SPMEs | |||
are used to monitor an OAM domain (like PW13 and PWXZ PSMEs) | are used to monitor an OAM domain (like PW13 and PWXZ PSMEGs) | |||
rather than the segment between two OAM domains. However the OAM | rather than the segment between two OAM domains. However the OAM | |||
framework does not pose any constraints on the way SPMEs are | framework does not pose any constraints on the way SPMEs are | |||
instantiated as long as they are not overlapping. | instantiated as long as they are not overlapping. | |||
The subsections below define the MEGs specified in this MPLS-TP | The subsections below define the MEGs specified in this MPLS-TP | |||
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 (SME) | 4.1. MPLS-TP Section Monitoring (SMEG) | |||
An MPLS-TP Section ME (SME) 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 SME may be configured on any MPLS-TP section. SME 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 SME 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 MEs configured in the network | Figure 5 shows five Section MEGs configured in the network | |||
between AC1 and AC2: | between AC1 and AC2: | |||
1. Sec12 ME associated with the MPLS-TP Section between LSR 1 | 1. Sec12 MEG associated with the MPLS-TP Section between LSR 1 | |||
and LSR 2, | and LSR 2, | |||
2. Sec23 ME associated with the MPLS-TP Section between LSR 2 | 2. Sec23 MEG associated with the MPLS-TP Section between LSR 2 | |||
and LSR 3, | and LSR 3, | |||
3. Sec3X ME associated with the MPLS-TP Section between LSR 3 | 3. Sec3X MEG associated with the MPLS-TP Section between LSR 3 | |||
and LSR X, | and LSR X, | |||
4. SecXY ME 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 ME 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 (LME) | 4.2. MPLS-TP LSP End-to-End Monitoring Group (LMEG) | |||
An MPLS-TP LSP ME (LME) is an MPLS-TP maintenance entity | An MPLS-TP LSP MEG (LMEG) is an MPLS-TP maintenance entity group | |||
intended to monitor an end-to-end LSP between two LERs. An LME | intended to monitor an end-to-end LSP between its LERs. An LMEG | |||
may be configured on any MPLS LSP. LME OAM packets must fate | may be configured on any MPLS LSP. LMEG OAM packets must fate | |||
share with user data packets sent over the monitored MPLS-TP | share with user data packets sent over the monitored MPLS-TP | |||
LSP. | LSP. | |||
An LME 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 LMEs configured in the network between AC1 | Figure 5 depicts two LMEGs configured in the network between AC1 | |||
and AC2: 1) the LSP13 LME 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 LME 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 LME 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 (PME) | 4.3. MPLS-TP PW Monitoring (PMEG) | |||
An MPLS-TP PW ME (PME) is an MPLS-TP maintenance entity intended | An MPLS-TP PW MEG (PMEG) is an MPLS-TP maintenance entity | |||
to monitor a SS-PW or MS-PW between a pair of T-PEs. A PME can | intended to monitor a SS-PW or MS-PW between its T-PEs. A PMEG | |||
be configured on any SS-PW or MS-PW. PME OAM packets must fate | can be configured on any SS-PW or MS-PW. PMEG OAM packets must | |||
share with the user data packets sent over the monitored PW. | fate share with the user data packets sent over the monitored | |||
PW. | ||||
A PME 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. | |||
|<----------------- MS-PW1Z ----------------->| | Figure 5 depicts a MS-PW (MS-PW1Z) consisting of three path | |||
| | | segments: PW13, PW3X and PWXZ and its associated end-to-end PMEG | |||
| |<LSP13>| |<-LSP3X->| |<LSPXZ>| | | (PW1Z PMEG). | |||
V V LSP V V LSP V V LSP V V | ||||
+----+ +-+ +----+ +----+ +-+ +----+ | ||||
+---+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +---+ | ||||
| |AC1| |=======| |=========| |=======| |AC2| | | ||||
|CE1|---|.......PW13......|...PW3X..|.......PWXZ......|---|CE2| | ||||
| | | |=======| |=========| |=======| | | | | ||||
+---+ | 1 | |2| | 3 | | X | |Y| | Z | +---+ | ||||
+----+ +-+ +----+ +----+ +-+ +----+ | ||||
^-------------------PW1Z PME------------------^ | ||||
Figure 6 MPLS-TP PW ME (PME) | ||||
Figure 6 depicts a MS-PW (MS-PW1Z) consisting of three path | ||||
segments: PW13, PW3X and PWXZ and its associated end-to-end PME | ||||
(PW1Z PME). | ||||
4.4. MPLS-TP LSP SPME Monitoring (LSME) | 4.4. MPLS-TP LSP SPME Monitoring (LSMEG) | |||
An MPLS-TP LSP SPME ME (LSME) is an MPLS-TP SPME with associated | An MPLS-TP LSP SPME MEG (LSMEG) is an MPLS-TP SPME with an | |||
maintenance entity intended to monitor an arbitrary part of an | associated maintenance entity group intended to monitor an | |||
LSP between the pair of MEPs instantiated for the SPME | arbitrary part of an LSP between the MEPs instantiated for the | |||
independent from the end-to-end monitoring (LME). An LSME can | SPME independent from the end-to-end monitoring (LMEG). An LSMEG | |||
monitor an LSP segment or concatenated segment and it may also | can monitor an LSP path segment and it may also include the | |||
include the forwarding engine(s) of the node(s) at the edge(s) | forwarding engine(s) of the node(s) at the edge(s) of the path | |||
of the segment or concatenated 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 LSMEs can be configured on any LSP. LSME | 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 end node and any intermediate node of a given LSP. | o The LER and LSR of a given LSP. | |||
o Any two intermediate nodes of a given LSP. | o Any two LSRs of a given LSP. | |||
An LSME 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 | |||
LSPs rather than the entire LSP itself, for example when there | LSPs rather than the entire LSP itself, for example when there | |||
is a need to monitor a part of an LSP that extends beyond the | is a need to monitor a part of an LSP that extends beyond the | |||
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 S-LSP V V S-LSP V V S-LSP V V | V V V V V V V V | |||
+----+ +-+ +----+ +----+ +-+ +----+ | +----+ +---+ +----+ +----+ +---+ +----+ | |||
+----+ | PE1| | | |DBN3| |DBNX| | | | PEZ| +----+ | +----+ | PE | |LSR| |DBN | |DBN | |LSR| | PE | +----+ | |||
| |AC1| |=====================================| |AC2| | | | |AC1| |=====================================| |AC2| | | |||
----+ | <span class="insert">PE</span> | <span class="insert">|LSR| |DBN</span> | <span class="insert">|DBN</span> | <span class="insert">|LSR|</span> | <span class="insert">PE</span> | +----+ | ||||
| CE1|---|.....................PW1Z......................|---|CE2 | | | CE1|---|.....................PW1Z......................|---|CE2 | | |||
| | | |=====================================| | | | | | | | |=====================================| | | | | |||
+----+ | 1 | |2| | 3 | | X | |Y| | Z | +----+ | +----+ | 1 | | 2 | | 3 | | X | | Y | | Z | +----+ | |||
+----+ +-+ +----+ +----+ +-+ +----+ | +----+ +---+ +----+ +----+ +---+ +----+ | |||
. . . . | . . . . | |||
| | | | | | | | | | |||
|<---- Domain 1 --->| |<---- Domain Z --->| | |<---- Domain 1 --->| |<---- Domain Z --->| | |||
^---------^ ^---------^ | ^---------^ ^---------^ | |||
LSP13 LSME LSPXZ LSME | LSP13 LSMEG LSPXZ LSMEG | |||
^-------------------------------------^ | ^-------------------------------------^ | |||
LSP1Z LME | LSP1Z LMEG | |||
DBN: Domain Border Node | DBN: Domain Border Node | |||
Figure 7 MPLS-TP LSP SPME ME (LSME) | Figure 6 MPLS-TP LSP SPME MEG (LSMEG) | |||
Figure 7 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: | |||
LSP13, LSP3X and LSPXZ. In this scenario there are two separate | LSP13, LSP3X and LSPXZ. In this scenario there are two separate | |||
LSMEs configured to monitor the LSP1Z: 1) a LSME monitoring the | LSMEGs configured to monitor the LSP1Z: 1) a LSMEG monitoring | |||
LSP13 Concatenated Segment on Domain 1 (LSP13 LSME), and 2) a | the LSP13 Concatenated Segment on Domain 1 (LSP13 LSMEG), and 2) | |||
LSME monitoring the LSPXZ Concatenated Segment on Domain Z | a LSMEG monitoring the LSPXZ Concatenated Segment on Domain Z | |||
(LSPXZ LSME). | (LSPXZ LSMEG). | |||
It is worth noticing that LSMEs can coexist with the LME | It is worth noticing that LSMEGs can coexist with the LMEG | |||
monitoring the end-to-end LSP and that LSME MEPs and LME MEPs | monitoring the end-to-end LSP and that LSMEG MEPs and LMEG MEPs | |||
can be coincident in the same node (e.g. PE1 node supports both | can be coincident in the same node (e.g. PE1 node supports both | |||
the LSP1Z LME MEP and the LSP13 LSME MEP). | the LSP1Z LMEG MEP and the LSP13 LSMEG MEP). | |||
4.5. MPLS-TP MS-PW SPME Monitoring (PSME) | 4.5. MPLS-TP MS-PW SPME Monitoring (PSMEG) | |||
An MPLS-TP MS-PW SPME Monitoring ME (PSME) is an MPLS-TP SPME | An MPLS-TP MS-PW SPME Monitoring MEG (PSMEG) is an MPLS-TP SPME | |||
with associated maintenance entity intended to monitor an | with an associated maintenance entity group intended to monitor | |||
arbitrary part of an MS-PW between the pair of MEPs instantiated | an arbitrary part of an MS-PW between the MEPs instantiated for | |||
form the SPME independently from the end-to-end monitoring | the SPME independently of the end-to-end monitoring (PMEG). A | |||
(PME). A PSME can monitor a PW segment or concatenated segment | PSMEG can monitor a PW path segment and it may also include the | |||
and it may also include the forwarding engine(s) of the node(s) | forwarding engine(s) of the node(s) at the edge(s) of the path | |||
at the edge(s) of the segment or concatenated segment. A PSME is | segment. A PSMEG is no different than an SPME, it is simply | |||
no different than an SPME, it is simply named as such to discuss | named as such to discuss SPMEs specifically in a PW context. | |||
SPMEs specifically in a PW context. | ||||
When SPME is established between non-adjacent S-PEs, the edges | When SPME is established between non-adjacent S-PEs, the edges | |||
of the SPME becomes adjacent at the MS-PW sub-layer network and | of the SPME becomes adjacent at the MS-PW sub-layer network and | |||
any S-PEs that were previously in between becomes an LSR for the | any S-PEs that were previously in between becomes an LSR for the | |||
SPME. | SPME. | |||
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 (CP) to centralized | such as the transition from distributed control plane (CP) to | |||
(NMS) control or at a routing area boundary. As such the | centralized Network Management System (NMS) control or at a | |||
architecture would appear not to have the flexibility that | routing area boundary. As such the architecture would appear not | |||
arbitrary placement of SPME segments would imply. Support for an | to have the flexibility that arbitrary placement of SPME | |||
arbitrary placement of PSME would require the definition of | segments would imply. Support for an arbitrary placement of | |||
additional PW sub-layering. | PSMEG would require the definition of additional PW | |||
Multiple hierarchical PSMEs can be configured on any MS-PW. PSME | sub-layering. | |||
OAM packets fate share with the user data packets sent over the | Multiple hierarchical PSMEGs can be configured on any MS-PW. | |||
monitored PW path Segment. | PSMEG OAM packets fate share with the user data packets sent | |||
over the monitored PW path Segment. | ||||
A PSME does not add hierarchical components to the MPLS architecture, | A PSMEG does not add hierarchical components to the MPLS | |||
it defines the role of existing components for the purposes of | architecture, it defines the role of existing components for the | |||
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 addressing of the MIPs may change and MIPs in the nested MEG are | TTL distance of the MIPs may change and MIPs in the nested MEG are no | |||
no longer part of the encompassing MEG. This means that the S-PE | longer part of the encompassing MEG. This means that the S-PE nodes | |||
nodes hosting these MIPs are no longer S-PEs but P nodes at the SPME | hosting these MIPs are no longer S-PEs but P nodes at the SPME LSP | |||
LSP level. The consequences are that the S-PEs hosting the PSME 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 PSME 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- | |||
domain MS-PW. | domain MS-PW. | |||
|<----------------- MS-PW1Z ------------------>| | Figure 5 depicts a MS-PW (MS-PW1Z) consisting of three path | |||
| | | segments: PW13, PW3X and PWXZ with two separate PSMEGs: 1) a | |||
| |<LSP13>| |<-LSP3X-->| |<LSPXZ>| | | PSMEG monitoring the PW13 MS-PW path segment on Domain 1 (PW13 | |||
V V LSP V V LSP V V LSP V V | PSMEG), and 2) a PSMEG monitoring the PWXZ MS-PW path segment on | |||
+----+ +-+ +----+ +----+ +-+ +----+ | Domain Z with (PWXZ PSMEG). | |||
+---+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +---+ | ||||
| |AC1| |=======| |==========| |=======| |AC2| | | ||||
|CE1|---|.......PW13......|...PW3X...|.......PWXZ......|---|CE2| | ||||
| | | |=======| |==========| |=======| | | | | ||||
+---+ | 1 | |2| | 3 | | X | |Y| | Z | +---+ | ||||
+----+ +-+ +----+ +----+ +-+ +----+ | ||||
^--- PW13 PSME ---^ ^--- PWXZ PSME ----^ | ||||
^-------------------PW1Z PME-------------------^ | ||||
Figure 8 MPLS-TP MS-PW SPME Monitoring (PSME) | ||||
Figure 8 depicts the same MS-PW (MS-PW1Z) between AC1 and AC2 as | ||||
in Figure 6. In this scenario there are two separate PSMEs | ||||
configured to monitor MS-PW1Z: 1) a PSME monitoring the PW13 | ||||
MS-PW path segment on Domain 1 (PW13 PSME), and 2) a PSME | ||||
monitoring the PWXZ MS-PW path segment on Domain Z with (PWXZ | ||||
PSME). | ||||
It is worth noticing that PSMEs can coexist with the PME | It is worth noticing that PSMEGs can coexist with the PMEG | |||
monitoring the end-to-end MS-PW and that PSME MEPs and PME MEPs | monitoring the end-to-end MS-PW and that PSMEG MEPs and PMEG | |||
can be coincident in the same node (e.g. TPE1 node supports both | MEPs can be coincident in the same node (e.g. T-PE1 node | |||
the PW1Z PME MEP and the PW13 PSME 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 Aggregations [21], the use of Link | |||
Bundling for MPLS [17] where the option to spread traffic over | Bundling for MPLS [17] 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 | |||
skipping to change at page 30, line 7 | skipping to change at page 33, line 23 | |||
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 messages 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 loss | system) as notifications events such as faults or indications | |||
measurement indication of excessive impairment of information | of performance degradations (such as excessive packet loss). | |||
transfer capability. | ||||
5. The measurements resulting from proactive monitoring may be | 5. The measurements resulting from proactive monitoring may be | |||
periodically harvested by an EMS/NMS. | periodically harvested by an NMS. | |||
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.1.4. | |||
5.1. Continuity Check and Connectivity Verification | 5.1. Continuity Check and Connectivity Verification | |||
skipping to change at page 30, line 35 | skipping to change at page 33, line 50 | |||
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 of OAM | |||
packets by the source MEP that are processed by the sink MEP. As | packets by the source MEP that are processed by the peer sink | |||
a consequence these two functions are grouped together into | MEP(s). As a consequence these two functions are grouped | |||
Continuity Check and Connectivity Verification (CC-V) OAM | together into Continuity Check and Connectivity Verification | |||
packets. | (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. When used to perform only pro-active Continuity | |||
Check, the CC-V OAM packet will not include any globally unique | Check, the CC-V OAM packet will not include any globally unique | |||
Source MEP identifier. Different formats of MEP identifiers are | Source MEP identifier. Different formats of MEP identifiers are | |||
defined in [10] to address different environments. When MPLS-TP | defined in [10] to address different environments. When MPLS-TP | |||
is deployed in transport network environments where IP | is deployed in transport network environments where IP | |||
addressing is not used in the forwarding plane, the ICC-based | addressing is not used in the forwarding plane, the ITU Carrier | |||
format for MEP identification is used. When MPLS-TP is deployed | Code (ICC)-based format for MEP identification is used. When | |||
in an IP-based environment, the IP-based MEP identification is | MPLS-TP is deployed in an IP-based environment, the IP-based MEP | |||
used. | identification is used. | |||
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 message type nor OAM message 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 leaking into a CC monitored MEG - undetectable | |||
o For CV leaking into a CC monitored MEG - presence of | o For CV leaking into a CC monitored MEG - presence of | |||
additional Source MEP identifier allows detecting the fault | additional Source MEP identifier allows detecting the fault | |||
o For CC leaking into a CV monitored MEG - lack of additional | o For CC leaking into a CV monitored MEG - lack of additional | |||
Source MEP identifier allows detecting the fault. | Source MEP identifier allows detecting the fault. | |||
o For CV leaking into a CV monitored MEG - different Source MEP | o For CV leaking into a CV monitored MEG - different Source MEP | |||
identifier permits fault to be identified. | identifier permits fault to be identified. | |||
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. This PHB is configurable on network operator's | are monitoring. For E-LSPs, this PHB is configurable on network | |||
basis. PHBs can be translated at the network borders by the same | operator's basis while for L-LSPs this is determined as per RFC | |||
function that translates it for user data traffic. The | 3270 [22]. PHBs can be translated at the network borders by 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 with the entire E-LSP fate sharing with any 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), only the | path (either point-to-point or point-to-multipoint), the source | |||
source MEP is enabled to generate CC-V OAM packets and only the | MEP is enabled only to generate CC-V OAM packets while each sink | |||
sink MEP is configured to expect these packets at the configured | MEP is configured to expect these packets at the configured | |||
rate. | rate. | |||
MIPs, as well as intermediate nodes not supporting MPLS-TP OAM, | MIPs, as well as intermediate nodes not supporting MPLS-TP OAM, | |||
are transparent to the pro-active CC-V information and forward | are transparent to the pro-active CC-V information and forward | |||
these pro-active CC-V OAM packets as regular data packets. | these pro-active CC-V OAM packets as regular data packets. | |||
During path setup and tear down, situations arise where CC-V | During path setup and tear down, situations arise where CC-V | |||
checks would give rise to alarms, as the path is not fully | checks would give rise to alarms, as the path is not fully | |||
instantiated. In order to avoid these spurious alarms the | instantiated. In order to avoid these spurious alarms the | |||
following procedures are recommended. At initialization, the MEP | following procedures are recommended. At initialization, the | |||
source function (generating pro-active CC-V packets) should be | source MEP function (generating pro-active CC-V packets) should | |||
enabled prior to the corresponding MEP sink function (detecting | be enabled prior to the corresponding sink MEP function | |||
continuity and connectivity defects). When disabling the CC-V | (detecting continuity and connectivity defects). When disabling | |||
proactive functionality, the MEP sink function should be | the CC-V proactive functionality, the sink MEP function should | |||
disabled prior to the corresponding MEP source function. | be disabled prior to the corresponding source MEP function. | |||
It should be noted that different encapsulations are possible | It should be noted that different encapsulations are possible | |||
for CC-V packets and therefore it is possible that in case of | for CC-V packets and therefore it is possible that in case of | |||
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 | |||
skipping to change at page 32, line 47 | skipping to change at page 36, line 19 | |||
the described defect cases, the sink MEP should notify the | the described defect cases, the sink MEP should notify the | |||
equipment fault management process of the detected defect. | equipment fault management process of the detected defect. | |||
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 receives a CC or CC/CV OAM packet with an | identifier or with an unexpected encapsulation. | |||
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 message to self identify the CC-V | |||
periodicity as not all MEPs can be expected to have knowledge | periodicity as not all MEPs can be expected to have knowledge | |||
of all MEGs. | of all 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 CV 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 | Period field value 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 CV 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 an unexpected globally unique Source MEP | If a MEP detects a mis-connectivity defect, it blocks all the | |||
Identifier, it blocks all the traffic (including also the user | traffic (including also the user data packets) that it receives | |||
data packets) that it receives from the misconnected transport | from the misconnected transport path. | |||
path. | ||||
If a MEP detects LOC defect that is not caused by a period | If a MEP detects LOC defect that is not caused by a period | |||
mis-configuration, it should block all the traffic (including | mis-configuration, it should block all the traffic (including | |||
also the user data packets) that it receives from the transport | also the user data packets) that it receives from the transport | |||
path, if this consequent action has been enabled by the | path, if this consequent action has been enabled by the | |||
operator. | operator. | |||
It is worth noticing that the OAM requirements document [11] | It is worth noticing that the OAM requirements document [11] | |||
recommends that CC-V proactive monitoring be enabled on every | recommends that CC-V proactive monitoring be enabled on every | |||
MEG in order to reliably detect connectivity defects. However, | MEG in order to reliably detect connectivity defects. However, | |||
skipping to change at page 35, line 15 | skipping to change at page 38, line 31 | |||
a consequent wrong traffic delivering. For these reasons, the | a consequent wrong traffic delivering. For these reasons, the | |||
traffic block consequent action is applied even when a LOC | traffic block consequent action is applied even when a LOC | |||
condition occurs. This block consequent action can be disabled | condition occurs. This block consequent action can be disabled | |||
through configuration. This deactivation of the block action may | through configuration. This deactivation of the block action may | |||
be used for activating or deactivating the monitoring when it is | be used for activating or deactivating the monitoring when it is | |||
not possible to synchronize the function activation of the two | not possible to synchronize the function activation of the two | |||
peer MEPs. | peer MEPs. | |||
If a MEP detects a LOC defect (section 5.1.1.1), a | If a MEP detects a LOC defect (section 5.1.1.1), a | |||
mis-connectivity defect (section 5.1.1.2) it declares a signal | mis-connectivity defect (section 5.1.1.2) it declares a signal | |||
fail condition at the transport path level. | fail condition of the ME. | |||
It is a matter if local policy if a MEP that detects a period | It is a matter if local policy if a MEP that detects a period | |||
misconfiguration defect (section 5.1.1.3) declares a signal fail | misconfiguration defect (section 5.1.1.3) declares a signal fail | |||
condition at the transport path level. | condition of the ME. | |||
The detection of an unexpected encapsulation defect does not | The detection of an unexpected encapsulation defect does not | |||
have any consequent action: it is just a warning for the network | have any consequent action: it is just a warning for the network | |||
operator. An implementation able to detect an unexpected | operator. An implementation able to detect an unexpected | |||
encapsulation but not able to verify the source MEP ID may | encapsulation but not able to verify the source MEP ID may | |||
choose to declare a mis-connectivity defect. | choose to declare a mis-connectivity defect. | |||
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 | |||
skipping to change at page 35, line 36 | skipping to change at page 39, 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; it identifies the per-hop behavior of CC-V packet. | o PHB for E-LSPs; it identifies the per-hop behavior of CC-V | |||
Proactive CC-V packets are transmitted with the "minimum loss | packet. Proactive CC-V packets are transmitted with the | |||
probability PHB" previously configured within a single | "minimum loss probability PHB" previously configured within a | |||
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 Monitoring: default transmission period is | |||
100ms (i.e. transmission rate of 10 packets/second). | 100ms (i.e. transmission rate of 10 packets/second). | |||
Performance monitoring is only relevant when the | Performance monitoring is only relevant when the | |||
transport path is defect free. CC-V contributes to the | transport path is defect free. CC-V contributes to the | |||
accuracy of PM statistics by permitting the defect free | accuracy of PM statistics by permitting the defect free | |||
periods to be properly distinguished. | periods to be properly distinguished. | |||
o Protection Switching: default transmission period is | o Protection Switching: default transmission period is | |||
3.33ms (i.e. transmission rate of 300 packets/second), in | 3.33ms (i.e. transmission rate of 300 packets/second). | |||
order to achieve sub-50ms the CC-V defect entry criteria | CC-V defect entry criteria can resolve in less than 12ms, | |||
should resolve in less than 10msec, and complete a | and a protection switch can complete within a subsequent | |||
protection switch within a subsequent period of 50 msec. | period of 50 ms. | |||
It is also possible to lengthen the transmission period | It is also possible to lengthen the transmission period | |||
to 10ms (i.e. transmission rate of 100 packets/second): | to 10ms (i.e. transmission rate of 100 packets/second): | |||
in this case the CC-V defect entry criteria is reached | in this case the CC-V defect entry criteria is reached | |||
later (i.e. 30msec). | later (i.e. 35ms). | |||
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 his internal | |||
requirements. | 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 statically provisioned transport paths the above parameters | For management provisioned transport paths the above parameters | |||
are statically configured; for dynamically established transport | are statically configured; for dynamically signalled transport | |||
paths the configuration information are signaled via the control | paths the configuration information are distributed via the | |||
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.1.4. | |||
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. RDI is only used for all | a signal fail condition exists. In case of co-routed and | |||
co-routed and associated bidirectional transport paths and is | associated bidirectional transport paths, RDI is associated with | |||
associated with proactive CC-V. The RDI indicator can be piggy- | proactive CC-V and the RDI indicator can be piggy-backed onto | |||
backed onto the CC-V packet. | the CC-V packet. In case of unidirectional transport paths, the | |||
RDI indicator can be sent only using an out-of-band return path | ||||
if it exists and its usage is enabled by policy actions. | ||||
When a MEP detects a signal fail condition (e.g. in case of a | When a MEP detects a signal fail condition (e.g. in case of a | |||
continuity or connectivity defect), it should begin transmitting | continuity or connectivity defect), it should begin transmitting | |||
an RDI indicator to its peer MEP. When incorporated into CC-V, | an RDI indicator to its peer MEP. When incorporated into CC-V, | |||
the RDI information will be included in all pro-active CC-V | the RDI information will be included in all pro-active CC-V | |||
packets that it generates for the duration of the signal fail | packets that it generates for the duration of the signal fail | |||
condition's existence. | condition's existence. | |||
A MEP that receives packets from a peer MEP with the RDI | A MEP that receives packets from a peer MEP with the RDI | |||
information should determine that its peer MEP has encountered a | information should determine that its peer MEP has encountered a | |||
defect condition associated with a signal fail. | defect condition associated with a signal fail condition. | |||
MIPs as well as intermediate nodes not supporting MPLS-TP OAM | MIPs as well as intermediate nodes not supporting MPLS-TP OAM | |||
are transparent to the RDI indicator and forward OAM packets | are transparent to the RDI indicator and forward OAM packets | |||
that include the RDI indicator as regular data packets, i.e. the | that include the RDI indicator as regular data packets, i.e. the | |||
MIP should not perform any actions nor examine the indicator. | MIP should not perform any actions nor examine the indicator. | |||
When the signal fail defect condition clears, the MEP should | When the signal fail condition clears, the MEP should stop | |||
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 a | |||
unique OAM message or an OAM information element embedded in a | unique OAM message or an OAM information element embedded in a | |||
CV message; the RDI transmission rate and PHB of the OAM packets | CV message. The in-band RDI transmission rate and PHB of the OAM | |||
carrying RDI should be the same as that configured for CC-V. | packets carrying RDI should be the same as that configured for | |||
CC-V. Methods of the out-of-band return paths will dictate how | ||||
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 | message to suppress alarms following detection of defect | |||
conditions at the server (sub-)layer. | conditions at the server (sub-)layer. | |||
When a server MEP asserts signal fail, it notifies that to the | When a server MEP asserts a signal fail condition, it notifies | |||
co-located MPLS-TP client/server adaptation function which then | that to the co-located MPLS-TP client/server adaptation function | |||
generates packets with AIS information in the downstream | which then generates OAM packets with AIS information in the | |||
direction to allow the suppression of secondary alarms at the | downstream direction to allow the suppression of secondary | |||
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 signal fail. These | immediately when the server MEP asserts a signal fail condition. | |||
periodic 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. It is | transmitted until the signal fail condition is cleared. | |||
assumed that to avoid spurious alarm generation a MEP detecting | ||||
loss of continuity will wait for a hold off interval prior to | ||||
asserting an alarm to the management system. | ||||
Upon receiving a packet with AIS information an MPLS-TP MEP | It is assumed that to avoid spurious alarm generation a MEP | |||
enters an AIS defect condition and suppresses loss of continuity | detecting a loss of continuity defect (see section 5.1.1.1) will | |||
alarms associated with its peer MEP but does not block traffic | wait for a hold off interval prior to asserting an alarm to the | |||
received from the transport path. A MEP resumes loss of | management system. Therefore, upon receiving an OAM packet with | |||
continuity alarm generation upon detecting loss of continuity | AIS information an MPLS-TP MEP enters an AIS defect condition | |||
defect conditions in the absence of AIS condition. | and suppresses loss of continuity alarms associated with its | |||
peer MEP but does not block traffic received from the transport | ||||
path. A MEP resumes loss of continuity alarm generation upon | ||||
detecting loss of continuity defect conditions 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 SME, LSP13 LME, PW1 PSME | defect is detected by the MEPs of Sec12 SMEG LSP13 LMEG, PW1 | |||
and PW1Z PME, however in a transport network only the alarm | PSMEG and PW1Z PMEG, however in a transport network only the | |||
associated to the fiber cut needs to be reported to an NMS while | alarm associated to the fiber cut needs to be reported to an NMS | |||
all secondary alarms should be suppressed (i.e. not reported to | while all secondary alarms should be suppressed (i.e. not | |||
the NMS or reported as secondary alarms). | reported to the NMS or reported as secondary alarms). | |||
If the fiber cut is detected by the MEP in the physical layer | If the fiber cut is detected by the MEP in the physical layer | |||
(in LSR2), LSR2 can generate the proper alarm in the physical | (in LSR2), LSR2 can generate the proper alarm in the physical | |||
layer and suppress the secondary alarm associated with the LOC | layer and suppress the secondary alarm associated with the LOC | |||
defect detected on Sec12 SME. As both MEPs reside within the | defect detected on Sec12 SMEG. As both MEPs reside within the | |||
same node, this process does not involve any external protocol | same node, this process does not involve any external protocol | |||
exchange. Otherwise, if the physical layer has not enough OAM | exchange. Otherwise, if the physical layer has not enough OAM | |||
capabilities to detect the fiber cut, the MEP of Sec12 SME in | capabilities to detect the fiber cut, the MEP of Sec12 SMEG in | |||
LSR2 will report a LOC alarm. | LSR2 will report a LOC alarm. | |||
In both cases, the MEP of Sec12 SME in LSR 2 notifies the | In both cases, the MEP of Sec12 SMEG in LSR 2 notifies the | |||
adaptation function for LSP13 LME that then generates AIS | adaptation function for LSP13 LMEG that then generates AIS | |||
packets on the LSP13 LME in order to allow its MEP in LSR3 to | packets on the LSP13 LMEG in order to allow its MEP in LSR3 to | |||
suppress the LOC alarm. LSR3 can also suppress the secondary | suppress the LOC alarm. LSR3 can also suppress the secondary | |||
alarm on PW13 PSME because the MEP of PW13 PSME resides within | alarm on PW13 PSMEG because the MEP of PW13 PSMEG resides within | |||
the same node as the MEP of LSP13 LME. The MEP of PW13 PSME in | the same node as the MEP of LSP13 LMEG. The MEP of PW13 PSMEG in | |||
LSR3 also notifies the adaptation function for PW1Z PME that | LSR3 also notifies the adaptation function for PW1Z PMEG that | |||
then generates AIS packets on PW1Z PME in order to allow its MEP | then generates AIS packets on PW1Z PMEG in order to allow its | |||
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 packets are transmitted with the "minimum loss probability | AIS packets are transmitted with the "minimum loss probability | |||
PHB" within a single network operator. This PHB is configurable | PHB" within a single network operator. For E-LSPs, this PHB is | |||
on network operator's basis. | configurable on network operator's basis, while for L-LSPs, this | |||
is determined as per RFC 3270 [22]. | ||||
AIS condition is cleared if no AIS message has been received in | AIS condition is cleared if no AIS message has been received in | |||
3.5 times the AIS transmission period. | 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) message 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 in | adaptation function generates packets with LKR information to | |||
both directions to allow the suppression of secondary alarms at | allow the suppression of secondary alarms at the MEPs in the | |||
the MEPs in the client (sub-)layer. Again it is assumed that | client (sub-)layer. Again it is assumed that there is a hold off | |||
there is a hold off for any loss of continuity alarms in the | for any loss of continuity alarms in the client layer MEPs | |||
client layer MEPs downstream of the node originating the locked | downstream of the node originating the locked report. In case of | |||
report. | client (sub-)layer co-routed bidirectional transport paths, the | |||
LKR information is sent on both directions. In case of client | ||||
(sub-)layer unidirectional transport paths, the LKR information | ||||
is sent only in the downstream direction. As a consequence, in | ||||
case of client (sub-)layer point-to-multipoint transport paths, | ||||
the LKR information is sent only to the MEPs that are downstream | ||||
to the server (sub-)layer that has been administratively locked. | ||||
Client (sub-)layer associated bidirectional transport paths | ||||
behave like co-routed bidirectional transport paths if the | ||||
server (sub-)layer that has been administratively locked is used | ||||
by both directions; otherwise they behave like unidirectional | ||||
transport paths. | ||||
The generation of packets with LKR information starts | The generation of packets with LKR information starts | |||
immediately when the server MEP is locked. These periodic | immediately when the server MEP is locked. These periodic | |||
packets, with LKR information, continue to be transmitted until | packets, with LKR information, continue to be transmitted until | |||
the locked condition is cleared. | the locked condition is cleared. | |||
Upon receiving a packet with LKR information an MPLS-TP MEP | Upon receiving a packet with LKR information an MPLS-TP MEP | |||
enters an LKR defect condition and suppresses loss of continuity | enters an LKR defect condition and suppresses loss of continuity | |||
alarm associated with its peer MEP but does not block traffic | alarm associated with its peer MEP but does not block traffic | |||
received from the transport path. A MEP resumes loss of | received from the transport path. A MEP resumes loss of | |||
skipping to change at page 40, line 10 | skipping to change at page 43, line 45 | |||
MIPs, as well as intermediate nodes, do not process the LKR | MIPs, as well as intermediate nodes, do not process the LKR | |||
information and forward these LKR OAM packets as regular data | information and forward these LKR OAM packets as regular data | |||
packets. | packets. | |||
For example, let's consider the case where the MPLS-TP Section | For example, let's consider the case where the MPLS-TP Section | |||
between LSR 1 and LSR 2 in the reference network of Figure 5 is | between LSR 1 and LSR 2 in the reference network of Figure 5 is | |||
administrative locked at LSR2 (in both directions). | administrative locked at LSR2 (in both directions). | |||
Assuming that all the MEGs described in Figure 5 have pro-active | Assuming that all the MEGs described in Figure 5 have pro-active | |||
CC-V enabled, a LOC defect is detected by the MEPs of LSP13 LME, | CC-V enabled, a LOC defect is detected by the MEPs of LSP13 | |||
PW1 PSME and PW1Z PME, however in a transport network all these | LMEG, PW1 PSMEG and PW1Z PMEG, however in a transport network | |||
secondary alarms should be suppressed (i.e. not reported to the | all these secondary alarms should be suppressed (i.e. not | |||
NMS or reported as secondary alarms). | reported to the NMS or reported as secondary alarms). | |||
The MEP of Sec12 SME in LSR 2 notifies the adaptation function | The MEP of Sec12 SMEG in LSR 2 notifies the adaptation function | |||
for LSP13 LME that then generates LKR packets on the LSP13 LME | for LSP13 LMEG that then generates LKR packets on the LSP13 LMEG | |||
in order to allow its MEPs in LSR1 and LSR3 to suppress the LOC | in order to allow its MEPs in LSR1 and LSR3 to suppress the LOC | |||
alarm. LSR3 can also suppress the secondary alarm on PW13 PSME | alarm. LSR3 can also suppress the secondary alarm on PW13 PSMEG | |||
because the MEP of PW13 PSME resides within the same node as the | because the MEP of PW13 PSMEG resides within the same node as | |||
MEP of LSP13 LME. The MEP of PW13 PSME in LSR3 also notifies the | the MEP of LSP13 LMEG. The MEP of PW13 PSMEG in LSR3 also | |||
adaptation function for PW1Z PME that then generates AIS packets | notifies the adaptation function for PW1Z PMEG that then | |||
on PW1Z PME in order to allow its MEP in LSRZ to suppress the | generates AIS packets on PW1Z PMEG in order to allow its MEP in | |||
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). | |||
LKR packets are transmitted with the "minimum loss probability | LKR packets are transmitted with the "minimum loss probability | |||
PHB" within a single network operator. This PHB is configurable | PHB" within a single network operator. For E-LSPs, this PHB is | |||
on network operator's basis. | configurable on network operator's basis, while for L-LSPs, this | |||
is determined as per RFC 3270 [22]. | ||||
Locked condition is cleared if no LKR packet has been received | Locked condition is cleared if no LKR packet has been received | |||
for 3.5 times the transmission period. | 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 | |||
skipping to change at page 41, line 6 | skipping to change at page 44, line 42 | |||
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 | |||
packets. These measurements are then correlated in real time | packets. These measurements are then correlated in real time | |||
with the peer MEP in the ME to derive the impact of packet loss | with the peer MEP in the ME to derive the impact of packet loss | |||
on a number of performance metrics for the ME in the MEG. The LM | on a number of performance metrics for the ME in the MEG. The LM | |||
transactions are issued such that the OAM packets will | transactions are issued such that the OAM packets will | |||
experience the same queuing discipline 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: | ||||
o One-way: a MEP sends LM OAM packet to its peer MEP containing | ||||
all the required information to facilitate near-end packet | ||||
loss measurements at the peer MEP. | ||||
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 | ||||
response. The request/response LM OAM packets containing all | ||||
the required information to facilitate both near-end and | ||||
far-end packet loss measurements from the viewpoint of the | ||||
originating MEP. | ||||
One-way LM is applicable to both unidirectional and | ||||
bidirectional (co-routed or associated) transport paths while | ||||
two-way LM is applicable only to bidirectional (co-routed or | ||||
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 PHB | |||
class associated with the LM OAM packets originating from a MEP | class associated with the LM OAM packets originating from a MEP | |||
need be configured as part of the LM provisioning. LM OAM | need be configured as part of the LM provisioning. LM OAM | |||
packets should be transmitted with the PHB that yields the | packets should be transmitted with the PHB that yields the | |||
lowest discard probability within the measured PHB Scheduling | lowest drop precedence within the measured PHB Scheduling Class | |||
Class (see RFC 3260 [16]). | (see RFC 3260 [16]). | |||
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. | |||
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 | |||
skipping to change at page 42, line 22 | skipping to change at page 46, line 26 | |||
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 synchronized precision | the peer MEP. Note that this requires precise time | |||
time at either MEP by means outside the scope of this | synchronisation at either MEP by means outside the scope of | |||
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 source MEP. | viewpoint of the originating MEP. | |||
One-way DM is applicable to both unidirectional and | ||||
bidirectional (co-routed or associated) transport paths while | ||||
two-way DM is applicable only to bidirectional (co-routed or | ||||
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 PHB | In order to support pro-active DM, the transmission rate and, | |||
associated with the DM OAM packets originating from a MEP need | for E-LSPs, the PHB associated with the DM OAM packets | |||
be configured as part of the DM provisioning. DM OAM packets | originating from a MEP need be configured as part of the DM | |||
should be transmitted with the PHB that yields the lowest | provisioning. DM OAM packets should be transmitted with the PHB | |||
discard probability 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 [16]). | |||
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 43, line 37 | skipping to change at page 47, line 46 | |||
transport path, the CFI message requires additional information | transport path, the CFI message 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 PHB of the CFI OAM message/information element should be | and, for E-LSPs, the PHB of the CFI OAM message/information | |||
configured as part of the CFI configuration. | element should be 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 44, line 20 | skipping to change at page 48, line 31 | |||
(e.g., data plane loopback) and the issuance of notifications | (e.g., data plane loopback) and the issuance of notifications | |||
into client layers of the transport path being removed from | into client layers of the transport path being removed from | |||
service (e.g., lock-reporting) | service (e.g., lock-reporting) | |||
3. The measurements resulting from on-demand monitoring are | 3. The measurements resulting from on-demand monitoring are | |||
typically harvested in real time, as these are frequently | typically harvested in real time, as these are frequently | |||
initiated manually. These do not necessarily require | initiated manually. These do not necessarily require | |||
different harvesting mechanisms that for harvesting proactive | different harvesting mechanisms that for harvesting proactive | |||
monitoring telemetry. | monitoring telemetry. | |||
The functions that are exclusive out-of-service are those | The functions that are exclusively out-of-service are those | |||
described in section 6.3. The remainder are applicable to both | described in section 6.3. The remainder are applicable to both | |||
in-service and out-of-service transport paths. | in-service and out-of-service transport paths. | |||
6.1. Connectivity Verification | 6.1. Connectivity Verification | |||
In order to preserve network resources, e.g. bandwidth, | On demand connectivity verification function, as required in | |||
processing time at switches, it may be preferable to not use | section 2.2.3 of RFC 5860 [11], is a transaction that flows from | |||
proactive CC-V. In order to perform fault management functions, | the originating MEP to a target MIP or MEP to verify the | |||
network management may invoke periodic on-demand bursts of on- | connectivity between these points. | |||
demand CV packets, as required in section 2.2.3 of RFC 5860 | ||||
[11]. | ||||
On demand connectivity verification is a transaction that flows | ||||
from the source MEP to a target MIP or MEP. | ||||
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, | ||||
processing time at switches, it may be preferable to not use | ||||
proactive CC-V. In order to perform fault management functions, | ||||
network management may invoke periodic on-demand bursts of on- | ||||
demand CV packets. | ||||
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 a source MEP and a specific | entire MEG (end-to-end) or between the originating MEP and a | |||
MIP. This functionality may not be available for associated | specific MIP. This functionality may not be available for | |||
bidirectional transport paths or unidirectional paths, as the | associated bidirectional transport paths or unidirectional | |||
MIP may not have a return path to the source MEP for the on- | paths, as the MIP may not have a return path to the originating | |||
demand CV transaction. | MEP for the on-demand CV transaction. | |||
On-demand CV may generate a one-time burst of on-demand CV | On-demand CV may generate a one-time burst of on-demand CV | |||
packets, or be used to invoke periodic, non-continuous, bursts | packets, or be used to invoke periodic, non-continuous, bursts | |||
of on-demand CV packets. The number of packets generated in | of on-demand CV packets. The number of packets generated in | |||
each burst is configurable at the MEPs, and should take into | each burst is configurable at the MEPs, and should take into | |||
account normal packet-loss conditions. | account normal packet-loss conditions. | |||
When invoking a periodic check of the MEG, the source MEP should | When invoking a periodic check of the MEG, the originating MEP | |||
issue a burst of on-demand CV packets that uniquely identifies | should issue a burst of on-demand CV packets that uniquely | |||
the MEG being verified. The number of packets and their | identifies the MEG being verified. The number of packets and | |||
transmission rate should be pre-configured at the source MEP. | their transmission rate should be pre-configured at the | |||
The source MEP should use the mechanisms defined in sections 3.3 | originating MEP. The source MEP should use the mechanisms | |||
and 3.4 when sending an on-demand CV packet to a target MEP or | defined in sections 3.3 and 3.4 when sending an on-demand CV | |||
target MIP respectively. The target MEP/MIP shall return a reply | packet to a target MEP or target MIP respectively. The target | |||
on-demand CV packet for each packet received. If the expected | MEP/MIP shall return a reply on-demand CV packet for each packet | |||
number of on-demand CV reply packets is not received at source | received. If the expected number of on-demand CV reply packets | |||
MEP, this is an indication that a connectivity problem may | is not received at originating MEP, this is an indication that a | |||
exist. | 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 target 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 source MEP should support the configuration | For on-demand CV the originating MEP should support the | |||
of the number of packets to be transmitted/received in each | configuration of the number of packets to be | |||
burst of transmissions and their packet size. | transmitted/received in each burst of transmissions and their | |||
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. | |||
The PHB of the on-demand CV packets should be configured as | For E-LSPs, the PHB of the on-demand CV packets should be | |||
well. This permits the verification of correct operation of QoS | configured as well. This permits the verification of correct | |||
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]. As proactive LM, on-demand LM is used to | |||
exchange counter values for the number of ingress and egress | 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 | |||
skipping to change at page 46, line 29 | skipping to change at page 50, line 42 | |||
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 tester. | |||
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 on-demand LM OAM packets as | information and forward these on-demand LM OAM packets as | |||
regular data packets. | 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 PHB associated with | the LM procedures, the transmission rate and, for E-LSPs, the | |||
the LM OAM packets originating from a MEP must be configured as | PHB associated with the LM OAM packets originating from a MEP | |||
part of the on-demand LM provisioning. LM OAM packets should be | must be configured as part of the on-demand LM provisioning. LM | |||
transmitted with the PHB that yields the lowest discard | OAM packets should be transmitted with the PHB that yields the | |||
probability within the measured PHB Scheduling Class (see RFC | lowest drop precedence within the measured PHB Scheduling Class | |||
3260 [16]). | (see RFC 3260 [16]). | |||
6.2.2. Sampling skew | 6.2.2. Sampling skew | |||
If an implementation makes use of a hardware forwarding path | The same considerations described in section 5.5.2 for the | |||
which operates in parallel with an OAM processing path, whether | pro-active LM are also applicable to on-demand LM | |||
hardware or software based, the packet and byte counts may be | implementations. | |||
skewed if one or more packets can be processed before the OAM | ||||
processing samples counters. If OAM is implemented in software | ||||
this error can be quite large. | ||||
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. | |||
6.3. Diagnostic Tests | 6.3. Diagnostic Tests | |||
Diagnostic tests are tests performed on a MEG that has been taken | Diagnostic tests are tests performed on a MEG that has been taken | |||
out-of-service. | out-of-service. | |||
6.3.1. Throughput Estimation | 6.3.1. Throughput Estimation | |||
Throughput estimation is an on-demand out-of-service function, | Throughput estimation is an on-demand out-of-service function, | |||
as required in section 2.2.5 of RFC 5860 [11], that allows | as required in section 2.2.5 of RFC 5860 [11], that allows | |||
verifying the bandwidth/throughput of an MPLS-TP transport path | verifying the bandwidth/throughput of an MPLS-TP transport path | |||
(LSP or PW) before it is put in-service. | (LSP or PW) before it is put in-service. | |||
Throughput estimation is performed between MEPs and between MEP | Throughput estimation is performed between MEPs and between MEP | |||
and MIP. It and can be performed in one-way or two-way modes. | and MIP. It can be performed in one-way or two-way modes. | |||
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), graphing 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 MEP source 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. | |||
For a one-way test, the remote MEP sink 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 MEP sink calculates the packet loss. | and the local sink MEP calculates the packet loss. | |||
It is worth noting that two-way throughput estimation can only | It is worth noting that two-way throughput estimation is only | |||
evaluate the minimum of available throughput of the two | applicable to bidirectional (co-routed or associated) transport | |||
directions. In order to estimate the throughput of each | paths and can only evaluate the minimum of available throughput | |||
direction uniquely, two one-way throughput estimation sessions | of the two directions. In order to estimate the throughput of | |||
have to be setup. | each direction uniquely, two one-way throughput estimation | |||
sessions have to be setup. | ||||
It is also worth noting that if throughput estimation is | ||||
performed on transport paths that transit oversubscribed links, | ||||
the test may not produce comprehensive results if viewed in | ||||
isolation because the impact of the test on the surrounding | ||||
traffic needs to also be considered. Moreover, the estimation | ||||
will only reflect the bandwidth available at the moment when the | ||||
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 | |||
as intermediate nodes, do not process the throughput test | as intermediate nodes, do not process the throughput test | |||
information and forward these on-demand test OAM packets as | information and forward these on-demand test OAM packets as | |||
regular data packets. | regular data packets. | |||
6.3.1.1. Configuration considerations | 6.3.1.1. Configuration considerations | |||
Throughput estimation is an out-of-service tool. The diagnosed | Throughput estimation is an out-of-service tool. The diagnosed | |||
MEG should be put into a Lock status before the diagnostic test | MEG should be put into a Lock status before the diagnostic test | |||
skipping to change at page 48, line 16 | skipping to change at page 52, line 35 | |||
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. | |||
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 packets, then accurate measurement of | data rates than OAM test packets, then accurate measurement of | |||
throughput using OAM packets is not achievable. Whether OAM | throughput using OAM test packets is not achievable. Whether | |||
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 | |||
If multilink is used, then it may not be possible to perform | If multilink is used, then it may not be possible to perform | |||
throughput measurement, as the throughput test may not have a | throughput measurement, as the throughput test may not have a | |||
mechanism for utilizing more than one component link of the | mechanism for utilizing more than one component link of the | |||
aggregated link. | aggregated link. | |||
6.3.2. Data plane Loopback | 6.3.2. Data plane Loopback | |||
skipping to change at page 48, line 47 | skipping to change at page 53, line 17 | |||
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 source MEP will see all source MEP originated OAM messages | the sink MEP will see all the OAM messages, originated by the | |||
returned to it. | associated source MEP, returned to it. | |||
The only way to send an OAM packet to a node set in the data | The only way to send an OAM packet (e.g., to remove the data | |||
plane loopback mode is via TTL expiry, irrespectively on whether | plane loopback state) to the MIPs or MEPs hosted by a node set | |||
the node is hosting MIPs or MEPs. It should also be noted that | in the data plane loopback mode is via TTL expiry. It should | |||
MIPs can be addressed with more than one TTL value on a | also be noted that MIPs can be addressed with more than one TTL | |||
co-routed bi-directional path set into dataplane loopback. | value on a co-routed bi-directional path set into dataplane | |||
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 | |||
skipping to change at page 49, line 38 | skipping to change at page 54, line 12 | |||
can be put into data plane loopback state via an NMS action or | can be put into data plane loopback state via an NMS action or | |||
using an OAM tool for data plane loopback configuration. | using an OAM tool for data plane loopback configuration. | |||
If the data plane loopback point is set somewhere at an | If the data plane loopback point is set somewhere at an | |||
intermediate point of a co-routed bidirectional transport path, | intermediate point of a co-routed bidirectional transport path, | |||
the side of loop back function (one side or both side) needs to | the side of loop back function (one side or both side) needs to | |||
be configured. | be configured. | |||
6.4. Route Tracing | 6.4. Route Tracing | |||
It is often necessary to trace a route covered by a MEG from a | It is often necessary to trace a route covered by a MEG from an | |||
source MEP to the sink MEP including all the MIPs in-between, | originating MEP to the peer MEP(s) including all the MIPs in- | |||
and may be conducted after provisioning an MPLS-TP transport | between, and may be conducted after provisioning an MPLS-TP | |||
path for, e.g., trouble shooting purposes such as fault | transport path for, e.g., trouble shooting purposes such as | |||
localization. | fault localization. | |||
The route tracing function, as required in section 2.2.4 of RFC | The route tracing function, as required in section 2.2.4 of RFC | |||
5860 [11], is providing this functionality. Based on the fate | 5860 [11], is providing this functionality. Based on the fate | |||
sharing requirement of OAM flows, i.e. OAM packets receive the | sharing requirement of OAM flows, i.e. OAM packets receive the | |||
same forwarding treatment as data packet, route tracing is a | same forwarding treatment as data packet, route tracing is a | |||
basic means to perform connectivity verification and, to a much | basic means to perform connectivity verification and, to a much | |||
lesser degree, continuity check. For this function to work | lesser degree, continuity check. For this function to work | |||
properly, a return path must be present. | properly, a return path must be present. | |||
Route tracing might be implemented in different ways and this | Route tracing might be implemented in different ways and this | |||
skipping to change at page 50, line 38 | skipping to change at page 55, line 10 | |||
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 synchronized precision | the peer MEP. Note that this requires precise time | |||
time at either MEP by means outside the scope of this | synchronisation at either MEP by means outside the scope of | |||
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 source 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 PHB associated with | the DM procedures, the transmission rate and, for E-LSPs, the | |||
the DM OAM packets originating from a MEP need be configured as | PHB associated with the DM OAM packets originating from a MEP | |||
part of the DM provisioning. DM OAM packets should be | need be configured as part of the DM provisioning. DM OAM | |||
transmitted with the PHB that yields the lowest discard | packets should be transmitted with the PHB that yields the | |||
probability within the measured PHB Scheduling Class (see RFC | lowest drop precedence within the measured PHB Scheduling Class | |||
3260 [16]). | (see RFC 3260 [16]). | |||
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 53, line 5 | skipping to change at page 57, line 24 | |||
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 | |||
terminated, as described in section 5.4. | terminated, as described in section 5.4. | |||
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 passwords, | OAM traffic can reveal sensitive information such as performance | |||
performance data and details about e.g. the network topology. | data and details about the current state of the network. | |||
The nature of OAM data therefore suggests that some form of | Insertion of, or modifications to OAM transactions can mask the | |||
authentication, authorization and encryption is in place. This | true operational state of the network and in the case of | |||
will prevent unauthorized access to vital equipment and it will | transactions for administration control, such as Lock or | |||
prevent third parties from learning about sensitive information | dataplane loopback instructions, these can be used for explicit | |||
about the transport network. However it should be observed that | denial of service attacks. The effect of such attacks is | |||
the combination of all permutations of unique MEP to MEP, MEP to | mitigated only by the fact that the managed entities whose state | |||
MIP, and intermediate system originated transactions mitigates | can be masked is limited to those that transit the point of | |||
against the practical establishment and maintenance of a large | malicious access to the network internals due to the fate | |||
number of security associations per MEG. | sharing nature of OAM messaging. | |||
For this reason it is assumed that the network is physically | The sensitivity of OAM data therefore suggests that one solution | |||
secured against man-in-the-middle attacks. Further, this | is that some form of authentication, authorization and | |||
document describes OAM functions that, if a man-in-the-middle | encryption is in place. This will prevent unauthorized access to | |||
attack was possible, could be exploited to significantly disrupt | vital equipment and it will prevent third parties from learning | |||
proper operation of the network. | about sensitive information about the transport network. However | |||
it should be observed that the combination of the need for | ||||
timeliness of OAM transaction exchange and all permutations of | ||||
unique MEP to MEP, MEP to MIP, and intermediate system | ||||
originated transactions mitigates against the practical | ||||
establishment and maintenance of 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 | ||||
network is physically secured from malicious access such that | ||||
OAM transactions scoped to fault and performance management of | ||||
individual MEGs are not encumbered with additional security. | ||||
Mechanisms that the framework does not specify might be subject | Mechanisms that the framework does not specify might be subject | |||
to additional security considerations. | to additional security considerations. | |||
9. IANA Considerations | 9. IANA Considerations | |||
No new IANA considerations. | No new IANA considerations. | |||
10. Acknowledgments | 10. Acknowledgments | |||
skipping to change at page 54, line 10 | skipping to change at page 59, line 10 | |||
Swallow, Yuji Tochio, Curtis Villamizar, Maarten Vissers and | Swallow, Yuji Tochio, Curtis Villamizar, Maarten Vissers and | |||
Xuequin Wei for their comments and enhancements to the text. | 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-00 | Network-to-Network Interfaces", draft-ietf-mpls-tp-uni-nni-02 | |||
(work in progress), August 2010 | (work in progress), December 2010 | |||
[10] Swallow, G., Bocci, M., "MPLS-TP Identifiers", draft-ietf- | [10] Swallow, G., Bocci, M., "MPLS-TP Identifiers", draft-ietf- | |||
mpls-tp-identifiers-02 (work in progress), July 2010 | mpls-tp-identifiers-03 (work in progress), December 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] ITU-T Recommendation G.806 (01/09), "Characteristics of | |||
transport equipment - Description methodology and generic | transport equipment - Description methodology and generic | |||
functionality ", January 2009 | functionality ", January 2009 | |||
11.2. Informative References | 11.2. Informative References | |||
[14] Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten, | [14] 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-02 (work in progress), July 2010 | |||
[15] Nichols, K., Blake, S., Baker, F., Black, D., "Definition | [15] 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 | [16] 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 | [17] 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 | [18] 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 | [19] 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 | [20] 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 | [21] 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) | [22] 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 | |||
End of changes. 242 change blocks. | ||||
699 lines changed or deleted | 887 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/ |