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/ |