draft-ietf-ccamp-rsvp-te-eth-oam-ext-04.txt   draft-ietf-ccamp-rsvp-te-eth-oam-ext-05.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: July 28, 2011 D. Fedyk Expires: September 15, 2011 D. Fedyk
Alcatel-Lucent Alcatel-Lucent
H. Long H. Long
Huawei Huawei
D. Mohan D. Mohan
January 24, 2011 March 14, 2011
GMPLS RSVP-TE Extensions for Ethernet OAM Configuration GMPLS RSVP-TE Extensions for Ethernet OAM Configuration
draft-ietf-ccamp-rsvp-te-eth-oam-ext-04 draft-ietf-ccamp-rsvp-te-eth-oam-ext-05
Abstract Abstract
The GMPLS controlled Ethernet Label Switching (GELS) work is The GMPLS controlled Ethernet Label Switching (GELS) work extended
extending GMPLS RSVP-TE to support the establishment of Ethernet GMPLS RSVP-TE to support the establishment of Ethernet LSPs. IEEE
LSPs. IEEE Ethernet Connectivity Fault Management (CFM) specifies an Ethernet Connectivity Fault Management (CFM) specifies an adjunct OAM
adjunct OAM flow to check connectivity in Ethernet networks. CFM can flow to check connectivity in Ethernet networks. CFM can be also
be also used with Ethernet LSPs for fault detection and triggering used with Ethernet LSPs for fault detection and triggering recovery
recovery mechanisms. The ITU-T Y.1731 specification builds on CFM mechanisms. The ITU-T Y.1731 specification builds on CFM and
and specifies additional OAM mechanisms, including Performance 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 defining Ethernet technology
TLV to [OAM-CONF-FWK]. specific TLV based on [OAM-CONF-FWK].
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
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 2, line 26 skipping to change at page 2, line 26
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on July 28, 2011. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 23 skipping to change at page 3, line 23
3.3.1. MD Name Sub-TLV . . . . . . . . . . . . . . . . . . . 10 3.3.1. MD Name Sub-TLV . . . . . . . . . . . . . . . . . . . 10
3.3.2. Short MA Name Sub-TLV . . . . . . . . . . . . . . . . 11 3.3.2. Short MA Name Sub-TLV . . . . . . . . . . . . . . . . 11
3.3.3. MEP ID Sub-TLV . . . . . . . . . . . . . . . . . . . . 12 3.3.3. MEP ID Sub-TLV . . . . . . . . . . . . . . . . . . . . 12
3.3.4. Continuity Check (CC) Sub-TLV . . . . . . . . . . . . 12 3.3.4. Continuity Check (CC) Sub-TLV . . . . . . . . . . . . 12
3.4. Pro-active Performance Monitoring . . . . . . . . . . . . 13 3.4. Pro-active Performance Monitoring . . . . . . . . . . . . 13
3.5. Ethernet OAM configuration errors . . . . . . . . . . . . 13 3.5. Ethernet OAM configuration errors . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
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 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], including the monitoring of explicitly-routed
explicitly-routed Ethernet connections. CFM can be used to track the Ethernet connections.
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) work
[GELS-Framework] work is extending the GMPLS control plane to support extended the GMPLS control plane to support the establishment of
the establishment of PBB-TE and point-to-point VLAN data plane explicitly routed Ethernet connections [RFC5828][RFC6060]. We refer
connections. We refer to GMPLS established Ethernet connections as to GMPLS established Ethernet connections as Ethernet LSPs. GELS
Ethernet LSPs. GELS enables the application of MPLS-TE and GMPLS enables the application of MPLS-TE and GMPLS provisioning and
provisioning and recovery features in Ethernet networks. recovery features in Ethernet networks.
2. Overview of Ethernet OAM operation 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 PBB-TE and point-to-point VLAN connections. of Ethernet LSPs.
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 only.
At both ends of the bidirectional point-to-point PBB-TE connection At both ends of the bidirectional point-to-point PBB-TE connection
one 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 In the case of point-to-point VLAN connections, the connection is
skipping to change at page 7, line 19 skipping to change at page 7, line 19
To simplify the configuration of connectivity monitoring, when an To simplify the configuration of connectivity monitoring, when an
Ethernet LSP is signaled 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 Optionally, MIPs may be created at the transit nodes of the Ethernet
LSP. The LSP Attributes Flags: "OAM MEP entities desired" and "OAM LSP. The LSP Attributes Flags: "OAM MEP entities desired" and "OAM
MIP entities desired", described in [OAM-CONF-FWK] are used to signal MIP entities desired", described in [OAM-CONF-FWK] are used to signal
that the respective OAM entities must be established. Subsequently, that the respective OAM entities must be established. Subsequently,
an OAM Configuration TLV is added to the LSP_ATTRIBUTES Object an OAM Configuration TLV is added to the LSP_ATTRIBUTES Object
specifying that Ethernet OAM is to be setup for the LSP. The below specifying that Ethernet OAM is to be setup for the LSP. The below
detailed Ethernet OAM specific information is carried in a new sub- detailed Ethernet OAM specific information is carried in the new
TLV. Ethernet OAM Configuration 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 formatting 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.
skipping to change at page 7, line 43 skipping to change at page 7, line 43
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 in a network domain. used within 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. Note that the determined is out of scope of this document. Note that the
highest priority is used as the default CCM priority. 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 address and ESP-MAC B is the same as remote MEP's
The GMPLS Ethernet Label for forwarding, as defined in MAC address. The GMPLS Ethernet Label for forwarding, as defined
[GELS-PBBTE], consists of the ESP-MAC DA and ESP-VID. Hence the in [RFC6060], 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). In the case of point-to-point VLAN connections, upstream labels). In the case of point-to-point VLAN connections,
MEPs need to be provisioned with the VLAN identifiers, which in MEPs need to be provisioned with the VLAN identifiers, which can
this case are derived similarly from the Ethernet Label. be derived similarly from the Ethernet Label.
Assuming the procedures described in [GELS-PBBTE] for bidirectional Assuming the procedures described in [RFC6060] for bidirectional
PBB-TE 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 signaling 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), which will be used to receive
receive traffic; traffic;
o Inserts an Ethernet OAM Configuration TLV in the LSP_ATTRIBUTES o Inserts the OAM Configuration TLV with OAM Type set to Ethernet
object, specifying the CCM Interval and MD Level; OAM in the LSP_ATTRIBUTES object;
o Adds the OAM Function Flags sub-TLV in the OAM Configuration TLV
and sets the OAM function flags as needed;
o Adds an Ethernet OAM Configuration sub-TLV in the OAM
Configuration TLV that specifies the CCM Interval and MD Level;
o Adds an MD Name Sub-TLV (optional) and a Short MA Name Sub-TLV to o Adds an MD Name Sub-TLV (optional) and a Short MA Name Sub-TLV to
the Ethernet OAM Configuration TLV, that will unambiguously the Ethernet OAM Configuration TLV, that will unambiguously
identify a Maintenance Association for this specific PBB-TE identify a Maintenance Association for this specific PBB-TE
connection. Note that values for these parameters may be derived connection. Note that values for these parameters may be derived
from the GMPLS LSP identification parameters; from the GMPLS LSP identification parameters;
o Adds a MEP ID Sub-TLV to the Ethernet OAM Configuration TLV. It o Adds a MEP ID Sub-TLV to the Ethernet OAM Configuration TLV. It
selects two distinct integer values to identify the local and selects two distinct integer values to identify the local and
remote MEPs within the Maintenance Association created for remote MEPs within the Maintenance Association created for
monitoring of the point-to-point PBB-TE connection. monitoring of the point-to-point PBB-TE connection.
Once the remote node receives the Path message it can use the Once the remote node receives the Path message it can use the
UPSTREAM_LABEL to extract the reachability information of the UPSTREAM_LABEL to extract the reachability information of the
initiator. Then it allocates a LABEL by selecting the MAC address initiator. Then it allocates a Lable by selecting the MAC address
(ESP-MAC B) and VID (ESP-VID2) it would like to use to receive (ESP-MAC B) and VID (ESP-VID2) it would like to use to receive
traffic. These parameters determine the reachability information of traffic. These parameters determine the reachability information of
the local MEP. That is, the 3-tuples [ESP-MAC A, ESP-MAC B, ESP- the local MEP. That is, the 3-tuples [ESP-MAC A, ESP-MAC B, ESP-
VID1] and [ESP-MAC B, ESP-MAC A, ESP-VID2] are derived from the VID1] and [ESP-MAC B, ESP-MAC A, ESP-VID2] are derived from the
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
operational. In certain situations, e.g., maintenance, re-
optimization of LSPs, it is desirable to explicitly enable or disable
the monitoring of LSPs (i.e., start/stop exchanging CC messages). To
allow administrative control of LSP monitoring the "Monitoring
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.
OAM Type Description OAM Type Description
------------ ------------------ ------------ ------------------
0 Reserved 0 Reserved
1 Ethernet OAM 1 Ethernet OAM
2-256 Reserved 2-256 Reserved
The receiving node when the Ethernet OAM Type is requested should The receiving node when the Ethernet OAM Type is requested should
look for the corresponding technology specific Ethernet OAM look for the corresponding technology specific Ethernet OAM
configuration TLV. Configuration TLV.
3.3. Ethernet OAM Configuration TLV 3.3. Ethernet OAM Configuration TLV
The Ethernet OAM Configuration TLV (depicted below) is defined for The Ethernet OAM Configuration TLV (depicted below) is defined for
Ethernet OAM specific configuration parameters. The Ethernet OAM Ethernet OAM specific configuration parameters. The Ethernet OAM
Configuration TLV is carried in the LSP_ATTRIBUTES object in Path Configuration TLV is carried in the LSP_ATTRIBUTES or
messages. This new TLV accommodates generic Ethernet OAM information LSP_REQUIRED_ATTRUIBUTES object in Path messages. This new TLV
and carries sub-TLVs. accommodates generic Ethernet OAM information and carries sub-TLVs.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (3) (IANA) | Length | | Type (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |MD L.| Reserved (set to all 0s) | | Version |MD L.| Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ sub TLVs ~ ~ sub TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: indicates a new type: the Ethernet OAM Configuration TLV (3) Type: indicates a new type: the Ethernet OAM Configuration TLV. IANA
(IANA to define). is requested to assigne a value from the "OAM Type sub-TLV" space in
the "RSVP-TE OAM Configuration Registry".
Length: indicates the total length including sub-TLVs. Length: indicates the total length including sub-TLVs.
Version: identifies the CFM protocol version according to [IEEE-CFM]. Version: identifies the CFM protocol version according to [IEEE-CFM].
If a node does not support a specific CFM version an error must be 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"
MD L. (MD Level): indicates the desired MD Level. The values are MD L. (MD Level): indicates the desired MD Level. The values are
according to [IEEE-CFM]. If a node does not support a specific MD according to [IEEE-CFM]. If a node does not support a specific MD
Level an error must be generated: "OAM Problem/Unsupported OAM Level an error must be generated: "OAM Problem/Unsupported OAM
Level". Level".
3.3.1. MD Name Sub-TLV 3.3.1. MD Name Sub-TLV
The optional MD Name sub-TLV is depicted below. The optional MD Name sub-TLV is depicted below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (1) (IANA) | Length | | Type (1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | Name Length | Reserved (set to all 0s) | | Format | Name Length | Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ MD Name ~ ~ MD Name ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1, MD Name Sub-TLV (IANA). Type: 1, MD Name Sub-TLV.
Length: indicates the total length of the TLV including padding. Length: indicates the total length of the TLV including padding.
Format: according to [IEEE-CFM]. Format: according to [IEEE-CFM].
Name Length: the length of the MD Name field in bytes. This is Name Length: the length of the MD Name field in bytes. This is
necessary to allow non 4 byte padded MD Name lengths. necessary to allow non 4 byte padded MD Name lengths.
MD Name: variable length field, formatted according to the format MD Name: variable length field, formatted according to the format
specified in the Format field. specified in the Format field.
skipping to change at page 11, line 26 skipping to change at page 11, line 26
Name sub-TLV is optional. In this case the MA Name must uniquely Name sub-TLV is optional. In this case the MA Name must uniquely
identify a Maintenance Association. identify a Maintenance Association.
3.3.2. Short MA Name Sub-TLV 3.3.2. Short MA Name Sub-TLV
The Short MA Name sub-TLV is depicted below. The Short MA Name sub-TLV is depicted below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (2) (IANA) | Length | | Type (2) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | Name Length | Reserved (set to all 0s) | | Format | Name Length | Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Short MA Name ~ ~ Short MA Name ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 2, Short MA Name Sub-TLV (IANA) Type: 2, Short MA Name Sub-TLV.
Length: indicates the total length of the TLV including padding. Length: indicates the total length of the TLV including padding.
Format: according to [IEEE-CFM]. Format: according to [IEEE-CFM].
Name Length: the length of the MA Name field in bytes. This is Name Length: the length of the MA Name field in bytes. This is
necessary to allow non 4 byte padded MA Name lengths. necessary to allow non 4 byte padded MA Name lengths.
Short MA Name: variable length field formatted according to the Short MA Name: variable length field formatted according to the
format specified in the Format field. format specified in the Format field.
skipping to change at page 12, line 12 skipping to change at page 12, line 12
Problem". Note that it is allowed to have no MD Name, in this case Problem". Note that it is allowed to have no MD Name, in this case
the MA Name must uniquely identify a Maintenance Association. the MA Name must uniquely identify a Maintenance Association.
3.3.3. MEP ID Sub-TLV 3.3.3. MEP ID Sub-TLV
The MEP ID Sub-TLV is depicted below. The MEP ID Sub-TLV is depicted below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (3) (IANA) | Length (4) | | Type (3) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local MEP ID |T|R| Reserved | | Local MEP ID |T|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote MEP ID |T|R| Reserved | | Remote MEP ID |T|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 3, MEP ID Sub-TLV (IANA) Type: 3, MEP ID Sub-TLV.
Length: indicates the total length of the TLV including padding. Length: indicates the total length of the TLV including padding.
Local MEP ID: a 16 bit integer value in the range 1-8191 of the MEP Local MEP ID: a 16 bit integer value in the range 1-8191 of the MEP
ID on the initiator side. ID on the initiator side.
Remote MEP ID: a 16 bit integer value in the range 1-8191 of the MEP Remote MEP ID: a 16 bit integer value in the range 1-8191 of the MEP
ID to be set for the MEP established at the receiving side. This ID to be set for the MEP established at the receiving side. This
value is determined by the initiator node. This is possible, since a value is determined by the initiator node. This is possible, since a
new MAID is assigned to each PBB-TE connection, and MEP IDs must be new MAID is assigned to each PBB-TE connection, and MEP IDs must be
skipping to change at page 12, line 44 skipping to change at page 12, line 44
corresponding MEP must expect to receive OAM packets. These flags corresponding MEP must expect to receive OAM packets. These flags
are used to configure the role of MEPs. are used to configure the role of MEPs.
3.3.4. Continuity Check (CC) Sub-TLV 3.3.4. Continuity Check (CC) Sub-TLV
The Continuity Check (CC) sub-TLV is depicted below. The Continuity Check (CC) sub-TLV is depicted below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (4) (IANA) | Length | | Type (4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prio | CCM I | Reserved (set to all 0s) | | Prio | CCM I | Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 4, Continuity Check (CC) sub-TLV.
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. Pro-active Performance Monitoring 3.4. Pro-active Performance Monitoring
skipping to change at page 13, line 32 skipping to change at page 13, line 35
commands, for pro-active PM it may be desirable to utilize the commands, for pro-active PM it may be desirable to utilize the
control plane for configuration and activation together with Fault control plane for configuration and activation together with Fault
Management functions such as Continuity Check. Management functions such as Continuity Check.
ITU-T Y.1731 defines dual-ended Loss Measurement as pro-active OAM ITU-T Y.1731 defines dual-ended Loss Measurement as pro-active OAM
for performance monitoring and as a PM function applicable to fault for performance monitoring and as a PM function applicable to fault
management. For dual-ended Loss Measurement each MEP piggy-backs management. For dual-ended Loss Measurement each MEP piggy-backs
transmitted and received frame counters on CC messages; to support transmitted and received frame counters on CC messages; to support
and synchronize bidirectional Loss Measurements at the MEPs. Dual- and synchronize bidirectional Loss Measurements at the MEPs. Dual-
ended Loss Measurement is invoked by setting the Performance ended Loss Measurement is invoked by setting the Performance
Monitoring/Loss OAM Function flag in the OAM Configuration TLV Monitoring/Loss OAM Function Flag in the OAM Function Flags Sub-TLV
[OAM-CONF-FWK]. Besides configuring the Continuity Check [OAM-CONF-FWK]. Besides configuring the Continuity Check
functionality, no additional configuration is required for this type functionality, no additional configuration is required for this type
of Loss Measurement. of Loss Measurement.
3.5. Ethernet OAM configuration errors 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
skipping to change at page 15, line 7 skipping to change at page 15, line 7
o If the combined length of MD Name and Short MA Name must be less o If the combined length of MD Name and Short MA Name must be less
or equal to 44bytes, if this is violated an error must be or equal to 44bytes, if this is violated an error must be
generated: "OAM Problem/Name Length Problem". generated: "OAM Problem/Name Length Problem".
o If a node does not support the requested CCM Interval an error o If a node does not support the requested CCM Interval an error
must be generated: "OAM Problem/Unsupported CC Interval". must be generated: "OAM Problem/Unsupported CC Interval".
4. IANA Considerations 4. IANA Considerations
This document specifies a new Ethernet OAM Configuration TLV to be This document specifies the Ethernet OAM Configuration sub-TLV to be
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.
IANA is requested to allocate the value 1 for Ethernet OAM from the
OAM Type space in the "RSVP-TE OAM Configuration Registry" and
allocate type 1 for the Ethernet OAM Configuration sub-TLV from the
OAM Type sub-TLV space in the "RSVP-TE OAM Configuration Registry".
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 signaling of OAM related parameters and the automatic This document does not introduce any additional security issuse to
establishment of OAM entities introduces additional security those discussed in [OAM-CONF-FWK].
considerations to those discussed in [RFC3473]. In particular, a
network element could be overloaded, if an attacker would request
liveliness monitoring, with frequent periodic messages, for a high
number of LSPs, targeting a single network element.
Security aspects will be covered in more detailed in subsequent
versions of this document.
6. Acknowledgements 6. Acknowledgements
The authors would like to thank Francesco Fondelli, Adrian Farrel, The authors would like to thank Francesco Fondelli, Adrian Farrel,
Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful
comments. comments.
7. References 7. References
[GELS-Framework] 7.1. Normative References
"GMPLS Ethernet Label Switching Architecture and
Framework", Internet Draft, work in progress.
[GELS-PBBTE] [OAM-CONF-FWK]
"GMPLS control of Ethernet PBB-TE", Internet Draft, work "OAM Configuration Framework for GMPLS RSVP-TE", Internet
in progress. Draft, work in progress.
[GMPLS-OAM] [RFC5828] "GMPLS Ethernet Label Switching Architecture and
"OAM Requirements for Generalized Multi-Protocol Label Framework", RFC 5828, March 2010.
Switching (GMPLS) Networks", Internet Draft, work in
progress. [RFC6060] "Generalized Multiprotocol Label Switching (GMPLS) Control
of Ethernet Provider Backbone Traffic Engineering
(PBB-TE)", RFC 6060.
7.2. Informative References
[IEEE-CFM] [IEEE-CFM]
"IEEE 802.1ag, Draft Standard for Connectivity Fault "IEEE 802.1ag, Draft Standard for Connectivity Fault
Management", work in progress. Management", work in progress.
[IEEE-PBBTE] [IEEE-PBBTE]
"IEEE 802.1Qay Draft Standard for Provider Backbone "IEEE 802.1Qay Draft Standard for Provider Backbone
Bridging Traffic Engineering", work in progress. Bridging Traffic Engineering", work in progress.
[OAM-CONF-FWK]
"OAM Configuration Framework for GMPLS RSVP-TE", Internet
Draft, work in progress.
[RFC3469] "Framework for Multi-Protocol Label Switching (MPLS)-based
Recovery", RFC 3469, February 2003.
[RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description", RFC 3471, January 2003.
[RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4377] "Operations and Management (OAM) Requirements for Multi-
Protocol Label Switched (MPLS) Networks", RFC 4377,
February 2006.
[RFC4420] "Encoding of Attributes for Multiprotocol Label Switching
(MPLS) Label Switched Path (LSP) Establishment Using
Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE)", RFC 4420, February 2006.
Authors' Addresses Authors' Addresses
Attila Takacs Attila Takacs
Ericsson Ericsson
Laborc u. 1. Laborc u. 1.
Budapest, 1037 Budapest, 1037
Hungary Hungary
Email: attila.takacs@ericsson.com Email: attila.takacs@ericsson.com
 End of changes. 42 change blocks. 
108 lines changed or deleted 86 lines changed or added

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