draft-ietf-ccamp-rsvp-te-eth-oam-ext-00.txt   draft-ietf-ccamp-rsvp-te-eth-oam-ext-01.txt 
Network Working Group A. Takacs Network Working Group A. Takacs
Internet-Draft B. Gero Internet-Draft B. Gero
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: June 26, 2009 D. Fedyk Expires: September 10, 2009 D. Fedyk
D. Mohan D. Mohan
Nortel Nortel
December 23, 2008 H. Long
Huawei
March 9, 2009
GMPLS RSVP-TE Extensions for Ethernet OAM Configuration GMPLS RSVP-TE Extensions for Ethernet OAM Configuration
draft-ietf-ccamp-rsvp-te-eth-oam-ext-00 draft-ietf-ccamp-rsvp-te-eth-oam-ext-01
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 26, 2009. This Internet-Draft will expire on September 10, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2008 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Abstract Abstract
The GMPLS controlled Ethernet Label Switching (GELS) work is The GMPLS controlled Ethernet Label Switching (GELS) work is
extending GMPLS RSVP-TE to support the establishment of Ethernet extending GMPLS RSVP-TE to support the establishment of Ethernet
LSPs. IEEE Ethernet Connectivity Fault Management (CFM) specifies an LSPs. IEEE Ethernet Connectivity Fault Management (CFM) specifies an
adjunct OAM flow to check connectivity in Ethernet networks. CFM can adjunct OAM flow to check connectivity in Ethernet networks. CFM can
be also used with Ethernet LSPs for fault detection and triggering be also used with Ethernet LSPs for fault detection and triggering
recovery mechanisms. The ITU-T Y.1731 specification builds on CFM recovery mechanisms. The ITU-T Y.1731 specification builds on CFM
and specifies additional OAM mechanisms, including Performance and specifies additional OAM mechanisms, including Performance
Monitoring, for Ethernet networks. This document specifies Monitoring, for Ethernet networks. This document specifies
extensions of GMPLS RSVP-TE to support the setup of the associated extensions of GMPLS RSVP-TE to support the setup of the associated
Ethernet OAM (CFM and Y.1731) entities adding a technology specific Ethernet OAM (CFM and Y.1731) entities adding a technology specific
TLV to [OAM-CONF-FWK]. TLV to [OAM-CONF-FWK].
Changes from previous version
Technology independent extensions were moved to a separate framework
document leaving only the Ethernet specific extensions in this
document.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in document are to be interpreted as described in
Table of Contents Table of Contents
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview of Ethernet OAM operation in PBB-TE networks . . . . 6 2. Overview of Ethernet OAM operation . . . . . . . . . . . . . . 6
3. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . 8 3. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . 8
3.1. Operation overview . . . . . . . . . . . . . . . . . . . . 8 3.1. Operation overview . . . . . . . . . . . . . . . . . . . . 8
3.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 10 3.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 10
3.3. Ethernet OAM Configuration TLV . . . . . . . . . . . . . . 10 3.3. Ethernet OAM Configuration TLV . . . . . . . . . . . . . . 10
3.3.1. MD Name Sub-TLV . . . . . . . . . . . . . . . . . . . 11 3.3.1. MD Name Sub-TLV . . . . . . . . . . . . . . . . . . . 11
3.3.2. Short MA Name Sub-TLV . . . . . . . . . . . . . . . . 12 3.3.2. Short MA Name Sub-TLV . . . . . . . . . . . . . . . . 12
3.3.3. MEP ID Sub-TLV . . . . . . . . . . . . . . . . . . . . 12 3.3.3. MEP ID Sub-TLV . . . . . . . . . . . . . . . . . . . . 13
3.3.4. Continuity Check (CC) Sub-TLV . . . . . . . . . . . . 13 3.3.4. Continuity Check (CC) Sub-TLV . . . . . . . . . . . . 13
3.4. Ethernet OAM configuration errors . . . . . . . . . . . . 13 3.4. Pro-active Performance Monitoring . . . . . . . . . . . . 14
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 3.5. Ethernet OAM configuration errors . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21
1. Background 1. Background
Provider Backbone Bridging - Traffic Engineering (PBB-TE) Provider Backbone Bridging - Traffic Engineering (PBB-TE)
[IEEE-PBBTE] decouples the Ethernet data and control planes by [IEEE-PBBTE] decouples the Ethernet data and control planes by
explicitly supporting external control/management mechanisms to explicitly supporting external control/management mechanisms to
configure static filtering entries in bridges and create explicitly configure static filtering entries in bridges and create explicitly
routed Ethernet connections. In addition PBB-TE defines mechanisms routed Ethernet connections. In addition PBB-TE defines mechanisms
for 1:1 protection switching of bidirectional Ethernet connections. for 1:1 protection switching of bidirectional Ethernet connections.
Ethernet Connectivity Fault Management (CFM) defines an adjunct Ethernet Connectivity Fault Management (CFM) defines an adjunct
connectivity monitoring OAM flow to check the liveliness of Ethernet connectivity monitoring OAM flow to check the liveliness of Ethernet
networks [IEEE-CFM]. With PBB-TE Ethernet networks will support networks [IEEE-CFM]. With PBB-TE Ethernet networks will support
explicitly-routed Ethernet connections. CFM can be used to track the explicitly-routed Ethernet connections. CFM can be used to track the
liveliness of PBB-TE connections and detect data plane failures. liveliness of PBB-TE and point-to-point VLAN connections and detect
data plane failures.
In IETF the GMPLS controlled Ethernet Label Switching (GELS) In IETF the GMPLS controlled Ethernet Label Switching (GELS)
[GELS-Framework] work is extending the GMPLS control plane to support [GELS-Framework] work is extending the GMPLS control plane to support
the establishment of point-to-point PBB-TE data plane connections. the establishment of PBB-TE and point-to-point VLAN data plane
We refer to GMPLS established PBB-TE connections as Ethernet LSPs. connections. We refer to GMPLS established Ethernet connections as
GELS enables the application of MPLS-TE and GMPLS provisioning and Ethernet LSPs. GELS enables the application of MPLS-TE and GMPLS
recovery features in Ethernet networks. provisioning and recovery features in Ethernet networks.
2. Overview of Ethernet OAM operation in PBB-TE networks 2. Overview of Ethernet OAM operation
For the purposes of this document, we only discuss Ethernet OAM For the purposes of this document, we only discuss Ethernet OAM
[IEEE-CFM] aspects that are relevant for the connectivity monitoring [IEEE-CFM] aspects that are relevant for the connectivity monitoring
of point-to-point PBB-TE connections. of PBB-TE and point-to-point VLAN connections.
PBB-TE [IEEE-PBBTE] defines point-to-point Ethernet Switched Paths PBB-TE [IEEE-PBBTE] defines point-to-point Ethernet Switched Paths
(ESPs) as a provisioned traffic engineered unidirectional (ESPs) as a provisioned traffic engineered unidirectional
connectivity, identified by the 3-tuple [ESP-MAC DA, ESP-MAC SA, ESP- connectivity, identified by the 3-tuple [ESP-MAC DA, ESP-MAC SA, ESP-
VID] where the ESP-MAC DA is the destination address of the ESP, the VID] where the ESP-MAC DA is the destination address of the ESP, the
ESP-MAC SA is the source address of the ESP, and the ESP-VID is a ESP-MAC SA is the source address of the ESP, and the ESP-VID is a
VLAN identifier allocated for explicitly routed connections. To form VLAN identifier allocated for explicitly routed connections. To form
a bidirectional PBB-TE connection two co-routed point-to-point ESPs a bidirectional PBB-TE connection two co-routed point-to-point ESPs
are combined. The combined ESPs must have the same ESP-MAC addresses are combined. The combined ESPs must have the same ESP-MAC addresses
but may have different ESP-VIDs. but may have different ESP-VIDs.
Note that although it would be possible to use GMPLS to setup a Note that although it would be possible to use GMPLS to setup a
single unidirectional ESP, the Ethernet OAM mechanisms are only full single unidirectional ESP, the Ethernet OAM mechanisms are only full
functional when bidirectional connections are established with co- functional when bidirectional connections are established with co-
routed ESPs. Hence, we focus on bidirectional point-to-point PBB-TE routed ESPs. Hence, we focus on bidirectional point-to-point PBB-TE
connections. connections.
At both ends of the bidiretional point-to-point PBB-TE connection one At both ends of the bidirectional point-to-point PBB-TE connection
Maintenance Endpoint (MEP) is configured. The MEPs monitoring a one Maintenance Endpoint (MEP) is configured. The MEPs monitoring a
PBB-TE connection must be configured with the same Maintenance Domain PBB-TE connection must be configured with the same Maintenance Domain
Level (MD Level) and Maintenance Association Identifier (MAID). Each Level (MD Level) and Maintenance Association Identifier (MAID). Each
MEP has a unique identifier, the MEP ID. Besides these identifiers a MEP has a unique identifier, the MEP ID. Besides these identifiers a
MEP monitoring a PBB-TE connection must be provisioned with the MEP monitoring a PBB-TE connection must be provisioned with the
3-tuples [ESP-MAC DA, ESP-MAC SA, ESP-VID] of the two ESPs. 3-tuples [ESP-MAC DA, ESP-MAC SA, ESP-VID] of the two ESPs.
In the case of point-to-point VLAN connections, the connection is
identified with a single VLAN forwarding traffic in both directions
or with two VLANs each forwarding traffic in a single direction.
Hence instead of the 3-tuples of the PBB-TE case MEPs must be
provisioned with the proper VLAN information, otherwise the same MD
Level, MAID, MEP ID configuration is required in this case as well.
MEPs exchange Connectivity Check Messages (CCMs) periodically with MEPs exchange Connectivity Check Messages (CCMs) periodically with
fixed intervals. Eight distinct intervals are defined in [IEEE-CFM]: fixed intervals. Eight distinct intervals are defined in [IEEE-CFM]:
+---+--------------------+----------------+ +---+--------------------+----------------+
| # | CCM Interval (CCI) | 3 bit encoding | | # | CCM Interval (CCI) | 3 bit encoding |
+---+--------------------+----------------+ +---+--------------------+----------------+
| 0 | Invalid | 000 | | 0 | Reserved | 000 |
| | | | | | | |
| 1 | 3 1/3 ms | 001 | | 1 | 3 1/3 ms | 001 |
| | | | | | | |
| 2 | 10 ms | 010 | | 2 | 10 ms | 010 |
| | | | | | | |
| 3 | 100 ms | 011 | | 3 | 100 ms | 011 |
| | | | | | | |
| 4 | 1 s | 100 | | 4 | 1 s | 100 |
| | | | | | | |
| 5 | 10 s | 101 | | 5 | 10 s | 101 |
skipping to change at page 7, line 32 skipping to change at page 7, line 32
| 7 | 10 min | 111 | | 7 | 10 min | 111 |
+---+--------------------+----------------+ +---+--------------------+----------------+
Table 1: CCM Interval encoding Table 1: CCM Interval encoding
If 3 consecutive CCM messages are not received by one of the MEPs it If 3 consecutive CCM messages are not received by one of the MEPs it
declares a connectivity failure and signals the failure in subsequent declares a connectivity failure and signals the failure in subsequent
CCM messages, by setting the Remote Defect Indicator (RDI) bit, to CCM messages, by setting the Remote Defect Indicator (RDI) bit, to
the remote MEP. If a MEP receives a CCM message with RDI set it the remote MEP. If a MEP receives a CCM message with RDI set it
immediately declares failure. The detection of a failure may trigger immediately declares failure. The detection of a failure may trigger
protection switching mechanisms or may be signalled to a management protection switching mechanisms or may be signaled to a management
system. However, what happens once a failure is detected is out of system. However, what happens once a failure is detected is out of
the scope of this document. the scope of this document.
At each transit node Maintenance Intermediate Points (MIPs) can be
established to help failure localization by supporting link trace and
loop back functions. MIPs need to be provisioned with a subset of
MEP identification parameters described above.
3. GMPLS RSVP-TE Extensions 3. GMPLS RSVP-TE Extensions
3.1. Operation overview 3.1. Operation overview
To simplify the configuration of connectivity monitoring, when an To simplify the configuration of connectivity monitoring, when an
Ethernet LSP is signalled the associated MEPs should be automatically Ethernet LSP is signaled the associated MEPs should be automatically
established. To monitor an Ethernet LSP a set of parameters must be established. To monitor an Ethernet LSP a set of parameters must be
provided to setup a Maintenance Association and related MEPs. provided to setup a Maintenance Association and related MEPs.
Optionally, MIPs may be created at the transit nodes of the Ethernet
LSP. The LSP Attributes Flags: "OAM MEP entities desired" and "OAM
MIP entities desired", described in [OAM-CONF-FWK] are used to signal
that the respective OAM entities must be established. Subsequently,
an OAM Configuration TLV is added to the LSP_ATTRIBUTES Object
specifying that Ethernet OAM is to be setup for the LSP. The below
detailed Ethernet OAM specific information is carried in a new sub-
TLV.
o A unique MAID must be allocated for the PBB-TE connection and both o A unique MAID must be allocated for the PBB-TE connection and both
MEPs must be configured with the same information. The MAID MEPs must be configured with the same information. The MAID
consists of an optional Maintenance Domain Name (MD Name) and a consists of an optional Maintenance Domain Name (MD Name) and a
mandatory Short Maintenance Association Name (Short MA Name). mandatory Short Maintenance Association Name (Short MA Name).
Various formating rules for these names have been defined by Various formatting rules for these names have been defined by
[IEEE-CFM]. Since these information is also carried in all CCM [IEEE-CFM]. Since these information is also carried in all CCM
messages, the combined length of the Names is limited to 44 bytes. messages, the combined length of the Names is limited to 44 bytes.
How these parameters are determined is out of scope of this How these parameters are determined is out of scope of this
document. document.
o Each MEP must be provisioned with a MEP ID. The MEP ID uniquely o Each MEP must be provisioned with a MEP ID. The MEP ID uniquely
identifies a given MEP within a Maintenance Association. That is, identifies a given MEP within a Maintenance Association. That is,
the combination of MAID and MEP ID must uniquely identify a MEP. the combination of MAID and MEP ID must uniquely identify a MEP.
How the value of the MEP ID is determined is out of scope of this How the value of the MEP ID is determined is out of scope of this
document. document.
o The Maintenance Domain Level (MD Level) allows hierarchical o The Maintenance Domain Level (MD Level) allows hierarchical
separation of monitoring entities. [IEEE-CFM] allows separation of monitoring entities. [IEEE-CFM] allows
differentiation of 8 levels. How the value of the MD Level is differentiation of 8 levels. How the value of the MD Level is
determined is out of scope of this document. Note that most determined is out of scope of this document. Note that most
probably for all Ethernet LSPs a single (default) MD Level will be probably for all Ethernet LSPs a single (default) MD Level will be
used. used in a network domain.
o The desired CCM Interval must be specified by the management o The desired CCM Interval must be specified by the management
system based on service requirements or operator policy. The same system based on service requirements or operator policy. The same
CCM Interval must be set in each of the MEPs monitoring a given CCM Interval must be set in each of the MEPs monitoring a given
Ethernet LSP. How the value of the CCM Interval is determined is Ethernet LSP. How the value of the CCM Interval is determined is
out of scope of this document. out of scope of this document.
o The desired CCM priority to be set by MEPs for the CCM frames can o The desired CCM priority to be set by MEPs for the CCM frames can
be specified. The same CCM priority must be set in each of the be specified. The same CCM priority must be set in each of the
MEPs monitoring a given Ethernet LSP. How CCM priority is MEPs monitoring a given Ethernet LSP. How CCM priority is
determined is out of scope of this document. determined is out of scope of this document. Note that the
highest priority is used as the default CCM priority.
o MEPs must be aware of their own and the reachability parameters of o MEPs must be aware of their own and the reachability parameters of
the remote MEP. In the case of bidirectional point-to-point the remote MEP. In the case of bidirectional point-to-point
PBB-TE connections this requires that the 3-tuples [ESP-MAC A, PBB-TE connections this requires that the 3-tuples [ESP-MAC A,
ESP-MAC B, ESP-VID1] and [ESP-MAC B, ESP-MAC A, ESP-VID2] are ESP-MAC B, ESP-VID1] and [ESP-MAC B, ESP-MAC A, ESP-VID2] are
configured in each MEP, where the ESP-MAC A is the same as the configured in each MEP, where the ESP-MAC A is the same as the
local MEP's MAC and ESP-MAC B is the same as remote MEP's MAC. local MEP's MAC and ESP-MAC B is the same as remote MEP's MAC.
The GMPLS Ethernet Label for forwarding, as defined in The GMPLS Ethernet Label for forwarding, as defined in
[GELS-PBBTE], consists of the ESP-MAC DA and ESP-VID. Hence the [GELS-PBBTE], consists of the ESP-MAC DA and ESP-VID. Hence the
necessary reachability parameters for the MEPs can be obtained necessary reachability parameters for the MEPs can be obtained
from Ethernet Labels (i.e., carried in the "downstream" and from Ethernet Labels (i.e., carried in the "downstream" and
upstream labels). upstream labels). In the case of point-to-point VLAN connections,
MEPs need to be provisioned with the VLAN identifiers, which in
this case are derived similarly from the Ethernet Label.
Assuming the procedures described in [GELS-PBBTE] for bidirectional Assuming the procedures described in [GELS-PBBTE] for bidirectional
Ethernet LSP establishment the MEP configuration should be as PBB-TE Ethernet LSP establishment the MEP configuration should be as
follows. When the RSVP-TE signalling is initiated for the follows. When the RSVP-TE signaling is initiated for the
bidirectional Ethernet LSP the local node generates a Path message bidirectional Ethernet LSP the local node generates a Path message
and: and:
o Allocates an Upstream Label from its MAC address (ESP-MAC A) and o Allocates an Upstream Label from its MAC address (ESP-MAC A) and
locally selected VID (ESP-VID1), that it would like to use to locally selected VID (ESP-VID1), that it would like to use to
receive traffic; receive traffic;
o Inserts an Ethernet OAM Configuration TLV in the LSP_ATTRIBUTES o Inserts an Ethernet OAM Configuration TLV in the LSP_ATTRIBUTES
object, specifying the CCM Interval and MD Level; object, specifying the CCM Interval and MD Level;
skipping to change at page 10, line 4 skipping to change at page 10, line 15
Ethernet Labels. In addition the information received in the Ethernet Labels. In addition the information received in the
Ethernet OAM Configuration TLV is used to configure the local MEP. Ethernet OAM Configuration TLV is used to configure the local MEP.
Once the Resv message successfully arrives to the initiator it can Once the Resv message successfully arrives to the initiator it can
extract the remote side's reachability information from the LABEL extract the remote side's reachability information from the LABEL
object whereby this node has also obtained all the information needed object whereby this node has also obtained all the information needed
to establish its local MEP. to establish its local MEP.
Once the MEPs are established the monitoring of the LSP is Once the MEPs are established the monitoring of the LSP is
operational. In certain situations, e.g., maintenance, re- operational. In certain situations, e.g., maintenance, re-
optimisation of LSPs, it is desirable to explicitly enable or disable optimization of LSPs, it is desirable to explicitly enable or disable
the monitoring of LSPs (i.e., start/stop exchanging CC messages). To the monitoring of LSPs (i.e., start/stop exchanging CC messages). To
allow administrative control of LSP monitoring the "Monitoring allow administrative control of LSP monitoring the "Monitoring
Disabled" (M) bit in the ADMIN_STATUS Object is used [OAM-CONF-FWK]. Disabled" (M) bit in the ADMIN_STATUS Object is used [OAM-CONF-FWK].
3.2. OAM Configuration TLV 3.2. OAM Configuration TLV
This TLV is specified in [OAM-CONF-FWK] and is used to select which This TLV is specified in [OAM-CONF-FWK] and is used to select which
OAM technology/method should be used for the LSP. In this document a OAM technology/method should be used for the LSP. In this document a
new OAM Type: Ethernet OAM is defined. new OAM Type: Ethernet OAM is defined.
skipping to change at page 13, line 42 skipping to change at page 14, line 10
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prio: Indicates the priority to be set for CCM frames. In Ethernet 3 Prio: Indicates the priority to be set for CCM frames. In Ethernet 3
bits carried in VLAN TAGs identify priority information. bits carried in VLAN TAGs identify priority information.
CCM I (CCM Interval): CCM Interval, according to the 3 bit encoding CCM I (CCM Interval): CCM Interval, according to the 3 bit encoding
[IEEE-CFM] shown in Table 1. If a node does not support the [IEEE-CFM] shown in Table 1. If a node does not support the
requested CCM Interval an error must be generated: "OAM Problem/ requested CCM Interval an error must be generated: "OAM Problem/
Unsupported CC Interval". Unsupported CC Interval".
3.4. Ethernet OAM configuration errors 3.4. Pro-active Performance Monitoring
Ethernet OAM functions for Performance Monitoring (PM) allow
measurements of different performance parameters including Frame Loss
Ratio, Frame Delay and Frame Delay variation as defined in the ITU-T
Y.1731 recommendation. Only a subset of PM functions are operated in
a pro-active fashion to monitor the performance of the connection
continuously. Pro-active PM supports Fault Management functions, by
providing an indication of decreased service performance and as such
may provide triggers to initiate recovery procedures.
While on demand PM functions are always initiated by management
commands, for pro-active PM it may be desirable to utilize the
control plane for configuration and activation together with Fault
Management functions such as Continuity Check.
ITU-T Y.1731 defines dual-ended Loss Measurement as pro-active OAM
for performance monitoring and as a PM function applicable to fault
management. For dual-ended Loss Measurement each MEP piggy-backs
transmitted and received frame counters on CC messages; to support
and synchronize bidirectional Loss Measurements at the MEPs. Dual-
ended Loss Measurement is invoked by setting the Performance
Monitoring/Loss OAM Function flag in the OAM Configuration TLV
[OAM-CONF-FWK]. Besides configuring the Continuity Check
functionality, no additional configuration is required for this type
of Loss Measurement.
3.5. Ethernet OAM configuration errors
In addition to error values specified in [OAM-CONF-FWK] this document In addition to error values specified in [OAM-CONF-FWK] this document
defines the following values for the "OAM Problem" Error Code. defines the following values for the "OAM Problem" Error Code.
o If a node does not support a specific CFM version an error must be o If a node does not support a specific CFM version an error must be
generated: "OAM Problem/Unsupported OAM Version". generated: "OAM Problem/Unsupported OAM Version".
o If a node does not support a specific MD Level an error must be o If a node does not support a specific MD Level an error must be
generated: "OAM Problem/Unsupported OAM Level". generated: "OAM Problem/Unsupported OAM Level".
skipping to change at page 16, line 7 skipping to change at page 17, line 7
carried in the OAM Configuration TLV in LSP_ATTRIBUTES and carried in the OAM Configuration TLV in LSP_ATTRIBUTES and
LSP_REQUIRED_ATTRIBUTES objects in Path messages. LSP_REQUIRED_ATTRIBUTES objects in Path messages.
The following values need to be assigned under the Error Code: "OAM The following values need to be assigned under the Error Code: "OAM
Problem": "Unsupported OAM Version", "Unsupported OAM Level", Problem": "Unsupported OAM Version", "Unsupported OAM Level",
"Unknown MD Name Format", "Unknown MA Name Format", "Name Length "Unknown MD Name Format", "Unknown MA Name Format", "Name Length
Problem", "Unsupported CC Interval". Problem", "Unsupported CC Interval".
5. Security Considerations 5. Security Considerations
The signalling of OAM related parameters and the automatic The signaling of OAM related parameters and the automatic
establishment of OAM entities introduces additional security establishment of OAM entities introduces additional security
considerations to those discussed in [RFC3473]. In particular, a considerations to those discussed in [RFC3473]. In particular, a
network element could be overloaded, if an attacker would request network element could be overloaded, if an attacker would request
liveliness monitoring, with frequent periodic messages, for a high liveliness monitoring, with frequent periodic messages, for a high
number of LSPs, targeting a single network element. number of LSPs, targeting a single network element.
Security aspects will be covered in more detailed in subsequent Security aspects will be covered in more detailed in subsequent
versions of this document. versions of this document.
6. Acknowledgements 6. Acknowledgements
skipping to change at line 584 skipping to change at page 20, line 38
Email: dwfedyk@nortel.com Email: dwfedyk@nortel.com
Dinesh Mohan Dinesh Mohan
Nortel Nortel
3500 Carling Ave 3500 Carling Ave
Ottawa, ON, K2H8E9 Ottawa, ON, K2H8E9
Canada Canada
Email: mohand@nortel.com Email: mohand@nortel.com
Hao Long
Huawei
Email: lonho@huawei.com
 End of changes. 30 change blocks. 
40 lines changed or deleted 101 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/